Inconsistent delays during homing and other movements

synfinatic

I've been talking to a few other people with the same printer using the same config. Nobody has seen anything like this. They were thinking I had a bad board.

Ran M122 again, just for comparison:

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.01beta2(RTOS) running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DGM-95BLL-N6PSS-6JKD0-3S46K-9JSBL
Used output buffers: 1 of 20 (12 max)
=== RTOS ===
Static ram: 28484
Dynamic ram: 95808 of which 0 recycled
Exception stack ram used: 508
Never used ram: 6272
Tasks: NETWORK(ready,400) HEAT(blocked,1248) MAIN(running,3648)
Owned mutexes:
=== Platform ===
Last reset 00:31:18 ago, cause: power up
Last software reset at 2018-07-14 19:28, reason: User, spinning module GCodes, available RAM 6272 bytes (slot 3)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 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 39.1, current 43.4, max 44.0
Supply voltage: min 24.1, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max 0/204
Driver 1: standstill, SG min/max 0/1011
Driver 2: standstill, SG min/max 0/0
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max 0/250
Driver 6: standstill, SG min/max 0/258
Driver 7: standstill, SG min/max 0/206
Driver 8: standstill, SG min/max 0/253
Driver 9: standstill, SG min/max not available
Expansion motor(s) stall indication: yes
Date/time: 2018-07-14 20:33:41
Slowest loop: 197.57ms; fastest: 2.97ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 236, MaxWait: 828444ms, Underruns: 0, 0
Scheduled moves: 70, completed moves: 70
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 1 is on, I-accum = 0.0
=== 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 ready with "M408 S0 R1" 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: 169.65ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state: 5
=== Expansion ===
DueX I2C errors 6830

Phaedrux

@synfinatic said in Inconsistent delays during homing and other movements:

=== Expansion ===
DueX I2C errors 6830

No idea if this is relevant or not. I thought so more before when I thought it was just the Z axis pausing during homing because all the Z motors are on the Duex, but if it's pausing in all axis that seems like a contraindication.

Do the other users you've talked to get similar errors?

dc42

As I mentioned in the release notes, I believe there is a problem with DWC 1.21.2b2 on CoreXY machines. I suggest you use DWC 1.21 for now.

synfinatic

Is DWC 1.21 compatible with the latest beta firmware?

Edit: release notes seem to indicate it is if I'm not using a password? Gonna give that a try. Still would love to understand why I'm seeing these delays with the stable release and nobody else running a Duet on the Voron2 is. Of course, it's a pretty small sample size right now.

synfinatic

So trying that combo, and power cycled the printer (no USB connection) to start from a baseline.

From DWC:
First "home all" went perfectly
Second "home all" started fine... X & Y homed normally. Then things started to slow down after the first Z touch off
Third "home all" and there's a ~20 sec delay before each movement, starting immediately from pressing the button in DWC.

Tried home all from the paneldue immediately after the 3rd and it had the same problem.

Rebooted printer again.

From PanelDue:
Ran "home all" 3 times, all behaved correctly

Tried home all from DWC immediately after the 3rd paneldue test and it worked correctly three times in a row.

Then did a bunch of x/y/z moves via DWC. Not only did they move in the correct direction, but they were quick & responsive.

So it seems that as long as I do the homing first via the PanelDue then things are ok. But initial homing via DWC == problems.

Update: edited my config.g (reduced Z travel max) and reloaded. Then tried to re-home via the PanelDue which was immediately buggy. So it really really wants to start off from a hard reset.

synfinatic

So been playing with the printer most of the day. In general this combo seems to work better, but I'm not at the point of it being fixed. From a fresh power cycle, homing via the PanelDue works most of the time, but not always. Executing more complicated actions like gantry/Z leveling (auto level) and mesh leveling sometimes works, sometimes doesn't. Haven't been able to complete a full leveling cycle yet without things starting to start showing the 20sec delay between moves I've mentioned earlier.

