I'm trying to make sure I understand the functionality of this vs 8.1.
I believe (and could be wrong) that in 8.1 memory tags were persisted to the tag configuration, as this was the only place at least visible via the designer to see these values. Now with 8.3 supporting None, Database, and Configuration, it seems like the default value only comes into play when None is selected, otherwise, the default value is really meaningless since the value after a gateway restart will load from either a separate persisted values DB or the tag configuration DB.
I would almost like to see the default value being hidden when database or configuration is selected if it works as I think it does as to not confuse anyone since that default value is meaningless with those 2 options.
the default value is really meaningless since the value after a gateway restart will load from either a separate persisted values DB or the tag configuration DB.
What about on initial config before a tag receives a value? I could also imagine a scenario where someone wants to make some decision based on the default value property.
On initial creation, you would be setting the value property, since both default value and value exist, there's no point in setting both to the same value if it can be done behind the scenes. I don't really see a point in setting the default value and value differently unless you're using the None option.
You're right that it is most obviously useful for None persistence, but particularly with the move to flat files and the emphasis on version control, etc. for 8.3 it's entirely possible and likely that people will want to move tag config files between environments but don't actually want the live happenstance values of those memory tags from a test environment to end up in prod. In those cases, you could move just the tag config files but not the value store database file, and in the new environment the tags would fall back to the desired default value instead. TLDR there needs to be a fallback for database as well in the case that the tag value store database is missing, or even just the record for that particular tag is missing if an older version of the database was restored from before the tag was created. It is unlikely to come up with configuration persistence memory tags for sure.
There are some future ideas like allowing tags to use the default value for the live value on import or send tags via EAM and set the live value to the default value to make it easier to move memory tag config without worrying about what happened to the live value during testing as well, but that's something that might happen down the line.
I'd also note this idea came up during a discussion regarding what should the config look like when database persistence is set. Before defaultvalue was added, it was a bit confusing to look at the tags.json file for a database persistence tag and see the "value" field that didn't match the value actually seen in the tag browser. By using defaultvalue instead and removing the value field from tags.json when using database persistence, it made the difference a bit more clear.
It looks to default to database on upgrade. I haven't created a new tag provider from scratch, but I would assume it also uses database as it's default.
The default setting for a Tag is 'Inherited', which means it will inherit the 'Value Persistence' setting of the Tag Provider.
The default 'Value Persistence' setting of a Tag Provider is 'Database', so on an upgrade, the Tag Provider Value Persistence setting is set to 'Database'.
What is this value store database? I know in 8.1 there is a sql lite DB but that has gone away now that all configuration is human readable files right?
data/config/ignition/tags/valueStore.idb is a new SQLite DB that is only used by the tag system.
Actual tag configuration is still read from individual files, but constantly reading/writing atomic tag updates to (approximately) a bazillion files was not a viable path for performance.
I want to weigh in that Configuration should really only be used when values change very infrequently. If you have looked at the tag configuration files on disk, you will see that each tags.json or udts.json file will contain the full configurations for each tag in that given folder. If values are getting written to the configuration, that entire file has to be recreated which will have performance impacts.
Will there be a way to update the default value "automatically" with the current value or would this just need scripted out on some sort of trigger. Let's say there's a bunch of memory tags in UDTs that have a default value from the UDT, but once commissioned/configured you want all those memory tags default values to be set to the current value.
In the Wonderware SystemPlatform world there was an "Upload runtime values" option to pull the runtime values into the configuration database as the default values. I'm thinking something similar to this.
Memory tag members in UDTs are handled a bit differently. defaultValue only applies to individual atomic memory tags. Any memory tag that is part of a UDT (Def/Instance) behaves the same as it did in 8.1 where the default value is populated from the Definition itself and is overridden at the instance level.
While we don't have a way to sync defaultValue for the tags that leverage the property, we can look into potentially adding a feature like this in the future.