iX Developer 2.52

Alarms are used to make the operator aware of events that require immediate action. An alarm is set when a certain condition is met. An alarm condition is designed as a logical evaluation of a tag value. Alarms can be divided into groups to create an order of priority.

Function keys can be used to perform actions and execute scripts. This allows operator control of data and screen functionality independent of which screen is active.

Translation of texts and system texts can be performed directly in the application, or via export to a text file to be translated in other software. The file is imported to the application after translation. The application language can be changed in runtime, for example based on a tag value.

Access to objects and actions in the project can be limited using security groups and user passwords.

With the text library function, text tables can be created, where values are linked to texts.

The Audit Trail function allows tracking of operator actions.

Data can be logged and saved to file. Bit, 16-bit, 32-bit and Real (Float) values can be logged. Be aware that logging of data consumes system resources and memory.

Setting and resetting digital tags in relation to the real-time clock can be performed using a scheduler, in order to control events in the process at special calendar times.

Recipes are used to set or save a predefined group of tags in one operation.

Values can be predefined or collected from the controller, and then saved to a recipe in the HMI panel. The operator can download the recipe at any time to the controller, which will start working with the recipe values. Recipe handling makes it possible to reuse large parameter sets, to improve efficiency of time critical production where a change of products must be made quickly. Recipe files can be created in the development project or with the HMI panel.

The reports function allows adding excel report templates to the project.

Tags used for driver communication can be static or dynamic. These are updated in different manners.

Define controller tags consecutively, for example M0.0-M11.7. If the tags are spread (e.g. I0.4, Q30.0, M45.3 etc.) a complete update will take longer time. The number of tags in each package depends on the used driver and information about this can be found in the driver help file.

Tags to be transferred are not all transferred at the same time, but are grouped into packages. The number of tags in each package depends on the driver for the controller.

To make communication as fast as possible the number of packages should be minimized. Consecutive tags require a minimum number of packages, but it is perhaps not always possible to program it this way. In such cases there is a “waste” between two tags.

Waste is the maximum distance between two tags that can be kept in the same package. The size of the waste depends on the driver used, and is included in the driver help file, e.g as in the table below:

In most drivers it is better to use bit-addressed words than regular bit devices, since you can fit more digital devices in one telegram when using bit-addressed words, than when using bit devices.

ASCII strings are transmitted in separate telegrams, and having a large number of strings will affect the communication performance negatively. If an ASCII string only has a small number of different string values, it may be a good idea to use the Text Library function in iX Developer with predetermined contents, thus minimizing impact on driver performance.

In order to optimize performance, it is recommended to limit the number of items in the project. The recommended limits depend on the type of panel, and are listed in the table below.

Try to avoid keeping the tag constantly active. If scripts are used, then hooking up event handlers on value change event will also set the tag to be always active. Use the passive value change event when possible. The passive event will only trigger when the tag is active, and the tag can be deactivated when it is not in use. When the tag is deactivated the passive event will remain idle until the tag is activated.

The default setting in iX Developer updates all tags every 500 ms. If some tags may be updated less often, it is possible to assign them to a poll group with a lower update interval. Poll groups are configured in the Tags configuration page.

Assign and configure poll-groups with care. High poll-interval frequency affects the performance.

Usage of the following properties on tags will reduce performance. The tag should not:

Optimizing screen update time minimizes CPU load and flash operations. This can make a significant difference in graphic-intense projects that approach the limits of the panel’s capabilities.

Screen changes are carried out most efficiently through a show screen action, either on a function key or an object.

Screens with less content will in general load faster. Certain objects will take longer to load, such as an alarm viewer. If screens are frequently shown or used as a background, try to keep it as slim as possible.

