Application Diagnostics with Unity

System User Guide

[source code]
33003586.00
Contents
Application Source Code...........................................................................................................3
General........................................................................................................................................4
System ........................................................................................................................................5
Architecture.............................................................................................................................5
Installation...............................................................................................................................7
Hardware .............................................................................................................................................................8
Software ............................................................................................................................................................10
Communication .................................................................................................................................................11
Implementation .....................................................................................................................12
General Settings................................................................................................................................................14
Static Diagnostics..............................................................................................................................................17
Dynamic Diagnostics.........................................................................................................................................19
Sequencer Diagnostics .....................................................................................................................................25
DFB Diagnostics................................................................................................................................................26
Diagnostics Viewer............................................................................................................................................31
Appendix...................................................................................................................................33
Detailed Components List.....................................................................................................33
Contact......................................................................................................................................34

Introduction This document is intended to provide a quick introduction to the described System.
It is not intended to replace any specific product documentation. On the contrary, it offers
additional information to the product documentation, for installing, configuring and starting up the
system.

A detailed functional description or the specification for a specific user application is not part of
this document. Nevertheless, the document outlines some typical applications where the system
might be implemented.

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 2

 Abbreviations

Word/Expression Explanation

PLC Programmable Logic Controller

HMI Human Machine Interface

PC Personal Computer

V AC Alternating Current

V DC Direct Current

OPC Process automation interface (OLE for Process Control)

FB Function Block

DFB Derived Function Block

SFC Sequential Function Chart

Quantum Is the product name of a Schneider Electric PLC

Premium Is the product name of a Schneider Electric PLC

Unity Pro Is the name of a Schneider Electric software product for

programming PLCs

Application Source Code

Introduction Examples of the source code and wiring diagrams used to attain the system function as
described in this document can be downloaded from our „Village“ website under this
link.

Using the The example software contains two Unity projects, one each for the Quantum and
Example Premium PLCs respectively. Please note that the Unity projects are import files, which
Software can be opened by selecting Open from the File menu and the file type *.xef.

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 3

 General

Introduction Application diagnostics are used to clarify the causes of a system or machine
malfunction for operating personnel in order to rectify the problem as quick as possible.
For this purpose, function blocks known as diagnostics blocks have been integrated into
the PLC program which monitor the program for specific values and temporal
sequences and report any deviations from set values as possible faults.
Once a fault has been detected, it is written to the fault memory (i.e. the diagnostics
buffer) in the form of a description comprising the block name, a comment, the time of
the fault, etc. As the buffer can be accessed from an external source, e.g., Unity or the
OPC server, fault data can be displayed directly. Moreover, once a fault has been
detected, its program logic is analysed for incorrect variable values, i.e., the variables
whose incorrect values triggered the malfunction can be detected. These variables are
also entered in the fault memory as causes of the fault.
The following diagnostic functions are supported:

• Static diagnostics:
Monitoring of a logical network for the Boolean values "false" or "true". If the relevant
Boolean value is not detected within a certain tolerance window, a message is
generated and the network is analysed for missing or incorrect signals.
Function Blocks: Process requirements (D_PRE) and signal groups (D_GRP)

• Dynamic diagnostics:
Here, the enabling of an action, its execution and the reaction to its execution are
monitored. The action must be enabled within a tolerance window on the basis of a
locking network. The execution must be indicated within a specific period of time and
remain pending as a permanent reaction until a deactivation signal is sent. Incorrect
signals are detected and displayed by the diagnostics function.
Function Blocks: Locking diagnostics (D_LOCK), reaction diagnostics (D_REA), action
diagnostics (D_ACT) and combined diagnostics (D_DYN)

• Sequencer diagnostics
The dynamic reaction of individual steps can be monitored for undershooting the
minimum execution time and overshooting of the maximum execution time. The
incorrect signals associated with the next transition are detected and displayed.
Function Blocks: None; setting is directly in sequencers.

