Feature Request: Optionally allow actuators to operate while machine is off or add the concept of servo power on/off

[alexanderwiller]

Feature Request

Describe the Feature

I see two possible variants of this feature:

Actuators have an option to allow their operation even while the machine is off

This option would introduce a checkbox in the configuration wizard for actuators. When the checkbox is active, the actuator can be used even while the machine is not enabled.

The machine has a general enabled state and a separate servo power enabled state

This option introduces a two-level approach to enabling a machine. The first level would be "Machine on" and allows all actuators to be operated, but no machine movement can be executed and all axis motors are not powered / not operable. The second level would be "Servo on" and allows machine movement.

How Will It Look?

Variant one

As described above, just a checkbox is added to the configuration of each actuator that decides if the actuator can be used while the machine is turned off.

Code-wise, it would probably make use of the onlyIfEnabled flag, that currently defaults to true for all actuations:

openpnp/src/main/java/org/openpnp/spi/base/AbstractMachine.java

Line 637 in 2a36a8d

public <T> T execute(final Callable<T> callable, final boolean onlyIfEnabled, final long timeout)

Variant two

This variant will be more complicated to implement. In the UI, an additional button, e.g. showing a motor, would be added besides the machine on/off button. This button would be used to turn the servo power on/off.

UX-wise, it would be an option to set the automatic enablement of the servo power when the machine is turned on as the default behavior. This would allow an unchanged workflow even if a new button is added to the UI.

As there could be actuators that trigger dangerous actions as well (pretty uncommon, but e.g. pinching hazard for a nozzle magazine cover) or whose operation doesn't make any sense without servo power, there could be a dropdown to select if the actuator is available with the machine being enabled or only with the servo power enabled (I think we can drop the "actuator available with machine disabled" option here).

I think for Axes there doesn't need to be any dropdown to allow them to be operated with the servo power off, as they all are controlled by the movement planner. Moving a single axis while keeping all others actually powered down doesn't seem to make much sense, not even for jogging.

Any "auxillary" axes, e.g. for a nozzle magazine with some kind of wheel, would also be represented by actuators, so this case would be covered.

Code-wise, I don't have a very specific plan yet, but it could be an option to start with (conceptually) replacing the onlyIfEnabled flag with a requiredMachineState enum.

Also, I don't know yet at which level (e.g. machine, actuator, driver) this feature would ideally be implemented to reduce the required code changes to a minimum. Probably, two new commands would be introduced to the gcode driver: SERVO_ENABLE_COMMAND and SERVO_DISABLE_COMMAND.

Why Do We Need It?

What problem does it solve?

There are many situations where actuators should be available for use, but no machine movement is required.
Some of these situations are:

• General setup and debugging, e.g. testing lights, feeders, vacuum valves, etc.
• Loading of feeders, especially "smart" ones like the SlotSchultzFeeder. This loading requires communication with the feeder via acuators.
• Manually trigger e.g. nozzle release when something went wrong during nozzle change

The issue with allowing machine movement in those situations is that it could, depending on the machine, be more or less dangerous. In my case, the robot I use is easily able to cause serious injury. There is no need for the robot to be enabled for those operations, so it should be possible to differentiate between these operational modes.

Even if in my case the robot has a safety interlock switch, just leaving this switch disabled for feeder setup is not enough, as enabling the machine then causes the robot controller to go into error state, desynchronizing communication.

Is it useful for everyone, or does it only solve a problem for your machine?

I think that this feature would be useful for other machines as well, increasing overall operational safety. It's not a silver bullet safety-wise, as regular software (non-functional safety software) shouldn't be relied on alone for this purpose.

Still, it allows more streamlined use of external safety interlock switches that are handled by the motor controller, without sending the controller a "enable motors" command while the switch is not actuated, causing potential downstream issues.

Also, even without safety interlock switches, it provides a new mode of operation that allows for safer debugging and set-up.

Provide Examples

I don't know of any PnP specific examples, but the concept of a machine differentiating between being "normally" enabled and having the drives powered is pretty common.

For example, pneumatic valves inside a industrial machine usually can still be actuated even while any motors are safely turned off by the controller/VFDs and associated interlock switches. Sending movements or just any enable command would cause errors with those controllers/VFDs as well.

---

I would try to implement this feature myself, but want to discuss all potential implications that implementing this would have and if its desirable from a general point of view.

Alex

[markmaker]

