Printer Model: GeeeTech Mizar S
MCU / Printerboard: (Stock Mizar S)
Host / SBC: Dell Latitude E5440 on Ubuntu Mate klippyLog.zip (953.1 KB)
klippy.log (it was 33mb so I zipped it.)
printer.cfg (as .txt) included as it may be relevant printer.txt (20.0 KB)
Fill out above information andin all cases attach yourklippy.logfile (use zip to compress it, if too big). Pasting yourprinter.cfgis not needed Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there
Describe your issue:
…
EDIT: To be clear, the XYZ coordinates in my CFG ARE correct; the nozzle itself is the probe. As mentioned in body of this post, it’s not a BL Touch, it just uses the BL Touch section / programming for its operation. This is not a DIY solution, this is how the printer comes stock from Geeetech.
Basically, this printer uses BL touch for its probing when using Klipper, it’s not actually using a gravity deployed probe. It’s just a load cell / strain gauge that the hot end is mounted onto on the x carriage. Something that I encounter a lot when I decide to increase my bed mesh density in terms of probe counts as that the error rate seems to go up. That is to say every now and then, it will erroneously fail to measure and trigger a BL touch failed to deploy message. Where there’s nothing physical to deploy and it’s simply needs to probe again, is there a way for me to force Klipper to just probe again in the event of a failure to deploy? It’s extremely irritating if I have a bad day where it just seems to happen once in the span of a 9x9 probe and I have to keep starting it over and over again until it finally completes without a single instance of a failed to deploy message.
I’ve asked on Reddit in r/klippers but didn’t get any answers so I’m trying the official forum. I asked chat GPT as well and I gave some answers but I’m not convinced. I already have a retry amount and I was already under the impression that that was meant for if samples exceed the tolerance set in your configuration and not in the event of a failure to probe.
Please God tell me someone has an idea, If I’m not probing a 3x3 mesh it’s almost a complete guarantee that it’s not going to complete because of that stupid fucking error, AAHHHHHHH!!
My bed doesn’t have knobs to do any leveling so it has to all be done through bed mesh, and this sensor is driving me fucking crazy! I have to do a lot of probes and with such a high number like 6x6 or 8x8, it’s virtually impossible to get through and I have to just stand here and supervise starting over and over and over. What does many probes like an 8x8 it can take up to 10 minutes to complete on my printer.
I’m not sure what you are reporting here. It looks like you have installed some DIY loadcell and run it under [bltouch] settings. Expecting this to work seems overly optimistic.
If your loadcell setup only produces a trigger signal at a certain contact force, then probably your best bet is to treat it as a simple endstop.
Sorry I don’t think I was clear this definitely isn’t the DIY solution, the GeeeTech Mizar S comes equipped with this - they call the bed self-leveling however there’s nothing actually being leveled it’s just measuring the surface. Because of this I need to rely on using it as a sort of BLtouch. In fact in the firmware configuration file provided by the vendor, they use BL touch for the same purpose. It works fine except for when it has like these random moments of failure and I just wish I could do something about it
Im definitely sure - the “probe” or “BLTouch” in this case is actually the nozzle itself. Instead of the hotend / heatsink being mounted to the carriage directly, it’s screwed onto a little metal fork which is the strain gauge sensor, which itself is screwed into the carriage. I’ll find a pic and send it as soon as I can, I know this is throwing people for a loop here because it’s rather non-standard. Another printer uses the same solution - I think the Anycubic cobra or vyper cant remember which.
Here’s a couple of photos of the mechanism - note the top of the heatsink of the hotend is mounted to it. Also below is the URL for the sensor itself on Geeetech’s website so you can see it better.
(I didn’t say “I like this. Do you think I should buy it?” - I think that’s a comment on the site or something?)
Perhaps it was Geeetech who was too optimistic about this working, but for me I have to rely upon it entirely due to the fixed hotbed design hahah. I’ve used it for several months with Klipper now but have faced this issue on large bed meshes from the beginning. It’s fine if I’m doing like a 3x3 mesh but 4x4 and higher quickly becomes more and more irritating due to the increased chances of a random error.
Also when the fail happens, sometimes the nozzle doesn’t even move down, or it happens when it pushes down to the bed and then it just stops and throws that error out.
It works well if it probes without random errors stopping it, but I just have to find a way to make it continue if it thinks the probe didn’t work.
Interesting (mis)use of the BL-Touch.
I cannot meaningfully comment on this, but I’m surprised that it “somehow” works in the first place.
Since the BL-Touches are very special regarding their timing requirements and way they work, I’m not at all surprised that it does not work reliably.
I would experiment with a similar approach as the MicroProbe uses:
[output_pin probe_enable]
pin: PA8
value: 0 # Or 1 as I don't have a clue how this probes activates
[gcode_macro Probe_Activate]
gcode:
SET_PIN PIN=probe_enable VALUE=1 # or 0 see above
[gcode_macro Probe_Deactivate]
gcode:
SET_PIN PIN=probe_enable VALUE=0 # or 1 see above
[probe]
pin: ^PC4 # or !^PC4, again, no clue
deactivate_on_each_sample: False
...
activate_gcode:
Probe_Activate
G4 P500 # Allow 500 milliseconds for the probe to activate
deactivate_gcode:
Probe_Deactivate
