Advertisement
7.2.3
Reliability
7.2.3.1
Recognizing events (time response)
There is a limit to how many events for which messages are configured can appear in rapid succession. While one
message is being sent, any other events occurring can only be stored. However, the event queue responsible for this
purpose is of limited size. Once this is used up, all subsequent events are discarded. These lost events are counted in
the Messaging variable "EventOverruns".
It isn't possible, however, to reconstruct afterwards which messages were lost due to discarded events!
As soon as Messaging is no longer occupied with sending a message, the accumulated events are translated to
message texts and entered into the sending queue. This queue's volume is also limited, so that messages can be lost
if they are generated more rapidly than they can be sent.
How long a message can be kept in the queue depends on the one hand on the actual sending duration (from a few
seconds to approx. 5 min), and on the other hand on the receiver's capacity to be reached, since, in the case of an
error the message will be repeated over and over.
If the modem is busy because a PC has dialed in, then all messages which require that modem will be delayed until
it's free. Thus in this case, the messages could stay in the queue indefinitely!
In this way, the transmitting is delayed and the queue's available space can be exhausted, for which reason no new
messages may be able to be accommodated.
All lost messages are counted in the Messaging variable "AllMessageLosses". In addition, the variable
"ThisMessageLosses" records for each individual message configuration how often a message stemming from this
configuration was lost.
Every message has the following addendum to provide a total overview (the numerical values are examples):
(This event :2
(All messages: 23 Unable to send: 3 Overflow: 0 )
This conforms to the template:
(This event : "ThisMessageCounter" Unable to send: "ThisMessageLosses")
(All messages: "AllMessageCounter"
"EventOverruns")
7.2.3.2
Delivery of the messages
As soon as there is a message in the queue ready to be sent, an attempt is made to send it. If an attempt fails, the
message is returned to the queue for a repeat attempt later following a pause. There is a specifiable delay before the
next attempt to send the message.
This process is repeated several times, each time increasing the pause between delivery attempts. Only after a
certain amount of repetitions has failed, the message is considered unable to be sent, and is deleted. The Messaging
variable "AllMessageLosses" and the corresponding instance of "ThisMessageLosses" are updated accordingly.
If the modem is busy, for instance due to a PC dialing in, all messages to be sent via modem must be held back until
it's once again available. Therefore, an occupied modem won't lead to failed delivery!
Emails which can be sent via the LAN are delivered even if the modem is busy. If appropriate, they can be bumped up
in the sending queue. Thus, the messages aren't necessarily sent in the order they were created!
If a message can't be delivered due to configuration errors such as a wrong telephone number or password, then
multiple attempts to deliver it may come at (substantial) monetary cost. Therefore it is strongly recommended to
test every message configuration under authentic conditions. The producer of SICAM Q80 7KG8080 is not
liable for any costs resulting from the use of Messaging!
Unable to send: 0 )
Unable to send: "AllMessageLosses" Overflow:
Power Quality Recorder SICAM Q80 7KG8080, System manual
Extras
E50417-H1076-C420-A2, Release 12.01.2015
223
Advertisement
