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.

DAClient not getting changes / tags remaining active after disposing

More
02 Apr 2019 19:47 #7290 by support
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:

                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.

More
01 Apr 2019 11:12 - 01 Apr 2019 17:49 #7286 by saratalley
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.

More
31 Mar 2019 09:21 #7285 by support
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

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

More
30 Mar 2019 17:20 #7284 by saratalley
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.

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

More
21 Mar 2019 07:36 #7248 by support
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

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

More
19 Mar 2019 20:14 #7236 by saratalley
#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.

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

More
19 Mar 2019 16:36 #7231 by support
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.

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

More
18 Mar 2019 11:52 #7226 by saratalley
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

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

More
16 Mar 2019 12:28 #7219 by support
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

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

More
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
Time to create page: 0.098 seconds