[RRF 3.2-b3] [DUET2-SBC] Jerkiness during print moves

SAtech

Sorry to bring this back up, but after updating to RRF 3.2-b3 I am still observing unwanted jerkiness during print moves. As the print head is moving, it stops for about 50ms at a time randomly, occurring roughly 1-2 times/10s. M122 shows no unusual information:

=== Diagnostics ===
RepRapFirmware for Duet 2 + SBC version 3.2-beta3 running on Duet 2 1.02 or later + SBC (SBC mode)
Board ID: 08DGM-917N9-FLMS4-7JTDG-3SJ6J-9HV4G
Used output buffers: 1 of 24 (21 max)
=== RTOS ===
Static ram: 20636
Dynamic ram: 103772 of which 60 recycled
Never used RAM 5580, free system stack 124 words
Tasks: Linux(ready,79) HEAT(blocked,306) MAIN(running,381) IDLE(ready,19)
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:27:46 ago, cause: software
Last software reset at 2020-11-10 22:45, reason: User, GCodes spinning, available RAM 5580, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task Linu
Error status: 0x00
MCU temperature: min 30.3, current 30.6, max 30.6
Supply voltage: min 23.8, current 23.9, max 24.0, under voltage events: 1, over voltage events: 0, power good: yes
Driver 0: position 27804, ok, SG min/max 0/281
Driver 1: position 1608, ok, SG min/max 0/295
Driver 2: position 8662, ok, SG min/max not available
Driver 3: position 0, ok, SG min/max 0/279
Driver 4: position 0, ok, SG min/max not available
Driver 5: position 0
Driver 6: position 0
Driver 7: position 0
Driver 8: position 0
Driver 9: position 0
Driver 10: position 0
Driver 11: position 0
Date/time: 2020-11-10 23:13:11
Cache data hit count 2641989901
Slowest loop: 1.58ms; fastest: 0.13ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 30.0MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 153, MinFreeDm: 142, MaxWait: 0ms
Bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 19876, completed moves 19837, StepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state 3
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, StepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.6
=== GCodes ===
Segments left: 1
Movement lock held by null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File* is doing "G1 X163.770004 Y147.505005 E-0.137980" 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.
=== SBC interface ===
State: 0, failed transfers: 0
Last transfer: 7ms ago
RX/TX seq numbers: 53001/53003
SPI underruns 0, overruns 0
Number of disconnects: 0, IAP RAM available 0x021ac
Buffer RX/TX: 400/1624-0
=== Duet Control Server ===
Duet Control Server v3.2.0-beta3
File:
Buffered code: G1 X162.728 Y146.619 E-0.07341
Buffered code: G1 X162.510 Y146.265 E-0.08215
Buffered code: G1 X162.298 Y145.707 E-0.11819
Buffered code: G1 X162.209 Y145.116 E-0.11819
Buffered code: G1 X162.248 Y144.521 E-0.11819
Buffered code: G1 X162.391 Y144.024 E-0.10221
Buffered code: G1 E-0.05000 F2400.00000
Buffered code: G1 X147.391 Y145.007 F14400.000
Buffered code: G1 E1.00000 F2400.00000
Buffered code: G1 F1500
Buffered code: M204 P1000
Buffered code: G1 X147.362 Y145.355 E0.01088
Buffered code: G1 X147.295 Y145.666 E0.00993
Buffered code: G1 X147.170 Y146.010 E0.01138
Buffered code: G1 X146.903 Y146.451 E0.01605
Buffered code: G1 X146.818 Y146.555 E0.00418
Buffered code: G1 X146.549 Y146.826 E0.01188
Buffered code: G1 X146.123 Y147.115 E0.01605
Buffered code: G1 X145.644 Y147.307 E0.01605
Buffered code: G1 X145.136 Y147.392 E0.01605
Buffered code: G1 X144.621 Y147.367 E0.01605
Buffered code: G1 X144.489 Y147.342 E0.00418
Buffered code: G1 X144.000 Y147.179 E0.01605
Buffered code: G1 X143.557 Y146.916 E0.01605
Buffered code: G1 X143.283 Y146.673 E0.01138
Buffered code: G1 X143.080 Y146.428 E0.00994
Buffered code: G1 X142.883 Y146.128 E0.01116
Buffered code: G1 X142.694 Y145.667 E0.01551
==> 1296 bytes
Pending code: G1 X142.606 Y145.171 E0.01570
Code buffer space: 2232
Configured SPI speed: 8000000 Hz
Full transfers per second: 31.10
File /opt/dsf/sd/gcodes/retraction_calibration_0.2mm_PETG__10m.gcode is selected, processing

I plan to get the DCS log and in-depth USB log soon.

Also, I will try in standalone mode as well, hopefully tomorrow.

Edit: added config.g

SAtech

I can confirm that this does NOT occur in standalone mode. I have tested the same file in SBC mode and in standalone mode and get no jerkiness in standalone.

@dc42 @chrishamm anything else I can do to help?

Edit: DCS log coming soon

TypQxQ

Try turning off all bed compensations with M561. I am having similar problems with it enabled.

oozeBot

Are the video's I posted in my currently last post of this thread what you are describing?

edit I am using a Duet3+RPi.. I see you have a Duet2. However, this might be the same issue as it is new to 3.2B3..?

https://forum.duet3d.com/topic/19633/duet-3-rpi-toolboard-on-3-2b3-g29-fails/59

SAtech

@oozeBot @TypQxQ No, what I am describing is different. I can only describe it almost like if your jerk is set too low on curved segments, only that it happens randomly and not only on curves, if that makes any sense.. It doesn't loose steps, but it's as if the controller hangs for a bit. I'll see if I can get a video.

I think what you both are experiencing is similar, and I have also experienced it way back on 3.1.1. If my travel speed was too high, it would loose steps exactly as in your videos. Haven't tried it without compensation, I should try that.

TypQxQ

@SAtech It does sound like what I hear at but can barely see at the time mark 00:08 in this video https://youtu.be/XvvZuclWqyU and at 00:05 in https://youtu.be/pry1-_EBak0

Phaedrux

@SAtech said in [RRF 3.2-b3] [DUET2-SBC] Jerkiness during print moves:

under voltage events: 1

How do you have the Duet and SBC powered?

SAtech

@Phaedrux I have separate 5v and 24v power supplies with the grounds connected. The pi and the 5V_EXT pins of the duet are powered by the 5v supply, which is always on. The duet switches the 24v power supply via a relay.

I believe that undervoltage event is due to me switching off the 24v supply once since the duet was last reset.

SAtech

Alright, I've managed to capture a DCS log of an affected print. It seems like an underrun of the movement buffer, but it also happens sometimes in the middle of travel moves, so I'm not really sure there.

dsf_log.txt

Also, a picture to better show what I mean.

All those little blobs are what I'm talking about. They're caused by the print head dwelling for a bit at that location.

chrishamm

Thanks for the DCS log, I could confirm that RRF is running out of G-codes. I've got an idea why this is caused and will test a potential fix shortly.

SAtech

@chrishamm I actually am using a Duet2 an SBC mode, but would be happy to test.

chrishamm

@SAtech Ahh okay, here's a new build for the Duet 2 in SBC mode: https://pkg.duet3d.com/Duet2Firmware_2SBC.bin

SAtech

@chrishamm All appears to be good. ~~I'll update when the current print finishes.~~

Update: Print finished successfully and with no unwanted artifacts. That seems to have solved it!