- Forum
- Discussions
- QuickOPC-Classic in .NET
- Reading, Writing, Subscriptions, Property Access
- DAClient not getting changes / tags remaining active after disposing
DAClient not getting changes / tags remaining active after disposing
02 Apr 2019 19:47 #7290
by support
Replied by support on topic DAClient not getting changes / tags remaining active after disposing
Hello,
I think that the error handling is not correct in your code. Therefore, it is possible that what you describe as "not getting changes" are actually some errors, but they are "swallowed" - not indicated in any manner.
Please read this: opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...%20the%20actual%20result_.html .
In your code, if "e.Vtq Is Not Nothing", you further test whether "e.Exception Is Nothing" (and if it is not, you do "Debug.Print"). But, when "e.Vtq Is Not Nothing", e.Exception is *always* nothing. Either e.Exception is not Nothing - that indicates an error, and in such case, e.Vtq is Nothing. Or, if e.Exception is Nothing, then there is no error, and in such case, e.Vtq is never Nothing. So, in essence, these two tests can be replaced by one - usually by testing the e.Exception.
However, what's worse, in case that e.Vtq is Nothing, your code does not do anything (not even "Debug.Print"). This is where some communication errors can be "lost".
So, in essence, I suggest that the basic structure of the handler is like this:
I also suggest that in the error case, the problem is indicated to the user, and not just through Debug.Print.
After making this change, of course the underlying problem will not go away. But I think you should then see an error message which reflects what is happening, and possibly lead to finding the cause.
Regards
I think that the error handling is not correct in your code. Therefore, it is possible that what you describe as "not getting changes" are actually some errors, but they are "swallowed" - not indicated in any manner.
Please read this: opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...%20the%20actual%20result_.html .
In your code, if "e.Vtq Is Not Nothing", you further test whether "e.Exception Is Nothing" (and if it is not, you do "Debug.Print"). But, when "e.Vtq Is Not Nothing", e.Exception is *always* nothing. Either e.Exception is not Nothing - that indicates an error, and in such case, e.Vtq is Nothing. Or, if e.Exception is Nothing, then there is no error, and in such case, e.Vtq is never Nothing. So, in essence, these two tests can be replaced by one - usually by testing the e.Exception.
However, what's worse, in case that e.Vtq is Nothing, your code does not do anything (not even "Debug.Print"). This is where some communication errors can be "lost".
So, in essence, I suggest that the basic structure of the handler is like this:
If e.Exception Is Nothing Then
<no error; you can use e.Vtq right away>
Else
<an error - the details are in e.Exception>
End If
I also suggest that in the error case, the problem is indicated to the user, and not just through Debug.Print.
After making this change, of course the underlying problem will not go away. But I think you should then see an error message which reflects what is happening, and possibly lead to finding the cause.
Regards
Please Log in or Create an account to join the conversation.
- saratalley
- Topic Author
- Offline
- Advanced
-
Less
More
- Posts: 5
- Thank you received: 0
01 Apr 2019 11:12 - 01 Apr 2019 17:49 #7286
by saratalley
Replied by saratalley on topic DAClient not getting changes / tags remaining active after disposing
Private Sub Da_Client_ItemChanged(sender As Object, e As EasyDAItemChangedEventArgs) Handles Da_Client.ItemChanged
Dim ctl As Control = TryCast(e.Arguments.State, Control)
Dim stp As New Stopwatch
Try
Debug.Print("ITEM CHANGED Da_Client ctl name: " & ctl.Name)
stp.Start()
If e.Vtq IsNot Nothing Then
If e.Exception Is Nothing Then
ctl.Tag = e.Vtq.DisplayValue
ctl.Text = ctl.Tag
Debug.Print("ctl.tag :" & ctl.Tag.ToString & " ctl.name: " & ctl.Name)
If TypeOf ctl Is LedLight Then
sw.Stop()
LblTime.Text = sw.ElapsedMilliseconds.ToString
If ctl Is BtnStart Then
Select Case LblStart.Tag
Case "0" Or False
LblStart.BackColor = Color.Red
LblStart.Text = "Waiting.... "
Case "1" Or True
If Not Bgw_SendSetupData.IsBusy Then
Bgw_SendSetupData.RunWorkerAsync()
End If
Case Else
LblStart.BackColor = Color.Orange
End Select
ElseIf ctl Is BtnSend Then
Select Case LblStop.Tag
Case "0" Or False
LblStop.BackColor = Color.FromArgb(192, 0, 0)
Case "1" Or True
LblStop.BackColor = Color.Green
Case Else
LblStop.BackColor = Color.Orange
End Select
ctl.Refresh()
Else
ctl.Text = ctl.Tag
End If
End If
ElseIf e.Exception IsNot Nothing Then
Debug.Print("Error.")
End If
End If
stp.Stop()
Debug.Print(stp.ElapsedMilliseconds)
Catch ex As Exception
Debug.Print("Error with FrmMain ItemChange " & ex.ToString & vbCrLf & " Ctl problem? " & ctl.Name & " VAL? " & ctl.Tag.ToString & ".")
End Try
End Sub
Last edit: 01 Apr 2019 17:49 by support.
Please Log in or Create an account to join the conversation.
31 Mar 2019 09:21 #7285
by support
Replied by support on topic DAClient not getting changes / tags remaining active after disposing
Hello,
before we go to further analysis, can you please post here the piece of code that is the event handler for the data change event (or its shortened version, which can leave out the details). What I am looking for is to verify that you do not "miss" some changes by not properly testing for error conditions.
Thank you
before we go to further analysis, can you please post here the piece of code that is the event handler for the data change event (or its shortened version, which can leave out the details). What I am looking for is to verify that you do not "miss" some changes by not properly testing for error conditions.
Thank you
Please Log in or Create an account to join the conversation.
- saratalley
- Topic Author
- Offline
- Advanced
-
Less
More
- Posts: 5
- Thank you received: 0
30 Mar 2019 17:20 #7284
by saratalley
Replied by saratalley on topic DAClient not getting changes / tags remaining active after disposing
It seems like the QuickOPC fix actually didn't do anything to worsen or fix the problem I'm having. I can connect to another PLC every time no problem, with immediate tag values.
I am using tags from a real device. Sometimes I can get tag values immediately, and sometimes it can take up to 10 minutes for the data change event to occur. I tried connecting to another server (not a vm) which our plant uses for other programs. This bogged down the server and other programs began getting OPC errors.
I am using tags from a real device. Sometimes I can get tag values immediately, and sometimes it can take up to 10 minutes for the data change event to occur. I tried connecting to another server (not a vm) which our plant uses for other programs. This bogged down the server and other programs began getting OPC errors.
Please Log in or Create an account to join the conversation.
21 Mar 2019 07:36 #7248
by support
Replied by support on topic DAClient not getting changes / tags remaining active after disposing
There seems to be something else in play as well. The QuickOPC fix was of such a nature that it could not make it worse, I believe.
What do you mean "from separate processor"? - Is that from a different computer?
Are you using Kepware simulated tags/driver, or is it with tags from real device?
Regards
What do you mean "from separate processor"? - Is that from a different computer?
Are you using Kepware simulated tags/driver, or is it with tags from real device?
Regards
Please Log in or Create an account to join the conversation.
- saratalley
- Topic Author
- Offline
- Advanced
-
Less
More
- Posts: 5
- Thank you received: 0
19 Mar 2019 20:14 #7236
by saratalley
Replied by saratalley on topic DAClient not getting changes / tags remaining active after disposing
#1. I updated and as of now I have only been able to get data changes twice out of approximately 20 program runs and they are taking much longer to complete. Interestingly, though if I try to subscribe to and read/write tags from a separate processor, that one is always able to connect and the data change event fires no problem.
#2. The delay worked, but this shouldn't be an issue. I just wasn't sure if it had anything to do with problem #1.
#2. The delay worked, but this shouldn't be an issue. I just wasn't sure if it had anything to do with problem #1.
Please Log in or Create an account to join the conversation.
19 Mar 2019 16:36 #7231
by support
Replied by support on topic DAClient not getting changes / tags remaining active after disposing
There seem to be two issues:
1. Missing data updates.
2. Unsubscribing from items is not always reflected on the server.
Regarding #1: We have recently discovered and fixed a similar issue. You might be facing a different problem, but it could also be the problem we have fixed. Before we proceed further, please download and install the current QuickOPC 2018.3 from the Download page of our Web site. It should report itself as 5.54.1115.1 or later on the first page of the installation wizard. Or, use the recent package from NuGet. Rebuild your project with it, and re-test. We'll see what happens...
Regarding #2: It is likely that I know the cause. Unsubscribing works in an asynchronous manner. The method call returns quickly, and the actual Unsubscribe happens later. Dispose does not wait for the completion either. This behavior is by design - without it, users had opposite complaints - such as that they could not quickly close their forms, because unsubscribing also takes time - and in case of problems with the server, it can actually take very long time. Unfortunately currently there is no way for you to tell when the unsubscribe has truly finished, or wait for it. If the process terminates, the unsubscribe may not yet have been finished, and the items remain temporarily subscribed on the server. After some time, COM/DCOM infrastructure detects that the client COM objects are gone, and releases them automatically. In order to test this hypothesis, add - just for test - a delay of e.g. 5 seconds after the UnsubscribexXXXX call, and check whether the issue goes away. If it goes away, the hypothesis was right, but as I wrote, there isn't any real solution, only a workaround. The fact that the item subscriptions remain on the server, for some time, should not, however, normally have any influence on the issue #1.
1. Missing data updates.
2. Unsubscribing from items is not always reflected on the server.
Regarding #1: We have recently discovered and fixed a similar issue. You might be facing a different problem, but it could also be the problem we have fixed. Before we proceed further, please download and install the current QuickOPC 2018.3 from the Download page of our Web site. It should report itself as 5.54.1115.1 or later on the first page of the installation wizard. Or, use the recent package from NuGet. Rebuild your project with it, and re-test. We'll see what happens...
Regarding #2: It is likely that I know the cause. Unsubscribing works in an asynchronous manner. The method call returns quickly, and the actual Unsubscribe happens later. Dispose does not wait for the completion either. This behavior is by design - without it, users had opposite complaints - such as that they could not quickly close their forms, because unsubscribing also takes time - and in case of problems with the server, it can actually take very long time. Unfortunately currently there is no way for you to tell when the unsubscribe has truly finished, or wait for it. If the process terminates, the unsubscribe may not yet have been finished, and the items remain temporarily subscribed on the server. After some time, COM/DCOM infrastructure detects that the client COM objects are gone, and releases them automatically. In order to test this hypothesis, add - just for test - a delay of e.g. 5 seconds after the UnsubscribexXXXX call, and check whether the issue goes away. If it goes away, the hypothesis was right, but as I wrote, there isn't any real solution, only a workaround. The fact that the item subscriptions remain on the server, for some time, should not, however, normally have any influence on the issue #1.
Please Log in or Create an account to join the conversation.
- saratalley
- Topic Author
- Offline
- Advanced
-
Less
More
- Posts: 5
- Thank you received: 0
18 Mar 2019 11:52 #7226
by saratalley
Replied by saratalley on topic DAClient not getting changes / tags remaining active after disposing
1. We are using QuickOPC2018
2/3. We are connecting to KEPServerEX.V5 (remote server) and KEPServerEX.V6 (vm) - the problem persists on both.
4. At the bottom of the screen where it lists the number of clients, right next to that is: "Active tags: x of x"
I can go into the PLC and manually toggle a test bit I have subscribed to and the change will not always be seen in the .net ItemChanged Event
2/3. We are connecting to KEPServerEX.V5 (remote server) and KEPServerEX.V6 (vm) - the problem persists on both.
4. At the bottom of the screen where it lists the number of clients, right next to that is: "Active tags: x of x"
I can go into the PLC and manually toggle a test bit I have subscribed to and the change will not always be seen in the .net ItemChanged Event
Please Log in or Create an account to join the conversation.
16 Mar 2019 12:28 #7219
by support
Replied by support on topic DAClient not getting changes / tags remaining active after disposing
Hello,
can you please answer some questions:
1. Which version of QuickOPC are you using?
2. Which OPC server are you connecting to, and which version?
3. Is your application (OPC client) on the same computer as the OPC server, or is it remote, with use of DCOM?
4. Where in the server are you observing the active tags?
Thank you
can you please answer some questions:
1. Which version of QuickOPC are you using?
2. Which OPC server are you connecting to, and which version?
3. Is your application (OPC client) on the same computer as the OPC server, or is it remote, with use of DCOM?
4. Where in the server are you observing the active tags?
Thank you
Please Log in or Create an account to join the conversation.
- saratalley
- Topic Author
- Offline
- Advanced
-
Less
More
- Posts: 5
- Thank you received: 0
15 Mar 2019 18:57 #7217
by saratalley
I have a .Net application in which I am using EasyDAClient. On starting the app. I run SubscribeMultipleItems to read approximately 600 tags. Sometimes when I run the app the tags populate my controls (textbox.text, etc.) correctly - this is done through the ItemChanged event. Other times it can anywhere from 5-10 minutes for the ItemChanged event to fire - this should obviously happen on startup and anytime a tag value changes. On closing the form I unsubscribe all items and dispose of the client. On the server I have noticed that the client will be disposed, but sometimes it will show 0 of 600 tags active - if I run the app a second time the number will be 600 of 1200 tags active, this doubles each time on restarting the app. If I wait a period of time (I haven't clocked it but it seems to be between 5-10 mins) eventually it will drop to 0 of 0 tags active, and I can run the app and tags usually (90% of the time) begin to populate correctly again. Any help on what I am missing would be appreciated.
Please Log in or Create an account to join the conversation.
Moderators: support
- Forum
- Discussions
- QuickOPC-Classic in .NET
- Reading, Writing, Subscriptions, Property Access
- DAClient not getting changes / tags remaining active after disposing
Time to create page: 0.215 seconds