Travel moves are not straight. Is this by design?

janbbeck · 22 Apr 2018, 23:00

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.

3DPMicro · 23 Apr 2018, 00:53

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

janbbeck · 23 Apr 2018, 01:00

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

Danal · 23 Apr 2018, 02:55

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.

janbbeck · 23 Apr 2018, 05:52

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

dc42 · 23 Apr 2018, 08:07

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.

janbbeck · 23 Apr 2018, 08:28

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

janbbeck · 26 Apr 2018, 06:36

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

dc42 · 26 Apr 2018, 11:51

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

janbbeck · 26 Apr 2018, 21:46

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

janbbeck · 26 Apr 2018, 22:08

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

janbbeck · 27 Apr 2018, 01:56

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

dc42 · 27 Apr 2018, 10:23

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.

janbbeck · 27 Apr 2018, 21:28

@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

3DPMicro · 28 Apr 2018, 06:49

Wowzers. That's some serious steps/mm

janbbeck · 28 Apr 2018, 07:29

@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

dc42 · 28 Apr 2018, 08:20

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?

janbbeck · 28 Apr 2018, 10:13

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

dc42 · 28 Apr 2018, 10:19

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

janbbeck · 29 Apr 2018, 23:38

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