Posts made by janbbeck

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

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

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

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

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

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

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

@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 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 My firmware is 1.19. Thanks for the suggestion to upgrade and the explanation of the possible cause.

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

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

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.

Thanks! Can I use them as inputs as well?

Something like in the gcode documentation:
M583 P5 S0 ; Wait for Pin 5 to become 0

Do commands switch pins' input/output state automatically when using G42/M583?
Also is there a timeout option for M583 to prevent an infinite loop?

Thanks again for taking the time!

On the help page here:
https://duet3d.com/wiki/Using_servos_and_controlling_unused_I/O_pins

There is a convenient table of logical pin numbers to expansion connector pin numbers for logical pins 60-63. Is there a table anywhere for the remaining expansion header pins?

It's kind of hard to hunt down. For example, it says "Fans 3-7 are on the DueX5 and DueX2 expansion boards", but it's not clear to me at all which expansion header pins drive those. My guess is that maybe an SPI bus carries more than one of those signals and they are not visible on the expansion header directly.

I see pins 0-7 map to heaters 0-7. I see names for Heater3-7 on the expansion headers. Does that mean I can use those as input pins using just M307 to disable the corresponding heater?

As a feature request, it would be nice to add the logical pin numbers to the pins able to be accessed directly here:
https://duet3d.com/wiki/Duet_WiFi_and_Ethernet_wiring_diagrams

Thank you for your time,

Jan

I did get the scope out and measured. The pin toggles correctly. Edit for correctness: The hard stop homing
wiggles the motor before moving in the homing direction. The rightmost X probing location was far enough that this wiggling was enough to get the hard stop to trigger on the wrong side…:/

Sorry for the noise...

I am using 1.17
I will also try to use pin 63 instead of 60 and report back if that works.