Benefits of 1HCL or 23CL over an external motor+driver ?

Pit34

Hello,

About closed-loop motion system, what are the benefits to go with 1HCL cards or 23CL motors, over using external closed loop motors+drivers connected to step/dir signals ? Is there some firmware features only implemented through those Duet solutions ? May be multiple feedback loop, current/torque/speed loops ?
Is it just working at driver level (error correction) without any acts of the firmware ?

Can someone explain to me how closed loop is actually implemented on Duet boards and RRF ?

Currently preparing an upgrade phase on my printer (BLV MGN Cube), I search information about the different solutions to maybe go in closed loop. I am familiar with the concept and already have used it on other project with position control.
I already read 1HCL doc and 23CL doc.

Thanks

dc42

@Pit34 the potential advantages of using the 1HCL or M23CL over external closed loop drivers with step/dir inputs are:

RRF sends these devices complete move profiles, a little in advance of when the corresponding move is due to start. This means that the driver software knows what is coming and can use feedforward to track the desired position more closely.
They provide continuous feedback of how closely they are achieving the desired position. This data can be collected and used to monitor performance and schedule preventive maintenance.

Pit34

@dc42 Thanks for those details.

So the loop is closed at the 1HCL or M23CL board software level. Can you tell me if it is a velocity loop or a position loop ?
A velocity loop here could be the software detecting in real time that the required speed of the running Gcode command is not reached. And so react by requiring more power to the driver, to motor reach the required speed, and catch up the theoretical position a T moment.

A position loop could be the software checking at the end of a Gcode command if the required position is reached or not. And so react by delaying the motion execution to wait the system reach the good position, before starting the next Gcode command.
It could be done in real time too, by checking current position in real time, and react by requiring more power to the driver too, to reduce the position error.

Anyway, if the loop is closed in real time during Gcode command execution, this should reduce and adapt the motor current to what is really needed, and so maybe reducing MRR and VFA.

One more thing. Is a linear encoder support could be added in future ? To check the axis carriage linear position instead of axis motor angular position ? The final idea would be to make a dual-loop system and so eliminate all possible belt / leadscrew / mechanical backlash on each axis.

I ask those questions just by curiosity, it's an interesting domain.
Thanks

droftarts

@Pit34 As far as I'm aware, it does both a position loop and a velocity loop. It will react to extra load on the axis to meet the required speed and acceleration by increasing torque. If stalled then released, it will attempt to catch up with the current position, and get back in sync with other axes. It checks position during and at the end of the loop, and will raise a driver error if there is a greater deviation than expected. Driver error response is scriptable; see https://docs.duet3d.com/en/User_manual/RepRapFirmware/Events

Position error (and torque will be added soon) is recorded to the Object Model. The OM can be queried and data captured and recorded (we have shown a demo using RESTful API to capture data, recording to an InfluxDB time-series database), then queried (we used Grafana to graph the data), and can show if the position error (or torque) increases over time, which would highlight a need to undertake maintenance on the axis.

Linear composite encoder are supported on the 1HCL. See https://docs.duet3d.com/Duet3D_hardware/Duet_3_family/Duet_3_Expansion_1HCL#compatible-encoders

A linear composite encoder comprises a linear quadrature encoder that tracks position on a linear axis (for example the Renishaw LM10IA or LM10IB) and a Duet3D magnetic shaft encoder. The shaft encoder handles motor commutation, the linear encoder is used to close the loop.

Ian

Pit34

@droftarts Thanks for those reply.

Do you know if the tests of those new features have shown motor consumption reduction or MRR and VFA improvement? Maybe motor noise reduction?

Anyway it's an impressive technology improvement. Great job !

dc42

@Pit34 it's a position loop, with velocity and acceleration feedforward.

@Pit34 said in Benefits of 1HCL or 23CL over an external motor+driver ?:

Do you know if the tests of those new features have shown motor consumption reduction or MRR and VFA improvement? Maybe motor noise reduction?

That depends on what you would otherwise set the motor current to and how tightly you set the PID parameters. If you use the same current in both modes, there is no constant load on the motor and you use relaxed PID settings then closed loop mode should be quieter, at least at low speeds. But if you tune the PID loop very tightly to maintain position more accurately than open loop mode would then closed loop mode may be noisier.

Pit34

@dc42 Ok, thanks. I think I would give it a try on my next upgrade.

I was thinking about the closed loop this afternoon. Does Duet team have investigated the feasibility of closing the acceleration loop ? With linear composite encoder, or maybe ultra-fast sample rate accelerometer ?
The idea would be a sort of closed loop feature merged with an input shaping feature. A sort of real time input shaping.
Theoretically, a motion system with sufficient sample rate and response speed could compensate and remove mechanical resonance (motors, belt, frame, leadscrew, etc.) in real time. Inputs data filtering and tuning could be a nightmare, but I wonder if there is not a track to explore on this side.