Inconsistent delays during homing and other movements
-
So my problem is very inconsistent. Here's my new printer homing correctly: https://www.youtube.com/watch?v=gMIsAuI0Cx4
It will do that sometimes. I haven't found any pattern to it.
However, many times it will home REALLY slowly. And I'm not talking about the steppers moving slowly, but rather LONG delays between movements. Ie: you press the button to home all axis and there will be a ~20sec delay before it starts. Another ~20sec delay between switching between X & Y. Sometimes a ~20sec delay before it tries to slow touch off after doing the fast touch off.
Here's a short example of the problem- finishing the Z homing (which is taking longer then in the above video) and the LONG delay before it goes to the center of the printer:
https://www.youtube.com/watch?v=pO5f5ZbefKE
Again, sometimes I can perform a full 3-axis homing without any problems in about 30sec. The 2nd video was the 3rd time I asked it to re-home, after the first two times happened normally. Othertimes it can't complete the whole process in 2min. I've already retried flashing the Duet2 to the latest stable version. My 4x Z axis steppers are on a Duex5, while A/B are on the Duet.
I'm pretty new to the Duet/RRF ecosystem so a bit at a loss of how to diagnose/debug. My config is based on this config here: https://github.com/mzbotreprap/VORON/tree/master/Firmware/DuetWifi/V2/daveidmx
-
Oh, realized I should include the version info (M115):
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 2.0(RTOS) ELECTRONICS: Duet Ethernet 1.02 or later FIRMWARE_DATE: 2018-06-05b3
Also, I should mention that I've noticed sometimes various commands over the USB connection seem to have a delay. Ie: something like M115 might take a few seconds before it returns the firmware version.
-
@synfinatic Can you post a copy of your config.g, and homeall.g files as you have them? I tried piecing it together from the github link you posted but it's a bit all over the place.
Also, after it's behaved odly like that can you run an M122 to get a diagnostic dump and post that here as well.
-
0_1531615356465_center_xyz.g
0_1531615163805_config.g
0_1531615217517_homeall.g
3_1531615425548_zhop_up.g
2_1531615425546_probe_zm.g
1_1531615425546_probe_y.g
0_1531615425546_probe_x.gHere's the M122 after trying to home all axis (which took about 3min). Not sure if it normally takes a few seconds to spit out it's answer, but probably took at least 5sec for me.
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS) running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DGM-95BLL-N6PSS-6JKD0-3S46K-9JSBL
Used output buffers: 1 of 20 (8 max)
=== RTOS ===
Static ram: 28380
Dynamic ram: 95596 of which 0 recycled
Exception stack ram used: 508
Never used ram: 6588
Task NETWORK ready, free stack 324
Task HEAT blocked, free stack 1256
Task MAIN running, free stack 3656
=== Platform ===
Last reset 00:11:21 ago, cause: power up
Last software reset at 2018-07-14 13:14, reason: User, spinning module GCodes, available RAM 6244 bytes (slot 2)
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 31.9, current 43.3, max 43.5
Supply voltage: min 0.0, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max 0/205
Driver 1: standstill, SG min/max 0/167
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/230
Driver 6: standstill, SG min/max 0/221
Driver 7: standstill, SG min/max 0/173
Driver 8: standstill, SG min/max 0/177
Driver 9: standstill, SG min/max not available
Expansion motor(s) stall indication: yes
Date/time: 2018-07-14 17:47:34
Slowest loop: 224.26ms; fastest: 3.03ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 236, MaxWait: 722287760ms, Underruns: 0, 2
Scheduled moves: 19, completed moves: 19
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 ready with "M122" 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 ===
Slowest loop: 228.12ms; fastest: 0.01ms
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 30269
ok -
@synfinatic Just to chase things along, can you also post the macros that those homing macros call?
-
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?
