Technical introduction

The TwinCAT 3 EventLogger transmits events. An event is a message or an alarm.

This technical introduction focuses on the data that are transmitted as the contents of an event, because they are necessary for the understanding of the process. The transmission and reception of an event are explained in detail in the API descriptions for PLC and C++ as well as in the samples.

Technical introduction 1:

Events

An event itself is not used directly, but rather the derived types "messages" or "alarms".

An event provides the following common elements of messages and alarms:

EventClass (GUID)

Event classes are a grouping of events (possibly for a topic).

Event-ID (UDINT)

The event is clearly identified within an event class by an Event-ID.

Text (String)

Description of the event. The description is intended for people and can therefore also be internationalized. Arguments can be inserted at runtime to make the text individually adaptable.

Source Info

Source of the occurrence of an event. Source consists of three elements. These can be used as desired, but there is a corresponding recommendation as to how they should be used.

  • Source-ID (INT): TcCOM object ID
  • Source-Name (STRING): Path within the TcCOM object, e.g. path to a function block in a PLC project
  • Source-GUID (GUID): Can be used, for example, to identify a project or a (sub-)product.

JSON Attribute (STRING)

Can be used as desired. Whereas the "text" (see above) is intended for people as recipients, the JSON attribute is intended for programmatic reception. A JSON string can easily be created (serialized) and processed (deserialized). TwinCAT offers the JsonXml library in real-time for this (see Documentation - PLC library Tc3_JsonXml).

In addition to these elements, events possess further elements, which are described in the TMC Editor.

Messages

Messages are stateless. They are sent when called and the corresponding registered components are delivered.

Identification

Messages are identified by the EventClass and Event-ID.

Alarm

As opposed to a message, an alarm is not stateless.

It has the following alarm states:

Technical introduction 2:

In addition, a confirmation can be demanded. Distinction is made between the following confirmation states:

Technical introduction 3:

Calling the corresponding methods causes an event to be transmitted and sets the alarm to the respective state.

If the call of a method is invalid in the current state, this will be indicated by a return value.

When shutting down TwinCAT (RUN → CONFIG transition), a dispose that sets a Clear time stamp is executed internally for all alarms in the Raised state. There is no confirmation for these alarms.

Identification

The TwinCAT 3 EventLogger identifies an alarm using the EventClass, Event-ID and Source Info. Thus an alarm (combination of EventClass and Event-ID) can be used at different points in a program. For example, an alarm "storage empty" can be used for different storages, since different "Source Info" is provided at runtime (see also Handling sources).

Architecture

The TwinCAT 3 EventLogger transmits events centrally between other components. These components include the real-time programming interfaces PLC or C++ as the primary source of events.

During the development the messages can be displayed in the TwinCAT Engineering (XAE).

An HMI, for example, can receive messages and display them accordingly. The customer can create further components of his own for receiving events.

Technical introduction 4:

The TwinCAT 3 EventLogger keeps a limited number of the last events in a cache. This can be queried from the Engineering, for example after a restart, in order to enable a diagnosis to be made. The cache is dependent on the secured shutdown of the computer.

Technical introduction 5:

Cache not persistent under Windows CE

Starting with TwinCAT 3.1 Build 4024.25 the cache of events is not persisted under Windows CE systems for performance reasons.

Workflow

The general workflow for establishing asynchronous communication between components is as follows:

  1. Creation of a new TwinCAT project.
  2. Definition of event classes and events in the TwinCAT type system.
  3. Execution of the automatic code generation in order to provide the source code for the real-time programming language in TwinCAT.
  4. Implementation of the use and thus the sending and receiving of events.

See also:

Further Information