From OpenSCADAWiki
Jump to: navigation, search

Signaling (Alarms)

An important element of any visualisation interface is the user notification about the violation — signalling. To simplify the perception, but also in mind the close connectivity of visualisation and notification (as a rule, the notification complements the visualisation) it is decided to integrate the interface of the notification in the visualisation interface. To do this, all the widget provides two additional attributes of the session level: "alarm" and "alarmSt". The attribute "alarm" is used to form the signal by the widget, according to his logic, and the attribute "alarmSt" is used to control the signalling fact of the branch of the session tree.

The "alarm" attribute is a string that has the following format: "{lev}|{categ}|{message}|{type}|{tp_arg}"
Where:

  • lev — signalling (alarm) level; number from 0 to 255;
  • categ — alarm category; parameter of the acquisition subsystem, object, path, or their combination;
  • message — signalling (alarm) message;
  • type — type of the notification, is formed as an integer number (0...7), which contains the flags of notification methods; typical notification methods:
    • 1 — visual;
    • 2 — beep tone, is frequently made through the PC-speaker;
    • 4 — sound signal from the sound file or the speech synthesis, and if in the tp_arg the name of the resource of the sound file is specified, then play it, or in other case the speech synthesis from the text specified in message is made.
  • tp_arg — argument of the type; often used to directly indicate the resource of a sound signal — a file of sound format, when the sound signal is made.

Attribute "alarmSt" is an integer number that represents the maximum alarm level and the fact of the quietance of the branch of the tree of the session. Format of the number is as follows:

  • first byte (0...255) characterises the level of the alarm of the branch;
  • the second byte indicates the type of notification, as well as in the attribute "alarm";
  • the third byte indicates the type of notification without quietance, as well as in the attribute "alarm";
  • the fourth byte has a special appointment, which is defined by separate bits:
    • bit 0 — indicates, by sets, to the quietance fact of the notification into first byte;
    • bit 1 — indicates, by sets it and the bit 0, to the quietance return — enable back the quietance.

Alarm forming and receiving of it by the visualiser.
The alarm forming is performed by the widget itself, by setting its own attribute "alarm" in appropriate way and, in accordance with it, the attribute "alarmSt" of the current and the parent widget. Visualisers receive signal notifications using the standard mechanism of notification about changes of the widget attributes.

Taking into account that the processing of the signalling conditions is made in the widgets, the pages containing the objects of signalling should be executed in the background, regardless of their openness to the moment. This is done by setting a flag of the background execution of the page.

Although the mechanism of signalling is built in the visualisation area, the possibility of forming non-visual elements of signalling remains, for example, by creating a page that will never open.

Quietance
Quietance — approving process is a fact of the operative personal take its attention to the violation into the TP work. The process mostly means of take actions for the violation eliminating and pressing to the button of the alarm quieting.

Quietance performs by specifying the root of the branch of the widgets and the types of notification, which allows to make quietance on the side of the visualiser, as in groups, for example, on the signalling object, and individually by the object of the source. It is possible to independently quietance different types of alarms. Setting of the quietance is made by the simple modification of the attribute "alarmSt".

Example of the script to work with the signals gives below:

//Separating the fact of the presence of alarms of different methods-types of notification
cvt_light_en = alarmSt&0x100; cvt_alarm_en = alarmSt&0x200; cvt_sound_en = alarmSt&0x400;
//Separating the fact of the presence of alarms without quietance of various ways of notification
cvt_light_active = alarmSt&0x10000; cvt_alarm_active = alarmSt&0x20000; cvt_sound_active = alarmSt&0x40000;
//Processing of the button's events of quietance and the quietance for different ways of notification
for(ev_rez = "", off = 0; (sval=event.parse(0,"\n",off)).length; ) {
  if(sval == "ws_BtPress:/cvt_light") alarmSt = 0x1000001;
  else if(sval == "ws_BtPress:/cvt_alarm") alarmSt = 0x1000002;
  else if(sval == "ws_BtPress:/cvt_sound") alarmSt = 0x1000004;
  else ev_rez += sval + "\n";
}
event = ev_rez;

