Dropping bed to Zmax at end of print

Simonjb

Can I place an endstop at Zmax and have in my slicer end Gcode something like G0 Z300 (Z300 max build height) and have it stop the bed at the endstop?

I am using a probe for Zmin.

I need to define the Zmax endstop in config.g

M574 X1 Y1 Z2 S1 (Currently is declared as M574 X1 Y1 S1 as using a probe for Zmin). As I am not homing to Zmax I don't need to alter any of the homing files?

I have read too much in the forum and I think I have confused myself in thinking it must be more complex than that....

Maybe I'm missing something but if you have homing working and properly defined the travel limits with M208 you shouldn't need an adittional endstop for Z. It will by means of software stop at the defined max, as long as homing sets the correct min position.

Futhermore, support version 2 of rep rap firmware only support 1 endstop pr axis, so you'd have to reconfigure the endstops on the fly, but that might be doable.

Simonjb

@bearer So an absolute move to the Zmax distance declared in M208 would work in the end gcode?. I must admit I would prefer a physical stop but if that is not possible then a soft endstop will have to do.

My reason for this is simply just access to the bed to remove the print easily.

Unless your other config does something weird along the way, M208 when configured properly will prevent the printer from crashing regardless of what you tell it to do. (ofcourse there are ways to override it).

But if your zstop is free and you have a spare switch you can reconfigure your m574 do the move, and revert the m574 configuration as well; but if everything else is configured the only thing I can see it would possible improve is that it would ensure you reach zmax even if you have lost some z steps during the print or the final move (by telling the last move to move longer than your z travel, until it hits the switch)

Torro

I did exact this using stall detection for Z max.
It's a bit tricky to get the detection working, but it works for me.

The key was to Reduce motor current and increase the Speed.

Ref my post, do you find there to be any difference to just setting the travel with M208 and using a normal move? I missed the fact that the Meastro didn't do stall detection, so moot point for me to try it.

deckingman

@bearer Like you, I think I must be missing something here. Unless there is some reason to travel to Z max before the printer has been homed? Otherwise, axis limits will always be respected by the firmware and this is likely to be more reliable than a physical switch )and much more so that stall detection).

In theory physical switches are better as they would account for lost steps; but...

Simonjb

@deckingman - the whole point of the original question was that a final move in the end gcode of a print to drop the Hypercube bed to its lowest point so that it is easy to access the bed for print removal.
@bearer I would prefer a physical switch too...

I didn't say I would prefer a physical switch, not for a 3d printer at least, the printer shouldn't loose steps as it would ruin prints, and if it doesn't loose steps the soft limits work just fine.
(Different story on my CNC, it can loose steps if I mess up the toolpaths, and it can crash as a result - but more likely in the work than the machine, still, min and max limit switches.)

deckingman

@simonjb said in Dropping bed to Zmax at end of print:

@deckingman - the whole point of the original question was that a final move in the end gcode of a print to drop the Hypercube bed to its lowest point so that it is easy to access the bed for print removal.

Yes I know that. As @bearer pointed out, all you need to is to put G1 Znnn as the last move in your slicer gcode. Where nnn is the maximum travel of your Z axis or it can be any number greater than that and the firmware will respect the limits which you define in your M208 S0. Once homed (which of necessity you have to do before you can print), then the firmware will only allow Z moves up to the maximum position as set in M208 and not beyond.

An even better approach is to use an axis maximum switch but connect it to a spare end stop and have that trigger an emergency stop. Then you have 3 levels of safety. One is the Z position that you set as the last move of your slicer. The second is the axis maximum limit that you have set in your configuration file so if you set the slicer value wrong, it'll still stop at the axis limit,. The third is that is if 1 and 2 fail because you've entered incorrect values in both your slicer and as the axis maximum in your configuration file, then the micro switch will trigger an emergency stop.

Simonjb

@deckingman I think I was coming to that conclusion too about having a switch as a final backup. I'll play with my finger hovering over the emergency stop button until I am sure that the firmware limits work.

Thanks to all for for the suggestions/assistance/reassurance!

jv43

@simonjb as long as you entered your the height of your printer corectly, the firmware imits will work.
The only problem that might arise is, when the printer loses steps during printing, but I'm not sure what could cause something like that on your Z-Axis.
If you want to be extra safe, put G0 Z295 or G0 Z290 in your end-gcode.
If you want to be extra extra safe define your Z-height as 290/295 in the firmware.
You will lose 10/5mm of usable printvolume your printer wont be able to use, but you'd have that extra peace of mind

deckingman

@simonjb For info, I have Z max micro switches on all my axes, not just Z. These are wired in series to a single end stop so if any one triggers, it will initiate an emergency stop. This is a "belt and braces" approach because once the printer has been homed, the axes limits will be respected. Furthermore, the default situation is that axes have to be homed (or at least moved with an "S" parameter) before any moves are allowed. I have that turned off for reasons that I won't go into here. So for the axes max limit switches to trigger, I have to be really stupid and thus far, I haven't been quite that stupid yet (but I never say never).

Edit. The worse case scenarios for you (providing you set the Z max limit correctly) are that the Z motor(s) skips steps or a belt jumps, or a pulley slips on a screw. In any of those cases the firmware will "think" it has moved to Z max but in reality it will be short of Z max. So there is no danger of you crashing something and causing physical damage.

antlestxp

I will add that you will need to make sure you have enough room at the bottom to allow what ever configured dive height just in case you power down at the end of travel. I had my printer set to drop the bed at the end of a print once and after a power cycle the homing pushed the bed down further than it wanted. In the case of a maestro using a bltouch for the Zmin is it still impossible to have a zmax switch?

deckingman

@antlestxp Good point that.

dc42

@simonjb said in Dropping bed to Zmax at end of print:

@deckingman I think I was coming to that conclusion too about having a switch as a final backup. I'll play with my finger hovering over the emergency stop button until I am sure that the firmware limits work.

Thanks to all for for the suggestions/assistance/reassurance!

As you will be moving the bed down with the force of gravity, you could use M913 to reduce the Z motor current temporarily for that move. Note, you should use M400 before any M913 commands to change motor current, except in the power fail script.

antlestxp

@dc42 I should probably use m913 in my homing scripts

deckingman

@antlestxp said in Dropping bed to Zmax at end of print:

@dc42 I should probably use m913 in my homing scripts

IMO it's always wise to reduce motor currents when homing. Generally, homing moves tend to be slowish so reducing current (by a sensible amount) shouldn't cause any problem, but it can help to mitigate damage in the effect of a sensor failure. You can use M913 to reduce the current by a percentage or use M906 to reduce the current to an amount. Both achieve the same thing. The difference is that M906 will wait for any moves in the queue to finish while M913 will not. Both need to be put back to default values at the end of the homing macro.