This document is intended to provide descriptions of recipes (How to ...) solving common problems and user tasks. Recipes for solving tasks and problems can be offered by users for placement in this document.

1 Cyclic programming into OpenSCADA particularity

Novice users often have question about time intervals hold while programming calculation procedures in the OpenSCADA environment. This question is usually associated with the presence of previous programming experience in linear calculations and lack of experience in programming of cyclic real-time systems.

The so-called tact or cycle of periodical calculations, ie the life rhythm is used in the real-time systems. Some procedure is calculated in each cycle that should not take more time than the cycle. As a consequence, if the cycle procedure stops for waiting, the life of the real-time system stops too. Hence, the using of traditional sleep task functions into such procedures is unacceptable!

The solution of the desired exposure time interval in the real-time systems, within the rhythm of life, is made in two ways. The first way is to decrement the counter value, set to the time interval, in each cycle by the cycle frequency to the value <= 0, for example, in OpenSCADA it is implemented as follows:

The second way is based on the astronomical time, ie the comparison with the current time is made in the cycle, for example, in OpenSCADA it is implemented as follows:

if(SYS.time() > tm_to)
{
tm_to = SYS.time()+10; //Setting the waiting threshold for 10 seconds more than the current time
//Other actions with the periodicity of 10 seconds
}

The second method is more reliable because it excludes the operation delay problem due to the possibility of calculating the cycle procedure over the cycle time. Although in the properly configured systems and tasks, this problem should not occur.

2General provisions of the working conception with violations, alarms and notifications

Alarms and their processing in OpenSCADA is implemented in two ways, which is associated with the OpenSCADA structure, ways of its usage, as well as with the nature of alarms.

The first part of alarms, with which the OpenSCADA works initially, and which is most needed, is notifications in various ways. Since the notification is part of the visualization interface, they are implemented in the VCA engine UI.VCAEngine and in the visualizers UI.Vision, UI.WebVision. Currently, notifications and alarms OpenSCADA subsystem implements the following functions:

Notification:

Light — blinking of the object, the signaling group, the general status with the alarm color.

Sound — playing the sound file, or speech synthesis from text, associated with the alarm;

Beep — a continuous signal to the system, "Beeper", regardless of the alarm.

Quittance of the alarm notification:

Full — by clicking on the colored blinking circle of the alarm status (the "ws_alarmLev" event), bottom right:

By the notification way — separate the light (the event "ws_alarmLight"), sound (event "ws_alarmSound") and the beep (the event "ws_alarmAlarm"), by pressing a button with the corresponding image, bottom right, or under the buttons of display options;

By the alarm object — to the visual presentation image it can be added the quittance command of the notification directly by itself;

Alternately with listening — it is character of the sound notification, because every alarm object can provide its own sound notification or the speech synthesis.

During the implementation of the notifications in the visualization area there is no direct rule for the formation of alarm sign because in many situations there is no uniqueness. Currently, on the side of the typified data source templates, it is practiced a method of the formation an "err" error attribute with the code and text of the alarm, and their processing and the formation of notification is made in the visual image of the data object. Sometimes the processing the parameter's borders is made directly in the visual image of the data object.

Subsequently, it became necessary to log and record the actual alarms for the current moment. For the alarms logging it is sufficient the formation of system messages with the specified category and message format, but for the monitoring the ongoing(actual) alarms a buffer is needed. Subsequently, a buffer was added as an add-on of the messages subsystem, and its addressing is made by the inversion of the message level. So, the message record with the level "-2" and the category "TEST" will put the message into the alarm buffer and duplicate it in the messages archive, with the level of "2". At the messages request with the negative level they will be taken from the alarm buffer. Deleting/removing of the alarm is made by writing the messages with the same category "TEST" and the non-negative level.

This concept of accounting the actual alarms allows you to use standard mechanisms for the messages processing to account the alarms:

