G-Code Meta commands: Option unset (all) globals

egmrudd

So I propose a unset [params|vars|globals|all|specific variable] command to allow for faster tweaking and returning to a blank slate than a full board reset during which I might not even see how my modified gcode fails.

If you unset everything, then you have to rerun config.g(which requires a board restart) or run the sys and macro files where they are first initialized one by one to recreate those variables again. I don't see how that is less tedious than just checking existence. Also I would recommend not defining anything you plan on changing often in the config.g. Just make a file in the sys directory that gets loaded when config.g is run on startup via M98. That way if you want to change something after config.g runs, you don't have to rerun it, you just rerun that specific file. For example I have motor settings in a file outside the config.g. That way I can turn down max accelerations during homing, then just revert to my default settings by running M98 P"motorSettings.g" at the end of the homing sequence. Or I can edit it and rerun to change my default motor settings without a board restart and those changes will be persistent on future restarts.

I partially agree with this feature, because it would be occasionally useful to nuke a global variable, but if you are unsetting specific variables, that is just as tedious as checking for the variables existence. Also what happens if you try to unset a variable that does not exist?

Here is a common example of how I handle variables that get modified in various locations. This actually stored in a 0:\sys file named probeLocation.g I created and gets initially run by config.g but I can modify this and run it without a restart.

;store values locally while existence is checked
var probeLocationX = XX.XX
var probeLocationY = YY.YY
var probeLocationZ = ZZ.ZZ

if exists(global.probeLocationX) == true
    ;if true REdefine probelocations
    set global.probeLocationX = {var.probeLocationX}
    set global.probeLocationY = {var.probeLocationY}
    set global.probeLocationZ = {var.probeLocationZ}

elif exists(global.probeLocationX) == false
    ;else define the probe location
    global probeLocationX = {var.probeLocationX}
    global probeLocationY = {var.probeLocationY}
    global probeLocationZ = {var.probeLocationZ}

vs

;clear variables
unset global.probeLocationX
unset global.probeLocationY
unset global.probeLocationZ

;redefine varaibles
 global probeLocationX = XX.XX
 global probeLocationY = YY.YY
 global probeLocationZ = ZZ.ZZ

Yeah its less code, but im not convinced its less work.

Im not saying it a bad idea, its just not getting my upvote for the reasons above and I think there are more pressing features to develop, but if this low hanging fruit for devs, then why not.

It would be better that the "global <var> = <expression>" command just did double duty and defined or redefined the global variable.

fcwilt

@egmrudd

well unset globals would do all globals - you wouldn't need to do them one at a time.

Frederick

oliof

@dc42 any chance for this? I am getting an explosion of statements due to the checking constructs that @egmrudd proposed; ten variable assignments are now 40 lines of code. And I haven't even started with interesting things yet (-:

dc42

@oliof I am considering allowing the "global" command to be used even if there is an existing global variable with the same name. It would replace the original value. This disadvantage would be that of you accidentally used the same global variable name for different purposes in more than one script, it could become difficult to work out what the problem was.

oliof

@dc42 maybe enable that with a "I know that I am shooting myself in the foot" G-Code?

Stephen6309

@oliof Wouldn't that be an ID10T error?

oliof

you can call it whatever you want but dc42 being a veteran c++ developer probably is well versed with the footgun analogy

tfjield

This is an old thread, but I've just run into this issue and I wanted to share my workaround. I wanted to be able to keep my data neat and not have to have the same value on more than one line. (Because that provides an opportunity for errors, especially later when I'm changing something.)

I thought of creating a script file to do it, but I couldn't figure out how to reference the contents of the parameters directly, so I wrote them to a file.

I have all my globals in a file such as the following, and I set them using the "setglobal.g" script.

; globals.g
; called to initialize all global variables

M98 P"setglobal.g" L"leveled" V"false"		; flag indicating whether the bed has been leveled
M98 P"setglobal.g" L"xmin" V0			; x-axis minimum limit
M98 P"setglobal.g" L"xmax" V620			; x-axis maximum limit
M98 P"setglobal.g" L"ymin" V-28			; y-axis minimum limit
M98 P"setglobal.g" L"ymax" V600			; y-axis maximum limit
M98 P"setglobal.g" L"xprobeoffset" V5		; x-axis offset for probing z-axis datum
M98 P"setglobal.g" L"yprobeoffset" V5		; y-axis offset for probing z-axis datum

;etc.

The "setglobal.g" file writes the logic to check if the variable exists or not, and then executes it:

; setgobal.g
; Creates a global variable (if it doesn't already exist) and sets it to a value
echo >"tempglobal.g" {"if !exists(global."^param.L^")"}
echo >>"tempglobal.g" "    global "^param.L^" = "^param.V
echo >>"tempglobal.g" "else"
echo >>"tempglobal.g" "    set global."^param.L^" = "^param.V

M98 P"tempglobal.g"

Seems to work alright, and keeps my code fairly neat. There are probably limitations to this approach, but I don't know what they are, yet. lol

fcwilt

@tfjield

Interesting but why?

If you create all your global variables at print boot-up then you know they will succeed in being created.

Frederick

tfjield

@fcwilt Because not all variable changes are used in config.g. Some of the variables are used elsewhere, and for development I would like to update them without having to rerun config.g. And yes, I could change the value and update the globals.g file, but that's tedious. It's just so simple to rerun globals.g after I've made my changes and go on with testing. Of course, if the variables are used in config.g then I have to run it.

Also, this gives me the flexibility of defining a global in another file and not in globals.g, and I don't have to check whether or not it already exists.

Like most things, once everything is set up and working right, then it doesn't matter how you got there, how many lines of code, etc. But for development and iteration, I'm finding this helps.

fcwilt

@tfjield

Thanks for the explanation.

Frederick

tfjield

@dc42 How about automatically creating the global if it doesn't already exist when set it called, and allowing global to set an already existing variable? I'm thinking that would maintain backwards compatibility while going forward it would allow simplifying the scripts. I actually like variable declarations in code with strongly-typed languages, but not so much in scripting.

tfjield

@fcwilt For sure!

fcwilt

@tfjield said in G-Code Meta commands: Option unset (all) globals:

How about automatically creating the global if it doesn't already exist when set it called

I want you to think long and hard about what you are proposing.

I am prepared to forgot you ever suggested such a thing.

Frederick

tfjield

@fcwilt