metacode rread-only variables
-
My suggestion is to be able to create "global" variables ( also would work for "var" ) that could be declared "read-only", meaning that only the assignment in the declaration of the variable would be valid and using "set" would be flagged as invalid. As I clean up my firmware for my multi-tool printer I am finding that some global variables are really global constants (like the docking positions of the tools) vs true variables (like the previous upTime a macro was called).
The declaration syntax would up to the firmware team.
Thanks!
Gene
-
@GeneRisi Can you give me a usecase for this wish?
I'm not sure if this is necessary? If you never use a "set" command in your meta code, the global will stay as it is.... -
@cosmowave said in metacode rread-only variables:
If you never use a "set" command in your meta code, the global will stay as it is....
I think that's the whole point of it, to prevent it from being changed.
One way of doing this would be to introduce new commands "const global" and "const var" that behave like "global" and "var" but the value is not allowed to be changed. Or maybe "global const" could create a global constant and "const" by itself create a local constant.
@GeneRisi feel free to create a Github feature request for this.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 said in metacode rread-only variables:
maybe "global const" could create a global constant and "const" by itself create a local constant.
This is probably closest to convention with most languages.
If it resulted in lower memory usage then I'd vote for it. -
@OwenD using 'const' wouldn't affect the memory usage.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 said in metacode rread-only variables:
@OwenD using 'const' wouldn't affect the memory usage.
Ah well.
In that case I can dress in either direction.
Can't hurt anyone and may help some. -
@dc42 The use case is that it would be nice to know if I have messed up when I make a script change. The past several days have been challenging because I implemented a second "pebble wiper" for the tool changer and realized that the variable declarations were scattered and the naming was inconsistent. I now have a defGlobalConstants.g and defGlobalVars.g that is called by config.g and some tool unique code is being reduced using indexing.
While I have your ear, I wish there was a way to check the gcode for syntax errors without actually doing anything. I don't know if this is what "simulation" is meant to do; if it is, I need to read up on it. Having macros fail during prints is a very slow way to debug.
