I am testing out the new Siemens Enhanced Driver to communicate with a S7-1500 PLC. I have the communications working, but they are very slow. It seems to take 4 to 5 seconds for the tag values from the PLC to update. I am using the symbolic addressing mode.
Prior to this I was using the third party Tanni OPC driver to communicate with the PLC using symbolic tags and didn't notice any issues with slow update rate.
Has anyone else experienced this?
When I first started testing with the new driver and only had it connected to a few tags I didn't notice the slow update rate. It was only when I switched all of the tags in the project over to using the new driver that I noticed the slow update rate. I am monitoring the seconds value of the time clock in the PLC so that I can see how often it is updating. It’ll jump 4 to 6 seconds on every update.
I’m pretty sure its not a bottleneck at the PLC because I am monitoring the same “seconds” tag using the tanni driver and its updating like clockwork every second.
There's one known issue that slows the polling that I think will get fixed in 8.3.2 or 8.3.3. Basically, the polling is happening using a fixed delay rather than a fixed rate.
This means the next poll isn't scheduled until after the subsequent poll finishes, e.g. if you are subscribed at 1000ms, it takes 500ms for the PLC to respond with all the items, then +1000ms from the response the next request is schedule. It makes the update rate more like ~1500ms.
Other than that... not sure. You might want to work with support so they can get a better idea of your tags and setup.
Thanks for the reply Kevin. I think I have it fixed now. Pretty sure it was network hardware related. The comms eventually stopped working altogether, so I bypassed the switch and cabled straight to the PLC and everything came back and the update rate greatly improved. Seems to be updating very reliably at around 1.5 to 2 seconds like you mentioned it would. Just a strange issue because the tanni OPC server never stopped working.
We’re seeing issues with slow update rates with the new driver as well. Not just that though, but other issues like:
Very slow browse/re-browse e.g. 5mins + many more minutes (10-20mins) for the OPC browser to actually show the tags, constantly getting “TimeoutException”. Have tried restarting Ignition service.
Nah we’re not seeing those errors in the logs i.e. we’re not seeing AGL40_SYMBOLIC_NOT_APPLICABLE, we’re seeing AGL40_SYMBOLIC_PATH_UNKNOWN_FIELD
This usually means the path to the tag on the PLC is wrong. You can see this tag path in the OPC Item Path. This probably shouldn't happen when dragging and dropping from the OPC Browser, unless you have changed the tag structure on the PLC after browsing.
What is the latency like to the PLC? Is the PLC very busy with other things? You can likely avoid the timeout exception by increasing the timeout in the device connection config on the gateway. This might indirectly make loading symbols faster by not repeatedly failing with timeouts until it is successful.
Hmm, this sounds odd. I don't recall anything off hand that would cause this on the driver side. Are the other connections to the same physical PLC?
The path is definitely correct, however I believe this is due to the OPC-UA server still trying to figure out the connection to the PLC. It took in the vacinity of 20-30mins to finally connect and display tags in the opc browser in our dev environment for that single PLC 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.
I’m not sure how to check the PLC latency, are you looking for something specific? I’m used to AB PLCs which have a dedicated comms CPU. I don’t know if it’s the same for Siemens.
Yeah, apparently v4 firmware for the S7-1500's is off to a rocky start. I haven't repro'd, but allegedly with v4.0.4, "The PLC may terminate the connection when two simultaneous connections read data larger than approximately 1300 bytes per request at short intervals."
I meant network latency between the gateway and PLC. Just ping the PLC from the gateway, you should see roundtrip time in milliseconds. Performance starts to tank as the network latency between the gateway and the PLC increases.
Do the AGL40_SYMBOLIC_PATH_UNKNOWN_FIELD errors eventually stop repeating? This error comes directly from the AGLink library when we attempt to resolve a node by its path. We shouldn't be attempting to resolve a node by its path until the symbols have completely loaded. If you stop getting those errors, I'm not sure what is going on.
5mins to load the symbols, then another 15+mins for the tags to finally appear in the opc browser
5 minutes to load the symbols could be explained by a slow network or PLC that is slow to respond. But, after the symbols have loaded, I'm not sure we need to make additional requests to the PLC for the OPC Browser to work. IIRC, all of the information we need for browsing is included in the symbol info. I'll have to take a closer look to see what could be causing this slowdown. As a sanity check, what does the resource usage on your gateway look like?
I’m told that there aren’t any more AGL40_SYMBOLIC_PATH_UNKNOWN_FIELD logged errors now after connections have come good / tags are reading values, and these opc item paths definitely do exist.
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.
