Strange 800xa OPC behaviour with third party clients
Hello,
In our plant in Koog aan de Zaan we wrote our own MES environment which communicates with ABB 800xa by OPC. Since a few months we are running on IIT version 5.1d. From that moment we experience strange OPC behaviour. If a status of an OPC boolean changes from 1 to 0 e.g. we get multiple events that the status of the variable is 1 and finally an event occurs that the status has changed to 0. We wrote a test application specially to test this behaviour and we see that this problem doesn't occur in combination with version 5.1.a. A screenshot of one of the test results is attached.
We tested this on different 51.d servers installed by different companies. We use the opcsurrogate server to connect. Set all DCOM setting according to the manual.
Is anyone familiar with this problem and/or can help us to solve this?
Kind regards,
John
Answers
An OPC server should not send anything unless data value or quality has changed.
I have not heard of such a problem with the surrogate server before.
Your trace would be more useful if you also add a time stamp (with milliesecond resolution)
Can you add a Basic History property log with min time 1 second and NO max time for the property you are writing to and see what the Basic History log is receiving?
You can also try connecting a third party OPC client to the same item via the same surrogate and see if any weird updates are received there. The system has one built-in called advdsopcclient.exe. Problem is you will only see last update and if sequence is fast, you will probably not detect the intermediate values.
Hello Stefan,
Thanks for your reply on my question. The fact is that we expect one datachange event from the opc server at the moment we change the status of a variable. What we see is that from the moment we change the status first a few (random) datachange events occur with the current value and finally an event occurs containing the new value. For the status itself it's no problem but in our MES layer we react on events. If e.g. three events occur which says that a variable status has changed to true then we three times respond to those events in the MES layer. I've added a screenshot of a test with an 800xa 5.1a OPC server and one with a 800xa 5.1d OPC server. I've also added the test application which exists out of two files. One executable and one configuration file. In the configuration file you can set the ip adress of the OPC server and also the path to a variable to test with. Be carefull not to use a variable that is also written in the controller. You need .net framework 4.5.2 to be able to run the test application. Because of deadlines of projects we are not able to adjust the test program for responses with timestamps.
I have less time to go into any deeper investigations here on AKS (I need a proper support case created at regional ABB and escalated to me to be able to give full time and priority).
I also have hesitations to install any newer version of .NET than listed in the 3rd party software (3BUA000500 document, i.e. 3.5 SP1) as this is not tested with System 800xA. We have had a couple of ".NET mishaps" in our lab and we stick to the versions that come with 800xA. .NET 4 is not used until 800xA version 6. Even if .NET4 is said to be "detached" from previous versions we have seen issues with installing a newer version - sometimes they come bundled and all versions become updated to beyond what the system has been tested with.
I have not seen the behavior your OPC client show - I suspect some problem with double subscriptions, etc. A more detailed trace (with high resolution timing would be beneficial, especially when correlating with the logging I'm about to describe below).
I recommend this approach; first with ABB's built-in OPC test client (so that you get aquainted with the logging tool, etc.) then secondly with your OPC client application.
1. Deploy a Basic History property log with Min Time 1 second, no Max Time. Verify that the log is logging the property properly.
2. Start the ABB OPC test client (advdsopcclient) and connect to the surrogate OPC server.
3. Start applog logging tool (Start->Run... afwapplogviewer). You need to be logged in as a member of the IndustrialITAdmin group in Windows to launch this tool. Press OK in the two following dialog boxes.
4. Select node (where surrogate is started) and the surrogate application (repeat step 2 if multiple surrogates exist to be able to pinpoint the one associated with the test client)
5. Select the log named OPC Communicator Common and change log level to 3. Click the upper Now button then click Get Messages. Now, GetStatus() messages should scroll in the window every 5th second.
6. Add a 1 second OPC group and the OPC item of interest (the one logged in step 1)
7. Mark the item, define a new value to write click "Set", then click "Write"
8. Observe the output in the Basic History log and the applog tool.
9. Stop the log, or disconnect the OPC client to have surrogate to quit (the log will reset when the surrogate server stop).
10. Run the OPC Communicator Statistics operation with argument "D" (see second image). The output will show exactly what the client is subscribing to. Is the result what you expect, or is something "double subscribed"?
I assume only one update will be seen in the log, and only one "OnDataChange" sent via the OPC Surrogate server to the AdvDsOPCClient.exe
I have attached an image of the above.
Now repeat the same procedure again, but this time replace the advdsopcclient with your OPC client program.
I believe I have reproduced the problem in my lab!
In both 5.1RevD and 5.1FP4RevE I think I see an update with the old value a second before the newly written value is returned.
If I turn off audit trail, the intermediate update does not appear.
I believe the "control read" made when audit is enabled "bleed" to the client. No other clients are affected.
Since most I write here on AKS is "gossip" I recommend that you ask your regional ABB support center to file a support case. You may refer to the two threads you have written here on AKS.
Add new comment