Catch movements beyond axis limits

justus2342

I would like to have some mechanism, that triggers custom gcode when a (print) move is soft-limited because it goes outside the printable area.

I would like to have this feature, to catch problematic prints before they actually fail.

dc42

@justus2342 said in Catch movements beyond axis limits:

I would like to have this feature, to catch problematic prints before they actually fail.

Unless the GCode file declares the limits of the print at the start, that would require scanning the whole GCode file to determine the limits, before they can be compared with the bed limits. Here are two ways in which that could be done:

If you use Duet with attached SBC, that could be done using a DSF plugin.
In standalone mode, it would be possible to run the print in simulation mode and have RRF warn or abort the simulation if it goes outside limits

In fact I think it may already be possible use simulation mode to achieve this. RRF tracks the limits of each object being printed, and those limits are available from the object model. So I think you could construct a stop.g file that compares the object limits with the bed limits.

justus2342

For clarification: I wrote

catch problematic prints before they actually fail.

Of course it would be nice, to check even before the print starts. But to my understanding it would also be sufficient to have a trigger, when a move outside the print area is about to happen or just happened. That is what I am suggesting here to implement.

A potentially catastrophic failure would be prevented if the print is paused just after the "bad" print move.

@dc42 said in Catch movements beyond axis limits:

If you use Duet with attached SBC, that cold be done using a DSF plugin.

Are you referencing to a existing plugin or are you just pointing out that such a plugin could be written?

jay_s_uk

@justus2342 he's pointing out one could be written

OwenD

@justus2342
If you are using Prusa Slicer or SuperSlicer then you can get the values and just call a macro to do the checks provided that you use a skirt.
The slicer only appears to provide access to the first layer, so if you don't use a skirt, it won't work in a print that has a small base.

Put something like this in your slicer start code

M98 P"0:/sys/checklimits.g" A{first_layer_print_min[0]} B{first_layer_print_max[0]} C{first_layer_print_min[1]} D{first_layer_print_max[1]} E{(total_layer_count-1)*layer_height+first_layer_height}

Then in your macro do this

;0:/sys/checklimits.;
; used to ensure print isn't outside bed limits
; requires paramaters A,B,C,D,E be sent from slicer
if (!exists(param.A)) || (!exists(param.B)) || (!exists(param.C)) || (!exists(param.D)) || (!exists(param.E))
	abort "Limits check macro called with no parameters"

if (param.A < move.axes[0].min) || (param.B > move.axes[0].max) || (param.C < move.axes[1].min) || (param.D > move.axes[1].max) || (param.E > move.axes[2].max)
	abort "Print moves outside bed limits - print aborted"

EDIT: Corrected typo and added Z height check

T3P3Tony

@OwenD said in Catch movements beyond axis limits:

The slicer only appears to provide access to the first layer, so if you don't use a skirt, it won't work in a print that has a small base.

unfortunately AFAIK prusa slicer skirt is only around the base layer so this does not help for prints that have a small base.

OwenD

@T3P3Tony said in Catch movements beyond axis limits:

@OwenD said in Catch movements beyond axis limits:

The slicer only appears to provide access to the first layer, so if you don't use a skirt, it won't work in a print that has a small base.

unfortunately AFAIK prusa slicer skirt is only around the base layer so this does not help for prints that have a small base.

Indeed that is correct.
So post processing or simulating is required.

mrehorstdmd

I know Prusa slicer and Cura both warn when the print is too big for the printer. AFAIK, all slicers will prevent you from generating gcode files that go beyond the print limits of the machine- that's why they want to know how big the bed is and the maximum Z dimension when you configure the printer.

If you're trying to run gcode generated for a different machine on your printer all bets are off. For that I'd say either don't do it or write a simple processor that reads the coordinates of all the moves in the gcode file and looks for any that are beyond the limits of your printer. Movement beyond axis limits is only one problem. There could be all sorts of other problems buried in the gcode, such as print speed or acceleration being too high for the printer.

If you're trying to detect layer shifting while printing, you'll need some limit switches that detect movement beyond axis limits because in a layer shifted print, the controller thinks everything is fine, even if it sends the extruder and/or bed beyond the limits of an axis. Keep in mind that layers can shift without moving beyond axis limits, so those added switches may not do any good. Some Markforged printers detect layer shifting by rehoming X and Y axes after every layer. If the extruder and/or bed travels the correct distance to reach home, the print isn't shifted and it's OK to print the next layer. I ran an experiment with this idea when I installed optical endstops in my corexy printer. The problem with rehoming every layer is it adds significantly to the total print time even as it minimizes wasted filament. You could rehome every 10th layer- that would reduce time spent rehoming but allow some waste of filament if the print was shifted.

My printer doesn't shift, ever, because I use conservative settings and maintain the mechanism. If you're experiencing frequent layer shifts, maybe there's a hardware problem that needs to be addressed, or it's time to adjust your expectations of the printer's performance limits and reconfigure accordingly.