[FR] Abort print if out-of-bounds

[RDS356]

Is your feature request related to a problem? Please describe.

Why the Marlin do not stop the job and send a message when soft limits is reached ? There is no sense just stop the move outside area and continue with a wrong or damaged work. I'm using Marlin with 3d and cnc router control. Regards, Reinaldo de Souza

Are you looking for hardware support?

No response

Describe the feature you want

Something like this;

DEFINE STOP_JOB_WHEN_SOFT_LIMITS TRUE

Additional context

No response

[thisiskeithb]

If you install endstops on both ends of travel limits, you can use: SD_ABORT_ON_ENDSTOP_HIT

https://github.com/MarlinFirmware/Marlin/blob/59f2f4fd47deaea59b7a8f1a43e8a66e05f17ca6/Marlin/Configuration_adv.h#L1546-L1551

[RDS356]

Is not possible setting travel soft limits and using only homming system ? The GRBL, mach3 and others works like this.

[ellensp]

This is why you run CNC firmware on CNC machines and 3d printer firmware on 3d printers.... not 3d printer firmware on CNC machines! They re not fully interchangeable

[RDS356]

Why do we have 'SPINDLE LASER' options in Marlin ? And have a logical question , why continue the job if it will damage ?

[thinkyhead]

I suppose it would be better to pre-scan the entire G-code file in advance and simply forbid starting the print if anything in the G-code instructs the machine to go out of bounds. I mean, why wait until you're in the middle of some impossible job?

[karliss]

I mean, why wait until you're in the middle of some impossible job?

Why continue the job when inputs show that something has clearly gone very wrong? Does marlin not have a safety check for thermal runaway, does it not work when sending gcode from slicer? Prescaning g code file is barely an improvement over having the same check in slicer or CAM software and it doesn't work if gcode is streamed from computer or smart LCD. People make mistakes and hardware sometimes goes bad. There are many things that can go wrong. You can accidentally use wrong config, upload wrong firmware file, specify the wrong machine size, specify wrong steps/mm, type an extra 0 when manually moving, homing may partially fail, movement hardware can slip , motor can skip steps, you might bump and move an axis after homing, you might have bugs experimental motion planner or kinematics, something else unpredicted. None of those should happen regularly if everything is good, they might cause even bigger problem before hitting limit switch , they may sometimes be caught by different check but safety checks are for cases when things go bad.

[DiskDoctor]

Please add this issue when trapping travel errors beyond bounds: https://github.com/MarlinFirmware/Marlin/issues/24050

[thinkyhead]

Why continue the job when inputs show that something has clearly gone very wrong?

We're talking about something which would be checked by looking at the coordinate values, not by detecting a switch being hit during the print, and that could be determined by a pre-scan of the file. However it is true that this would not catch a bit-flip caused by a solar flare.

[descipher]

While it is not difficult to implement a simple "if gcode request exceeds the co-ordinate bounds then abort" but it could occur in the last gcode of the entire job .. lol Pre parsing would be better but .. what is the actual goal of this request?

[lukasradek]

I think there are a few misundestandings in this thread.

First, it seems to me that the loud voices here think that when they visually see the printer out of soft bounds the printer always knows about it. It doesn't. If there is a hardware failure (skipped steps, belt slip) or misconfiguration (steps/mm) the printer still thinks it is inside print area... it just does not know that the hardware failed or is misconfiged - it is an open loop system. By using hardware endstops you can convert it to closed loop system.

So the only case when the printer knows it is out of bounds (so that it can do something about it) is when it is part of the instructions - gcode file. Hence if you want to prevent user error during slicing, checking the gcode before printing is fully sufficient.

(Second, the knowledgable voices here think the others know that 🙂.)

If you want to prevent hardware failure (which is suggested by the comparison to thermal runaway) you have to install hardware endstops. Full stop.

Likening the OP issue to thermal runaway is just plain lack of understanding. Thermal runaway is not something that is planned in the gcode. Thermal runaway is a hardware failure which can be detected because there is a closed loop in place thanks to thermal sensor.

The correct comparison would be
Abort on soft endstop hit = Abort on too high temperature SET Abort on (hardware) endstop hit = Abort on thermal runaway (thermal sensor "hit")

Therefore if you want to detect thermal runaway... get a temp probe. If you want to detect out of hardware bounds... get an endstop.

I think this can be closed as solved by the SD_ABORT_ON_ENDSTOP_HIT unless we want to implement gcode "sanitizer" that runs before print job.