WP PerformanceImplementationTips EN 1 - WinCC OA 资料

Unrestricted

Whitepaper issued bc: ETM.

© ETM professional control GmbH. All rights reserved.

1

www.siemens.com/wincc-open-architecture

Whitepaper Performance Implementation Tips

Version 1.0

Unrestricted

Whitepaper | Performance Implementation Tips | 23.09.2019

Abopt this docpment

This whitepaper provides you with answers to the following questions:

- Avoiding typical faults regarding performance

- Practical examples for performance topics

Disclaimer

This whitepaper is for information purposes only and is provided “as is” with no warranties whatsoever including any warranty

of merchantability, fitness for any particular purpose, or any warranty otherwise arising out of any proposal, specification, or

sample.

No license, expressed or implied, to any intellectual property rights is granted or intended hereby.

Product or company names mentioned herein may be the trademarks of their respective owners.

This whitepaper may not be incorporated into any contract. It is not a commitment to deliver any material, code, or func-

tionality, and should not be relied upon in making purchasing decisions. The development, release and timing of any

features or functionality described for ETM’s products remains at the sole discretion of ETM.

No part of this document may be reproduced except as authorized by written permission. The copyright and the foregoing

restriction extend to reproduction in all media.

The information provided in this documentation contains merely general descriptions or performance characteristics,

which in case of actual use, do not always apply as described and may change as a result of further developments of the

products. An obligation to provide the respective characteristics shall only exist if expressly agreed in the terms of contract.

Secprity information

Siemens provides products and solutions with industrial security functions that support the secure operation of plants,

solutions, machines, equipment and/or networks. They are important components in a holistic industrial security con-

