Probes cause Klipper to shutdown during middle of a print (long after homing, leveling, and bed mesh were completed) when they accidently disconnect (commonly a wire issue or timer too close issue depending on hardware used such as pi3, Beacon, and CAN bus toolhead setup.) These probes are no longer necessary after these probe necessary functions.
I propose on the Klipper backend to only enable the probe when homing, leveling, bed mesh, other probe necessary functions beforehand and afterwards to disable the probe. Instead of enabling/disabling probe entirely, could enabling/disable health checks of it to prevent a shutdown during a print when the probe is no longer being utilized.
This would be a win-win by if the probe is unable to communicate, it’ll shutdown during the next probe required function but won’t halt a print at >70% when one of it’s wires disconnect or timer too close event.
Providing and maintaining code and configuration complexity to work around a potential print failure due to a potential hardware defect doesn’t sound like a win-win situation to me.
While I cannot state the difficulty in which how much new code is required (could be 2 lines per probe function or much more code) and maintenance of said code, I had witnessed multiple printer owners request for this feature in private conversations including myself and had replaced these probe cables repeatedly (mostly due to poor cable routing within the printer design).
This feature would be a more of improving customer satisfaction and reputation of Klipper with handling these known probe failures. It would reduce plastic waste as we lose bed adhesion when Klipper turns off everything including bed heaters during a fatal error. Smaller print farms will run into this issue over time and wouldn’t need to re-print to avoid negatives reviews, returns, and damage to their reputation and reduce their plastic waste costs.
Imagine owning a printer with a failed print near it’s completion and not sure why it was failing, then ended up being a probe wire, when it isn’t necessary at that stage of the printing process. How would you feel as the printer owner?
Could you explain by what you mean by “probe”? Other than temperature sensors, there are generally no other “probes” running after homing. If one of these become loose then you won’t have temperature regulation of the extruder and bed, which is a good reason to stop a print no matter how close it is to finishing.
Similarly, you mention “Timer Too Close” as something that should be ignored/powered through. Do you understand that this error indicates that the printer can’t continue? Timer Too Close can be a difficult problem to fix as it can have many causes and is generally printer configuration specific.
This happens to everybody. You curse a bit and work at understanding the cause of the problem, maybe put a post here or on the Discord server if you don’t understand the problem or what the messages/klippy.log is telling you.
You’re looking for somebody to develop code to fix an unspecified problem which hasn’t happened yet on an unknown printer configuration.
Regarding this, there must be code for every imaginable circumstance that can fail a print - and also for the not imaginable ones.
Don’t you think this will blow up the necessary code to a big balloon that may cause issues itself?
Interesting perspective.
In my opinion, the correct questions to ask are:
Am I properly maintaining my printer(s)?
Am I using proper cable routing?
Am I using a cable specified for the intended use?
Am I accidentally using cheap consumer-grade printers with consumer-grade components for a business?
Sorry, but I’m a firm believer in fixing things in hardware when possible. This is certainly one of those cases where it can be done quite simply, and there’s no need to resort to a software band-aid. Just my 0.02 USD.
Edit:
I’m still wondering when a broken probe cable would forcibly cause a shutdown or TTC. The only reason I can imagine is if it causes a short-circuit, such as towards GND, which would at least crash the MCU anyway.
I’m referring to Z-probes. They aren’t required after homing, leveling, bed meshing; yet cause the printer to halt the print; especially beacon probe. It’s likely the beacon cable provided by the seller is the wrong type of cable is used for long term usage. Unfortunately, I do not recall every probe affected as I do not run a ticket system for others to keep track of their and my previous hardware issues.
Ignore “Timer too close” portion then; though seems to happen quite a bit with beacon and pi3 long after the homing, leveling, bed meshing is done.
From someone else, believe this is fixed in Kalico. I hadn’t tested it myself, but I would rather avoid switching firmware just for this issue.
Whom is Klipper’s main client, professional businesses or creators? Your mainboard sponsor, BigTreeTech, has always innovated for creators and solved their pain points. Most creators do not have large budgets nor have industrial knowledge on proper cabling/maintenance. Most of the time, creators start off using consumer-grade printers with consumer-grade components and replace those components with more consumer-grade components.
Unfortunately, most will blame the firmware for not ignoring the z-probes state beyond their required use as these z-probes aren’t needed at all once the print starts and causes the print to fail as the behavior logic doesn’t make any sense.
Most would use cables provided with printer kits or 3rd party solutions (like Beacon) than purchasing a separate proper chain cable and soldering/crimping the proper ends as they assumed the vendor already did their tests and provided the best cable for their use and just buy replacement cables from the same vendor.
Beacon connects to the host via a custom USB cable and has its own device driver. If a connector in the USB cable breaks, it is the Beacon USB device driver that is failing and causing the print to stop.
I don’t see this as a Klipper issue. It certainly isn’t reasonable to expect Klipper to compensate for a problem with a device driver that is not part of it’s basic functionality.
If you disagree, please provide a klippy.log in which a print failed due a beacon wire being broken so that it can be examined.
I cannot find any reference to a Kalico “fix”. Maybe you could post a link to show what’s been done there.
Regardless:
You’re using the plural “probes” when you’ve only provided a single example. Along with that, it seems to me that the problem is due to the Beacon USB device driver and not the fault of the firmware.
I get that you’re angry that a broken wire caused a long (maybe multi-day) print to fail but I would think that “most” people would try to understand the problem (because if it was a broken cable the printer would be offline until it was fixed) and then try to prevent it from happening again in the future - tying down the end with the single wires to eliminate movement/strain on them would be an obvious first step.
Actually, you are not. From what you are writing here, I’m meanwhile pretty sure you are referring to extra MCUs that are connected to Klipper and are performing various tasks, for example, probing.
It is correct that Klipper does not allow you to activate or deactivate additional MCUs at runtime.
Generally, my position also applies to this case: On a properly set up and built printer, you should have no TTC errors. Masking unstable MCUs by “turning them off” is akin to adding black tape to your car’s check engine light. Trying to mask symptoms and ignoring the root cause has never been a good idea.
I sure hope that Klipper will always stand true to its “error early, error comprehensively, and error hard” philosophy, as this will allow you to build stable machines, not ones that merely appear to be stable.
I and others had the break further down in the cable and both ends were tied down to eliminate strain. However, the printer would be fine when it restarted the firmware, likely there was some motion to have the cable connection reconnect fine again and worked normally during probe functions.
It’s possible it’s at MCU level with these probes and I know i haven’t provided additional affected probes as I do not recall which ones were affected but I know Beacon wasn’t the only one. USB drivers only load when the USB device is plugged in & unload when the connection is lost. It wouldn’t be on the USB driver when the cable disconnects.
However, how is a dedicated z-probe MCU that works fine during probing, but suddenly doesn’t respond/work when it’s not needed need to be fixed immediately?
With your definition, a car should have zero issues and if it has a single issue stop every function. It’s like your car’s check engine light turns on because a loose fuel cap, minor vacuum leak, tail light is out, or one of your tire pressure sensors is a bit low and your engine shuts down completely until it’s repaired and you have another 3 hours of driving to do to get to your destination. Reality allows the owner to continue to a gas station and fill up the tire or can wait till they can get to the mechanic when they are able to do so.
If it shuts down during a probe function due to unable to communicate, then no issue there as it’s absolutely required to communicate for probe function and would be a hard error then to prevent a hardware crash. Anytime after those functions, it’s not required.
I guess there is no need to, since this is a philosophical discussion, in the sense of “I’m not happy that there are errors; make a feature that allows turning them off”. This approach will likely lead nowhere since the difference between an MCU and its needs and a z-probe is not understood.
Kalico, which is a divergent branch of Klipper, has a non-critical mcu flag which will allow MCUs to disconnect from the system without throwing a critical fault and stopping print. Currently it doesn’t work for MCUs on CAN bus but that feature is being discussed.
For example, the config for beacon probe would have this flag allowing it to disconnect during a print without halting the system.
[beacon]
is_non_critical: true
As others have noted, this feature should not be a band-aid fix to ignore MCU disconnects or timer too close errors. It should be a mitigation for failed prints while root cause issues are fixed.
As I do not use Kalico, I cannot really comment, but declaring the MCU as non-critical, which is responsible for homing and stopping your axis before the nozzle sticks out of the wrong side of the bed, sounds like fun.
Klipper is designed to make you fix your hardware issues before you print. If you don’t fix hardware issues, things could fail catastrophically later on.
This feature only allows the system to accept heartbeat errors for the non-critically configured MCUs (as i understand it). The system will still throw a halting error if that MCU is called on for any other function such as homing or stopping the axis (beacon for example). It has been pretty well tested and used for a good period of time.
That is acceptable to completely halt if the particular function cannot reach the required MCU at the time it’s required. Most of the time the function will communicate fine with the required MCU, then the heartbeat fails at >50% completion of a print & causing printer halt and print failure. Eventually, it’ll worsen to the point when the function fails and would need replacement unless there is a warning indicator that flags up at the time of failure like a car warning indicator; then we, the 3D printer mechanic, can get it replaced as soon as we can.
I’m not saying the hardware problem would be completely ignored. Even a normal car owner will replace the dead battery, sometimes needing to jump it until replacement can be obtained. Same with other failures such as a bad inlet O2 sensor doesn’t shutdown the entire engine from functioning.
If a MCU has heater/s & their associated temp sensor/s, and/or motor/s, then heartbeats shouldn’t be ignored at all for obvious reasons.
