A couple of questions regarding global variables

o_lampe

@jay_s_uk
I'm struggling to find the right command which pops up a question and asks you to confirm or cancel.

jay_s_uk

OwenD

@deckingman
I'm going to have a bit of a rant, but it's not aimed at you specifically, it's more an observation given the embryonic state of people using conditional code on printers.

I still feel the best way is have a section in config.g where you put all your global variables.
I also feel checking if the global exists is important not just from the point of view of avoiding console errors.
It is equally important to ensure that any temporary alteration to that global is returned to the default on a restart.
Putting the code in config.g handles that most completely and easily.
As you've deducted, using a macro called from config only works if you then have a mechanism to ensure changes apply.
I guess you could check the file hash value from daemon.g, but why?
Some people feel doing such checks is "too much work", but the fact is that if you want to start using code, then you'd better start getting used to ensuring YOUR code handles unexpected events.
If YOUR code will except something to be in a certain state, then it's YOUR responsibility to ensure that is the case before your code executes.

I wonder if the guy that programmed the plc in your microwave said "meh - too much work to check the doors closed before starting... we know they're going to close it right?"

deckingman

@owend Fair comments I suppose. It's the mechanical engineer mentality thing vs software engineer thing again. If I adjust something mechanically, I tend to accept that the adjusting screw that I know I fitted earlier exists. I don't say to myself, "every time I want to turn this adjusting screw, I must check that I fitted this adjusting screw and if I didn't, then fit one and turn it, else just turn it".

fcwilt

@deckingman

To give you an opinion from a retired programmer:

if we had a command to remove all existing global vars I would create them all in a file which I called from config.g
since we don't I create them all in config.g
I do not check for their existence when I use them - I verify my code works and leave it at that

Frederick

o_lampe

@owend
Some macros can get several pages long, so I agree it's best practice to check for existing variable names. Especially when more than one person develops or changes this macro over time.
Additional to your post, I'd propose NOT to use standard variable names (X,Y, I,J etc) but 'speaking' names, but that's common sense I guess.

deckingman

Playing Devils advocate here, but going back to my original use case, the reason I wanted to use global variables in a number of macros, was so that I could set the values in one place and any macro that needed to use those values would do so. The alternative (which I used before) is to use a fixed value which involves editing numerous files if that value needed to be changed. This could mean that "fat finger syndrome" might mean that one or more macros could use the wrong value. If I check that the global variable exists and that it is set to a certain value at the start of every macro, then I'm back to editing every file which uses those global variables every time I make a change. Which negates the advantages of using global variables instead of fixed values does it not?

OwenD

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

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.