I was wonder if anyone knows a good way of connecting a couple of Siemens S7 1515F/1516F PLC’s (TIA V16 in seperate projects, later switching to V17) to Ignition.
The build in driver in Ignition is no option as it doesn’t do optimized blocks.
Currently we are using the build in OPC UA server inside the PLC. However we are running/exceeding its limits. We are over the recommended 2000 elements. We are already reading whole structs and making derived tags from it in order to minimize the elements. However this is already a workaround in in my opinion as when you are writing multiple derived tags at the same time from a single OPC tag it messes up (only writes the first or last one, don’t remember correctly).
I have tried letting Kepware do the heavy lifting and accessing that OPC UA server with kepware, which kinda works. But also bogs down the communication load of the PLC CPU. (and kepware doesn’t understand wstrings which is a bummer)
Now I’m looking into using Simatic NET OPC, but dont know if that will work either.
Ideally I would like to read/write around 8000 PLC tags directly without a decent update rate (say 1sec or so). and other ones with a slower rate
Anyone have a good suggestion or thing that works for you?
You could take some of the load off the PLC with one of these but not sure how much difference it will make since you still have to access the tags. But on the plus you can browse all your tags and DB’s, optimized or not.
Yes you can use it with non optimized blocks. However this is something we dont want to do. It defeats all the nice things that optimized gives you. and its slower for the plc to run
This also works with derived tags from a single OPC tag (with the jsonGet / jsonSet magic)? as i would expect if you write a derived tag it pushes to the OPC Tag. but if i write another derived tag within the time the OPC tag is read from the plc (retreiving the new values). what would happen to the second tag being written? wouldn’t you loos information with this?
The "Optimistic Write" setting exists to solve this race condition. The "optimistic" part is that it applies the write mutation to the value in memory immediately, so that subsequent writes also mutate the recently mutated value, and rolls it back if it turns out the write failed.
This helped with that issue, good tip. And playing with the opc settings in the plc and taggroups helped improving the perfermance alot.
However what i dont understand in Tag groups (regarding OPC tags) is “Rate” and “Publishing interval (ms)”. If i set rate to 1000 and publishing to 500. what will it do? its kinda vague in the manual.
Tag group rate corresponds to OPC UA MonitoredItem Sampling Interval, which is pretty much what you’d expect - how fast you’re asking the server to sample an underlying value.
OPC UA subscription change notifications are delivered in batches, the Publishing Interval is how often the server will deliver all the queued change notifications for all the items that belong to it.