I've done quite a bit of digging and still coming up short.
In the PLC, I have Function Blocks and the instances create Instance Data Blocks. Each IDB consists of ~50 tags. In Ignition, my path would look :
[PLC_3]nsu=http://www.siemens.com/simatic-s7-opcua;s="AI_1"."HAlarm"
where 'AI_1' is the IDB name and 'HAlarm' is a FB parameter.
This wouldn't be an issue, however, the PLC I'm using is limited to 10,000 monitored items which we would probably reach in some applications: one IDB to Ignition UDT would use 50 items.
I've seen others create Structs inside the FB and then parse the json with derived tags. I tested this and it appears that the whole structure would only use one monitored item. Is this the best way to accomplish what I'm trying to do? Will I just be shifting "too much data" from multiple items to one item?
Thanks!
Depends on what you need to write. The "structure as single item" solution also requires all-or-nothing writes.
Consider a mix of both.
Reading structs is better for the S7 server performance than reading the individual items that might make up a struct. You do have to consider the all-or-nothing writes as @pturmel suggested, unless you can do the writes from scripting and derive the NodeId so that the write call can target just individual Nodes.
Another hack some people have used is Tag Groups configured in OPC Read mode, essentially polling the server using the Read service instead of subscribing.
1 Like
Trying to think of the implications of the all-or-nothing writes.
For example, a lot of the items are configuration parameters. I would like to be able to configure the values from Ignition and also in the PLC. Would there be an issue here?
I've done some testing and everything seems to work as intended. The only issue I ran into was if I try to edit tags in quick succession, only the last one takes. I found this post and turned on optimistic writes and allowed data backfill on the tag provider. Thanks!