I have a driver that I successfully ported from 7.7 to 7.8, 7.9, and 8.1 (gave up on 8.0), but I used the deprecated xopc modules that are supposed to disappear soon. Because of that I started going through it to move to the new device interface, which is basically touching everything in the gateway project. It's been almost 8 years since I wrote the original driver, and I have NO idea what I was thinking when I did... I see usages of browsable tags and OPC-UA nodes in weird (and wonderful) ways.
I've been heavily tempted to toss the whole thing and start over. I was never really happy with the way it turned out anyways. Unfortunately I have no wish to modify the project scripting that utilizes the defined tags.
It looks almost like tags and OPC-UA nodes are almost the same thing, so I've been wondering do I need to implement both? Can I just implement/define the OPC-UA tags and call it a day.
I guess what I'm really looking for are:
a definition of what a device tag really means to Ignition, and how it's used. vs
a definition of what an OPC-UA node really means to Ignition, and how it's used.
OPC doesn't have tags. It has items/nodes. Don't call them "tags", and don't expect to see them called "tags", and you'll be a big step ahead. (Drivers can point at tags in a device, but inside OPC they are not tags.)
Ignition has tags, and some of them are OPC tags, and those are simply Ignition tags that get their value from, and possibly write back to, an OPC item/node.
(FWIW, I'm finally doing this same conversion from Driver model to Device model.)
"Tag" is the industry standard term and the terminology Ignition uses for some kind data point.
OPC Tags are one kind of tag Ignition has - a data point from an OPC server.
In OPC UA the address space is made of "Nodes", not tags. You can browse an OPC server via the OPC browser, drag a Node in, and it becomes an Ignition OPC tag. You can also manually create and configure an OPC tag to point at a Node in some address space on some server via the OPC Item Path (which is the NodeId when it's an OPC UA server).
Device drivers are the extension point for providing Nodes in the Ignition OPC UA server address space. That they later become Ignition OPC tags is not really relevant to you, and in fact they may never become tags, because in theory you could just have any other 3rd party OPC client connected to the server and accessing those Nodes instead.
Ok, so what is the purpose of the ManagedTagProvider and the rest the com.inductiveautomation.ignition.gateway.tags. methods?
My device is basically a CNC type device. I'm regularly polling it for machine status information which I update local nodes with the values and I have defined internal nodes that trigger actions to the device.
If I was doing this now, that last bit would have been scripting functions, but...
I also have some nodes that tracked status of the 2 socket connections to the device that were necessary for proper functioning. 1 socket for the status information and a different socket used for asking it to do things. The status socket also receives unsolicited messages as well.
It's sounding like I should be looking at chopping out ALL the Tag Provider stuff which does create OPC-UA nodes as part of crating the tags and just have OPC-UA nodes.
Well, everything compiles now. Just need to check if it works, if so, I'm going to call it a day. Just need to update the signing certificate.
What happens when my self-signed certificate expires for a module that has already been installed? My current certificate is going to expire in 2 years.
Another kind of extension point that isn't related to OPC servers/drivers at all.
It might be a viable alternative for you, though. It's the same thing the MQTT modules use to provide tags, if you're familiar with those. It allows a module to provide tags via a Tag Provider that can be selected and used in the Ignition Tag Browser.
Nothing. The modules page will show a warning. Everything will continue to work.