Dropping bed to Zmax at end of print

[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).

[A Former User]

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

[A Former User]

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.