Duet3D 1HCL - Closed Loop Controller Beta test
-
@lirwin17 M122 B50
Diagnostics for board 50:
Duet EXP1HCL firmware version 3.4.0beta3+1 (2021-09-14 15:07:31)
Bootloader ID: SAME5x bootloader version 2.4beta (2021-07-23)
Never used RAM 51472, free system stack 2592 words
Tasks: Move(notifyWait,0.0%,160) HEAT(notifyWait,0.0%,95) CanAsync(notifyWait,0.0%,70) CanRecv(notifyWait,0.0%,81) CanClock(notifyWait,0.0%,72) TMC(notifyWait,38.1%,344) CLSend(notifyWait,0.0%,148) CLData(notifyWait,0.0%,142) MAIN(running,59.9%,408) IDLE(ready,0.0%,39) AIN(notifyWait,2.0%,265), total 100.0%
Last reset 00:01:25 ago, cause: power up
Last software reset time unknown, reason: HardFault bfarValid precise, available RAM 51580, slot 2
Software reset code 0x0060 HFSR 0x40000000 CFSR 0x00008200 ICSR 0x00430803 BFAR 0x20030008 SP 0x2001eba8 Task MAIN Freestk 531 ok
Stack: 00000000 00000000 00000002 20030000 00030f39 0001b8f9 0001ea4c 41000000 bf800000 00000000 533c0605 04001200 a8888700 06420000 c2010829 19a21029 50708239 5d000040 2a60041c 54540122 04801201 41200000 41c27924 4142a3fe 20000010 0002699b 00000002
Closed loop enabled: yes, live status: 0x4, encoder type rotaryQuadrature, pre-error threshold: 5.000000, error threshold: 10.000000, reverse polarity: no, tuning: 0, tuning error: 0x1f, position 0, raw count = 0, collecting data: no, ultimateGain=0.000000, oscillationPeriod=0.000000, Control loop runtime (ms): min=0.000000, max=0.066667, avg=0.008000, Control loop frequency (Hz): min=7075.472168, max=18292.683594, avg=15625.000977
Driver 0: pos 0, 106.5 steps/mm, standstill, reads 8610, writesMoves scheduled 0, completed 0, in progress 0, hiccups 0, step errors 0, maxPrep 0, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0
Peak sync jitter -4/3, peak Rx sync delay 179, resyncs 0/0, no step interrupt scheduled
VIN: 24.3V, V12: 12.2V
MCU temperature: min 23.1C, current 25.4C, max 25.4C
Ticks since heat task active 157, ADC conversions started 84048, completed 84047, timed out 0, errs 0
Last sensors broadcast 0x00000000 found 0 162 ticks ago, loop time 0
CAN messages queued 728, send timeouts 0, received 744, lost 0, free buffers 37, min 37, error reg 0
dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 0Disconnected the motor coils and turn the motor by hand one full revolution by hand:
M122 B50
Diagnostics for board 50:
Duet EXP1HCL firmware version 3.4.0beta3+1 (2021-09-14 15:07:31)
Bootloader ID: SAME5x bootloader version 2.4beta (2021-07-23)
Never used RAM 51472, free system stack 2580 words
Tasks: Move(notifyWait,0.0%,160) HEAT(notifyWait,0.0%,95) CanAsync(notifyWait,0.0%,70) CanRecv(notifyWait,0.0%,81) CanClock(notifyWait,0.0%,72) TMC(notifyWait,38.4%,344) CLSend(notifyWait,0.0%,148) CLData(notifyWait,0.0%,142) MAIN(running,59.6%,380) IDLE(ready,0.0%,39) AIN(notifyWait,2.0%,265), total 100.0%
Last reset 00:05:31 ago, cause: power up
Last software reset time unknown, reason: HardFault bfarValid precise, available RAM 51580, slot 2
Software reset code 0x0060 HFSR 0x40000000 CFSR 0x00008200 ICSR 0x00430803 BFAR 0x20030008 SP 0x2001eba8 Task MAIN Freestk 531 ok
Stack: 00000000 00000000 00000002 20030000 00030f39 0001b8f9 0001ea4c 41000000 bf800000 00000000 533c0605 04001200 a8888700 06420000 c2010829 19a21029 50708239 5d000040 2a60041c 54540122 04801201 41200000 41c27924 4142a3fe 20000010 0002699b 00000002
Closed loop enabled: yes, live status: 0x4, encoder type rotaryQuadrature, pre-error threshold: 5.000000, error threshold: 10.000000, reverse polarity: no, tuning: 0, tuning error: 0x1f, position 4055, raw count = 4055, collecting data: no, ultimateGain=0.000000, oscillationPeriod=0.000000, Control loop runtime (ms): min=0.006667, max=0.086667, avg=0.008000, Control loop frequency (Hz): min=6756.756836, max=16304.347656, avg=15625.000977
Driver 0: pos 0, 106.5 steps/mm, standstill, reads 0, wriMoves scheduled 0, completed 0, in progress 0, hiccups 0, step errors 0, maxPrep 0, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0
Peak sync jitter -3/4, peak Rx sync delay 183, resyncs 0/0, no step interrupt scheduled
VIN: 24.3V, V12: 12.2V
MCU temperature: min 23.1C, current 26.3C, max 26.5C
Ticks since heat task active 205, ADC conversions started 324949, completed 324948, timed out 0, errs 0
Last sensors broadcast 0x00000000 found 0 210 ticks ago, loop time 0
CAN messages queued 2005, send timeouts 0, received 2218, lost 0, free buffers 37, min 37, error reg 0
dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 0 -
@lirwin17 it is reading the encoder... raw count 4055 from zero.. .and it is a 4000 count encoder
-
@lirwin17 what would be the next step to trouble shoot
-
@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, etcIf 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
-
@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 -
@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 -
@lirwin17 and my current home X
-
@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 loopG91 ; 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 X0G1 H2 Z0 F6000 ; lower Z again
-
@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. -
This post is deleted! -
@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 positionLet me know how you get on
-
@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
-
-
@lirwin17 let me know your thoughts
-
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
-
@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. -
This post is deleted! -
This post is deleted! -
@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.
-
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 runM122 B50, you're right that it should say closed loop is enabled, but I suspect it also says something liketuning error: xwhere x is a non-zero value. Wheneverxis 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 forand 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 haveC5in yourM569.1command
If you do, then we need to consider if the motors are actually 4000 PPRX-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)
