New guy here, barging in with a question. It seems like I can create a OPC Item Path using UDT parameters, but not using other tag values within the UDT (or anywhere else, for that matter). Is this correct, and if so, any easy way around it?
We’re using Ignition 8.0.5 and I’m trying to create a UDT to read some modbus input registers from a machine. The address of the data I’m trying to read (Uptime, a double) is offset by a number that can be determined based on a variable (Channels, an integer) which itself is read to an OPC tag, though using a static address. So basically what I want to do is have the OPC item path of “Uptime” be a function of “Channels”. I’m successfully using a parameter “DAQBox Name” to create the OPC item path of Uptime, but it won’t accept another tag. For instance, I’d like it to be
ns=1;s=[{DAQBox Name}]IRD____
with ____ being Channels * 5 +5. I tried using something like:
([.]Channels * 5 + 5)
{[.]Channels * 5 + 5}
[.]UptimeIndex (another tag within the UDT which = Channels * 5 + 5)
and I keep getting it returned as
ns=1;s=[DAQBox0]IRDnull
I’ve also tried setting the OPC item path of Uptime to an expression tag within the UDT that creates the entire path as desired, for instance with a value of 30 in Channels, UptimePath returns
ns=1;s=[{DAQBox Name}]IRD155
but Uptime’s OPC item path just appears as null when it references this tag as [.]UptimePath or {[.]\UptimePath} or anything like that.
So it seems to me that I can create an OPC item path based on UDT parameters (as in my use of the parameter “DAQBox Name”), but not other tags. I’d really like to be able to do that, so I’m hoping there’s a way and I’m just doing something wrong. Thanks for any input!
To get the expression tag, yes. But for some reason that won’t work in the OPC Item Path field of the Uptime tag. It will just appear just as you wrote it there, quotes and all, as if it doesn’t evaluate it as an expression. That seems to be my problem, that the OPC Item Path field accepts UDT parameters, but not tags. I can create an expression tag (I called it “UptimePath”) like that that creates the right path, but I can’t get that path into the OPC Item Path field of the Uptime tag because UptimePath is a tag, not a parameter.
I may have finally stumbled upon a way as a result of talking this one out on here. So since parameters can be used in the OPC Item Path field, I looked for a way to programmatically write values to parameters. So I created a second parameter, “Channel Count”, which I then have the UDT write to with an event script from another tag within it, an OPC tag with a static address. Let me see if I can illustrate with pictures because even I find that hard to read.
Seems to work, and be adaptable to new "DAQBox Name"s since that’s the only variable I really want to have to ever set manually for these UDT’s. Though now I see that maybe I won’t even have to set that manually, which would be great!
Can’t be done. You can’t ref anything but udt params and use very simple maths arithmetic inside of any tag property binding. If you could, operators would see these tags displayed with red overlays when changing opcitempath while the tag was reinitialised.
You best bet will be to create instances of all of your devices and then read the right one
Also, you should consider upgrading from 8.0.5. There have been many bug fixes and features added since then
Thanks for the definitive reply, that’s what I was afraid of.
So it’s not so much that I want to automate creating instances of the devices, it’s that the data coming from the devices changes such that the OPC item path for some tags would need to change depending what the machine is doing. It sends that “channel count” number at a definite, static address so that I can adjust the rest of the addresses accordingly, but I guess it wasn’t as straightforward as I had hoped.
The scripting trick above seems to work, making the UDT set one of its own parameters, but I won’t pop the cork just yet since it’s only been running for a couple days now and has hardly been tested to see if anything might break it.
@Matt_Payne Did you pop the cork? Did you find another better way? I'm looking to do the same. Be able to change the "Device Name" part dynamically from a OPC Item Path. (See yellow marked at the picture part that I want to change)
His solution uses a tag value change script to write to the Udt instance's parameters which are bound to the tag's OPC Item Path. For a non-UDTInstance tag, you can simply write to the OpcItemPath using system.tag.writeBlocking
Is that the recommended approach ?
Does it have a cost, beside the obvious tag write ?
Here's my situation:
I have devices, with a multitude of opc tags (in UDTs)
The devices have a failover communication channel, so the "value" UDTs need to pick the right opc path, depending on which channel is alive.
From what I understand, I have 2 solutions:
run a script that reconfigures the opc path (with a tag write, apparently)
have 2 opc tags, one for each channel, and a 3rd tag that would pick the value depending on what channel is alive
We're talking ~500 devices, with maybe 50/100 values for each, so the increased number of tags would not be negligible.
From what I gathered, it seems the scripting way is what I should aim at, but I'd rather make sure - it's hard to test and benchmark this kind of things.
There is a tradeoff between response time and complexity. The statically configured OPC tag pairs with a third tag to do the picking (based on quality, presumably) will respond the quickest, as it requires no scripting and no tag reconfigurations (those aren't free).
If the protocol is Modbus, you might want to try my alternate driver, which will maintain two connections and feed you data from whichever works (or alternate packets if both are up).
A third option might be to reconfigure the device(s) via script.
You could have one-or-both devices configured, have the gateway monitor the connections, and use the status of the active device to reconfigure the IP address of the (both) device(s).
Certainly not a high-availability solution (potential for lengthy reconnection times - driver & config-specific), but more straightforward than reconfiguration (or duplication) of tags, IMO.
