"Safe" Z Probe
-
I think he's saying that the secondary probe will keep moving the full length of the axis if the probe fails to trigger even though the first probe succeeded and it's only a few mm away from the surface.
-
@Phaedrux *she
@fcwilt The setup is the machine uses the probe to home Z. No Z max endstops.
What I mean is if the printer is homed after startup, assuming the motors are not powered off, during future home cycles the printer should have an idea of how far it needs to move until it reaches home again. This goes for all axes, but Z is generally the most dangerous to overshoot.
Currently, a standard G30 (used for homing the Z axis) will command a move of 1.1x the axis length to reach the trigger point, even if it knows it should only need to move 20mm (plus probe z offsets), assuming it's at Z20. A safer G30 would command a move of 20mm+probe offsets, plus an additional Xmm (X being configurable) in this situation, stopping if it fails to trigger.
A G1 based homing move could fairly easily be configured to do this, but you can not specify the commanded move distance of a G30 currently AFAIK.
-
The problem that I see is that just because the Z axis is homed it doesn't mean the Z position is accurate.
If I do this command G92 Z50, as far as the firmware is concerned Z is homed and the position is 50. I've basically "lied" to the firmware.
But since the G30 move is going to stop when the probe is triggered the benefit of a limited G30 move would seem to apply only in the case of a failed probe. Now I'm sure folks have experienced failed probes but how often does it happen?
And since the "safe G30" would only take effect if the printer was already homed why is homing being done again? Or are you talking about a G30 that is not being used for homing?
You can achieve what you want now by using M208 to set a temp set of Z axis min/max values and reset them after the G30.
Thanks.
Frederick
-
@fcwilt I just wanted an option, an additional parameter that does not have to be used. I don't understand why you're so hostile to this idea.
It is rare to use G92 to set an axis to a useless value, and generally it is temporary. This edge case does not invalidate the usefulness of this (optional) feature.
I think it's standard practice to home at the beginning of a job. The state of the machine should not be assumed at the beginning of a print. Heated beds swell, and some people have multiple build surfaces. Generally these don't cause variations greater than a few mm, but it would affect the print. This is like saying "why would you set the bed and heater temps after they've been set once?".
This suggested solution is janky, and homing from short distances may cause issues, while homing from long distances doesn't help. The 1.1x the axis length is not configurable AFAIK, and on large machines (ours has a 1m long Z axis), homing from near the bottom means the extra length equals near 100mm, which is quite thoroughly smashing the gantry if something goes wrong and isn't caught.
-
Not hostile at all. But I don't see any compelling benefit.
As to the example of G92 that was simply to point out that the homed status and the Z position can change in unpredictable ways. Implementing a "safe" homing using G30 requires trusting that state of the machine. Yet the assumption behind homing is that the state is unknown.
And since you can use M208 to achieve exactly the behavior you seek and I would think that would be acceptable.
Why is it not?
Frederick
-
@fcwilt said in "Safe" Z Probe:
And since you can use M208 to achieve exactly the behavior you seek and I would think that would be acceptable.
Why is it not?I already explained why I do not think that is an acceptable solution.
@curieos said in "Safe" Z Probe:
This suggested solution is janky, and homing from short distances may cause issues, while homing from long distances doesn't help. The 1.1x the axis length is not configurable AFAIK, and on large machines (ours has a 1m long Z axis), homing from near the bottom means the extra length equals near 100mm, which is quite thoroughly smashing the gantry if something goes wrong and isn't caught.
Again, my suggestion is an optional parameter that can be used in certain contexts. It's not meant to be used for every probing move, it's just an extra safety to help avoid major crashes if configured. If your proposed solution were more satisfactory, how is it different from my suggestion? Doesn't your solution have the same theoretical problem? Why is your solution free from the criticism of my suggestion?
@fcwilt said in "Safe" Z Probe:
As to the example of G92 that was simply to point out that the homed status and the Z position can change in unpredictable ways.
What situation is that? Can you provide a realistic example that doesn't involve an unrealistic use of G92?
I don't see how this discussion is productive, I asked for a feature to be added, and you are picking apart my request when, forgive me if I am wrong, I don't think you are in charge of implementing it.
I have provided a realistic situation (one that actually happened recently), and a simple way the firmware could've helped me in this situation. I have modified the homing routine to not try to home over the hole, but other printer setups still have this problem with no real solution (Inductive probes on aluminum beds with magnet sheets, I had a similar crash on my ender 3 with a superPINDA a few months ago. I took the steel sheet off and forgot to replace it. The magnetic sheet is too thick for the probe to pickup on the aluminum bed). I would implement it myself with conditional gcode if I were using G1 homing moves, but I would prefer to keep using the simplicity and readability of G30.
-
@curieos said in "Safe" Z Probe:
I already explained why I do not think that is an acceptable solution.
Sorry but I didn't see any explanation directed to the pros/cons of using M208.
Could you elaborate?
Frederick
-
@fcwilt Am I misunderstanding what you mean by using M208? In my example, if the bed is near the max limit, say Z900, and I set the max length of the axis to 900mm, which I believe is what you're suggesting, then the G30 move will move the Z axis 990mm. If the probe fails to trigger, 90mm is equivalent to the length of our hotend+extruder. Best case, if this isn't caught by the user, the Z motors stall out after the hotend has buckled and snapped off, after the bed is turned into a taco and the gantry has been twisted.
The opposite situation, say the Z axis is at first layer height, 0.3mm. The homing scripts and probe deploy script move the bed down, but that's only around 10mm. This means if there is more than 1mm deviation from the previous home position it won't probe successfully. If the user swapped bed plates (we have an FR4 plate that is around 1mm thicker than our PEI plate), this could happen. This example may be worsened due to probe offsets, since 10mm is relative to the tool, not the probe. Our probe is around 5mm lower than the tool.
If I misunderstand what you mean by using M208, please inform me on how I can use this to emulate the behavior I desire. As I see it, this is not an acceptable solution, and in my opinion it's janky at best.
-
Well it turns out that G30 does not appear to move 1.1 x the length of the axis.
A quick test suggests that it does not.
My whole theory of using M208 was based on that belief.
What I did was issue this commands (the printer was already homed) from the console:
- G1 Z200
- M208 Z175:200
- G1 Z150
- G1 Z200
- G30
Now the G1 Z150 failed, as expected, stopping at Z175
But, to my surprise, what the G30 did was move slowly from Z200 to Z175 and then picked up speed and kept on moving. It stopped around Z10 which did not trigger the probe. It then moved slowly back to around Z200. It then tried again moving slow then fast and again stopping around Z10. The probe was never triggered and the error message confirmed this. And the Z position was displayed as 3.75 which is the sum of the probe dive height setting and the probe z trigger height setting.
So it did stop short of moving far enough to trigger the probe but the move was clearly much more than 1.1 x the axis length if 25. What the actual behavior is, is not obvious.
So achieving your goal is going to need help from @dc42
Frederick
-
@fcwilt That is interesting. Granted this was a few years ago, but according to Dave on this post, it moves 1.1x the axis length.
My only thought is perhaps it has to do with the format of your M208. I'm not sure where I got this impression, but I thought I saw somewhere that setting axis minima/maxima via
min:maxwas deprecated, and you're supposed to do it via separate M208 commands with S0 and S1. There's no indication of this in the documentation though, so I'm not sure where I got this impression. -
I've used the aaa:bbb form of M208 since I first read about it. I find it easier to remember than which S parameter is min and max.
I also issued M208 by itself to verify that the changes took place.
It's really too bad that the movement isn't limited to 1.1 x the axis length. Had it work that way changing the Z axis "length" using M208 could have been used to limit the length of a G30 move.
Changing the Z axis "length" to 25 did prevent it from reaching the probe but it stopped just 10mm or so short. I was counting on it stopping after 27.5mm. So let's say it moved 190mm. That is 7.6 x the 25mm. That makes little sense. I really have no idea what it is doing.
Frederick
Printers: A FT-5 with the 713 upgrade bits, a custom MarkForged style, a small Utilmaker style, a small CoreXY from kit and a E3D MS/TC setup. Various hotends. Using Duets (2 and 3) running 3.4.6
-
@fcwilt I agree, that format for M208 is more readable without comments. Don't know where I got the idea that it is deprecated from.
Thanks for giving your idea a try. It would've at least been a solution to tide things over until I get a response from the Duet team.
-
@fcwilt if you set the Z axis values to 0:25 rather than 175:200, does the behavior improve? if yes, maybe there is an issue in how rrf determines the maximum length moved before aborting the homing move.
-
@oliof said in "Safe" Z Probe:
@fcwilt if you set the Z axis values to 0:25 rather than 175:200, does the behavior improve? if yes, maybe there is an issue in how rrf determines the maximum length moved before aborting the homing move.
I will perform that test after diner and post back here.
Frederick
