A couple of questions regarding global variables

OwenD

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

@owend Thanks. I always appreciate your replies. You have a good way of explaining things in a way that an old retired mechanical engineer can understand.

Ah well, I'm a welder by trade, so we're used to telling engineers how it "should have been done"
Sorry, couldn't help myself

deckingman

For the sake of completeness and for anyone stumbling on this thread in the future, and thanks to those who helped, I have created a macro called "declareGlobals". This macro contains:-

global left=64 ; 64mm from left hand edge
global rear=366; equal to Y max

I call this macro from my config.g file with :-

M98 P"0:/macros/declareGlobals.g"

In my "user macros", I then use commands such as:-

G1 X{global.left} U{global.left} A{global.left} F12000
G1 Y{global.rear} V{global.rear} B{global.rear} F12000

Which all works a treat. So if the position of my nozzle relative to my wiping strip changes (as it is apt to do when I modify things or swap hot ends), then all I have to do is set the variables "left" and "rear" to some other value and all gantries will move to the new position for any of the multiple macros which are affected.

Thanks again @jay_s_uk & @OwenD

deckingman

Just a quick update on this. Having slept on it, I'm not sure if putting the variable declarations into a separate file is quite such a good idea. The reason being that if I make changes to those global variables (i.e edit the macro and save it) I must remember to run that macro again because the changes only get applied when the macro is run and not when it's saved. The same thing applies if the variables are set in config.g but at least I get a prompt and config.g will get run "automatically" again if any changes are made to it, whereas this doesn't happen when changes are made to any other macro.

I'll leave it for now and I've put a comment in the macro in big bold letters to remind me to always run it if any changes are made. But I suspect it might come back to bite me at some point in the future.

o_lampe

@deckingman you could also add a trigger event to the end of the macro which asks you to rerun it or not.

deckingman

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

@deckingman you could also add a trigger event to the end of the macro which asks you to rerun it or not.

Now that's a brilliant idea!. How would I go about adding such a trigger?

o_lampe

@deckingman there's an option to add external trigger or use the touchpad of a PanelDue

jay_s_uk

@o_lampe i suppose the only issue there is remembering to run the macro once you've edited it.
You'd also have to include the checks that @OwenD mentioned so you don't get errors

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

@o_lampe M291

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.