Hi @alexanderwiller,

I'm glad you discuss this first. The machine enabling/disabling is also coupled with connecting/disconnecting to the controllers. So with a disabled machine, you cannot currently actuate actuators, and if you wanted to do so, you would need some kind of ad-hoc-connection, which would be a mess in a multi-controller setup.

For the kind of safety you want, please have a look at the Interlock Actuators:

https://github.com/openpnp/openpnp/wiki/Axis-Interlock-Actuator

I believe using those, you can implement what you want to achieve, and more (like reduced speed operation etc.). Even if your machine does not have a safety door, you could instead add a simple safety switch. Granted, this is all software safety, i.e. as in "soft". But so would your solution be.

Furthermore, frankly, I'm very skeptical on a conceptual level. Connecting (and Homing) are clear machine state transitions that would be missing and leave the machine in an undefined state.

However, having said all that, the Homing state could be better handled in OpenPnP. Currently one can move around the unhomed machine at full speed (even though the soft limits are clearly invalid). One can also do some other actions on an unhomed machine that might be dangerous. If you wanted to help improve that, you're very welcome 😁! The unhomed machine could perhaps be limited to a certain speed, and more of the other actions would have to be prohibited. It would result in another safety level between enabled and homed, where your actuator actions might be admissible, but not much else.

_Mark

[alexanderwiller]

Hello @markmaker,

regarding the first option I outlined, I see that there may be some significant issues with the need for ad-hoc connections.

Seeing https://github.com/openpnp/openpnp/blob/develop/src/main/java/org/openpnp/machine/reference/driver/wizards/GcodeDriverSettings.java#L193-L194 made me think that this would be an option, but I'm not so sure anymore. Already in my case, some problems become apparent, e.g. that I need the CONNECT_COMMAND to be executed before I can control any acutators.

For the second option, I don't think that the Interlock Actuators can provide the same level/type of functionally that I'm proposing. My proposal is not really about providing safety via software, its about closely modeling the operational states of an advanced machine (characterized especially, but not only, by servo drives with enough power to cause serious harm). Sorry if my kinda chaotic initial message was not clear in expressing this intent.

Please see this diagram of the idea I have in mind:

Implementing it like this seems to be mostly a matter of introducing an intermediate state, Servo enabled, between Machine enabled and Homed states. I think it shouldn't be neccessary to make any changes to driver initialization, connection, etc.

Any moveTo based actions would only be possible in the Servo enabled stated, causing an exception in the Machine enabled (and Disabled) state.

Characteristics and usage of the three operational modes:

Disabled:

The machine is completely turned off, where 'completely' is defined by what the machine is capable of. E.g., my feeders consume a total of ~100 watts, so leaving them powered off as long as they are not required would be desirable.

Machine enabled:

All non axis-related features are useable. This means that feeders are powered and actuators to ID, load, unload and test the feeders can be used. Lights, valves, pumps and nozzle changers can be actuated.

Any fully hardware-based interlock switch that is connected to a controller can be left open in this machine state without the controller going into an error state. As servos are off in this state, another few tens to maybe 100 watts are saved as long as they aren't needed. Also, no servo noise, which can be quite annoying, is emitted.

This is meant as a safe test and setup (as in recurring machine setup, feeders especially) mode.

Servo enabled:

Motors are enabled. Before enabling this state, all hardware safety interlocks must be closed, otherwise the controller may throw an error (if it supports hardware interlock).

All moveTo commands are usable (how exactly as before depending on the Homed state).

---

So, in summary, I consider it a serious, safety-relevant shortcoming that recurring set-up tasks have to be done with the machine being in the single Enabled state that exists.

By itself, my proposal isn't meant to add any true (as in hardware) safety, even if it does add a software-only differentiation between a not-so-dangerous and a more dangerous state. Instead, it is meant to clear the path for machines that implement true hardware safety, enabling their control with OpenPnP in a way that mirrors their capabilities.

Alex

[markmaker]

Sorry gotta go now, will read this later/tomorrow.

[markmaker]

Hi @alexanderwiller,

OK now I understand much better. Some thoughts:

• I believe we should not make OpenPnP more complex for the vast majority of users that do not have "Terminator class" machines 😆. Most have light aluminium extrusion/stepper motor machines that may still hurt but don't usually maim or kill, so I'm looking for something that can be added as an option (read on before forming counter-arguments in your mind)
• While I can follow the argument from a still-building-the-machine perspective, I don't see a need for the new Servo enabled intermediate state as a permanent feature. You can fold that into the Homed state. This can include a "failed homing state" where some of the latter stages of homing may fail (precision visual homing, nozzle tip calibration etc.) while you are still setting up the machine. With a machine that is so powerful to be dangerous, I don't see how you would want to jog around with a completely unhomed and therefore not soft-limited machine. The electro-mechanical homing done by the controller should always be a precondition for motion.
• I still think that most machines implement interlocking with machine doors and the likes (I have never actually worked with pro PnP machines, but any other (newer) CNC machine that I encountered has the door logic. So these safety states must also be available during the Homed state. I believe that machines can power servos (holding position) and still electrically prevent any motion on them through the door switch. Think about it practically: if you have a problem with a feeder in the middle of a job, you don't want to unpower and unhome the machine each time, before you dare go near it, which would also mean discarding all parts currently on the nozzles. You park the machine, open the door, which locks the servos in place, then stick your head into the machine, you quickly fix the problem, close the door, which unlocks the servos, resume the job with the machine still homed, nozzles still calibrated and perhaps still carrying their parts.

Does your machine not have such doors?

_Mark

[alexanderwiller]

Hey @markmaker,

thanks for those those thoughts, I've tried to address them in the first three points, then went on about some other aspects. Sorry for that wall of text 😄

Complexity exposed to users

I agree with the point of avoiding any unnecessary complexity and don't think that having this intermediate state has to make things more complicated for users that don't want to use it. It could be configurable if this state is exposed to the user and if it isn't the machine would go straight from Disabled to Servo on without the extra step showing in the UI. If it's a good idea to not at least point out the option of a separate state to users e.g. in the Basic setup milestone, I'm not sure.

It would expose them to this concern at least and the issue description could mention the caveat of having to re-home after disabling a machine that uses stepper motors. It is then up to them to decide, with "extra state hidden" being the default option, as most people use stepper-based open loop machines.

Homing with different drive (meaning motor + controller) technologies

Regarding this paragraph, I'll start from the end: Servo on is merely about enabling the servos capability to produce torque, which is a precondition for homing. If jogging works in this state or not is usually up to the controller to decide.

I'd say that advanced homing diagnostics/states belong very much into the territory of stepper-based open loop machines, but are not very relevant to all other types of drives. These usually have encoders and can home to sth like 1/4000 of a revolution just by turning at most one revolution. For multi-turn homing, they still use a limit switch or move against a mechanical endstop, detecting motor current increase. There is simply no need for anything else than a HOME_COMMAND with those drives.

In my case, I don't even need to do any homing at all, as the machine has battery-backed absolute encoders that hold their position indefinitely, even when moving the machine manually without power applied. But that is kinda on the luxurious end already 😄 The encoders mentioned in the previous paragraph are very common though and available even with 24 V 50 W-class motor/drive kits you get from Aliexpress.

Handling of safe stop in professional machines (PnP and basically all other factory automation equipment)

As you said, professional machines have these safety states available while being homed, because of having encoders. As long as the machine is plugged in / mains switch is on, they keep their position after homing once, even if the motors themselves are powered down.

The way these states are implemented in almost all cases is that the drive has a two-channel digital input for STO (Safe Torque Off). Internally, the three-phase transistor bridge gets inhibited from getting gate signals on two redundant channels. This level of safety is commonplace and any somewhat professional drive made in the last two decades has something like it.

I point this out cause what you describe power servos (holding position) in contrast is very uncommon and expensive, as it requires the drive to apply PWM gate signals for maintaining standstill torque, without allowing a major rotational component in the magnetic field. This has to be monitored on two channels again and therefor is a pricey extra feature.

For further reference, this might be helpful: https://www.motioncontroltips.com/faq-what-are-typical-drive-based-safety-functions/

The consequence of this is that any machine that uses encoders and allows position read-back doesn't ever leave the homed state as long as the system power is present. The motors can be turned off anytime without consequence.

Practical use of such a feature

The mentioned drive systems are well within the price range of hobbyists, here are some examples:

Options with true STO

• https://teknic.com/model-info/CPM-SCSK-2310D-RLNB/?model_voltage=75VDC
• https://store.granitedevices.com/ionidrives/25-ioni-servo-stepper-drive-8542310001.html

Options with hardware enable input

• https://www.omc-stepperonline.com/de/modbus-rs485-closed-loop-schrittmotortreiber-0-5-7-0-a-24-48vdc-cl57rs + https://www.omc-stepperonline.com/de/nema-17-schrittmotor-mit-geschlossener-regelkreis-45ncm-64oz-in-mit-magnetischem-geber-1000ppr-4000cpr-17hs15-1504-me1k
• https://odriverobotics.com/shop/odrive-s1
• https://en.nanotec.com/products/1622-pd4-cb59m024035-e-08

So I wouldn't see this as a ivory tower Terminator class machine feature (please excuse me 😆), but one of general usefulness. Having a closed-loop drive system is both crucial and state of the art for building any high-speed motion control system.

I only included drives that allow to read back the position, which is need for being able to turn motors off without loosing position, because it doesn't help to maintain position in the drive but not having a way to read it back.

Extra benefits of using encoders (why are encoders required at some point for advanced machines)

• Angular accuracy: It gets difficult to place e.g. a Xilinx Artix 7 FPGA in CSG324 0.8 mm pitch package with open-loop steppers as they lack the required angular precision, even using microstepping.
• Precision homing for angular axes without encoders is quite hard to do.
• Better dynamic control, higher movement speeds.

Existing examples of machines using closed-loop drives

I found a few projects that already use closed-loop drives, some of them with enough power to be truly dangerous:

• https://www.eevblog.com/forum/manufacture/pick-and-place-build-openpnp/msg3017540/#msg3017540 / https://www.youtube.com/watch?v=5jwegV7XlWE
• https://www.eevblog.com/forum/projects/pick-and-place-software/msg768340/#msg768340
• https://groups.google.com/g/openpnp/c/O1j_0x9tP6U/m/w5WBrxb2CQAJ

These projects would already benefit from this feature.

Side note: Handling of machines that don't need homing or keep there homing state even when disabled, but having mains power

A IS_HOMED_COMMAND that - if gcode is present in the driver config - is sent when the machine is enabled / enters servo power on state, paired with the existing HOME_COMPLETE_REGEX would even right now (without any extra state) be useful to all users having machines that keep their home position. It would also be opt-in automatically.

This feature would avoid the need to track external homing state in OpenPnP, but still make the house go black and update current coordinates automatically (Assuming OpenPnP tracks homing state for each controller/axis automatically an the global home state is a sum of all controller/axis home states).

Further perspective

Making use of the advanced Motion Control Types that are now available, new possibilities open up on how machine can be built.

Cyclic synchronous position data transmission is a mode well suited to all "smart" drives listed above and enables OpenPnP to do all multi-axis coordination and motion planning, while the drives just execute this.

In future, I will probably abandon the robot I'm currently using and replace it with a multi-head gantry style mechanism, that uses one of those smart drives. No matter what drive is used, there won't be any typical driver board (like Smoothieboard), but I would write a Modbus RTU, ClearPath protocol or CANopen CiA 402 profile (a generic drive profile defining registers a CANopen drive has to provide) driver that supports cyclic synchronous position transfers and reads back the current machine position.

A word on safety

Again, starting from the specific example going to a general perspective: I don't think that the issue with re-homing being required after turning off a stepper-based machine is an argument to not support an additional "set-up mode", cause setup is an expected operational mode and lots of time is spent in this mode. If you can't fully use it with a machine in all workflow phases, thats unfortunate, but doesn't devalue the safe set-up mode in itself.

The general approach to safety should be "ensure that the machine cannot move while you are working in the danger zone", which requires the ability to turn motion off while still being able to use feeder actuators etc. This isn't changed by the fact that a majority of machines doesn't support this mid-job, it's still useful in job preparation.

Last, regarding injury potential: I would say that even a stepper machine can rip out your hair and maybe even damage the skin if you get it in the pulley (1.9 Nm motor, 1 cm radius is ~20 kgf, even more if the machine is already moving and having some kinetic energy). Also, breaking a small finger wouldn't be out of the question. Granted, this requires unlucky circumstances, but it's a real risk. Not to speak of larger machines.

---

And to answer the question Does your machine not have such doors?:
It doesn't really have doors for build effort reasons (and as the machine will likely be partially rebuilt in a few years), but a retractable barrier with a safety switch directly connected to the robot controller with a redundant circuit.

But that alone doesn't help, as its common that triggering STO while the motors are active sends the drive into an error state. Thats another reason why one should be able to turn off servos first in OpenPnP, before opening the barrier.

Or, in other words, the barrier isn't meant to be used as an on/off switch for motors. That holds true for allmost all safety features on industrial machines, they aren't meant to switch operational modes, that feature is provided by the control system (i.e. OpenPnP).

Alex

[markmaker]

Hi @alexanderwiller,

I may misunderstand something, but it appears to me that you kind of argue my case. If the machine remains homed all the time thanks to absolute encoders, and even for cyclic encoders, there is "simply no need for anything else than a HOME_COMMAND with those drives", then there is no need to make these two states (Powered/Homed) separate or nested. You also haven't disputed the practical considerations of mid-job intervention, or addressed the unhomed soft-limits problem for machines that do not have absolute encoders (the vast majority). You argue that such an Unpowered state would be useful for setup purposes, which I never denied, but you don't elaborate why such a mode could not equally be obtained and be useful from the Homed state, given absolute encoders.

You also confirm having this "retractable barrier, with a safety switch". So unless I missed something, everything falls into place. You could power down the servos from both the Enabled and the Homed states, simply driven by an interlocking Actuator.

An actuator can kind of embody a machine condition. I say "condition" and not "state", because states are mutually exclusive, while you can combine multiple conditions and combine these conditions with any one state (if permissible). The beauty of "orthogonality" in computer science.

In fact, for years I've been thinking about such machine conditions even for the simplest DIY machines. These could be embodied by different Actuators and be actuated explicitly/manually and/or automatically. After an idle time, one actuator would be actuated and the associated G-code could make the machine enter a condition where the steppers are less powered, i.e. still enough to not lose position, but not getting so hot. For your Übermaschine you could power down the servos completely. If there is no part on the nozzle, yet another actuator could power down the pump and other stuff (note how these conditions are not triggered by the same conditions and can overlap either way). The Motion Planner would automatically "wake them up" when needed (but subject to interlocking!).

I admit not to know so much about professional industrial machines and servos etc. But I think it is fair to say that absolute encoder servo systems are still very rare in the "affordable" domain. I mean the "Minas" servo featured in the Chende video is 700$ plus the driver another $650, each per axis, and you haven't even started talking about ball-screws and encoders. Typical OpenPnP users' budgets are at least one order of magnitude lower.

Having said that, I fully agree that closed loop actuators are always better and that some are starting to be in the "affordable" domain. However, all the affordable ones AFAIK have cyclic (not absolute) encoders that work autonomously, mostly still driven by STEP/DIR, i.e. the controller does not know about the position. The ones I have looked at do not truly "reposition", they merely try to catch up with a few lost steps, and if they fall behind too much, they simply give up and E-STOP. For all intents and purposes discussed here, everything remains the same, they still need to be homed.

Furthermore, I'm not sure if you know all the (deferred) homing calibrations OpenPnP does, like Z calibration, runout calibration, precision tool specific bottom camera position calibration, background calibration. Those require the nozzle to be empty, so mid-job homing would mean discarding any parts on the nozzle. It could be that your Übermaschine does not require any of these calibrations, but the usual OpenPnP machine still does.

_Mark

[alexanderwiller]

Hey @markmaker

I think now I got the central point you were trying to make, that is that servo enabled/disabled and homed/not homed can exist in parallel in any combination. Good that you pointed it out again, thanks.

My perspective was always the workflow perspective, e.g. enable machine -> load feeders -> turn on servos -> home -> work -> turn off servos (optional) -> fix feeders -> turn on servos -> work -> turn off servos -> disable machine.

As long as we find a way to model this workflow in a practical way, I'm happy no matter the implementation.

I would like to outline a few variants, from most optimal to most simple:

Fully automatic STO mode

Machine features: The machine has a door with a safety switch and drives with STO, the drives support positon read-back.
Behavior: You open the door at any time, the drive goes into STO, OpenPnP pauses any running job. After you close the door again, the job must be continued manually (It could continue automatically, but your user intervention probably had a reason that may require further manual adjustments).
Implementation: For this, usually a delayed safety relay is used. When the door is opened, a regular quick stop signal is sent to all drives (digital input), maybe even a simplified park command. After e.g. 200 ms, STO is then applied. This keeps the drives from going into error state.

Manual STO mode

Machine features: The machine has a door with a safety switch and drives with STO, the drives support positon read-back.
Behavior: The job must be paused and the servos have to be disabled before the door is opened, because otherwise an uncoordinated STO signal while the drives are enabled can cause a drive error. The drives can either already be disabled through timeout (e.g. no movement for 30 seconds) or have to be disabled manually. After you close the door again, the job must be continued manually.
Implementation: For this, the safety switch is directly connected to the drives STO input.

Locked door STO mode (for completeness, doesn't really fit in this ordered list)

Machine features: The machine has a door with a lockable safety switch and drives with STO, the drives support positon read-back.
Behavior: The job must be paused and the servos have to be disabled before the door is unlocked. After you close the door again, the job must be continued manually.
Implementation: For this, the safety switch is directly connected to the drives STO input. The lock is actuated by OpenPnP.

No STO mode

Machine features: The machine has no drive-related safety measures, the drives don't support position read-back.
Behavior: The job must be paused and the servos have to be left enabled during any manual intervention, but current can be reduced as a non-failsafe precaution. The job must be continued manually.
Implementation: No special measures required.

I really like the ideas from the machine conditions even for the simplest DIY machines paragraph, but I'm still missing some pieces to see how I can model my scenario only with Axis Interlock actuators.

To not make things too complicated, I want to just focus on the Manual STO mode for now:

Required features:

• Disable and enable the servos on manual request as part of a comfortable workflow
• No movement commands are sent with disabled servos

Comfort features

• Don't allow enabling of the servos as long as the doors are open, because it would cause an immediate drive error
• Automatically enable the servos when the doors are closed and a move is requested
• Disable the servos after 30 seconds or sth without movement
• Pause the job when disabling the servos (or maybe the other way round)

Given that I add a ServoPower actuator, I have no comfortable way of controlling it as part of the regular workflow, without first bringing up the actuator panel and then opening the appropriate dialog. I think that here something like a ActuatorMacro could be helpful to add buttons for this. The No movement commands are sent with disabled servos requirement should be easily realizable with the Axis Interlock Actuator.

For the other "Comfort" features, I need to think those through later, as the complexity regarding interlock actuator dependencies and naming are not trivial to me.

Writing this use case / feature analysis, it became apparent to me that even if some features regarding actuators may be lacking, e.g. a "Actuator Interlock Actuator" and a delay option, the largest issue is probably communicating the abilities of OpenPnP and recommended ways to set things up. I'd suggest that all this, besides technical additions, should result in a guide how to set up servo power control for machines with different capabilities.

To the third and second to last paragraphs:

If you use absolute or incremental encoders doesn't make a difference for this discussion, only the ability for position read-back does, as initial homing after enabling the machine is always possible (if required). I'm pointing this out because that makes all of the previously linked incremental encoder drives available for mid-job STO/Disable without having to rehome and they have a reasonable price tag:

• 299 $ for Teknic ClearPath integrated drive / motor
• 179 $ for Granite Devices IONI including 30 $ motor with encoder
• 128 $ for Leadshine / OMC including 30 $ motor with encoder
• 159 $ for ODrive S1 including 30 $ motor with encoder
• 340 $ for Nanotec integrated drive / motor-
• 396 $ for a used or even brand new Minas drive kit (https://www.ebay.de/itm/303838515293 + https://www.ebay.de/itm/224656236927, or variants, I thoroughly checked the market a few years ago for a CNC build)

These prices are all-inclusive, given the right Driver you just connect them via RS485/CANOpen/USB/whatever to the computer running OpenPnP and can use all those advanced features. Also, you can still use belt drive and have lots of advantages with these drives, so they are a drop-in replacement.

I really want to pursue this path with smart drives and appropriate Driver support in the future, it already is a very popular option in the DIY CNC field.

Regarding advanced homing, I know only some of those features and without a need for mid-job homing even with affordable drives, I don't see issues here. My machine will still make use of these calibrations.

Alex

[markmaker]

I'm glad we are converging here. Yes, it could well be that features are missing, like prohibiting the manual control of certain safety critical actuators. Delays can probably be obtained by dwelling on the controller side (G4).

Also like the proposal of adding custom buttons/macros. Another option would probably be to make the Power, Home and Park buttons have drop-down behavior when pressed long (or whatever that is called), where custom power/homing actions like "Power save mode", "Lock motors", "Park and power down motors", "Unhome" could be triggered. Those could be defined on the condition Actuators.

_Mark