• Diagnosing derived function blocks (DFBs)

Boolean inputs can be monitored for the value "true" or "false". The diagnostics
function detects incorrect signals on the upstream network and displays them.
Moreover, within the block, text messages can be sent to the diagnostics function for
display.
Function Blocks: Registration (REGDFB, UREGDFB) and deregistration (DEREG) as
well as text messages (REGEXT)

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 4

 System

Introduction The system chapter describes the architecture, components and dimensions of the
devices and parts used.

Architecture

Overview The system is a PLC on which the program code for an application is loaded. The
application diagnostics function must be added to the program code in order to monitor
and analyse specific application states. If a fault state is detected (diagnosed) the
associated data is written to the diagnostics buffer as a fault. Faults can be read out and
displayed, for example, via Unity or the OPC server.
The figure below illustrates the essential elements of diagnostics, starting with the
diagnostics logic, which sends its messages to the diagnostics buffer. The viewers then
access the buffer.
In the example system below, the various types of diagnostics, the associated function
blocks and their operation are illustrated.

Layout

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 5

Components Hardware:
• TSX Premium (PLC)
Or
• TSX Quantum (PLC)

Software:
• Unity Pro 2.0.2 (PLC)

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 6

 Installation

Introduction This chapter describes the steps required to install the hardware and set up the software
for the task associated with the following application:

Layout The following points are relevant for application diagnostics in the PLC program:

• Application diagnostics must be activated in the PLC project and the diagnostics
functions, e.g., function blocks must be configured in the program.
• A display unit, usually a PC, must be available for viewing the diagnostics data. In its
simplest form, this will be the programming device for the PLC as the Unity
programming software with integrated diagnostics viewer is installed on this unit.
• There must be a connection between the PLC and the display unit via which
diagnostics data can be exchanged between the two devices.
The following options are available for displaying diagnostics data but are not described
in more detail in this document:

• Diagnostics data on the PLC can optionally be polled via an OPC server, with the
result that the data is available for viewing on any display unit.
• The OPC server may poll a number of PLCs and then display all the data recovered
for viewing on a single unit.
• Similarly, data polled via the OPC server can be distributed to a number of different
display units.

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 7

 Hardware

General • Either a Premium or Quantum Unity PLC can be used (the minimum configuration
must include a power supply and a rack).
• Depending on the power supply card used, a 230 V AC or 24 V DC supply is required.
• A connection between the programming device (PC) and PLC is required in order to
program and display the diagnostics messages. This can be established either via a
serial link or, if available, via a USB or Ethernet link.

Premium PLC TLX P57 5634M

1 Display LEDs
2 Eject button for PCMCIA-SRAM card
3 Terminal port (TER)
5 Slot for a memory expansion card (PCMCIA)
6 Slot for a communication card (PCMCIA)
8 RJ45 connector for Ethernet connection
9 USB port
10 RESET button

Premium TSX PSY 5500

Power Supply

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 8

Quantum PLC 140 CPU 651 60

1 Model number, module description, color code

2 Cover (open)
3 LCD (obscured by the cover here)
4 Mode selector
5 Keypad
6 Modbus port
7 USB port
8 Modbus Plus port
9 PCMCIA slot (type II, type III)
10 Ethernet communication indicators
11 Ethernet port
12 Battery
13 Reset button

Quantum 140 CPS 114 00

Power Supply

1 LED panel
2 Model number, module description, color code
3 Field wiring port
4 Cover for field wiring port
5 Removable flap
6 Labeling plate

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 9

 Software

General The Unity Pro configuration software must be installed for the Premium PLC.
The following installation requirements apply in respect to all software packages:

• Operating system: Windows 2000 (SP1 minimum) or Windows XP

• Free hard disk memory: At least 2.4 GB, 4.4 GB recommended
• User memory: At least 512 MB, 1024 MB recommended.
• Processor: Pentium III or higher with min. 800 MHz, 1.2 GHz recommended.
• Interfaces: Serial interfaces as a minimum, USB recommended in addition
• Additional software: Internet Explorer 5.5 or higher

