for CoDeSys version 2.3 and higher...The contents of this manual 2 Supplement to the system manual ecomat mobile Controller R 360 18/01/2006, for CoDeSys V 2.3 or higher Warranty This

Supplement to the system manual

SafetyController R360

for CoDeSys version 2.3 and higher

The contents of this manual

2

Supplement to the system manual ecomat mobile Controller R 360 18/01/2006, for CoDeSys V 2.3 or higher Warranty This manual was written with the utmost care. However, we cannot assume any guarantee for the contents. Since errors cannot be avoided despite all efforts we appreciate any comment. We reserve the right to make technical alterations to the product which might result in a change of contents of the manual.

3


The contents of this manual.............................................................. 3

1. General....................................................................................... 5 1.1 Safety advice .............................................................................................. 5

1.2 Functions and features.............................................................................. 5

1.3 Test basis for certification......................................................................... 7

2. General information on the safety of machines ..................... 9 2.1 What is safety of machines ....................................................................... 9

2.2 The risk appraisal of a machine................................................................ 9

2.3 The standard EN 954-1 ............................................................................ 10

2.4 Error prevention in control applications.................................................11

2.5 Safety of bus systems ............................................................................. 12

3. Electric connection of the controller..................................... 13

4. Safety concept of the hardware ............................................. 15 4.1 Analog inputs ........................................................................................... 16

Use of analog inputs for digital signals....................................................... 17

4.2 Digital inputs ............................................................................................ 18

4.3 Fast counting and frequency inputs ...................................................... 21 Function description SAFE_ANALOG_OK................................................. 23 Function description SAFE_FREQUENCY_OK ......................................... 25 Function description SAFE_INPUTS_OK .................................................. 27

4.4 Inputs for fail-safe inductive switches ................................................... 29 Function description SAFETY_SWITCH.................................................... 31

4.5 Digital outputs .......................................................................................... 33 Output group %QX0.0 ... %QX0.7 ............................................................. 34 Output group %QX0.8 ... %QX1.7 ............................................................. 35

4.6 PWM and current controlled PWM outputs............................................ 37


4

4.7 System flags for diagnostics .................................................................. 38 Inputs ......................................................................................................... 38 Outputs ...................................................................................................... 38

5. Use of the SafetyController Extended................................... 41

6. CANsafety in safety-related applications.............................. 43 6.1 CANsafety – General information and explanations............................. 43

6.2 Function description CANsafety ............................................................ 48

7. Safety concept of the software .............................................. 55 7.1 Program and system monitoring............................................................ 55

7.2 Error messages........................................................................................ 56

7.3 Program creation and download ............................................................ 57

8. Special conditions and requirements for the use in control category 3 applications ................................................................... 59

9. Annex ....................................................................................... 61 9.1 Implemented functions in the SafetyController .................................... 61

9.2 I/O configuration SafetyController CR7020 ........................................... 63



5

1. General

1.1 Safety advice

Please follow the details of the description. Ignoring the instructions, operation outside the proper use as described below, wrong installation or incorrect handling can result in severe impairment of the safety of people and systems.

These instructions are aimed at persons who can be considered "experts" in the sense of the EMC guideline, the low-voltage guideline, the machine guideline and the safety-relevant special standards listed below. The controllers are to be installed and set up by a skilled person (programmer or service technician)

This description is a supplement to the current system manual ecomat mobile controller family R 360 the knowledge of which is required. It contains text and diagrams on the use of the controller under safety-relevant considerations and has to be read before installation or application.

In the case of malfunctioning or uncertainties please contact the manufacturer. Tampering with the unit might lead to considerable impairment of the safety of persons and systems. It is not permissible and will lead to an exclusion of liability and warranty.

1.2 Functions and features

The freely programmable controllers of the type series “SafetyControllers R 360” are designed for use under severe conditions (e.g. extended temperature range, strong vibration, intensive EMC stress). They are suitable for direct installation in machinery in mobile and robust applications. Due to their specifications the inputs and outputs are specially designed for this application. Integrated hardware and software functions (operating system) offer high protection.

In addition, special hardware and software functions for safety-relevant applications are integrated in the certified controllers allowing the use as safety controllers.

General

6

The SafetyController is approved for safety-relevant tasks in the sense of the protection of persons if the appropriate system test routines are integrated in the operating system and in the application software.

Depending on the use of the hardware or its external wiring (see chapters 3 and 4) and the structure of the user program (see chapter 7) the following safety class can be reached with the certified SafetyController:

to EN 954-1: control category 3

However, the final classification should only be made after a risk analysis of the application. The relevant supervisory bodies have to release the system (hardware and software).

The application software can easily be created by the user with the

programming software CoDeSys (version 2.3 or higher).

All software functions and programming procedures described in this documentation refer to the programming software CoDeSys version 2.3 or higher the knowledge of which is required in this description.

The operating system (*.H86) and the unit libraries (*.LIB) always have to have the same software version. The software status is indicated by suffixed numbers in the file names (e.g. CR7020_Vxxyyzz.H86). The placeholders xx, yy, zz are replaced by numbers from 00 .. 99.

Xx: 00...99 version number

Yy: 00...99 release nnumber

Zz: 00...99 patch number

It also has to be noted that the internal libraries (made in IEC1131), the configuration files (*cfg) and the target files (*.trg) are loaded. The configuration files (*.cfg) and the target files (*trg) are only identified by the version number Vxx. They have to be compatible with the unit libraries and the operating systems.

In general, only certified operating systems can and may be used in safety-relevant applications.

The user himself is responsible for the safe functioning of the application programs that he has created. If required, he has to obtain an approval by a relevant test and supervisory authority in accordance with the national regulations.

7

1.3 Test basis for certification

Testing and certification was carried out on the basis of the following standards and specifications:

DIN EN 954-1/03.97

Safety-related parts of control systems

Part 1: General principles for designs

General

8

9

2. General information on the safety of machines

2.1 What is safety of machines The European directive and the standards define the safety of a machine as its ability to execute its functions without causing any harm. The construction of the machine has to ensure that in the intended use operation, fitting, and maintenance can be carried out without endangering individuals.

2.2 The risk appraisal of a machine The machine directive demands the exclusion of the risk of accidents during the

life of the machine. In general, there is no zero risk in technical equipment, i.e.the residual risks need to be reduced to an acceptable level. The risk of amachine can be considered acceptable if it is borne by the operators.

The standard defines the following elements of risk:

risk without protective measures

risk without safety-related parts of control systems (SPS)

acceptable / justifiable risk

actual residual risk

General information on the safety of machines

10

as well as the probability of occurrence:

frequency and duration of exposure to the hazard

probability of occurrence of a hazardous event

possibility of avoiding or limiting the harm

Apart from the probability of occurrence the anticipated severity of the harmneeds to be taken into account.

Thus the risk is defined by the severity of the possible harm and the probability of occurrence of possible harm

2.3 The standard EN 954-1

Risk estimation The standard EN 954 is based on the guidelines for risk assessment. It isindependent of the application and the technology in use (controller, hydraulics,etc.). A machine might have different safety requirements depending on itsfunction and operating mode.

The risk assessment is an important step on the way to a safe machine.Potential hazards no matter what kind need to be identified before the firstdesign step is made or the first line of the application software is programmed.

Design as well as technical protection equipment have to ensure a minimisationof risk.

As soon as the machine controller is assigned safety tasks the EN 954-1 isbecoming much more important. Part of the EN 954-1 is a simplified riskassessment (on the basis of EN 1050). Furthermore, the 5 categories (B, 1, 2,3, 4) provide information on the ability of the machine controller to withstandfaults.

Application of the risk graph

What happens when the guard fails?

Assess the risk by means of the risk graph,

define the required category,

select the correct components and their connection.

Part of the inputs and outputs of the R360 SafetyController are approved for applications up to control category 3 to EN 954-1. Provided that the inputs and outputs are connected as follows and are evaluated by the application program.

11

The risk graph (to EN954)

Legend S Severity of injury S1 - Slight injury S2 - Serious irreversible injury to one or several persons or death F Frequency and time of exposure to the hazard F1 - Rarely to often and/or a short duration F2 - Frequent to continuous and/or a long duration P Possibility of avoiding hazards P1 - Possible under specific conditions P2 - Scarcely possible

Preferred category • Additional measures required

Over-dimensioned category

2.4 Error prevention in control applications

The figure below shows examples for error prevention measures for categoriesB to 4. Applications of category 3 require all measures except those fromcategory 4.

