Update macros.cfg for buggy AUTO_BED_LEVEL #229
Conversation
There was a bug in calling down to BED_LEVEL and passing a name that could have spaces in it. Added requoting name. Also, there was a problem IF you started auto bed level when bed temp was ABOVE the target temp already, it would NOT wait for it to cool down to target. Fixed this with a preliminary bed temp target.
|
I confirm this works great on my AD5M Pro–thanks for fix it! This should get merged asap, kind of a big fix for a function that's used extensively. |
|
Is there a reason this hasn't been merged yet? I'm trying to figure out if this repo is under active development |
|
None that I'm aware of. I have not seen activity here for quite a while and I'm beginning to despair of getting newer updates. |
|
@Krumpet You can just copy the file over ssh or via fluidd/mainsail. I think frankly things work so not really much to fix. I think the print pause/runout macro does need to be resolved but other than that I haven't encountered anything |
|
...I would like to have some of the newer bed_mesh routines (adaptive) of newer Klipper, and possibly a way to update to newer python and base Linux. Extremely limited on update/curl/git as is and worse, I've been getting like 7 TTC failures for every ONE good print of late. It is getting worse. Granted, I've broken out my config files quite a bit to make them more accessible and in a manner that I like (hardware, macros, bed mesh, status) and I've added a custom Knomi v2 print head. I've likely gone too far with this as it is, but I simply can not go back to no Fluidd/Moonraker and not having control. It's a bummer too, because I love how this printer prints. It is pretty good. But I think it's time to build a Voron Trident and get a "real" Klipper setup. |
|
I'm looking to build a voron as well, but being able to cancel individual
objects or monitor the printer from afar without flashmaker are very
appealing to me as well, in addition to getting to know klipper in general
…On Wed, Oct 30, 2024, 16:25 Jeff McClain ***@***.***> wrote:
...I would like to have some of the newer bed_mesh routines (adaptive) of
newer Klipper, and possibly a way to update to newer python and base Linux.
Extremely limited on update/curl/git as is and worse, I've been getting
like 7 TTC failures for every ONE good print of late. It is getting worse.
I've likely gone too far with this as it is, but I simply can not go back
to no Fluidd/Moonraker and not having control. It's a bummer too, because I
*love* how this printer prints. It is pretty good. But I think it's time
to build a Voron Trident and get a "real" Klipper setup.
—
Reply to this email directly, view it on GitHub
<#229 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEUXSXPUTCG5DMS7PU7QDP3Z6DT6VAVCNFSM6AAAAABLO7J5GCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBXGMZTMMBZHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Yup! this platform has been a WEALTH of learning and experience and the KlipperMOD has really been a good platform to learn from and work through. It is long over-due to dive in and get a Siboor AWD CNC Trident 350mm and start that learning. I've just pushed this platform further than it was ever intended. And I don't regret a cent spent on it or what I've learned. It has dramatically improved my understanding of 3D Printing and slicers and setup for quality with all the test prints to make a much more informed decision and build my own Voron. How Moonraker and Fluidd/Mainsail interact and getting familiar with klipper config files... Totally worth it. |
Most of the development in this repo has been done by xblax and consp. They basically two-handed (four-handed?) most of the core features. And ballaswag really helped porting guppy over, being that theirs own creation. Realistically, this is as far as the mod can move forward feature-wise without action from Flashforge. The fact we have been unable to compile and update a workable firmware in the tool-head has been quite frustrating, but neither I or the others had any luck with that. I am sure this PR will be tested and picked up in case of a future release, but for now it is an easy fix one can perform on their own :). |
Yup! No worries on my part upgrading manually, and I did NOT mean to make it sound like I was at all unappreciative of what the folks that contributed to this original product made. It has really allowed me to experiment with a fairly cheap printer and become familiar with Klipper and the various tools used with it. It is just so unfortunate that I have had such a horrible time with MCU: TTC failures (getting worse of late)...so much so that I'm now back to stock FW and completing my Voron Trident purchase/config. Thank you all for the support here (wish there was a "simple fix to the TTC", but i realize that is a "catch all" in Klipper for hardware that is typically exceeding the demands being placed on it... |
What features do we not have that would require any action from FlashForge to achieve? |
As I wrote before:
It is likely that them, on someone they contracted to work on klipper, patched the C part of klipper to work on a "cloned" arm processor. Basically the instruction set is the same, specs are more or less aligned, but the on-board devices are mapped differently. Without that piece of information it is very hard to update klipper and have an operational toolhead. Flashforge should disclose how they built the C firmware fully, and how their repo was patched to do so. This information is not present in the fork they gave us few months back. |
Sure, I'm familiar with Nation's STM32 clones. What's confusing to me is why this is an issue, as the particular N32 FF used in the toolhead board is natively supported in Klipper, at least assuming Klipper's commit history and its own menuconfig is to be trusted. Compiling firmware for this chip takes only moments, a proper update mechanism would be the hardest part to track down if that isn't already known, but is probably just in FlashForge's init scripts or the updater script like most things on these printers. Config for the MCU shouldn't need to change if we swap Klipper versions, but even if it does that's not a difficult or time consuming task. We don't need FlashForge for anything here. |
|
Yes, you can compile the firmware. For reference: #155 |
Do we know if there is an official update mechanism or not? Or did they just plan to leave the toolhead firmware alone... Edit: My machine arrived. I found the toolhead update process rather quickly. |
|
Crazy this still hasn't been merged yet. Looks like this project has effectively been abandoned. |
As I wrote before, it is not crazy. It will be most surely merged if/when a new release will happen. Keeping this as an open PR at least allows people to see it and patch accordingly. |
There was a bug in calling down to BED_LEVEL and passing a name that could have spaces or special characters in it. Added requoting name. Also, there was a problem IF you started auto bed level when bed temp was ABOVE the target temp already, it would NOT wait for it to cool down to target. Fixed this with a preliminary bed temp target. FINALLY, the extruder TEMP was being allowed to just FLOAT (not actively driven) once it got below 120'C to start the CALIBRATION. This is bad, as it can change the bed level. Most sources recommend calibration at no more than 150'C on extruder to avoid damaging the bed sheet, but you should ALWAYS be driving it. This is changed to allow it to CAL at 150'C and steady.