Caching of screens have a great impact on screen switching times. The more screens that can be cached the more screens will load faster, hence it is preferred to keep RAM as low as possible to utilize it for screen caching. Large screens will take up more memory when cached and will possibly prevent smaller and more frequently used screens from being cached. It is possible to prevent screens from being cached by setting its Cached property to false. When utilized RAM reaches approximately 85% the application will start to remove screens from the cache in order to avoid the application from running low on memory. This implies that if the application utilize more than 85% without caching the application will not be able to cache any screens and therefore not experience faster screen switching times.

Several trend viewers can show data from the same log item.

In order to optimize performance in the panel, it is strongly recommended to place all log items logged on the same frequency/event in the same data logger or at least reduce the amount of data loggers.

Try to avoid having one data logger for each trend viewer.

Data logging in general have impact on the performance. Reconsider the data logger settings, the log frequency and the amount of log items. Heavy data logging will increase the CPU usage and will influence performance across the whole application.

The recommended limit for a data logger's "Max number of logged rows" is based on a typical project. When exceeding this limit, it might slow down the project start-up time. However, this will depend on the number of logged items in a data logger as well as the number of data loggers in a project. If a project has a single data logger with only one logged item, this limit might be higher, but in a project with max number of data loggers and logged items, this limit will be lower. In general, the size of the database should not exceed 200 MB for panels, or 800 MB for PC, to avoid performance issues.

Data logging is queued up if more logging is done than the database can handle at the moment. If the queue reaches a too high level, the warning “Data logging has too high load. Data might be lost.” is shown on the screen in the top left notifier window. If the queue reaches a critical level, there is a risk that the system will malfunction. If this happens, alarm and data logging are turned off, the error message “Data logging is overloaded. Data logging is now disabled.” is shown in the dialog and the system tag Database Error Active is set. The system tag Database Error Message contains the error message.

The system tag is not reset by the system. It is up to the user to reset it when the system error is taken care of.

Alarm and data logging are turned on again when the queue is below the critical level.

If the storage media reaches a critically low level, there is a risk that the system will malfunction. If this happens, alarm and data logging is turned off. The error message “99% of disk used. Alarm logging is nowdisabled. Data logging is now disabled.” is shown and the system tag Database Error Active is set. The system tag Database Error Message contains the error message.

The system tag is never reset by the system. It is up to the user to reset it when the system error is taken care of.

Alarm and data logging are turned on again when the storage usage is below the critical level.

You can avoid this situation by using the Max Size setting for the database. When the limit is reached you will be informed by a warning message.

If there is a risk of the database running out of storage media, then a warning is shown on the screen. If the usage reaches a critical level, risking the system to crash, alarm and data logging is turned off, an error message is shown and the system tag Database Error Active is set. The system tag Database Error Message contains the error message. Alarm and data logging are turned on again when the storage usage is below the critical level.

Using objects with gradients creates a slightly higher load on the CPU. If a large number of objects use gradients, this will make the screen update time significantly slower. Pay special attention to objects with gradients that are updated frequently, e.g. a bar graph witha style with gradients connected toa tag that changes at short intervals.

Avoid excessive use of polygons. Polygons are usually complex and are drawn each time the screen is shown, hence they will not benefit from caching the screen.

From a performance perspective it is preferred to use styled buttons instead of the default button.

Drawing transparent objects (circular meter, slider etc.) without transparency will result in improved performance. In order to do so these objects should not overlap other objects within their bounding box. Also, avoid gradients in backgrounds and dynamics on screens containing these types of objects.

A circular meter and its bounding box

Pressing a button triggers a click- and mouse button event.

Pressing on a text box object displays a virtual alpha-numeric keyboard on the panel screen. Type a text using this keyboard and finish by pressing [Enter].

Pressing on an analog numeric object displays a virtual keyboard on the panel screen. The keyboard type depends on the format chosen for the Analog Numeric — String, Integer, Decimal, Hex or Binary. Enter a value using this keyboard and finish by pressing [Enter].

In runtime a validation of the value is done. If the value entered is out of bounds, the corresponding limit value for the object will be shown.

Pressing on the desired value position of a slider object sets it to the pressed position.