Creating a list of actual (active) alarms by means of the "Protocol" or "Document" elements with the "-1" negative level for all.

Messages registration is best done on the side of the typified data source templates by a special function SYS.DAQ["Modul"]["Controller"].alarmSet(string mess, int lev = -5, string prm = ""), which unifies the category. To call this function from the context of the template you need to add "this" IO of the "Object" type, then the set of the alarm would be of the following formthis.cntr().alarmSet("Parameter: alarm", -5, "prm");. This function is now used in many data sources modules to account the global alarms of the controllers objects. The function creates the alarm with the category: al{ModId}:{CntrId}[.{PrmId}], where:

ModId — module's ID;

CntrId — controller's ID;

PrmId — parameter's ID from the prm argument.

In general, it should be noted that the notification and alarms registration are different mechanisms that can be used individually for simple projects, or together for large complex projects.

Sometime you can be to need for store and next restore, mostly in restart, some modified data like a hardware working time counters. At all like data source's and hardware's processing you need perform into the logic level of the subsystem DAQ. The task you can do in more ways means storing the data and next it's restoring to some storage but most known ways are:

Create some specific DB table and write/read the data direct to the table by the SQL-requests through SQLReq().

4 Debugging

If you strongly follow the main instruction, you won't encounter here any problems but if you make some doings for self, you may need also for some debugging for them. OpenSCADA provides wide possibilities to debug and observation for problems of programming into OpenSCADA of the regular user's space and for problems into same OpenSCADA and its parts.

Generic approaches for user space debugging, allowed for both LTS and Work versions, mean:

External attributes creation to see for the interim values and to observe for the current execution context.

Debug messages creation to see also for the interim values and to observe for the execution sequence.

The present debugging mechanisms were expanded into the Work version in the way:

User control for debugging by debug messages category, for the OpenSCADA parts and messages of the user space.

Current execution context of the VCA procedures (procedures of the widgets) you can observe on the tab "Attributes" of the proper page or widget of the session of the executed now project (Fig. 6.3). To append some interim values you can temporary append and link some attributes to the widget/page.

Fig. 6.3. Tab "Attributes" of a page or widget of the session of the executed now project.

4.2 Execution sequence debugging

The debugging methods means placing and/or enabling debugging messages and next its observing into the generic messages' archiving and observing interface (Fig. 6.4) or into the interface proper to the OpenSCADA part:

The tab "Diagnostics" of the controller's object of the data source (Fig. 6.5).

The tab "Diagnostics" of the project's object of VCA into the configurator (Fig. 6.6) or of the project's properties of the development mode of UI.Vision (Fig. 6.7).

Fig. 6.4. Generic messages archiving and observing interface.

Fig. 6.5. Tab "Diagnostics" of a controller's object of a data source.

Fig. 6.6. Tab "Diagnostics" of a project's object of VCA into the configurator.

Fig. 6.7. Tab "Diagnostics" of project's properties of the development mode of UI.Vision.

To append debug or other level's messages to self procedures you can use next functions:

Generic: SYS.*.messSys() — To form the system messages with the node path as a category and with the human readable path before the message. The messages will be allowed to observe into the diagnostics interface proper to the OpenSCADA part (Fig. 6.5, 6.6, 6.7).

The same debug messages (the suffix is "Debug" or the level is 0), on Work version, will be allowed to observe only after the debugging enabled, the field "Least level" set to "Debug (0)" (Fig. 6.8), and category(es) of the messages checked (Fig. 6.9), for the details read here! But the debug messages enabling and disabling allows you to include the debug messages permanently into the procedures with the proper category of the place. All other, not debug, messages will show anytime, for levels more or equal to the globally set (Fig. 6.8).

Fig. 6.8. Field "Least level" set to "Debug (0)".

Fig. 6.9. Debug messages checking to debug.

Internal or system parts of the controller's object of the data source enable for diagnostics from self interface by property "Level" set to "Debug (0)" (Fig. 6.5), irrespective.