I am trying to look at the PLC device diagnostics page to see why the tags are so slow.
But I only have Aggregate Statistics, and none of those “@1000ms” sections etc.
Request Count says N/A
Monitored items says 0.
From what I see in other people’s posting on this forum, this doesn’t sound right.
I am using V8.1.8 Ignition, and this is connected to AB CompactLogix PLC V33.
I only have the “Default” tag group, but I have changed it to Leased Mode.
Open a client that has bindings to some of your tags. “Monitored Items” are live subscriptions, which don’t exist for leased tags until something is watching them.
I opened several clients that show the tags and that does not show anything either.
In below screenshot, I have a web client opened on the right showing some indicators from PLC, and the Device page on the left, and the numbers are still 0.
I can’t understand why I cannot see any detailed diagnostic statistics on my Device Diagnostics page. Is it supposed to look like that?
The tags are “polled” rather than “subscribed”, does that make a difference?
(UascClientMessageHandler Warning there was a vague mention here that using polls does not help device diagnostics.)
I read that Subscribed is asychronous, so I am not sure how reliable that is.
Our PLC writes values to a large UDT then latches a “Trigger” bit. The Trigger Bit and the UDT are all mapped as OPC Tags in Ignition.
We have a python script that checks for the Trigger bit then reads the UDT.
We were afraid that if the tags are “subscribed” (thus asychronous), then when the trigger bit is set and we read the UDT Tags, then the UDT tags may not have been updated yet.
If your script checks the bit and issues a read (system.opc.readValues I assume?) then why do you need OPC tags at all, whether polled or subscribed? If your script uses system.tag.read* functions then you’re just reading all the tags’ current value in memory and it’s the group polling the OPC tags that is updating that value in the background.
We have a Perspective View that shows the UDT values as well.
So I thought using system.tag.read* functions would be the way to go so I wouldn’t have to map the PLC paths in both the tag definitions and the python script.
Are you suggesting that using system.opc.readValues is a more reliable way to get values from PLC for a script?
system.opc.readValues goes straight to the OPC Server and issues a read. system.tag.read* just gives you the tags most recent value as it sits in memory.
I don't think your setup has the atomicity you're looking for. You're sort of mimicking what transaction groups can do for you, but I think what you really want is something like:
The trigger tag in its own group, polled or subscribed doesn't matter. Then the UDT tags in their own group, set up to be driven based on that trigger tag (and possibly one-shot, unless it's okay that they keep getting read while the trigger is high). This way you know those UDT tags were not read until a positive trigger value was received.
Or if you want to drive this in script, just put a tag event script on the trigger, then read the values with system.opc.readValues (you just need addresses, not to actually have OPC tags created), then write those values to memory tags. Your Perspective view can look at the memory tags.
