Inconsistent delays during homing and other movements

Phaedrux

Can you confirm you are using this version of the DWC?

https://github.com/dc42/RepRapFirmware/releases/download/2.01beta2/DuetWebControl-1.21.2-b2.zip

synfinatic

Yeah, I uploaded the b2 DWC zip file via the UI after upgrading the firmware.

So I downgraded back to the release version and moving via the web (after homing via paneldue) only moves in a single axis at a time, but there's about a 5sec delay before executing the move. No delay with the paneldue.

I also tried re-homing via DWC, and it's slooooowwwwww again.

Phaedrux

Hopefully from the information we've gathered someone will have a better idea of what might be going on.

BTW, have you printed anything yet? Does it execute a print properly?

synfinatic

Back to beta2 firmware and DWC.

Behaving the same as I described before with this version. The only additional info I can provide is I notice when doing a moves, they're not just running at angles, but reversed on the selected axis. Basically -100 Y causes the head to move +50Y and -50X. Same pattern for X moves. The head position values in the upper right corner of the DWC update correctly based on the physical movement of the head.

Phaedrux

If you manually go through the movement testing section for coreXY do you get the movements you expect?

https://duet3d.dozuki.com/Wiki/ConfiguringRepRapFirmwareCoreXYPrinter#Section_Movement_section

synfinatic

@phaedrux Nope. Just finished wiring and slowly bringing the printer to life. Was acting so wonky I haven't even gotten to the gantry leveling step or even tried the extruder.

Honestly, until upgrading to beta2 I was pretty much convinced my board was bad and I needed to RMA it with Filastruder. But b2 seems like an improvement (at least it seems more consistent) so not sure anymore

synfinatic

@phaedrux It was fine under 2.0 and is fine under 2.01.beta2 via the PanelDue. Only has issues under 2.01beta2 via the DWC.

BTW, thanks for the help. Feel like we made some progress. Hopefully someone else can provide some ideas.

Phaedrux

Have you been able to get any feedback from the creators of the config set?

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?