Software

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 10

 Communication

General A connection between the programming device (PC) and PLC is required in order to
program and display diagnostics messages. This can be established either via a serial
link or, if available, via a USB or Ethernet link.

Premium PLC The UNY XCA USB 033 remote connection

TSX P57 5634M cable is used for the connection between
the PC’s USB ports (Unity Pro) and the
PLC.
Alternatively, a serial link (PC <->
TER/AUX) can be established using cable
TSX PCX 1031 (switch position "0").

Quantum PLC The UNY XCA USB 033 remote connection

140 CPU 651 60 cable is used for the connection between
the PC’s USB ports (Unity Pro) and the
PLC.
Alternatively, a serial link to the Modbus
port can be established using cable 110
XCA 282 01 and adapter 110 XCA 203 00.

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 11

 Implementation

Introduction The Implementation chapter describes all the steps required to initialize, parameterize,
program, and start up the system.

Functional Application diagnostics comprises of three essential elements: the diagnostics logic, the
Description diagnostics buffer and the diagnostics viewer.
The diagnostics logic must be created and programmed in accordance with the
application during PLC configuration. Depending on the requirements, static and
dynamic diagnostics, as well as sequencer and DFB diagnostics, can be set up.
The diagnostics buffer is located on the PLC and does not require configuration.
Either the internal viewer in Unity or the OPC server (polling of diagnostics messages)
can be used to display diagnostics data. The message display format can be
customised to meet the needs of the user and/or process. If an external viewer is used
via the OPC server, communication between the OPC server and viewer must be
configured.

Layout

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 12

Procedure The procedure for creating diagnostics logic based on the four types of diagnostics
described, is outlined in this section. An existing PLC project, based on Unity, is used as
the basis. The following topics are discussed:
1. General settings for diagnostics
2. Static diagnostics: Process requirements and group signals
3. Dynamic diagnostics: Action, reaction and lock diagnostics
4. Sequencer diagnostics: Time monitoring of individual steps
5. Derived function blocks: DFB diagnostics
6. Diagnostics display in Unity

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 13

 General Settings

Introduction This chapter describes how to activate the diagnostics functions for a PLC project and
the information settings common to all diagnostics blocks.

Activating 1 In order to be able to run

Diagnostics diagnostics in a PLC project, the
function must first be activated
for the project. The
Tools->Project Settings
menu is used for this purpose.
Note: The setting is project-
specific and must be repeated
for each individual PLC project.

2 Application diagnostics is
activated on the Build tab.
When activating diagnostics,
you must select the Local
diagnostic application level.

3 The entire project must be

rebuilt when diagnostics has
been selected.

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 14

Information When a diagnostics block reports a fault, information from the block is written to the
Settings buffer. This includes the block instance, block comment and what is known as the area
Blocks number. As all three codes are used to identify and describe the diagnosis, we
recommend that this data is customised as described below.
The block instance and associated comment can be combined to create a description by
means of which the block triggering the diagnosis is instantly recognisable. For fieldbus
monitoring, for example, the "DIAG_FBUS" instance and "Fieldbus diagnostics"
comment are specified. This information will appear in the diagnostics viewer.
Moreover, the area number can be used to indicate an area in which the diagnosis was
triggered. There are a total of 15 areas available, i.e. a system can be divided into 15
different areas. This is particularly useful if, for example, processes need to be executed
in parallel or a PLC is controlling more than one system.
Acknowledgement procedures can also be specified. You can decide whether the
diagnosis must be acknowledged by the user on the display unit or if the message is
acknowledged automatically by the PLC.

1 Information data cannot be

