Best posts made by lirwin17

@maxgyver Hi Max!
Glad to hear the boards are finally in the hands of users! I've been working on the firmware for these boards most recently, so I'll answer your points

1. I'll investigate that at some point this week. Cheers for flagging it - for now I've just amended the documentation. I've also added in something that I don't think was clear enough before - although the 1HCL boards do support the error thresholds, I do not believe the current mainboard firmware does anything with them once they are received. This is something that's on the cards, but hasn't quite been implemented yet in the mainboard firmware.

2. Ah yes - this is an interesting one - so the M569.3 & M569.4 commands haven't been added by me as a part of the 1HCL closed loop stuff - I believe they have been added by a member of the community for use on a different board entirely. The other M569.x commands should all state which boards they are supported on (e.g. M569.5: "Only supported for drivers on Duet 3 closed loop driver boards that are configured in closed loop mode.") I'll chase up which boards M569.3 is supported on and then add them to the docs so it's clear. We have had conversations about implementing M569.3 on the 1HCL board - but it's a fair way down our roadmap right now.

3. The default state for the drivers is not to move. Only after a successful full tune (M569.6 ... V31) should they move.
   This is because closed loop systems have the potential to do much worse things that open loop ones if they are configured incorrectly (e.g. if you set a negative P term it will accelerate in the opposite direction to what you want, or an I term that's too large could result in unbounded oscillation)
   This means that if the axis still doesn't move after tuning, the tuning was unsuccessful - I'll walk you through what to do in this instance in a sec.
   What's more concerning to me is that sometimes it vibrates erratically. It shouldn't pass tuning unless it's pretty sure it will behave. In these instances, are the PID parameters set as you describe (R100 I0 D0)? (i.e. you've not maybe increased them to see if that makes any difference?)
   When a tuning move has been unsuccessful (you run M569.6 ... V31 and it doesn't move), it should report back how it was unsuccesful. Although you may need to go to the console tab down the left to see the full output. Please could you let me know what it reports back after running M569.6 ... V31 and I'll talk you through what to do. If, for whatever reason, M569.6 isn't reporting anything back, please could you let me know the output of M122 B50 (Assuming the board is at address 50, as you give in your example). For future reference, the docs for this should be going up soon.

4. Oops, the repo is private. I'll ask someone to change that Edit: That's been changed now, hopefully you should be able to see it

Cheers,
Louis

@maxgyver said in Duet3D 1HCL - Closed Loop Controller Beta test:

@lirwin17 I am using Duet Web Control 3.4.0-b3

That should be fixed now
Please could you re-dowload the 0.2-alpha release of the plugin, uninstall the previous plugin, and then install the new one. With any luck that should have fixed the issue.

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 about step phase is that it roughly follows desired 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

@maxgyver thank you for the update! Don't worry, I've not forgotten about increasing the max speed - it's actually next on my list!

was able to increase my acceleration and jerk significantly

Excellent that's what we like to hear

I have two motors on my Y axis. They are both wired to one 1HCL board, but only one has an encoder. It calibrates fine, and I did not spot a significant problem during printing. Only the recorded graphs were of no use on this axis (at least for me). Maybe something to keep in mind for future development

Hmm okay do you mean that both motors are wired into the single driver output on the 1HCL? What exactly were the issues you were having with the recorded graph?

Furthermore, I have the impression that the drivers run in full step without any microstepping as soon as I switch to closed loop. It sounds very much like my very first printer. The prints also show a strong stepping pattern.

This is an interesting one haha - so with closed loop, we kinda lose all sense of microstepping, since the motors no longer move in discrete steps, but move as close to continuously as possible. This means that in theory, the microstepping is infinite... but the keyword here is 'continuously as possible', in reality the motor has to move some discrete distance per PID iteration, and this is a function of the frequency of the PID loop (constant) and the speed of the move (variable). If you do a very slow move, I'd expect you to be getting very small discrete moves per PID cycle (the equivalent of very high mocrostepping), whereas if we're pushing the boundary on how fast we can move, you'll get very large discrete moves per PID cycle (up to a full step).
You can actually measure the size of these discrete steps by taking a recording (with speed set to 'as fast as possible') and looking at the step phase variable, and the vertical distance between datapoints. A distance of 90 degrees means 1 step, you could work out an 'effective microstepping' from this, since you know the increments in which the motor moves.

The good news is though, as we increase the maximum speed, the 'effective microstepping' will also increase as well, so hopefully you'll see less of the stepping pattern as we do so