Automatic Bed Leveling with Conditional Gcode Iterations

Phaedrux

@mwolter That's a good question, and I'm not sure off the top of my head. Would have to test to see if it sticks in that format or not.

Kolbi

Another thing I noticed is repeatability with PindaV2 probe is not as consistent as BLTouchV3.1... So being that I use a bondtech bmg mosquito, I've made this modified version to scrap the Pinda and welcome the BLTouch. Will get it sorted on the printer and test it fully this weekend.

mwolter

@Kolbi looks good! Is that SLS or MJF printed?

Kolbi

@mwolter It was done on an HP Multijet Fusion (MJF), using Nylon PA12.

A Former User

@mwolter said in Automatic Bed Leveling with Conditional Gcode Iterations:

If the command G90 G1 Z20 is used in one line, does G91 have to be used to return to absolute mode?

yes, g-code knows nothing about white space or line breaks

(optionally you can use push and pop, M120, M121)

fcwilt

@mwolter said in Automatic Bed Leveling with Conditional Gcode Iterations:

@Phaedrux If the command G90 G1 Z20 is used in one line, does G91 have to be used to return to absolute mode?

G90 is absolute, G91 is relative.

Frederick

mwolter

@fcwilt
That’s why I used that command. Pulled that command from another macro and couldn’t remember why it was created. It’s used to move some amount from the current position without needing to bounce back and forth from absolute to relative and back to absolute positioning.

fcwilt

@mwolter said in Automatic Bed Leveling with Conditional Gcode Iterations:

@fcwilt
That’s why I used that command. Pulled that command from another macro and couldn’t remember why it was created. It’s used to move some amount from the current position without needing to bounce back and forth from absolute to relative and back to absolute positioning.

But there is no reason not to make use of the two positioning modes, there is no downside to using them.

There is nothing to be gained by emulating relative mode using the object model as you are doing.

Frederick

Kolbi

@bearer said in Automatic Bed Leveling with Conditional Gcode Iterations:

optionally you can use push and pop, M120, M121

@bearer I read the gcode manual but these two functions still made little sense to me - best I can derive is a save state / restore state? Could you expand a little on these and give me some use examples?

Many thanks,
Kolbi

A Former User

@Kolbi does https://forum.duet3d.com/topic/17854/retrieve-the-position-of-an-axis/5?_=1596130135808 help?

Kolbi

@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              ;pop

I 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?

A Former User

@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.

Kolbi

@bearer Ah ok - thanks! Besides rel/nonrel state changes - what would be an additional use case?

A Former User

@Kolbi ref M120 docs; i only used for absolute/relative and feedrate

Kolbi

@bearer Thanks! I'll read the docs again and go for a run to let it soak in.

Kolbi

@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?

fcwilt

@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

Kolbi

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.

Kolbi

...Maybe if I get one of these, all will be clear

fcwilt

@Kolbi

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