OPC Problems - RSLinx and OpenOPC

[DLB 0]

I am using an OpenOPC client to talk to RSLinx to read and write PLC tag values. I'm finding that I occasionally get cached data returned when I do a PLC read. As an example, I have a Boolean tag that I can see on a PLC trace has dropped from 1 to 0, but I still get a 1 when I read via OpenOPC for a period of time before I get the most up to date value of 0 returned. I’ve noticed my PLC topic configurations in RSLinx have the “Polled Messages (mSec)” parameter (Data Collection tab) set to 1000ms. However, my OpenOPC clients set the update rate argument to 100ms whenever they read anything, which I thought would override the update rate specified in the RSLinx topic configuration, is that correct? After noticing this I changed the RSLinx Topic configuration so that poll rates match on both Server and Client, but I won’t know for a while whether it has helped or not. However, if my understanding of the client poll rate overriding the server poll rate is correct then I guess it won’t make much difference. Also, I'm seeing 2 other issues which I guess could be related but I am unsure: - I am seeing active topics/groups hanging around in RSLinx after I've closed all OPC connections (which looking at the OpenOPC code, should remove all groups: “self.remove(self.groups())”). I'm not really sure what is going on here? - I'm seeing a few RSLinx communication errors with the description of “Desc: A DDE/OPC Client has passed an invalid server handle while attempting a Remove Item call. Handle value is 0x79ac130.” i) How can I figure out what is causing this? ii) Is it logical to think that this could be related to the above issue where some groups aren’t being removed? iii) Snipped of an RSLinx communication error log below ---------------------------------------------------------------------------------------------------------------- -none- : -none- : 11/29/13 - 01:12:05 : 00h Items: -none- Type: READ Mfg: Allen-Bradley PlcType: Desc: A DDE/OPC Client has passed an invalid server handle while attempting an Async IO Read call. Handle value is 0x79ac130. Number of occurrences: 814 Last Error occurred: 11/29/13 - 07:59:02 -none- : -none- : 11/29/13 - 08:07:00 : 00h Items: -none- Type: READ Mfg: Allen-Bradley PlcType: Desc: A DDE/OPC Client has passed an invalid server handle while attempting a Remove Item call. Handle value is 0x79ac130. Number of occurrences: 1 Last Error occurred: 11/29/13 - 08:07:00 ---------------------------------------------------------------------------------------------------------------- Any help would be brilliant. Thanks.

[Mark- 17]

Hello, >I’ve noticed my PLC topic configurations in RSLinx have the “Polled Messages (mSec)” parameter (Data Collection tab) set to 1000ms. However, my OpenOPC clients set the update rate argument to 100ms whenever they read anything, which I thought would override the update rate specified in the RSLinx topic configuration, is that correct? No, the server is allowed to return the best time it supports. You ask for 100, the server returns 200, that is the best the server can do. >- I am seeing active topics/groups hanging around in RSLinx after I've closed all OPC connections (which looking at the OpenOPC code, should remove all groups: “self.remove(self.groups())”). I'm not really sure what is going on here? Per the specification removing groups marks them as removed. Then the server determines when to "delete" the group. There are several reasons a server will delay in deleting the group. > i) How can I figure out what is causing this? That can be tough. Logging OPC client actions and responses would be a start. > ii) Is it logical to think that this could be related to the above issue where some groups aren’t being removed? If the client is sending bad values for group handles then yes, the server only acts on the values from the client. > Desc: A DDE/OPC Client has passed an invalid server handle while attempting an Async IO Read call. Handle value is 0x79ac130. Ouch. Something is out of sync or misconfigured. As to the read delay; there are several ways to get data from the server sync/async read and cached or not (direct). Depending on the configuration this may be the cause of the delay. My2c.

[DLB 0]

Thanks My2c. From what you say then, lowering the poll rate in the OPC topic configuration in RSLinx may actually make a difference? If I understood your comments correctly, the 1000ms I have in the RSLinx sort of dictates the servers "best effort". Right? I have lots of logs so plan to try and correlate the handle errors in the RSLinx log to test logs showing the data we were attempting to read at the time the error occured.