Thanks Rohan, I had seen your support ticket come in, but I didn't realize Nick was referring to the same scenario. I've got the logs you've uploaded to my dropbox, as well as all of the info you've submitted in the ticket.
I placed all of my tags in a tag group with an update rate of 10s and 1 tag in a different tag group with an update rate of 500ms. What occurred is that the 1 tag does not update for a while and then proceeds to update 3-4 times quickly before stopping. It seems similar to what was mentioned previously, where the next poll does not occur until the previous poll has finished.
This is somewhat expected. If you're reading a small tag group at a frequent rate, it can read multiple times before it is eventually interrupted by a larger tag group at a slower rate. While the large tag group's read request is in progress, the small tag group's request will have to wait.
As of 8.3.2, the Siemens driver makes a read request for all of the tags in your subscribed tag group at a fixed rate. (Technically several small read requests, one would be too large for a PDU.. but for simplicity's sake, let's consider it a single read request). It has to wait for that request to complete (i.e- get a response) before it can make another request. So, if you have a 10s tag group with 3k tags, the driver will read those 3k tags every 10 seconds. If it takes 6 to 7 seconds to actually read those tags, then another read request from another tag group can't start until 6-7 seconds later (when the large one finishes). If that second tag group is at a rate of 500 ms, it could update 3-4 times before the next large tag group request blocks it again. An overly simplified sequence would look something like this:
- Large tag group submits large read request to driver
- Small tag group submits small read request to driver
- Driver submits large read request to PLC
- Driver waits until it receives large read response from PLC
- Driver receives large read response from PLC
- Driver submits small read request to PLC
- Driver waits until it receives small read response from PLC8.
- Driver receives small read response from PLC
- Small tag group submits small read request to driver
...so on, and so on...
So, what can we (as a user) do about this? A couple of options, both are a pain, but might help:
- Split tags across multiple device connections.
- Each device connection would get its own connection to the PLC, and requests for tags from one device connection wouldn't have to wait on requests from another device connection.
- This only scales so far-- testing on one of our PLCs shows that the PLC itself can still only process one request at a time. (Behavior may differ based on model
)
- You might be about to say, "Wait, if the PLC can only process one request at a time, how would this help at all?" Remember how I mentioned that larger requests actually get broken up into many small requests? Well, the driver has to treat that as one larger request because of how we're using the AgLink library, but with multiple device connections, those smaller requests to the PLC can be interleaved with each other.
- Replace large tag groups with many small tag groups at similar (but different) rates. Using many smaller tag groups at similar rates would allow the driver to potentially interleave requests from more frequent groups.
- This is will be much less effective than having multiple connections, because the more frequent requests wouldn't have priority over the slower requests, and several slow requests can't be reliably spaced out from each other. So, even if you do this, you may end up waiting on multiple slower requests. But, Siemens PLCs have a limit to the number of connections that can be made, so this might be worth a try if you're in a pinch. Probably not.
What can we (as developers at IA) do about this? A couple of things, but they're not planned yet. I have done some testing/prototyping, so it's on the radar. Just not sure when we can actually get something in:
- Allow a configurable number simultaneous connections/requests to be made to the PLC. (I have prototyped this, but it's not close to production)
- If a user has multiple tag groups, this could give a similar behavior to configuring multiple device connections.
- We could maybe try to be smart and split up large requests from a single tag group across multiple connections, but if the PLC can only process one at a time, this won't really help for large requests, because we still won't be able to update any of the tags until the entire request completes.
- Implement a better subscription model. (This is something we want to do, for multiple reasons, but I haven't prototyped this yet. So, the benefits below are theoretical might work)
- With a better subscription model, we could probably update tags as values come in from the PLC.
- We could try to split large requests into smaller requests before giving to AgLink, and update the tags for each of those smaller requests as they complete.
We also tried setting the mode to polled rather than subscribed, set to 1000ms, and the tags seemed to update every 2000ms. If we set it to subscribed with the same rate, they were updating every 4000-5000ms
This doesn't make sense to me. Subscribed should be faster than polled, especially in 8.3.2. Polling is still fixed delay, but subscribed is now fixed rate. If you have a 1000ms tag group, and it takes 2 seconds to actually read those tags on the PLC, you should see the tags updating every ~2 seconds with subscribed, and every ~3 seconds with polling. Also, polled mode has some additional overhead in the OPC server that Subscribed mode doesn't have.
All that being said, I really wouldn't expect it to take near this long to read 3k tags on the PLC. Are there several other clients connecting/reading from the PLC at the same time? All my testing was done with a PLC doing no other work and serving no other clients, so obviously my results will differ from a PLC in production, I'm just surprised that it's this slow for you.
5mins to load the symbols, then another 15+mins for the tags to finally appear in the opc browser. We only have 2 PLC connections at the moment.
