RRF3 Homing Issues
-
@gtj0 is that not expected behaviour... and the head is tracking +/- the Z=0 position to follow the height map?
-
@t3p3tony said in RRF3 Homing Issues:
@gtj0 is that not expected behaviour... and the head is tracking +/- the Z=0 position to follow the height map?
The Z axis should certainly move according to the heightmap but the actual distance to the nozzle and reported position should remain constant. I.E. If Z=5.00, then when the XY axes are moved, the Z axis should automatically adjust to maintain Z=5.00. At least that's how it's always been before.
-
-
@gtj0 I am having this issue. everything works perfectly 40% of the time, then it seems to ignore the endstops. The lights all go out properly, so I know the switches and signal are properly being received, but it will error out and then stop.
The fix here seems to be working atm.
-
I'm sure it'll all get sorted once the guys are done with the upcoming trade show.
-
I think this is the same issue I mentioned in the RRF 3.0 thread.
I also happens with stall detection. -
I am completely and totally confused.
I don't see how anyone with a CoreXY can home their machines at all.It all seems to be related to what happens when the XY axes are already homed. Homing again puts both in this weird state where I either get "Homing failed", "Insufficient axes homed" or " Code has been cancelled".
If you have a Duet3 CoreXY that works, can you share your homing files and maybe your endstop configurations?
-
@gtj0 I had to change it to make sure it backs off of the endstops first, since the issue seems to be that it will error out if it's too close. Here are my files. While they work, I still at times will get the error. A few tries will eventually get it to "home", or worst case I disable the motors and manually move it away a bit. I also had to slow down the speed of approach to the endstops.
I have a BLV cube, so the Y axis is a max, not a min, fyi...
; homex.g
; called to home the X axis
;
G91 ; relative positioning
G1 Z5 F1000 S2 ; lift Z relative to current position
G1 H1 X-355 F4000 ; move quickly to X axis endstop and stop there (first pass)
G1 H2 X5 Y5 F3000 ; go back a few mm
G1 H1 X-355 F360 ; move slowly to X axis endstop once more (second pass)
G90 ; absolute positioning; homey.g
; called to home the Y axis
;
G91 ; relative positioning
G1 Z5 F2000 S2 ; lift Z relative to current position
G1 H1 Y355 F4000 ; move quickly to Y axis endstop and stop there (first pass)
G1 H2 Y-5 F4000 ; go back a few mm
G1 H1 Y355 F360 ; move slowly to Y axis endstop once more (second pass)
G90 ; absolute positioning; homez.g
; called to home the Z axis
;
G91 ; relative positioning
G1 Z5 F1000 S2 ; lift Z relative to current position
G90 ; absolute positioning
G1 X162.5 Y162.5 F6000 ; go to first probe point
G30 ; home Z by probing the bedG91 ; relative positioning
G1 S2 Z5 F100 ; lift Z relative to current position
G90 ; absolute positioning; homeall.g
; called to home all axes
;
G91 ; relative positioning
G1 Z5 F2000 S2 ; lift Z relative to current position
G1 H1 X-355 Y355 F4000 ; move quickly to X or Y endstop and stop there (first pass)
G1 H1 X-355 ; home X axis
G1 H1 Y355 ; home Y axis
G1 H2 X5 Y-5 F3000 ; go back a few mm
G1 H1 X-355 F360 ; move slowly to X axis endstop once more (second pass)
G1 H1 Y355 F360 ; then move slowly to Y axis endstop
G90 ; absolute positioning
G1 X152 Y166.4 F4000 ; go to first bed probe point and home Z
G30 ; home Z by probing the bed
G32 S2G91 ; relative positioning
G1 S2 Z5 F100 ; lift Z relative to current position
G90 ; absolute positioning -
@Nuramori said in RRF3 Homing Issues:
@gtj0 I had to change it to make sure it backs off of the endstops first, since the issue seems to be that it will error out if it's too close. Here are my files. While they work, I still at times will get the error. A few tries will eventually get it to "home", or worst case I disable the motors and manually move it away a bit. I also had to slow down the speed of approach to the endstops.
Yeah that's exactly the same behavior I see. Thanks for confirming I'm not crazy.
-
I am on duet2wifi, but the issue sounds equal
-
@smoki3 Yeah I had the same issue on my Duet2 so it's not the boards.
-
My home x:
G91 ; use relative positioning G1 S2 X3 Y3 F10000 ; move X away a little so the switch is not pressed M98 P"homey.g" ; Home Y ;M400 ; make sure everything has stopped before we make changes G4 P100 ; wait 400ms M913 X25 Y25 ; drop motor currents to 25% G1 S2 Z3 F5000 ; lift Z 3mm G1 S1 X-400 F6000 ; move left 400mm, stopping at the endstop G1 S2 X2 Y2 F6000 ;move away for second pass G4 P500 ; wait 500msec G1 S1 X-300 F300 ; (second pass) G1 S2 X2 Y2 F6000 ; move away from end G1 S2 Z-3 F1200 ; lower Z G90 ; back to absolute positioning ;M400 ; make sure everything has stopped before we reset the motor currents G4 P100 ; wait 400ms M913 X100 Y100 ; motor currents back to 100%Home Y:
G91 ; use relative positioning G1 S2 X3 Y3 F10000 ; ensure X is clear G1 S2 X3 Y-3 F10000 ; move Y away a little so the switch is not pressed ;M400 ; make sure everything has stopped before we make changes G4 P100 M913 X20 Y20 ; drop motor currents to 20% G1 S2 Z3 F5000 ; lift Z 3mm G1 S1 Y-400 F5000 ; move to the front 400mm, stopping at the endstop G1 S2 X2 Y-2 F5000 ;move away for second pass G4 P500 ; wait 500msec G1 S1 Y-300 F300 ; (second pass) G1 S2 X2 Y-2 F6000 G1 S2 Z-3 F1200 ; lower Z G90 ; back to absolute positioning ;M400 ; make sure everything has stopped before we reset the motor currents G4 P100 ; wait 400ms M913 X100 Y100 ; motor currents back to 100%Notes:
- The M400s\G4s are from an issue with old DSF that i think is fixed but i have just not removed them.
- Home X always calls home Y first due to an issue with X movement if the tool pickup head is at Y max on the toolchanger.
- Home Y moves X a bit first because otherwise if X is at its minimum position it can crash on the switch mount (will change this in a future design).
With that in mind I don't experience the issues you are seeing with homing failed if the switches are already triggered however if multiple people are seeing this on RRF 3 on Duet 2 and 3 then its something we need to look at.
-
Thanks @T3P3Tony . I'll test your files within the hour.
-
@gtj0 they are very specific to my setup!
-
@T3P3Tony Ha! of course. I meant "I'll adapt your homing methodology to my printer"
-
@T3P3Tony I've adapted your homing files and they do seem to work but they highlight a few issues...
It's a lot of gyrations to go through that we didn't have to go through before and the bit about moving away from the endstops to make sure they're not triggered isn't going to work if you're already at the upper limit of one of the axes. It also makes a homexy.g redundant since homex.g has to homey.g first.Since I only switched from Cartesian to CoreXY recently, I'm not sure if long standing CoreXY users normally do a move away from the endstops first but it's certainly not documented that way.
Hopefully long standing CoreXY users will chime in.
-
@gtj0 not sure. for reference these hare the homing files for the e3d toolchanger for Duet 2:
https://github.com/e3donline/RepRapFirmware-SD/tree/master/sys
The issue is they use stall detection rather than switches
-
@T3P3Tony Maybe I'll give stall detection a try this weekend.
-
@T3P3Tony said in RRF3 Homing Issues:
Home X always calls home Y first due to an issue with X movement if the tool pickup head is at Y max on the toolchanger.
aaaaah, I wonder if this is a key part of my issue - the BLV cube uses a Y max approach. I'll modify my homing files later and test your settings (in concept).
-
It's normal for stall detection homing to need a small (>=1 full step) movement away from the endstop sometimes before the homing move, to ensure that the motor doesn't register as stalled to start with. But that shouldn't apply to regular endstops such as microswitches. That said, the endstop detection code in RRF 3 is very different from RRF 2, so bugs may have crept in.
