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

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