Marlin: max Z height reached and printing goes on

[boelle]

Issue by maukcc
_Friday Dec 11, 2015 at 09:53 GMT_
_Originally opened as https://github.com/MarlinFirmware/MarlinDev/issues/303_

---

Say your max Z height in firmware is set to 200mm.
When you print something that is 201mm(or 200000mm) the Z-axis will not go any further.
The printing does not stop at that time but will keep on depositing material on/in the last layer.
Can we stop the printjob when the max Z-height is reached?

[boelle]

Comment by KiteLab
_Friday Dec 11, 2015 at 10:35 GMT_

---

The question is, how to handle software endstops. Currently we only clip the move but do not send a message or break the print. (clamp_to_software_endstops() in Marlin_main.cpp)

Shouldn't the slicers prevent from producing points outside the allowed volume?

[boelle]

Comment by maukcc
_Friday Dec 11, 2015 at 10:58 GMT_

---

Both slicer AND machine should do this.
I am seeing something like the filament runout sensor.
if "z-height is more then Z_MAX_POS" then "stop/pause print".
or even if z-height is Z_MAX_POS - 1 then ....
and then display a message: max z-height reached

[boelle]

Comment by a4jp-com
_Saturday Dec 12, 2015 at 11:42 GMT_

---

+1 for @maukcc 's idea

[boelle]

Comment by Wackerbarth
_Saturday Dec 12, 2015 at 12:06 GMT_

---

I agree. If we treat the "out of bounds" as an implied "out of filament" type of condition, that should be able to stop the process.

[jbrazio]

@AnHardt clipping is not happening with Z-pos ?

[AnHardt]

@jbrazio
Please reread the original post. @maukcc says the move in z direction is clipped but the extruder still spills material and the print does not stop. That is exactly the same in z direction as i illustrated in 'Software-Endstop clipping #3825' for x. For the y direction there is the same problem.

[jbrazio]

@AnHardt Sorry I was culling the flood of issues from the last two days and some stuff may have slipped me. Then the idea to stop extruding and "ignore" the movements would also fix this one. from your experience, is this a "implementable" ?

[AnHardt]

When we have decided for the right 'action' (kill, stop, pause, error) the coding is a matter for 5 minutes.

[jbrazio]

@AnHardt Haven't we settled upon "fake extruding" and ignoring the moving out of the plane ?

You said:

For a good cliping algotythem i'd expect to not extrude the left part and omitting the moves, while the right part shold be exactly as drawn.

I agreed with you, and then @thinkyhead said the same as you:

To get "proper" clipping, the planner should instead chop lines off at the edge of the movement range, throw away any lines that lie entirely outside the movement range. The E axis will need to continue advancing logically (but not actually move the E motor) when the nozzle position is "out of range".

There is no much room for discussion IMO..

[AnHardt]

@jbrazio
A proper clipping is more a thing for weeks or month. Cohen-Sutherland clipping is simple but we also need a strategy to move from an exit point to an entry point. For round beds things are different but not easier. For z-max on deltas i still have no really good idea.

[jbrazio]

OK.. my question is in that direction Andreas.
So the 5m fix is to "kill" the robot ?

[thinkyhead]

Edge clipping could work in the same way that MBL chops up lines that cross the probe grid. For round beds this would require sqrt, so it would slow down all lines.

[jbrazio]

@AnHardt do we mark this as a bug and you provide a quick (5 minute) workaround for it ?

[sarf2k4]

Hi, I wanted to point out about the z-max feature as well, where this one to avoid my head from crashing to the z axis top bracket.

I used the increase z before homing and tested with z-max triggered; of course, the z max port are enabled in the config.h. During the z increase of the homing procedure, marlin does stop whenever the z-max are triggered but it doesn't stop if

1. z-max were set at 175mm in config.h
2. goes to 175mm physically
3. z-max triggered (which should be triggered somewhere between 174-175mm)

I'm sorry if this is a hard thing to explain/understand. But I want to know whether or not these are part of marlin or a bug?

So currently, I put my z-max at config.h is 170mm which won't trigger the z-max endstop

[thinkyhead]

Setting the Z max lower sounds like an ok solution. Marlin doesn't have an emergency stop for SD printing when it reaches the max height. Maybe it should.

[sarf2k4]

I thought there's an option in config_adv.h about emergency stop or something upon hitting the endstops?

[thinkyhead]

an option in config_adv.h about emergency stop

@sarf2k4 That is still there, and can be enabled to stop printing with a hardware endstop. But there is no option to stop when hitting the Z max software endstop, and I'm not sure what the complete behavior is when the Z software endstop is exceeded. I think probably Z stops going up, but it keeps trying to print and extrude at the same height. It should probably just stop at that point instead.

[sarf2k4]

@thinkyhead , what about my previous post? My reason to put the z-max way above the 170mm is to avoid the z axis crashing on the top z bracket, which is sufficient enough, but if I put the endstop at 165mm or so, moving the z axis manually (after homed) to 170mm would ignore the z-max endstop if it's triggered or not

[thinkyhead]

I'm not sure what is actionable here. What solution are you looking for?

[sarf2k4]

Sorry if I offended you there, I just wanted to know is it supposed to be like that ignoring the hardware endstop or should it stop at the hardware endstop when the software endstop still not reached.

Should there be 'probably' another option to add in prioritize hardware endstop instead of software?

[thinkyhead]

If you have ENDSTOPS_ONLY_FOR_HOMING disabled and you have ABORT_ON_ENDSTOP_HIT_FEATURE_ENABLED enabled, then SD printing will stop when an endstop is hit. Host printing won't stop in the case of an endstop hit, regardless of settings.

[jbrazio]

Thank you for your interest making Marlin better and reporting this issue but this topic has been open for a long period of time without any further development. Marlin has been under heavy development for the past couple of months and moving to it's last mile to finish the RC cycle and release Marlin v1.1.0. We suggest you to try out the latest RCBugfix branch and reopening this issue if required.