@oozebot This is fantastic! Yeah its not optimal, but I'll take progress over perfection.
Thank you for this!
@oozebot This is fantastic! Yeah its not optimal, but I'll take progress over perfection.
Thank you for this!
So I propose a
unset [params|vars|globals|all|specific variable]
command to allow for faster tweaking and returning to a blank slate than a full board reset during which I might not even see how my modified gcode fails.
If you unset everything, then you have to rerun config.g(which requires a board restart) or run the sys and macro files where they are first initialized one by one to recreate those variables again. I don't see how that is less tedious than just checking existence. Also I would recommend not defining anything you plan on changing often in the config.g. Just make a file in the sys directory that gets loaded when config.g is run on startup via M98. That way if you want to change something after config.g runs, you don't have to rerun it, you just rerun that specific file. For example I have motor settings in a file outside the config.g. That way I can turn down max accelerations during homing, then just revert to my default settings by running M98 P"motorSettings.g" at the end of the homing sequence. Or I can edit it and rerun to change my default motor settings without a board restart and those changes will be persistent on future restarts.
I partially agree with this feature, because it would be occasionally useful to nuke a global variable, but if you are unsetting specific variables, that is just as tedious as checking for the variables existence. Also what happens if you try to unset a variable that does not exist?
Here is a common example of how I handle variables that get modified in various locations. This actually stored in a 0:\sys file named probeLocation.g I created and gets initially run by config.g but I can modify this and run it without a restart.
;store values locally while existence is checked
var probeLocationX = XX.XX
var probeLocationY = YY.YY
var probeLocationZ = ZZ.ZZ
if exists(global.probeLocationX) == true
;if true REdefine probelocations
set global.probeLocationX = {var.probeLocationX}
set global.probeLocationY = {var.probeLocationY}
set global.probeLocationZ = {var.probeLocationZ}
elif exists(global.probeLocationX) == false
;else define the probe location
global probeLocationX = {var.probeLocationX}
global probeLocationY = {var.probeLocationY}
global probeLocationZ = {var.probeLocationZ}
vs
;clear variables
unset global.probeLocationX
unset global.probeLocationY
unset global.probeLocationZ
;redefine varaibles
global probeLocationX = XX.XX
global probeLocationY = YY.YY
global probeLocationZ = ZZ.ZZ
Yeah its less code, but im not convinced its less work.
Im not saying it a bad idea, its just not getting my upvote for the reasons above and I think there are more pressing features to develop, but if this low hanging fruit for devs, then why not.
It would be better that the "global <var> = <expression>" command just did double duty and defined or redefined the global variable.
I have this issue too, but my work around is I have sub directories in the sys directory that have their own config.g and other sys files. When I want to switch configs, I have macros that run M505 "0:\sys\config1" or M505 "0:\sys\config2", etc. I have global variables that get reused in each, like probeLocation, but it gets redifined depending on which config.g is run.
You will also have to run this code block to check if the variable already exists and act accordingly... yeah, yeah I know, the elif is not necessary in this case, I just like being as explicit as possible
edit: converted code from text to embedded code block
;create local variable that is stored until the existence of a global variable is checked
var probeLocationX = XX.XX
var probeLocationY = YY.YY
var probeLocationZ = ZZ.ZZ
if exists(global.probeLocationX) == true
set global.probeLocationX = {var.probeLocationX}
set global.probeLocationY = {var.probeLocationY}
set global.probeLocationZ = {var.probeLocationZ}
elif exists(global.probeLocationX) == false
global probeLocationX = {var.probeLocationX}
global probeLocationY = {var.probeLocationY}
global probeLocationZ = {var.probeLocationZ}
Yes! This would be very useful. Or at a minimum just have an option that has "yes", "no" and "cancel". "Yes" and "No" would return a boolean, that could be checked with an if statement, and cancel would kill the macro like it currently does. I'm not sure how or where to store the boolean. Having the ability to type a value into a UI prompt would extremely useful as well.
@dc42 Has this been implemented, and if so how. My company is also using duets in our in-house built machines. We do R&D research for multiple customers and are often changing the configuration of our machines to perform specific tasks. So it is not feasible to war game out every single user error case that can occur, therefore having generic safe guards in place such as enabling a heater to time out when the machine is idle would be beneficial.
Global time out could be an option but im not a fan of that because shutting off the power would also kill power to my cooling systems, which would be a problem if the machine was in a hot state.