Solved 3.2 Jerking motion Duet3 + SBC
This post is a continuation of what I believe to be this issue:
I have a 5-axis machine with linear axes X,Y,Z and rotational axes A,B running rrf3.2 stable.
When sending a series of small segment, commands to the machine, a loud audible clunk happens intermittently.
The types of movements that create the clunks are simultaneous X,Y + A(rotational) moves.
Here is video:
As you can see, it does not seem as if the machine loses steps, just starts/stops so quickly as to create a jolt.
Changing the M595 movement queue length (I have tried several values from 5 to 1000) only worsens this behavior to the point where steps are lost and even more clunks happen.
Here is my config.g:
;CNC Mode M453 ;Name M550 P"tristan-painting-machine" ;Brake Pins M950 P2 C"out8" M950 P1 C"out7" ;Drivers M569 P0.0 S0 I1 M569 P0.1 S0 I1 M569 P0.2 S1 I1 M569 P0.3 S0 I1 M569 P0.4 S0 I1 M569 P121.0 S1 I1 ;Driver Mapping M584 X0.3 Y0.1:0.2 Z0.0 S0 R0 P3 M584 A0.4 B121.0 S1 R1 P5 M584 U0.2 P5 ;Current M906 X2000 Y3750 Z2000 U3750 A1750 B1500 I100 ;Microstepping M350 X16 Y16 Z16 U16 A16 I1 ;Steps Per MM M92 X80 Y80 Z80 U80 A46.1062140618 B26.6666 ;Instantaneous Speed Change M566 X500 Y500 Z500 U500 A500 ;Max Speeds M203 X13000 Y13000 Z13000 U6000 A40000 B40000 ;Max Acceleration M201 X750 Y750 Z500 U750 A2000 B2000 ;Disable Idle Current Reduction M84 S0 M917 Y100 ;Probe M558 P9 C"!^121.io0.in" H200 F400 T2000 I1 ;Limits M208 X0 Y-1360 Z-145 A-72000 B-101.4 S1 M208 X1242 Y0 Z0 A72000 B230 S0 ;Servos M950 S3 C"io4.out" M950 S4 C"io5.out" ;Endstops M574 U1 S1 P"!io6.in" M574 Y1 S1 P"!io1.in" M574 X1 S1 P"!io8.in" M574 Z1 S1 P"io7.in" M574 A1 S1 P"io0.in" ;Head Endstop M574 B1 S1 P"121.io2.in" ;Tool 0 M563 P0 S"Probe" ;Tool 1 M563 P1 S"1/4 Flat Brush" ;Tool 2 M563 P2 S"5/8 Flat Brush" ;Allow Movement M564 S0 H0
M122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.2 running on Duet 3 MB6HC v1.01 or later (SBC mode) Board ID: 08DJM-956L2-G43S8-6J9D6-3S46R-KU2AD Used output buffers: 1 of 40 (14 max) === RTOS === Static ram: 149788 Dynamic ram: 63020 of which 52 recycled Never used RAM 145972, free system stack 132 words Tasks: Linux(ready,83) HEAT(blocked,353) CanReceiv(blocked,881) CanSender(blocked,352) CanClock(blocked,352) TMC(blocked,19) MAIN(running,1265) IDLE(ready,19) Owned mutexes: HTTP(MAIN) === Platform === Last reset 00:40:24 ago, cause: software Last software reset at 2021-01-08 22:10, reason: User, none spinning, available RAM 145852, slot 1 Software reset code 0x0012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task Linu Freestk 0 n/a Error status: 0x00 Aux0 errors 0,0,0 Aux1 errors 0,0,0 MCU temperature: min 42.5, current 43.8, max 44.2 Supply voltage: min 23.5, current 23.9, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.0, current 12.1, max 12.1, under voltage events: 0 Driver 0: position 54723, standstill, reads 54250, writes 55 timeouts 0, SG min/max 0/1023 Driver 1: position -56731, standstill, reads 54217, writes 88 timeouts 0, SG min/max 0/733 Driver 2: position -4137, standstill, reads 54214, writes 91 timeouts 0, SG min/max 0/837 Driver 3: position 4495, standstill, reads 54230, writes 75 timeouts 0, SG min/max 0/687 Driver 4: position -1200, standstill, reads 54226, writes 79 timeouts 0, SG min/max 0/294 Driver 5: position 0, standstill, reads 54295, writes 11 timeouts 0, SG min/max 0/0 Date/time: 2021-01-08 22:51:03 Slowest loop: 152.89ms; fastest: 0.03ms === Storage === Free file entries: 10 SD card 0 not detected, interface speed: 37.5MBytes/sec SD card longest read time 0.0ms, write time 0.0ms, max retries 0 === Move === DMs created 125, maxWait 752461ms, bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves 630, completed moves 630, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 2, 11], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters = -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 === GCodes === Segments left: 0 Movement lock held by null HTTP* is doing "M122" in state(s) 0 Telnet is idle in state(s) 0 File* is idle in state(s) 0 USB is idle in state(s) 0 Aux is idle in state(s) 0 Trigger* is idle in state(s) 0 Queue* is idle in state(s) 0 LCD is idle in state(s) 0 SBC is idle in state(s) 0 Daemon is idle in state(s) 0 Aux2 is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === CAN === Messages queued 80, send timeouts 0, received 50, lost 0, longest wait 1ms for reply type 6036, free buffers 48 === SBC interface === State: 4, failed transfers: 0 Last transfer: 1ms ago RX/TX seq numbers: 21479/21479 SPI underruns 0, overruns 0 Number of disconnects: 0, IAP RAM available 0x2c8a8 Buffer RX/TX: 0/0-0 === Duet Control Server === Duet Control Server v3.2.0 Code buffer space: 4096 Configured SPI speed: 8000000 Hz Full transfers per second: 35.91 Maximum length of RX/TX data transfers: 3596/1696
M98 P"config.g" returns a green: M98 P"config.g" in the console.
Here also a file which produces many clunks (which is running in video):
It is hard to see which lines of the code cause the issue as I believe it is a problem with sending small segments.
I have had this issue since upgrading to the first of the 3.2 betas, but it does not occur 3.1.1.
I've had to go back to 3.1.1.
Maybe my use case is too obscure for anyone to weigh in?
I will give this a try in standalone mode tomorrow if that would help debug at all, but I really do prefer using the Pi.
Yes, it would help to know whether the same issue occurs in standalone mode.
PS - some types of issue with very small segments (e.g. never reaching the requested speed) can be ameliorated in firmware 3.3 by extending the size of the movement queue using the new M595 command; although I doubt that will help in this case.
@dc42 I can confirm that sending M595 P100 on the 3.3 beta firmware has resolved this issue.