Inconsistent delays during homing and other movements
-
Here's a zip file (forums won't let me upload zip files) of the entire contents of my sd card: https://synfin.net/misc/duet-config.zip
-
@synfinatic Thanks thats a lot easier.
-
Ok, so I pieced together everything that get called from Homeall.g
M906 Z600 ; set absolute motor drive current ;; Set reduced physics parameters to help prevent missed steps. M203 Z3000 ; maximum speed (mm/min) M201 Z450 ; maximum acceleration (mm/min/s) M566 Z0 ; instantaneous speed change (mm/min) G91 ; relative positioning G0 Z10 F1800 S2 ; unhomed move up M913 Z100 ; restore motor current percentage to 100% M906 Z1200 ; motor drive current M203 Z9000 ; maximum speed (mm/min) M201 Z900 ; maximum acceleration (mm/min/s) M566 Z120 ; instantaneous speed change (mm/min) G91 ; relative positioning M906 X1000 Y1000 ; set absolute motor drive current ;; Set reduced physics parameters to help prevent missed steps. M203 X4500 Y4500 ; maximum speed (mm/min) M201 X900 Y900 ; maximum acceleration (mm/min/s) M566 X180 Y180 ; instantaneous speed change (mm/min) G1 X310 F6000 S1 ; +X probe move, fast. (*ADJUST* to 10mm larger than your X size) M913 X100 Y100 ; restore motor current percentage to 100% M906 X1200 Y1200 ; motor drive current M203 X18000 Y18000 ; maximum speed (mm/min) M201 X3600 Y3600 ; maximum acceleration (mm/min/s) M566 X180 Y180 ; instantaneous speed change (mm/min) G1 X-5 F6000 ; back off from the endstop G1 X10 F120 S1 ; +X probe move, slow G1 X-1 F6000 ; back off from the endstop G91 ; relative positioning M906 X1000 Y1000 ; set absolute motor drive current ;; Set reduced physics parameters to help prevent missed steps. M203 X4500 Y4500 ; maximum speed (mm/min) M201 X900 Y900 ; maximum acceleration (mm/min/s) M566 X180 Y180 ; instantaneous speed change (mm/min) G1 Y310 F6000 S1 ; +Y probe move, fast (*ADJUST* to 10mm more than your Y size) M913 X100 Y100 ; restore motor current percentage to 100% M906 X1200 Y1200 ; motor drive current M203 X18000 Y18000 ; maximum speed (mm/min) M201 X3600 Y3600 ; maximum acceleration (mm/min/s) M566 X180 Y180 ; instantaneous speed change (mm/min) G1 Y-5 F6000 ; back off from the endstop G1 Y10 F120 S1 ; +Y probe move, slow G1 Y-1 F6000 ; back off from the endstop G90 ; absolute positioning G1 X304 Y303 F99999 ; move to directly above mechanical Z-switch M906 Z600 ; set absolute motor drive current ;; Set reduced physics parameters to help prevent missed steps. M203 Z3000 ; maximum speed (mm/min) M201 Z450 ; maximum acceleration (mm/min/s) M566 Z0 ; instantaneous speed change (mm/min) M558 P7 H5 R0.1 F1800 T99999 A1 B1 G31 P1000 X0 Y0 Z0 G30 ; z-probe as configured M913 Z100 ; restore motor current percentage to 100% M906 Z1200 ; motor drive current M203 Z9000 ; maximum speed (mm/min) M201 Z900 ; maximum acceleration (mm/min/s) M566 Z120 ; instantaneous speed change (mm/min) M558 P7 H5 R0.1 F120 T99999 A5 S0.01 B1 G31 P1000 X0 Y0 Z2.55 G30 ; z-probe as configured M558 P5 I1 H5 R0.1 F1800 T99999 A1 B1 G31 P1000 X0 Y25 Z0 G90 ; absolute positioning G1 X150 Y150 Z150 F99999 ; move to a centerpointGimme a minute to digest that.
-
I should mention it's not just homing. That's just the obvious example. Manual moves after a successful homing also tend to have random ~20sec delays before execution. The first few times it happened I thought it didn't register the click and I'd click the button again... so the commands would end up getting queued up and execute over time.
-
Other than calling a lot of nested macros I can't see anything obvious that should cause those delays.
You may want to try the latest firmware beta. https://forum.duet3d.com/topic/6070/new-firmware-2-01-beta-2-available
-
@synfinatic Are those clicks in the DWC or on the PanelDue? What version of DWC are you running? Try the new firmware beta 2 along with the DWC beta 2 from the same download link.
-
I have been testing via the webUI. I've upgraded the firmware and webcontrol files to the latest beta. Started the full homing (via web) and X & Y seemed to work fine. But it never dropped the gantry to home Z and then gave up. The console has the error:
Error: Z probe was not triggered during probing move
Which is accurate.
Rebooted the whole printer and started homing via the PanelDue. That worked perfectly. Moved it around in X, Y, Z, no problems. Re-homed a few more times (still using the PanelDue) and it worked great.
So then started using the WebUI again. Did a full home- worked fine. Tried moving in X and it moved in X and Y. Went back to the PanelDue and verified that DOES NOT happen when moving via the PanelDue. Did more moves via the webUI and seems like any X or Y moves diagonally in both X and Y. If I didn't know better I'd say my CoreXY printer was setup wrong, but this is only happening via the webui.
Update: I should mention that it doesn't move in X and Y when homing X or Y. It only does that during moves post-homing.
-
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
-
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.
-
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?
-
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.
-
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
-
@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
-
@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.
-
Have you been able to get any feedback from the creators of the config set?
-
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 -
@synfinatic said in Inconsistent delays during homing and other movements:
=== Expansion ===
DueX I2C errors 6830No 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?
-
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.
-
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.
-
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 correctlyTried 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.
