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.

MonitoredItemChanged datachange occured after 3 minutes tag was changed

More
12 May 2015 06:43 #3122 by adid@contel.co.il
hello,

thank you.

you can close this issue.

thank you,
Adi Damty

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

More
11 May 2015 19:37 #3118 by support
Hmm, the posts are numbered on the right side to their titles, but links to them doe't seem to work well. I meant your post dated 07 May 2015 10:29.

Given the type of issues and requirements you have, I still suggest to set Isolated to true.

Best regards
The following user(s) said Thank You: adid@contel.co.il

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

More
11 May 2015 07:31 #3110 by adid@contel.co.il
hello,

first of all thank you for your answer.
it's seems to see that the problem, reading and writing was taking a lot of time, resolved after using EasyUaClient for each thread. but i didn't set the property Isolated to true, should i do it right now ?

also i didn't found post #3094 can you attach link to it ?

thank you,
Adi Damty

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

More
11 May 2015 07:00 #3108 by support
Let's keep this thread for now; but in future, whenever it is clear that there are separate issues (and I understand that sometimes it is not known upfront), it is much better to maintain separate forum threads.

I think I know understand much of what is happening. I have not known (or, I might have overlooked? somewhere in your posts), that you are accessing EasyUAClient from multiple threads.

If this happens, it is by design that we serialize the calls (it is not precisely queuing, but it may appear as such). The serialization is by design, and it is done *per client session*. That is, if you have one session open to your target server (more about it later), calling an operation from one thread blocks until operations being performed on that one session from other threads complete (this applies to ReadXXXX, WriteXXX, BrowseXXXX and similar, it does not directly apply to SubscribeXXXX/UnsubscribeXXXX). If, however, you used sessions that work with two different servers, or two sessions that target the same server, this serialization does not happen.

This explains many of the issues you reported (not sure about them all, especially you very preceding post, but it is a start).

If you want to truly perform multiple operation on the same target server at once, (and if the server supports it - I do not known that - it may serialize on its side as well), then here is what you should do: Create one EasyUAClient instance for each activity that needs to be kept in parallel (this may be, in your case, one in each of your threads). Right after 'new'-ing it, set its Isolated property to 'true'. This will case it to use a separate session for its operations. This of course requires some more resources, but it should not be a problem.

Can you please do this, and then let me know if there are still problems outstanding?

Some more information:

A. Unless there is a specific reason that I do not know, why don't you replace the periodic reading threads (e.g. 1 and 2 in your forum post #3094) simply by OPC subscriptions as well? Besides other advantages, it won't create that much blocking.

B. While the "one operation at a time per client session" behavior described above is by design, the OPC UA subscriptions should - ideally - run unaffected by that. BUT, I have now quickly looked into the implementation of the OPC UA .NET Stack (which we use on the lower level, and it is a code from OPC Foundation), and, to my bug surprise, I have found that this may not be the case. If so, we will probably have to put some workaround into QuickOPC, but clearly the developer won't expect that Reads, Writes etc. should be able to "damage" the ongoing subscriptions. Using a separate EasyUAClient with Isolated = true would currently be a workaround here as well.
The following user(s) said Thank You: adid@contel.co.il

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

More
07 May 2015 08:36 #3095 by adid@contel.co.il
hello,

i forget to mention still when the RealTimeTags thread and RealTimeRawMaterialTags threads are diabled, it takes 11-12 seconds to read 8 tags using readMultipleValues - can i reduce this time ?

thank you,
Adi Damty

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

More
07 May 2015 08:29 #3094 by adid@contel.co.il
hello,

do you want me now to open new case for it, or just next time ?

i was investigating this case yesterday with Kepware, the server vendor, about 3 hours with wireshark and we saw that it's takes the server 200 miliseconds to write the tag, and the kepware get the write request after 11-12 seconds (the write request that was sent in 20:19:01 due to my logs ).