modified via the block pins but
must be customized in the
Variables Editor ("Function
Blocks" tab) once the block has
been placed. The instance name
and comment are entered
directly. The area number and
acknowledgement procedure
are indicated via public variables
("area_no", "op_ctrl").
op_ctrl:= true Acknowledgement
required
op_ctrl:= false Automatic
acknowledgement
2 Acknowledgement procedures
and area numbers can also be
customized in the program, for
example, when the PLC starts
up (here, an example with
structured text).

Information As in blocks, the same information settings are available for sequencers, although the
Settings data entry procedure differs from that for blocks. The instance name and comment are
Sequencers assigned directly as the step name and step comment, when the step is programmed,
but the area number and acknowledgement procedure are assigned to the entire
sequencer.

Continued on next page

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 15

Information 1 Start the configuration of the
Settings step by double-clicking on the
Sequencers step to open it and entering the
step name and comment.
Note: As with instance names,
step names must be unique.

2 The area number and

acknowledgement procedure
can only be specified for the
entire sequencer in the
Properties dialog box for the
section (SFC specific field).
Note: In the dialog, the
acknowledgement type is
indicated as operator control.
Activating operator control
means user acknowledgement
is mandatory.

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 16

 Static Diagnostics

Introduction Static diagnostics describes the monitoring of signals and networks not linked directly to
an action such as the controlling of a drive. This means the blocks for static diagnostics
only have one fault output and no action output. Static diagnostics is divided into
process requirements and signal-group monitoring.

Process Process requirements are signals that are absolutely essential for the operation of a
Requirements system, such as a sign-of-life signal from a fieldbus or activated cooling. For this reason
process requirements are always monitored for the value "true". Monitoring is performed
via the D_PRE block.

1 Block connection:
• ED enables monitoring.
• DTIME is the time during
which the signal at IN must
adopt the value "true".
• IN: The network connected to
this signal is monitored for the
value true and analysed for
incorrect values.
• ERR indicates an active fault
(message in buffer).
2 In the example programming
example, there is an AND block
with four signals at the IN input.
In the event of a fault (IN =
false) the block identifies which
signals at the AND block are at
false and makes entries in the
diagnostics buffer accordingly.

Signal Groups Signal groups are signals that are not essential for the operation of a system but can
have an adverse effect on it. An example of such a group would be the fault signal from
a fan running in a group of fans. Unlike process requirements, signal groups are
monitored for the value false. Monitoring is performed using the D_GRP block.

Continued on next page

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 17

Signal Groups 1 Block connection:
• ED enables monitoring.
• DTIME is the time during
which the signal at IN must
adopt the value "true".
• IN: The network connected to
this signal is monitored for the
value "false" and analyzed for
incorrect values.
• ERR indicates an active fault
(message in buffer).
2 In the example circuit, there is
an OR block with four signals at
the IN input. In the event of a
fault (IN = true) the block
identifies which signals at the
OR block are at "true" and
makes entries in the diagnostics
buffer accordingly.

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 18

 Dynamic Diagnostics

Introduction In dynamic diagnostics, an action output is set on the basis of a trigger and an input
network (locking network) that is to be monitored. If the locking conditions are met, an
action output is switched. If the locking conditions are not met, an entry is made in the
diagnostics buffer (as per static diagnostics). The absent locking-condition signals
causing the switching of the output are written to the buffer.
It is also possible to check for a reaction to the triggering of the action output within a
specific time limit (action monitoring) and, if required, to check for the maintaining of that
reaction until a stop signal is received (reaction monitoring).
An example would be a cam that can only travel once the gap monitoring function at the
cam input and output cannot detect anything (locking condition). When the run
command is received, the cam must reach the next stage within a specific period of time
(action monitoring) and remain there until the next run command (reaction monitoring) is
received.
The blocks available for dynamic diagnostics are locking diagnostics (D_LOCK),
locking/action diagnostics (D_ACT), locking/action/reaction diagnostics - also known as
combined diagnostics - (D_DYN), and reaction diagnostics (D_REA).

Locking Locking diagnostics describes the monitoring of the locking condition. If this is met
Diagnostics during the delay when the trigger is set, the output will be set. The occurrence of the
reaction to the setting of the output is simply used to deactivate the output (the function
does not check whether the reaction occurs within a specific period of time).

Continued on next page

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 19

Locking 1 Block connection:
Diagnostics
• ED enables monitoring.
• DTIME is the time during
which the lock at UNLOCK
must adopt the value "true".
• TRIGR is the trigger to start
the action; the delay is
activated on a rising edge.
• UNLOCK is the locking
condition which must be met
in order to enable ACT.
• REACT: Feedback signal
indicating that the action has
been completed.
• ERR indicates an active fault
(message in buffer).
• ACT: Action output which
must be set while the locking
condition is true and the
trigger is pending and until
REACT is received.
2 In the example circuit, there is
an AND block with two signals
as a lock at the UNLOCK input.
In the event of the lock not being
present (UNLOCK = false), the
block identifies which signals at
the AND block are set to "false"
and makes entries in the
diagnostics buffer accordingly.
The ACT output is not set.
By way of a feedback signal for
the action, an AND block with
two signals is connected at the
REACT input. This block uses
these signals simply to
deactivate the ACT output.

Locking/Action Locking/action diagnostics describes the monitoring of locking and action execution.
Diagnostics The locking condition must be met during the delay when the trigger is set in order for
the output to be set. Similarly, once the output has been set, the action must be
executed within a delay time of a second. The execution of the action is indicated by
the setting of the reaction input. This signal is then used to deactivate the output.

Continued on next page

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 20

Locking/Action 1 Block connection:
Diagnostics
• ED enables monitoring.
• DTIMEL is the time during
which the lock at UNLOCK
must adopt the value "true".
• DTIMEA is the time during
which the execution of the
action must be indicated with
the value "true" at REACT.
• TRIGR is the trigger to start
the action; the delay is
activated on a rising edge.
• UNLOCK is the locking
condition which must be met
in order to enable ACT.
• REACT: Feedback signal
indicating that the action has
been completed.
• ERR indicates an active fault
(message in buffer).
• ACT: Action output which
must be set while the locking
condition is true and the
trigger is pending and until
REACT is received.
2 In the example circuit, there is
an AND block with two signals
as a lock at the UNLOCK input.
In the event of the lock being
absent (UNLOCK = false), the
block identifies which signals at
the AND block are set to "false"
and makes entries in the
diagnostics buffer accordingly.
The ACT output is not set.
By way of a feedback signal for
the action, an AND block with
two signals is connected at the
REACT input. If the feedback
signal is not received within the
specified time, the block
identifies which signals at the
AND block are set to "false" and
makes entries in the diagnostics
buffer accordingly. Once the
feedback signal has been
received, the ACT output is
reset.

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 21

Locking/Action Locking/action/reaction diagnostics describes the monitoring of locking, action
/Reaction execution and reaction stability. The locking condition must be met during the delay
Diagnostics when the trigger is set in order for the output to be set. Similarly, once the output has
been set, the action must be executed within a second delay. The execution of the
action is indicated by the setting of the reaction input. This signal is then used to
deactivate the output. Moreover, the reaction signal must be maintained continuously
until a stop signal is received and may only be interrupted during a tolerance window,
e.g., due to the input bouncing. In addition, in respect of this block, a distinction is
drawn between two types of action diagnostics: motor (M) and pulse (I) mode. In motor
mode, action diagnostics is interrupted when the trigger is reset, but in pulse mode, the
action must occur before the delay expires, even if the trigger has been reset.

1 Block connection:
• ED enables monitoring.
• DTIMEL is the time during
which the lock at UNLOCK
must adopt the value "true".
• DTIMEA is the time during
which the execution of the
action must be indicated with
the value "true" at REACT.
• DTIMER is the maximum time
during which the reaction
signal may be interrupted
following initial occurrence.
• TRIGR is the trigger to start switch:= true I mode
the action; the delay is switch:= false M mode
activated on a rising edge.
• UNLOCK is the locking
condition which must be met
in order to enable ACT.
• REACT: Feedback signal
indicating that the action has
been completed.
• SWITCH: Changeover from/to
M and I modes.
• STOP is used to deactivate
reaction monitoring.
• ERR indicates an active fault
(message in buffer).
• ACT: Action output which
must be set while the locking
condition is true and the
trigger is pending and until
REACT is received.

Continued on next page

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 22

Locking/Action 2 In the example circuit, there is
/Reaction an AND block with two signals
Diagnostics as a lock at the UNLOCK input.
In the event of the lock being
absent (UNLOCK = false), the
block identifies which signals at
the AND block are set to "false"
and makes entries in the
diagnostics buffer accordingly.
By way of a feedback signal for
the action, an AND block with
two signals is connected at the
REACT input. If the feedback
signal is not received within the
specified time, the block
identifies which signals at the
AND block are set to "false" and
makes entries in the diagnostics
buffer accordingly.
Moreover, a signal is connected
to the STOP input to indicate
completion of reaction
monitoring.

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 23

Reaction Reaction diagnostics describes the monitoring of the stability of a signal following initial
Diagnostics setting and until a completion or stop signal is received. Once it has been set, the signal
must be maintained continuously until a stop signal is received and may only be
interrupted during a tolerance window, e.g., due to the input bouncing.

1 Block connection:
• ED enables monitoring.
• DTIME is the maximum time
during which the reaction
signal may be interrupted
following initial occurrence.
• REACT: Feedback signal
indicating that the action has
been completed.
• STOP is used to deactivate
reaction monitoring.
• ERR indicates an active fault
(message in buffer).
2 By way of a feedback signal for
the action, an AND block with
two signals is connected at the
REACT input. If this signal
changes to "false", the block
identifies which signals at the
AND block are set to "false" and
makes entries in the diagnostics
buffer accordingly.

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 24

 Sequencer Diagnostics

Introduction Sequencer diagnostics is used to monitor the dynamic response of the individual steps
in a sequencer. It analyzes the transition conditions if a step is not completed within the
specified time and enters the causes, i.e., the faulty transition signals, in the diagnostics
buffer. The same analysis is performed in the event of a step being completed
prematurely (undershooting of minimum time).

Activation 1 In order to activate diagnostics,

at least one of the two activation
times must be entered for the
step to be monitored. Double-
click on the step to open the
dialog box and enter the
relevant time as a value or
variable.
Note: When editing step times,
you can enter a step name and
comment at the same time.

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 25

 DFB Diagnostics

Introduction Derived function block (DFB) diagnostics serve a number of different purposes: First, it
can be used to diagnose the logic of user-defined function blocks and, therefore, to
achieve a complete diagnosis of the entire PLC program. Secondly, the DFBs can
themselves be user-defined diagnostics blocks offering more extensive diagnostics
options than the blocks outlined above.
In the first instance of logic monitoring of DFBs, two options are available. First, the
values of the DFB's Boolean input pins can be monitored (the REGDFB, UREGDFB and
DEREG functions are available for this purpose). Second, the internal logic can be
monitored using the REGEXT function. However, it is not possible to use type D_*
instances of the diagnostics blocks described above within the DFB.
The REGDFB, UREGDFB and DEREG functions are also used for the creation of user-
defined diagnostics blocks and the blocks' input-pin values are monitored. The example
project contains an example of a user-defined diagnostics DFB in the form of a DFB for
first-fault monitoring. With this DFB, four inputs are monitored in parallel and only the
first pin that detects an incorrect value indicates a fault.

