SIMATIC WinCC Open Architecture Forum

Hello Support Team,

We're facing a UI-Crash ( Full, Desktop-UI and Web ) in 3.15p23 and 3.16p14 when we execute a dpDisconnect() on 'xxx:_alert_hdl.._act_state'.
A DebugTN() print of the specific datapoint element on 'connect' and 'disconnect' with their return-values looks like this:

WCCOAui2:2019.10.22 09:33:43.053["doConnect"]["System1:93001703.Status.DS1.b08:_alert_hdl.._act_state"][" RTN:0"]
WCCOAui2:2019.10.22 09:33:43.054["doConnect"]["System1:93001703.Status.DS1.b09:_alert_hdl.._act_state"][" RTN:0"]
WCCOAui2:2019.10.22 09:33:43.055["doConnect"]["System1:93001703.Status.DS1.b10:_alert_hdl.._act_state"][" RTN:0"]
WCCOAui2:2019.10.22 09:33:43.055["doConnect"]["System1:93001703.Status.DS1.b11:_alert_hdl.._act_state"][" RTN:0"]
WCCOAui2:2019.10.22 09:33:43.056["doConnect"]["System1:93001703.Status.DS2.b00:_alert_hdl.._act_state"][" RTN:0"]
WCCOAui2:2019.10.22 09:33:43.057["doConnect"]["System1:93001703.Status.DS2.b01:_alert_hdl.._act_state"][" RTN:0"]
WCCOAui2:2019.10.22 09:33:43.059["doConnect"]["System1:93001703.Status.DS1.b15:_alert_hdl.._act_state"][" RTN:0"]
..
..
WCCOAui2:2019.10.22 09:33:44.661["doDisconnect"]["System1:93001703.Status.DS1.b08:_alert_hdl.._act_state"][" RTN:0"]
WCCOAui2:2019.10.22 09:33:44.661["doDisconnect"]["System1:93001703.Status.DS1.b09:_alert_hdl.._act_state"][" RTN:0"]
WCCOAui2:2019.10.22 09:33:44.661["doDisconnect"]["System1:93001703.Status.DS1.b10:_alert_hdl.._act_state"][" RTN:0"]
WCCOAui2:2019.10.22 09:33:44.661["doDisconnect"]["System1:93001703.Status.DS1.b11:_alert_hdl.._act_state"][" RTN:0"]
WCCOAui2:2019.10.22 09:33:44.661["doDisconnect"]["System1:93001703.Status.DS2.b00:_alert_hdl.._act_state"][" RTN:0"]
WCCOAui2:2019.10.22 09:33:44.661["doDisconnect"]["System1:93001703.Status.DS2.b01:_alert_hdl.._act_state"][" RTN:0"]
WCCOAui2:2019.10.22 09:33:44.661["doDisconnect"]["System1:93001703.Status.DS1.b15:_alert_hdl.._act_state"][" RTN:0"]

> The Connects and Disconnects are executed in a loop.
> The Crash occurs when in this example the 'last' 'Disconnect()' is executed.
> An isolated 1by1 test showed us that the UI kept running for all the Disconnects except for the Disconnect on b15.
> The Crash only occurs on 1 or 2 datapoints in a whole project of over 8000 datapoints. The datapoint shown above is not the only one of its type, all other datapoint withing the Type ( With the same alarm-configuration ) do not crash the UI.
> During bug-tracing we found out that the Crash only happens when the UI is running under a manager-number higher then 1. A UI with Mannum-1 does'nt crash.

An export of the datapoint doesn't show any obvious differences with other datapoints which are constructed in the same way.

1) I suspect the database to be somehow corrupt but how to further analyse it?
2) In my opinion the UI should not crash on executing a Disconnect, is there a bug in UI under these circumstances ( Mannum higher then 1 )?
3) Are there any users who faces similar issues?
4) Can we get more info from a Disconnect() execution?
4) What are the approaches to resolve this problem?

The windows-eventlogger shows the following error.