i would explain about my threads in my code :
1. I am using one thread that read 10 tags in each 3 seconds ( this is the first easyUAClient i am using ) - let's call this tags RealTimeTags.
2. I am using One thread that read 4 tags each 1 minute ( this is the second easyUAClient i am using ) - let's call this tags RealTimeRawMaterialTags.
3. I am using two more threads ( each tread for specific line ) that each thread listen to 5 dataChange event and for example after coilStatus tag change if the value is bigger than zero than i am reading 20 tags, operate store procedure in my DB, and than set CoilStatus tag to zero.
i am using 2 more easyUAClients for this two threads ( each thread is specific line ).
in this two thread when i am reading the 20 tags, this tags contains the RealTimeTags tags, and the RealTimeRawMaterialTags.

now i am thinking i found the problem :

i disable the 3 seconds thread and 1 minute thread and now it's working fine - the time for read and write is good.
than i enable the 1 minute thread ( the 3 sceonds thread is still disable ) - and than i saw the read coilStatus tag taking sometimes 1 second and sometimes 6 seconds. i think what causing this is that the CoilStatus tag write is puttng in the queue and when it's the exactly same time that i read the RealTimeRawMaterialTags tags than it's waiting to this tags to be read and just after it write the coilStatus tag. i don't understand why its behave like this, and how to solve this, if i am using one EasyUAClient in thread RealTimeRawMaterialTags, and another EasyUAClient in CoilStatus dataChange and reading and writing tags.

thank you,
Adi Damty

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

More
06 May 2015 20:31 #3092 by support
Alright, you are changing subject here; please start a new thread in such cases.

The original problem does not need Wireshark to troubleshoot at all; the 3 minute time period is between source value change and the server sending it out, thus there is hardly anything to look at with Wireshark.

To the slow "write" issue: Unfortunately I do not see enough of a Wireshark data to be able to tell more. It would have been helpful if you could send that. One possibility is that what takes the long is an additional read that we may have to do before the Write when the data type is not specified. Can you please post a couple of lines of your code that call the Write?

Thank you
The following user(s) said Thank You: adid@contel.co.il

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

More
06 May 2015 18:11 #3087 by adid@contel.co.il
Hello,

i talk with the Kepware vendor today about this problem, and we try to figure out what is the problem and we use wireshark.
i wasn't able to preduce the problem that dataChange event taking 3 minutes, but we are able to preduce the problem that reading and writing using opcLabs is taking a lot of time - i will exaplain :

as you can see in the imgae attached the coilStatus read, just reading one tag, takes 12 seconds ( see in red box in the image ) :

2015-05-06 20:19:01 – readNewCoil line 2406 before write tag CoilStatus seconds 22.4977988
2015-05-06 20:19:13 – readNewCoil line 2406 after write tag CoilStatus seconds 34.4755457

also you can see in the image ( in yellow ) using wireshark the server get the call only at
20:19:13 - 12 seconds after i made the call in my service using opcLabs client.
and the server response withing 100 milliseconds.

and this is just one example it's happened a lot, what could causing this just reading one tag takes 12 seconds ?

thank you
Adi Damty
Attachments:

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

More
06 May 2015 06:26 #3083 by support
With the problem at hand, there is absolutely no need to tweak the keep-alive mechanism. It works fast enough. The connection *is* alive. It is just that the server does not think it should send the data at the moment you intended.

The cache reads *are* the default.

By specifying a different maximum age with the read, depending on your application needs, you can choose a read from the device (zero), or something in between - the server should then make a decision where to take the value from.

Best regards
The following user(s) said Thank You: adid@contel.co.il

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

More
06 May 2015 05:58 #3082 by adid@contel.co.il
hello,

i am checking the problem with Kepware - i will notify when there is progress.
is there any settings i can put to EasyUAClient so the Keep Alive Mechanisam work faster ?
can i use cache read instead of device read when using readTag in opcLabs dll ?

thank you,
Adi Damty

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

Moderators: support
Time to create page: 0.061 seconds