Posts made by achrn

https://docs.duet3d.com/en/Duet3D_hardware/Duet_3_family/Duet_3_Roto_Toolboard under "Operating limits" lists the stepper current limits as "Up to 1A peak current, 1.1A RMS". One of these figures must be wrong, I think. Further up teh page it repeats 1A peak, so I suspect it's the RMS that's wrong.

It occurred to me to check some other input shapinng:

M593 P"zvd" F37 clunks more softly and at different movements: in the 1200 acceleration case (which clunks under zvddd other than 12-26) it clunks for movements above xval=22

M593 P"zvdd" F37 clunks intermediately loudly, but at different movements: in the 1200 acceleration case (which clunks under zvddd other than 12-26) it clunks other than xval=8-24

So I also tried varying teh frequency

M593 P"zvddd" F74 and M593 P"zvddd" F18 both clunk and not-clunks differently to F37

@droftarts Aha! Excellent, thank you. I was just about to figure out how to try it standalone, following @Phaedrux 's request. I confirm that if I run mine SBC mode without input shaping I have no clunks. Since the cause has been narrowed this far and repeated by someone else, I'm not inclined to work back through old firmware versions, unless really likely to make teh difference between solving it and never resolving it, but I could try some older versions if it will make a big difference to tracking down the problem - please let me know.

Input shaping as the 'cause' stacks up because I only relatively recently put on a toolboard, and it's only when I got the toolboard (with the accelerometer) that I enabled input shaping. So although I hadn't made the connection that that's when clunks started, with hindsight it's very credible it was at about that time. I don't run it fast enough to really need input shaping anyway - the quality enhancement is debatable, and it's more a case of enabling it because it's there, so disabling it is not a hardship.

Thanks everyone for input, I'm now clunk free (though I also have a printer in pieces, so I need to spend some time re-assembling).

@droftarts no, no config-override.

I've tried taking teh test case that clunks and rotating it 120 degrees about the global z-axis, and running taht to see if teh X tower motor then clunks. All teh moves are then teh same relative to X tower as teh clunking case were relative to Z tower. However, when I do that, nothing clunks.

This is my rotated test case:

; test clunking for varying coordinates
; rotated 120 degrees about Z

G1 X56.292 Y32.500 F9000
G4 P100
G1 X43.292 Y55.017

G4 S3

G1 X56.292 Y32.500 F9000
G4 P100
G1 X42.792 Y55.883

G4 S3

G1 X56.292 Y32.500 F9000
G4 P100
G1 X43.292 Y55.017

G4 S3

G1 X56.292 Y32.500 F9000
G4 P100
G1 X42.792 Y55.883

G4 S3

@Phaedrux it's on the Z-tower motor, regardless of which physical motor or which driver that is. I've tried three different motors and four of the drivers on the 6HC board, in various combinations, whatever is defined as Z-tower motor clunks. The motors and drivers that clunk when they are Z do not clunk when they are X or Y.

@droftarts I've tried playing with accelerations, and there's a clear correlation, but not a helpful one (not one that lets me avoid the clunk).

To recap: with accelerations = 1200, at Y=-65, it doesn't clunk for movements to X=12 to X=26 inclusive, but does for all other coordinates.

I've tried various other accelerations and there is clearly a correlation. This is maximum (orange) clunk-free movement and minimum (blue) clunk-free movement against acceleration. So no clunk between the lines, but clunks outside them.

