Analog current -> duet -> stepper motor speed

Visionary

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