Overrunning dpConnect

[iain]

I have a loop in UI that's writing to a datapoint which has a dpConnect() in the control manager. The loop is writing too fast, and I see "Values were discarded... function has 200 pending runs -> DISCARDING!"

Which isn't a problem, obviously I need to stop the loop writing so often, but I'd like to see if this is coming close to happening at other times. Is there a way for me to read the size of the connect queue so that I can be sure that I don't have a process that's overloading the connect callback mechanism?

[leoknipp]

There is no possibility to get the current size of the queue.
In the work function you can get the information if work functions have been discarded by calling getLastError() at the start of the work function.
If the issue occured you get the following error:
WCCOAui (2), 2023.05.22 10:38:04.573, CTRL, SEVERE, 114, Values were discarded,
Module: Vision_3
Panel: C:\WinCC_OA\projects\etm\test_318\panels\main.pnl [main.pnl]
Object: 1 named: "RECTANGLE1" of type: RECTANGLE
Script: Initialize
Line: 6, work, previous values were discarded

Best Regards
Leopold Knipp
Senior Support Specialist

[gschijndel]

The control debugger is able to show the current size of the queue with the 'info connections' command.

For example it returns this result:

Code: Select all

connections:
(0) dpConnect reloadCb
System1:_CtrlCommandInterface_oaTestPv.Command:_online.._value
(0) dpConnect reload
System1:_UiDeviceMgmt.Name:_online.._value

In this case both dpConnects do not have any pending runs.

Besides using the control debugger, it is also possible with a control extension to get this value.

In many cases the pending runs are caused by calling waiting functions (like 'dpGet' or 'dpQuery') in the callback, which results in that the callbacks are not executed as fast as they are generated.

[iain]

Thanks both, that's useful info. It turned out that it wasn't the UI triggering the control manager, it was the control manager itself - but as soon as I cleaned it up I reversed the problem and started overrunning dpConnect() in the UI. It's only on startup, and increasing ctrlMaxPendings in config takes care of startup, so the app is okay, but I'm still working on cleaning up startup.

gschijndel's comment may be especially useful, because several of the connected functions immediately query other DPs, and that's probably why the queue is backing up.

[leoknipp]

If there is a need to read information for dp elements different to those which are connected, everytime when the work function is executed, you should possibly think about another approach.
Instead of reading them everytime you can also do a connect for them and save the information in global variables.
When several objects/work functions are referring to the same "global" information the connect must be done in a main panel to avoid several identical connects. e.g. in the main panel used for a panel topology template.

Best Regards
Leopold Knipp
Senior Support Specialist