Travel moves are not straight. Is this by design?



  • Hi, I am using the DeutWifi to control linear servo motors for my X and Y axes. Often times the travel moves, but not the printing moves are not the straight lines as shown in the slicer, but staircase like steps. Is this something the Duet is doing or should I look for the cause somewhere else?

    Thanks for taking the time to read this.



  • the slicer produces the gcode and the servos should do as commanded. Do you have something like "avoid crossing parameters" selected? this will create weird, non print moves. if you can identify the part of the gcode program where this taking place you should be able the see the non linear moves. Could possibly be something else. Do your servos have a controller of some sort



  • @3dpmicro
    Thank you for your reply. The moves show as straight red lines in Simplify3d. The servo drives take step/direction signals in. I would suspect the servos first, if it wasn't just travel moves (and just long ones) showing this behaviour. I figured I would ask here first before going off on a wild goose chase...



  • I would suggest viewing the G-Code in an online simulator. I mostly use this one:

    https://ncviewer.com/

    If you google "online gcode viewer", there are several good ones.



  • @danal Thank you for that excellent suggestion. I was able to verify with ncviewer that the gcode commands linear moves, just like Simplify3D claims it does.


  • administrators

    Which firmware version are you using? The Duet switches to double, quad or octal stepping when the step rate is high, to reduce the computation load on the processor. Older firmwares generate the 2, 4 or 8 step- pulses in a bunch, which is fine for ordinary stepper motors at high speeds because the drivers can't change the current that fast anyway. However, some servo drives are more sensitive to changes in frequency. So in version 1.21 firmware a change was made to avoid bunches of step pulses.

    Therefore, if you are using firmware older than 1.21, please try version 1.21 or 2.0beta2.



  • @dc42 My firmware is 1.19. Thanks for the suggestion to upgrade and the explanation of the possible cause.



  • @dc42 I did install 2.0 beta2. The staircase behaviour is still there.

    Also, my test print freezes at the same spot every time. It actually causes the Duet to reboot it seems. The LCD display only displays a single message - the obtaining of a new DCHP address. The axes are unhomed and the heaters are all off.

    I had the occasional freeze before upgrading too. But it was erratic. The model that freezes all the time never ran on 1.19

    Is there a command to send messages to the LCD screen console? That would make it easier to track down the place in the gcode that causes the problem....
    edit: I found M114. Will use that.


  • administrators

    If you think the Duet is rebooting, please run M122 after it has rebooted and post the results here.



  • @dc42 Sure. I had already powered off the system, but there is a line for "last software reset" so maybe this is useful. I am starting a new print to get it stuck again, and will then do another M122 taken fresh from the reboot and post it here as well:

    M122
    === Diagnostics ===
    RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS)beta2 running on Duet WiFi 1.02 or later
    Board ID: 08DGM-95BNL-MGPSN-6J1FD-3S86L-K1XZX
    Used output buffers: 1 of 20 (10 max)
    === RTOS ===
    Static ram: 28484
    Dynamic ram: 95992 of which 0 recycled
    Exception stack ram used: 308
    Never used ram: 6288
    Task NETWORK ready, free stack 448
    Task HEAT blocked, free stack 1204
    Task MAIN running, free stack 3808
    === Platform ===
    Last reset 00:00:20 ago, cause: power up
    Last software reset at 2018-04-26 19:28, reason: User, spinning module GCodes, available RAM 6176 bytes (slot 3)
    Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0041f000, BFAR 0xe000ed38, SP 0xffffffff
    Error status: 0
    Free file entries: 10
    SD card 0 detected, interface speed: 20.0MBytes/sec
    SD card longest block write time: 0.0ms
    MCU temperature: min 21.9, current 29.8, max 30.4
    Supply voltage: min 24.3, current 24.5, max 24.6, under voltage events: 0, over voltage events: 0
    Driver 0: standstill, SG min/max not available
    Driver 1: standstill, SG min/max not available
    Driver 2: standstill, SG min/max not available
    Driver 3: standstill, SG min/max not available
    Driver 4: standstill, SG min/max not available
    Date/time: 2018-04-27 06:36:29
    Slowest main loop (seconds): 0.004038; fastest: 0.000068
    === Move ===
    MaxReps: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 240, MaxWait: 0ms, Underruns: 0, 0
    Scheduled moves: 0, completed moves: 0
    Bed compensation in use: mesh
    Bed probe heights: 0.000 0.000 0.000 0.000 0.000
    === Heat ===
    Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
    Heater 1 is on, I-accum = 0.0
    === 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 ===
    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 2c:3a:e8:0b:16:3b
      WiFi Vcc 3.34, reset reason Turned on by main processor
      WiFi flash size 4194304, free heap 17264
      WiFi IP address 172.30.1.15
      WiFi signal strength -71dBm, reconnections 0, sleep mode modem
      Socket states: 0 0 0 0 0 0 0 0
      === Expansion ===


  • @dc42 Ok, here is the log right after reboot due to failure. Watchdog timeout:

    M122
    === Diagnostics ===
    RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS)beta2 running on Duet WiFi 1.02 or later
    Board ID: 08DGM-95BNL-MGPSN-6J1FD-3S86L-K1XZX
    Used output buffers: 1 of 20 (10 max)
    === RTOS ===
    Static ram: 28484
    Dynamic ram: 95992 of which 0 recycled
    Exception stack ram used: 324
    Never used ram: 6272
    Task NETWORK ready, free stack 476
    Task HEAT blocked, free stack 1204
    Task MAIN running, free stack 3800
    === Platform ===
    Last reset 00:00:43 ago, cause: software
    Last software reset at 2018-04-27 06:57, reason: Watchdog timeout, spinning module Platform, available RAM 5652 bytes (slot 0)
    Software reset code 0x4050 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x1441f014, BFAR 0xe000ed38, SP 0x2001febc
    Stack: 00000007 00416748 81000027 fffeace0 00000000 00000000 00415c41 00435f08 21005027 00415b0a 61000027 2000ca30 fffffff1 00000000 00000000 00000000 200130b0 2000ca30 200088da ffffffff 20013738 20013b00 00000000 2000c900
    Error status: 0
    Free file entries: 10
    SD card 0 detected, interface speed: 20.0MBytes/sec
    SD card longest block write time: 0.0ms
    MCU temperature: min 38.3, current 40.8, max 41.8
    Supply voltage: min 24.3, current 24.4, max 24.7, under voltage events: 0, over voltage events: 0
    Driver 0: standstill, SG min/max not available
    Driver 1: standstill, SG min/max not available
    Driver 2: standstill, SG min/max not available
    Driver 3: standstill, SG min/max not available
    Driver 4: standstill, SG min/max not available
    Date/time: 2018-04-27 06:58:46
    Slowest main loop (seconds): 0.004691; fastest: 0.000068
    === Move ===
    MaxReps: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 240, MaxWait: 0ms, Underruns: 0, 0
    Scheduled moves: 0, completed moves: 0
    Bed compensation in use: mesh
    Bed probe heights: 0.000 0.000 0.000 0.000 0.000
    === Heat ===
    Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
    Heater 1 is on, I-accum = 0.0
    === 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 ===
    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 2c:3a:e8:0b:16:3b
      WiFi Vcc 3.34, reset reason Turned on by main processor
      WiFi flash size 4194304, free heap 17184
      WiFi IP address 172.30.1.15
      WiFi signal strength -71dBm, reconnections 0, sleep mode modem
      Socket states: 0 0 0 0 0 0 0 0
      === Expansion ===


  • One more update: I just had it happen when pressing the "run mesh grid compensation button":

    M122
    === Diagnostics ===
    RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS)beta2 running on Duet WiFi 1.02 or later
    Board ID: 08DGM-95BNL-MGPSN-6J1FD-3S86L-K1XZX
    Used output buffers: 3 of 20 (9 max)
    === RTOS ===
    Static ram: 28484
    Dynamic ram: 95992 of which 0 recycled
    Exception stack ram used: 324
    Never used ram: 6272
    Task NETWORK ready, free stack 476
    Task HEAT blocked, free stack 1204
    Task MAIN running, free stack 3864
    === Platform ===
    Last reset 00:00:53 ago, cause: software
    Last software reset at 2018-04-27 10:48, reason: Watchdog timeout, spinning module Platform, available RAM 5756 bytes (slot 2)
    Software reset code 0x4050 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x1441f014, BFAR 0xe000ed38, SP 0x2001ff24
    Stack: 00415c41 00415b4c 61000027 00039884 00000000 0000000e 2000be18 00000004 a5a5a5a5 00000000 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 00435e97 00000001 20008618 00000000 ffffffe1 00000001 20006460 10000000 00000001 00000101
    Error status: 0
    Free file entries: 10
    SD card 0 detected, interface speed: 20.0MBytes/sec
    SD card longest block write time: 0.0ms
    MCU temperature: min 38.4, current 40.9, max 42.0
    Supply voltage: min 24.3, current 24.4, max 24.6, under voltage events: 0, over voltage events: 0
    Driver 0: standstill, SG min/max not available
    Driver 1: standstill, SG min/max not available
    Driver 2: standstill, SG min/max not available
    Driver 3: standstill, SG min/max not available
    Driver 4: standstill, SG min/max not available
    Date/time: 2018-04-27 10:53:32
    Slowest main loop (seconds): 0.004124; fastest: 0.000067
    === Move ===
    MaxReps: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 240, MaxWait: 0ms, Underruns: 0, 0
    Scheduled moves: 0, completed moves: 0
    Bed compensation in use: mesh
    Bed probe heights: 0.000 0.000 0.000 0.000 0.000
    === Heat ===
    Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
    Heater 1 is on, I-accum = 0.0
    === 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 ===
    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 2c:3a:e8:0b:16:3b
      WiFi Vcc 3.34, reset reason Turned on by main processor
      WiFi flash size 4194304, free heap 17264
      WiFi IP address 172.30.1.30
      WiFi signal strength -65dBm, reconnections 0, sleep mode modem
      Socket states: 0 0 0 0 0 0 0 0
      === Expansion ===

  • administrators

    Thanks for that last report. I suspect that both issues are caused by using a combination of high steps/mm (resulting in high step rates) along with extended step pulse timing for the external stepper drivers. What steps/mm (M92) and driver timings (M560) have you set in config.g?

    Please execute a few high speed travel moves, then run M122 and report the MaxReps figure.



  • @dc42 here the results:

    M92
    Steps/mm: X: 1000.000, Y: 5120.000, Z: 5120.000, E: 2400.000:2400.000:420.000:420.000:420.000:420.000:420.000:420.000:420.000

    M560 is not set in config.g

    MaxReps: 115137, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 216, MaxWait: 788103523ms, Underruns: 0, 18



  • Wowzers. That's some serious steps/mm



  • @3dpmicro Yeah. Linear motors with 1 micron or better feedback on the X and Y. They can also move wickedly fast....
    https://www.youtube.com/watch?v=lq-wMWWwWzQ


  • administrators

    Yes, your MaxReps figure is way too high, you should try to keep it below 100. Your Y steps/mm in particular will cause serious problems. Can you configure your linear motors to use a lower steps/mm? What M569 T parameters do they need?



  • @dc42 Note sure what the timing parameters are they need, but I do know that I can put scaling parameters in for the steps. Adjusting those so that I get 100 steps/mm should be easy.

    Will report back here. Thanks for the help!


  • administrators

    200 steps/mm should be no problem if you don't want to go as low as 100.



  • @dc42 I am happy to report that this seems to have fixed my problems. Gonna do a few more test prints, but so far I think it's solved.

    Thanks for the help!


Locked
 

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