Chiron+Duet3+BlTouch
-
In homex: The G1 Z5 should have H2, otherwise it will complain if Z isn't homed first. Also remove the G90 and second G91. You just need to be in relative mode for those moves. Also, if you're using stall detection on X and Y, it's pointless to do a back off and second homing pass. A single fast homing pass is all you need.
;homex.g G91 ; relative positioning G1 Z5 F6000 ; lift Z relative to current position G90 ; absolute positioning G1 H1 X-405 F1800 ; move quickly to X axis endstop and stop there (first pass) G91 ; relative positioning In homeY the same thing goes for the G1 Z5 move needing H2. And the removal of the G90 and second G91 for the same reason. Also here if you are using stall detection, only ne pass is needed. If you are using an endstop switch, then the back off move should NOT have H2.
;homey.g G91 ; relative positioning G1 Z5 F6000 ; lift Z relative to current position G90 ; absolute positioning G1 H1 Y-415 F1800 ; move quickly to Y axis endstop and stop there (first pass) G91 ; relative positioning P4 P500 ; wait 500ms G1 H2 Y5 F6000 ; go back a few mm G4 P500 ; wait 500ms G1 H1 Y-415 F360 ; move slowly to Y axis endstop once more (second pass) G1 H2 Z-5 F6000 ; lower Z again G90 ; absolute positioning In your homeall and homez you should be positioning your probe at the center of the bed before sending G30.
You don't need all of the G4 pause commands in there either.
Your bed.g and level gantry macro could be the same thing. And I would leave G29 as a separate command rather than using it in G32 (bed.g)
; bed.g ; called to perform automatic bed compensation via G32 M561 ; clear any bed transform G28 ; home all G30 P0 X42 Y0 Z-99999 ; probe near a leadscrew G30 P1 X358 Y0 Z-99999 S2 ; probe near a leadscrew and calibrate 2 motors G28 Z ; home z again to reset Z0 ; homeall.g ; called to home all axes G91 ; relative positioning G1 H2 Z10 F6000 ; lift Z 10mm relative to current positio M402 ; retrack probe in case it's deployed ; first move/home Y axis G1 H1 Y-415 F1800 ; move quickly to Y axis endstops and stop there G1 Y5 F6000 ; go back 5mm G1 H1 Y-415 F360 ; move slowly to Y axis endstop once more (second pass) ;second move/home X axis G1 H1 X-405 F1800 ; move quickly to X axis endstops and stop there G1 X5 F1800 ; go back 5mm G1 H1 X-405 F360 ; move slowly to X axis endstop once more (second pass) ;third move/home Z axis G90 ; absolute positioning G1 X150 Y150 ; move probe to bed center G30 ; move Z down stopping at the endstop -for BLT G1 X0 Y0 Z10 ; move to parking position ; homex.g G91 ; relative positioning G1 H2 Z5 F6000 ; lift Z relative to current position G1 H1 X-405 F1800 ; move quickly to X axis endstop and stop there (first pass) G1 X5 F1800 ; go back 5mm G1 H1 X-405 F360 ; move slowly to X axis endstop once more (second pass) G1 H2 Z-5 F6000 ; lower Z again G90 ; absolute positioning ; homey.g G91 ; relative positioning G1 H2 Z5 F6000 ; lift Z relative to current position G1 H1 Y-415 F1800 ; move quickly to Y axis endstop and stop there (first pass) G1 Y5 F6000 ; go back a few mm G1 H1 Y-415 F360 ; move slowly to Y axis endstop once more (second pass) G1 H2 Z-5 F6000 ; lower Z again G90 ; absolute positioning ; homez.g G91 ; relative positioning G1 H2 Z5 F6000 ; lift Z relative to current position G90 ; absolute positioning G1 X150 Y150 ; position probe at center of the bed G30 ; move Z down until the endstop is triggered-for BLT I cleaned up your files a bit.
-
Thanks....I will upload the new files and see how it's working. I will do 2 separate sd cards....I will use them in a fresh install and on the old one . Just testing to see if this will fix the map height thing.
-
Above - you said " If you are using an endstop switch, then the back off move should NOT have H2."
Can you explain that please. I'm trying to better understand the documentation. I can see that H0 could be used for the backoff move since we now have a "home" for the axis. The documentation for H2 says
"H2 Individual motor mode. X refers to the X motor, Y refers to the Y motor, and so on. Normally used with relative motor coordinates (see G91).is used for a single"
This description would seem to apply to this situation - albeit may be redundant in the context of a backoff move. Basically - you said "NOT" and I'm seeking to understand if there is a negative here.One last thing (may be related) - is it "good practice" to issue a G90 at the end to avoid any potential, accidental issues with subsequent positioning commands ? Or does the homing move H1 automatically revert the printer to absolute positioning ?
-
@stuartofmt H2 is intended to allow movement for an unhomed axis or to isolate a single motor move on a corexy. Using it for the backoff move would prevent any error messages from being thrown in cases where the initial homing move actually failed. In normal working operation this may not matter, but when doing your initial testing, missing that error can lead to a lot of confusion. (Ex: I press home but it move in the wrong direction a few mm, I don't know why so I start changing homing direction or motor direction or endstop position, etc and make things much much worse, when the actual problem was that the initial homing either failed with a false positive or false negative and the H2 allowed the back off move to work anyway)
H2 in homing files is really only appropriate for the Z axis to allow an unhomed z axis to raise a few mm just to ensure clearance for moving the X and Y axis.
Unfortunately the web configurator tool has been generating XY back off moves that use H2 for a while, so it's pretty common to see now. But it really shouldn't be the case and I believe it's now fixed there.
Best practice for G90/G91 is to always declare it before you need it. Partly to ensure the moves happen the way you intend them, and to make the readability of the macro more clear because it declares the intention of the following moves.
As for whether the G90/G91 is persistent after the macro exits I'm not actually sure. It my return to whatever was set previously.
-
Thanks - makes sense.
I note that the documentation says that macros implicitly call a M120 Push at the start. But M121 Pop does not state that it is applied at the end of a Macro call. I suspect that logically - it must otherwise the stack would just grow ....
Would be great if there was some clarification on that.
Implicit in the above is that it's perhaps not a bad idea (although in practice likely irrelevant) to have a G90 in config.g before any macro calls so that the default state is absolute.
-
@stuartofmt said in Chiron+Duet3+BlTouch:
to have a G90 in config.g
this is the default produced by the config tool.
-
I've loaded your files and now I am start testing but so far looks good.
A small problem is that when I am moving to bed centre the speed is very slow.....after X and Y homing the move to the bed centre is very slow.....but after gantry level when is doing the second G30 the speed is normal.
The start.g code is executed first when the board is powered or before any print starts? I need to ad a delay , probe reset and self test for BLT because in 95% of the cases after "emergency stop" or when I power up the board is in error mode.
Can't wait to finish with this and move to piezo probe..... -
@Phaedrux said in Chiron+Duet3+BlTouch:
G1 H1 X-405 F360 ; move slowly to X axis endstop once more (second pass) ;third move/home Z axis G90 ; absolute positioning G1 X150 Y150 ; move probe to bed center
The move to center is slow because the last feed rate set was only F360. Add a new fast feed rate to the G1 X150 Y150 F6000 move.
@razrudy said in Chiron+Duet3+BlTouch:
The start.g code is executed first when the board is powered or before any print starts?
start.g is run as soon as a print starts.
@razrudy said in Chiron+Duet3+BlTouch:
I need to ad a delay , probe reset and self test for BLT because in 95% of the cases after "emergency stop" or when I power up the board is in error mode.
Add those reset commands to the start of homeall.g and homez.g and the end of config.g just to make sure the BLTouch is ready to go.
M280 P0 S160 ; Clear any alarms M402 ; retract pin just in case -
This post is deleted! -
Can we use now M205 in mm/s instead of M566 in mm/min for better compatibility with the slicers? Any advantage in one over the other? From @dc42 post , about 1 year ago , the M205 is supported since RRF 2.0.1 for XYZ or other axis. this includes the E jerk too?
-
Yes you can use the marlin format if you wish. though most slicers should output the correct reprap syntax when set to reprap gcode flavour.