External notification methods
The first and the typical method of notifications is screen's light notification by alarm colors and its dynamic about proper visual elements, which always presents and does not require of specific configuration. But often we need for an external type notification, for example: external lamp, PC buzzer or "howler", arbitrary sound, synthesised speech and etc.

In order to realize this possibility, the external methods of the notification and the corresponding notification types, are freely described for the visualisation server and the visualiser itself. On the side of the visualisation server, the formation/receipt of the notification resource and the notification itself is described. On the side of the visualiser, the notification is described according to the resources of the visualisation server.

Description of the rules and scenarios of the notifications performs with user attributes of the text type for pages of the visualisation project, which applies at the page open. That is, potentially, for each open page, you can describe your own rules of the notification, though, it's usually enough and describes the general rules of the notification on the project's main page — a page that opens one-off and does not close at work:

  • For the visualisation server/engine, by the attribute "notify{N}" into the format:
//flags=notifyServ[{DL}][|resource[|queue[|qMergeMess]]]
//resStatic={ResourceFile}
if(doRes) { The command text to form the resource. }
if(doNtf) { The command text to notify. }
  • For a visualiser by the attribute "notifyVis[Vision|WebVision]{N}" into the format:
//flags=notify[{DL}][|resource[|queue[|quietanceRet]]]
//name={The notifier name}
//ico={The icon name}
{ The notification command text to any or concrete visualiser. }

Flags:

  • notify[{DL}], notifyServ[{DL}] — enables the notification with the repeating by the time DL, if the set; for DL = 0 the repeat carried out immediately.
  • resource — request-form (force) the notification resource from the visualisation server, can be an audio file, a text or other data for the notification produce; but currently the notifiers mostly expect audio.
  • queue — the notification resources are determined not only by the global sign of alarming and quietance, but also according to the priority sources queue of the notification-resources. The queue is formed on the side of the visualisation server, and for the visualisers it is indicated the need to work with it when requesting resources.
  • qMergeMess — merging the notifications into the queue by equality their messages.
  • quietanceRet — possibility of the visualiser for the quietance recall-return i.e. in fact — the notification enable back.

Presence of the field "resStatic" enables the resource obtaining directly from the resource table or a file, pointed in the way like to the "Media" primitive.

The exchanging variables:

  • en[0,1] — the notification enable (1) or disable (0);
  • doNtf[0,1] — call the script of the notification;
  • doRes[0,1] — call the script of the resource forming;
  • res — content or content's file name of the resource, for the external scripts;
  • resTp — resource type, like to "audio/ogg"; is return and placed to stdout (for Shell) for doRes;
  • mess — message-parameters of the forming the resource and the notification;
  • lang — language of the current user or system;
  • prcID — the procedure unique ID (like to "ses_AGLKS_ntf2"), mostly for temporary files safe creation.

The examples and comments to work of the typical notification methods:

  • Beep (buzzer) on the visualiser or the visualisation server side:
  • alarm = "10|Prm||0x02"
  • notifyVisVision1 | notify1 =
//flags=notify|notifyServ
if(en) SYS.system("beep -f 1000 -l 1000000 &", true);
else if((beepPID=SYS.system("pidof beep")).toInt()) SYS.system("kill "+beepPID);
  • notifyVisVision1 | notify1 =
#!/bin/sh
#flags=notify|notifyServ
if test $en = 1; then
	beep -f 1000 -l 1000000 &
else
	beepPID=$(pidof beep)
	if test "x$beepPID" != "x"; then kill $beepPID; fi
fi
  • Repeating play for ready audio file, one common, on the visualiser or the visualisation server side:
  • alarm = "10|Prm||0x04"
  • notify2 | notifyVisVision2 =
//flags=notify2|notifyServ2
if(en) SYS.system("play -q alarm.ogg");
  • notify2 | notifyVisVision2 =
