How can I improve performance. (Panels and faceplates)

[autocon]

Panels and faceplates What are the ways to turn faster. How can I improve performance.

[leoknipp]

Hello,

to be able to give you useful information we need to know more details.
As it will be take some time to analyse and to answer your questions please get in contact with your common WinCC OA support.

When submitting a service request please follow the instructions described in the following FAQs:
https://portal.etm.at/index.php?view=it ... &Itemid=54

https://portal.etm.at/index.php?view=it ... &Itemid=54

Best Regards
Leopold Knipp
Senior Support Specialist

[Gertjan van Schijndel]

There are some debug and report flags, which could help you improve the performance of your control code. They are described in the online help under: CONTROL -> Introduction to CONTROL -> CONTROL Code Coverage.

[fmulder]

Let me give you several tips:

- Try to make one big dpGet() or one big dpConnect(). Assume that every dpGet()/dpConnect() will cost you 1 millisecond (this is just an example value). When you now have a panel with 100 symbols each doing 10 dpGet()'s will cost 1 second to load (this is not an actual measurement. it is just a tool to help you understand why panels can be slow)
- Try to avoid using a dpGet() in the callbackj of your dpConnect()
- Carefull with dpQuery(). Do you really need it or can you store something in a global variable
- do not dpConnect(0 to data that never changes. Load that data once at startup of your GUI in global variable
- Run your user interface with '-dbg 29'. Then check the LogViewer and see what source is actually being executed. Are you sure that you ned all this source code

Good luck

[autocon]

Thanks a lot.

dpQueryConnectAll() What can I use instead ?
There's an area I've done continuous query. I suspect in this case .

[fmulder]

dpQueryConnectAll() might become expensive when:
- Your database (number of items in query) is quite big OR
- When the items in the query change often so that you get many callbacks and keep on parsing/executing the answer

I'd advise
- First try to eliminate the dpQueryConnectAll(). Are you sure you need a query or can you use a dp function or something else.
- is this something that every client does. Then consider doing the logic on the server and post only the result through a datapoint
- Consider dpQueryConnectSingle(). Store the results of the previous callbacks in a global variable. Update your global variabele when you get a callback and then do your calculations

First:
- see how often you get a callback. Do all items change or just one (then go for dpQueryConnectSingle() )
- Why does the item change so often. Is it because you've created an endless-loop (you get a callback because you did a dpSet() which again triggers a callback). Or did you forget old/new comparison in the driver or smoothing

[autocon]

I figured it out.

Alone, I'm doing this for this filtering alarms, and the subject's coloring.
Thanks for the valuable information.