Diagnosing DFB inputs are diagnosed in the same way as type D_* instances of the blocks
DFB Inputs described, i.e., Boolean inputs can be monitored for the value "true" or "false". If the
required value is not pending at the input, the network connected to the input is
analysed and the faulty signals are entered in the buffer along with the fault message.
In order for inputs to be monitored in this way, the REGDFB and DEREG functions must
be invoked in the DFB for each input to be monitored. REGDFB writes the fault to the
buffer and DEREG deletes it. The extended function UREGDFB can be used instead of
REGDFB.

1 In order to be able to diagnose

the input of a DFB, the input
must be enabled for diagnostics.
To do this, highlight the DFB
input under DFB Types in the
Variables Editor and call up the
Properties dialog box.

Continued on next page

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 26

Diagnosing 2 Activate the Diag parameter in
DFB Inputs the Properties dialog box. You
may need to confirm the
subsequent prompt to rebuild
the project.

3 The REGDFB function can now

be called for the input. The
following parameters are made
available:
• AREA is the area number
associated with the fault.
• CLAS is the fault class and
always has the value 62hex.
• SLEN indicates the length of
the status and is currently not ctrl:= true Acknowledgement required
used (value 0). ctrl:= false Automatic acknowledgement

• CTRL is the stat:= 0 Entry in buffer successful