cept. With this in mind, Siemens` products and solutions undergo continuous development. Siemens recommends

strongly that you regularly check for product updates.

For the secure operation of Siemens products and solutions, it is necessary to take suitable preventive action (e.g. cell

protection concept) and integrate each component into a holistic, state-of-the-art industrial security concept. Third-

party products that may be in use should also be considered. For more information about industrial security, visit

http://www.siemens.com/industrialsecurity.

To stay informed about product updates as they occur, sign up for a product-specific newsletter. For more information,

visit https://support.industry.siemens.com/cs/start?lc=en-DE.

Unrestricted




3

Disclaimer ................................................................. 2

1. Contents............................................................... 3

2. Data model ........................................................... 5

2.1. Save format and unit ..................................... 5

2.2. Tips for usage of statistical functions .............. 5

2.3. Tips for usage of alert handler ........................ 5

2.4. Usage of Alert Class ....................................... 6

2.5. Usage of multiinstance alerts ......................... 6

2.6. Usage of alertConnect() ................................. 6

2.7. Counting the pending alarms ......................... 7

3. Archiving .............................................................. 8

3.1. Tips for usage of archives ............................... 8

4. Driver ................................................................... 9

4.1. Poll groups/Subscriptions ............................... 9

4.2. Treatment of peripheral assets (Configs

_address, _msg_conv, _smooth) .................................. 9

5. Code .................................................................. 10

5.1. Multiple use of CTRL code ............................ 10

5.2. Definition of variables in libraries ................. 10

5.3. Load CTRL Libraries ..................................... 10

5.4. Use of Queries in CTRL Code......................... 11

5.5. Combine CTRL scripts .................................. 11

6. Panels ................................................................ 13

6.1. Loading of a big panel with Init Script Mode .. 13

6.2. Loading of a big panel with Lazy Loading ...... 13

6.3. End detection of all initializations of a panel .. 14

1. Contents

This guideline is intended to help a WinCC OA programmer

avoiding typical errors in performance when creating a

project. In the following some points from different areas

are listed.

It is important to mention that the points below can de-

pend on many factors and the corresponding use cases

and therefore there can not always be a generally valid

statement. The larger the project the more severe the im-

pact of the “Don’ts” will be.

Unrestricted




4

6.4. Fileformat .................................................. 14

6.5. Reduction of shapes in graphical references.. 14

6.6. Data distribution in graphical references ...... 15

6.7. Retrieve data for multiple use (caching) ....... 16

6.8. Retrieve a larger amount of data .................. 18

6.9. Reducing the number of messages - bulkwise

processing of data ................................................... 19

6.10. kisible / Invisible switching of different objects

during runtime ........................................................ 20

6.11. kisible / invisible switching of different objects

during loading ........................................................ 20

6.12. Properties in object-oriented panel (OOP)

references............................................................... 21

6.13. Use of alert colors ....................................... 21

6.14. addSymbol() and Layout ............................. 23

6.15. Panel Caching ............................................ 23

6.16. Use Shape Identifier .................................... 24

6.17. Use of graphic formats ................................ 25

6.18. Shadow of graphical objects ........................ 25

6.19. Trend – Scroll Area ...................................... 25

7. Architecture ....................................................... 26

7.1. Calculations in UI ........................................ 26

7.2. Automatic update of directories when booting a

UI (Desktop UI, Mobile UI, ULC UX) ........................... 26

7.3. Tips for distributed systems ......................... 26

7.4. Identification Caching ................................. 27

7.5. Message Compression ................................. 27

8. Appendix ........................................................... 28

8.1. Implementation example for 6.2 and 6.3 ...... 28

8.2. Implementation example for 6.12 ................ 32

8.2.1. Do .............................................................. 32

8.2.2. Don’t: ......................................................... 33

Unrestricted




5

2. Data model

2.1. Save format and pnit

Scenario:

Save format, unit, description and alias. These are editable in the para under each DPE in the "_common" -Config or set-

table by script with the functions dpSetUnit(), dpSetFormat(), ....

Do:

Using the "_common" -Config.

Don’t:

Save format, unit, etc. in own DPEs and then query them with dpGet().

Reason: The advantage of the "_common" -config is that this data can be queried via its own functions (dpGetUnit(),

dpGetFormat(), ...) which do not cause messages to the Event Manager. The information for the unit, format etc. is

loaded into the manager's memory at startup and data is read from local memory if information is requested.

2.2. Tips for psage of statistical fpnctions

Scenario:

Use of statistical functions.

Do:

• Use sensibly (use only if really needed).

• Match intervals (no overlapping intervals).

• The interval length must match the input values (e.g. calculating an annual value based on the spontaneous values

makes no sense).

• Do not set the calculation period too short (a too often repeated interval causes additional load for the Event Man-

ager).

• Only set the checkbox "Initialize calculation from archive" if the input values are archived and if the intervals are

correspondingly large (bigger than 5 minutes). At short intervals (a few seconds) it makes no sense.

• Synchronization time should be a multiple of the calculation interval, so that the intervals have the same time du-

ration; otherwise it will overlap.

• If compression levels build on each other, the interval of a higher aggregation level must be an integer multiple of

the previous level.

• Compression levels should be chosen in that way that the calculation of average values is based on more than 1-2

values.

• If RDB is used, the compression functions in Oracle can also be used.

2.3. Tips for psage of alert handler

Scenario:

Use alarms on a DPE.

Do:

Keep the number of alert handlers as low as possible; delete unnecessary alert handler.

Don’t:

Install many alert handlers; not used alert handler are only disabled, not deleted.

Reason:

Deactivated alert handlers are still processed by the Event Manager, which means an unnecessary additional load on the

Event Manager.

Unrestricted




6

2.4. Usage of Alert Class

Scenario:

Create / use Alert Class.

Do:

Avoid the usage of

- "Acknowledge old alerts"

- Alert action script in alert class definitions

Reason:

"Acknowledge old alerts": The bigger the number of living alerts of one range of one DPE (> 10.000), the more the Event

Manager is busy with them. If a large number of those alerts would then be acknowledged at the same time, this could

lead to a high load of the Event Manager.

Alert action script: This code is processed in the Event Manager and gives additional load, especially when there is an

alert surge. A better possibility is to do this in a CTRL Manager, using dpQueryConnectSingle(), because it will be

processed in an own thread. Additionally the use of the parameter “blockingTime” can be very helpful (blockwise pro-

cessing).

2.5. Usage of mpltiinstance alerts

Scenario:

Use of multiinstance alerts (for details see Online Help, chapter "Alert handling for multi instance alerts")

Do:

Keep the number of active alert instances per detail low (recommendation: less than 500; if the changeable threshold of

500 is reached, a warning message will be displayed in the log viewer).

Reason:

Excessive CPU load of the Event Manager.

2.6. Usage of alertConnect()

Scenario:

Usage of the function alertConnect().

Do:

Avoid using alertConnect(), if performance is important in the project.

Reason: With alertConnect() no filtering on DPE Level is possible. It always connects to each and every alert handler of the

system. This will lead to a very high number of callbacks in the case of an alert surge.

Unrestricted




7

2.7. Copnting the pending alarms

Scenario:

The number of pending alarms should be counted in order to display them on a panel.

Do:

Use sum alert handling for the desired alarms in the system (these can be queried using the config attribute

"_alert_hdl.._summed_alerts_count").

Don’t:

Perform many queries on individual alarms and add the results in one CTRL script.

Reason:

Additional unnecessary load on the Event Manager, possibly unnecessary CTRL Script with associated Manager.

Implementation:

In the following example, a sum alert handling has been implemented on the "CountAlerts" data point, which collects

the alarms of several DPEs. From this data point, the number of pending alarms is read by means of the following code.

main()

{

dpConnect("workCB", "CountAlerts.:_alert_hdl.._summed_alerts_count");

}

workCB(string dp1, unsigned uSummedAlerts)

{

DebugN("uSummedAlerts",uSummedAlerts);

}

Unrestricted




8

3. Archiving

3.1. Tips for psage of archives

Scenario:

Use of archives.

Do:

• Existing archive managers (except archive manager 0) can be used and renamed. The archive manager 0 is respon-

sible for the archiving of the internal data points, all others are freely available.

• Create additional archives only if necessary (each manager needs additional space in RAM).

• Meaningfully parameterize archive sizes (not larger than 1 GB per archive, because at redu projects the files must

be synchronized at project start).

• kalues with a similar change rate shall be assigned to the same archives (e.g. one archive for fast changing values,

another one for slow changing values).

• Parameterize archive file changes of the individual archives with a time offset, otherwise an excessively high load

is generated at a single point in time.

• Do not set the archive file change during the period of the changeover from summer time to winter time (and vice

versa, 2 to 3 o'clock).

• Do not configure the archive file change for times where other database actions are in progress, such as Online

Backup.

• Cyclic archive changes are mandatory in Redu systems.

• Check the fill level of the archives and then adjust the configuration accordingly.

• Smoothing should happen through the driver and not in the archive. However, in special cases, it may make sense

to smooth both ways so that you can see more accurate data at runtime and reduce the amount of archived data to

a reasonable level.

Unrestricted




9

4. Driver

4.1. Poll gropps/Spbscriptions

Scenario:

Usage of poll groups and subscriptions (for drivers that support subscriptions, such as S7plus driver, OPC UA).

Do:

• Note the limitation of the hardware in case of suscriptions (this should be requested from the manufacturer of the

hardware).

• Set fast changing values to subscriptions, slow to poll groups.

• Set polling time sensibly (too fast polling time loads the driver and may not be necessary in every application).

• Name poll groups meaningfully ("fast" and "slow" and not "1 sec" and "10 sec", as in the latter case a change of the

polling time can become very misleading).

• Combine similar changing values (rate of change in the PLC) in one poll group.

4.2. Treatment of peripheral assets

(Configs _address, _msg_conv, _smooth)

Scenario:

For example, 3000 values should be read from a PLC. These are different data. Binary signals such as status messages

rarely change. For analog measurements, pressures tend to change frequently, but temperatures tend to be sluggish and

change less often. In addition, the accuracy of the measuring devices is often limited, so that the later decimals would

just reflect digital noise and thus needs to be smoothed.

Do:

There are several measures that can be used for the above scenario:

• Low level comparison: This can already be set in the "_address" configuration and prevents the PLC value from being

forwarded without the value having changed.

• Message conversion ("_msg_conv" -Config): This allows the PLC value to be converted and forwarded in various

ways. For example, the accuracy can already be defined here, or the value can be adapted by means of a polynomial

conversion.

• Smoothing ("_smooth" -Config): There are several possibilities to let a value pass only if it meets certain criterias:

o kalue-dependent smoothing: A value passes only if it is outside a certain deadband

o Time-dependent smoothing: A value passes only after a certain tolerance time

o kalue AND time-dependent smoothing: Combination of the two smoothings

o kalue OR time-dependent smoothing: Combination of the two smoothings

o Old/new comparison: A value passes only if the value itself changes

o Old/new AND time-dependent: Combination of the two smoothings

o Old/new OR time-dependent: Combination of the two smoothings

Don’t:

• kalues, especially float values, pass unfiltered.

• Old/new comparison for float values.

Reason:

A usage of _address configs without filters creates a heavy load on the driver and the Event Manager.

Unrestricted




10

5. Code

5.1. Mpltiple pse of CTRL code

Scenario:

Multiple use of the same code.

Do:

Use CTRL libraries.

Don’t:

Duplicate the same code multiple times and make each change multiple times.

Reason:

Higher error rate and more maintenance effort with duplicate code.

5.2. Definition of variables in libraries

Scenario:

Definition of Manager-global variables in libraries.

Do:

Define variables in libraries with the keywords "const" or "global".

Don’t:

Definition of variables without the keywords "const" or "global".

Reason:

If variables without the keywords mentioned above are defined in libraries, a separate instance of these variables is gen-

erated in each script as a script-global variable (NOT Manager-global). This will result in unnecessary use of main

memory.

Note:

Using these keywords only makes sense in libraries. In the code of panels, they are ineffective.

5.3. Load CTRL Libraries

Scenario:

Load CTRL Libraries.

Do:

Always load the libraries with #uses whenever possible.

If libraries are to be loaded via config entry, then load only those libraries that are necessary. Use the config entry

loadCtrlLibs = "xxx" and avoid using the config entry loadAllCtrlLibs = 1.

Don’t:

Always load all libraries (with config entry loadAllCtrlLibs = 1).

Reason:

By not loading unnecessary libraries, memory consumption is reduced, and scripts become more powerful.

Note:

The ending “ctl” is not necessary anymore and should be avoided, because there is a special loading sequence, and if the

library is later encrypted (ending “ctc”) it can be used without any code change.

Unrestricted




11

5.4. Use of Qperies in CTRL Code

Scenario:

Use of Queries in CTRL Code.

Do:

Create a query in the SQL Query Panel, query the result and observe the query duration. This should only be done when

the project is fully configured.

Don’t:

Implement query without information about the size of the result and the query duration.

Reason:

The programmer must be aware of the extent of his query (with the final data) to avoid any performance issues. It also

depends on the load and the real amount of data. For historical queries, useful results are available after the project has

run for some time.

5.5. Combine CTRL scripts

Scenario:

Use of several CTRL scripts.

Do:

Scripts can be combined using script lists. That means, a script list is executed by exactly one CTRL manager, and this list

in turn executes the scripts contained within it. Important scripts should run in a separate manager to avoid influences

of the scripts to each other. For example, load peaks in one script could result in delayed processing in another script.

Keep in mind that one CTRL manager can only process one CTRL thread at a time (single threaded).

Don’t:

Use a separate CTRL manager for each script.

Reason:

Each manager uses additional space in RAM and adds to the startup time of the project, so the number of managers

should be kept as small as possible.

Implementation:

Do:

Unrestricted




12

Don’t:

Unrestricted




13

6.1. Loading of a big panel with Init Script Mode

Scenario:

A large panel shall be loaded, in which the whole area cannot be displayed on the screen at once and some objects are

in the non-visible area, where they can only be reached by scrolling.

In each individual case, it must be defined what is "big" and where this measure makes sense at all. This depends on the

one hand strongly on the screen resolution used, because at, for example, 10% larger than the screen, the effort is not

worthwhile, but well for the double resolution. And on the other hand, this only makes sense if the loading times are

long (in accordance to the requirement specification of the project).

Do:

Use the property "Start Init-Script Mode" in the panel. With this you can specify that only the visible objects are initialized

when loading. Objects outside the visible area are loaded, but the scripts are just initialized as soon as the objects be-

come visible, e.g. by scrolling.

Don’t:

The whole panel is loaded at once. The objects of the invisible part also affect the loading speed of the visible areas and

cause correspondingly longer loading times.

6.2. Loading of a big panel with Lazy Loading

Scenario:

Same scenario as above (6.1).

Do:

Another, more complex possibility is to divide the content of the panel into several references (reference as a logical

grouping of objects). When loading, the visible part is loaded first in order to give the user a feedback as quickly as possi-

ble and to display the most important values. The invisible parts are loaded afterwards ("Lazy Loading").

Reason:

If the use of the "Start Init-Script Mode" property is not applicable, the functionality of the Lazy Loading offers the user

the possibility to get a faster response to his command to show a new panel, since the visible area appears first and is

not waiting on the drawing and loading of the remaining objects on the panel.

Implementation:

Below is a brief outline of the implementation of Lazy Loading. A concrete example of can be found in the appendix

(chapter 8.1).

• The original panel is split:

o in a panel for the initially visible area and

o in one or more panels for the initially invisible area.

• The invisible parts are saved as separate references.

• When the panel is loaded, the content of the visible panel is first drawn and initialized.

• Subsequently, the invisible panels (references) are loaded with the function addSymbol().

• The end of the initialization is detected by synchronizing the individual scripts against a global variable and inserting

a shape on layer 8 (also synchronized against the global variable) whose script is executed last (see chapter 6.3).

6. Panels

Unrestricted




14

6.3. End detection of all initializations of a panel

Scenario:

Often it is necessary to know when all init scripts on a panel are finished and the loading of a panel is done.

Implementation:

Two things must be done:

• The init script of a panel and every shape on the panel containing an init script (rectangle, button, ...) must be

synchronized against a global variable.

• A shape on the panel must be assigned to layer 8.

Objects on layer 8 will handled later than objects on the other layers. Synchronization prevents one script of a reference from

"overhauling" another script.

A practical example including panel and code is given in the appendix in the example for the Lazy Loading (chapter 8.1).

6.4. Fileformat

Scenario:

pnl or xml

Do:

Use pnl file format if xml is not required mandatory.

Reason:

pnl files are smaller and processed faster in the UI than xml files (about 5 - 10%). For xml files, the interpreter takes

longer to parse and build the DOM structure, which in turn leads to longer load times.

Note:

It is not necessary to save pnl files with the file extension pnl. A pnl file can also be called Filename.xml without affect-

ing its functionality. This is especially interesting if many files with the extension xml have already been created and are

also referenced in the code.

Implementation:

• Individual panels can be converted from the GEDI (save with "Save Panel As ..." and choose the corresponding panel

format).

• Converting from xml to pnl can also be easily done from the command line (using the UI Manager start option

-xmlConvert). This will recursively convert all panels in the “panels” directory:

WCCOAui.exe –proj Projectname –xmlConvert=PNL

6.5. Redpction of shapes in graphical references

Scenario:

Create a reference with several shapes (lines, rectangles, circles, buttons, ...).

Do:

Keep the number of shapes per reference as small as possible.

Don’t:

Use shapes as placeholders or for better placement (e.g. help for positioning) in references.

Reason: The more shapes a reference has and the more often this reference appears on a panel, the longer it takes to load. Refer-ences used multiple times are loaded from the disk only once per module if panel caching is enabled.

Unrestricted




15

6.6. Data distribption in graphical references

Scenario:

Display the value of a DPE on an object in the reference (numeric display, graphical display, ...). It especially applies to

big panels with many thousand objects. In this scenario we focus on reducing the loading time of a panel.

Do:

Using dpConnect() directly on the object.

Don’t:

Use of dpQueryConnectSingle() for all objects on the panel and subsequent distribution to the objects.

Reason:

At loading the objects do not have to be searched because the work function runs in the context of the object and thus

the value is displayed faster.

Note:

Because of project specific requirements there could be situations where a dpQueryConnectSingle() is the preferred

implementation method. For example on a panel with thousands of objects, cross-object wise, the use of dpQueryCon-

nectSingle() together with blocking time and through that blockwise processing of the messages is reasonable. This

has to be decided on the occasion.

In any case alerts and values should be requested in separate dpConnect().

Normally there should be no dpGet() in a callback. Exception: If a value is changing very often, but it is not used as

trigger, then it can be read via dpGet() in the callback. In this case this would lead to a reduction of messages.

Implementation:

The following example inserts a reference with 2 text fields (TEXT_FIELD1, TEXT_FIELD2) into a panel.

The code at Do is in the initialize script of the reference and provides the two objects of the reference with the current

values.

The code at Don’t is in the initialize Script of the panel, so the reference there must be explicitly addressed, and the data

must then be distributed to the objects.

Do

─// [(Panel PANEL_REF1)] [0] - [Initialize]

main()

{

dpConnect("workCB", "Testvalue.Current", "Testvalue.Voltage");

}

workCB(string sDp1, float fValue1, string sDp2, float fValue2)

{

setMultiValue("TEXT_FIELD1", "text", fValue1,

"TEXT_FIELD2", "text", fValue2);

}

Unrestricted




16

Don’t

─// [(Panel)] [0] - [Initialize]

main()

{

dpQueryConnectSingle("workCB", 1, "userData01", "SELECT '_online.._value' FROM

'{Testvalue.Voltage,Testvalue.Current}'");

}

workCB(string sDp1, dyn_dyn_anytype ddaTab)

{

string sDp, sDPE;

for (int i = 2; i<=dynlen(ddaTab); i++)

{

sDp = dpSubStr(ddaTab[i][1],DPSUB_DP);

sDPE = dpSubStr(ddaTab[i][1],DPSUB_DP_EL);

strreplace(sDPE, sDp + ".", "");

if(sDPE == "Voltage")

setValue("PANEL_REF1.TEXT_FIELD1", "text", ddaTab[i][2]);

else

setValue("PANEL_REF1.TEXT_FIELD2", "text", ddaTab[i][2]);

}

}

6.7. Retrieve data for mpltiple pse (caching)

Scenario:

Retrieving data that is often needed in different scripts within the same manager.

Do:

Save data in global variables, which are captured with dpConnect() or dpQueryConnect*().

Don’t:

Repeatedly use of dpGet().

Reason:

The function dpGet() is executed synchronously, which multiplies the delay. The execution of the following code in the

same scope would thererfor be delayed.

Note:

Static data can be loaded with dpGet() (no connect needed).

Implementation:

The following example illustrates how the value of a DPE is stored on a global variable and made available to other appli-

cations, and only in the case of change the value of the global variable will be updated. In the "Don’t" example, this is

done using dpGet().

In this specific case, the available hard disk space is determined.

Unrestricted




17

Do

─// Library xxx.ctl

global long g_lFreeDiskSpace = 0;

public long getFreeDiskSpace()

{

if(g_lFreeDiskSpace == 0) //only do dpConnect once

synchronized(g_lFreeDiskSpace)

{

dpConnect("setFreeDiskSpaceCB", true, "_ArchivDisk.FreeKB");

}

synchronized(g_lFreeDiskSpace)

{

return g_lFreeDiskSpace;

}

}

// Callback function for dpConnect()

private setFreeDiskSpaceCB(string sDPE, long lDiskSpace)

{

g_lFreeDiskSpace = lDiskSpace;

}

─// Panel, CTRL script

#uses "xxx"

main()

{

//somewhere in your code e.g. 100 times in a loop

DebugN("Free Disk Space: "+getFreeDiskSpace());

}

Don’t

─// Panel, CTRL script

main()

{

long lDiskSpace;

//somewhere later in your code e.g. 100 times in a loop

dpGet("_ArchivDisk.FreeKB", lDiskSpace);

DebugN("Free Disk Space: "+lDiskSpace);

}

Unrestricted




18

6.8. Retrieve a larger amopnt of data

Scenario:

Retrieve a larger amount of data with dpQuery*().

Do:

Using data point filter in the FROM part or data point type filter in the WHERE part of the SELECT statement. If you use

the same DPs more than once in the FROM part, you could create data point groups for simplicity and specify them in

the FROM part.

Don’t:

SELECT statement without filter (that means without WHERE part) and processing of the complete result set afterwards

in a script.

String comparisons or usage of LIKE or NOT LIKE in the WHERE part.

Reason:

DP filters or DPT filters are much more efficient operations, while the filters mentioned under Don’t put a heavier load on

the event manager.

Implementation:

Here are some examples of how data can be retrieved using Query.

Do Retrieving the online values of all DPEs belonging to datapoint type ANALOG1:

(Reason for Do: With this definition only one subset is selected)

dpQuery("SELECT '_online.._value' FROM '*' WHERE _DPT = \"ANALOG1\" AND _LEAF",

tab);

Retrieve the online values of all DPEs where the data point name starts with "Ana":

dpQuery("SELECT '_online.._value' FROM 'Ana*'", tab);

Retrieve the online values of all DPEs that are grouped in a data point group:

dpQuery("SELECT '_online.._value' FROM 'DPGROUP(_DpGroup00019_Public)'", tab);

Don’t Retrieving the online values of all DPEs for which the data point name starts with "Ana" (counter example above):

(Reason for Don’t: Combination of ‘*’ and LIKE)

dpQuery("SELECT '_online.._value' FROM '*' WHERE _DP LIKE \"Ana*\"", tab);

Note:

When using dpQueryConnect* and executing “-report QUERY” on the Event Manager: Compare rowmask and

result table. If there is a huge difference, it can be a sign that the query is bad. Note:

Generally avoid using the function dpQueryConnectAll() instead of dpQueryConnectSingle(). With

dpQueryConnectAll() big messages will be built, which is difficult for the Event Manager.

Unrestricted




19

6.9. Redpcing the npmber of messages - bplkwise processing

of data

Scenario:

Get data from multiple data point elements using dpGet() or write data to multiple data point elements using

dpSet() or updating graphical attributes from screen objects using setMultiValue().

Do:

Use a single dpGet()for all data point queries.

Use a single dpSet() for writing data.

Use setMultiValue() for updating multiple attributes of different screen objects at once (here are no messages in-

volved, but nevertheless it is the same mechanism).

Don’t:

Use separate dpGet() for individual data point elements.

Use separate dpSet() for individual data point elements.

Use multiple setValue() commands for updating different screen objects.

Reason:

dpGet() is a waiting function. This means that if you have multiple dpGet(), it is waiting for a response before calling

the next dpGet(). Therefore, single call of the function, even with multiple parameters, is more efficient than a multi-

ple call. In addition, the values are read at the very same time (snapshot).

The same reason applies for dpSet() with a little less impact.

Furthermore it also applies for setMultiValue(), but with an even smaller effect.

Note:

The number of messages (so the dpGet() calls) should be kept as low as possible. Messages that are too large are to be

avoided (from approx. 200 DPEs per message it is advisable to split them into several messages).

Implementation dpGet (the same applies for dpSet):

Do

dpGet(dpName1, dpValue1,

dpName2, dpValue2,

dpName3, dpValue3);

Don’t

dpGet(dpName1, dpValue1);



Implementation setMultiValue:

Do

setMultiValue("RECTANGLE1", "visible", true,

"RECTANGLE2", "visible", true,

"RECTANGLE3", "visible", true);

Don’t

setValue("RECTANGLE1", "visible", true);



Unrestricted




20

6.10. Visible / Invisible switching of different objects dpring

rpntime

Scenario:

Several objects should be set visible or invisible, depending on the same information.

Do:

Use a single setMultiValue() for all objects.

Don’t:

Set visibility for each object individually with setValue().

Reason:

Using the setMultiValue() function is faster than using single calls with setValue(). It also prevents a kind of

blinking sequence when a thread switch occurs between each setValue() call.

Implementation:

Do

main()

{

setMultiValue("RECTANGLE1", "visible", true,

"RECTANGLE2", "visible", true,

"RECTANGLE3", "visible", true);

}

Don’t

main()

{




}

6.11. Visible / invisible switching of different objects dpring

loading

Scenario:

Several objects on a panel should be switched to visible or invisible code dependent.

Do:

By default, always configure the property on the object (for the initially invisible objects) to invisible and then use code

to make the corresponding objects visible.

Don’t:

Define objects as visible and then switch them invisible by code.

Reason:

Objects that are visible by default and are invisible by code appear briefly on the panel. This creates unnecessary flicker-

ing of objects for the user during loading.

Unrestricted




21

6.12. Properties in object-oriented panel (OOP) references

Scenario:

Use additional properties (with #property) in object-oriented panel references (OOP) for initializations.

Do:

Set initial values directly to the references by the means of overwriting attributes of individual instances. The implemen-

tation of one single init function would be another possibility.

Don’t:

Configuration of panel references with many User defined Properties (#property).

Reason:

Additional used properties always result in function calls. But a single call is faster than several individual ones. These

increased calls generate additional load in the UI. Overwriting attributes of individual instances from graphical refer-

ences (such as change of colors, position, …) additionally reduce the executed code lines and therefor improve the ini-

tialization time of a panel.

Implementation:

An example of Do and Don’t is attached in the appendix (chapter 8.2).

6.13. Use of alert colors

Scenario:

Display of the states of a shape with different colors, where the shape is already linked to a DPE which has an alert han-

dling.

Do:

Use the colors of the alert handling.

Don’t:

Build your own state machine or implement a status evaluation and color conversion.

Reason:

The own script generates additional, unnecessary load. And the need for this is not given due to the already existing col-

ors in the alert handling. Furthermore, the maintenance is higher, and the UI is charged more.

Implementation:

Connect to the config „_alert_hdl.._act_state_color” and use the color in the symbol.

Do

main()

{

dpConnect("workCB", "ExampleDP_AlertHdl1.:_alert_hdl.._act_state_color");

}

workCB(string sDp1, string sAlertColor)

{

RECTANGLE1.backCol = sAlertColor;

}

Unrestricted




22

Don’t

main()

{

dpConnect("workCB", "ExampleDP_AlertHdl1.:_alert_hdl.._act_state");

}

workCB(string sDp1, int iAlertState)

{

if (iAlertState == 0)

RECTANGLE1.backCol = "white";


RECTANGLE1.backCol = "alertCamUna";


RECTANGLE1.backCol = "alertCamAckn";


RECTANGLE1.backCol = "alertWentUna";

}

Unrestricted




23

6.14. addSymbol() and Layopt

Scenario:

Objects are inserted into a layout using the function addSymbol().

Do:

Disable the layout before addSymbol() and afterwards enable it.

Don’t:

Use without disabling and enabling the layout.

Reason:

Disabling and enabling the layout will result in fewer layout calculations during generation using addSymbol(), and

will not display any interim layout changes, which makes the panel drawing and loading faster.

Implementation:

main()

{

LAYOUT_GROUP1.enabled = false;

addSymbol(myModuleName(),

myPanelName(),

"RefRectangle.pnl",

"Ref1",

0,

"LAYOUT_GROUP1",

makeDynString("$DP:DP"));

LAYOUT_GROUP1.enabled = true;

}

6.15. Panel Caching

Scenario:

The same panel file is used multiple times in the same module.

Do:

Set the property "Keep in memory" on the panel to TRUE. Default is TRUE.

With the config entry panelCacheSize = x the size of the cache can be defined. Here "size" means the number of

panels in the cache, a value of x = 0 deactivates the cache.

Don’t:

Set the property "Keep in memory" on the panel to FALSE.

Reason:

With TRUE, it is achieved that the information from the panel file remains in the main memory of the respective module

after closing the panel. If the same panel is redisplayed, the file does not need to be loaded from the disk. When a mod-

ule is closed the cache for this module is deleted.

Unrestricted




24

6.16. Use Shape Identifier

Scenario:

Multiple use of setValue()/getValue() for the same shape or frequent calls of a callback function with

setValue()/getValue().

Do:

Using a Shape kariable and the function getShape().

Don’t:

Call the functions setValue()/getValue() with the corresponding shape as a string.

Reason:

Each time you call setValue()/getValue(), the UI looks for the shape again. With getShape() the shape identifier

can be stored on a variable and then only has to be searched once.

Note:

If the shape is itself or is within its own reference, and the reference has only a few shapes, this scenario is not relevant.

Implementation:

Do

main()

{

string s_dpe;

shape s_shape = getShape("value");

s_dpe = $dp + ".in.value";

if (dpExists(s_dpe))

dpConnectUserData("show_value", s_shape, 1, s_dpe);

}

show_value(shape s_shape, string s_dpe, float f_val)

{

setValue(s_shape, "text", f_val);

}

Don’t

main()

{

string s_dpe;

s_dpe = $dp + ".in.value";

if (dpExists(s_dpe))

dpConnect("show_value", 1, s_dpe);

}

show_value(string s_dpe, float f_val)

{

setValue("value", "text", f_val);

}

Unrestricted




25

6.17. Use of graphic formats

Scenario:

Use of graphics in panels.

Do:

Use memory-conserving formats, such as PNG, GIF.

If graphics are needed for a small presentation, do not use large images. For example, it does not make much sense to

include a 1280x1024 pixel graphic for a 30x30 pixel rectangle.

Don’t:

Use memory-intensive formats, such as BMP.

Use big SkG graphics where big in the sense of the content is meant (many objects). SkG is an XML format that must be

parsed, and it again contains some primitive graphics objects that have to be drawn each time.

Reason: Memory-intensive formats increase the loading time of the panels containing these graphics.

6.18. Shadow of graphical objects

Scenario:

Use of the property shadow in graphical objects (e.g. rectangles, circles).

Do:

Avoid using shadow at big panels where objects are dynamically animated.

Reason: Using shadow costs CPU load at the user interface.

6.19. Trend – Scroll Area

Scenario:

Display of a trend.

Do:

Depending on the displayed time range, you should configurre the value for the scroll area. For example, a 10% scroll

area is fine for a day trend, while for a 30 second trend this might be too low. However, this also depends on how many

curves are displayed and how big the trend area is.

Reason:

With a low value for the scroll area, a frequently redrawing of the trend area is necessary. As soon as the last point of the

curve reaches the right edge of the trend surface, the trend is redrawn.

Unrestricted




26

7. Architectpre

7.1. Calcplations in UI

Scenario:

The same data is needed in multiple UIs.

Do:

Calculate data centrally (for example via CTRL script in a CTRL Manager).

Don’t:

Calculate data in each UI separately.

Reason:

Bigger error rate and higher maintenance effort.

7.2. Aptomatic ppdate of directories when booting a UI (Desk-

top UI, Mobile UI, ULC UX)

Scenario:

Download of defined directories when booting from Desktop UI, Mobile UI and ULC UX.

Do:

Avoid using the config entry autoUpdateDir if possible. This entry is expensive and should not be necessary.

The correct way of accessing project files on the client is the use of the CTRL function getPath().

Don’t:

Use the config entry autoUpdateDir for directories with big files.

Reason:

The more and bigger files need to be downloaded, the longer it will take to start up the UI (especially the first start will

be very slow). The use of autoUpdateDir is considered as a work around only.

7.3. Tips for distribpted systems

Scenario:

Use of big distributed systems.

Do:

Use the config entry distributed = 1 only for managers, which needs dist. All other managers deactivate from dist

with distributed = 0.

A more detailed selection is possible with distSystemIds (see example below):

Reason:

Every manager, which is connected to dist, loads the DpIdentification of every other system, also if it is not used. And

this results in longer startup times and higher memory usage.

Example: [ctrl_3]

distSystemIds = "1-28, 46, 280-290, 320"

Unrestricted




27

7.4. Identification Caching

Scenario:

Use identification caching.

Do:

Use the config entry useLocalIdentification = 1 in the [data] section to activate the identification cach-

ing (default is deactivated).

Reason:

Especially for slow connections (e.g. for remote UIs via modem connection) the start phase of a manager is very slow

when the whole identification is transferred in bigger projects. To improve this, the identification is saved on the local

computer.

7.5. Message Compression

Scenario:

Bandwith problems between server and client or server and server.

Do:

Use the config entry messageCompression (for all sections). There are different compression methods, like “zlib”,

“bzip2“, "zlib-bzip2" (for details see Online Help).

Use the config entry messageCompressionThreshold (for all sections) with a specified value (default is 0, which

means “compress all”).

Reason:

Activating message compression is recommended if the network bandwidth is the identified bottleneck (router speed

limitations, etc.).

But be aware: Message compression always comes with a penalty of CPU usage. So the usage of a certain messageCom-

pressionThreshold is recommended, because small messages do not need to be compressed.

Unrestricted




28

8. Appendix

8.1. Implementation example for 6.2 and 6.3

The content of the entire panel is divided into different segments (here on 3 segments), each with their own panels.

A main panel loads the first segment with the function addSymbol(). The first segment, after the end of all init scripts,

also activates the second segment via the function addSymbol(), and this in turn loads the third segment.

How do you recognize the end of all init scripts of a panel?

The init script of the panel and every shape on the panel containing an init script (rectangle, button) must be synchro-

nized to a global variable (here: g_sync). In addition, a shape on the panel must be assigned to layer 8. As a result, this

is processed last and can therefore also contain the code for the next segment. In our example, this shape is the red rec-

tangle (RECTANGLE2), which is invisible.

Parameterization of the red rectangle (Layer 8)

Unrestricted




29

Main panel and segment panels in Gedi

Unrestricted




30

Result in run time

Below is the code of each part:

1. The library sync.ctl contains the global synchronization variable:

sync.ctl:

global bool g_sync;

2. Code of the main panel:

Main.pnl:

─// [(Panel)] [0] - [ScopeLib]

#uses "sync"

──────────────────────────────────────────────────────────────────


main() synchronized (g_sync)

{

addSymbol(myModuleName(), myPanelName(), "Segment01.pnl", "Seg1",

makeDynString("ABC"), 70, 100, 0, 1, 1);

}

Unrestricted




31

3. Code of the panel Segment01.pnl (for the other segments the code should be used analogously):

Segment01.pnl:

─// [(Panel)] [0] - [ScopeLib]

#uses "sync.ctl"

──────────────────────────────────────────────────────────────────



{

DebugTN("Init Segment 1 - Panel");

}

──────────────────────────────────────────────────────────────────

─// [PUSH_BUTTON1] [1] - [Initialize]


{

DebugTN("Init Segment 1 - Button");

}

──────────────────────────────────────────────────────────────────

─// [RECTANGLE1] [2] - [Initialize]


{

DebugTN("Init Segment 1 - Rectangle");

}

──────────────────────────────────────────────────────────────────

─// [RECTANGLE2] [3] - [Initialize]


{

addSymbol(myModuleName(), myPanelName(), "Segment02.pnl", "Seg2",

makeDynString("ABC"), 70, 250, 0, 1, 1);

}

Unrestricted




32

8.2. Implementation example for 6.12 In the following example, the visibility of a shape (red rectangle) of a reference is set to false, in “Do” by means of over-parameterization, in “Don’t” by means of an extended property.

8.2.1. Do

Reference with 3 different shapes and without any code:

The reference is inserted 3 times on a panel. With the second reference the visibility of the rectangle is set to FALSE by use of the button "Select Object inside Pan-

elRef ".

Here is the result in the QuickTest:

Unrestricted




33

8.2.2. Don’t: A reference with 3 different shapes and the following code in the ScopeLib:

The reference is inserted again 3 times. The second reference uses the extended property to set the visibility of the rectangle to FALSE.

Here is the result in the QuickTest:

Unrestricted




34

ETM professional control GmbH

A Siemens Companc

Marktstrasse 3

7000 Eisenstadt, Austria

www.siemens.com

All rights reserved. All trademarks used

are owned by Siemens or their respective owners.

© Siemens AG

WP PerformanceImplementationTips EN 1 - WinCC OA 资料

Documents

Transcript of WP PerformanceImplementationTips EN 1 - WinCC OA 资料