What’s everyone doing with respect to gantry dropping when powering down?

Was wondering what options we have (other than a block of wood) to deal with the router bit plunging into material upon disconnecting power?

Also, my LR4 consistently drops only on the non-rail side. If it is going to drop, I wish both sides were equal… I can freely turn the lead screw by hand so it doesn’t seem to be hitting anything. This happens with or without the router installed. Also makes no difference if the core was to the max side.

Any ideas?

Fairly normal for a LR to do that. Usually on the side that is carrying more weight. Like where the router and core is parked.

This is because the unpowered motor is easy to turn, and the weight is enough to do so.

I park my LR with supports under the gantry. You can also switch to 2 start lead screws (instead of the more normal 4 start ones.) This means that there is 4mm of travel per revolution instead of 8. This shallower pitch often means that the weight of the gantry isn’t enpugh to make it drop, or at the very least makes it drop much more slowly. It isn’t a guarantee, but it’s usually good.

1 Like

For the LR3, there was a printed part that you could put on the lead screws to hold the gantry up before turning off the power.

I don’t think that this would work with the LR4, and I don’t think that anyone has come up with something similar for that model (yet).

So a couple of blocks of wood seem as good as anything at this time…

This is common if the core is parked on that side, but it should drop on both sides if parked in the middle, or on the rail side if parked on that side.

Try lubing the lead screws and the linear rails. There also may be some added friction due to slight misalignment, or if the linear rail is clogged with sawdust.

I switched to the 4mm lead screws on my LR4 build vs. the 8mm ones on my LR3, and it has been a super nice feature to not have the gantry fall on power off. It is pretty consistent in that I have never had it fall before, and even putting some pressure doesn’t make it go down. Granted, my gantry is only made for 24in of cut(I think my strut plates are actually 31.5 from the calculator), so I’m sure a bit lighter than a full sheet machine.

When you short out one of the sets of coils on a stepper motor, it becomes much more difficult to turn. So, I’m wondering would it be viable to set up a pair of relays which shorts out a set of windings on each Z-axis stepper when you power the machine down? If not, why? This is the sort of thing I’m thinking of. The coil of the relay would be powered whenever the machine has power thus connecting A- on the motor to A- on the driver and and when the machine powers down, gets disconnected from the driver and connects to A+. As drawn here, it’s in the powered down state.

Ryan has such stepper brakes in his store. I don’t know why nobody ever talks about them.

https://www.v1e.com/products/orobs-stepper-brakes

It could be that (maybe) it blows up stepper drivers during the switch. :thinking:

Okay, that looks quite similar to what I proposed. :+1:

It only switches when it powers down so I can’t image why would do any damage during the switchover

Those were designed for the MP3DP. On that you can have klipper unlock the brakes before the Z ever tries to move. I am not sure anyone has tried to make them work on FluidNC. The bed falling 300mm+ on a MP3DP that has a belt driven Z is MUCH more violent than the gantry going down when you unplug it. So much so that it has claimed the life of a few SKR Pro boards (2 of mine) so the brakes are very much needed there.

1 Like

Under normal circumstances, the Z-axes on the lowrider would never drop when the control board has power so, don’t see the need to have the braking relay under software control, just power up the relay when you power up the control board.

1 Like

Very true. BUT how far will it drop from the time it gets power to the time the stepper motors engage? OR is there enough time to remove the short from the motors BEFORE the drivers energize so they don’t error out?

With the recent updates to fluidnc, I haven’t had an “unexpected” drop recently. At the end of the day I park my lr4 core near x0y0, and jog Z down to nearly bottoming out. Then when I cut power it just quietly slumps a couple millimeters. (I do have space where I can drive it off the spoilboard so the bit doesn’t hit anything on the way down.) This also makes homing X and Y pretty quick when I power back up.

Is this actually correct? Clearly, when the motors are engaged there would be no issue, but, after a period of time, the motors automatically disengage (at least using the Marlin firmware with an SKR1.3, for example.)

I am absolutely sure this occurs because if the unit is left sitting (paused) too long waiting for a change in router bit for example, it is possible to unintentionally move X and/or Y while in the process of changing the bit. (I’m not sure what the time limit is, perhaps 15 minutes?, but it’s definitely not too long.) This poses a major problem if one loses the accurate zero position in a multi-bit project.

Along the same line, in case someone who can answer is watching this thread, is there any gcode command that can be issued from a terminal that can extend the time? Or would it require a firmware modification? Ideally, one could add a line to the gcode generated by EstlCAM for example that could help accommodate pauses, bit changes, etc. (assuming that you don’t want to just leave the motors engaged all the time)

Yes, for FluidNC this is correct as long as the idle_ms param in the config.yaml file is set to 255 (which is what Ryan’s configs set it to).

  • idle_ms:
    • Type: Integer
    • Range: 0-255
    • Default: 250
    • Details: A value of 255 will keep the motors enabled at all times (preferred for most projects). Any value between 0-254 will cause the disable pin to activate this many milliseconds after the last step. Note: Motors can be manually disabled at any time with the $MD command.

http://wiki.fluidnc.com/en/config/axes

I don’t even let my printer’s motors disable.

I think the FluidNC distinction is important. After additional digging, It’s clear that with Marlin/SKR1.3 for example, this is not correct–the motors will disable after a timeout period. This can be overridden, but the default appears to be that they become disabled after a timeout.

2 Likes

The brake board works by shorting one or both of the 2 coils to itself. It doesnt blow up stepper drivers, but if you dont have it and you turn the motors really fast you can blow your control board. The 2209 drivers throw an error if the motor coils are shorted when it tries to power on. I powered them many many times with shorted coils when i was developing that brake board for the mp3dp. folks were frying boards when the bed would drop. I put brakes on my lr4 and it doesnt stop the drop. Just slows it down. I think a block is a better option.

Though it might be cool to get a solenoid-actuated cradle that could be deployed on shutdown…

based on what was made to hold the LR3 up when disengaging power, I drew and printed these side-specific blocks that hold my gantry up near Z home. I believe this is better than a block of wood since the gantry sits level and can be easily moved manually.

File can be had here for those that might want to use these

https://makerworld.com/en/models/1066772

3 Likes

if you print this and use it, please let me know how it works for you.