acknowledgement type. stat:= 1 Buffer not configured
stat:= 2 Buffer full
• PIN is the number of the
monitored input.
• VALPIN is the value for which
the input is to be monitored.
• ESTS is the status value and
is currently not used.
• ERID is the fault ID under
which you will find the
diagnosis in the buffer.
• STAT is the feedback signal Note: The function starts at 1 when counting the
for the message entry in the inputs for the PIN parameter, where 1
buffer. corresponds to the first DFB input enabled for
diagnostics (see above). Therefore, only the
inputs to be diagnosed are incremented,
regardless of the number of inputs and the
position in the Data Editor. Example: If pins 2
and 4 of the DFB are to be diagnosed, these are
addressed with pins 1 and 2 in the diagnostics
functions.

Continued on next page

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 27

Diagnosing 4 If the UREGDFB function is
DFB Inputs used instead, the following
additional inputs are available:
• UTXT is a text to be added to
the diagnostics message.
• RSEL indicates the section of
the diagnostics message to be
replaced with UTXT.
The value for the CLAS input
changes to 4Ahex.

rsel:= 0 UTXT is not used

rsel:= 1 Instance comment is replaced
rsel:= 2 Instance name is replaced
rsel:= 3 DFB type is replaced
rsel:= 4 PIN name is replaced
5 You must call the DEREG
function to remove the fault from
the buffer once it has stat:= 0 Deletion in buffer successful
disappeared. The function's only stat:= 1 Buffer not configured
parameter is the fault ID stat:= 2 1 Fault ID incorrect
stat:= 2 2 Fault ID unavailable
supplied by REGDFB or
UREGDFB. A feedback signal is
sent as the result.
6 Note: In principle, any variable
can be used for the status
values of the REGDFB,
UREGDFB and DEREG
functions, although system
words %SW76 and/or %SW77,
which are also recommended for
use in the Unity help, are
designated for this purpose.

