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

infiniteloop

@MaxGyver Where’s the problem? If you use G30 within your calibration process, they are embedded in scripts - when writing those scripts, you might possibly remember the permitted coordinate range. If not (or if you intend to enter probe points from the console), use a macro instead. This macro can clip any input to the working area constraints.

gloomyandy

@MaxGyver Not sure if it helps but "normal" G30 probes (without a P parameter) do not take X/Y coordinates so there is no chance of moving out of bounds with those. So that leaves G30 commands as a part of bed levelling and other operations. I agree you might exceed the bed then, but there are plenty of other places (like homing operations etc.) when it is also possible to exceed limits. In such situations I would suggest lowering motor power and taking other precautions if possible.

MaxGyver

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

Where’s the problem? If you use G30 within your calibration process, they are embedded in scripts - when writing those scripts, you might possibly remember the permitted coordinate range.

Having to know and remember all the cases where the axis can move out of bounds is kind of my problem. I am not trying to be lazy here, I just want to improve the user experience and make the duet system safer and more intuitive to use.

For example, I have just installed the Duet scanning Z-probe. The probe is mounted with an offset of 25mm in Y-direction.
Setting the probe offset to 25mm made the head move out of bounds and damaging the probe coil. →Very frustrating and on larger machines dangerous.
Granted, It says so in the documentation. I have read the section on G30 more than once and still did not remember in this case.
For the probe points at the Y-min, I added an offset to counter the probe offset: → not very intuitive.

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

[...] but there are plenty of other places (like homing operations etc.) when it is also possible to exceed limits. In such situations I would suggest lowering motor power and taking other precautions if possible.

Exactly, but what are all those cases? I certainly don't know.

I understand that the axis can not adhere to limits if they have not been homed or during homing. But when an axis has been homed and the machine boundaries are known, I would expect the machine to adhere to these boundaries, like with every CNC-Machine controller that I have worked with so far. I understand that with 3D-Printers and nema17 motors it is not a big deal, but the Duet is becoming a good alternative for established CNC-Controllers. Especially with the Duet 6XD that I am using with AC-Servo drives ( I don't know if I can lower the current on those)

gloomyandy

@MaxGyver 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.

As to what operations allow movement outside of the limits... Well clearly any homing moves, special probing moves (but only with a P parameter), any code that makes changes to the limits, G1 H2 moves, any moves after M564 H!/S1, possibly some others. Most of those you are unlikely to be using on a CNC machine, but like any sharp tool take care.

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.