General information on the safety of machines

12

2.5 Safety of bus systems In addition to the measures described above for the structure of safe machine

controllers, additional errors have to be detected and mastered regarding thetransmission of "safe data" via a bus. In the development of the protocol supplement CANsafety the measuresdescribed below were taken into consideration and integrated into the protocol. The result is a protocol that can be used in applications up to control category 4.

In conjunction with the SafetyController, CANsafety can be used in applications up to category 3.

Subsequent Number Time Stamp Expected

Time EchoLabel for

Transmitter and Receiver

Message Label Data Back-up Encryption

Techniques

Repetition X X

Loss X

Insertion X X X X

Wrong Sequence X X

Distorted Data X X

Delay X X

Masking X X X

Error

Measure per Message

13

3. Electric connection of the controller On principle, all supply and signal lines of safety controllers have to be laid separately, and the ground lines of the controller (GNDS, GNDO, GNDA) and the ground lines of the actuators in particular have to be connected with a common star point.

Linking the terminals in the connector or connecting supply and ground lines of the controller modules and the sensors and actuators to different star points is not permitted.

permitted

not permitted

Electric connection of the controller

14

15

4. Safety concept of the hardware

The following chapters describe the safety concept of the hardware and its use in safety-relevant applications. Certified SafetyControllers can be used in applications up to control category 3 if the inputs and outputs are selected and wired accordingly.

Possible configurations of the individual inputs and outputs are described in the system manual ecomat mobile Controller R360.

Their knowledge is required for the description below.

Differences and peculiarities concerning the controllers SafetyController are described in the documentation below. The available input/output configurations are described in the annex or in the unit documentation.

The following example shows the configuration of two inputs and one output in the SafetyController.

Programm example

Safety concept of the hardware

16

4.1 Analog inputs

Only if the monitoring functions of the operating systems are activated for the analog inputs can they be used for applications up to control category SK3. For this purpose the operating mode (mode byte) of the input in questions has to be set to IN_SAFETY. This activates the automatic monitoring and testing of the analog/digital converter.

If an error is detected during this internal test the corresponding bit in error flag ERROR_I0 and the error flags ERROR_ANALOG and ERROR_IO are set.

Errors in the wiring (short circuit, wire break) or in the sensor are not detected in these checks.

Therefore analog input signals also have to be connected to the controller via separate connection cables and processed redundantly.

Example connection:

Furthermore, it makes sense to evaluate the signal voltage only in a limited range (e.g. 1 ... 9 V). This way the errors short circuit to ground or wire break and short to supply voltage /short circuit can be detected.

In the following example for the redundant use of input signals, the function SAFE_ANALOG_OK (library ifm_SafetyIO_Vxxxxxx) compares the two analog values SAFE_A_IN_1a and SAFE_A_IN_1b. If the difference is smaller than or equal to the value of ACCEPT_TOLERANCE the two analog values are considered equal and can be further processed.

17

Program example

Use of analog inputs for digital signals The analog inputs can also be used for evaluating digital signals. To do so, the selected input needs to be set to operating mode (mode byte) IN_DIGITAL_H:

The diagnosis via an additional fixed current limitation for mechanical switches or the diagnosis of sensors to NAMUR is not supported by the SafetyControllers.

If safe digital input signals are evaluated via the analogue inputs (mode byteIN_SAFETY set), these signals must only be static signals (e.g. mechanicalswitches). For the evaluation of frequency signals (e.g. pulse pick-ups) the safefrequency inputs (%IX0.12 ... %IX0.15 and %IX1.4 ... %IX1.7) must be used.


18

4.2 Digital inputs

Only if the monitoring functions of the operating systems are activated for the digital inputs may they be used for applications up to control category SK3. For this purpose the operating mode (mode byte) of the input in questions has to be set to IN_SAFETY. This activates the automatic monitoring and testing of the digital input.

If an error is detected during this internal test the corresponding bit (only for safety inputs) in error flag ERROR_I1 or ERROR_I2 and ERROR_IO are set.

Errors in the wiring (short circuit, wire break) or in the sensor are not detected by means of these tests since the switching states 0 (no voltage present) and 1 (voltage present) are permissible for the processing of digital signals (e.g. mechanical switches).

For this reason the input signals need to be redundant, i.e. connected to thecontroller via separate connection cables and processed by the user software.Additionally, the inputs need to be located in different input groups. The use of thediagnostic function does not release the user from this signal processing.

For safety-critical signals only inputs without parallel outputs should preferably beused. For the redundant processing the input channels of the second input group(group of four) must be used.

The function block SAFE_INPUTS_OK (library ifm_SafetyIO_Vxxxxxx) is available for monitoring two-channel safety systems (e.g. E-stop). If this safety system is not used regularly, it must be checked manually at defined intervals. This ensures that an error e.g. in the wiring or in the switch does not go undetected.

If more than 8 safety-related inputs are required in the application, the redundant processing can also be carried out via inputs %IX1.8 to %IX1.15. In each case a safety-related channel (%IX012 ... %IX0.15 und %IX1.4 ... %IX1.7) must then be used for the first input. The redundant processing must by no means be carried out with only the input channels %IX1.8 to %IX1.15.

The diagnosis via an additional fixed current limitation for mechanical switches or the diagnosis of sensors to NAMUR is not supported by the SafetyControllers.

19

Connection of E-stop switches On principle, E-stop switches can be connected to the SafetyController and canbe processed directly via the controller. Please ensure a two-channelconnection. Switching off must be effected via the safety-related outputs.

The approved function block SAFE_INPUTS_OK (library ifm_SafetyIO_Vxxxxxx) must be used for monitoring the positively driven contacts. If this e-stop system is not used regularly, it must be checked manually at defined intervals. This ensures that an error e.g. in the wiring or in the switch does not go undetected.

Program example

Plausibility check via the process

If the application allows, sufficient failure safety can be achieved by selectingsuitable signal transmitters (mechanical or electronic), by appropriateinstallation and plausibility checks of certain parts of the plant which makes theinstallation of two equal signal transmitters in one installation position obsolete.


20

Connection example

21

4.3 Fast counting and frequency inputs

Only if the functions FREQUENCY and PERIOD are used for the fast inputs and if the measured frequencies are compared via the function block SAFE_FREQUENCY_OK may they be used for applications up to control category SK3.

Fast counter, pulse or interrupt inputs (%IX0.12 ...%IX0.15 and %IX1.4 ... %IX1.7) are a special form of digital inputs. Errors in the wiring (short circuit, wire break) or in the sensor are not detected by means of these tests since the switching states 0 (no voltage present) and 1 (voltage present) are permissible for the processing of digital signals.

For this reason the input signals need to be redundant, connected to the controller via separate connection cables and processed by the user software.

Additionally, the inputs need to be located in different input groups. The use of the diagnostic function does not release the user from this signal processing.

Measuring methods for fast pulses

In the case of safety-relevant frequency measurements the signal frequency also has to be determined in two different ways in addition to the external wiring. Depending on the selected software functions (see library: CR7xxx_Vx.LIB) different hardware parts are used in the SafetyController. The software function FREQUENCY determines the frequency on the basis of the internal hardware counter, the function PERIOD on the basis of the internal timer. The result of these different measurement methods then has to be checked via the user program.

Connection example


22

Program example

In the example above the function SAFE_FREQUENCY_OK (library ifm_SafetyIO_Vx) compares the two frequency values SAFE_frequency and REF_frequency. If the difference is smaller than or equal to the value of ACCEPT_TOLERANCE the two frequency values are considered equal and can be further processed.

Use

It has to be observed that due to the different measurement methods, errors in the frequency determination might occur.

The function FREQUENCY is therefore suited for frequencies between 100 Hz and 50 kHz with the error decreasing at higher frequencies.

The function PERIOD carries out a period measurement. Therefore it is suitable for frequencies lower than 1000 kHz. In general, higher frequencies can also be measured. However, this means a considerable load on the cycle time. This needs to be taken into consideration when designing the user software.

Safety consideration

For safety considerations errors in the reference measurement of up to 25% can be tolerated, as the reference value is only used to check the function of the measuring channel. The frequency value for the application must be derived from the "precise" measurement.

Use as digital inputs

It also has to be observed that due to the permissible high input frequencies error signals (e.g. bouncing contacts of mechanical switches) are also detected. This has to be suppressed via the user software, if required.

23

