Analog current -> duet -> stepper motor speed

Visionary

Is it possible to use 4-20mA signal to control speeds of stepper motors connected to Duet 6HC (and expansion boards)? The direction would be determined by digital input. All connected motors would spin at the same rate or if possible at predetermined ratios to one another.

This thread might be redundant if there is already another, although I couldn't find one.

Maestro

@Visionary How responsive does this speed control need to be? Will it be a sort of continuous/background process or is it for precise motion control?

If the former, I would think you could accomplish this through daemon.g code. Based on input, calculate a move speed to be applied to whichever steppers, and run G1 with sufficient distance for that stepper to run however far/long you want (there is a limit to microsteps per move, but it's some really big number and can be reset).

If you're wanting to set up a precise motion control system with this analogous to running a servo in speed-control mode, I would think you'd have troubles, but maybe someone will know a way. Perhaps you could use G1 H1 to interrupt and update to new speed/directions.

T3P3Tony

@Visionary the first step is hardware to get the 4-20mA readings to something the duet can work with, for example an analog reading. Depending on the resolution required a simple circuit which ran the current through a known resistance and uses that to set an analog voltage between 0 and 3.3V for an analog input could be sufficient. I expect that a slightly more sophisticated circuit would be needed for something like motor control.

on the firmware side, as @Maestro alludes to it depends if you want this to be in any way real time or not. if realtime then it would require firmware changes to incorporate the idea of a analog input, or analog level read from external hardware that read the 4-20mA to translate to motor motion. That will be a non trivial amount of work

It would help to better understand your application because there amy be alternative ways to achieve the same goals.

Visionary

@T3P3Tony
@Maestro

Thanks for the responses.

The application is to run 10 rollers that move sheets of materials. In the application driving the rollers do not need to be in real time. Each motor rotates two rollers via timing belt. The accuracy does not need to be as high as in CNC applications (but it still needs to be quite good), but the system needs to be repeatable, smooth and the sheet materials have to maintain predictable position when oscillating several times. The materials and the rollers are heavy and this could be a problem for the drivers when decelerating (duet drivers or external drivers). The roller drive is just for testing proof of concept and probably more refined solution would be used in the end.

I intend to use Nema 23/24 with up to 4A current. Drivers that can do that are a bit hard to find. Duet can run predetermined G-code precisely and has high current drivers. I think it may be possible that simple signal conversion to step direction and pulse may not be accurate enough or has some other issues. Use of the 4-20mA signal would be however convenient as it is compatible with existing software/automation systems. For those reasons I think Duet could be good for my use case as I can test the setup either with external 4-20mA signal + converter + Duet or Duet in standalone mode.

I also found that there are integrated drivers that can be mounted directly onto the motors and they could one solution. If I can prove the concept, could custom driver boards (possibly with signal converters) be a good cost effective solution?

o_lampe

@Visionary Maybe I can suggest simpleFOC for that?
I'm already using it as an brushless extruder driver & step/dir controller.
It also works with analog voltage or PWM inputs, which both would need a bit of hardware (shunt resistor) to convert 4-20mA . I think a simple rp2040 or esp32 MCU can do the trick. The firmware also has a commander-module to accept control over PC or other serial devices ( not gcode, but comparable)
Thereby you could tell the rollers to run at a certain speed with a single command.

The drivers work with BLDC and stepper motors. It works best in close loop with a bunch of positional sensors to work with. And the FOC algorithm makes it very energy-efficient.

Visionary

@o_lampe

BLDC motors have low torque at low speeds. In my application stepper motors (vs. for example servos and BLDC motors) have high enough torque at about 0-300 RPM to be used without gearboxes. SimpleFOC seems interesting and I will look into it. Plug and play options would be preferable for the converter. The converter may need to be able to adjust its output to determine speeds (something like this: 4mA -> 0 RPM, 16 mA -> 300 RPM).

T3P3Tony

@Visionary you many find a project or product out there that already does 4-20mA -> stepper control. Custom hardware is an option but unless you need more that a 4-20mA input to a single stepper driver output then using RepRapFirmware for the controller would be overkill. How do there inputs/stepper outputs have to intehrate with the larger system, if at all?

Visionary

@T3P3Tony

In the first version RPM of one motor is measured from its shaft and it is used to control all of the motors. The measurement shouldn't be required and it should work just fine without it if motors are chosen correctly and no step losses occur even at max loads. All of the loads in my application are predictable.

I've been trying to google suitable converters. Would any converter do if it outputs pulse at desired frequencies? Does the pulse shape matter?

What I mean by custom drivers is that using something like Duet as final solution to drive the rollers is overkill, but I need 5-8 drivers in a single package (PCB board?) and many of the existing solutions I've found so far seem very expensive or they lack sufficient power. Would it make sense to design custom PCB with 5-8 drivers with 4-5 Amps (perhaps even with signal converter integrated) that has input of 4-20mA for speed and digital input for direction? So no encoder in this type of setup and the production volume would be potentially hundreds yearly.

Current system:
Inputs to stepper drivers/converters:

4-20mA speed signal
digital signal of rotation direction (I don't know yet what voltage)

Output information from motor shaft

Encoder (I don't know anything about the sensor spefically, but it should not matter if there are plans to get rid of it anyways eventually)

dc42

@Visionary we recently implemented torque mode for the Expansion 1HCL boards that we make and also for the Nema 23 closed loop stepper motors that we hope to start shipping soon. In the near future we will implement a velocity limit for torque mode. It occurs to me that this may meet your requirement for continuous motion at a selectable speed. See https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m5694-set-motor-driver-torque-mode for how torque mode works, but note that although the V parameter is reserved, it is not yet implemented.

Reading a 4-20mA sensor is fairly straightforward if the sensor is isolated from ground and can use a 12V supply provided by the Duet, and a little more complicated if it is not isolated. We have designed electronics for both in the past. It can be implemented in the form of a daughter board that plugs into the SPI connector on the Duet.

Visionary

@dc42 said in Analog current -> duet -> stepper motor speed:

It occurs to me that this may meet your requirement for continuous motion at a selectable speed.

The rollers are constantly moving, but they change rotation directions periodically and do high movement speeds occasionally. Having constant torque is not needed as long the movement stays relatively smooth and requested speeds are followed.

########################################################

I think this could be suitable converter that can directly control an external stepper driver speed: MINI MCR-SL-UI-F.

Maestro

@Visionary If all you're looking to control is the rollers and there is no CNC-based router/laser/printhead/etc that needs to coordinate with those rollers, then it does seem like a Duet board is way more capability than you are really looking for. If you're looking at production volumes in the hundreds-per-annum, you'll have to weigh the development cost of a dedicated solution against the cost of those Duets.

As noted by several others, conversion of your current signal to voltage is not really a problem. Translating that voltage to a speed in, for example, daemon.g is also not a problem. You have access to the world of algebra there, so you can create your voltage/RPM curve to trigger 0rpm @ 4mA and 300rpm @16mA. If your motors are appropriately sized, then smooth operations at requested speeds shouldn't be a problem; your acceleration/jerk limits determine your smoothness and the daemon code determines your speed and commands a move. The potential for problems seems to arise when you want to change what the rollers are doing. What were they already doing? Were they rolling a set distance/speed, then need a new distance/speed command when that move is completed? Or, do they need to be responding in real-time to an unpredictably-changing input, where already commanded moves may need smooth interruption? RepRap is not intended to support the real-time response to a changing input case, so there would be an argument for the less-capable but more applicable "dumb" external converter/driver.

EDIT: Maybe I take it back. Based on DC's following response, perhaps this move interruption is not so much an issue.

dc42

@Visionary said in Analog current -> duet -> stepper motor speed:

The rollers are constantly moving, but they change rotation directions periodically and do high movement speeds occasionally. Having constant torque is not needed as long the movement stays relatively smooth and requested speeds are followed.

That would all be possible. Torque can be applied in either direction and the motion will proceed at the required torque or at the required velocity, whichever is reached first. Torque mode can be interrupted to perform normal moves (i.e moves of a fixed length at a specified speed).

@Visionary said in Analog current -> duet -> stepper motor speed:

I think this could be suitable converter that can directly control an external stepper driver speed: MINI MCR-SL-UI-F.

A PWM signal or frequency signal is not ideal because that would need to be decoded. Something like a UART output would be easier to interface to, possibly via RS232 or RS485 Modbus.

Even better would be a design such as the one we did before, that interfaces directly to the Duet SPI bus.

Maestro

@dc42 said in Analog current -> duet -> stepper motor speed:

@Visionary said in Analog current -> duet -> stepper motor speed:

I think this could be suitable converter that can directly control an external stepper driver speed: MINI MCR-SL-UI-F.

A PWM signal or frequency signal is not ideal because that would need to be decoded. Something like a UART output would be easier to interface to, possibly via RS232 or RS485 Modbus.

I think he was thinking that the output from the frequency transducer could be used to directly drive the pulse/step input for an external driver.

@Visionary The transducer has limited frequency outputs; you would need to confirm availability of a range that matches the appropriate pulse input for your use. Additionally, you would lose any ability to control acceleration or jerk (I mean jerk both in the 3D printing terminology and in the more standard sense, s/t^3). Something with brains like the Duet or even an Arduino would give you control over smoothness of the response.

Visionary

@Maestro said in Analog current -> duet -> stepper motor speed:

I think he was thinking that the output from the frequency transducer could be used to directly drive the pulse/step input for an external driver.

That is what I meant. So is this kind of setup possible:

The setup above would be for one time testing the motion. Some other control solution (and components) would probably be much better alternatives. I just need something that works with existing software (which I cannot change) used by rest of the machine.

Frequency limits might be problem, though I think it should be smooth enough for simple test. Jerk and acceleration control would be done by software of the input mA signal.

o_lampe

@Visionary said in Analog current -> duet -> stepper motor speed:

BLDC motors have low torque at low speeds.

I have shown in the linked example that this is an urban legend. I could extrude 2-3 times faster with the BLDC motor versus the same sized NEMA14.
And millions of hoverboard motors do the same: produce heaps of torque from standstill.
It's only the sensorless BLDC motors that wants to be pampered at low speeds, but in general every electric motor that runs in current-limited mode has full torque upto 50% of it's max. speed. That's an axiom

@Visionary said in Analog current -> duet -> stepper motor speed:

I n the first version RPM of one motor is measured from its shaft and it is used to control all of the motors.

That's an interesting usecase for simpleFOC. You can probably use one closed loop master motor and copy the calculated PWM values to the other slave motors.
The people there are always interested in implementing new stuff like the current input mode.

Visionary

@o_lampe

BLDC motors referred by simpleFOC cost more than NEMA 23s or have less power. Can you refer a BLDC motor with sensor that is similarly priced as NEMA 23s and have torque of 2-3 Nm at 300 RPM?

But would slave motors rotate at different if there is no load on them?

I think I'm going to try stuff in following order:

Simple signal converter between external cheap driver and signal source. For testing only.
Arduino or Duet (these for sure have better features). For testing only.
Custom driver boards (this would only be in final version and it's a bit early to think about that).

Getting to the actual testing phase probably takes a lot of time.

Unsolved Analog current -> duet -> stepper motor speed