Thank you all for your insights.

I read a few more things on the DUET forums and other forums and I'm starting to think that implementing a PID for motion planning may not bring so many benefits. It would be complicated to implement, and the speed gains would be marginal. (It may already be implemented in LinuxCNC, but I didn't look into the details).

Still, while reading, I read a bit more about TinyG and the way they handle the higher order derivatives, as was suggested by @Danal . Their implementation detail is here: https://github.com/synthetos/TinyG/wiki/Jerk-Controlled-Motion-Explained . The major advantage of their implementation is that it smooths the movement, so less force would be put on the belts, which in turn would cause them to not stretch that much, which in turn would provide more accurate prints. There was some talk about it last year on this forum https://forum.duet3d.com/topic/4802/6th-order-jerk-controlled-motion-planning , but I don't think it was implemented.

Other than that, maybe the idea of reading the motion feedback would not be that bad, provided the printer is rigid "enough". Using some carefully chosen calibration movements before printing would allow people to calibrate the motion parameters, thus determining optimal settings for speed, quality, or different trade-offs between them. Maybe this could be implemented as a separate (slave) module connected to the main board via CAN...

@Danal
Huh! Cool!! How about this: https://www.youtube.com/watch?v=uFZCv1Ns5cA ?
Edit: Or this one: https://www.youtube.com/watch?v=idMcJ1h2L8U , which I personally saw in action, and I was blown away... And to think that it is implemented with PID

@Danal said in Steppers PID - NOT heaters PID:

Others have said in more detail what I was trying to say in a very quick post:

1. Visible artifacts are from inertia, belt stretch, ...

2. PID algorithms require feedback.

3. Combine (1) and (2) and it surfaces the need for feedback more accurate than the visible artifacts (microns) and corrections the same... with a speed of correction that ensures plastic is never put in the wrong place.

That's actually much harder than just getting the positioning right to begin with.

On the other hand, your comment about 8 bit algorithms is very well taken. Many controllers still use trapezoidal acceleration; a few use S. The real magic comes when you quit trying to calculate speed/accel at all and go to higher level derivatives like jerk, snap, crackle, and pop.

I have one controller that calculates "constant jerk" instead of calculating speed or acceleration. It is amazing. I tripled the speed of the (largish) CNC router where I installed it (that machine had Mach3 before, which is trapezoidal speed/accel) while at the same time producing better cuts.

I believe that's where 32 bit code developer effort should go: Higher order derivatives.

The thing with the constant jerk is quite interesting... But I don't know what systems implement it.

And about the higher order derivatives... Wouldn't that complicate things for the end users? How could you determine them, without trial and error?
The thing with PID is that with 3 numbers you can optimize the entire system, and there is a whole lot of literature on this subject, provided you are able to calculate the real step response...

Thank you all for finding the time to read and answer to this post. I don't know many things, which is why I wrote here some unfinished thoughts.

@bearer From what I know, the servos cost a lot. I was thinking that maybe there would be some way to obtain an accurate position from the trinamic driver, thus eliminating the need for an encoder or expensive servo assembly.

@mrehorstdmd (As a side note, I read many of your articles and I really admire you!!!) Theoretically, a PID would allow you to control the system "as a whole". For example, in the youtube video that I posted, you could have weights attached to the "arrow", with different shapes and different positions, but it wouldn't matter, because you would tune the whole movement. So I'm thinking that finding the right PID parameters would mean that you would tune not only the motor movement, but also the final carriage, thus tuning the springiness of the belts and other motion system elements.
You are right about the difficulty of measuring the "real" position accurately. Initially I was thinking about using a laser mounted on the print head and an array of photodiodes mounted on the bed. In order to find the PID parameters, you don't need to analyze the entire motion of the carriage, but only the oscillations nearby the target position, which wouldn't be that big anyway. But then I thought that the oscillations of the carriage would be sent back to the motor via the belts (or the screws), and you would be able to measure them at the motor side. And then I was thinking of obtaining these positioning errors from the trinamic driver used in DUET. But I don't know if that is possible. So another idea would be to use a rotary encoder. For a 1.8 degree stepper, a 2000 ppr encoder and 100 steps per mm, you would obtain a 1 micron resolution, allowing you to measure a step response for PID tuning.
As for tweaking acceleration, jerk, etc... I think we are treating the symptoms, and not the cause. The current algorithms were some adaptations that needed to be performed in order to allow computing the motion on 8 bit MCUs. Now, as the available computing power grew a lot, maybe a "normal" algorithm would be worth implementing. I know that FDM will never be like injection molding, but I was thinking more about optimizing the process results (speed and print quality). I have a feeling that using PID would allow faster movement speeds than using a constant acceleration (the ramp speed profile).

I was not thinking about skipped steps or mechanical issues. I was thinking about the small oscillations caused by the carriage inertia, which creates the ghosting effect. In a "real" system that has to move, if you plot the real movement on X for example, you will find that at the end of the movement there are minor oscillations caused by the inertia (something like this: https://3l4sbp4ao2771ln0f54chhvm-wpengine.netdna-ssl.com/wp-content/uploads/2017/10/Motion-controller-FAQ-how-to-address-overshoot-768x394.jpg ). If you fine tune the PID parameters, that overshoot can be eliminated. If you can find the right parameters for critical damping, you will have the maximum speed with no oscillations happening at the end of the movement.

Hi All,

I was watching this video https://www.youtube.com/watch?v=qKy98Cbcltw and that got me thinking about all the problems with oscillations related to 3D printing. Basically, some quirks like max acceleration, jerk, etc are implemented to control the movement jerk caused by a "heavy" heat-end assembly. This jerk will cause the ghosting in the printing items, and the only ways to reduce it would be to reduce the printing speed or decrease the total moving mass.

But if a PID control would be implemented, you could effectively control the amount of ghosting present in the printed items, while maximizing the printing speed. Right now, choosing the max speed is some kind of an art, making it less user friendly. If PID would be implemented, it would allow anyone to obtain quality prints easier, at fastest possible speeds for their printers.

There are 2 problems that I see:

1. How to calibrate the PID parameters? A feedback signal would be needed to measure for example the overshoot while moving. For sure, this can be done with an encoder attached to each motor. But is it possible to obtain this data from the Trinamic drivers?
2. The filament flow will probably be more difficult to compute, since the acceleration profile would not be a ramp anymore...

As a note, from what I read about movement control in CNCs and 3D printers, the current movement algorithms were created to overcome the processing limit specific to 8 bit controllers. Having faster 32 bit processors would probably allow this kind of implementation...

What are your opinions on this?