Duet 3 use for other motion systems?
-
I have a number of projects that will need a stepper or two, mostly controlling positions of components on an optical bench. Rotating a filter wheel, turning fine thread screws or micrometers on stages to precisely control position or angle. Perhaps controlling the grating in a spectrometer. These will often involve reading instruments and adjusting position/angle, or a bit of simple image processing to locate a focal spot. The actual motion control is quite simple. The integration across instrumentation and image processing with the Duet is what I worry about. Am I just buying myself pain and a steep learning curve, or is this a way to make the motion part extremely easy?
I would welcome your thoughts.
-
if you're okay with synchronized motion then it'll likely work, by that I mean you can't control two axes independently of each other at the same time.
Integrating to the duet can be done with anything from sending gcode as http requests to using a Raspberry pi and integrate with DSF on the Pi. You can even go oldschool and send g-code to serial, either use the usb serial port or 3.3v uart on the duet.
grbl based boards is likey a much cheaper option that essentially do the same with respect to gcode and motion, but the duets do have their upsides if the cost isn't a issue
-
@bearer
Yeah, I have been wondering about synchronization and multiple axes. But reading that the Duet can run so many different kinds of printers, I assumed it would permit simple configurations. Other motion control systems (Newport, Newmark , Parker) have explicit commands or techniques to synchronize motion, but single axis moves are always possible, independent of the activities of the other axis.
I wondered about the inverse problem. With the 5160 sophistication, how does the host ARM processor keep the axes coordinated? But that’s off topic.
Can’t I send a command to a single axis? Does the command interpreter force you to wait for one command to finish before starting the next one? Surely the movement of the extruder drive is independent of the head’s movement.
I clearly need to spend some quality time with the documentation.Regards,
Jon -
The origin of the Duet and RRF is for 3D printing, where multiple motors need to operate in coordinated fashion to drive a kinematic + extruder motor to produce the desired combined motion. The need to drive independent unrelated motors doesn't exist there. Whether the duet is suitable or could be made suitable for your needs, I'm not sure.
-
Can’t I send a command to a single axis? Does the command interpreter force you to wait for one command to finish before starting the next one? Surely the movement of the extruder drive is independent of the head’s movement.
you can command a single axis, at the time, and yes commands are queued and executed sequentially. and no, the extruder is coordinated with the head - and the slicer deals with working out the necessary g-code for each segment to sort of provide the illusion of independent motion.
edit: the duet does have the ability to execute multiple command queues from multiple sources, but last i remember there is a single lock for motion. not sure of the current state.
-
My (limited) understanding of the 5160 driver is that you can set a motion ‘profile’, with acceleration, max velocity, and deceleration all given via the SPI bus, and the chip does the necessary sequencing of the motor phases to achieve that position, velocity, acceleration (and jerk?) profile.
So the question then becomes, does processing a ‘command’, a line of g code, complete when the motor has been told what to do, and to ‘go’, or does it wait for an event, or status read back from the 5160 indicating the move is complete? For non-orthogonal printers, the relation between extruder tip position and motor position is quite complex. Yet I have to believe the extruder rate is kept reasonably proportional to the extruder velocity.
Most motor controllers, I think, let you update parameters in the middle of a move giving the Duet the ability to, for example, adjust the extrusion rate on the fly.
Such sophisticated parametric operation is likely(???) hidden from view by the printer setup commands (and subsequent adjustment of the movement and extruder profiles), but if the slicer has to handle such issues, then the implementation would seem to be at the g-code level, and thus commands must just kick off the movement, then process the next command so that the g-code can command the extruder dynamically.
I had hoped to avoid getting down into the weeds, and just define a configuration of a “printer” to be more like a robot arm.
-
@jonathan said in Duet 3 use for other motion systems?:
My (limited) understanding of the 5160 driver is that you can set a motion ‘profile’, with acceleration, max velocity, and deceleration all given via the SPI bus, and the chip does the necessary sequencing of the motor phases to achieve that position, velocity, acceleration (and jerk?) profile.
The TMC5160 can do that except for jerk profile; however, that facility is not usable for doing the coordinated continuous motion required by 3D printers. So the motion is generated by the MCU on the Duet instead.
-
That must be interesting code. Will have to learn how to maintain such precision sync. Can I have two independent motion paths concurrently? 50 kHz time ticks is roughly what is needed, so that’s 20 microseconds. A 100 MHz ARM can execute 2000 instructions in that time, and given it’s RISC nature, it’s likely 10 or 20 instructions to do much of anything useful. Lots of time to run down a list of motors to step or some such. Using step and direction you could avoid the overhead of SPI.
How are the CAN bus expansion drives sync’d up to the main timer interrupt loop. An NTP like protocol can get you to sorta the 1 MHz CAN clock rate, a small fraction of the 20 us time slice. With oscillators good to 10^-6 you can wait a second before they drift apart by a microsecond. Or maybe get better oscillators but that gets expensive. VCO’s and tweak them on the fly? Or relax the sync requirement to 10 us.
Just ordered one, so the adventure begins. Maybe I just have to order one per multi-axis stage. They are so much cheaper than even Galil that that may be the easy solution.
Sorry to ramble. The questions are can I have multiple independent motion queues concurrently, started and stopped independently, and timing sync (or independence) across the CAN bus expansion units.
Thanks to all who have responded!