Function description SAFE_ANALOG_OK Function SAFE_ANALOG_OK

Library

ifm_SafetyIO_Vx.LIB

Function symbol

Target Monitoring safety-related analog input signals

Parameters Function inputs

Name Data Type Description

SAFE_ANALOG_IN1 DWORD Safety-related analog value 1

SAFE_ANALOG_IN2 DWORD Safety-related analog value 2 (reference value)

ACCEPT_TOLERANCE BYTE Permissible deviation analog value 1 to analog value 2 in percent Value range 0 ... 100 %

ANALOG_MIN WORD Bottom limit of the analog input value (e.g. wire break detection)

ANALOG_MAX WORD Upper limit of the analog input value (e.g. detection of short against supply voltage)

Function outputs


ANALOG_INPUTS_OK BOOL TRUE: Deviation of the analog values lower than ACCEPT_TOLERANCE

FALSE: Deviation of the analog values higher than ACCEPT_TOLERANCE


24

ERROR_INPUTS BOOL TRUE: Analog values outside the permissible limits or deviation of the analog values higher than ACCEPT_TOLERANCE

FALSE: Analog values within the permissible limits.

Description The function SAFE_ANALOG_OK monitors an analog input signal (SAFE_ANALOG_IN1) and the corresponding reference signal (SAFE_ANALOG_IN2). If the deviation in percent of the analog input signals is smaller than or equal to the limits indicated under ACCEPT_TOLERANCE the values are valid and function output ANALOG_INPUTS_OK is set. If the deviation in percent is higher than ACCEPT_TOLERANCE, ANALOG_INPUTS_OK is set to FALSE and ERROR_INPUTS is set to TRUE.

In addition, both analog signals are monitored with regard to not reaching or exceeding a limit value (ANALOG_MIN or ANALOG_MAX). Thus, e.g. wire break or short against supply voltage can be detected. If the limits are not reached or exceeded output ERROR_INPUTS is set to TRUE.

The safe output signal ANALOG_INPUTS_OK can then be further processed in the application.

If the deviation in percent of the analog input signals is within the permissible limit value ACCEPT_TOLERANCE, but the limit values ANALOG_MIN or ANALOG_MAX are not reached or exceeded, only output ERROR_INPUTS is set.

25

Function description SAFE_FREQUENCY_OK Function SAFE_FREQUENCY_OK

Library

ifm_SafetyIO_Vx.LIB

Function symbol

Target Monitoring safety-related frequency signals



SAFE_FREQUENCY_IN1 REAL Safety-related frequency value 1

SAFE_FREQUENCY_IN2 REAL Safety-related frequency value 2 (reference value)

ACCEPT_TOLERANCE BYTE Permissible deviation frequency value 1 to frequency value 2 in percent Value range 0 ... 100 %

Function outputs


FREQUENCY_INPUTS_OK BOOL TRUE: Deviation of frequency values lower than ACCEPT_TOLERANCE

FALSE: Deviation of frequency values higher than ACCEPT_TOLERANCE

ERROR_INPUTS BOOL TRUE: Deviation of frequency values higher than ACCEPT_TOLERANCE

FALSE: Deviation of frequency values lower than ACCEPT_TOLERANCE


26

Description The function SAFE_FREQUENCY_OK monitors a frequency input signal (SAFE_FREQUENCY_IN1) and the corresponding reference signal (SAFE_FREQUENCY_IN2). If the deviation in percent of the input signals is smaller than or equal to the limits indicated under ACCEPT_TOLERANCE the values are valid and function output FREQUENCY_INPUTS_OK is set. If the deviation in percent is higher than ACCEPT_TOLERANCE, FREQUENCY_INPUTS_OK is set to FALSE and ERROR_INPUTS is set to TRUE.

The safe output signal FREQUENCY_INPUTS_OK can then be further processed in the application.

27

Function description SAFE_INPUTS_OK Function SAFE_INPUTS_OK

Library

ifm_SafetyIO_Vx.LIB

Function symbol

Target Monitoring digital, safety-related input signals



SAFE_DIGITAL_IN1 BOOL Safety-related input signal 1

SAFE_DIGITAL_IN2 BOOL Safety-related input signal 2

SYNCHRONOUS_TIME TIME Max. permissible delay time between the two input signals

Function outputs


DIGITAL_INPUTS_OK BOOL TRUE: Safety request via DIGITAL_IN1 and DIGITAL_IN2

FALSE: No input signal or error due to timeout

ERROR_INPUTS BOOL TRUE: Timeout during safety request or cancellation of safety request

FALSE: no error


28

Description The function SAFE_INPUTS_OK monitors two digital input signals (DIGITAL_IN1 and DIGITAL_IN2). Only when both signals are safely applied during the time stated in SYNCHRONOUS_TIME is function output DIGITAL_INPUTS_OK set. If the time elapses without the two signals being applied safely DIGITAL_INPUTS_OK is not set, but ERROR_INPUTS is set.

If, after output DIGITAL_INPUTS_OK has been set, only one input signal drops (e.g. due to contact bouncing or wire break) the error output is also set after the time of SYNCHRONOUS_TIME has elapsed and DIGITAL_INPUTS_OK is reset immediately.

Only if both outputs are reset within SYNCHRONOUS_TIME is the error output not set.

The function SAFE_INPUTS_OK monitors switching signals of positively-driven contacts in e-stop switches or the synchronous switching of two-hand operations. By inverting the input signals complementary contact pairs can also be processed.

If the e-stop device or the two-hand operation are not used regularly, they have to be tested manually at fixed intervals. This ensures that an error e.g. in the wiring or in the switch does not go undetected.

Max. permissible delay times for typical two-channel input signals:

e-stop device max. 100 ms

two-hand-operation (to SK3) max. 500 ms

29

4.4 Inputs for fail-safe inductive switches

The R360 SafetyController can trigger and processed up to 4 safety chains each of which can consist of max. 9 fail-safe inductive switches in series (4 x 9) (for the Extended SafetyController up to 8 x 9 switches). No further evaluation electronics is required. The generation of the necessary test signal and the processing of the sensor output signals are handled directly via the SafetyController.

Please note the following points:

At present, only the following units are supported: cylindrical, M18, type GIGA Order no. GG505S cylindrical, M30, type GIIA Order no. GI505S rectangular, type GIMC Order no. GM504S rectangular, type GIMC Order no. GM505S All units have to be supplied with 24 V DC. A use of the fail-safe switches in 12 V DC on-board supply systems is not possible.

Operating principle

The fail-safe switches are supplied with a supply voltage of 24 V DC. In addition the switches have to get a clock signal from the controller. By means of the clock signal wiring errors (wire break, short circuit and cross fault) and a simple defeating of the switch (e.g. by linking clock signal and controller input) are detected. The switch monitors and evaluates the clock signal generated in the controller. In addition, the switch monitors the supply voltage and the correct position of the damping element.

If the switch detects no error, the clock signal is provided as an input signal to the SafetyController with a delay of approx. 1.5 ms (time td). The skew and the correct signal form are monitored and evaluated by the controller.

In the case of no error the output of the software function is released and can be further processed as a digital input signal.


30

Typical response times of the SafetyController: (without response time of the sensor) T 250 ms + 2 * cycle time T1 200 ms + cycle time T2 50 ms + cycle time Td approx. 1.5 ms Response time to safety request (SWITCH_ON = FALSE) max. 50 ms + cycle time (typ. cycle time) Response time to rising edge of the sensor signal (sensor damped) max. 250 ms + 2 * cycle time (typ. cycle time) (For further technical data please see the unit description of the sensor in use)

Permissible inputs/outputs for the connection of fail-safe inductive switches

Cycle outputs: CR7020 / CR7200 Q23/%QX0.7 oder alternativ Q47/%QX1.7 CR7505 Q23/%QX0.7 Signal inputs for fail-safe inductive switches: All controllers I24/%IX1.4, I25/%IX1.5, I26/%IX1.6, I27/%IX1.7 (Max. 4 independent safety chains with max. 9 fail-safe switches each in series can be evaluated simultaneously).

Example connection of 2 safety chains with a total of 3 fail-safe inductive sensors

31

Function description SAFETY_SWITCH Function SAFETY_SWITCH

Library

ifm_CR7xxx_Vx.LIB Only ifm_CR7505_Vx.LIB

Function symbol

Target Evaluation of fail-safe inductive switches



ENABLE BOOL TRUE: function processing FALSE: function not processing

INIT BOOL TRUE: function is initialised

