Update Count and Refresh Rate

[ScottInTexas]

When I click on "Launch Quick Client Here" the quick client opens showing 640 tags. Most of which are unwanted. I have the timestamp for the opening time, quality Good and Update Count 1. All but two of the update count values remain at 1 and the time stamps for those value remain at the starting time. Two tags are updating every couple of seconds. Of the rest of the tags 7 are marked Bad. In the KepserverEx event log there are 12 tags marked "Unable to read tag" with a CIP Error = 0x5. Am I really getting data from the PLC? How can I tell if this is accurate? How do I make the other tags update like the two anomalies?

KepserverEx 6.14.263.0

Thanks for the help.

[cmorehead]

@ScottInTexas

It sounds like you added the tags to the KEPServerEX Configuration through the Automatic Tag Generation

 which pulls in all the tags that are Globally Scoped. You can go inti the configuration and delete all of the unwanted tags.

If the automatic tag generation was successful, then you are at least connected to the PLC.

Here is a link to the Kepware Knowledgebase Article that cover the CIP Error = 0x5:

Article - CS286352 - Received CIP 0x05 Error Message from Allen-Bradley ControlLogix Ethernet Driver in PTC Kepware Products

My Kepware login credentials will be needed to access the article.

I recommend opening a support ticket with the Kepware team to provide a full analysis of your specific architecture. Here is a link the login page where a ticket submitted:

Log In | My Kepware

Thanks,

*Chris

[ScottInTexas]

Thank you, Chris, for replying.

I should have added that this is connected to an Omron PLC. I am not all that concerned with the CIP Ox5 error. My biggest concern, or primary question, is why do only two or three tags update? How do I make everything update? Each tag is set to 100ms, but the Group Update Rate Option is set to 1000ms . But watching for minutes only shows 3 being updated.  I just checked and  of the three updating tags one stopped at Update Count 7739, another at 7418, the third stopped at 10236. This was since Friday morning.

Thanks,

[cmorehead]

@ScottInTexas 

Ok, so the Omron error is typically an indication of the following:

Error message: CIP error = 0X5, Extended error = 0000 in PTC Kepware Products

Description

• Omron NJ Ethernet driver returns CIP error = 0X5 when trying to read a tag within KEPServerEX / ThingWorx Kepware Server
• Omron NJ Ethernet drive tags show Bad quality in QuickClient
• Error indicator CIP error = 0X5, Extended error = 0000 in event log

Additional Context

Cause

• CIP error = 0X5 indicates :
  • Path destination unknow
  • Structure member does not exist or array element is out of range

Resolution

• Suggestions are :
  • Increase value of  Request Timeout (ms) and Inter-Request Delay (ms) property of device
  • It needs to check/review tag address and PLC address by PLC owner

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

100ms seems may be too fast for this type of device. What is your client scan rate set to? The recommendation of increasing the Request Timeout in the device properties should allow more time for the device to respond. 

I definitely suggest opening a ticket so other diagnostic tools can be used to assist with troubleshooting.

Thanks,

*Chris 

[ScottInTexas]

Hi Chris,

Still working at this. I have the Client scan rate set to 1000ms. Do you think 1 second is too fast? 

Scott

[cmorehead]

Hi Scott,

1000ms scan rate should be fine. The CIP error is coming directly from the device and indicates there is at least a successful connection. I recommend opening a support ticket so the Kepware team can take a closer look at your exact architecture. 

Thanks,

*Chris

[ScottInTexas · Accepted solution]

I have finally found the answer to this question. It must be in the manual somewhere, but I failed to see it. The update count I was looking at does not change if the value is the same as the last reading. So some update count values may remain 1 forever because there is no change in the reading to update.