Processing Messages

The MessageControl module is available for each reporting system and usually runs on the server station for distributed projects. In the process, the posting module shows some status information, such as the size of different tables. The following describes the functionality of the processing logic roughly.

Databases

All data from the reporting system is kept in the project database (Sql server). For more information about setting up the project database, see Chapter 4, “Project Database.”

The capture modules pass new reporting events to the reporting system via a database procedure and are stored in a log table. The message control system processes all incoming message telegrams and records in the log table the successful processing or any errors that have occurred. Especially during commissioning, it can be helpful to check the message processing against the log table (reporting system display, menu item Tracing).

When a new message is triggered (coming event), a new entry is created in the message archive with the identifier “Message is currently pending”. The message retains this status until all conditions for completing the message are met (e.g. message and acknowledged by the user). In the reporting system display, all messages with this identifier are listed in the current display, as soon as the message is completed, it appears in the archive view.

Separate modules are available for capturing, editing and displaying messages. However, all modules use the same database tables for configuration and expiration data.

Invoking an Message Event

At the lowest level, the message handling is implemented by calling an Stored Procedure on the database. You can invoke this stored procedure by an variety of different methods, for example by using an SQL server script

Please keep in mind that you have to make an Message configuration first, which defines the actual text of the message. When calling this Stored Procedure, you give it the “Operand” of your message and applies the “action” on it.

TSql

DECLARE @RC int
DECLARE @time datetime
DECLARE @source nvarchar(50)
DECLARE @algrp int
DECLARE @operand nvarchar(16)
DECLARE @action char(1)

set @time = GETUTCDATE()       --The time the event happened, usually "Now"
set @source = 'My Application' --Your Application name
set @algrp = 1                 --The id of the alarm group you want to record the message to
set @operand = 'Fault0001_Ext' --This is the Message Identifier of the message to activate
set @action = 'K'              --K = Incoming alarm

EXECUTE @RC = [dbo].[al_new_action] 
   @time
  ,@source
  ,@algrp
  ,@operand
  ,@action

C# without VisXpert SDK

using (SqlConnection conn = new SqlConnection("Server=(local);DataBase=xxxx;Integrated Security=SSPI")) {
    conn.Open();

    // 1.  create a command object identifying the stored procedure
    SqlCommand cmd  = new SqlCommand("al_new_action", conn);

    // 2. set the command object so it knows to execute a stored procedure
    cmd.CommandType = CommandType.StoredProcedure;

    // 3. add parameter to command, which will be passed to the stored procedure
    cmd.Parameters.Add(new SqlParameter("@time", DateTime.Now));
    cmd.Parameters.Add(new SqlParameter("@source", "My Application"));
    cmd.Parameters.Add(new SqlParameter("@algrp", 1));
    cmd.Parameters.Add(new SqlParameter("@operand ", "Fault0001_Ext"));
    cmd.Parameters.Add(new SqlParameter("@action", "K"));

    // execute the command
    cmd.ExecuteReader()
}

Parameters of the Stored Procedure

ParameterData typeDescription
@timeDateTimeThe date and time when the event happened
@sourceStringThe Source where the event originated from. usually your application name
@algrpIntThe ID of the Alarm group where the Operand belongs to
@operandStringThe Operand of the message where the action should be performed
@actionStringThe identifier of the action to perform on the operando. See table below
Parameters of Stored Procedure
ActionDescription
KMessage comes: This telegram indicates the beginning of a message. The posting module will enter a new message in the current table when a comment message is received.
GMessage gone: This marks the end of a message. The posting module will then complete the corresponding current message, i.e. re-enact the “gone” time for the message and calculate the duration of the fault.
FAcknowledge: All current messages of the specified controller are completed, i.e. receive the “Gone” time
PProtocol The message does not appear in the current table, but is immediately posted to the archive
EMessage detected This marks the corresponding current message as recognized
QMessage acknowledged Corresponds to the manual acknowledgment of a message
Values for @action

Simulate messages with MessageSimu

With the reporting system simulation, random signal telegrams can be generated manually or timer-controlled. Simulation is only important in the configuration phase for testing purposes in order to test the function of the reporting system if no values from the process are available yet.

For automatic simulation, the posting probabilities for coming, going and error-free entries, as well as the posting interval can be selected.

Print Friendly, PDF & Email