Keep Motors energised when changing assignment

sotpurk

This is in reference to the query here: https://forum.duet3d.com/topic/31427/moving-an-actuator-as-a-zprobe-instead-of-the-entire-axis?_=1678019622288

When attempting to implement the aforementioned, on changing the assignment for the z-axis the motors de-energize which results in the gantry (80+ Kgs) falling.
Is there any way to keep the drivers enabled when the motor assignment for the Z axis is changed?
If I were using external drivers this could easily have been done using the enable pin, is there a way to control the enable of the driver and not the axis?

o_lampe

@sotpurk I guess you could assign the "real" Z motors to a different axis and use post processing to rewrite the gcode.
That way you wouldn't have to swap them during probing.

A 3-way swap macro might also work, at least in theory:

Send a gcode line to a virtual (dummy) axis with the current Z-height
swap Z-motors to the dummy axis
swap actuator motor to Z-axis

deckingman

@sotpurk Here is a suggestion - untested and might not work. Assuming your second axis is U, try mapping the Z motors to both the U axis and the Z axis. The firmware might not allow you to do that, but worth a shot? You can certainly map multiple motors to a single axis but whether you can assign the same motor to multiple axes might not be allowed (although on a CoreXY both Alpha and Beta motors control both X and Y movement so who knows?). If it is allowed, then a G1 Zn will do the same thing as a G1 Un so no need to change mapping.

Phaedrux

@sotpurk said in Keep Motors energised when changing assignment:

the gantry (80+ Kgs)

Z motors with brakes may be advisable?

sotpurk

@deckingman That's interesting and I'll certainly give it a try just to mess around, but it's not applicable here because assuming it works it'd move all the motors simultaneously or none at all whereas the purpose is to move 4 motors for Z when printing and otherwise and use an actuator on the extruder for leveling.
So mapping 4 motors for Z and mapping actuator for Z and U probably will result in the entire axis moving with the actuator on any Z command.

sotpurk

@o_lampe @deckingman The post-processing solution might just work but will need to figure out how variables work here better.
I've tried out the 3-way swap and ran into an issue, I'll walk through the current flow:

Home the printer with Z motors assigned to Z
Assign all the Z motors to U and do a relative G1 H2 U0.1 move right after to energize the motors.
Assign the actuator to Z and probe the bed.

The problems with the current flow are as follows:

When doing the G1 H2 U0.1 move after the reassignment to energize the motors there's a slight period where the motors are not energized and the gantry falls just a bit before they are. The falling is a problem, to begin with, but energizing the motors while it's falling would result in massive back emf.
Right now I'm without the actuator logic this is what I'm using to level the bed:

G30 P0 X180 Y310 Z-99999 ; probe near a leadscrew fl
G30 P1 X180 Y1160 Z-99999 ; probe near a leadscrew
G30 P2 X1190 Y310 Z-99999 ; probe near a leadscrew 
G30 P3 X1190 Y1160 Z-99999 S4; probe near a leadscrew and calibrate 4 motors

The issue is with the last line, since executing the gantry leveling is automatic at the last line which does not give me a chance to remap the 4 Z motors to Z.
Is there any way to split the execution of the leveling from the last line (S4)

sotpurk

@Phaedrux It would be very expensive for me to swap the motors or attach brakes to the same. As a last resort, I'd much rather move to external drivers since an enable pin would solve all my issues, but to do that I'd have to buy a 6XD or 4 1XD boards which would result in about the same price so yeah still quite expensive. And either way would result in more points of failure.

And since this is something that possibly could be done in software, I'd much rather do that.

deckingman

@sotpurk It sounds to me that having 80Kg of mass that can fall if power is not applied to motors, is a somewhat hazardous thing to do. You say you have 4 lead screws so I assume that they auto rotate when power to the motors is lost. That must be due to using very course lead screws which have a steep helix angle. In which case, I can't help thinking that a better solution to all your problems would be to use finer lead screws with a shallower helix and which will not auto rotate. The knowledge that 80Kgs of mass can come crashing down if power is lost for ANY reason, would certainly scare the crap out of me.

sotpurk

@deckingman I'm not using leadscrews, I've made a custom chain + sprocket assembly that the gantry runs up and down on.
There's a 10:1 worm gearbox between the sprocket and motor. I figured a worm gearbox would not be back-driven but I seem to have selected a lower ratio than required. My current solution to that is to switch the sprockets to smaller-diameter ones or switch the gearboxes to a higher ratio.
I'm leaning toward the latter.

Even still assuming the gantry doesn't fall down, I'd like for it to be rock solid in place when the entire actuator-based leveling happens which takes us back to the previous issues.

P.S.: The mounts are only printed to test and will be CNC'd later on.

deckingman

@sotpurk Sorry but there are too many contradictions for me to keep up. In your OP, you stated that when motors are de-energised, the 80 Kgs of mass falls and you want to prevent that happening. My point is that when power is lost for any reason, that 80Kgs of mass is still going to fall. So to my mind, this is a mechanical problem which requires a mechanical solution. Preventing the motors from de-energising when you re-map them isn't going to help if power is lost for some other reason.

sotpurk

@deckingman I apologize if my description was confusing.
I will fix the gantry falling by replacing the gearboxes so the gantry falling when power is lost isn't an issue.

The problem is only when reassigning the axes while the machine is powered on do the motors lose energy. Now the axis won't fall when that happens even if the motors are not energized, but since it'll be probing the weight is going to be shifting and I would like to have no lost steps.
And since it's an industrial environment I can't rely purely on the worm gears when probing hence it's important that the motors are energized.

TL;DR: What happens when power is lost is not the concern here, but keeping the motors energized while probing is.

o_lampe

@sotpurk Maybe it's as simple as adding a capacitor to the enable pins? Just to cover the short time gap between assigning and energizing...
IMHO the enable pins aren't time critical part of the motion planner, so adding a bit of delay won't harm.

I remember having all drivers on my DIY Duet2 extension board permanently enabled and IIRC the DUEX5 only has one enable pin for all drivers as well.
@T3P3Tony am I right?

T3P3Tony

@o_lampe @sotpurk AFAIK to kepe the motors enabled when switching between assignments would need a firmware change so I am moving this to the firmware wishlist.

sotpurk

@o_lampe Oo that's neat and would solve the issue. Thanks.
I just checked the schematics. All the enable inputs seem to be tied to a single pulled-up line from the MCU.

I'll try this out as soon as I get a chance. Thanks again.

dc42

@sotpurk the enable/disable of individual drivers is done using SPI commands to them. The global enable pin is only used to prevent the drivers being enabled before they have been initialised and for emergency stop.

o_lampe

@dc42 @sotpurk
A dropping bed because of pushing the emergency button sounds like a nightmare.
Is there a way to mask which motors should stay enabled during a reset?
Maybe use M569 for it? Would it be NIST compatible?

T3P3Tony

@o_lampe if the bed has to remain still during a firmware reset (different issue from what the OP was discussing with axis remapping) then the correct solution is to use brakes on the motors, or potentially in some situations geared motors.

sotpurk

@T3P3Tony @o_lampe
Yes, have ordered new gearboxes(worm) with higher ratios to mitigate this issue.
The problem with the motors de-energizing when changing assignments still remains though.
I messed around with the firmware but couldn't produce any results.
It seems to be a firmware limitation as was said before and to move forward I've ordered a 6XD with drivers so that I can control the enable and power separately; hopefully that should be enough to get the levelling logic working reliably.