7 The basic-framework block

USER_DIAG_ST_MODEL is
available in Unity to ensure that
functions are called correctly
and diagnoses are completed in
the DFB. It is on the basis of this
block that the DFB in the
example project was created.
This is also illustrated in the
flowchart below.

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 28

DFB The flowchart below provides an overview of the calling of the REGDFB/UREGDFB and
Diagnostics DEREG functions within a DFB. It also illustrates how the diagnostics function can be
activated and possible fault scenarios.

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 29

Diagnostics As well as the possibility to monitor the inputs of a block within the DFB, the REGEXT
Within a DFB function can be used to send a diagnostics message. The REGEXT function is used to
transfer all types of fault information to a diagnostics viewer and to register the fault in
the diagnostics buffer. When the fault condition disappears, REGEXT is also responsible
for de-registration. REGEXT can be used to send a fault code, a fault comment and a
descriptive text. However, the function is a system alarm and does not analyse the
upstream network.
Note: The REGEXT function can also be used outside of DFBs.

1 The REGEXT function features

the following inputs and outputs:
• COND is the monitored
condition (an entry is made in
the buffer when "true" and
deleted when "false").
• ECODE is a fault code with
any value displayed instead of
the fault analysis.
• CMNT is the text displayed in
the diagnostics viewer as the
block comment. stat:= 0 Entry in buffer successful
• DESC is the text displayed in stat:= 1 Buffer not configured
the diagnostics viewer as the stat:= 2 Buffer full
block instance.
• LEN is the length in bytes of
the additional information.
• EINF is the additional
information and is displayed
instead of the fault analysis
(max. 96 bytes).
• ERID is the fault ID under
which you will find the
diagnosis in the buffer.
• STAT is the feedback signal
for the message entry in the
buffer.

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 30

 Diagnostics Viewer

