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

Options with hardware enable input

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:

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 automatically an the global home state is a sum of all controller 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

Edit

Pub: 05 Sep 2022 07:56 UTC

Edit: 05 Sep 2022 08:20 UTC

Views: 88