Application Diagnostics with Unity System User Guide [source code]

Transcription

1 Application Diagnostics with Unity System User Guide [source code]

2 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 Schneider Electric 2

3 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 Using the Example Software 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. Application Diagnostics with Unity_EN Schneider Electric 3

4 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 Schneider Electric 4

5 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 Schneider Electric 5

6 Components Hardware: TSX Premium (PLC) Or TSX Quantum (PLC) Software: Unity Pro (PLC) Application Diagnostics with Unity_EN Schneider Electric 6

7 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 Schneider Electric 7

8 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 P M 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 Power Supply TSX PSY 5500 Application Diagnostics with Unity_EN Schneider Electric 8

9 Quantum PLC 140 CPU 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 Power Supply 140 CPS 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 Schneider Electric 9

10 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 Schneider Electric 10

11 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 P M The UNY XCA USB 033 remote connection 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 140 CPU The UNY XCA USB 033 remote connection 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 and adapter 110 XCA Application Diagnostics with Unity_EN Schneider Electric 11

12 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 Schneider Electric 12

13 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 Schneider Electric 13

14 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 1 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. 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 Schneider Electric 14

15 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"). 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). op_ctrl:= true required op_ctrl:= false acknowledgement Acknowledgement Automatic 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 Schneider Electric 15

16 Information Settings Sequencers 1 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. 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 Schneider Electric 16

17 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 Schneider Electric 17

18 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 Schneider Electric 18

19 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 Schneider Electric 19

20 Locking Diagnostics 1 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. 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 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 Schneider Electric 20

21 Locking/Action Diagnostics 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. 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 Schneider Electric 21

22 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. switch:= true switch:= false I mode M mode Continued on next page Application Diagnostics with Unity_EN Schneider Electric 22

23 Locking/Action /Reaction Diagnostics 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. 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 Schneider Electric 23

24 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 Schneider Electric 24

25 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. 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 Schneider Electric 25

26 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 Schneider Electric 26

27 Diagnosing DFB Inputs 2 Activate the Diag parameter in 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 62 hex. 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. ctrl:= true ctrl:= false stat:= 0 stat:= 1 stat:= 2 Acknowledgement required Automatic acknowledgement Entry in buffer successful Buffer not configured Buffer full 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 Application Diagnostics with Unity_EN Schneider Electric 27

28 Diagnosing DFB Inputs 4 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 4A hex. 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. 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. rsel:= 0 rsel:= 1 rsel:= 2 rsel:= 3 rsel:= 4 stat:= 0 stat:= 1 stat:= 2 1 stat:= 2 2 UTXT is not used Instance comment is replaced Instance name is replaced DFB type is replaced PIN name is replaced Deletion in buffer successful Buffer not configured Fault ID incorrect Fault ID unavailable 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 Schneider Electric 28

29 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 Schneider Electric 29

30 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 Schneider Electric 30

31 Diagnostics Viewer Introduction Unity features an integrated diagnostics viewer for displaying diagnostics messages and messages from the local PLC. Diagnostics Viewer 1 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. 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 Schneider Electric 31

32 Diagnostics Viewer 4 By way of example, the columns and corresponding block references are listed opposite. 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 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 Application Diagnostics with Unity_EN Schneider Electric 32

33 Appendix Detailed Components List Type Description Revision/ Version TSXP575634M TSXPSY5500M TSXRKY8EX TSXTLYEX TSXPCX1031 UNYXCAUSB033 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 Or 140CPU CPS XBP00400 UNYXCAUSB XCA XCA 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 UNYSPUEFUCD20 Unity Pro XL single-user license V2.0.2 Application Diagnostics with Unity_EN Schneider Electric 33

34 Contact Author Phone Schneider Electric GmbH Customer & Market System & Architecture Architecture Definition Support Schneider Electric GmbH Steinheimer Strasse 117 D Seligenstadt Germany Application Diagnostics with Unity_EN As standards, specifications and designs change from time to time, please ask for confirmation of the information given in this publication. 34