I made a UDT.
It had two parameters.
machine and index
It had one tag
I made an instance of the UDT.
I set a static value for the machine parameter.
I wrote a script to change the index parameter when needed.
I tried to write a script on change for the tag in the UDT.
However, the values written from that script were always coming out null.
I think I was not getting the value to the tag before the script on the tag was running.
Do you guys have that issue too, or was something weird in my plc where the tag was taking extra long since the array the index was navigating had so many values?
Right now, I am avoiding using UDTs as much as possible.
I can’t tell if they are slow, or just slow when indirect addressed, or just slow when the indirect addressing is into a possible 2500 indexes
This doesn’t sound like it has anything to do with using UDTs. I have literally 1000s of UDT instances.
What’s your tag change script?
3 Likes
I deleted the script now, but was a currentValue and then a writeblocking to the parameter that indicated which index.
Ran on change of the index variable itself.
Then uses that index variable to get information from that indexed set of information.
so iirc it was like
temp=currentValue.value
system.tag.writeBlocking(["[.]tag.parameter"],[temp])
I can’t remember exactly how it looked. I know it was the udt parameter.
It did set the value.
It just took so long to get the value, it was like more than 2 seconds long to populate.
If I tried to write from the tags in the UDT, I got null from readblocking in that script.
I’m not at all surprised. You are changing the OPC Item Path with that parameter, right? That change causes the tag to have to unsubscribe from the prior OPC item, then subscribe to the new item, then wait for the subscription pace to trigger an update. If this is an infrequent event, just suck it up. Otherwise, don’t do this with tags. Use system.opc.read*() to construct a scripted immediate read of the indirect value and place it where you need it.
3 Likes
Also, "heavily delayed" might have been a slight exaggeration if it's only ~2-3s for the process Phil described 
If it were me, I would move the current index's data into a new "current" register in the PLC with the data from the current index and in Ignition I would read that, then you can still use tags. Otherwise, use opc.read as Phil said, or you can also add the tags for all indices into Ignition which could obviously add a large number of "useless" tags to the system.
2 Likes
Thanks
Changes to PLC code has expensive barriers put in place.
I agree that would have been good.
Thanks @pturmel for telling me about the immediate read.