Duet3D 1HCL - Closed Loop Controller Beta test

[lirwin17]

@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

[supertb1]

@lirwin17 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, I then reconnected the motor to the drive on the 1HCL took it out of close loop mode and homed the axis, moved the motor around.. with the M569 p50.0 D3 it seams as though it cut my steps in half and is making the motor oscillate loudly, but it moves. With the closed loop off the motor also oscillates but it does move.50_2021-09-22_10.54.21.csv
Not sure what has happened but I ran a step maneuver and the drive moved about 5mm and returned some interesting results... let me know what you think

[supertb1]

@lirwin17 here is my current config
G4 S3 ;wait for expansion boards to start
M569.1 P50.0 T2 C5 E5:10 ; Configure the 1HCL board at CAN address 50 with a quadrature encoder on the motor shaft that has 20 steps per motor full step.
M569.1 P51.0 S1 T2 C20 E20 R100 I0 D0 ; Configure the 1HCL board at CAN address 51 with a quadrature encoder on the motor shaft that has 20 steps per motor full step.
M569 P50.0 D4 S1 ; Configure the motor on the 1HCL at can address 50 as being in closed-loop drive mode (D4), Open loop (D2) and not reversed (S1) X axis
M569 P51.0 D2 S1 ; Configure the motor on the 1HCL at can address 51 as being in closed-loop drive mode (D4), Open loop (D2) and not reversed (S1) Y axis
M569 P0.0 S1 ; physical drive 0.0 goes forwards Z 1-2 axis
M569 P0.4 S1 ; physical drive 0.4 goes forwards Extruder
M584 X50.0 Y51.0 Z0.0:0.1 E0.4 ; set drive mapping
M671 X-122.25:689.20 Y0:0 S3.0 ; leadscrews at left (connected to Z0) and right (connected to Z1) of X axis
M350 X32 Y32 Z32 E16 I1 ; configure microstepping with interpolation
M92 X106.5 Y257 Z795.00 E339.00 ; set steps per mm
M566 X900.00 Y900.00 Z60.00 E120.00 ; set maximum instantaneous speed changes (mm/min)
M203 X6000.00 Y6000.00 Z180.00 E1200.00 ; set maximum speeds (mm/min)
M201 X500.00 Y500.00 Z20.00 E250.00 ; set accelerations (mm/s^2)
M906 X1000 Y3000 Z3000 E800 I30 ; set motor currents (mA) and motor idle factor in per cent
M84 S30 ; Set idle timeout
M917 X0 Y0 ; Set the closed loop axes to have a holding current of zero

[supertb1]

@lirwin17 and my current home X

[supertb1]

@supertb1 ; homex.g
; called to home the X axis
;
; generated by RepRapFirmware Configuration Tool v3.2.3 on Mon Mar 08 2021 08:53:31 GMT-0600 (Central Standard Time)
M569 P50.0 D0 ; Turn off closed loop

G91 ; relative positioning
G1 H2 Z5 F6000 ; lift Z relative to current position
G1 H1 X-240 F3000 ; move quickly to X axis endstop and stop there (first pass)
G1 H2 X5 F6000 ; go back a few mm
G1 H1 X-240 F240 ; move slowly to X axis endstop once more (second pass)

G90 ; absolute positioning
G1 X50 F3000 ; Move to a known-safe position
M400 ; Wait for the move to complete
G4 P500 ; Wait for the motor to settle
M569 P50.0 D4 ; Turn closed loop back on
M569.6 P50.0 V31 ; Perform the tuning manoeuvres for a quadrature encoder
G1 X0 ; Move back to X0

G1 H2 Z0 F6000 ; lower Z again

[supertb1]

@lirwin17 in closed loop I tried to do a homing move and it returned a: 9/22/2021, 11:03:30 AM G28 X
Warning: One or more tuning errors occurred. The drive has been found to have an incorrect polarity.

[supertb1]

This post is deleted!

[lirwin17]

@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]

@lirwin17 Hi Louis, glad things are sorted at the Irwin residence. Ok I double checked the wiring today, Homed the axis in closed loop and then ran a tuning maneuver 1a2fa09f-8b25-4e18-82bd-03b9d4f5fee2-50_2021-09-27_07.10.36.csv

[supertb1]

@supertb1 50_2021-09-27_07.10.36.csv

[supertb1]

@lirwin17 let me know your thoughts

[lirwin17]

@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]

@lirwin17 Ok so today I finished installing the Y axis motor and connecting it up. and yes I did perform a homing in closed loop and open loop with the X axis motor, "M569.6 P50.0 V2, it gives an "G28 X; G28 Y
Warning: No new tuning errors have been found, but some existing tuning errors exist. The drive has not had it's polarity checked. The drive has not had it's control checked. The encoder has not had it's count per revolution checked." respectively, 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, like it skips the command to move the axis back to zero in absolute.
The X and Y axis do not move back to the position of home after being put in closed loop and manually moved from position furthering the issue with the encoder polarity and count check.
The Y axis and X axis maneuver are attached 51_2021-09-29_17.19.21 X Axis.csv
51_2021-09-29_17.07.23 Y Axis.csv . I am waiting to hear from you before I try and use the machine to make a print... I am hoping there may be some tweeks to optimize what is being recorder.... please let me know what you think.

[supertb1]

This post is deleted!

[supertb1]

This post is deleted!

[supertb1]

@lirwin17 This morning I ran a M122 B50 to which it returned a confirmation of being in closed loop mode. 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? I ran the M122 B50 again immediately after running the homing sequence to which it returned a confirmation of being in closed loop.

[lirwin17]

@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]

