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

  • 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
    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

  • 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

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

  • 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..?


  • @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.

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

  • Moderator

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

  • @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.

  • 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.


    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.

  • administrators

    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.

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

  • administrators

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

  • @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!

Log in to reply