Vous êtes sur la page 1sur 34

Application Diagnostics with Unity System User Guide

[source code]

33003586.01

Mar 2006

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 Component 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.doc

Schneider Electric

Abbreviations
Word/Expression PLC HMI PC V AC V DC OPC FB DFB SFC Quantum Premium Unity Pro Explanation Programmable Logic Controller Human Machine Interface Personal Computer Alternating Current Direct Current Process automation interface (OLE for Process Control) Function Block Derived Function Block Sequential Function Chart Is the product name of a Schneider Electric PLC Is the product name of a Schneider Electric PLC 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. The example software contains two Unity projects, one each for the Quantum and Premium PLCs respectively. Please note that the Unity projects are import files, which can be opened by selecting Open from the File menu and the file type *.xef.

Using the Example Software

Application Diagnostics with Unity_EN.doc

Schneider Electric

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.doc

Schneider Electric

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.doc

Schneider Electric

Components

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

Software: Unity Pro 2.0.2 (PLC)

Application Diagnostics with Unity_EN.doc

Schneider Electric

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.doc

Schneider Electric

Hardware
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.

General

Premium PLC

TLX P57 5634M

1 2 3 5 6 8 9 10

Display LEDs Eject button for PCMCIA-SRAM card Terminal port (TER) Slot for a memory expansion card (PCMCIA) Slot for a communication card (PCMCIA) RJ45 connector for Ethernet connection USB port RESET button

Premium Power Supply

TSX PSY 5500

Application Diagnostics with Unity_EN.doc

Schneider Electric

Quantum PLC

140 CPU 651 60

1 2 3 4 5 6 7 8 9 10 11 12 13

Model number, module description, color code Cover (open) LCD (obscured by the cover here) Mode selector Keypad Modbus port USB port Modbus Plus port PCMCIA slot (type II, type III) Ethernet communication indicators Ethernet port Battery Reset button

Quantum Power Supply

140 CPS 114 00

1 2 3 4 5 6

LED panel Model number, module description, color code Field wiring port Cover for field wiring port Removable flap Labeling plate

Application Diagnostics with Unity_EN.doc

Schneider Electric

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.doc

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
TSX P57 5634M

The UNY XCA USB 033 remote connection cable is used for the connection between the PCs 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
140 CPU 651 60

The UNY XCA USB 033 remote connection cable is used for the connection between the PCs 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.doc

Schneider Electric

11

Implementation

Introduction

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

Functional Description

Application diagnostics comprises of three essential elements: the diagnostics logic, the 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.doc

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.doc

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 Diagnostics

In order to be able to run 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 projectspecific and must be repeated for each individual PLC project.

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

The entire project must be rebuilt when diagnostics has been selected.

Application Diagnostics with Unity_EN.doc

Schneider Electric

14

Information Settings Blocks

When a diagnostics block reports a fault, information from the block is written to the buffer. This includes the block instance, block comment and what is known as the area 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 required op_ctrl:= false acknowledgement

Acknowledgement Automatic

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 Settings Sequencers

As in blocks, the same information settings are available for sequencers, although the data entry procedure differs from that for blocks. The instance name and comment are 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.doc

Schneider Electric

15

Information Settings Sequencers

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

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.doc

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 Requirements

Process requirements are signals that are absolutely essential for the operation of a 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.doc

Schneider Electric

17

Signal Groups

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).

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.doc

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 Diagnostics

Locking diagnostics describes the monitoring of the locking condition. If this is met 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.doc

Schneider Electric

19

Locking Diagnostics

Block connection: 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.

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 Diagnostics

Locking/action diagnostics describes the monitoring of locking and action execution. 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.doc

Schneider Electric

20

Locking/Action Diagnostics

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. 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.

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.doc

Schneider Electric

21

Locking/Action /Reaction Diagnostics

Locking/action/reaction diagnostics describes the monitoring of locking, action execution and reaction stability. 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 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 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. 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 switch:= true switch:= false I mode M mode

Application Diagnostics with Unity_EN.doc

Schneider Electric

22

Locking/Action /Reaction Diagnostics

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. 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.doc

Schneider Electric

23

Reaction Diagnostics

Reaction diagnostics describes the monitoring of the stability of a signal following initial 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.doc

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

In order to activate diagnostics, at least one of the two activation times must be entered for the step to be monitored. Doubleclick 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.doc

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 userdefined 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

DFB inputs are diagnosed in the same way as type D_* instances of the blocks 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.doc

Schneider Electric

26

Diagnosing DFB Inputs

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

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 used (value 0). CTRL is the acknowledgement type. 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 for the message entry in the buffer. Note: The function starts at 1 when counting the inputs for the PIN parameter, where 1 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 ctrl:= true ctrl:= false stat:= 0 stat:= 1 stat:= 2 Acknowledgement required Automatic acknowledgement Entry in buffer successful Buffer not configured Buffer full

Application Diagnostics with Unity_EN.doc

Schneider Electric

27

Diagnosing DFB Inputs

If the UREGDFB function is 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:= rsel:= rsel:= rsel:= rsel:= 5 You must call the DEREG function to remove the fault from the buffer once it has disappeared. The function's only parameter is the fault ID supplied by REGDFB or UREGDFB. A feedback signal is sent as the result. 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.

0 1 2 3 4

UTXT is not used Instance comment is replaced Instance name is replaced DFB type is replaced PIN name is replaced

stat:= stat:= stat:= stat:=

0 1 21 22

Deletion in buffer successful Buffer not configured Fault ID incorrect Fault ID unavailable

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.doc

Schneider Electric

28

DFB Diagnostics

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

Application Diagnostics with Unity_EN.doc

Schneider Electric

29

Diagnostics Within a DFB

As well as the possibility to monitor the inputs of a block within the DFB, the REGEXT 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. DESC is the text displayed in the diagnostics viewer as the 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.

stat:= 0 stat:= 1 stat:= 2

Entry in buffer successful Buffer not configured Buffer full

Application Diagnostics with Unity_EN.doc

Schneider Electric

30

Diagnostics Viewer

Introduction

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

Diagnostics Viewer

The diagnostics viewer is called 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.

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. 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.doc

Schneider Electric

31

Diagnostics Viewer

By way of example, the columns and corresponding block references are listed opposite.

Status

Symbol indicating message status 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

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 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.doc

Schneider Electric

32

Appendix

Detailed Component List


Type TSXP575634M TSXPSY5500M TSXRKY8EX TSXTLYEX TSXPCX1031 UNYXCAUSB033 Or 140CPU65160 140CPS11400 140XBP00400 UNYXCAUSB033 110XCA28201 110XCA203 00 UNYSPUEFUCD20 Description Premium CPU; 640 KB INTEGR.ETH 115/230 V AC/55 W power supply Expandable backplane 8 Terminating resistors A and B Communication cable multifunctional Communication cable USB Revision/ Version

Quantum CPU; 640KB INTEGR.ETH 115/230 V 8 A power supply Backplane with 4 slots Communication cable USB Modbus cable 1 m, RJ45 RJ45 adapter on DSUB9 Unity Pro XL single-user license V2.0.2

Application Diagnostics with Unity_EN.doc

Schneider Electric

33

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

Schneider Electric GmbH Steinheimer Strasse 117 D - 63500 Seligenstadt Germany


Application Diagnostics with Unity_EN.doc

As standards, specifications and designs change from time to time, please ask for confirmation of the information given in this publication. 34

Vous aimerez peut-être aussi