I tried creating a connection to a s7-1500 but when I save the connection the connection page stays empty, I cannot create any new connections as well
wrapper.log file(s) please.
Sometimes there can be a delay on the connections page when the connection attempt takes a while. However, if this is the problem I'm thinking of, it should be resolved within a minute or so.
If you can set the siemens driver logs to debug and share those as well, that may be helpful.
It was indeed a wait because a setting was wrong, I moved to a windows vm instead docker and now have a working connection
new issues:
- plc browser does not refresh, I need to disable en re-enable the connection to get a refresh
- same for newly added data to the plc, tags will not communicate until connection is reset
There's supposed to be some UI like this lets you refresh the browse, but it's apparently not implemented yet:
In the meantime you can disable/enable or edit/save the connection to force a rebrowse.
There doesn't appear to be any way to learn about tags being added/removed and rebrowse automatically with the S7+ protocol.
How long did you have to wait before the connections page was responsive again? Obviously too long, and I have a ticket for this.
PLC Browser refresh
Kevin's right. We have this implemented on the backend, but hasn't made the priority list on the Web UI, yet. There's a web api route you can call to do this yourself, but it is more "implementation detail" than "public API." Meaning, it may be subject to change.
Im not sure, i checked again after 5 minutes and the connection was there, but faulted.
1 Like
Have you guys done bulk testing with the driver. if so what where your results ?
I measure the actual pollrate by reading the PLC clock in milliseconds in a tag and then compare it to a previous value. im already seeing values of 1160 ms on a 1 sec pollrate with 3900 tags. the value only increases when adding more tags.
adding multiple connections does help, but I dont want to create dozens of connections.
This could limit what we can do with 1 plc, even the largest
I did some rough benchmarking fairly early in the development of this driver, and it's on my list to revisit to get some more formalized results. The numbers I got were rough and probably aren't fit to share as a "you can expect this" type of result. That being said, by far the largest factor for performance that I observed with this driver is network latency. For example, a large read request that takes 30 seconds at ~90-100ms latency, may take less than 20 seconds with ~30ms latency.
Generally, you should see better performance than our legacy drivers. How much better will depend on your specific use case. (Symbolic/absolute, which model PLC, PLC busyness, network latency, optimized vs non-optimized data blocks, contiguous vs non-contiguous tags, etc).
As I mentioned, I don't have good benchmarks that are worth sharing, but 1160ms to read 3900 tags with symbolic access is fairly in line with the performance that I was seeing. Although, I was measuring a bit differently than you are.
I'd love to hear more about your use case and expectations for performance. How many tags would you typically want to read at a 1 second rate? Do you have other tags that you would poll more slowly?
I'm also excited about new s7+ driver and I've observed the same behavior as @Pdeswert.
The changes in the PLC are not 'reflected' in the tag browser until you disable and re-enable the driver.
There are buttons for 'Refresh' in the OPC server tag browser, but apparently they are not doing what they're supposed to do...
They're doing what they're supposed to, they're just not doing what you think they are supposed to. They just refresh the browse at the OPC level (between client and server), they don't instruct the driver to rebrowse for symbols.
Do the disable/enable or edit/save as I mentioned earlier. There should be a button in the gateway UI for refreshing on its way.
2 Likes
OK, understand.
But, if you (IA) can add button in the gateway UI for refreshing, then would be more convenient to have that button also in the OPC server tag browser, beside the existing one...? 
That's a generic piece of UI for not just OPC UA, but all kinds of OPC connections (yes there's only 2...), from any vendor including third party. A button for an IA driver-specific action doesn't belong there.
OK, I understand.
What I want to say is, that would be very nice if we could have that kind of 'button' in the designer also... somewhere...
1 Like
I am now able to get arround 50k of tags (pointing to UDT members in the PLC) from a s7-1515 with firmware 3.1 at a 1 second pollrate, but there is a delay in value update between 1 and 2 seconds.
The symbolic adresses matter allot, when data is nested deeply (UDT in UDT or multi instance DB) in the PLC it will take more time to communicate.
I did not find any difference between software unit and regular program.
Setting the taggroup to polled instead of subscribed makes a big difference.
Problems I found:
- The gateway crashed twice when creating a PLC connection (at 10h and arround 13h)
- Creating to many tags at once ( 1500+ with multi instance wizzard) seems to crash the driver, I had to reboot the gateway in order for the tags to start polling again
- leased tag group with a non leased rate of 0ms (tag goes to sleep) does not work, the tag keeps polling. In our case this is 80% of the data, it would mean a big optimization.
- memory leak, while ignition was using 11/32 gb of ram, the ram usage still got to 100% many times and I had to reboot
wrapper log should be attached ( I did censor the IP adresses)
wrapper.log (8.9 MB)
2 Likes
Thanks! I'll be taking a look at these issues today. I may reach back out for more information.
Iām curious to see if there is an improvement with firmware 4 for those plc. We could clearly see an improvement with opc ua. I will try at work tomorrow
I'm setting up an environment to try to reproduce these issues specifically. I suspect there is more going on here that may include other parts of Ignition. Your wrapper logs do not have any entries that point to the Siemens driver. This isn't to say the Siemens driver isn't at fault for at least some of these issues.
If you can, set the Siemens related loggers to Debug, try to repro some of the issues you have seen, and share the logs with me. You can upload them at this dropbox link: https://www.dropbox.com/request/ilZgcCn8hJgcWdrPPEfi