#!/bin/sh
#flags=notify2|notifyServ2
if test $en = 1; then play -q alarm.ogg; fi
  • Play an individual audio file for the source, on the visualisation server side:
  • alarm = "10|Prm||0x04|res:al_prm1"
  • notify2 =
//flags=queue
  • notifyVisVision2 =
//flags=notify2|queue
if(doNtf && en && res.length) {
  SYS.fileWrite("tmpPlay", res);
  SYS.system("play -q tmpPlay");
  SYS.fileRemove("tmpPlay");
}
  • notifyVisVision2 =
#!/bin/sh
#flags=notify2|queue
if test $doNtf = 1 -a $en = 1 -a -s $res; then play -q $res; fi
  • Speech synth for an individual message for the source, on the visualiser side:
  • alarm = "10|Prm|Text message of the speech synth|0x04"
  • notify2 =
//flags=queue
  • notifyVisVision2 =
//flags=notify2|queue
if(doNtf && en && mess.length) {
  SYS.fileWrite("tmpForSpeech", mess);
  SYS.system("festival --tts tmpForSpeech");
  SYS.fileRemove("tmpForSpeech");
}
  • notifyVisVision2 =
#!/bin/sh
#flags=notify2|queue
if test $doNtf = 1 -a $en = 1 -a "x" != "x$mess"; then
  echo $mess > tmpForSpeech
  festival --tts tmpForSpeech
  rm tmpForSpeech
fi
  • Preparing a sound file, one common, and playing it on the side of the visualiser or the visualisation server:
  • alarm = "10|Prm||0x04"
  • notify2 =
//flags=notify2|notifyServ2|resource
if(doRes) res = SYS.fileRead("alarm.ogg");  //Insert here a different method of the generation
if(doNtf && en && res.length) {
  SYS.fileWrite("tmpPlay", res);
  SYS.system("play -q tmpPlay");
  SYS.fileRemove("tmpPlay");
}
  • notify2 =
#!/bin/sh
#flags=notify2|notifyServ2|resource
if test $doRes = 1; then cp -f alarm.ogg $res; fi  #Insert here a different method of the generation
if test $doNtf = 1 -a $en = 1 -a -s $res; then play -q $res; fi
  • notifyVisVision2 =
//flags=notify2|resource
if(en && res.length) {
  SYS.fileWrite("tmpPlay", res);
  SYS.system("play -q tmpPlay");
  SYS.fileRemove("tmpPlay");
}
  • notifyVisVision2 =
#!/bin/sh
#flags=notify2|resource
if test $en = 1 -a -s $res; then play -q $res; fi
  • Prepare an individual audio file for the source of notification through the speech synth, on side of the visualiser or the visualisation server:
  • alarm = "10|Prm|Text message of the speech synth|0x04"
  • notify2 =
//flags=notify2|notifyServ2|queue
if(doRes && mess.length) {
 SYS.fileWrite("tmpText", mess);
 SYS.system("text2wave tmpText -o tmpWAV");
 res = SYS.fileRead("tmpWAV");
 SYS.fileRemove("tmpText"); SYS.fileRemove("tmpWAV");
}
if(doNtf && en && res.length) {
 SYS.fileWrite("tmpPlay", res);
 SYS.system("play -q tmpPlay");
 SYS.fileRemove("tmpPlay");
}
  • notify2 =
#!/bin/sh
#flags=notify2|notifyServ2|queue
if test $doRes = 1 -a "x" != "x$mess"; then
 echo $mess > tmpText
 text2wave tmpText -o $res
 rm tmpText
fi
if test $doNtf = 1 -a $en = 1 -a -s $res; then play -q $res; fi
  • notifyVisVision2 =
//flags=notify2|queue
if(en && res.length) {
 SYS.fileWrite("tmpPlay", res);
 SYS.system("play -q tmpPlay");
 SYS.fileRemove("tmpPlay");
}
  • notifyVisVision2 =
#!/bin/sh
#flags=notify2|queue
if test $en = 1 -a -s $res; then play -q $res; fi