Add function blocks for uniform handling of persistent data

[klauer]

• The library could keep track of per-variable persistent data changes
• The library could provide an aggregated status of "has any persistent data changed"
• The library could provide a tool to periodically save data and/or save only when "any persistent data has changed" per the above flag

Once this is done, this page should be modified:
https://confluence.slac.stanford.edu/pages/viewpage.action?pageId=337066917

[klauer]

• Data storage could happen in the FB, but I think it might be preferable to just stash the previous value for comparison
• Data type variants would be required
  • For floats, specifically, have a fTolerance setting
• Have a minimum period (never save more than once/minute, for example)

[ZLLentz]

We may also want to handle this outside of the built-in persistent variable support, e.g. saving the values in a file on the OS so they are essentially guaranteed to be consistent between software runs

[klauer]

That's a good point - and a great reason to keep it inside lcls-twincat-general as we can adjust its implementation if/when our best practices change (again).

[ZLLentz]

I'm thinking something like (rough sketch):

• Central FB that manages saving/loading the file
• Instanced FB that communicates save/load with the central FB for a single variable
• Central FB reads from file on startup and makes a json blob
• Instances read from or write to that blob
• After a savable change, if nothing else changes for e.g. 1 minute, the central instance writes the blob back to the filesystem
• On a planned shutdown, if there is a change to save, save it (can this be done?)

The goal is to limit the number of writes for CFast card health while being somewhat robust to surprise outages and keeping the saved variables through refactors. It might even be possible to export, track, and restore the saved values if we need to change out the memory card or reimage for some reason.

[klauer]

I quite like your sketch. I'm not sure if there's a hook for the planned shutdown, but there should be.

I also really like the idea of an external file that can be easily downloaded, tracked, and version-controlled externally. (Maybe with BSD that could be improved since we have actual access to git there, too, but that's getting a bit too far ahead...)

[ZLLentz]

I could absolutely imagine a file scraper that periodically grabs the file and commits it, which becomes much simpler to implement with TC BSD