I'm trying to save value tags to an excel via script. In some types doesn't work doing str().
Things like "Document" type is needed to do system.util.jsonEncode() instead of str().
Could I generalize using system.util.jsonEncode() for all types? Or there are any types that couldn't work with that?
Is there any way of maybe doing something like toStr() for tags?
Any information is appreciated.
Feel free to ask any question!
Summary: I want to save tag values to an Excel. I need to write it in a way that I later can recover it. Some types like "Document" doesn't work correctly.
In general what you're trying to do is a class of problem known as "serialization", and it gets very complicated to deal with all the possible edge cases.
This doesn't quite explain what you're trying to do (to me, at least). Are you looking for durable storage recovery, in some kind of disaster recovery scenario, or more of a "whoops, I just made a change to tag configuration I didn't mean to" recovery?
In either case my first recommendation would be to update to 8.3 and use git over the filesystem because that's objectively more powerful and useful than anything you can do via Excel.
We're also planning to add first party Excel import and export of tags in Ignition 8.3 in an upcoming minor release.
If you're on 8.1 for the foreseeable future, then I would ask you to provide more context/info on what you are ultimately actually trying to do, because Excel might not be the best fit or there might be a better way to get data between Ignition's tag system and Excel (i.e. Phil's spreadsheet export tool).
Also about the original problem (i totally forgot to answer that).
In our team we have a protocol of having excels with the data of different providers/machines/systems.
That means that we have the tags data in a custom excel. We are designing an app that takes care of the checking and importing. So the excels data and the real data are aligned.
You import the excel to the app, it check what is in the provider and spits out another excel with the differences. In that second excel you can "resolve" the conflicts, and then import it. The scripts detects that is the "conflicts" excel so instead of spitting out an excel it simply imports it to the provider.
Example
Provider:
name
path
type
value
tag01
[prov]folder1
Memory
asd
tag02
[prov]folder1
Memory
dasdas
Excel:
name
path
type
value
tag01
[prov]folder1
Memory
asd
tag02
[prov]folder1
Memory
hgfvdsf
You import the excel to the script and you get this: Conflicts Excel:
name
provider data
excel data
override/ignore/merge
tag01
{"value": "asd"}
{"value": "asd"}
IGNORE
tag02
{"value": "dasdas"}
{"value": "hgfvdsf"}
OVERRIDE
Then, you resolve the conflicts in the excel (override/merge) and you import it again. This time the script would modify the provider for real. And you would get this:
What about UDTs and their parameters ?
What about other tag types that don't have a writable value ?
What if the tags changed between the moment you first ran the script and the moment you give it the resolution file ?
The whole thing seems a bit clunky and unreliable.
PS: I'd probably work on an export of the tags and not on the tags themselves:
write a tool that takes both the tag export and your definition file, prompts the user to ask for conflict resolution, and spits out a new json file you can import into ignition.
You can decide if you wan't to override a specific tag or not. You can also write the tag property in a .txt file so that property doesn't matter or gets ignored (as a timestamp value for example).
Is about the same more or less with some differences
Yes, with some caveats; it's up to you to initialize your git repo at the correct location and you're in charge of synchronizing it, we don't do anything on your repos automatically.
But tag configuration is spread out into a hierarchy of plain JSON files on disk:
This is a fundamentally unsound assertion. A module could be added to your system that changes the set of properties a tag can have/cares about. For instance, MQTT tags provided by the Cirruslink modules work fundamentally differently to standard Ignition tags. Phil's got a module that adds various properties to tags to support custom 'tag actors' that do different things.
I still don't fully understand what you're trying to do, and I'm not an expert in Ignition's tag system by any means. I can offer help for specific questions about things you come across, but I'll close this particular post with a general thought:
Here's two folks who have a lot of experience with production Ignition systems saying that this seems like an "incorrect" thing to do.
Can you get something working, with a lot of engineering effort? Yes, I'm sure you can.
Should you continue down the path you're on? When, as far as I can tell, the main goal is to enable to use of Excel files, a monster of a file format with three decades of legacy cruft that's owned by an utterly uncaring/unfeeling third party? That's for you to decide.
I will generally say that from an Ignition perspective, you're going to have the happiest experience if you stick to what is supported by the software as it stands in whatever version you're deploying against.
The supported mechanisms for interacting with tags in 8.1 are limited and basically start and end at JSON/XML import/export. That's your lowest common denominator.
The first difference that comes to mind is "forced backups".
Might not sound like that big a deal, until that one time you go "Hey, it always worked so far, I'll skip the backup this time. What could go wrong ?".
That's for you to decide.