Hi Friends, I have what I think is a simple question but I can't find the correct setting. In one of our class exercises, Ignition is already set up on the training stations, has an OPC UA connection established to a Compactlogix PLC, but is polling some tags that do not exist.
When the student adds the tag in Studio 5000, there is a delay before it starts showing up in Ignition. Looks like worst case scenario is about 1 minute so I'm guessing I'm looking for a timeout that is set to 60000ms but I can't find one that is for tags.
Whenever a tag is added in Studio 5000, the driver has to first detect that the program changed (I believe it checks for this about every 5 seconds), then the driver does a rebrowse to get the new tag names. On your trainers, I'm guessing this happens almost immediately, but should happen within a second or 2.
What tag group do you have them on? If it's a leased tag group (or even direct) with a long polling time, this could be part of the delay. Tags in designer do not lease values, so unless you have them on a window or view and with at least comms set to read mode, they'll read at the unleased rate.
Welcome to the forums Tim! (Looks like you've been a member for a long time and I'm just now noticing! LOL)
This is constant in the driver. Not configurable. Same in my alternate driver.
On top of that, subscribing to tags that don't exist put the OPC connection into a pathological retry mode that causes all subscription activity to happen only every 8 seconds.
That just got me thinking. I usually add my tags/logic to the PLC before trying to read the tag in Ignition, so the data always shows up very quickly. Not sure I ever do it in reverse.
But it also makes me wonder (without me knowing all the details of the drivers) if it would be beneficial to mark any tags that are not found and never retry them until a rebrowse is done, then as you mentioned in another thread, when any tags aren't found, mark them as overdue, so if a rebrowse is done where the tag does show up, it's immediately read/subscirbed to.
Hi Michael. They are using the default tag group with a data mode of Subscribed. They are on a window, I see the 60000 on the write timeout but I'm guessing that doesn't affect the read.
Yes, I've been around here a long time but haven't participated much. That will probably start to change
PLCs don't notify outsiders that they have new tags. Outsiders have to check some status words occasionally to notice, then rebrowse to find what has changed.
Ignition's OPC client has the pathological retry behavior to avoid crushing wimpy OPC servers. As long as Ignition treats all OPC Servers, including the loopback connection, the same, there's no avenue to do this.
Definitely listen to whatever @pturmel says. He knows all of this inside and out. But you definitely have a different use case doing training where your "workflow" is a bit different from when we're developing projects.
As a workaround and part of the training exercise, you could make a "typo" in the Ignition tag name/parameter depending on how you have it set up, and have them fix it, which would be a more immediate feedback.
Ah, I'm probably doing something that most people wouldn't...
Really, the first tag in the exercise is to show them that with no effort in Studio 5000, an HMI, SCADA, or other device can read and write to tags and it not be clear what is doing it in the PLC program. After that, I could have the create all the tags, that way there is only the one 60 second wait time. Let me see if I can reflow my exercise.
Wouldn't this be covered since the driver knows the tag's not found, but on the periodic for status it detects it needs a rebrowse, then refreshes the "not found" status on all the tags after it does the rebrowse and any that were previously "not found" get tagged also with "overdue". While this isn't probably a super-critical change/update that needs to take place in most normal scenarios, it's definitely something that affects trainers like @TimWilborne.
So is this more on the OPC client side then? I guess I assumed that the client subscribed and got a quality of bad/not found, and then the server just wouldn't push any updates. Or is it when the tag isn't found, the client subscription actually fails and then goes into this 60sec retry loop? (Is this to follow standards I assume? Or just to not crush other OPC servers like you mentioned?) Seems to me like the more efficient method would be to allow the subscription to happen on OPC but just have the server send the bad quality status and then report by exception like normal.
This makes sense. My guess is when using other products like FTView is that they aren't using OPC and doing direct comms with FTLinx/RSLinx so they bypass this entire issue.
You worry me a little bit with the word "pathological". Is their any major performance issues I should be looking for? It is only 12 tags but they are missing except on Tuesday of the training week.
Drivers are asked by the OPC server in which they live if a given OPC Item Path can be subscribed. That is the only opportunity to start a subscription, and it only happens when the OPC client asks. Which it will repeat as desired. (Eight seconds in Ignition.)
Driver's can only respond with whether they saw a particular item on their last browse. Browsing a Logix processor is expensive, so a driver will only do it when the PLC's metadata says that something changed. (Most other PLC brands can't be auto-browsed at all, so this is mostly a Logix "problem".) Both IA's driver and my driver check that meta-data once per minute.