Faulting application name: WCCOAui.exe, version: 3.15.0.0, time stamp: 0x5d931a88
Faulting module name: Qt5Core.dll, version: 5.5.0.0, time stamp: 0x5a0ec037
Exception code: 0xc0000005
Fault offset: 0x0000000000083143
Faulting process id: 0x4dda8
Faulting application start time: 0x01d585cea77b2067
Faulting application path: C:\Siemens\Automation\WinCC_OA\3.15\bin\WCCOAui.exe
Faulting module path: C:\Siemens\Automation\WinCC_OA\3.15\bin\Qt5Core.dll
Report Id: 106f7ce9-3833-4b89-80e1-d32bb6a6bc05
Faulting package full name:
Faulting package-relative application ID:

It should not make a difference which manager number and also which datapoint element is used.
A problem at a dpDisconnect() does not give any information for a corrupted database as the connect function is only a task between the UI manager and the Event Manager.

What it the use case of doing a dpConnect() and dpDisconnect() in a loop?
Why are you using dpDisconnect() in your script?

Best Regards
Leopold Knipp
Senior Support Specialist

Hello Leopold,

The use-case is that we have an information 'table' in an always visible module. This table contains details of an object/symbol ( Description of Bit, its state Active or Inactive and its Alertstate ) . An object can be selected in another module -> The table need to show the details, or un-selected -> table should become empty. We use a central-datapoint to inform all graphical objects that need to act on selection. A selection can be done by clicking on an object, but can also be done be selecting an alertline, or typing its name in a searchbox, etc.

Most of the symbols look similar ( simple rectangle ) but are connected to objects of different-types, with different details. The Types are constructed in a similar way, the details can be found via a generic way. With this construction we only have to maintain a single panel and single script for all types we encounter, even in the feature, to show its details.

Unfortunately the UI-mannumber makes a difference, we have it reproducible on two different projects running on different hardware.
The behavior is as desribed.
> When running a user-interface as mannum-1 no crash occurs, otherwise it crashes.
> When we skip the dpDisconnect() the user-interface keeps running, otherwise it crashes.
> When we only skip the dpDisconnect() for the specific bit15 the user-interface keeps running, otherwise it crashes.
> When we only dpDisconnect on bit01 the user-interface keeps running, if we dpDisconnect on bit15 it crashes.

When we look with gedi in the alert-details of bit15 no problems can be found, the alert itself is working as it is supposed to do.

LS,

For the described use-case, could there be an other approache to reach the same goal?

In addition:
- The always visible component uses 'layout' management. We want to limit the switching ( dynamic loading and unloading ) of objects inside the layout.

In your description you have written that you are using a "table" object to show the details.
Is it really a table object or someting other?

When you are using a table you can possibly use the following approach:
-- On a central datapoint element the information is stored which objects shall be shown
-- The "table" is defined as panel reference and reads the information which objects are selected
-- If the selection is changed the reference is removed by removeSymbol()
-- Afterwards the table is added again with addSymbel()

When doing removeSymbol() the connects are destroyed automatically and there is no need to do it by script.

Best Regards
Leopold Knipp
Senior Support Specialist

Hello Leopold,

Thanks for the suggestion.. I don't know if your approach can work in our scenario, but I definitely see some other locations where we can make use of this approach.

Since this week we think we found the cause of the Crash of the UI.

The structure that we use for the filling of the details table is the following,
1) We have a dpConnect(xx) construction a field that gives us a new selected object.
2) The callback gives us the DP from which we can get the details and fill the table -> we applied 'synchronized' for this callback
3) We want the details be dynamic ( alarm-states ), thus we additionally made a dpConnect to all alert-states of alarms belonging to the details
4) The callback with alarmdata is used to update the table-rows -> we didn't applied 'synchronized' for this callback.

On selection of a new object the 'dpDisConnects' of both dpConnects are executed.

solution:
- We removed the 'synchronized' keyword on the first Callback function, and now it seems the UI runs stable.

Question:
- Could it be that a UI is crashing when 1 synchronized function and 1 un-synchonized function tries to update the same graphical object?


PS: We didn't checked yet to add 'synchronized' to the second callback-function, Would this also resolved the Crash?

Gr. Michel.