A couple of questions regarding global variables

[deckingman]

@owend said in A couple of questions regarding global variables:

@deckingman
I think you misunderstand my reasoning.
The only place I definitely check for the existence of the global is in config.g
If you don't do so and run say M98 P"config.g" then you'll get error messages saying the global already exists.
Maybe not a big deal, but apart from the aesthetic annoyance it also also means you can't reset your globals to "default" without a full restart.

When you run M98 P"config.g" and it gets to your global creation directive it does not process the value if it already exists. It (correctly) gives an error and moves on.
So any changes to your values require a full restart of they won't apply!

So... if it doesn't exist, I create it and apply a value.
If it DOES exist I reset the value because I can be pretty sure it's been changed in code somewhere.

With the calls to allow globals to be freed, it will become more important to check for existence in all macros.

Personally I think there's less chance of drama the way it is now.
If you don't want a persistent variable use a var instead of a global.
That said there are probably cases where it might be handy to free individual globals, so I'm not fussed either way there.

Ah, now that makes more sense. I naively assumed that running M98 P"config.g" after power up would result in the same behaviour as when it gets run as part of the start up process. I'm guessing the reason is that "stuff" gets read from config.g and put into volatile memory and stays there until power is cycled?

If I understand you correctly, what you are saying is the firmware checks if a global variable exists and if it does, it won't let you create one. So to get around that first check that the firmware does, you have to use another check to avoid the error message that the first check will generate and which will also prevent changes from being applied.

Playing Devil's advocate again but wouldn't it just be easier if the first check simply didn't happen, which would negate the need for the second check? Might this be a case that error trapping causes more problems than it fixes?

As an aside, would running M999 work after making changes to global variables? According to the wiki, https://duet3d.dozuki.com/Wiki/Gcode#Section_M999_Restart it restarts the firmware using a software reset. But I don't know if that restart also involves reading config.g and clearing anything that's in memory.

[dc42]

@deckingman said in A couple of questions regarding global variables:

As an aside, would running M999 work after making changes to global variables? According to the wiki, https://duet3d.dozuki.com/Wiki/Gcode#Section_M999_Restart it restarts the firmware using a software reset. But I don't know if that restart also involves reading config.g and clearing anything that's in memory.

Yes, running M999 will clear global variables.