@lirwin17 ok, We will focus on the Y axis then
here is the current config:
G4 S1 ;wait for expansion boards to start
M569.1 P50.0 T2 C5 E5:10 ; Configure the 1HCL board at CAN address 50 with a quadrature encoder on the motor shaft that has 20 steps per motor full step.
M569.1 P51.0 T2 C5 E5:10 ; Configure the 1HCL board at CAN address 50 with a quadrature encoder on the motor shaft that has 20 steps per motor full step.
M569 P50.0 D4 S1 ; Configure the motor on the 1HCL at can address 50 as being in closed-loop drive mode (D4), Open loop (D2) and not reversed (S1) X axis
M569 P51.0 D4 S1 ; Configure the motor on the 1HCL at can address 51 as being in closed-loop drive mode (D4), Open loop (D2) and not reversed (S1) Y axis
M569 P0.0 S1 ; physical drive 0.0 goes forwards Z 1-2 axis
M569 P0.4 S1 ; physical drive 0.4 goes forwards Extruder
M584 X50.0 Y51.0 Z0.0:0.1 E0.4 ; set drive mapping
M671 X-122.25:689.20 Y0:0 S3.0 ; leadscrews at left (connected to Z0) and right (connected to Z1) of X axis
M350 X16 Y16 Z16 E16 I1 ; configure microstepping with interpolation
M92 X106.5 Y257 Z795.00 E339.00 ; set steps per mm
M566 X900.00 Y900.00 Z60.00 E120.00 ; set maximum instantaneous speed changes (mm/min)
M203 X6000.00 Y6000.00 Z180.00 E1200.00 ; set maximum speeds (mm/min)
M201 X500.00 Y500.00 Z20.00 E250.00 ; set accelerations (mm/s^2)
M906 X1000 Y4000 Z3000 E800 I30 ; set motor currents (mA) and motor idle factor in per cent
M84 S30 ; Set idle timeout
M917 X0 Y0 ; Set the closed loop axes to have a holding current of zero
51_2021-09-30_09.34.56Y axis.csv

M122 B51, Taken after homing maneuver
Diagnostics for board 51:
Duet EXP1HCL firmware version 3.4.0beta3 (2021-08-24 14:56:43)
Bootloader ID: SAME5x bootloader version 2.4beta (2021-07-23)
Never used RAM 52992, free system stack 2579 words
Tasks: Move(notifyWait,0.0%,126) HEAT(notifyWait,0.0%,78) CanAsync(notifyWait,0.0%,70) CanRecv(notifyWait,0.0%,79) CanClock(notifyWait,0.0%,72) TMC(notifyWait,15.5%,26) CLSend(notifyWait,0.0%,130) CLData(notifyWait,0.0%,142) MAIN(running,82.6%,418) IDLE(ready,0.0%,39) AIN(notifyWait,1.9%,265), total 100.0%
Last reset 00:09:14 ago, cause: software
Last software reset time unknown, reason: HardFault bfarValid precise, available RAM 53024, slot 2
Software reset code 0x0060 HFSR 0x40000000 CFSR 0x00008200 ICSR 0x00487803 BFAR 0x20030018 SP 0x2001e658 Task MAIN Freestk 533 ok
Stack: 00000000 2001e70c 20001bac 20030000 0002f65d 0001b621 0001e628 41000000 bf800000 00000000 e2080202 809c0f12 00884802 45a0900e 818917c0 0a003008 62004200 05020070 1084081c 76001303 88124026 41200000 41c1a2e1 41425f6e 20000010 00000002 00000002
Closed loop enabled: yes, live status: 0x4, encoder type linearQuadrature, pre-error threshold: 5.000000, error threshold: 10.000000, coil A polarity: -, coil B polarity: -, tuning: 0, tuning error: 0x18, position -1515847609, raw count = 65526, collecting data: no, ultimateGain=0.000000, oscillationPeriod=0.000000
Driver 0: position -244150, 257.0 steps/mm, standstill, reads 22774, writes 9256 timeouts 0, SG min/max 0/461, steps req 300690 done 82207
Moves scheduled 10, completed 10, in progress 0, hiccups 0, step errors 0, maxPrep 25, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0
Peak sync jitter -4/6, peak Rx sync delay 179, resyncs 0/0, no step interrupt scheduled
VIN: 24.2V, V12: 12.2V
MCU temperature: min 28.8C, current 31.3C, max 33.9C
Ticks since heat task active 120, ADC conversions started 550990, completed 550989, timed out 0, errs 0
Last sensors broadcast 0x00000000 found 0 125 ticks ago, loop time 0
CAN messages queued 6003, send timeouts 0, received 5035, lost 0, free buffers 37, min 37, error reg 0
dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 297, adv 37072/37191

RTellegent Nema 23

what steps can I perform to give you the best information to come to a resolution on this drive?

[alankilian]

@lirwin17

I noticed that in the .csv file whenever raw encoder value changes by one, step phase changes by 204.

You can see those large jumps in the graph you posted.

I'm not sure what "Step phase" is, but I see that it wraps at 4096. Is this the actual (calculated) microstep that corresponds to the encoder value? If so, how many microsteps-per-step are you using?

If he's got a 4,000 count-per-rev encoder and a 200 full-step-per-rev motor, as you say, there are 5 encoder counts per motor full-step so if you are counting 200 "Step-phase" units per encoder count, that's 1020 (or 1024) microsteps-per-full-step which seems like a lot.

NOTE: I don't have much insight into what you are doing, or into the code you are using, so even though I'm trying to help here, this might be a complete waste of your time, so PLEASE ignore my ignorance if it's a distraction to you getting your work done.

[dc42]

@supertb1 in the M569.1 commands, where you already using C5, or have you just changed them to C5? If you were already using C5, please try C20 instead.