Using variables in gcode
-
I thought it might be a good idea to parse the gcode for variables and replace them with values that would have been set previously.
The usecase for this would be that you could use a macro to set the temperatures and fan speed when changing the material and still use the same gcode file for printing something.
The macro could look like this:
M1111 Ne1temp V210 ; set e1temp to 210 M1111 Nbtemp V70 ; set btemp to 70
And the setting for the start gcode in slicers could look like this:
M140 S{{btemp}} M109 S{{e1temp}} M190 S{{btemp}}
I'm not sure what the firmware should do, when a variable is not set resulting in an invalid command. Just ignoring it would probably not be good…
-
The firmware should do nothing with this, the slicer should be substituting in the values before saving the g-code file. No need to use flash memory and add code to fix issues that shouldn't exist. The firmware should only be keeping the printer from damaging itself (ideally) or your home or business (overheat).
-
After thinking about this I agree. The usage of variables would not bring enough benefits to justify the work on this. Also I found out that slic3r has the name of the current filament preset as a replaceable variable in all the G-code settings. I currently use this in slic3r
Start:
M106 S153 M140 S[first_layer_bed_temperature] ; set bed temperature M104 S[first_layer_temperature] ; set extruder temperature M98 P/macros/Material/[filament_preset] ; call filament settings script M98 P/sys/before_print.g
Layer change:
M98 P/macros/Layerscripts/[filament_preset]/[layer_num]
I use the layer change G-code to reduce the speed at some layers when I fear that it will fail at full speed without sitting in front of the printer all the time. The macro in the start G-code is setting the retraction settings for the material I use, and I can override the temperatures if a print failed with the ones it was originally sliced with.
I still have to slice the files again for every material I want to use. -
So there's no way to use variables from the Web Controller into the Macros?
I would need this to make a Manual Calibration of the Z offset when no probe is available and the endstop is near the highend (220mm long printer or 300+mm)
Because with this I could
HomeZ
Move Z The whole Z distance -20mm (for safety) (this I can do ofc)
Then the user would move the Z with the -0.1 buttons until is near the nozzle
Then after is aligned I would send a M206 Z-{Current Z position}
M500
DoneSo Is there anyway to grab the web controller variable, and insert it on a macro?
Or maybe there's other gcode to do this?
I see that G10 is also available, and more powerful than a M206 to set each tool offsets, but still dunno how can I grab the Z current position and insert it on a macro
-
Hi Sebastian
No the variables set by clicking buttons in DWC do not flow through to macros however you can do most of what you want with a macro.
Macro: adjust_Z.g
G28 Z ;home Z
G1 Xnnn Ynnn ; Position A
G1 Z20 Fxxx ;move down to Z20 approx
M117 Adjust ZThen the user would use the buttons as you describe until the nozzle is at the feeler gauge position near the bed.
M206 is not saved by M500 so that would not work. The user would need to adjust M208 in their config.g to set the correct Z height (the original top homed height less the offset at the current postion)
-
Indeed that's more or less what I been doing. Yesterday night made the first test with a bottom z installed.
My idea is to make a G10 P0 Z-{user adds value here}
Then the user should add this to the config.g with that line followed by a T0.
Ofc I'm doing this for um2 classic users that would have just one head, also will serve as a fast explanation about how to tune stuff.
I think is better to use G10 than changing the axis length just because it leaves more fixed things and also is more interchangeable.
What surprised me is that when I do a G10 P0 Z-0.4 (example) It doesn't store this tool offset anywhere?
Anyhow as for future stuff, I think it could add a lot of flexibility to use current values (from the machine current position/temp) to use it on gcodes, it will allow/add some old-style-Logo programming.
For example, Set new temp (current temp)-30,
Or Save (current z) offset.Ofc some stuff can be done on the slicer, but we depend on the slicer capacity instead of the power of the printer to do simple math.
-
I can see the value in setting based on existing conditions (like increase temp by X) - this is effectively a relative mode for temperature and other settings that we apply this to.
Adding to the M500 settings that are saved would also be useful (but of course adds to the potential confusion, which is why i wanted to just edit the config.g always)
We are continuing to more closer to a general language for programming using gcodes….a friend of mine compared it to the development of shader languages in GPUs into general purpose programming languages.