Homing issue when homey.g
-
Hello,
I have an E3D tool changer (CoreXY) and it was initially using stall detection for the X / Y axis endstops.
I've just upgraded to physical endstops but I'm now having an issue where running the homey.g file performs the actual homing moves, but then seems to hang the printer. It shows as "idle" and the axis shows as homed, but it ignores any input when trying to jog the file and running homey.g again hangs the printer. (State changes to "busy" and the homing moves do not occur)
If I run each line from homey.g manually in the console, it works and I can cycle through these numerous times without issue.
; homey.g ; called to home the Y axis ; DC42 reduced stall sensitivity from 3 to 2 ; DC42 replaced G1 S parameters by H ; DC42 removed redundant G4 and M574 commands ; AY updated to use physical endstops G91 ; use relative positioning G1 H2 X0.5 Y-0.5 F10000 ; energise motors to ensure they are not stalled M400 ; make sure everything has stopped before we change the motor currents M913 X20 Y20 ; drop motor currents to 20% ;M915 H200 X Y S3 R0 F0 ; set X and Y to sensitivity 3, do nothing when stall, unfiltered G1 H2 Z3 F5000 ; lift Z 3mm G1 H1 X3 F5000 ; move X 3mm G1 H1 Y-400 F3000 ; move to the front 400mm, stopping at the endstop G1 Y1 F2000 ; move away from end G1 H1 Y-2 F500 ; fine home, stopping at the endstop G1 Y2 F2000 ; move away from end G1 H2 Z-3 F1200 ; lower Z G90 ; back to absolute positioning M400 ; make sure everything has stopped before we reset the motor currents M913 X100 Y100 ; motor currents back to 100%What can I do to debug this?
Duet Web Control 2.0.4 Board: Duet WiFi 1.0 or 1.01 + DueX5 Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.0 (2020-01-03b3) Duet WiFi Server Version: 1.23Diagnostic output while it's in its "hung" state:
=== Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.0 running on Duet WiFi 1.0 or 1.01 + DueX5 Board ID: 08D6M-91AST-L23S4-7JTD6-3S86L-TNXFK Used output buffers: 3 of 24 (14 max) === RTOS === Static ram: 30516 Dynamic ram: 92924 of which 28 recycled Exception stack ram used: 536 Never used ram: 7068 Tasks: NETWORK(ready,688) HEAT(blocked,1240) DUEX(suspended,160) MAIN(running,3676) IDLE(ready,156) Owned mutexes: === Platform === Last reset 00:02:38 ago, cause: software Last software reset at 2020-04-08 12:22, reason: User, spinning module GCodes, available RAM 7052 bytes (slot 2) Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d Error status: 0 Free file entries: 9 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest block write time: 0.0ms, max retries 0 MCU temperature: min 42.8, current 44.5, max 45.0 Supply voltage: min 24.1, current 24.2, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes Driver 0: standstill, SG min/max 0/350 Driver 1: standstill, SG min/max 0/1023 Driver 2: standstill, SG min/max 0/225 Driver 3: standstill, SG min/max not available Driver 4: standstill, SG min/max not available Driver 5: standstill, SG min/max not available Driver 6: standstill, SG min/max not available Driver 7: standstill, SG min/max not available Driver 8: standstill, SG min/max not available Driver 9: standstill, SG min/max not available Date/time: 2020-04-08 12:25:09 Cache data hit count 439170185 Slowest loop: 4.00ms; fastest: 0.09ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Move === Hiccups: 0(0), FreeDm: 169, MinFreeDm: 165, MaxWait: 15498ms Bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves: 21, completed moves: 14, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 === AuxDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 === Heat === Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 === GCodes === Segments left: 1 Stack records: 1 allocated, 1 in use Movement lock held by http http is idle in state(s) 1 8, running macro telnet is idle in state(s) 0 file is idle in state(s) 0 serial is idle 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: 81.61ms; fastest: 0.00ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) HTTP sessions: 1 of 8 - WiFi - Network state is running WiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 0 WiFi firmware version 1.23 WiFi MAC address a0:20:a6:16:ee:92 WiFi Vcc 3.35, reset reason Turned on by main processor WiFi flash size 4194304, free heap 24360 WiFi IP address 192.168.1.189 WiFi signal strength -44dBm, reconnections 0, sleep mode modem Socket states: 0 0 0 0 0 0 0 0 -
@yngndrw said in Homing issue when homey.g:
G1 H1 X3 F5000 ; move X 3mm
H1 means stop at endstop. I assume you have already homed x, so most likely you cant hit x endstop with move x3. Should that H1 be H2 instead?
-
@aidar said in Homing issue when homey.g:
@yngndrw said in Homing issue when homey.g:
G1 H1 X3 F5000 ; move X 3mm
H1 means stop at endstop. I assume you have already homed x, so most likely you cant hit x endstop with move x3. Should that H1 be H2 instead?
Good catch, you're absolutely right. Sadly as H2 moved individual motors instead of axes I have to manually coordinate the CoreXY move but I've changed that now:
G1 H2 X3 Y3 F5000 ; move X 3mm (adjusted for CoreXY movement)Sadly it doesn't seem to have resolved my main issue though, it still seems to hang within the routine for some reason.
-
For some reason you lowered you motors current to 20%. With endstop switches you dont have to do so, leave it to 100% and test then.
-
@yngndrw said in Homing issue when homey.g:
Sadly as H2 moved individual motors instead of axes I have to manually coordinate the CoreXY move but I've changed that now:
If the axis is already homed you don't need an H at all.
Agree with Aidar about the 20% current. That may be too low to reliably ensure movement.
-
@yngndrw said in Homing issue when homey.g:
Duet Web Control 2.0.4 Board: Duet WiFi 1.0 or 1.01 + DueX5 Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.0 (2020-01-03b3) Duet WiFi Server Version: 1.23At this point if you are planning on sticking with RRF3 you should consider upgrading to 3.01 RC6 and DWC 2.1.1
-
@aidar said in Homing issue when homey.g:
For some reason you lowered you motors current to 20%. With endstop switches you dont have to do so, leave it to 100% and test then.
@Phaedrux said in Homing issue when homey.g:
Agree with Aidar about the 20% current. That may be too low to reliably ensure movement.
This was left over from the old stall-detection setup, it is sufficient to move the axis as it was working like this previously and the M913 documentation does suggest that this can be used to protect your endstops so that's why I left it in. I've just tried it without (Also removed the related M400's) but sadly it didn't make a difference.
@Phaedrux said in Homing issue when homey.g:
@yngndrw said in Homing issue when homey.g:
Sadly as H2 moved individual motors instead of axes I have to manually coordinate the CoreXY move but I've changed that now:
If the axis is already homed you don't need an H at all.
In this case the X axis may not have been homed (Even for a "home all", I home the Y axis before the X axis) as the X endstop switch is mounted on the fixed frame and touches the carriage. This move is to make sure that the carriage is out of the way so that I don't smash into the X endstop while homing the Y axis. This is another reason for the reduction in current while homing, this particular line may bump the carriage into the other side of the machine - Thinking about it I should probably back it off a tiny amount so that it can't scrape along the frame!
@Phaedrux said in Homing issue when homey.g:
@yngndrw said in Homing issue when homey.g:
Duet Web Control 2.0.4 Board: Duet WiFi 1.0 or 1.01 + DueX5 Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.0 (2020-01-03b3) Duet WiFi Server Version: 1.23At this point if you are planning on sticking with RRF3 you should consider upgrading to 3.01 RC6 and DWC 2.1.1
I had avoided 3.01 as it's an RC, but I've just realised that the version I'm on is a beta version anyway so I might as well upgrade. I'll have to work out the configuration changes I need to make in order to upgrade and then give it another go.
While looking over the configurations in relation to your suggestions I did just find the line which is causing the issue. Looking at the actual homing section for the Y axis: (I've changed some of the speeds here)
G1 H1 Y-400 F3000 ; move to the front 400mm, stopping at the endstop G1 Y1 F10000 ; move away from end G1 H1 Y-2 F300 ; fine home, stopping at the endstopI coarsely home the axis once at a high(er) speed, then step back and re-home at a lower speed. It appears to be hanging on the
G1 H1 Y-2 F300line for some reason. I've double checked that the 1mm back-off is enough to clear the endstop so it must be a bug in this version. I also tried setting it to absolute mode and back to relative mode between the two homing commands in case the coordinates were getting messed up but it doesn't seem to be the case. -
@yngndrw said in Homing issue when homey.g:
it is sufficient to move the axis as it was working like this previously and the M913 documentation does suggest that this can be used to protect your endstops so that's why I left it in.
Yes reducing the current is a good idea, but you must ensure that it's still set high enough to guarantee reliable movement. So you'll need to experiment. Try 30% or 40%.
@yngndrw said in Homing issue when homey.g:
It appears to be hanging on the G1 H1 Y-2 F300line for some reason.
try increasing the movement distance. 2mm should be enough based on the distance of the previous move, but setting it higher still just to be safe.
RC6 seems to have some issues of it's own at the moment and RC7 appears to be right around the corner, so maybe hold out for that.
-
@Phaedrux said in Homing issue when homey.g:
@yngndrw said in Homing issue when homey.g:
it is sufficient to move the axis as it was working like this previously and the M913 documentation does suggest that this can be used to protect your endstops so that's why I left it in.
Yes reducing the current is a good idea, but you must ensure that it's still set high enough to guarantee reliable movement. So you'll need to experiment. Try 30% or 40%.
Okay I'll increase it a little to be safe.
@yngndrw said in Homing issue when homey.g:
It appears to be hanging on the G1 H1 Y-2 F300line for some reason.
try increasing the movement distance. 2mm should be enough based on the distance of the previous move, but setting it higher still just to be safe.
RC6 seems to have some issues of it's own at the moment and RC7 appears to be right around the corner, so maybe hold out for that.
I just tried 10mm but that didn't resolve it - It doesn't even try to move for that line.
I did notice in the release notes for
RepRapFirmware 3.01-RC3:Bug fixes: * When homing switches were already triggered at the start of a homing move, sometimes the move queue got stuck, requiring a reboot... so this looks to be the issue that I'm seeing. I've still not finished reading through the release notes but it looks like I shouldn't have to change anything in order to upgrade. If RC6 is having issues, I might upgrade to RC5 for the time being.
-
RC5 is working fine so it looks like that bug was the issue.
Thank you all for your time and help.
