Print Buffer pauses



  • Hello All,
    I'm having one heck of a time troubleshooting a problem. The printer will very randomly pause durring the print. It seems as if the gcode buffer is only down to a couple of lines and then it sits idle for a 2-30 seconds before continuing to the next commanded location. The gcode monitor shows a ton of motor phase disconnections for all phases of a bunch of motors. I'm running 2A Nema17 steppers at 1A for noise. The problem is that I can print the exact same part and one time it will come out perfectly and the next it will f-up.
    Also I should mention that when I try to pause and home it doesn't recognize the endstops and smashes everything into everything.
    Problem started when I upgraded to 2.02RC1 but it's still around with RC3.

    Here's M122 diagnostic
    M122
    === Diagnostics ===
    RepRapFirmware for Duet 2 WiFi/Ethernet version 2.02RC3(RTOS) running on Duet WiFi 1.02 or later + DueX5
    Board ID: 08DDM-9FAM2-LW4SD-6JTD6-3SJ6T-1LZVZ
    Used output buffers: 1 of 20 (16 max)
    === RTOS ===
    Static ram: 28532
    Dynamic ram: 99140 of which 0 recycled
    Exception stack ram used: 344
    Never used ram: 3056
    Tasks: NETWORK(ready,400) HEAT(blocked,1184) MAIN(running,3484)
    Owned mutexes:
    === Platform ===
    Last reset 00:27:57 ago, cause: software
    Last software reset at 2018-11-16 11:45, reason: User, spinning module GCodes, available RAM 2932 bytes (slot 3)
    Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
    Error status: 0
    Free file entries: 10
    SD card 0 detected, interface speed: 20.0MBytes/sec
    SD card longest block write time: 0.0ms, max retries 0
    MCU temperature: min 46.5, current 51.3, max 51.5
    Supply voltage: min 24.1, current 24.3, max 24.5, under voltage events: 0, over voltage events: 0
    Driver 0: standstill, SG min/max 0/239
    Driver 1: standstill, SG min/max 0/1023
    Driver 2: standstill, SG min/max 0/1023
    Driver 3: standstill, SG min/max not available
    Driver 4: standstill, SG min/max not available
    Driver 5: standstill, SG min/max not available
    Driver 6: standstill, SG min/max not available
    Driver 7: standstill, SG min/max not available
    Driver 8: standstill, SG min/max not available
    Driver 9: standstill, SG min/max not available
    Expansion motor(s) stall indication: yes
    Date/time: 2018-11-16 12:13:39
    Cache data hit count 4294967295
    Slowest loop: 3.37ms; fastest: 0.07ms
    === Move ===
    Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 234, MaxWait: 2584ms, Underruns: 0, 0
    Scheduled moves: 6, completed moves: 6
    Bed compensation in use: none
    Bed probe heights: 0.000 0.000 0.000 0.000 0.000
    === Heat ===
    Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
    === GCodes ===
    Segments left: 0
    Stack records: 1 allocated, 0 in use
    Movement lock held by null
    http is idle in state(s) 0
    telnet is idle in state(s) 0
    file is idle in state(s) 0
    serial is idle in state(s) 0
    aux is idle in state(s) 0
    daemon is idle in state(s) 0
    queue is idle in state(s) 0
    autopause is idle in state(s) 0
    Code queue is empty.
    === Network ===
    Slowest loop: 14.47ms; fastest: 0.00ms
    Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
    HTTP sessions: 1 of 8

    • WiFi -
      Network state is running
      WiFi module is connected to access point
      Failed messages: pending 0, notready 0, noresp 0
      WiFi firmware version 1.21
      WiFi MAC address 5c:cf:7f:ee:69:8c
      WiFi Vcc 3.35, reset reason Turned on by main processor
      WiFi flash size 4194304, free heap 16792
      WiFi IP address 192.168.1.19
      WiFi signal strength -64dBm, reconnections 0, sleep mode modem
      Socket states: 0 0 0 0 0 0 0 0
      === Expansion ===
      DueX I2C errors 0


  • @jakemestre

    Was that M122 generated when the fault was present?

    If not, run it again when the fault happens. I'd be very interested to know if you see a lot of I2C error as there area few of us experiencing similar issues with Duet plus Duex5.


  • administrators

    I've done a lot of investigation of I2C errors over the past week. One of the issues is that when an I2C protocol error occurs, recovering from that error is difficult or impossible, because the master (the Duet) doesn't know what state the slave (the DueX) is in.

    My suggestions for you and others who have seen similar problems in Duet + DueX systems:

    1. Make sure you have a short, thick ground wire between the VIN terminal blocks of the Duet and the DueX.

    2. Keep the ribbon cable between the two boards short. Use the cable we supply, not a longer one.

    3. Try the 2.02RC4 firmware that I hope to release later today, if it passes my tests.

    4. If all else fails, connect a 1.5K resistor between the TWCK pin and the +3.3V pin, and another between TWD and +3.3V. This improves the signal rise times and reduces the susceptibility to noise. Here is one way to do this without soldering to the board.

    0_1542465902554_2018-11-17 14.44.07.jpg



  • Got the diagnostic from after it started again. I'll update the firmware. The "ground wire" is just a jumper between the Vin's? I'm thinking that Vin directly to ground will not turn out well. lol I'll keep you posted If the pausing is happening again. Thank you so much David for keeping up with this forum and solving so so many problems we didn't even know we had.
    Jake

    M122
    === Diagnostics ===
    RepRapFirmware for Duet 2 WiFi/Ethernet version 2.02RC3(RTOS) running on Duet WiFi 1.02 or later + DueX5
    Board ID: 08DDM-9FAM2-LW4SD-6JTD6-3SJ6T-1LZVZ
    Used output buffers: 1 of 20 (15 max)
    === RTOS ===
    Static ram: 28532
    Dynamic ram: 99212 of which 0 recycled
    Exception stack ram used: 440
    Never used ram: 2888
    Tasks: NETWORK(ready,328) HEAT(blocked,1132) MAIN(running,3476)
    Owned mutexes:
    === Platform ===
    Last reset 46:02:34 ago, cause: power up
    Last software reset at 2018-11-16 11:45, reason: User, spinning module GCodes, available RAM 2932 bytes (slot 3)
    Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
    Error status: 0
    Free file entries: 10
    SD card 0 detected, interface speed: 20.0MBytes/sec
    SD card longest block write time: 234.8ms, max retries 0
    MCU temperature: min 39.2, current 41.1, max 52.0
    Supply voltage: min 24.1, current 24.2, max 24.5, under voltage events: 0, over voltage events: 0
    Driver 0: standstill, SG min/max 0/1023
    Driver 1: standstill, SG min/max 0/1023
    Driver 2: standstill, SG min/max 0/1023
    Driver 3: standstill, SG min/max not available
    Driver 4: standstill, SG min/max 0/1023
    Driver 5: standstill, SG min/max 0/1023
    Driver 6: standstill, SG min/max not available
    Driver 7: standstill, SG min/max 0/216
    Driver 8: standstill, SG min/max 0/266
    Driver 9: standstill, SG min/max not available
    Expansion motor(s) stall indication: yes
    Date/time: 2018-11-18 13:00:50
    Cache data hit count 4294967295
    Slowest loop: 174.79ms; fastest: 0.07ms
    === Move ===
    Hiccups: 1, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 120, MaxWait: 71306433ms, Underruns: 0, 1
    Scheduled moves: 6, completed moves: 6
    Bed compensation in use: none
    Bed probe heights: 0.000 0.000 0.000 0.000 0.000
    === Heat ===
    Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
    Heater 0 is on, I-accum = 0.0
    Heater 2 is on, I-accum = 0.3
    === GCodes ===
    Segments left: 0
    Stack records: 3 allocated, 0 in use
    Movement lock held by null
    http is idle in state(s) 0
    telnet is idle in state(s) 0
    file is idle in state(s) 0
    serial is idle in state(s) 0
    aux is idle in state(s) 0
    daemon is idle in state(s) 0
    queue is idle in state(s) 0
    autopause is idle in state(s) 0
    Code queue is empty.
    === Network ===
    Slowest loop: 266.71ms; fastest: 0.00ms
    Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
    HTTP sessions: 1 of 8

    • WiFi -
      Network state is running
      WiFi module is connected to access point
      Failed messages: pending 0, notready 0, noresp 0
      WiFi firmware version 1.21
      WiFi MAC address 5c:cf:7f:ee:69:8c
      WiFi Vcc 3.36, reset reason Turned on by main processor
      WiFi flash size 4194304, free heap 16792
      WiFi IP address 192.168.1.19
      WiFi signal strength -64dBm, reconnections 0, sleep mode modem
      Socket states: 0 0 0 0 0 0 0 0
      === Expansion ===
      DueX I2C errors 729882

  • administrators

    Your M122 report shows a lot of I2C errors, so this confirms it is a problem with the I2C communication between the Duet and the DueX5.

    The ground wire is the wire between the ground (negative) sides of the VIN terminal blocks. See https://duet3d.dozuki.com/Wiki/Duex2_and_Duex5_Features#Section_Wiring.


 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.