FALSE: in cyclical program run

INPUT_CHANNEL BYTE Input channel for evaluating the fail-safe switch 0: I24 / %IX1.4 1: I25 / %IX1.5 2: I26 / %IX1.6 3: I27 / %IX1.7

ENABLE_CLOCK_Q23 BOOL Clock signal is generated via output Q23/ %QX0.7.

ENABLE_CLOCK_Q47 BOOL Clock signal is generated via output Q47/ %QX1.7 (not for CR7505).

Function outputs


SWITCH_ON BOOL TRUE: Fail-safe inductive switch is damped and generates a safe input signal. FALSE: Sensor is undamped

ERROR BOOL TRUE: Sensor signal faulty or sensor manipulated FALSE: No faulty sensor signal


32

Description The function SAFETY_SWITCH has to be integrated once for each connected sensor and has to be initialised once for one cycle at the program start. The configuration of the function (selected input channel and cycle output) is stored during initialisation and is fixed. During the program run the configuration of the function block cannot be changed.

The function can be deactivated via the ENABLE input.

Only when the SafetyController reads the generated clock signal with the correct signal form and the correct time flow at the configured input is function output SWITCH_ON set to TRUE when the sensor is damped.

The safe output signal SWITCH_ON can then be further processed in the application.

In the case of an error the ERROR output is set to TRUE and the output SWITCH_ON is set to FALSE simultaneously. Output SWITCH_ON is set again when the cause of the error has been eliminated and the fail-safe switch has been undamped once.

Program example

33

4.5 Digital outputs

Only the outputs marked "safe" may be used for applications up to control category SK3 since they have all the diagnostic and monitoring functions (short circuit, wire break and cross fault) described below.

The monitoring functions of the operating system that can be activated by the user software have to be used. In the user software error messages and feedbacks have to be evaluated and corresponding action has to be taken.

If an error is detected during this testing, the corresponding bits in the error bytes ERROR_BREAK_..., ERROR_SHORT_..., or – depending on the output configuration - ERROR_OUTPUTBLANKING and the error flag ERROR_IO are set.

In order to activate all monitoring functions the bit OUT_SAFETY in the mode byte of the output in question is to be set.

Switching off the outputs in case of a fault is one of the most important features of machine controllers. The switched-off (de-energized) output is considered the safe state.

The constant monitoring of the connected actuators for wire break, short to the supply voltage or ground or cross fault is therefore absolutely necessary.

For the above-mentioned faults the SafetyController provides outputs with diagnostic capability which are in parts automatically checked by the operating system. Also, they must be evaluated by the user in the application software.

The response of a safety function first results in the switching off of the outputs. The logic state generated by the user program remains unchanged.

To set the outputs again after the peripheral fault (e.g. wire break) has been remedied, the outputs first have to be logically reset in the user program. If necessary, they can then be set again.

For this reason the error flags have to be evaluated and reset via the user program.


34

Depending on the output group, the output channels are internally set differently:

Output group %QX0.0 ... %QX0.7

Structure of the output channels %QX0.0 ... %QX0.7

Wire break detection

Wire-break detection is effected via the readback channel. When the output is switched, wire break is detected when no current flows over resistor Ri (no voltage drops). Without the wire break the load current flows through the series resistor Ri and causes a voltage drop which is evaluated via the readback channel.

The error bit in the system flag byte ERROR_BREAK.... for the corresponding output is only set in the state Output ON.

Short-circuit detection

Short-circuit detection is effected via the readback channel. When the output is switched a short circuit to GND is detected when the supply voltage drops over the series resistor.

The error bit in the system flag byte ERROR_SHORT... for the corresponding output is only set in the state Output ON.

Monitoring for cross fault

Depending on the result of the risk analysis of the application the outputs must be additionally tested for cross fault and short to the supply voltage. To do so, a short switch-off pulse (approx. 200 µs) is automatically applied to the monitored outputs (readback outputs) one after the other by the operating system of the controller. It is read back and evaluated by the integrated diagnostic channels. This test is cyclically carried out (approx. every 30 s) during the whole controller test and monitoring.

This test detects the cross fault in the safety-related outputs %QX0.4 ... %QX0.7 when the output is active.

35

A fault detected in the test is indicated by the error bit ERROR_OUTPUTBLANKING. By means of a more extensive diagnosis (see above) the exact fault can be located.

For safety relevant applications it is only allowed to use the outputs

%QX0.4, %QX0.5, %QX0.6, %QX0.7

In order to activate the testing the bit OUT_SAFETY in the mode byte of the output in question is to be set.

Output group %QX0.8 ... %QX1.7

Structure of the output channels %QX0.8 ... %QX1.7

Wire-break detection

Wire-break detection is effected via the readback channel. When the output is blocked wire break is detected when the resistor Ri pulls the readback channel to HIGH potential (VBB). Without the wire break the low-resistance load (RL < 10 kΩ) would force LOW (logic 0).

The error bit in the system flag byte ERROR_BREAK.... for the corresponding output is only set in the state Output OFF.


36

Short-circuit detection

Short-circuit detection is effected via the readback channel. When the output is switched a short circuit to GND is detected when the readback channel is pulled to LOW potential (GND).

The error bit in the system flag byte ERROR_SHORT... for the corresponding output is only set in the state Output ON.

Monitoring for cross fault

Depending on the result of the risk analysis of the application the outputs must be additionally tested for cross fault, short to the supply voltage and wire break in the switched state. To do so, a short switch-off pulse (approx. 200 µs) is automatically applied to the monitored outputs (readback outputs) one after the other by the operating system of the controller. It is read back and evaluated by the integrated diagnostic channels. This test is cyclically carried out (approx. every 30 s) during the whole controller test and monitoring.

