@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

@cncmodeller

is there any way to recor a large move so I can see if the encoder values are leading the motor judders

This is coming in a beta soon
What you could do for now is a short recording whilst the motor is moving. So when the motor starts juddering, hit record in the plugin. That should record a short snippet in very high resolution.

This might actually be preferable to a long recording in high resolution because you're going to end up with a lot of data and a huge file!

@supertb1 That's worked

So from those graphs it's definitely C5, so keep it at that
From your M122: tuning error: 0x1c, this is yet to be documented, but this happens when not all the required tuning moves are made. From the docs:

manoeuvres 1, 2, 4, 8 and 16 are required

And 0x1c means 4, 8 & 16 haven't (yet) been run - so just try to home (assuming your homing file includes running those moves - which it should if you followed the tuning page - i.e. you should have an M569.6 ... V31 in your homing file somewhere)

Let me know if your motor then holds position after completing homing

If that works, we can move onto the x axis. Perhaps try unplugging your y motor and encoder from board 51 and plugging your x motor and encoder into board 51. I would expect your x axis to then just work (albeit it will think it's Y). If it doesn't we'll need to investigate your motor

@supertb1 Ah this is a much better graph - is this with C20?
Something else has caught my eye in your M122 - TMC(notifyWait,15.5%,26) - I'm pretty sure the TMC task runs at ~50% in the latest firmware, and around 15% in some older firmware. Is the firmware you're using definitely the 'unoffical' closed-loop dropbox release linked further up (https://www.dropbox.com/sh/qkexrvhgsebbz0g/AAD9gfyS8UIU5Sau311WS1oLa?dl=0)?

I think that because the 'unoffical' build has the same version number as the latest beta, any boards that were plugged in after you updated the firmware wouldn't update automatically - since it thinks it's already on the latest beta. @dc42 might be able to confirm if it works this way.
I assume the y-axis board is newly connected? if so, it might have fell into this trap.

Either way, I think it would be a good idea to at least try updating again to make sure you're on the 'unoffical' dropbox build linked above.

Just to be 100% sure, here's how I would update:

• Download Duet3Firmware_EXP1HCL.bin from the link above
• Drag and drop that bin file into the upload button on the system files tab
• It should then ask if you want to install the firmware, and then go ahead and visibly install it - if it doesn't do this, this means there's a problem

Then after that's done, maybe try running M122 again, and see if that percentage on the TMC task has jumped from 15% to >40% - that would be a good sign that this was indeed the issue, and that it's now resolved.

If that's successful, you might want to set your C value back to 5, then please could you send another picture like that graph & we'll see if it's made any difference

@supertb1

then I ran a homing sequence which returned the G28 X warning. And again the axis fails to move the drive back to the home position before the Z axis lowers using the Home X example with the V3 maneuver. Maybe I am confused here, the encoder should tell the motor to stay where ever it is when it stopped?

Yup you're absolutely right, the encoder should tell the motor to stay where it is even when it is stopped.
However, what is happening here is that the drive has been (intentionally) disabled because it failed tuning.
When you run M122 B50, you're right that it should say closed loop is enabled, but I suspect it also says something like tuning error: x where x is a non-zero value. Whenever x is non-zero, the drive is disabled because it treats it as a 'fault'. (At the moment this can be quite confusing - we're currently working on a way of making this more obvious such as a pop up in web control saying 'driver fault')
This is also the case for

and fails to return X and Y to home location using the homing example listed on the tuning page, however it does lower the Z axis back down at the end of the move

In this case, the X and Y motors have been intentionally disabled because there is a tuning fault - so they will be 'limp'. The z motor however has not been disabled, so that will continue to work.

I'll walk through the x and y axes data that you have collected separately, because I believe they have different issues.

Y-Axis

The second reason that tuning might fail is that step phase does not closely track desired step phase.
(For the interested reader, the first reason is that step phase moves in a different direction to desired step phase - e.g. step phase decreases when desires step phase increases)
In this case, step phase is increasing roughly 4x the speed as the desired step phase.
At this point hopefully it becomes evident why we disable the drivers if they fail tuning - in this instance, the motor would move 4x the intended distance - probably smashing into something you don't want to smash into!

This is normally caused by the encoder's count per step being set incorrectly (probably out by a factor of 4...)

You gave this originally:

Encoder Resolution 4000ppr

I've personally found the units that the manufacturers use to be pretty confusing - this seems to be specified in PPR - pulses per revolution. However, our docs refer to CPR:

Encoder counts per step (Cn.n) can be found from the datasheet of the encoder being used. If the value is stated as counts per revolution (CPR), divide by the steps per revolution of the stepper motor to get the count per step. For example, a 1000 CPR encoder attached to a 200 step/rev motor will have a count per step of 1000 ÷ 200 = 5.

To get from PPR to CPR you divide by 4 (this is probably our factor of 4 )
So your 4000 PPR encoders have a CPR of 1000
You say the motor has 200 steps, so that gives us a count per step of 1000 / 200 = 5
This means your config.g should have C5 in your M569.1 command
If you do, then we need to consider if the motors are actually 4000 PPR

X-Axis

Looking at the same graph for the x axis, the motor doesn't seem to be moving at all!

I think the best thing to do is focus on getting Y working, and once it is, we can use the fact you have a working axis to find the fault in the other (perhaps a dodgy wire, motor, encoder or 1HCL board - we can start swapping things around to see what works and what breaks things)

@supertb1

Ok I double checked the wiring today, Homed the axis in closed loop and then ran a tuning maneuver

Okie dokie, good stuff.
Can I just confirm if the motor is working as expected in open-loop mode?
When you say "Homed the axis in closed loop" I assume that's a typo and you homed in open-loop?
Was that homing successful?

You said before:

it seams as though it cut my steps in half and is making the motor oscillate loudly

Is this still the case? Or are you satisfied that the motor is now working correctly when attached to the duet board in open-loop mode?

To be honest, if the motor isn't working in open-loop, then there's no chance it will work in closed-loop, so we need to get the motor working (i.e. without these 'half-steps' and loud oscillations) in open-loop first before we can move onto doing anything in closed loop (tuning moves etc...)

On the other hand, I might have misinterpreted, and the motor is now working in open-loop? Please could you confirm either way

@supertb1
Apologies for the delayed reply, I've been moving house over the last few days so everything has been a bit hectic!

I disconnected the motor and ran it from a separate stepper drive I have built from an Arduino and a A4988.. The motor works fine in both directions outside the system

Okie dokie, that's good, we know the motor itself works.

I then reconnected the motor to the drive on the 1HCL ... with the M569 p50.0 D3 [open loop] it seams as though it cut my steps in half and is making the motor oscillate loudly, but it moves

Okay, so even in open-loop, the drive isn't behaving as expected.
From what you have said, it almost sounds like one of the coils isn't being energised, or is only being energised intermittently - so the motor is limping along on just 1 coil.
I don't know if @T3P3Tony has a set of standard troubleshooting instructions for when a drive doesn't work in normal open-loop mode, I'll give it a stab below, but I defer to anyone else's expertise for a more concrete procedure.

From the fact that we know your motor works, that seems to be suggesting it is either a problem with the wiring to the motor, or a problem with the driver chip on the Duet board.
I personally tested each one of those boards before they went out, so it's fairly certain they worked when they left me, but I suppose they could have been damage in mailing, so we should keep an open mind here.
However, I think more likely there is an intermittent connection on at least one of your wires going to the motor.
When you tested the motor on a separate stepper driver built from an arduino, did you use the same wiring to the motor?
Either way, it would be worth using a multimeter to test for continuity across those wires - perhaps giving them a bit of a wiggle to test for an intermittent connection that may only show itself when the wire is in a certain position

Let me know how you get on

@supertb1 hmm okay so it looks like the encoder is working...

Perhaps that reading of 0 is correct - is the motor actually moving at all during the recording?

If it's not, please could you check that the motor works in open loop mode - i.e. boot up the board and then run M569 P50.0 D3, and try to home the motor, move it, etc

If it doesn't work in open loop mode, it's most likely an issue with the wiring, you could try plugging the motor into your main board and check that it works in there

@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

@supertb1

is there another report with different variables I need to run for more information?

No, this is great

I'm not sure how to read these...

There's docs coming soon, but for now I'll talk you through it

The first thing to say is that the raw encoder reading is 0 on both recordings - this means it doesn't seem to register the encoder as moving at all.
This is strange because I thought that you did M122 twice after manually turning a full rotation and the encoder's reading changed... Please could you confirm this is still the case
(See this post for more detailed information)

@supertb1

does this mean that I need to switch the positive and negative wires?

Sorry, this error message is a bit misleading - I'll change that. The polarity should be detected automatically, so a better error message may be "encoder polarity failed to be detected"

Please could you follow the same instructions I gave to maxgyver above (here), although on the 'movement' checkboxes down the right hand side, please could you check 'polarity detection'

We should then be able to take a look at the graph and see what's going on