Duet3D 1HCL - Closed Loop Controller Beta test
-
@maxgyver okie dokie. Looking at your raw encoder reading (the black line) it seems to be a bit all over the place. I think the next thing to check is that the encoder is doing what we think it should be doing.
I think we've both got 500 CPR from the datasheet, but I must admit the wording of it in there is a bit confusing to me:impulse/turn: 500
So unless you know any differently, I think it would be good to investigate if the CPR really is 500.
Please could you run
M122 B50and then look for theClosed loop enabled: ...line. You should see a position value on there. Take a note of that, then manually move the motor ~1 full revolution (youcanshould disconnect the motor from the board to be safe from back EMF), then do the same again. This value is in PPR, so we should expect the value to increase by around 2000.For example, my motor has a CPR of 1000 (so a PPR of 4000). When I do this, I get:
Closed loop enabled: yes, live status: 0x4, encoder type rotaryQuadrature, pre-error threshold: 10.000000, error threshold: 50.000000, reverse polarity: no, tuning: 0, tuning error: 0x1f, position -13572, raw count = 51964, collecting data: no
Closed loop enabled: yes, live status: 0x4, encoder type rotaryQuadrature, pre-error threshold: 10.000000, error threshold: 50.000000, reverse polarity: no, tuning: 0, tuning error: 0x1f, position -9633, raw count = 55903, collecting data: no
13572-9633 = 3939 ~= my 4000 PPR
[When you do this, we should expect to see ~2000 PPR] -
@lirwin17 This is very strange, after disconnecting the N Pin from the encoder input I get the difference of 2000 for the position value when the motor shaft is turned one revolution. When the N pin is connected, it's around 3(+-1)
-
@maxgyver the index - N or Z pin is not needed right now so i would proceed using the encoders without it.
-
@t3p3tony Okay, this is the data chart with the N-pin disconnected
-
after disconnecting the N Pin from the encoder input I get the difference of 2000 for the position value when the motor shaft is turned one revolution. When the N pin is connected, it's around 3(+-1)
That is very strange
Yeah, as Tony suggests that pin isn't required at the moment so I'd just leave it disconnected.this is the data chart with the N-pin disconnected
That looks a lot better - the step phase is closely tracking the desired step phase. Is it passing tuning now? If not, there is still a fair degree of error between the two lines at points. I've often found I can decrease this error by increasing the motor current. Is your motor current set to the maximum for your motor? If not, try increasing it and see if it brings the step phase/desired step phase closer together.
-
@lirwin17 said in Duet3D 1HCL - Closed Loop Controller Beta test:
Is it passing tuning now?
Yes, it is passing the tuning. Sometimes tuning reports "incorrect polarity of the driver" first and then passes on the second try.
Is your motor current set to the maximum for your motor? If not, try increasing it and see if it brings the step phase/desired step phase closer together.
Changing the current doesn't make much of a difference.
Cheers
Max -
Okay, this is what I have tried so far:
- Quadruple checked my wiring, tried different encoder cables (long, short, with and without shielding/grounding.)
- Confirmed the CCP/PPR by turning the shaft by hand (motor disconnected) and checking the position results with M122 B50
- Disconnected all other CAN-Boards from the printer
- Disabled Input shaping
- Tried with a second 1HCL board
- Tested with a different motor
The Step Phase and desired step phase plot is still all over the place.
I have tried tuning the motor. But I get stuck at the derivative value that does not really influence the graph.
R70 I0 D0
R70 I0 D0.3
-
Hi @maxgyver ,
The Step Phase and desired step phase plot is still all over the place.
This graph looks good
Step phase basically means the current rotational position of the motor (step phase = current step position * 90 mod 360). As the motor rotates 4 steps, I would expect to see the graph you give - it increases by 360 degrees, but rolls over once due to that mod 360.
The main point aboutstep phaseis that it roughly followsdesired step phase- which it does
But I get stuck at the derivative value that does not really influence the graph.
Hmm okay, each setup will have different requirements for the D parameters - especially if an axis is particularly heavy. It might just be that you need to increase the D parameter to see an impact - but you're definitely right to start small to reduce the risk of causing unstable oscillations.
If you're worried that the D parameter is having no effect at all, you should be able to toggle on the recording of the PID control variables, so you'll be able to see the actual D value that's being calculated, and the effect it's having on the overall PID control signal. If you find that it is too small, you can increase the D value.
But do heed the warning on the tuning page:
We've already had some issues with the latest beta firmware being out of date - which I won't rule out causing these issues. As promised, we've just published an 'unofficial' firmware at this dropbox link.
Feel free to install this updated firmware and see if it has any effect - but don't forget to undo the multiplication by 4 that we did on your CPR! This updated firmware works as-per the docs, so requires a CPR value for the C parameter
-
HERE'S an article I wrote (oh, god, 21 years ago) about how to tune a PID system.
It's for DC servo motor with an encoder, but all the theory applies to steppers also.
It looks like you've got EXCELLENT logging and plotting ability, so you should be able to tune fairly well.
As I've said in the past, I'm not sure what people think they are going to get out of closed-loop steppers that they don't get from open-loop steppers other than recovery if you crash your head and miss a bunch of steps.
It is not going to get you better accuracy than open-loop if you are not crashing. In fact, I'd be willing to bet that accuracy goes way down to about 2 or 3 steps even when well tuned. (I'm ready and willing to be proven wrong, this is based on decades of tuning DC servos closed-loop with a lot of different mechanical systems.)
-
@lirwin17 said in Duet3D 1HCL - Closed Loop Controller Beta test:
This graph looks good
Step phase basically means the current rotational position of the motor (step phase = current step position * 90 mod 360). As the motor rotates 4 steps, I would expect to see the graph you give - it increases by 360 degrees, but rolls over once due to that mod 360.
The main point about step phase is that it roughly follows desired step phase - which it doesAaaah okay, that makes sense
I just installed the latest firmware. The D an I parameter plots are now much more comparable to the one's in the manual, and changes in the parameters can now be seen in the plot. BTW, I often get some parameters as this zigzag lines...
R75 I0 D0.26
R75 I2000 D0.26
One more Thing:
EDIT: (I wrote mm/s instead of mm/min. Absolute no go, especially if you call yourself an engineer
) Thank's @T3P3Tony for pointing that out!I noticed that when I put the motor in closed loop mode the maximum achievable speed is reduced to about 22000mm/min. In open loop mode I run at 36000mm/min easily.
@alankilian Thank's I will have a look!
Cheers,
Max -
HERE'S an article I wrote (oh, god, 21 years ago) about how to tune a PID system.
Looks like a great article! Thanks for linking it. I might add it to a 'further resources' section on the tuning docs
It looks like you've got EXCELLENT logging and plotting ability, so you should be able to tune fairly well.
Thankyou
As I've said in the past, I'm not sure what people think they are going to get out of closed-loop steppers that they don't get from open-loop steppers other than recovery if you crash your head and miss a bunch of steps.
You're definitely right there - but recovery like that can be a big advantage if you're dealing with especially large/costly prints. I used to do some work on a 1m^3 build volume printer that could easily churn through £1000 of filament on a single print. Because the extrusions it laid down were so big, if one was unlucky enough to slightly bend upwards into the path of the head, it could easily cause skipped steps and trash a very expensive print. IMHO Closed loop definitely makes sense as a sort of 'insurance' system in these cases - pay a little more upfront for closed loop motors to avoid the risk of trashing a £1000 print.
But closed loop does also have some other advantages:
- Less power usage, so motors run cooler. Generally when a motor is at a constant speed in closed loop mode (especially when that speed is 0) it will not be running at full current. This is especially pronounced on z-axis motors where 99% of the time the motors can be practically off, and yet they will still hold position if nudged. As opposed to an open loop system running a holding current through them all the time
- You can get higher speeds whilst maintaining accuracy! Hopefully something I might work on in my spare time is seeing just how fast a closed loop drive can run whilst still maintaining accuracy. Watch this space... Having closed loop on all your drives means you can finally answer the question "Just how fast can I run whilst maintaining an accuracy of < x steps"
It is not going to get you better accuracy than open-loop if you are not crashing. In fact, I'd be willing to bet that accuracy goes way down to about 2 or 3 steps even when well tuned. (I'm ready and willing to be proven wrong, this is based on decades of tuning DC servos closed-loop with a lot of different mechanical systems.)
I defer to your decades of experience here, although on my Ender 3 this is the kind of movement profile I get back from a simple 5mm (~25 step) move:
And plotting the error alone:
In the roughly 'steady state' section of the move the error very rarely exceeded 0.1 steps (both graph's y axes are in units of steps - my old high school teachers would be yelling at me to label that
)
As you would expect the most error comes in the initial transient part as the acceleration increases - we're hopefully looking to eliminate that in the near future with a feed-forward mechanism, that feeds forward the next move into the control algorithm.Although as we've already said, the target audience for these probably isn't ender 3's so maybe I've made a moot point! Either way I'm really interested to see how it performs on larger axes, and whether your prediction holds true, or if we can maintain this level of performance!
-
I just installed the latest firmware. The D an I parameter plots are now much more comparable to the one's in the manual, and changes in the parameters can now be seen in the plot
Ah excellent! Sorry about that. At least the new firmware is working & out there now.
BTW, I often get some parameters as this zigzag lines...
Hmm yeah... I'll look into this. It looks like sometimes it's just reading back 0 when it should't be. I'm confident this is a issue with the data transmission between the board & DWC though - the closed loop system itself should still be performing well
I'll get back to you on this I noticed that when I put the motor in closed loop mode the maximum achievable speed is reduced to about 22000mm/s. In open loop mode I run at 36000mm/s easily.
I'll definitely look into this - we don't want to be reducing our top speed with closed loop!
-
@maxgyver said in Duet3D 1HCL - Closed Loop Controller Beta test:
I noticed that when I put the motor in closed loop mode the maximum achievable speed is reduced to about 22000mm/s. In open loop mode I run at 36000mm/s easily.
Can I just double check you mean 36000mm/s and not either 3600mm/s or 36000mm/m ?36000mm/s would be a "F" parameter of F2160000
-
@lirwin17 Wonderful, thanks a lot for your effort and support!
@t3p3tony said in Duet3D 1HCL - Closed Loop Controller Beta test:
Can I just double check you mean 36000mm/s and not either 3600mm/s or 36000mm/m ?36000mm/s would be a "F" parameter of F2160000
Sry rookie mistake! I did indeed mean mm/min and not mm/s
-
@lirwin17 said in Duet3D 1HCL - Closed Loop Controller Beta test:
In the roughly 'steady state' section of the move the error very rarely exceeded 0.1 steps
That's an impressive graph.
Assuming a 200 step-per-rotation motor you are showing a measurement resolution of around 0.02 steps which means you have a 10,000 counts-per-revolution encoder?
I very much doubt anyone will have such high resolution encoders except people with large (huge) budgets.
I wonder what you'd get with a more traditional stepper motor with a 300 count-per-revolution encoder on it. That's 1.2 degree-per-count, and you will not be able to get your error to less than +/- 1 count, so you have a base error of one FULL step (of 1.8 degrees) and I think you'll find you get poor print quality on any printer at that error magnitude.
It's still interesting experiment and I'm super glad you are getting the result you are with high-precision equipment. That's an excellent result so far.
And I know you're at the beginning, I don't in any way want to discourage you, I'd just like to help you understand the limitations and set expectations appropriately so people aren't disappointed in the end.
ALSO, I may be misinterpreting or misunderstanding something. I haven't been very involved at all so I'm willing to be corrected without getting any undies in a twist.
-
That's an impressive graph.
Cheers!
you are showing a measurement resolution of around 0.02 steps which means you have a 10,000 counts-per-revolution encoder
The fact I'm plotting error might make it appear like I have more resolution than I do...
As an example, imagine the motor isn't moving so I'm getting a constant encoder reading. But my target is increasing at a rate of 0.000001/s. You'd get an error reading of 0, 0.000001, 0.00002 etc... which might imply I have a (very good) resolution of 0.000001. Whereas the actual encoder reading hasn't changed so we can't tell anything about the encoder resolution. I think something along those lines is going on hereThe actual encoder I'm using is a ~£30 encoder/motor combo from stepper online. Which gives an impressive 1000 CPR. The cheapest you can get is actually only ~£17 for 1000 CPR - which includes both the motor and the high-res encoder 🤯! I was pretty surprised with how cheap you could get high-res encoders like these.
You're completely right though that we need to consider how we can get the high-res required without breaking the bank, so something else that's in the works is using a hall effect 'encoder' like the AS5047D - which gives an impressive 2048 'CPR'. To be honest I have found them fairly noisy compared to the quadratures, but even that noise hasn't lead to any noticeable quality defects on my Ender 3 when compared to open loop controlOne final trick up my sleeve is to dissect the CPR signal into it's individual pulses. Given that a single 'count' is actually made up of 4 pulses, we get an extra factor of 4 resolution for free!
Now technically I don't think there are any guarantees that these pulses are evenly spaced, but even if they are unevenly spaced, it still gives us an increase in resolution. (With counts, we could be up to 0.999... out, whereas even with unevenly spaced pulses, we could only ever be up to 0.4999 out (If that makes sense ))So dissecting the signal gives me effectively a 4000 CPR encoder for the low low price of ~£30
-
@lirwin17 said in Duet3D 1HCL - Closed Loop Controller Beta test:
One final trick up my sleeve is to dissect the CPR signal into it's individual pulses. Given that a single 'count' is actually made up of 4 pulses, we get an extra factor of 4 resolution for free!
I really don't think that's true for quadrature encoders.
The two terms used in the industry are:
- Lines per rev
- Counts per rev
An optical encoder with 100 lines on it when used in a quadrature arrangement produces 400 "edges" in the two signals in its output, so it can count 400 times per revolution.
So if your motor says 300 counts-per-rev, it's a 75-line optical encoder. If it says 1,000 counts-per-rev it's a 250-line encoder.
Of course, they COULD be saying 300 counts-per-rev and may actually mean 300 lines-per-rev but that would be a mistake on their part. Or the language has changed out from under me.
Turn the stepper one turn and see how many counts you get from your encoder-reading method and you'll know!
I'll start a new thread on an idea that I think can get you both the expected great open-loop performance of a stepper and the error-recovery of a closed-loop system without getting into all the darn PID tuning/feedforward-complexity/integral-windup/mode-changing difficulties you are about to encounter trying to implement a pure PID control of a stepper using encoder feedback.
SeemeCNC Rostock Max V3 converted to V3.2 with a Duet2 Ethernet Firmware 3.2 and SE300
-
Aye I'm not 100% sure of the terminology
But I've experimentally verified that this motor gives 1000 of these
full cycles per revolution, and therefore 4000 rising/falling edges per full revolutionIn order to be consistent with stepperonline and some other datasheets that I've seen, we've documented 'CPR' as the number of complete cycles per revolution - which is at odds with your understanding of the terminology. This is what this period of testing is for though! So thanks for raising it! If a lot of people are getting confused, we'll look at changing the terminology that we're using to be in line with what you say. But for now, even if it's technically wrong, we'll keep the terminology as CPR so at least we're consistent with the common motor datasheets
I'll start a new thread on an idea that I think can get you both the expected great open-loop performance of a stepper and the error-recovery of a closed-loop system
I look forward to reading it!
-
I've gone down a bit of a rabbit hole looking at why it can't run at top speeds - but I think I finally have an answer!
Forgive me, but I might talk about RPM here instead of mm/min. It just makes it a bit less printer-dependant.
For reference, RPM = (mm/min) * (step/mm) * (rev/step), and here are some common conversion that we've talked about (for an average printer):
22000 mm/min = 550 RPM
36000 mm/min = 900 RPMIn theory, the maximum speed is given by the PID loop frequency. Each iteration of the PID loop can command the motor to take 1 step (=rotate 0.005 degs). The PID loop currently runs at 12000 Hz.
This means that the theoretical max speed is 12000 x 0.005 x 60=3600 RPM.Why then are we topping out at ~900 RPM (measured on my Ender 3, other's results may be different)
The answer is how long it takes to communicate the new motor currents to the driver ICs that we use.
At the minute, this takes ~0.064ms. At low RPMs, this is negligible. But at high RPMs, it means the motor has moved on a significant amount between deciding what current to set, and actually setting that current. At my max speed of 900RPM, it's moved on a whole 0.2 steps. We should be able to fix this by looking at the current RPM and 'predicting' how much the motor will have moved by the time the currents have been sent.Thanks for pointing this out! It would be useful if I could gauge just how much of an issue this is. Would the current top speed be an issue for you? Or is it just a nice-to-have? If anyone else would have issues with this limitation, please do say
This feedback will then impact our decision on what to focus on improving next -
@lirwin17 said in Duet3D 1HCL - Closed Loop Controller Beta test:
Thanks for pointing this out! It would be useful if I could gauge just how much of an issue this is. Would the current top speed be an issue for you? Or is it just a nice-to-have? If anyone else would have issues with this limitation, please do say
For me, the whole point of switching to closed loop was to increase speed and reliability. In open loop my printer starts skipping steps at around 900 RPM (36000mm/min). During printing, I limit the travel speed to 24000 mm/s just to be on the safe side. So if it can reliably run at 900 RPM in closed loop, it would be okay for me. Everything more than that would be a nice to have.