This test detects the cross fault in the safety-related outputs (%QX1.0 ... %QX1.7 when the output is active.

A fault detected by the test is indicated by the error bit ERROR_OUTPUTBLANKING. By means of a more extensive diagnosis (see above) the exact fault can be located.

For safety relevant applications it is only allowed to use the outputs

%QX1.0, %QX1.1, %QX1.2, %QX1.3, %QX1.4, %QX1.5, %QX1.6, %QX1.7.

For the outputs %QX1.2, %QX1.3, %QX1.5, %QX1.6 in configuration LowSide only limited diagnostic possibilities (no short-circuit detection) are available. Therefore this configuration is not suitable for safety applications.

In order to activate the testing the bit OUT_SAFETY in the mode byte of the output in question is to be set.

37

4.6 PWM and current controlled PWM outputs

No internal test

Due to the function principle, system internal monitoring and testing for these outputs are not provided. If these outputs are used for safety-related applications (only applies to Q20/%QX0.4 ... Q24/%QX0.7), the plausibility of the signals has to be monitored through the application and the user program. The current can, for example, be read via the software function OUTPUT_CURRENT when using the PWM function.

When using the current-regulated PWM outputs it has to be ensured that the output is only triggered within permissible limits. The plausibility can be monitored e.g. with additional sensors.

If an output is used as PWM or current-controlled PWM output the cross fault detection of the output in question must not be activated (MODE byte OUT_SAFETY not set).

Example program


38

4.7 System flags for diagnostics

Inputs flag byte input addresses configured as Analog inputs ERROR_I0 %IW3 ... %IW10 safety

ERROR_ANALOG %IW3 / %IX0.0 ... %IW10 / %IX0.7

safety

flag byte input addresses configured as Digital inputs ERROR_I1 %IX0.12 ... %IX0.15 safety

ERROR_I2 %IX1.4 ... %IX1.7 safety

If one of the above errors is detected at a safe input, all (!) outputs and the safetyrelay are switched off immediately. In addition, the LED at the controller modulegoes into the state red/flashing (error) and the error bits ERROR and ERROR_IOare set.

Outputs flag byte output addresses configured as Wire break

flag bytes ERROR_BREAK_Q1Q2 %QX0.0 ... %QX0.3 non safety ERROR_BREAK_Q1Q2 %QX0.4 ... %QX0.7 safety ERROR_BREAK_Q3 %QX0.8 ... %QX0.15 non safety ERROR_BREAK_Q4 %QX1.0 ... %QX1.7 safety

flag byte output addresses configured as Short Circuit flag bytes ERROR_SHORT_Q1Q2 %QX0.0 ... %QX0.3 non safety ERROR_SHORT_Q1Q2 %QX0.4 ... %QX0.7 safety ERROR_SHORT_Q3 %QX0.8 ... %QX0.15 non safety ERROR_SHORT_Q4 %QX1.0 ... %QX1.7 safety

flag byte output addresses configured as Q20_MODE ... Q23_MODE %QX0.4 ... %QX0.7 safety

Activation cross fault monitoring

Q40_MODE ... Q47_MODE %QX1.0 ... %QX1.7 satety

Cross fault detection can be configured for all outputs (bit OUT_SAFETY set). However, it is only evaluated for the outputs marked "safe", so it can only be of use for those outputs.

If one of the above errors is detected at a safe output, all (!) outputs and the safety relay are switched off immediately. In addition, the LED at the controller module goes into the state red/flashing (error) and the error bits ERROR, ERROR_IO and, if required, ERROR_OUTPUTBLANKING are set.

39

Input test (pin 24) or function SET_DEBUG activ

If outputs are defined as safety relevant (MODE-Byte OUT_Safety set) they cannot be used when the test input is active. The test input has to be set when e.g. the software is to be loaded into the controller.

The outputs are only available again when the test is deactivated and the controller has been reset (switching off and on).

To still allow software monitoring (no program download) with the programming system CoDeSys the function SET_DEBUG is available.

In the running application (normal operation) neither the test input nor the function SET_DEBUG must be set.

Applications to control category 2 (and higher) require a second switch-off way if the dangerous failure is not signalled in time (warning message, alarm, display etc.). For this purpose the SafetyController has an additional relay. Only the outputs which are switched off via the safety relay and provide full diagnostic capability are identified in the configuration diagrams by the designation "safe outputs" and the reference to the relay contact.

The analysis of the safety system has to show if an output working as a safety-relevant switch-off way has to be redundant or if monitoring and testing as described above are sufficient. Furthermore, the analysis has to check if in the case of an error switching off via the internal relay is sufficient or if a second output (electrical or hydraulic) needs to be used for redundant switching off. If e.g. a cable loom to an external valve has no supply cable or if a short to GND is harmless from a safety point of view, switching off the output via the internal relay is sufficient in the case of an error.

Program example


40

41

5. Use of the SafetyController Extended The ExtendedController can be operated in two different ways. In the Master/Master or Master/Slave operating mode.

Only in the mode master/master can the SafetyController Extended be used a controller for safety relevant applications. In this mode two separate applications are loaded into the two sections of the controller. These work completely independently and asynchronously of each other (not to be confused with CANopen Master). The inputs and outputs are addressed with the same system variables and system functions in both controller sections. If desired, the built-in interface can be used for exchanging non safety relevant data between the two sections. This is implemented with an integration of the functions SSC_TRANSMIT and SSC_RECEIVE (see functional descriptions in the system manual section “Data access and verification”) in the application programs.

Use of the SafetyController Extended

42

43

6. CANsafety in safety-related applications

6.1 CANsafety – General information and explanations

A work group of the user organisation "Can in Automation" (CiA) prepared anexpansion of the CANopen communication profile (Framework DS 304). Thisallows the exchange of safe data between bus nodes on the same bus line inparallel with the "normal" communication between CANbus nodes (e.g. I/Omodules and a controller).

This communication is possible when the bus nodes generating and reading thesesafety-related data support the corresponding CAN mechanisms and have ahardware design in accordance with the control category in question.

As in the designing of a safety controller and the implemented application softwarethe integrity of data has to be ensured in a "safe bus system". If a communicationerror occurs reaction has to follow within a sufficiently short time and the machinehas to be brought into a safe state.

At the same time it has to be ensured that the implemented safety functions do notinterfere with the "normal" communication of the not safety-related bus nodes.

CANopen for safety-oriented communication

The complete "safe" communication is based on the standard CAN mechanismsand is integrated in the CANopen communication profiles. This allows thesimultaneous exchange of "simple" data on one bus line between non-safe nodes,but also between non-safe and safe nodes.

The services, protocol mechanisms, and functions described below are an addition to the CANopen application and communication profile. These CAN mechanisms guarantee only the safe exchange of data between safety-related nodes. The safe processing of the data in the application software is the responsibility of the programmer.

CANsafety in safety-related applications

44

Safe communication

SRDO – Safety-relevant data object

The "safe data" are exchanged via the SRDOs. An SRDO always consists of twoCAN messages with different identifiers. Message 1 contains the original user data,message 2 the same data, but inverted bit by bit. The operating system reads andcompares the data. If they were transmitted without an error, the original data areavailable to the application and they can be further processed.

Apart from the distortion of the data during transmission the cyclical refresh (SCT)of the SRDO and the correct time (SVRT) between the redundant message 2 andthe original message are monitored.

The identifier structure of CANopen limits the number of SRDO which can be sentin a network of safety-related nodes (producer) to 64 (normally 32 receiving and 32transmitting identifiers) The number of nodes which can receive these data(consumer) is only limited by the network structure and the general CANopenmechanisms.

SCT - Safeguard cycle time

To check the correct function of the periodical transmission of the SRDO the datarefresh is monitored via the SCT mechanism. Only if the data were repeated withinthe set time are they valid. Otherwise the receiving controller signals an error andgoes into the safe state (outputs switched off).

45

SRVT - Safety-relevant object validation time

A second mechanism (SRVT) ensures that the time between the two SRDOmessages is adhered to. Only if the redundant message 2 was transmitted withinthe set time is the message valid. Otherwise the receiving controller signals anerror and goes into the safe state (outputs switched off).

GFC – Global failsafe command

In order to increase the response time of the complete CANopen network it ispossible to send the "Global failsafe command". The message is event-driven andnot "safe". This means that it is only sent once by the producer. The GFC is thesame for all network nodes (same identifier) and does not contain any data. TheGFC can e.g. be used to send a pre-alarm to all safety-related nodes in thenetwork.

Since the GFC cannot be transmitted safely it must not be included in thecalculation of the occurrence time of the first fault.

Processing of the SRDO in the SafetyController and connection of the CAN interfaces

In order to safely process the SRDO data in the R360 SafetyController they have tobe read via the two CAN interfaces. The differences in the hardware and softwareinterfaces ensure that the transmitted data can be transferred to the subsequentapplication process without any error and can be further processed.

In a CAN bus system in which also safety-related data are to be transmitted thebus line is connected with the two CAN interfaces. By using the library functionsCAN_SAFETY_TRANSMIT and CAN_SAFETY_RECEIVE the data are read viaboth interfaces and tested in accordance with the "CANopen framework for safety-relevant communication" DS 304 and transferred to the application software.

Further additional protocols (e.g. CAN layer 2 or CANopen via CAN interface 1) aretransmitted to CANsafety "in parallel" and processed.

In combination with CANsafety the CAN interface 1 must be used for theCAN layer 2. A protocol using the 29 bit identifier (e.g. the protocol SAE J 1939 on CANinterface 2) cannot be used in conjunction with CANsafety.


46

Structure of the software interface

As the SafetyController is a programmable unit and due to the internal structure ofthe implemented different CANopen interfaces no object directory (OD) wasimplemented for the exchange of CANsafety parameters. All settings, networkcommands and the data transmission are handled via the two function blocksCAN_SAFETY_TRANSMIT and CAN_SAFETY_RECEIVE. This means that anexternal configuration tool e.g. a CANopen master cannot set the parameters viaSDO.

Predefined identifier for CANsafety

Normally, predefined identifiers (pre-defined connection set) are used in CANopennetworks. For CANsafety, too, an identifier range has been defined. It is integratedin the CANopen "pre-defined connection set".

It is strongly recommended to only use identifiers from the "pre-defined connection set". Otherwise the overview of the network is lost.

However, the application programmer has to validate in each case that the CAN messages are free of conflict.

As described above, an SRDO always consists of two messages. Message 1contains the regular data and an identifier with an odd value. Message 2 containsthe inverted data and an identifier with an even value. This structure is compulsoryand has to be adhered to.

The "pre-defined connection set" assumes that each safety-related node sends atransmit and a receive message. The SafetyController supports max. eight TX-SRDO and max. eight RX-SRDO from the following identifier range.

47

CAN identifiers Object Normal Data Inverted Data

257dez 101hex 258dez 102hex



: : : :

SRDO – TX SafetyController 1 SRDO – RX SafetyController 2

319dez 13Fhex 320dez 140hex




: : : :

SRDO – RX SafetyController 1 SRDO – TX SafetyController 2

383dez 17Fhex 384dez 180hex

Example:

Identifier combination 257dez and 258dez is e.g. used as transmitting SRDO andidentifier combination 321dez and 322dez is e.g. used as receiving SRDO. In asecond SafetyController identifier combination 257dez and 258dez then has to beused as receiving SRDO and identifier combination 321dez and 322dez astransmitting SRDO.


48

6.2 Function description CANsafety

Function CAN_SAFETY_TRANSMIT

Library

CR7xxx_Vx.LIB

Function symbol

Target Transmits a safe CAN message (SRDO – TX)



NUMBER BYTE Number of the SRDO.

A value range of 0...7 is permissible.

CONFIG BOOL TRUE: Configuration is written

(Condition OPERATIONAL = FALSE)

ID1 WORD SRDO ID1 for the original data

ID2 WORD SRDO ID2 for the inverted data

REFRESHTIME TIME The time transmitted is the time in which the SRDO is sent at the latest. The REFRESHTIME has to be shorter than the SCT indicated at the receiving block CAN_SAFETY_RECEIVE.

OPERATIONAL BOOL TRUE: The SRDO is cyclically safely transmitted. Reconfiguration of the function is not possible in this state.

FALSE: The SRDO cannot be transmitted. The function can be configured.

49


DLC BYTE Number of bytes to be transmitted from array DATA (permissible values 0 ... 8)

DATA ARRAY The array (length 8, type Byte) contains the data to be transmitted.

EVENTMODE BOOL TRUE: The data are transmitted in an event-driven manner, i.e. a modification to the data array causes an immediate transmission. If no modification is made, the data will be transmitted after the REFRESHTIME has elapsed, at the latest.

FALSE: The data are cyclically transmitted after the REFRESHTIME.

GFC BOOL A rising edge at the input transmits the "global failsafe command" once.

Function outputs


CFG_ERROR BYTE faulty configuration

0: no error

1: faulty identifier pair

2: SRDO number invalid

3: attempted configuration in mode Operational

Description CAN_SAFETY_TRANSMIT initialises, configures and transmits an SRDO. Before the function input OPERATIONAL is set to TRUE the configuration (NUMBER, ID1, ID2 and RFRESHTIME) has to be transferred to the function with CONFIG = TRUE. Starting the communication (OPERATIONAL = TRUE) stores the configuration and secures it by means of a check sum.

Maximum 8 transmit SRDO can be initialised in one application program.

Each millisecond 1 transmitting SRDO and 1 receiving SRDO are processed. That means: If only one SRDO is defined in the program it can be transferred every ms. In the case of 8 SRDO each object is processed only every 8 ms.

Depending on the bus load (further CAN messages independent of CANsafety) a SRVT of 16ms – 24ms has to be set in the case of 8 transmitting SRDO. If the bus load is very high the time between the normal and the inverted data messages increases resulting in an even longer SRVT.


50

Recommended setting for very high bus load due to CANopen and 8 SRDO:

REFRESHTIME = 100ms

SCT = 150 ms

SRVT = 40 ms

Transmission of analogue data via an SRDO:

If analogue values are transmitted via an SRDO, the input EVENTMODE should be set to FALSE. Otherwise, an extreme load might be caused on the CAN bus.

51

Function CAN_SAFETY_RECEIVE

Library

CR7xxx_Vx.LIB

Function symbol

Target Receives a safe CAN message (SRDO – TX)



NUMBER BYTE Number of the SRDO.

A value range of 0...7 is permissible.

CONFIG BOOL TRUE: Configuration is written

(Condition OPERATIONAL = FALSE)

ID1 WORD SRDO ID1 for the original data

ID2 WORD SRDO ID2 for the inverted data

SCT TIME The maximum time in which the SRDO is to be cyclically received is indicated. The SCT value has to be longer than the SCT indicated at function CAN_SAFETY_TRANSMIT. If the SCT is exceeded function output ERROR is set to TRUE and the controller goes into the "safe state".

SRVT TIME The maximum time is indicated in which the 2nd message with the inverted data has to be received. If the SRVT is exceeded function output ERROR is set to TRUE and the controller goes into the "safe state".


52


OPERATIONAL BOOL TRUE: The SRDO can be received safely. Apart from the correctness of the data, the SCT and SRVT are monitored. If the set time values are exceeded function output ERROR is set to TRUE and the controller goes into the "safe state".

Reconfiguration of the function is not possible in this state.

FALSE: The SRDO cannot be received. The function can be configured.

Function outputs


CFG_ERROR BYTE faulty configuration

0: no error

1: faulty identifier pair

2: SRDO number invalid

3: attempted configuration in mode Operational

DATA ARRAY The array (length 8, type Byte) contains the received data.

DLC BYTE Length of the CAN message (number of transmitted bytes). The data bytes can be read from the ARRAY.

VALID BOOL The output is TRUE for one cycle when new valid data have been received.

ERROR BOOL Collective error: Faulty data transmission, SCT or SRVT error (error flag ERROR_CAN_SAFETY is set simultaneously). The controller goes into the safe state – outputs off.

GFC BOOL GFC received. The output is TRUE for one cycle.

53

Description CAN_SAFETY_RECEIVE initialises, configures and receives an SRDO. Before the function input OPERATIONAL is set to TRUE the configuration (NUMBER, ID1, ID2, SCT and SRVT) has to be transmitted to the function with CONFIG = TRUE. Starting the communication (OPERATIONAL = TRUE) stores the configuration and secures it by means of a check sum.

Received data are stored in the array and the output VALID is set to TRUE for one cycle. The data have to be read and safely processed with the application software.

If the data are received faulty or outside the defined time limits the controller passes into the safe state (all outputs off).

Maximum 8 receive SRDO can be initialised in one application program.

Each millisecond 1 transmitting SRDO and 1 receiving SRDO are processed. That means: If only one SRDO is defined in the program it can be transferred every ms. In the case of 8 SRDO each object is processed only every 8 ms.

Depending on the bus load (further CAN messages independent of CANsafety) a SRVT of 16ms – 24ms has to be set in the case of 8 transmitting SRDO. If the bus load is very high the time between the normal and the inverted data messages increases resulting in an even longer SRVT.

Recommended setting for very high bus load due to CANopen and 8 SRDO:

REFRESHTIME = 100ms

SCT = 150 ms

SRVT = 40 ms

Important:

Before the function is activated (OPERATIONAL = TRUE), valid CANsafety data (correct identifier, correct order, etc.) must be transmitted on the bus. Otherwise the fault monitoring of the function block will be activated, the ERROR output set and the controller will pass into the safe state. Then, a safe CAN communication is no longer possible.

55

7. Safety concept of the software

7.1 Program and system monitoring

System test All software parts in the controller are monitored by the operating system and theinternal additional processor as far as possible. This way errors, e.g. time-out in thecase of an improper program run, can be detected and the user can reactaccordingly.

When the controller is switched on all hardware and software parts of the controllerare tested. These internal tests and monitoring processes are repeated at regularintervals with the time to first fault of 30 s being kept. Independent of the userprogram all function parts of the controller incl. the outputs (see chapter 4.5) aretested.

Structure of the software

The software in the controller is divided into the parts operating system and usersoftware. They are monitored cyclically with regard to faultless operationindividually and as a total by means of check sums. The check sums are generatedautomatically and are attached to the software parts.

Operating system

The user receives the operating system together with the programming system. Ithas to be loaded once (normal case).

The numbers of the operating system and of the hardware have to match,e.g. CR7020_V020000.H86 -> CR7020.

User program The user program or application program is created on site. The structure has tocorrespond to the required safety class. It has to be loaded into the controller afterthe operating system.

When creating the application program, make sure that the versions of theoperating system (*.H86), the controller configuration (*.cfg) and the libraries(*.LIB) are identical.

Maximum program cycle time

The maximum cycle time of a user program must not exceed 100 ms. Longer timesresult in a reaction of the watchdog and thus in a Fatal Error (LED red /permanently).

Safety concept of the software

56

7.2 Error messages

If any errors are detected during the system monitoring the controller reacts.Depending on the severity of the error the controller behaves differently.

The error flags are not automatically reset by the operating system. This has to bedone by the user program after error analysis and elimination.

Slight error Slight errors are only signalled to the user program. It is the responsibility of theapplication programmer to react to these errors. The minimum reaction should beto reset the error marker.

Note:

If an output is configured as SAFETY, ERROR_BREAK_Qx andERROR_SHORT_Qx cause the error flag ERROR_IO to be set and thus cause asevere error. Slight error

ERROR_BREAK_Qx Error byte wire break (output not SAFETY) ERROR_SHORT_Qx Error byte short circuit (output not SAFETY

Severe error If a "severe error" is detected all outputs (and the relay) are switched off. The LEDlights red. The application program continues running; communication, e.g.regarding error location, via the interfaces is possible.

Severe error ERROR Collective error flag ERROR_TEMPERATURE Overtemperature (> 85°C) ERROR_POWER Under/overvoltage ERROR_VBBR Voltage missing at terminal VBBR ERROR_ANALOG Error analog conversion

ERROR_IO Collective error wire break, short circuit, cross fault

ERROR_BREAK_Qx Error byte wire break (OUT_SAFETY set) ERROR_SHORT_Qx Error byte short circuit (OUT_SAFETY set) ERROR_OUTPUTBLANKING Cross fault at one of the safety outputs ERROR_CAN_SAFETY SCT, SRVT and data error

If a severe error occurs, no further diagnosis (wire break, short circuit) of theinputs/outputs can be carried out. That is why e.g. all error bits have to be resetfirst. A further error analysis has to be carried out in the user program by means ofan error routine.

CAN error If the mechanism of safe data transmission is selected via CAN bus all detectederrors in the transmitter (producer) and receiver (consumer) of the data cause anerror message and the SafetyController passes into the safe state (severe error). Inaddition, system flag ERROR_CAN_SAFETY is set and all outputs (and the relay)are switched off. The LED lights red. The application program continues running;communication, e.g. regarding error location, via the interfaces is possible.

CAN errors can be monitored via the CAN system flag with or without CANsafety.

57

CAN error/messages CAN1_WARNING warning threshold reached (>= 96), interface 1 CAN1_LASTERROR error register CAN controller 1 CAN1_BUSOFF bus-off error interface 1 CAN2_WARNING warning threshold reached (>= 96), interface 2 CAN2_LASTERROR error register CAN controller 2 CAN2_BUSOFF bus-off error interface 2

If a severe error occurs, no further diagnosis (wire break, short circuit) of theinputs/outputs can be carried out. That is why e.g. all error bits have to be resetfirst. A further error analysis has to be carried out in the user program by means ofan error routine.

Fatal error When a "fatal error" occurs the controller is stopped completely. All outputs areswitched off, the processing of the software is stopped and communication is nolonger possible. The LED lights red.

fatal error ERROR_MEMORY memory error ERROR_ADDRESS addressing error ERROR_CPU CPU error ERROR_CO_CPU error in the co-processor ERROR_INSTRUCTION_TIME processing time error ERROR_TIME_BASE error internal system time ERROR_RELAIS error relay triggering ERROR_DATA faulty system data

If the test input (pin 24) is active a "fatal error" is treated like a "severe error" whichmeans that the outputs are switched off and the LED lights red. Communication forfurther error diagnostics is possible as the application program continues running.

7.3 Program creation and download

The user program is created with the programming system CoDeSys and is loadedinto the controller several times during the program development. Before eachdownload the generated code is translated again which means that each time anew check sum is created.

This procedure is permissible up to the release of the software. For the seriesproduction of the machine or for service a uniform software and check sum have tobe ensured.

Safety concept of the software

58

Saving the released software

After the program development has been finished and the complete systemhas been released by the certifying body in question (e.g. TÜV, BiA) the finalversion of the application program loaded in the controller has to be readfrom the controller by means of the auxiliary program DOWNLOADER andhas to be saved on a data carrier under the name name_of_project_file.H86.This is the only way to ensure that the application software is saved with thecorresponding check sums.

Downloading the released software

In order to provide one and the same software to all machines in seriesproduction, only this file may be loaded into the controllers by means of theDOWNLOADER program.

An error in the data of this file is automatically detected by the integratedcheck sum when loading with DOWNLOADER.

Changes in the application software with the programming software CoDeSysautomatically generate a new application file which may only be loaded into thesafety-oriented controllers after renewed certification.

59

8. Special conditions and requirements for the use in control category 3 applications

The SafetyController is a one-channel controller which meets the requirements forcontrol category 3 without any restrictions.

Configuration and use in safety-oriented applications should only be carried outbased on a risk analysis.

In addition, the following points have to be observed:

General The de-energized state of an output with safety function is the safe state (L-signal).This state has to be accomplished via 2 separate and independent switch-off waysby using tested trip actuators

Connection of inputs and outputs

Safety-oriented inputs and outputs have to be used redundantly. This includes theredundant connection of signal transmitters to the inputs and the use of redundantoutputs as a second way of switching off in the application (e.g. hydraulic valvesand pumps) (see chapter 4)

Sensors / signal transmitters

The signal transmitters have to be connected to two different input groups. As faras possible the inputs marked safe and for redundancy the analog channels haveto be used.

If inductive fail-safe switches are connected the provided outputs and inputs haveto be used.

Safety consideration

On the basis of the monitoring functions of the above points implemented in theoperating system it has to be assessed if process dependent safety functions tocontrol category 3 are provided in accordance with the safety system and the usersoftware.

Fault tolerance time

In this context the fault tolerance time of the process in particular needs to beassessed. This is the maximum time which may pass in the application betweenthe occurrence of an error and the safe state without any danger for persons. Themaximum cycle time of the user program (in the most unfavourable case 100 ms)and the possible delay and response times of the trip actuators need to be takeninto account. The resulting total time has to be shorter than the fault tolerance timeof the application.

Time to first fault

The time to first fault also has to be observed. The controller is tested by theoperating system via internal monitoring and test routines in a period of max. 30 s.This "test cycle time" has to be shorter than the statistical time to first fault for theapplication.

Programming The user software always has to be created by observing all information and notesin the system manual.

Use of the Extended Controller

This special variation of the SafetyController contains two control modules in onehousing. They are internally connected via a bus. During programming please notethat both control modules are loaded with an own, independent program. Theinternal interface is only available for the not safety-related data exchange.

Operating system detection

The number of the operating system has to match the article number of the controlmodule (e.g. CR7020_Vx.H86 -> CR7020). It also has to be ensured that thesoftware parts operating system (*.H86), control configuration (*.CFG) and libraries(*.LIB) have the same version identification (e.g. CR7020_Vx).

Special conditions and requirements for the use in control category 3 applications

60

Program structure

In the program structure it has to be ensured that safety functions are separatedfrom pure control functions, i.e. that they are implemented in their own programand function blocks. This prevents problems in the safe program parts and can bechecked and tested more easily.

Variables and flags in the safety-relevant part have to have a clear identification,e.g. prefix S_.... . Furthermore, it has to be verified that the safety-relevant part ofthe software is not influenced by the other program parts.

Monitoring the user data by means of the CRC check

In general, the most important data of the operating system are monitoredautomatically via a check sum (CRC check). For safety-related data generated inthe user program the function CHECK_DATA can be used in addition. Details aredescribed in the system manual ecomat mobile controller family.

Function check of the software

All parts of the application software have to undergo a complete function check.The function check has to be carried out with the test input deactivated.

Test input When outputs have been configured as safety-related (mode byte OUT_SAFETYset) they cannot be used when the test input is active. The test input has to be setwhen e.g. the software is to be loaded in the controller.

The outputs are only available again when the test input has been deactivated andthe controller has been reset (switch on and off).

To still allow software monitoring (no program download) with the programmingsystem CoDeSys the function SET_DEBUG is available.

In running operation the test input or the function SET_DEBUG must not beused.

Program changes

After the application software has been approved, no more changes are allowed.Only use the software should with an unchanged operating system software. Theonly file allowed to be loaded into the control modules via the download software isthe HEX file name_of_project_file.H86.

If changes are made, the complete application software needs to be checked andcertified again.

Documentation In addition to a print out, the application software has to be archived with writeprotection in two copies (e.g. diskette, CD). The documentation has to clearly showthe version of the operating system used, the programming software and thehardware used.

Via the download software the version of the application software and theoperating system can, if required, be compared with the archived software. Thisincludes comparison of the CRC code.

61

9. Annex 9.1 Implemented functions in the SafetyController

Function block category Function

CAN functions CAN1_BAUDRATE

CAN1_TRANSMIT

CAN1_RECEIVE

CAN1_ERRORHANDLER

CAN1_DOWNLOADID

CAN2

CAN2_TRANSMIT

CAN2_RECEIVE

CAN2_ERRORHANDLER

CAN Safety CAN_SAFETY_RECEIVE

CAN_SAFETY_TRANSMIT

CANopen: Master/Slave CAN1_SDO_READ

CAN1_SDO_WRITE

CANopen functions CoDeSys

J1939 J1939

J1939_RECEIVE

J1939_TRANSMIT

J1939_RESPONSE

J1939_SPECIFIC_REQUEST

J1939_GLOBAL_REQUEST

PWM signal processing PWM

PWM100

FAST_ANALOG

OUTPUT_CURRENT

OUTPUT_CURRENT_CONTROL

Fail-safe inductive switch SAFETY_SWITCH

Annex

62

Counter functions FREQUENCY

PERIOD

PERIOD_RATIO

PHASE

INC_ENCODER

FAST_COUNT

Additional functions

Data saving, reading, conversion MEMCPY

FLASHWRITE

FLASHREAD

FRAMWRITE

FRAMREAD

Data access SET_IDENTITY

SET_PASSWORD

CHECK_DATA

SET_DEBUG

Internal SSC interface SSC_RECEIVE

(only CR7200) SSC_TRANSMIT

Serial interface SERIAL_SETUP

SERIAL_TX

SERIAL_RX

SERIAL_PENDING

Reading the system time TIMER_READ

TIMER_READ_US

Variables processing NORM

Analog value processing INPUT_VOLTAGE

INPUT_CURRENT

INPUT_ANALOG

Closed loop controller DELAY

PT1

PID1

PID2

GLR

63

9.2 I/O configuration SafetyController CR7020 Supply Pin Potential Description Comment 23 VBB S (10...32 V DC) Supply sensors and module 05 VBB O (10...32 V DC) Supply outputs relay switched 34 VBB R (10...32 V DC) Supply via relay relay switched 01 GND S Ground sensors and module 15 GND O Ground outputs 12 GND A Ground analog outputs

CAN, RS-232, ERROR, TEST Pin Potential Description Comment 14 CAN 1 H CAN-Interface 1 (High) 32 CAN 1 L CAN-Interface 1 (Low) 26 CAN 2 H CAN-Interface 2 (High) SAE J 1939 25 CAN 2 L CAN-Interface 2 (Low) SAE J 1939 33 GND Ground 06 RxD RS-232 Interface (programming) Pin 03, PC DSUB 07 TxD RS-232 Interface (programming) Pin 02, PC DSUB 13 ERROR Error output B H 24 TEST TEST input

INPUTS/OUTPUTS Pin INPUTS Configuration OUTPUTS Configuration Diagnosis In / Out relay switched 08 %IX0.0/%IW03 B L A – – - / 27 %IX0.1/%IW04 B L A – – - / 09 %IX0.2/%IW05 B L A – – - / 28 %IX0.3/%IW06 B L A – – - / 10 %IX0.4/%IW07 B L A – – - / 29 %IX0.5/%IW08 B L A – – - / 11 %IX0.6/%IW09 B L A – – - / 30 %IX0.7/%IW10 B L A – – - / 44 %IX0.8 B L %QX0.0 B H PWM PWM I – / • VBB O 45 %IX0.9 B L %QX0.1 B H PWM PWM I – / • VBB O 46 %IX0.10 B L %QX0.2 B H PWM PWM I – / • VBB O 47 %IX0.11 B L %QX0.3 B H PWM PWM I – / • VBB O 20 %IX0.12 B L I L *1 – – - / – 02 %IX0.13 B L I L *1 – – - / – 21 %IX0.14 B L I L *1 – – - / – 38 %IX0.15 B L I L *1 – – - / – 36 - %QX0.4 B H PWM PWM I / • VBB R 54 - %QX0.5 B H PWM PWM I / • VBB R 17 - %QX0.6 B H PWM PWM I / • VBB R 53 - %QX0.7 B H PWM PWM I / • VBB R 19 %IX1.4 B L I L *2 – – - / 55 %IX1.5 B L I L *2 – – - / 18 %IX1.6 B L I L *2 – – - / 37 %IX1.7 B L I L *2 – – - / 39 %IX1.8 B L/H %QX0.8 B H - / • VBB O 03 %IX1.9 B L/H %QX0.9 B H - / • VBB O 40 %IX1.10 B L/H %QX0.10 B H - / • VBB O 22 %IX1.11 B L/H %QX0.11 B H - / • VBB O 41 %IX1.12 B L/H %QX0.12 B H - / • VBB O 42 %IX1.13 B L/H %QX0.13 B H - / • VBB O 43 %IX1.14 B L/H %QX0.14 B H - / • VBB O 04 %IX1.15 B L/H %QX0.15 B H - / • VBB O 48 - %QX1.0 B H PWM / • VBB R 49 - %QX1.1 B H/L H-Brdg / • VBB R 31 - %QX1.2 B H/L H-Brdg / • VBB R 50 - %QX1.3 B H PWM / • VBB R 51 - %QX1.4 B H PWM / • VBB R 52 - %QX1.5 B H/L H-Brdg / • VBB R 16 - %QX1.6 B H/L H-Brdg / • VBB R 35 - %QX1.7 B H PWM / • VBB R Marked inputs/outputs and input/output functions -> safe inputs/outputs *1: Fast inputs FRQ0...FRQ3 *2: Fast inputs CYL0...CYL3

Annex

64

9.3 I/O configuration SafetyController CR7200

This special variation of the SafetyController contains two control modules ofconfiguration CR7020 in one housing. They are internally connected via a bus.During programming please note that both control modules are loaded with anown,independent program. The internal interface is only available for the not safety-related data exchange.

9.4 I/O configuration SafetyController CR7505 Supply Pin Potential Description Comment 23 VBB S (10...32 V DC) Supply sensors and module 05 VBB O (10...32 V DC) Supply outputs relay switched 34 VBB R (10...32 V DC) Supply via relay relay switched 01 GND S Ground sensors and module 15 GND O Ground outputs 12 GND A Ground analogue outputs

CAN, RS-232, ERROR, TEST Pin Potential Description Comment 14 CAN 1 H CAN-Interface 1 (High) 32 CAN 1 L CAN-Interface 1 (Low) 26 CAN 2 H CAN-Interface 2 (High) SAE J 1939 25 CAN 2 L CAN-Interface 2 (Low) SAE J 1939 33 GND Ground 06 RxD RS-232 Interface (programming) Pin 03, PC DSUB 07 TxD RS-232 Interface (programming) Pin 02, PC DSUB 13 ERROR Error output B H 24 TEST TEST input

INPUTS/OUTPUTS Pin INPUTS Configuration OUTPUTS Configuration Diagnosis In / Out relay switched 08 %IX0.0/%IW03 B L A – – - / 27 %IX0.1/%IW04 B L A – – - / 09 %IX0.2/%IW05 B L A – – - / 28 %IX0.3/%IW06 B L A – – - / 10 %IX0.4/%IW07 B L A – – - / 29 %IX0.5/%IW08 B L A – – - / 11 %IX0.6/%IW09 B L A – – - / 30 %IX0.7/%IW10 B L A – – - / 44 %IX0.8 B L %QX0.0 B H PWM PWM I – / • VBB O 45 %IX0.9 B L %QX0.1 B H PWM PWM I – / • VBB O 46 %IX0.10 B L %QX0.2 B H PWM PWM I – / • VBB O 47 %IX0.11 B L %QX0.3 B H PWM PWM I – / • VBB O 20 %IX0.12 B L I L *1 – – • / 02 %IX0.13 B L I L *1 – – • / 21 %IX0.14 B L I L *1 – – • / 38 %IX0.15 B L I L *1 – – • / 36 - %QX0.4 B H PWM PWM I / • VBB R 54 - %QX0.5 B H PWM PWM I / • VBB R 17 - %QX0.6 B H PWM PWM I / • VBB R 53 - %QX0.7 B H PWM PWM I / • VBB R 19 %IX1.4 B L I L *2 – – • / 55 %IX1.5 B L I L *2 – – • / 18 %IX1.6 B L I L *2 – – • / 37 %IX1.7 B L I L *2 – – • / Marked inputs/outputs and input/output functions -> safe inputs/outputs *1: Fast inputs FRQ0...FRQ3 *2: Fast inputs CYL0...CYL3

Documents

for CoDeSys version 2.3 and higher...The contents of this manual 2 Supplement to the system manual ecomat mobile Controller R 360 18/01/2006, for CoDeSys V 2.3 or higher Warranty This