Travel moves are not straight. Is this by design?

janbbeck

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

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

@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

Wowzers. That's some serious steps/mm

janbbeck

@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

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

@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

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

janbbeck

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

janbbeck

@dc42 No more crashes. But I still have the staircase behavior. It has only happened on travel moves, but I don't know if that is a coincidence with them being faster and longer moves. Is there any easy way of finding out whether the Duet is sending the pulses out as bunches?

dc42

Can you check your MaxReps fixture again after a few travel moves?

janbbeck

@dc42 maxreps is typically this now:
MaxReps: 4, StepErrors: 0, LaErrors: 0, FreeDm: 231, MinFreeDm 120, MaxWait: 721129289ms, Underruns: 0, 0

dc42

That sounds OK. It looks like at worst, when some interrupt (probably a tick interrupt) occurs 3 pulses become overdue, so it sends a bunch of 4 pulses when the interrupt completes. Hence MaxReps = 4. This will probably happen one per millisecond.

janbbeck

@dc42 Ok, I take that to mean that I should look at the servo drive causing the behavior, right?

dc42

@janbbeck said in Travel moves are not straight. Is this by design?:

@dc42 Ok, I take that to mean that I should look at the servo drive causing the behavior, right?

Yes. If you use an oscilloscope to look at the step pulses, I am sure you will find they are regular. If they were not, then normal stepper motors would show the same problem. Even when step pulses for more than one motor become overdue, RRF continues to serve the motors evenly, except in extremely old firmware versions.

janbbeck

@dc42 I will replace the servo drive with one from a different manufacturer. Thank you for your time and help!