Dynamic OPC Item Path from another UDT Tag

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!

1 Like

If you are using expression language, should you not be using something like this?

"[{DAQBox Name}]IRD"+{[.]Channels * 5 + 5}

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!

1 Like

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

1 Like

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.

I’ll recommend the upgrade too. Thanks again!