Haven't gotten things reliable enough to start tuning the extruder or even trying to attempt a print.

Honestly, the fact that sometimes it works and sometimes it doesn't, even though the config/macros don't change seems to indicate some kind of firmware/hardware issue. I've re-flashed the firmware probably half a dozen times now, so maybe it's hardware? Not sure what else to do other then to RMA the board unless someone has a better idea?

dc42

Can you confirm that you have a very short and thick wire connected directly between the ground sides of the VIN terminals of the Duet and the DueX5, as per the DueX5 installation instructions; and that those terminal block screws are tight?

synfinatic

@dc42 Connections are solid. Using ferrules on the Duet/Deux5 side and spade connectors on the power supply end. Wire is 13AWG silicone wire. Here's the wiring:
alt text

elmoret

Not convinced that this is the cause of your issues, but note that your grounding configuration is in express violation of the recommendations in the documentation.

synfinatic

@elmoret You're right. I miss-read the docs. What is the proper way? With the ferrules, I can't daisy-chain the grounds can I? Am I supposed to splice the wires together (solder & heat shrink?). Smaller wires and run two wires into the same ferrule?

dc42

Some of the ferrules we normally supply have wider, almost rectangular inlets, designed to accept two cables. Did you not receive any of those? I'll post a photo when I am in the office.

Edit: here is the photo.

alt text

synfinatic

@dc42 So I do have those, but they're too small for a single 13AWG wire I've been using for power, let alone two of them, so I used my own. The next smallest size wire I know I have is 20. Might have some 18 lurking around. What size wire is acceptable/is it designed for?

synfinatic

So I rewired the ground for the Duet/Duex5 to be per the instructions. The 20AWG wire was IMHO a bit too thin so I spliced the ground together. Basically, the two boards are connected via a single 13AWG wire and then I soldered in another 13AWG wire to connect to the power supply at a single point. I measured the resistance between the 3 connectors to verify a good connection and added some strain relief.

TL;DR: It follows the same pattern. Was able to home a couple of times and run the mesh bed scan via the PanelDue without problems, but I couldn't even get to homing the Y axis the first time without tripping the 20sec delay using DWC.

Any other suggestions/ideas?

dc42

OK, I'm running out of ideas. Please ask Tim to exchange your Duet.

synfinatic

Thanks David. I'll reach out to Tim.

synfinatic

Just a quick followup. Was able to RMA both boards and finally found the time to install them and test again. Made sure to use the latest stable releases for both firmware and DWC. All my problems seem to have been resolved.

Thanks to everyone for their help!

Jeremy Watkins

I just started setting up a Cartesian and I am experiencing a very similar issue. When I home all, the board immediately homes the x and y axis. However, the z axis doesn't home until around 60 seconds later. This doesn't happen if I home the z, x, and y independently.

Here is my homeall.g

; homeall.g
; called to home all axes
;
; generated by RepRapFirmware Configuration Tool on Wed Sep 26 2018 00:09:26 GMT-0400 (Eastern Daylight Time)
G91 ; relative positioning
G1 Z5 F6000 S2 ; lift Z relative to current position
G1 S1 X207 Y-215 F1800 ; move quickly to X and Y axis endstops and stop there (first pass)
G1 X-5 Y5 F6000 ; go back a few mm
G1 S1 X-07 Y-215 F360 ; move slowly to X and Y axis endstops once more (second pass)
G1 S1 Z-150 F1800 ; move Z down stopping at the endstop
G90 ; absolute positioning
G92 Z.2 ; set Z to axis minimum (you may want to adjust this)

; Uncomment the following lines to lift Z after probing
G91 ; relative positioning
G1 S2 Z5 F100 ; lift Z relative to current position
G90 ; absolute positioning

Jeremy Watkins

@jeremy-watkins I just caught my mistake. Clearly, I didn't have enough sleep to see it last night, but my 5th line of code has X-07 instead of X207. Changing it resolved all my issues.