Professional OPC
Development Tools

logos

Online Forums

Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.

Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.

Do not use the Contact page for technical issues.

ReadMultipleItems returns old values (The same data will be collected.)

More
20 Dec 2022 08:53 #11360 by support
Hello.

I do not understand what you mean by "I checked the packet (tcp.port=135) through Wireshark and found that the request packet was not found.".
Please try to explain in more detail what you did.

Regards

Please Log in or Create an account to join the conversation.

More
20 Dec 2022 05:27 #11357 by yong
Hello
I am replying to you following the previous reply.

I upgraded to QuickOPC 2022.1.

I made a program using the OPC library, so I'm using it.
OPC program(Monitoring PC) -> OPC Server

Remote communication in progress. There is a phenomenon that the same value keeps coming once every two to three months.
I checked the packet (tcp.port=135) through Wireshark and found that the request packet was not found.
However, we are receiving the same value through ReadMultipleItems.
Have you ever had similar symptoms?

Resgards

Please Log in or Create an account to join the conversation.

More
14 Jul 2022 12:31 #11044 by support
Hello.

Here is what we suggest, in this order:

1. Upgrade to QuickOPC 2022.1. There have been bug fixes that can, at least in theory, cause this.
2. If upgrade to 2022.1 does not help, use read from device (see previous post).
3. If reads from device do not help, try to use OPC Analyzer (with our help) to get the trace f the communication between the OPC client and the server, and then analyze which side is at fault.

Regards

Please Log in or Create an account to join the conversation.

More
14 Jul 2022 10:40 #11043 by yong
I have to prove that OPC Server is the problem, not OPC Client.

OPC Version: QuickOPC 2021.3.


Regards

Please Log in or Create an account to join the conversation.

More
14 Jul 2022 10:02 #11041 by support
Thank you.

By default, QuickOPC uses "maximum value age" of 1 second. This can result in receiving values that are not completely up-to-date. But there can be other reasons (such as server problem) for the behavior you described.

On the QuickOPC side, you can reduce the "maximum value" to zero, by specifying a read from the device. See:

- opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...ems%20from%20the%20device.html
- opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...m%20OPC%20Classic%20Items.html

This is the "brute force" approach (reading from the device is discourage din OPC specifications, for performance reasons).

Also, please post here the QuickOPC version&build number you are using (there is an additional piece of advise if you are on some old versions).

Regards

Please Log in or Create an account to join the conversation.

More
14 Jul 2022 08:12 #11040 by yong
Yes. Opc client should have gotten the latest value(newer value). And after restarting the opc client, I got the latest values again.
When there are no problems, it is collected as a real-time timestamp.

As expected, it often occurs after OPC Server(Schneider)settings have been changed or restarted..(I can't test it. it might not be)

Best regards

Please Log in or Create an account to join the conversation.

More
14 Jul 2022 07:58 #11039 by support
Hello.

I first need some clarification. In your screenshot, you have highlighted the timestamps. But, the timestamp is just an information about when the data was collected, and it even does not have to change when the value itself has not changed. So, complaint about "old values" is not the same as "old timestamps". OPC Data Access should deliver the up-to-date values to you. But, the value does not necessarily have the timestamp close to the time of the OPC read.

So, do you have any indication that the actual *values* you are too old at the time of the reading? That is, that you should have received a different, newer value?

Regards

Note: It is true that by default, values from cache can be supplied to you. There are ways to control this. More about it after you answer this.

Please Log in or Create an account to join the conversation.

More
14 Jul 2022 06:29 #11038 by yong
Hello.
My English is not good enough..

ReadMultipleItems return old values. (The same data will be collected.)


Data from the OPC server (Schneider) is collected well by the OPC client, but sometimes the same old data is provided.
Then, turn off the OPC client and turn it on again to collect it normally. It seems to keep getting the last cache value of the OPC Server.
For your information, I'm using the polling method.

Is it a problem with setting up the OPC server (Schneider)? Or is it an opc client setting problem?


Best regards
Attachments:

Please Log in or Create an account to join the conversation.

Moderators: support
Time to create page: 0.056 seconds