Inconsistent delays during homing and other movements

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.