Persistant storage of variable data
-
Is there any plan to be able to store variable data in something akin to an .ini file?
Or perhaps a couple of arrays could be stored in config.g
Perhaps one for string values and one for floats and bools?
The former would allow greater flexibility, but I imagine the latter has less overhead as the arrays could be loaded when config.g is parsed.I think this would enhance development of new uses without having to wait for the object model or firmware to catch up and I can't really see it being able to break anything
-
config-override.g maybe? its already on the checklist to have a look see when things go haywire. Although it does raise the question of flash wear.
-
Conditional g-code does not yet have variables. When it gets them, it will also get globals, at some point macro arguments.
At that point, you can implement your own persistence, by writing the variables to a file (named anything) where each line in that file actually is the command to set a global variable to a value. Execute that macro after a power up, and... voilà! Persistence!
Of course, deciding when (really, how often) to write that file gets very interesting. Time? Change detect? Do it in the daemon g-code task? Etc.
-
@Danal
Yes, that is basically what I was suggesting when I mentioned and approach akin to .ini files
We can open a file and write all subsequent gcode commands to create the file entries, then close it with M28/29 (from memory)
I guess implementation is going to come down to how to manage the memory overhead of the variables. I mentioned a couple of arrays as an option as that allows the developers to control how many variables are stored. I have no idea of the available room.
With some sort of file handling routine(s) it would be possible to load a single required value rather than all values.
To be honest I don’t have a full usage case for why this would be necessary, but I’m sure it will be useful, although probably not always for 3D printing.
For example I sell semi automated and robotic welding equipment.
Persistent storage allows for saving “jobs” which would contain things like oscillating speeds, widths etc. -
@OwenD said in Persistant storage of variable data:
Persistent storage allows for saving “jobs” which would contain things like oscillating speeds, widths etc.
I'm sure there are lots of use cases... but... the above literally is a gcode job.
-
@Danal
Yes & no.
Unlike a printer, you don’t generate new gcode for each different shape.
A typical interface would simply allow the user to pick a weave shape pattern (toolpath) e.g sawtooth, square wave and then select/set width, oscillating speed and travel speed.
Once optimised these settings are saved as a job.
So your “job” file would only contain the variables of speed, width.
The “pattern” or toolpath file remains unchanged an unknown to the user.E.g for square wave pattern
(Loop until endstop)
G1 X{weave-width} F{oscillating-speed}
G4 S{pause-time}
G1 Y{step-distance} F{travel-speed}
G4 S{pause-time}
G1 X{-weave-width} F{oscillating-speed}
G4 S{pause-time}
G1 Y{step-distance} F{travel-speed}
G4 S{pause-time}
