[Greg McKaskle]

The way persistence works is that the value of the variable is updated to the robot file about once a second ( if changed ) so that the robot retains the last value across a reboot. Robot values show up on the DB, so this means that one way to view the persisted values is by looking at the DB -- either displays or the Variable tab.

Once the robot restores and shares variables, any client can then change the value. This means that if the DB changes a variable to modify a set point, it is propagated to the robot and all other clients. And if it is persisted, it will be used on the next reboot. Extending this idea, if you have a whole recipe file full of set points, and your DB loads those and calls NT Write for each of them, they will all propagate and be setup to be used for the next run.

So the persistence feature means that you may be able to avoid a big DB feature to load from a file. You simply use the DB to tune or update, and it automatically becomes part of the startup values on the robot. But if you wish to use a DB persistence mechanism, it automatically makes it to the robot and can be used with persisted variables to lessen the need to reload the DB each time.

It may be useful to periodically pull the .ini file from the robot and put it into SCC along with code, otherwise a roboRIO replacement will not have the values to restore with. If you have a DB file, that can obviously be used instead.

Greg McKaskle