[3.5.0-rc.3] G30 probe point does not respect axis limits

MaxGyver

@gloomyandy said in [3.5.0-rc.3] G30 probe point does not respect axis limits:

If you are really concerned I'd suggest that you wire limit switches (in addition to any homing switches) that kill the power if they are triggered. Simple and they do not rely on any code to execute. Anything that relies on "soft limits" can go wrong.

On my CNC-Machines I have this security switches installed as a last resort security measure. They will stop the machine before it hits the bearing support of the spindle axis. But when these switches are triggered, the machine is already far outside its boundaries, meaning that before the security switches are hit something else might get hit first. Just like my Z-probe that got caught on aluminum profile just before the Y-axis touched its physical endtsop.

infiniteloop

@MaxGyver

Having to know and remember all the cases where the axis can move out of bounds is kind of my problem.

That depends on which bounds you mean. Prior to homing all axes, there are no bounds at all - just mechanical limitations (who might cause damage on a powerful machine if it runs into these).

After homing, you set up a coordinate system related to the tool tip - you zero-in on a single point. In practice, the machine’s head tends to be more spacious, so you have to take various offsets into account. This can be cumbersome, especially with regards to the Z probe, but there’s no other way.

At this stage of the setup, the bounds define the physical range your tooltip can operate within - which might still include regions outside of the working area. That’s why you can further restrict axis movement with M208. This working area should be safe in the sense that, while executing milling instructions, these will not exceed the limits.

During the setup process, this safety cannot exist - else, you would not be able to probe the limits. The same applies to tool changes: you will have to recalibrate your Z-height (which is inherently unsafe). For that reason, I suppose to enclose these potentially dangerous ops in carefully crafted macros.

dc42

@MaxGyver said in [3.5.0-rc.3] G30 probe point does not respect axis limits:

Setting the probe offset to 25mm made the head move out of bounds and damaging the probe coil.

is that with G29 or G30?

MaxGyver

@dc42 said in [3.5.0-rc.3] G30 probe point does not respect axis limits:

is that with G29 or G30?

G30 during four screw bed leveling: Please note that I have added the above-mentioned offset of 25mm to the PrintY_min point in order to counteract the probe Y-offset to keep it from crashing.

G30 K0 P0 X{global.PrintX_min} Y{global.PrintY_max} Z-99999 ; probe rear left
G30 K0 P1 X{global.PrintX_max} Y{global.PrintY_max} Z-99999 ; probe rear right
G30 K0 P2 X{global.PrintX_max} Y{global.PrintY_min+25} Z-99999 ; probe front right
G30 K0 P3 X{global.PrintX_min} Y{global.PrintY_min+25} Z-99999 S4 ; probe front left and calibrate 4 motor

MaxGyver

@infiniteloop said in [3.5.0-rc.3] G30 probe point does not respect axis limits:

During the setup process, this safety cannot exist - else, you would not be able to probe the limits. The same applies to tool changes: you will have to recalibrate your Z-height (which is inherently unsafe). [...]

In therms of referencing the machine at startup, I absolutely agree with you. But everything after that should happen within these machine (soft) limits or not? I can't think of a reason to command the machine outside these limits, since it can't physically move there. Maybe we need something like machine-limits and work-limits? Just like we have machine and work coordinates in CNC. The machine limits are set after referencing (aka. homing) and are not exceeded. By defining work-limits the head movement can be limited to a specified boundary like for example the printing area.

infiniteloop

@MaxGyver said in [3.5.0-rc.3] G30 probe point does not respect axis limits:

Everything after that should happen within these machine (soft) limits or not?

When you run milling instructions, i.e. during normal operation, there should be no need to exceed the work area, so it might be a good idea to limit the axes to that instead of the physical machine limits. I understand that you want to apply the machine limits to every command except of those „milling instructions“. As RRF doesn’t provide more than one set of boundaries, I propose to secure the out-of-bounds instructions by macros who can observe the machine limits. Of course, probing Z with G30 can still fail, but as @gloomyandy stated, you then will have to provide power-killing limit switches to protect the machine.

dc42

@MaxGyver feel free to raise an issue about this at https://github.com/Duet3D/RepRapFirmware/issues. You might find there is one already.

soare0

@MaxGyver For such machinery, I would double the firmware with true hardware limit switches (good ones, not toys) coupled with brakes, and whatnot, just in case. I noticed that infiniteloop already suggested, but better twice told than none heard, as I think this is not optional but mandatory, by any regulation at least ...

T3P3Tony

@MaxGyver Turns out I agree with you:

https://github.com/Duet3D/RepRapFirmware/issues/818

I added a reference to this thread in the issue

That said I also get the points made by other that having a physical backup of some sort is a good idea. That could be a hardstop that cannot be broken/damaged or an of band e-stop , depends on the machine design.

T3P3 created this issue in Duet3D/RepRapFirmware

open [FeatureRequest]: Raise error if G30 is used to probe outside axes limits #818

MaxGyver

Thank you all for your feedback! In conclusion, we all agree that for heavier machines, hardware limit switches are a must-have or are even mandatory for machines that are used in professional/business environment.

@dc42
@T3P3Tony
Are the X and Y moves considered probing or travel moves in G30 Pnnn?
I assumed that moves in X and Y are travel moves that position the head above the next probing point, and only the following move in Z is the actual probing move. Therefore, the limits in X and Y should be respected like for any other travel move. This would avoid raising faults or adjusting the bed.g macro.