Automatic Bed Leveling with Conditional Gcode Iterations
-
-
@bearer Maybe because I just woke or hadn't gone on my run yet - but it is not completely crystal clear to me. Given the example below:
M120 ;push G91 ; relative positioning G0Z30 ; move Z 30mm M121 ;popI gather that 'M120; push' saves the current kinematic control state, then the user issues G91 & G0Z30 to relatively move the Z axis, and then returns to the previous control state by issuing an M121 - meaning that no M90 command was needed as M121 sorted that out?
-
@Kolbi said in Automatic Bed Leveling with Conditional Gcode Iterations:
meaning that no M90 command was needed as M121 sorted that out?
yes - but more importantly if you for reasons unknown already were in relative mode you would not return to absolute in error.
-
@bearer Ah ok - thanks! Besides rel/nonrel state changes - what would be an additional use case?
-
@Kolbi ref M120 docs; i only used for absolute/relative and feedrate
-
@bearer Thanks! I'll read the docs again and go for a run to let it soak in.
-
@bearer said in Automatic Bed Leveling with Conditional Gcode Iterations:
already were in relative mode you would not return to absolute in error
If I'm understanding correctly; If you are in currently in relative positioning and then you issue a G91 again - it would toggle, putting you in absolute positioning?
-
@Kolbi said in Automatic Bed Leveling with Conditional Gcode Iterations:
@bearer said in Automatic Bed Leveling with Conditional Gcode Iterations:
already were in relative mode you would not return to absolute in error
If I'm understanding correctly; If you are in currently in relative positioning and then you issue a G91 again - it would toggle, putting you in absolute positioning?
G90 sets the mode to absolute. Sending it again changes nothing.
G91 sets the mode to relative. Sending it again changes nothing.
Frederick
-
Ok, rgr that. So given the following:
M120: Push Example M120 Push the state of the machine onto a stack. Called automatically when a macro file is run. It pushes the following values on the stack: Current feedrate Extruder positions Whether moves (and separately extrusion) are relative or absolute M121: Pop Example M121 Recover the last state pushed onto the stack.Could use M120 before issuing any homing related current/sensing changes and then instead of changing them all back via individual commands - just use M121? I'm thinking no, but figure it doesn't hurt to ask.
I guess what I'm trying to figure out and ask is, what exactly is saved in the 'stack'? Also, the documentation states that M120 is called automatically when a macro file is run - I assume this means any gcode file that resides in the macros directory and that this would not apply to files in the sys directory?
BTW, @fcwilt & @bearer Thanks for helping me understand this.
-
...Maybe if I get one of these, all will be clear
-
Hi,
I've never used Push & Pop.
Yes there are places where I switch to relative (G91) and shortly thereafter switch back to absolute (G90) but not that many places, primarily in the homing macros.
If you were to look at all of the .g files in my sys directory the numbers of G90s or G91s would be small in comparison with all the other code.
I've simply never worried about it - I use them as needed.
Frederick
-
Thanks @fcwilt, much like what you have stated - I have never used M120/1 and haven't had any issues.
But on the other side of the coin, it makes me wonder if I could/should be doing things better by employing it's use? It seems to me, with my limited duet experience, that such command would be most usefully employed by a macro being called while performing an actual print, so that the desired settings set by the slicer would 'pick up where the macro leaves off' & not so important while performing homing evolutions before a print is started.
-
I don't rely on the commands my slicer sets at the beginning of a print.
Here is my "print begin" macro called by the slicer at the beginning of a print.
None of those slicer commands matter because my code overrides them all.
; S3D inserts the following 5 lines of code just before calling this file ;G90 ; absolute XYZ moves ;M83 ; relative E moves ;M106 S0 ; fan off ;M140 S60 ; bed temp to 60 ;M104 S190 T0 ; extruder temp to 190 M98 P"test_if_homed.g" ; aborts print if not homed T0 ; select tool 0 so extruder commands below will work M703 ; configure selected filament (sets bed/extruder temps) M106 P2 S255 ; lights on M106 P3 S255 ; lights on M106 P4 S255 ; lights on G90 ; absolute moves G1 Z75 F1200 ; position for cleaning G1 X0 Y-145 F6000 ; position for cleaning M291 R"Heating Extruder/Bed" P"Please wait..." T0 M116 ; wait for temps to reach set points M291 R"Priming Extruder" P"Please wait..." T0 G92 E0 ; reset the extruder logical position M83 ; extruder relative mode G1 E10 F120 ; prime the extruder M400 ; wait for extruding to finish G92 E0 ; reset the extruder logical position M291 R"Clean Nozzle and Bed" P"Click OK to begin printing" S3 M98 P"mesh_comp_map_load.g" ; load height map based on height map modeFrederick
-
@fcwilt Thanks for that info. Could you achieve the same thing by use of start.g? If not the same because timing with regards of being called by the slicer, what does your start.g contain?
Many thanks,
Kolbi -
@Kolbi said in Automatic Bed Leveling with Conditional Gcode Iterations:
@fcwilt Thanks for that info. Could you achieve the same thing by use of start.g? If not the same because timing with regards of being called by the slicer, what does your start.g contain?
Many thanks,
KolbiI haven't gotten around to determining exactly when start.g executes, just too many things on my plate.
My current system works but I imagine converting it to rely on start.g would not be a problem.
Frederick
-
@fcwilt said in Automatic Bed Leveling with Conditional Gcode Iterations:
too many things on my plate
I totally understand that. Thanks again for sharing all the info.
Cheers,
Kolbi -
I updated the first initial post to give a 'bottom line up front', the two efficient ways that were created to level the gantry, for ease of use.
-
Hi,
Normally I invoke PRINT_BEGIN.g and PRINT_END.g from within the slicer using whatever feature the slicer provides.
START.g was called before the call to PRINT_BEGIN.g. That seems to happen automatically without any action on part of Simply3D (S3D).
PRINT_BEGIN.g was called because I invoked it within S3D in the "Starting Script" option on the "Scripts" tab.
STOP.g was not called at all. It seems the slicer must insert a M0 command at the end of the print to invoke STOP.g.
PRINT_END.g was called because I invoked it within S3D in the "Ending Script" option on the "Scripts" tab.
Since I want a "end of print" macro to execute, without a way to force the slicer to include M0 at the end I will stick with the "Script" options and invoke PRINT_BEGIN.g and PRINT_END.g
If would be nice if START.g and STOP.g would execute without any action on the part of the slicer. Then I could dispense with insuring the slicer invokes PRINT_BEGIN.g and PRINT_END.g
Frederick
-
@fcwilt I understand, thanks!
-
there is also this overview https://duet3d.dozuki.com/Wiki/Macros#Section_System_Macros