Introduction Unity features an integrated diagnostics viewer for displaying diagnostics messages and
messages from the local PLC.

Diagnostics 1 The diagnostics viewer is called

Viewer with
Tools->Diagnostic Viewer.
When the viewer is called, a
connection with the PLC's
diagnostics buffer is established
(as long as Unity is already
connected to the PLC). If a
connection has not previously
been established with the PLC,
the diagnostics viewer will
automatically connect to the
buffer when the connection with
the PLC is established.

2 When the viewer is called, it

appears as a new window with
two sections. The diagnostics
messages and basic information
are listed at the top of the
window and detailed information
for the selected connection
appears at the bottom.

3 Basic information for a

diagnostics message includes
the elements opposite (there is a
separate column in the viewer
for each element). Click with the
right mouse button on each
header to access the dialog box
displayed and select the visible
columns.

Continued on next page

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 31

Diagnostics 4 By way of example, the columns Status Symbol indicating
Viewer and corresponding block message status
references are listed opposite. Acknowledgment Acknowledged/not
acknowledged (op_ctrl)
Message Block comment
Area Area number
Symbol Block instance
Fault Message type: FB/SFC
Appearance date Date/time fault occurred
Disappearance date Date/time fault
disappeared
Acknowledge date Date/time fault was
acknowledged

5 By way of example, detailed

information for an SFC
diagnosis appears opposite.
This is essentially the same as
other diagnoses. The following
information is displayed:

• Basic information
• Transition/block name
• Step/pin name
• Trigger variables
6 The diagnostics viewer also
features a dedicated menu bar
via which the following functions
can be executed:

• Read message again

• Call animation table
• Call search function
• Jump to trigger block
• Acknowledge message
• Configure diagnostics viewer

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 32

 Appendix

Detailed Components List

Type Description Revision/

Version
TSXP575634M Premium CPU; 640 KB INTEGR.ETH
TSXPSY5500M 115/230 V AC/55 W power supply
TSXRKY8EX Expandable backplane 8
TSXTLYEX Terminating resistors A and B
TSXPCX1031 Communication cable multifunctional
UNYXCAUSB033 Communication cable USB

Or
140CPU65160 Quantum CPU; 640KB INTEGR.ETH
140CPS11400 115/230 V 8 A power supply
140XBP00400 Backplane with 4 slots
UNYXCAUSB033 Communication cable USB
110XCA28201 Modbus cable 1 m, RJ45
110XCA203 00 RJ45 adapter on DSUB9

UNYSPUEFUCD20 Unity Pro XL single-user license V2.0.2

Application Diagnostics with Unity_EN - 03-2005 Schneider Electric 33

 Contact

Author Phone E-mail

Schneider Electric GmbH +49 6182 81 2555 cm.systems@de.schneider-electric.com
Customer & Market
System & Architecture
Architecture Definition
Support

Schneider Electric GmbH As standards, specifications and designs

Steinheimer Strasse 117 change from time to time, please ask for
D - 63500 Seligenstadt confirmation of the information given in this
Germany publication.

Application Diagnostics with Unity_EN

34