Bedrock PLC Polling

Ignition
1

I have a bedrock PLC that faults tags if I have too many in the same polling group. Has anyone have issues with bedrock PLCs?

2

Can you explain this in more detail? Are you trying to tell us that after a certain number of tags in a Tag Group the server in the Bedrock PLC starts returning Bad_TooManyMonitoredItems when corresponding Monitored Items are created?

What are you seeing? What's in the logs?

3

If I change the tag group on a tag, all other tags using that tag group go to "Bad" state.
If I change the selected tag to a different tag group the "Bad" tags work again.

4

What version of Ignition are you using?

Turning these loggers to DEBUG level may help figure out what's happening:

  • OpcUaSubscriptionModel
  • OpcUaSubscriptionSyncrhonizer
5

I just upgraded my customer from 7.9.5 to 8.1.39

6

Might be easier if you call support and let them take a live look.

7

Thanks, I might do that

8

If anybody from the future stumbles into this thread, it turned out to be a problem with the size of the Read requests being assembled by Tag Groups that were configured with an OPC data mode of Polled instead of Subscribed.

The relevant error in the logs was something like:

E [o.e.m.o.s.c.t.u.UascClientMessageHandler] [12:25:17.520]: Error serializing ReadRequest(requestHeader=RequestHeader(authenticationToken=NodeId{ns=1, id=10}, timestamp=DateTime{utcTime=133580211175200000, javaDate=Fri Apr 19 12:25:17 CDT 2024}, requestHandle=55921, returnDiagnostics=0, auditEntryId=null, timeoutHint=120000, additionalHeader=null), maxAge=0.0, timestampsToReturn=Both, nodesToRead=...

The solution turned out to be lowering the "Max Per Operation" setting on the OPC UA connection. It seems the server in the Bedrock PLC is/was configured with a relatively small max message size at the transport layer, and a relatively large (or unspecified) Max Nodes Per Read at the application layer.

3 Likes