Chiron+Duet3+BlTouch
-
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.