(at A = 300 I can't detect any movement at all at the lower limit, clunking or not)

I note that you refer to bearings sticking - I have none, the motor clunks with nothing connected, so I'm confident it's not mechanics-related (i.e. not bearings, belts, interference, etc).

I've taken a video to show the difference between clunk and noclunk - there's no mistaking whether it clunks or not, the video is playing a move to 26, then one to 27, then one to 26, then one to 27. This is with the original 1200 acceleration where 27 clunks and 26 does not: https://vimeo.com/955477735

; test clunking for varying coordinates

G1 X0.00 Y-65 F9000 
G4 P100
G1 X26 Y-65

G4 S3

G1 X0.00 Y-65 F9000 
G4 P100
G1 X27 Y-65

G4 S3

G1 X0.00 Y-65 F9000 
G4 P100
G1 X26 Y-65

G4 S3

G1 X0.00 Y-65 F9000 
G4 P100
G1 X27 Y-65

G4 S3

@droftarts thanks. I'm out of reach of the machine for a couple of days, so it will be a little while. I don't think you'd miss the clunk if it occurred - it's enough to make the print head visibly quiver on my printer.

I'm using code such as:

G1 X0.00 Y{var.yval} F9000
G4 P100
G1 X{var.xval} Y{var.yval}

wrapped in a loop altering xval or yval.
The clunk happens at the end of G4 or start of the second move (which I find slightly odd, because it means where the move ends affects the behaviour at the start of the move).

This is what I've tested so far (xval across the page 5 to 99 and yval down the page -40 to -99). So far, if a given yval value clunks, it clunks at the same xval values, being 5 to 11 and 27 to 99 inclusive. Red is a clunk, blue is no clunk, white is untested.

@droftarts Hello. 3.5.2-rc.1 also clunks, and in all the tests I've redone it clunks or not-clunks for teh same coordinates as 3.5.1.

@achrn said in delta Z motor goes clunk, regardless of motor or driver:

It clunks at whatever X coordinate is in the second move, as long as it is enough that the motor moves.

Ha! That's not true.

G1 X-5.00 Y-64.00 clunks
G1 X-6.00 Y-64.00 clunks
X-7 to -11 all clunk

G1 X-12.00 Y-64.00 does not clunk
X-13 to -26 all do not clunk

G1 X-27.00 Y-64.00 clunks
-28 to -69 all clunk

The pattern is same for positive X numbers, i.e. G1 X5.00 Y-64.00 clunks, G1 X12.00 Y-64.00 does not clunk, G1 X27.00 Y-64.00 clunks etc. all the way up to X99

@o_lampe thanks for thoughts. Yes, 64,64 (with any combination of signs) is well within the bed. Bed is 150 radius, with 0,0 at the centre and standard 120 degree spaced towers.

It clunks at whatever X coordinate is in the second move, as long as it is enough that the motor moves. That is, because this is the Z motor at X=0 it isn't actually turning. If the second move is G1 X-1.00 Y-64.00 there is no clunk, but the motor doesn't move at all (it's a theoretical move of less than a quarter of a microstep). If it's G1 X-5.00 Y-64.00 (which is 5.8 microsteps of the motor - I don't know whether that will actually apply 5 or 6) it clunks (though more weakly).

I've also found it clunks for Y= +/- 32 but not for Y= +/- 16 or Y= +/- 128. I'm going to do some more investigation about what coordinates trigger a clunk.

It clunks for any value of Z, whether Z is specified or not, and indeed for any motor position - if I home it to a random position (i.e. so the physical position of the motors is not what they would be when properly homed) it still clunks at the same coordinates.

Odder and odder

This clunks (consistently) between the two moves:

; this does clunk
G1 X0.00 Y-64.00 F9000
G4 P100
G1 X-64.00 Y-64.00

This does not clunk:

; this does not clunk
G1 X0.00 Y-63.00 F9000
G4 P100
G1 X-64.00 Y-63.00

nor does this:

G1 X0.00 Y-64.00 F9000
G4 P100
G1 X-64.00 Y-63.00

I have a linear delta. It has started to go clunk - it behaves exactly as if the head has snagged on something then jumped free. There's a 'clunk' from the Z motor, the head jolts and visibly vibrates and the belts thrummm. It happens consistently at the same points in a bed mesh probing, always on the X=0 line, after the probe, i.e. the head dips, touches, rises, then just as the head starts to move to the next position it goes clunk and the printer shakes. It doesn't matter what stepper or what driver, it's always the Z motor that clunks.

I am very perplexed and would welcome suggestions.

If I program the track the head follows without the pauses and dips to the bed it doesn't happen, but it does if I put a pause in at each point, i.e. this will clunk just as it leaves X0 Y-64

G1 X128.00 Y-64.00 F9000 
G4 P400 
G1 X64.00 Y-64.00 F9000 
G4 P400 
G1 X0.00 Y-64.00 F9000 
G4 P400 
G1 X-64.00 Y-64.00 F9000 
G4 P400 

this will not clunk:

G1 X128.00 Y-64.00 F9000 
G1 X64.00 Y-64.00 F9000 
G1 X0.00 Y-64.00 F9000 
G1 X-64.00 Y-64.00 F9000 

It clunks even if there is no mechanics connected, i.e. just the motors with drive pulleys - no belts on any pulley, no movement going on, no torque (beyond inertia of the rotor).

It clunks for the Z motor on any driver (I've tried motors variously on 0.1, 0.2, 0.3 and 0.5). If I put the Y motor on those drivers the Y motor does not clunk. If I swap the steppers round it's the Z motor that clunks, regardless off which physical stepper is connected as Z (I've tried three) or which driver is driving it.

Swapping cables makes no difference.

I've put a completely different spare motor on several drivers and configured the board to believe that's the Z motor and it still clunks. In fact, this is the easiest way to detect it - if I hold the motor as it runs, I feel it kick with each clunk (but that might be specific to me - my hearing is very poor).

So it's not the physical motor (I've tried three physical motors, all are fine when they are the Y motor and clunk when they are the Z motor).

It's not the driver (0.1 and 0.2 don't clunk when they are driving the Y motor but do clunk when they are driving the Z motor) 0.3 and 0.5 also clunk when driving the Z motor for at least two different motors, but I haven't tried them being Y.

I don't remember when it started, it seems to have got worse recently, but I've been fettling things recently trying to figure out what is clunking and I might have just made it louder by tightening belts and opening up the enclosure etc.

I haven't made apparently significant (e.g. relating to the movement parts) config.g changes to trigger it, but I've done a lot of swapping drivers and motors around investigating what causes it.

It's MB6HC (with toolboard) in SBC mode (Pi 4) running bookworm DuetPi and 3.5.1 firmware. It also clunks with 3.4.2 firmware and an older DuetPi.

config.g:

; Configuration file for Duet 3 (firmware version 3)
; initially generated by RepRapFirmware Configuration Tool v3.1.4 on Thu Sep 17 2020 20:49:45
; but subsequently significantly modified variously
; this for firmware 3.5.1

; initial pause for power and CAN bus to stabilise
G4 S2

; General preferences
M550 P"Delta"                                 ; set printer name
G90                                           ; send absolute coordinates
M83                                           ; relative extruder moves

; geometrical config
; M665 = diagonal rod length, delta radius, homed height, printable radius, tower pos corrections
; M665 L360.250:360.250:360.250 R184.819 H538.341 B150.0 X-0.227 Y0.223 Z0.000  ; old 55mm centres effector
M665 L360.250:360.250:360.250 R177.754 H520.261 B150.0 X-0.166 Y0.337 Z0.000  ; new 80mm centres effector
; note, with this geometery max height reachable over entire bed area (radius 150) = 470
M666 X0.101 Y0.027 Z-0.128 A0.00 B0.00        ; endstop adjustments

; Drives
M569 P0.0 S0                                  ; physical drive 0.0 goes backwards
M569 P0.1 S0                                  ; physical drive 0.1 goes backwards
M569 P0.2 S0                                  ; physical drive 0.2 goes backwards
M569 P121.0 S0                                ; toolboard (CAN 121) drive 0 goes backwards
M584 X0.0 Y0.1 Z0.2 E121.0                    ; set drive to axis mapping
M350 X16 Y16 Z16 E16 I1                       ; configure microstepping with interpolation
M92 X160.00 Y160.00 Z160.00 E680.00           ; set steps per mm - note XYZ are 400 steps/rev motors
; note extruder steps should notionally be 690 - to be tested (680 is figure from bear)
;M592 D0 A0.0007 B0.0010                       ; configure non-linear extrusion, tbc with new extruder

; Speeds
; jerk at configtool defaults (20 mm/s) but extruder at manuf recommended values
M566 X1200.00 Y1200.00 Z1200.00 E300.00       ; set maximum instantaneous speed changes (mm/min)
M203 X15000 Y15000 Z15000 E7200               ; set maximum speeds (mm/min)
; acceleration (configtool default is 1000 mm/s2) and set extruder to manuf recommended
M201 X1200 Y1200 Z1200 E3000                  ; set accelerations (mm/s^2)
; rated current E3D high-torque motor = 1.68A, x 75% = 1260 mA
; however, motors stay quite cool at that current
; increase current to 85% = 1430 mA
; extruder manufacturer recommended current is 1200 and idle 10%, but cannot set idle per axis
; note E should be 1200, but workaround to a bug requires that at the end of config.g
M906 X1430 Y1430 Z1430 E1000 I30              ; set motor currents (mA) and motor idle percentage
M84 S60                                       ; Stop idle hold after 60 seconds timeout

; Enable on-board accelerometer on the toolboard and/or apply input shaping
;M955 P121.0 I54
M593 P"zvddd" F37

; Axis Limits
M208 Z0 S1                                    ; set minimum Z

; Endstops
M574 X2 S1 P"io6.in"                          ; configure active-high endstop for high end on X via pin io0.in
M574 Y2 S1 P"io1.in"                          ; configure active-high endstop for high end on Y via pin io1.in
M574 Z2 S1 P"io2.in"                          ; configure active-high endstop for high end on Z via pin io2.in

; Z-Probe on CAN bus 121
; note cannot program smart effector via toolboard, so no out port defined
M558 P8 R0.4 C"121.io0.in" H3 F1200 T9000     ; set Z probe type to effector via toolboard and the dive height + speeds
G31 P100 X0 Y0 Z-0.12                         ; set Z probe trigger value, offset and trigger height
M557 R145 S64                                 ; define mesh grid
M376 H25                                      ; taper mesh compensation over first 25mm only

; Heaters
; bed
M308 S0 P"spi.cs1" A"bed" Y"rtd-max31865"     ; configure sensor 0 as PT100 via CS pin spi.cs1
M950 H0 C"out1" Q3 T0                         ; create bed heater output on out1 and map it to sensor 0
; v3.1 tuning: M307 H0 A530 C1330 D21 S1 V0 B0
M307 H0 R0.243 C1212.7 D46.41 S1.0 V0 B0      ; configure bed heater average three runs of M303 H0 S75 
M140 H0 S0                                    ; map heated bed to heater 0
M143 H0 S150                                  ; set temperature limit for heater 0 to 150C - fault at 150
; hotend
; previous: M308 S1 P"spi.cs0" Y"rtd-max31865" A"hotend"  ; hotend was previously PT100 via CS pin spi.cs0
M308 S1 P"121.temp0" A"hotend" Y"thermistor" T100000 B4725 C7.06e-8  ; E3D Revo built-in thermistor
M950 H1 C"121.out0" Q25 T1                    ; create nozzle heater output on toolboard out0 and map it to sensor 1
; v3.1 tuning: M307 H1 A550 C330 D3 S1 V24 B0
; v3.2 tuning: M307 H1 R1.543 C300:200 D4.17 S1.0 V24 B0     ; average of three runs M303 H1 S220
; v3.3 tuning after rebuilding and rewiring effector: M307 H1 B0 R1.642 C245.2:183.2 D4.36 S1.00 V23.9
; v3.4 tuning with E3D revo micro: M307 H1 R4.4 K0.47 D1.48 E1.35 S1.00 B0 V24
; v3.5 tuning with revo via toolboard and diodes in supply: 
M307 H1 R3.90 K0.48:0.85 D1.95 E1.35 S1.00 B0 V24.0 ; average of multiple runs - see spreadsheet
M143 H1 S300                                  ; heater 1 limit 300 (generate heater fault)
; chamber
M308 S2 P"temp1" A"chamber" Y"thermistor" T4701 B4266 C1.048787e-7  ; dangling thermistor
M950 H2 C"out3" T2                            ; create a heater, but not actually anything connected to this output
M141 H2 S101                                  ; set this to be chamber and set initial temperature (101 is effectively a flag - anything over 100 deemed unreal)
M141 S-400                                    ; switch chmaber heater off

; additional temperature sensors
; sensor 3: thermistor in bed heater mat
M308 S3 P"temp0" A"bed_mat" Y"thermistor" T100000 B3950 
; use this as additional overtemperature
M143 H0 S150 P1 T3 A2                         ; turn off heater if mat gets to 150C

; 4,5,6 - toolboard information
; sensor 4: PT1000 just above alu plate
M308 S4 A"tool air" Y"PT1000" P"121.temp1"
; sensor 5: mcu temperature sensor
M308 S5 A"tool processor" Y"mcu-temp" P"121.dummy" 
; sensor 6: overtemperature flag on stepper driver
M308 S6 A"tool drivers" Y"drivers"  P"121.dummy"

; 7,8,9 mainboard information
; sensor 7: thermistor in electronics enclosure
M308 S7 P"temp3" A"6HC air" Y"thermistor" T4701 B4266 C1.048787e-7 
; sensor 8: mcu temperature sensor
M308 S8 A"6HC processor" Y"mcu-temp" 
; sensor 9: overtemperature flag on stepper drivers
M308 S9 A"6HC drivers" Y"drivers" 

; Fans
; print fan is four-wire on toolboard out1
M950 F0 C"!121.out1+out1.tach" Q25000         ; create fan 0 on toolboard out1 and set its frequency
M106 P0 S0 L0.1 B0.5 H-1 C"print"             ; fan initially off, min pwm 0.1, 0.5 second blip, not thermostatic
; hot end fan
; hot end fan is always either on or off so PWM frequency etc. dont much matter
M950 F1 C"121.out2" Q100                      ; create fan 1 on toolboard out2 and set its frequency
M106 P1 S1 H1 T50 C"hotend"                   ; set fan 1 thermostatic control on heater 1 at 50C
; other cooling fans
; both following predominantly controlled by analogue sensors but also set if stepper drivers flag is set
; fan 2 is blowing air into electronics compartment
M950 F2 C"!out4" Q25000                       ; fan 2 is 4-wire noctua on out4 (note inverse for 4-wire to work correctly) tacho not used
M106 P2 S1 L0.25 B0.2 H7:9 T35:40 C"mainb"    ; cooling electronics space thermostatic on sensor 7 35 to 40C
; fan 3 is small centrifugal fan blowing under main board
M950 F3 C"out9" Q100                          ; fan 3 on pin out9 and set its frequency
M106 P3 S1 L0.4 B0.5 H8:9 T50:60 C"underb"    ; fan 3 for cooling mainboard underside thermostatic sensor 8 (mcu temperature) 50 to 60C
; fan 4 is enclosure purge fan
; initially this is hard-coded to start at 35C enclosure temperature
; but daemon.g will override it
M950 F4 C"!out5" Q25000                       ; fan 4 is 4-wire noctua on out5 (note inverse for 4-wire to work correctly) tacho not used - could be '+out5.tach'
M106 P4 S1 L0.25 B0.2 H2 T36:40 C"chamber"    ; fan 4 thermsotatic, narrow band

; other IO etc
; paneldue on io0
M575 P1 S1 B57600                             ; serial channel 1, PanelDue mode w checksum; 57600 baud 

; filament monitoring
M591 D0 P1 C"121.io1.in" S1                   ; enable filament monitoring on toolboard io1, high = filament present
M950 J2 C"121.io2.in"                         ; filament sensor press-button is on different IO set to sensor 2
M581 P2 T2 S1 R2                              ; set up trigger 2 on the press-button (extrudes) 
if !exists(global.t2time)
    global t2time = state.upTime              ; used to memorise nozzle temperature
else
    set global.t2time = state.upTime

; toolboard buttons
M950 J3 C"121.button0"                        ; corner button defined as sensor 3
M581 P3 T3 S1 R2                              ; calls trigger 3 when pressed (when not printing)

; GPIO P1 on io7.out (note, needs to be 4, 5 or 7 as these are only PWM capable outputs)
; although this is servo, define as genral GPIO
M950 P1 Q50 C"io7.out"                        ; create gpio 1
M42 P1 S0.025                                 ; set to blades closed

; GPIO P2 used to reset attached pi 
M950 P2 C"io8.out"                            ; gpio 2 set to io8
M42 P2 S1                                     ; that gpio set high
; M42 P2 S0 will shut down pi via. GPIO header

; 24V power control (only enabled for drives and heaters)
; note toolboard gets power from either 12V or 24V (diodes)
M81 C"pson"                                   ; set up power pin, power off

; system to memorise settings and filament parameters
if !exists(global.nozt)
    global nozt = -1                          ; used to memorise nozzle temperature when pausing
if !exists(global.filament)
    global filament = ""                      ; this will be name of filament
if !exists(global.filChangeT)
    global filChangeT = 0                     ; this will be the nozzle temperature for a filament change
if !exists(global.filWeight)
    global filWeight = 0                      ; this will be teh weight of filament on spool
M98 P"0:/sys/setfilament.g"                   ; enable whatever was last recorded

; Define tool
M563 P0 S"Nozzle" D0 H1 F0                    ; define tool 0
G10 P0 X0 Y0 Z0                               ; set tool 0 axis offsets
G10 P0 R0 S0                                  ; set initial tool 0 active and standby temperatures to 0C
M207 S1.5 F7200 Z0.2                          ; set typical retract
T0                                            ; select first tool

; putting this here is a temnporary workaround - see https://forum.duet3d.com/post/338869
M906 E1200

@oliof It said "File stop.g is not only run when a print completes."

It has been corrected to "File stop.g is now only run when a print completes."

What firmware version?

There's a known bug in 3.5.1 which makes the first LED green, but I don't recall it being reported on a toolboard. https://github.com/Duet3D/RepRapFirmware/issues/996

If it is 3.5.1 your M950 and M150 config lines look very wrong. M950 shoudl have E0 not P0, Q should be 3000000 (probably), M150 should not have Q or D and should have some colour definitions.

droftarts created this issue in Duet3D/RepRapFirmware

closed [Bug]: MB6HC (maybe 6XD too) - LED strips connected to io ports set first LED incorrectly, always green #996

@oliof OK, my mistake. Thanks.

I assume the 'not' in the very next bullet is intended to be 'now'?

Can the 3.5 release notes highlight that stop.g runs automatically now at the end of a print job, regardless of M0 or not. It has caused me some aggravation and I've eventually found the italics note at https://docs.duet3d.com/User_manual/Reference/Gcodes#m0-stop-or-unconditional-stop but I don't think it is mentioned in the changelog at https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-RC .

Arguably the statement "When the job completes the secondary file stream is closed and commands in the stop.g file for both motion systems are executed by the primary stream." could be interpreted as indicating this, but firstly I read it as being about independent motion streams and not relevant if you only have one, and secondly I'd probably still read it as having an implicit 'if you asked for it' rather than a 'whether you ask for it or not'.

Adding When a print file completes normally then file stop.g is run automatically even if the print file did not end with a M0 command to the changelog would help.

Redefine your endstops on the fly?

Could you set up the 'endstop' for the axis being beam A breaking, run until the endstop triggers, then redefine the endstop for the axis to be beam B breaking and run until the endstop triggers.

For my sand table, which has a true continuous rotation axis, all I do is a very high limit (3,600,000 degrees, so 10,000 revolutions).

The motor steps register is a 32 bit signed value, I believe, so your hard limit is 2.14 E9 steps - that's (probably) a lot more than 500 rotations, so if your 180 degrees 1000 times is an upper limit you're fine. (I will admit I'm assuming there's no rounding errors problems as might occur with the steps register being multiplied by a smaller number - but if operations on it are additions and subtractions, I think it should be OK, and I've never detected any abnormal behaviour from the table).

My sand table has 115,200 steps per rev (400 step motor, x16 microstepping, 1:18 gearing) and that still allows for in excess of 18,640 revolutions. I concluded that while it looked like a fudge, the pragmatic approach was to accept it - it will take weeks of running in the same direction to get to the limit.

You can also throw in some G92 Y{mod(move.axes[1].userPosition,360.0)} periodically, which will 'unwind' the axis. That is, if the machine thinks the axis is at (say) 724 degrees, it will reset it to 4 degrees without actually moving anything. Obviously, if you do this you need to adjust your gcode moves accordingly (unless you're using relative moves exclusively). I tend to just put it in the ending gcode, so the axis doesn't wind up from one job to the next (though if you home every job that won't be needed).

@airscapes My Pi 3 B+ (Rev 1.3) running Raspbian 11 (bullseye) running Chromium 101 connects fine to my Mini 5+ running standalone 3.5.1 (and also to my 6HC running SBC mode 3.5.1 with a DuetPi 12 (bookworm)). I don't think it's anything intrinsic to 3.5.1 for all Pi 3.

I don't often connect to either printer from this Pi (in fact, I don't often use this Pi - I just plugged it in out of interest following your post). It's not very up-to-date (apt says 280 packages can be updated) and it's a fairly default set of packages.

Have you tried some cache-bypassing refreshes (shift-F5, sometimes multiple times) ?