Himatrix Series
Himatrix Series
Himatrix Series
Safety-Related Controller
Contact
HIMA contact details:
HIMA Paul Hildebrandt GmbH + Co KG
P.O. Box 1261
68777 Brühl, Germany
Phone: +49 6202 709-0
Fax: +49 6202 709-107
E-mail: info@hima.com
Table of Contents
1 Introduction 7
1.1 Structure and Use of the Document 7
1.2 Target Audience 9
1.3 Formatting Conventions 9
1.3.1 Safety Notes 9
1.3.2 Operating Tips 10
1.4 Service and Training 10
2 Safety 11
2.1 Intended Use 11
2.1.1 Scope 11
2.1.1.1 Application in Accordance with the De-Energize to Trip Principle 11
2.1.1.2 Application in Accordance with the Energize to Trip Principle 11
2.1.1.3 Use in Fire Alarm Systems 11
2.1.2 Non-Intended Use 11
2.2 Environmental Requirements 12
2.2.1 Test Conditions 12
2.2.1.1 Climatic Requirements 13
2.2.1.2 Mechanical Requirements 13
2.2.1.3 EMC Requirements 13
2.2.1.4 Power Supply 14
2.2.2 Noxious Gases 14
2.3 Tasks and Responsibilities of Operators and Machine and System Manufacturers
14
2.3.1 Connection of Communication Partners 14
2.3.2 Use of Safety-Related Communication 14
2.4 ESD Protective Measures 15
2.5 Residual Risk 15
2.6 Safety Precautions 15
2.7 Emergency Information 15
3 Product Description 16
3.1 Line Control 16
3.2 Line Monitoring with HIMatrix F35 17
3.3 Supply Voltage Monitoring 17
3.4 Monitoring the Temperature State 18
3.4.1 Setting the Temperature Threshold for Messages in F*03 Devices 18
3.5 Short-Circuit Reaction of Output Channels 18
3.6 Alarms and Sequences of Events Recording - with F*03 Devices 19
3.6.1 Alarms&Events 19
3.6.2 Creating Events 19
3.6.3 Recording Events 20
3.6.4 Transfer of Events 20
3.7 Product Data 20
3.8 Licensing with F*03 Systems 20
4 Communication 21
4.1 HIMatrix Communication Protocols 21
4.2 Ethernet Communication 21
4.2.1 safeethernet 21
4.2.2 Maximum Communication Time Slice 23
4.2.3 Connectors for safeethernet/Ethernet 23
4.2.4 Communication with the PADT 23
4.2.5 Ethernet Communication Protocols 24
4.2.5.1 SNTP 24
4.2.5.2 Modbus TCP 24
4.2.5.3 Send & Receive TCP 24
4.2.5.4 PROFINET IO and PROFIsafe (with F*03 only) 24
4.2.5.5 EtherNet/IP (up to CPU OS V7) 24
4.3 Fieldbus Communication 25
4.3.1 Equipment of Fieldbus Interfaces with Fieldbus Submodules 25
4.3.2 Restrictions for Operating Protocols Simultaneously 26
5 Operating System 27
5.1 Functions of the Processor Operating System 27
5.2 Indication of the Operating System Versions 27
5.2.1 SILworX 27
5.2.2 ELOP II Factory 27
5.3 Behavior in the Event of Faults 27
5.3.1 Permanent Faults on Inputs or Outputs 28
5.3.2 Temporary Faults on Inputs or Outputs 28
5.3.3 Internal Faults 28
5.4 The Processor System 28
5.4.1 Modes of Operation for the Processor System 29
5.4.2 Programming 29
6 User Program 30
6.1 Modes of Operation for the User Program 30
6.2 User Program Cycle Sequence, Multitasking with F*03 Devices 30
6.2.1 Multitasking 31
6.2.2 Multitasking Mode 33
6.3 Reload - with F*03 Devices 37
6.4 General Information 39
6.5 Forcing - CPU OS V7 and Higher 39
6.5.1 Forcing in Connection with F*03 40
6.5.2 Forcing in Connection with Standard devices and Modules 40
6.5.3 Restriction to the Use of Forcing 42
6.6 Forcing - CPU OS up to V7 42
6.6.1 Time Limits 42
6.6.2 Configuration Parameters for Forcing 43
6.6.3 Force Allowed - CPU Switch 43
7 Start-Up 44
7.1 Considerations about Heat 44
7.1.1 Heat Dissipation 44
7.1.1.1 Definitions 44
7.1.1.2 Installation Type 44
7.1.1.3 Natural Convection 45
7.2 Installation and Mounting 45
7.2.1 Mounting 46
7.2.1.1 Routing Cables 47
7.2.2 Air Circulation 48
7.2.3 Construction Depths 49
7.2.4 Connecting the Input and Output Circuits 50
7.2.5 Earthing and Shielding 50
7.2.5.1 Earthing the 24 VDC System Voltage 50
7.2.5.2 Earthing Connections 51
7.2.5.3 Shielding 51
7.2.5.4 EMC Protection 51
7.2.6 Connecting the Supply Voltage 51
7.3 Configuration with SILworX - CPU OS V7 and Higher 52
7.3.1 Configuring the Resource 52
7.3.1.1 Resource Properties 52
7.3.1.2 Parameters for the Remote I/Os 55
7.3.1.3 Hardware System Variables for Setting the Parameters 56
7.3.1.4 Hardware System Variables for Reading the Parameters 56
7.3.1.5 Rack System Parameter Settings 59
7.3.2 Configuring the Ethernet Interfaces 59
7.3.3 Configuring the User Program 60
7.3.4 Configuring the Inputs and Outputs 61
7.3.5 Configure Line Control 63
7.3.5.1 Required Variables 63
7.3.5.2 Configuring Pulsed Outputs 64
7.3.5.3 Configuration Example with SILworX 64
7.3.6 Generating the Resource Configuration 65
7.3.7 Configuring the System ID and the Connection Parameters 66
7.3.8 Loading a Resource Configuration after a Reset 66
7.3.9 Loading a Resource Configuration from the PADT 67
7.3.10 Loading a Resource Configuration from the Flash Memory of the Communication
System 67
7.3.11 Cleaning up a Resource Configuration in the Flash Memory of the Communication
System 67
7.3.12 Setting the Date and the Time 68
7.4 User Management in SILworX - CPU OS V7 and Higher 68
7.4.1 User Management for SILworX Projects 68
7.4.2 User Management for the Controller 69
7.4.3 Setting up User Accounts 70
7.5 Configuration with SILworX - CPU OS V7 and Higher 71
7.5.1 Configuring the Ethernet Interfaces 71
7.6 Configuring Alarms and Events in F*03 Devices 72
7.7 Configuring a Resource Using ELOP II Factory - CPU OS up to V7 75
7.7.1 Configuring the Resource 75
7.7.2 Configuring the User Program 76
7.7.3 Configuring the Inputs and Outputs 78
7.7.4 Configure Line Control 78
7.7.4.1 Required Signals 78
1 Introduction
The safety-related compact systems described in this manual can be used for different
purposes. The following conditions must be met to safely install and start up the HIMatrix
automation devices, and to ensure safety during their operation and maintenance:
Knowledge of regulations.
Proper technical implementation of the safety instructions detailed in this manual performed
by qualified personnel.
HIMA will not be held liable for severe personal injuries, damage to property or the environment
caused by any of the following: unqualified personnel working on or with the devices, de-
activation or bypassing of safety functions, or failure to comply with the instructions detailed in
this manual (resulting in faults or impaired safety functionality).
HIMatrix automation devices have been developed, manufactured and tested in compliance with
the pertinent safety standards and regulations. They may only be used for the intended
applications under the specified environmental conditions and only in connection with approved
external devices.
This document usually refers to compact controllers and remote I/Os as devices, and to the
i plug-in cards of a modular controller as modules.
Modules is also the term used in SILworX.
All these devices are identified in this document with F*03. The additional features of these
devices compared to standard devices are:
Enhanced performance
Sequence of events recording possible
Multitasking possible
Reload possible
Two IP addresses
This manual distinguishes between the following variants of the HIMatrix system:
Programming tool Hardware Processor operating Communication
system operating system
SILworX F*03 CPU OS V8 and higher COM OS V13 and
higher
SILworX Default CPU OS V7 and higher COM OS V12 and
higher
ELOP II Factory Default CPU OS up to V7 COM OS up to V12
Table 1: HIMatrix System Variants
Projects created with ELOP II Factory cannot be edited with SILworX, and vice versa!
i
The latest manuals can be downloaded from the HIMA website at www.hima.com. The revision
index on the footer can be used to compare the current version of existing manuals with the
Internet edition.
In addition to the Table 2 documents, the manuals specific to the individual controllers and
remote I/Os must be taken into account.
SIGNAL WORD
Type and source of risk!
Consequences arising from non-observance
Risk prevention
NOTE
Type and source of damage!
Damage prevention
2 Safety
All safety information, notes and instructions specified in this document must be strictly
observed. The product may only be used if all guidelines and safety instructions are adhered to.
The product is operated with SELV or PELV. No imminent risk results from the product itself.
The use in Ex-Zone is permitted if additional measures are taken.
2.1.1 Scope
The safety-related HIMatrix controllers can be used in applications up to SIL 3 in accordance
with IEC 61508.
The HIMatrix systems are certified for use in process controllers, protective systems, burner
controllers, and machine controllers.
2.1.1.1 Application in Accordance with the De-Energize to Trip Principle
The automation devices have been designed in accordance with the de-energize to trip
principle.
A system that operates in accordance with the de-energize to trip principle adopts the de-
energized state if a fault occurs.
2.1.1.2 Application in Accordance with the Energize to Trip Principle
The HIMatrix controllers can be used in applications that operate in accordance with the
'energize to trip' principle.
A system operating in accordance with the energize to trip principle switches on, for instance,
an actuator to perform its safety function.
When designing the controller system, the requirements specified in the application standards
must be taken into account. For instance, line diagnosis for the inputs and outputs or message
reporting a triggered safety function may be required.
2.1.1.3 Use in Fire Alarm Systems
The HIMatrix systems with detection of short-circuits and open-circuits are tested and certified
for used in fire alarm systems in accordance with DIN EN 54-2 and NFPA 72. To contain the
risks, these systems must be able to adopt an active state on demand.
The operating requirements must be observed!
All the environmental requirements specified in this manual must be observed when operating
the HIMatrix system.
The devices have been tested to ensure compliance with the following standards for EMC,
climatic and environmental requirements:
Standard Content
IEC/EN 61131-2: Programmable controllers, Part 2
2007 Equipment requirements and tests
IEC/EN 61000-6-2: EMC
2005 Generic standards, Parts 6-2
Immunity for industrial environments
IEC/EN 61000-6-4: Electromagnetic Compatibility (EMC)
2007 + A1:2011 Generic emission standard, industrial environments
Table 4: Standards for EMC, Climatic and Environmental Requirements
When using the safety-related HIMatrix control systems, the following general requirements
must be met:
Requirement type Requirement content
Protection class Protection class III in accordance with IEC/EN 61131-2
Pollution Pollution degree II in accordance with IEC/EN 61131-2
Altitude < 2000 m
Housing Standard: IP20
If required by the relevant application standards (e.g., EN 60204,
EN 13849), the HIMatrix system must be installed in an enclosure of the
specified protection class (e.g., IP54).
Table 5: General Requirements
Operating requirements other than those specified in this document are described in the device-
specific or module-specific manuals.
2.2.1.2 Mechanical Requirements
The following table lists the most important tests and limits for mechanical requirements:
IEC/EN 61131-2 Mechanical tests
Vibration immunity test:
5...9 Hz / 3.5 mm
9...150 Hz, 1 g, EUT in operation, 10 cycles per axis
Shock immunity test:
15 g, 11 ms, EUT in operation, 3 shocks per axis (18 shocks)
Table 7: Mechanical Tests
NOTE
Electrostatic discharge can damage the electronic components within the HIMatrix
systems!
When performing the work, make sure that the workspace is free of static, and wear
an ESD wrist strap.
If not used, ensure that the modules are protected from electrostatic discharge, e.g.,
by storing them in their packaging.
3 Product Description
HIMatrix compact systems are compactly constructed, safety-related controllers including one
safety-related processor system, a number of inputs and outputs and communication interfaces
in its housing.
In addition to the controllers, HIMatrix compact system also comprise remote I/Os, which can be
connected to the controllers via safeethernet and expand the controllers by additional inputs
and/or outputs.
For a detailed description of the individual devices, refer to the corresponding manuals.
The compact systems may also be connected to modular systems F60, via safeethernet as
well.
To this end, connect the digital outputs DO of the system to the digital inputs (DI) of the same
system as follows:
T1 T2 T3 T4
1 2
T1 1
T2 1
Configurable 5...2000 µs
The digital outputs DO are pulsed (briefly set to low level), to monitor the wires connected to the
digital inputs. The time base of the test pulse can be configured within 5...2000 μs (default value
400 μs).
If line control is configured in a remote I/O, the remote I/O's watchdog time must be increased
i (default value 10 ms).
Line control can be configured if the following systems are used: F1 DI 16 01, F3 DIO 8/8 01,
F3 DIO 16/8 01, F3 DIO 20/8, F20, F30 and F31.
The power supply units of HIMatrix systems must comply with the SELV (Safety Extra Low
Voltage) or PELV (Protective Extra Low Voltage) requirements.
Observing the permitted voltage limits guarantees the system's proper operation.
The required SELV/PELV power supply units ensure safe operation.
The device monitors the 24 VDC voltage during operation. Reactions occur in accordance with
the specified voltage level:
Voltage level Reaction of the device
19.3...28.8 V Normal operation
< 18.0 V Alarm states (internal variables are written and provided to the inputs or
outputs)
< 12.0 V Switching off the inputs and outputs
Table 12: Operating Voltage Monitoring
The Power Supply State system variable is used to evaluate the operating voltage state with the
programming tool or from within the user program.
If no or insufficient air circulates within a control cabinet and natural convection is not enough,
the threshold associated with High Temperature in the HIMatrix controller can already be
exceeded at ambient temperatures of less than 35 °C.
This can be due to local heating or to a bad heat conduction. In particular with digital outputs,
the heat levels strongly depend on their load.
The Temperature State system variable allows the user to read the temperature. If the state
Very high temperature often occurs, HIMA recommends improving the system heat dissipation,
e.g., by taking additional ventilation or cooling measures, such that the long life time of the
HIMatrix systems can be maintained.
The safety of the system is not compromised if the state High Temperature or Very High
i Temperature is entered.
If the maximum current permitted for all outputs is exceeded, all outputs are switched off and
cyclically switched on again.
The terminals for output circuits must not be plugged in while a load is connected. If short-
i circuits are present, the resulting high current may damage the terminals.
3.6.1 Alarms&Events
Events are state changes of a variable that are performed by the plant or controller, and are
provided with a timestamp.
Alarms are events that signalize increased risk potential.
The HIMatrix system records the state changes as events specifying the time point when they
occurred. The X-OPC server transfers the events to other systems such as control systems that
display or evaluate the events.
Status Variables
Status variables provide the user program with the state of scalar events. Each of the following
states is connected to a status variable and can be assigned a global variable of type BOOL:
Normal.
Low limit (L) exceeded.
Lowest limit (LL) exceeded.
High limit (H) exceeded.
Highest limit (HH) exceeded.
The assigned status variable becomes TRUE when the corresponding state is achieved.
The software activation code can be generated on the HIMA website using the system ID of the
controller (value 1...65 535). To this end, the SMR license must be activated.
The software activation code is intrinsically tied to this system ID. One license can only be used
one time for a specific system ID. For this reason, only activate the code when the system ID
has been uniquely defined.
4 Communication
Communication runs via the following interfaces:
Ethernet interfaces
Fieldbus interfaces
After 5000 operating hours, communication continues until the controller is stopped.
i Afterwards, the user program cannot be started without a valid license for the protocols used in
the project (invalid configuration).
Order the software activation code on time!
The software activation code can be generated on the HIMA website using the system ID of the
controller (value 1...65 535).
The software activation code is intrinsically tied to this system ID. One license can only be used
one time for a specific system ID. For this reason, only activate the code when the system ID
has been uniquely defined.
HIMatrix systems support the following Ethernet interface communication protocols.
safeethernet, redundant operation possible for F*03 controllers
Modbus TCP master
Modbus TCP slave
Send/Receive TCP
SNTP
EtherNet/IP
Only up to CPU OS V6.x (ELOP II Factory)
PROFINET IO controller
Only F*03
PROFINET IO device
Only F*03
Each protocol can be used once per controller.
Communication options for serial interfaces are described in Chapter 4.3.
4.2.1 safeethernet
An overview of safeethernet is available in the corresponding chapter of the SILworX
communication manual (HI 801 101 E).
When configuring safety-related communication, observe the instructions specified in the safety
manual (HI 800 023 E).
The different systems can be connected to one another via Ethernet in any configuration (e.g.,
star or linear network); a PADT may also be connected to any device.
NOTE
Ethernet operation may be disturbed!
Ensure that no network rings result from interconnecting the controllers. Data packets
may only travel to a system over a single path.
If controllers and remote I/Os with different versions of operating systems are connected via
safeethernet, the following cases must be observed:
Operating system of Operating system of safeethernet connection possible?
controller remote I/O
CPU OS V7 and CPU OS V7 and higher Yes
higher
CPU OS up to V7 CPU OS up to V7 Yes
CPU OS up to V7 CPU OS V7 and higher Yes
CPU OS V7 and CPU OS up to V7 No
higher
Table 15: Connection of Controllers and Remote I/Os with Different Operating Systems
Controllers with different operating system versions (CPU OS V7 and higher and CPU OS up to
V7) can be connected with cross-project communication, refer to the communication manual (HI
800 101 E)
When calculating the maximum response times allowed, the number of communication time
i slices must be equal to 1, see the communication manual (HI 801 101 E). The duration of the
communication time slice must be set such that, when using the communication time slice, the
cycle cannot exceed the watchdog time specified by the process.
A controller can simultaneously communicate with up to 5 PADTs. If this is the case, only one
programming tool can access the controller with write permission. The remaining programming
tools can only read information. If they try to establish a writing connection, the controller only
allows them a read-only access.
Refer to the corresponding communication manual for details on the various protocols.
4.2.5.1 SNTP
The SNTP protocol (simple network time protocol) is used to synchronize the time of the HIMA
resources via Ethernet. The current time can be retrieved via Ethernet in predefined time
intervals from a PC, or a HIMA resource configured as SNTP server.
HIMA resources with COM OS V6 and higher, can be configured and used as SNTP server
and/or as SNTP client. The SNTP server communicates with the SNTP client via the non-safe
UDP protocol on port 123.
For further details on the SNTP protocol, refer to the SILworX communication manual
(HI 801 101 E) or the online help of the programming tool.
4.2.5.2 Modbus TCP
The HIMA-specific designation for the non-safety-related Modbus TCP is Modbus Master/Slave
Eth.
The fieldbus protocols Modbus master/slave can communicate with the Modbus TCP via the
Ethernet interfaces of the HIMatrix controllers.
In a standard Modbus communication, the slave address and a CRC checksum are transferred
in addition to the instruction code and data, while in a Modbus TCP, this function is assumed by
the subordinate TCP protocol.
For further details on the Modbus TCP, refer to the SILworX communication manual
(HI 801 101 E) or HIMatrix Modbus master/slave manual (HI 800 003 E).
4.2.5.3 Send & Receive TCP
S&R TCP is a manufacturer-independent, non-safety-related protocol for cyclic and acyclic data
exchange and does not use any specific protocols other than TCP/IP.
With S&R TCP, HIMatrix systems are able to support almost every third-party system as well as
PCs with implemented socket interface to TCP/IP (e.g., Winsock.dll).
For further details on the S&R TCP, refer to the SILworX communication manual (HI 801 101 E)
or HIMatrix TCP/SR manual (HI 800 117 E).
4.2.5.4 PROFINET IO and PROFIsafe (with F*03 only)
The non-safety-related protocol PROFINET IO and the safety-related protocol PROFIsafe are
only available for F*03 controllers and must be configured using SILworX. Refer to the SILworX
communication manual (HI 801 101 E) for more information about communication.
4.2.5.5 EtherNet/IP (up to CPU OS V7)
EtherNet/IP communication is only supported in ELOP II Factory. EtherNet/IP is not supported
in SILworX.
EtherNet/IP (Ethernet Industrial Protocol) is an open industrial communication standard for
exchanging process data via Ethernet.
For further information, see http://www.odva.org (ODVA = Open DeviceNet Vendor
Association).
EtherNet/IP enables HIMatrix controllers to communicate with other Ethernet/IP devices (e.g.,
PLC, sensors, actuators and industrial robots).
The physical connection of EtherNet/IP runs over Ethernet interfaces with 10/100 Mbit/s.
For HIMatrix controllers, the EtherNet/IP protocol can be configured in the ELOP II Factory
Hardware Management (with hardware revision 02).
A HIMatrix controller can be configured as EtherNet/IP scanner and/or as EtherNet/IP target.
Refer to the ELOP II Factory online help for further details on the EtherNet/IP communication.
Prior to resetting a controller, take the consequences for other fieldbus subscribers into account!
If required, appropriate measures must be taken, e.g., the separation of the fieldbus connection.
The F20, F30 and F35 controllers must be equipped with fieldbus submodules for fieldbus
communication. The installation of the fieldbus submodules is optional and is carried out by the
manufacturer. The fieldbus interfaces are not operational without fieldbus submodule.
Only HIMA is authorized to mount the fieldbus submodules; failing which the warranty will be
i void.
Some fieldbus submodules are shown in Table 17. All available fieldbus submodules are listed
in the SILworX communication manual (HI 801 101 E).
Fieldbus submodule Protocols
PROFIBUS master PROFIBUS DP master
PROFIBUS slave PROFIBUS DP slave
RS485 module RS485 for Modbus (master or slave) and ComUserTask
RS232 module RS232 for ComUserTask
RS422 module RS422 for ComUserTask
SSI module SSI for ComUserTask
CAN module CAN - for F*03 only
Table 17: Fieldbus Submodule
The fieldbus submodule is selected when ordering the controller using the part number.
Depending on the fieldbus submodule, the communication protocols must be activated. For
further details on the procedures for registering and activating the protocols, refer to the
communication manuals, see Table 2.
The fieldbus submodules PROFIBUS master can be used on controllers F20, F30, F35 or F60
i with hardware revision 02.
5 Operating System
The operating system includes all basic functions of the HIMatrix controller.
Which application functions the PES should perform is specified in the user program. A code
generator translates the user program into a machine code. The programming tool transfers this
machine code to the controller's flash memory.
Each operating system is inspected by the TÜV in charge and approved for operation in the
safety-related controller. The valid versions of the operating system and corresponding
signatures (CRCs) are documented in a list maintained by HIMA in co-operation with the TÜV.
Additional features of one operating system version can only be used if a corresponding version
of the programming tool is used.
5.2.1 SILworX
The current COM and CPU operating system versions can be displayed using the module data
overview, see the SILworX online help. The module data overview is activated from within the
online view of the Hardware Editor, selecting the menu option Online.
The OS column contains the list of the current operating system versions.
5.4.2 Programming
A PADT (programming and debugging tool) is used to program the HIMatrix controllers. The
PADT is a PC equipped with one of the programming tools:
SILworX for HIMatrix systems with processor operating system V7 and higher.
ELOP II Factory for HIMatrix systems with processor operating system up to 7.
The programming tools supports the following programming languages in accordance with
IEC 61131-3:
Function block diagrams (FBD)
Sequential function charts (SFC)
The programming tools are suitable for developing safety-related programs and for operating
the controllers.
For more details on the programming tools, refer to the manuals 'First Steps ELOP II
Factory' (HI 800 006 E) and 'First Steps SILworX' (HI 801 103 E), and to the corresponding
online help.
6 User Program
In accordance with the IEC 61131-3 requirements, a PADT with installed programming tool, i.e.,
ELOP II Factory or SILworX, must be used to create and load the user program for the PES.
First, use the PADT to create and configure the user program for the controller's safety-related
operation. To this end, observe the instructions specified in the safety manual (HI 800 023 E)
and ensure that the requirements specified in the report to the certificate are met.
Once the compiling is complete, the programming device loads the user program (logic) and its
configuration (connection parameters such as IP address, subnet mask and system ID) into the
controller and starts them.
The PADT can be used to perform the following actions while the controller is operating:
Starting and stopping the user program.
Displaying and forcing variables or signals using the Force Editor.
In test mode, executing the user program in single steps - not suitable for safety-related
operation.
Reading the diagnostic history.
This is possible, provided that the PADT and the controller are loaded with the same user
program.
In a simplified overview, the processor module cycle (CPU cycle) of only one user program runs
through the following phases:
1. Process the input data.
2. Run the user program.
3. Supplying the output data.
These phases do not include special tasks, e.g., reload, that might be executed within a CPU
cycle.
In the first phase, global variables, results from the function blocks and other data are
processed and provided as the input data for the second phase. The first phase need not start
at the beginning of the cycle, but may be delayed. For this reason, using timer function blocks to
determine the cycle time in the user program may result in inaccurate cycle times, potentially
exceeding the watchdog time.
In the third phase, the user program results are forwarded for being processed in the following
cycles and supplied to the output channels.
6.2.1 Multitasking
Multitasking refers to the capability of the HIMatrix system to process up to 32 user programs
within the processor module.
This allows the project's sub-functions to be separated from one another. The individual user
programs can be started and stopped independently from one another. SILworX displays the
states of the individual user programs on the Control Panel and allows the user to operate them.
Using multitasking, the second phase changes so that a CPU cycle performs the following
tasks:
1. Process the input data.
2. Processing of all the user programs.
3. Supplying the output data.
In the second phase, the HIMatrix can run up to 32 user programs. Two scenarios are possible
for each user program:
An entire user program cycle can be run within a single CPU cycle.
A user program cycle requires multiple CPU cycles to be completed.
These two scenarios are even possible if only one user program exists.
It is not possible to exchange global data between user programs within a single CPU cycle.
Data written by a user program is provided immediately before phase 3, but after the user
program execution has been completed. This data can thus first be used as input values at the
next start of another user program cycle.
The example in Figure 4 shows both scenarios in a project containing two user programs: Prg 1
and Prg 2.
First CPU cycle considered. Input processing in the second CPU cycle
Second CPU cycle considered. Second Prg 1 cycle considered
Input processing in the first CPU cycle Second portion of the considered Prg 2
First Prg 1 cycle considered cycle
First portion of the considered Prg 2 cycle Output processing in the second CPU
cycle
Output processing in the first CPU cycle
Each Prg 1 cycle is completely processed during each CPU cycle. Prg 1 processes an input
change registered by the system at the beginning of the CPU cycle and delivers a reaction
at the end of the cycle.
One Prg 2 cycle requires two CPU cycles to be processed. Prg 2 needs CPU cycle to
process an input change registered by the system at the beginning of CPU cycle . For this
reason, the reaction to this input change is only available at the end of CPU cycle .
The reaction time of Prg 2 is two times longer than that of Prg 1.
Upon completion of the first part of the Prg 2 cycle under consideration, Prg 2 processing is
completely aborted and only resumed when starts. During its cycle, Prg 2 processes the
data provided by the system during . The results of Prg 2 are available to the system during
(e.g., for process output). The data that the system exchanges with the user program are
always consistent.
The program execution order can be controlled by assigning a priority, which indicates how
important the corresponding user program is compared to the others (see multitasking mode 2).
To specify the user program execution order, use the following parameters in the resources and
programs or in the Multitasking Editor:
The sum of the Max. Duration for Each Cycle [µs] parameters in all user programs must not
exceed the resource watchdog time. Make sure that sufficient reserve is planned for
processing the remaining system tasks.
The sum of the Max. Duration for Each Cycle [µs] parameters in all user programs must be
large enough to ensure that sufficient reserve is available to maintain the target cycle time.
The Program IDs of all user programs must be unique.
During verification and code generation, SILworX monitors that these rules are observed. These
rules must also be observed when modifying the parameters online.
SILworX uses these parameters to calculate the user program watchdog time:
User program watchdog time = watchdog time * maximum number of cycles
The sequence control for executing the user programs is run in cycles of 250 µs. For this
i reason, the values set for Max. Duration For Each Cycle [µs] can be exceeded or under-run by
up to 250 µs.
Usually, the individual user programs operate interference-free and independently to one
another. However, reciprocal influence can be caused by:
Use of the same global variables in several user programs.
Unpredictably long runtimes can occur in individual user programs if a limit is not configured
with Max. Duration for Each Cycle [µs].
NOTE
Reciprocal influence of user programs is possible!
The use of the same global variables in several user programs can lead to a variety of
consequences caused by the reciprocal influence among the user programs.
Carefully plan the use of the same global variables in several user programs.
Use the cross-references in SILworX to check the use of global data. Global data may
only be assigned values in one location, either in a user program or from the
hardware!
HIMA recommends to set the Max. Duration for each Cycle [µs] parameter to an appropriate
i value ≠ 0. This ensures that a user program with an excessively long runtime is stopped during
the current CPU cycle and resumed in the next CPU cycle without affecting the other user
programs.
Otherwise, an unusually long runtime for one or several user programs can cause the target
cycle time, or even the resource watchdog time, to be exceeded, thus leading to an error stop
of the controller.
The operating system defines in which order the user programs are executed in accordance
with the following scheme:
User programs with lower priority are executed before user programs with higher priority.
If the user programs have the same priority, the system executes them in ascending order of
the Program IDs.
This order is also followed when starting and stopping the user program during the start and
stop of the PES, respectively.
1. Multitasking Mode 1 uses the unneeded time to reduce the CPU cycle. If the user program
is completely processed, processing of the next user program begins immediately. In total,
this results in a shorter cycle.
Example: 3 user programs (Prg 1, Prg 2 and Prg 3) that allow a user program cycle to take
up to 3 CPU cycles.
Prg 1
Prg 2
Prg 3
t
First CPU cycle considered. Max. Duration for Each Cycle [µs] of
Second CPU cycle considered. Prg 3 has expired, completion of the
second CPU cycle.
Third CPU cycle considered.
The next user program cycle of Prg 1
Max. Duration for Each Cycle [µs] of
starts.
Prg 1 has expired, Prg 2 starts.
Max. Duration for Each Cycle [µs] of
Max. Duration for Each Cycle [µs] of
Prg 1 has expired. The next user program
Prg 2 has expired, Prg 3 starts.
cycle of Prg 2 starts.
Max. Duration for Each Cycle [µs] of
Max. Duration for Each Cycle [µs] of
Prg 3 has expired, completion of the first
Prg 2 has expired, Prg 3 starts.
CPU cycle.
Completion of the Prg 3 cycle.
Completion of the Prg 1 cycle, Prg 2 is
resumed.
Completion of the Prg 2 cycle, Prg 3 is
resumed.
Prg 1 x x x
Prg 2 y y y
Prg 3 y y y
Prg 4 z z z
t
First CPU cycle considered. Prg 3 Max. Duration for Each Cycle [µs] +
Second CPU cycle considered. proportional remaining duration of Prg 1 have
expired, Prg 4 starts.
Third CPU cycle considered.
Max. Duration for Each Cycle [µs] of Prg 4 has
Max. Duration for Each Cycle [µs] of Prg 1 has
expired, completion of the first CPU cycle.
expired, Prg 2 starts.
The next user program cycle of Prg 1 starts.
Max. Duration for Each Cycle [µs] of Prg 2 has
expired, Prg 3 starts. Completion of Prg 1 Max. Duration for Each
Cycle [µs], Prg 2 resumes.
Max. Duration for Each Cycle [µs] of Prg 3 has
expired, Prg 4 starts. Completion of Prg 2 Max. Duration for Each
Cycle [µs], Prg 3 is resumed.
Max. Duration for Each Cycle [µs] of Prg 4 has
expired, completion of the first CPU cycle. Completion of the Prg 3 cycle, Prg 4 is resumed.
The remaining duration is added to Prg 4
Completion of the Prg 1 cycle, Prg 2 is resumed.
(highest priority z).
The remaining duration is distributed to the Max.
Duration for Each Cycle [µs] of Prg 2 and Prg 3 Max. Duration for Each Cycle [µs] of Prg 4+
(medium priority y) (arrows). remaining duration of Prg 3 have expired,
completion of the third CPU cycle.
Prg 2 Max. Duration for Each Cycle [µs] +
proportional remaining duration of Prg 1 have
expired, Prg 3 is resumed.
The unused execution time of user programs that were not run cannot be exploited as residual
i time by other user programs. User programs are not run if they are in one of the following
states:
STOP
ERROR
TEST_MODE
As a consequence, the number of CPU cycles required to process another user program cycle
could increase.
In such a case, if the value set for Maximum Cycle Count is too low, the maximum time
for processing a user program can be exceeded and result in an error stop!
Maximum processing time = Max. Duration for Each Cycle [µs] * Maximum Number of
Cycles
Use multitasking mode 3 to verify the parameter setting!
3. Multitasking Mode 3 does not use the unneeded duration for running the user programs,
rather, it waits until the Max. Duration for Each Cycle [µs] of the user program is reached and
then starts processing the next user program. This behavior results in CPU cycles of the
same duration.
Multitasking mode 3 allows users to verify if multitasking mode 2 ensures proper program
execution, even in the worst case scenario.
The example examines user programs named Prg 1, Prg 2 and Prg 3:
Prg 1
Prg 2
Prg 3
t
First CPU cycle considered. Completion of the Prg 2 cycle. Waiting for
Second CPU cycle considered. the remaining duration.
Third CPU cycle considered. Max. Duration for Each Cycle [µs] of
Prg 3 has expired. Completion of the
Max. Duration for Each Cycle [µs] of
second CPU cycle.
Prg 1 has expired, Prg 2 starts.
The next user program cycle of Prg 1
Max. Duration for Each Cycle [µs] of
starts.
Prg 2 has expired, Prg 3 starts.
Max. Duration for Each Cycle [µs] of
Max. Duration for Each Cycle [µs] of
Prg 1 has expired. The next user program
Prg 3 has expired, completion of the first
cycle of Prg 2 starts.
CPU cycle. Prg 1 is resumed.
Max. Duration for Each Cycle [µs] of
Completion of the Prg 1 cycle. Waiting for
Prg 2 has expired. Prg 3 is resumed.
the remaining duration.
Completion of the Prg 3 cycle. Standby
Max. Duration for Each Cycle [µs] of
time until the Prg 3 Max. Duration for
Prg 1 has expired. Prg 2 is resumed.
Each Cycle [µs] has expired. Completion
of the third CPU cycle.
In the examples illustrating the multitasking modes, input and output processing are
i represented as empty spaces at the beginning and the end of each CPU cycle.
Take the following points into account when reloading step chains:
i The reload information for step sequences does not take the current sequence status into
account. The step sequence can be accordingly changed and set to an undefined state by
performing a reload.
The user is responsible for this action.
Examples:
Deleting the active step. As a result, no step of the step chain has the active state.
Renaming the initial step while another step is active.
As a result, a step chain has two active steps!
Prior to performing a reload, the operating system checks if the required additional tasks would
increase the cycle time of the current user programs to such an extent that the defined
watchdog time is exceeded. In this case, the reload process is aborted with an error message
and the controller continues operation with the previous project configuration.
The reload can only be performed if the Reload Allowed system parameter is set to ON and the
Reload Deactivation system variable is set to OFF.
The user is responsible for ensuring that the watchdog time includes a sufficient reserve time.
i This should allow the user to manage the following situations:
Variations in the user program's cycle time
Sudden, strong cycle loads, e.g., due to communication.
Expiration of time limits during communication.
During a reload, the global and local variables should be assigned the values of the
corresponding variables from the previous project version. Names of local variables contain the
POU instance names.
This procedure has the following consequences, if names are changed and loaded into the PES
by performing a reload:
Renaming a variable has the same effect as deleting the variable and creating a new one,
i.e., it results in an initialization process. This is also the case for retain variables. The
variables lose their current value.
Renaming a function block instance results in initializing all variables, even retain variables,
and all function block instances.
Renaming a program results in initializing all contained variables and function block
instances.
This behavior may have unintended effects on one or multiple user programs and
therefore on the plant to be controlled!
Conditions for Using the Reload Function
A license is required to use the reload feature.
The following project modifications can be transferred to the controller by performing a reload:
Changes to the user program parameters.
Changes to the logic of the program, function blocks and functions.
Changes that allows a reload in accordance with Table 22.
Changes to Type of change
Add Delete Change of Assignment of
the initial other variables
value
Assigning global variables to
User programs
System variables
I/O channels
Communication protocols - - - -
safeethernet - - -
SOE - -
Communication protocols - - n.a. n.a.
User programs ** n.a. n.a.
System ID, rack ID -
IP addresses -
User accounts and licenses
Reload possible
- Reload impossible
** Reload possible, but the controller must still contain at least one user program
n.a. non-applicable
Table 22: Reloading after Changes
A reload may only be performed in accordance with the conditions mentioned in the previous
section. In all the other cases, stop the controller and perform a download.
TIP Proceed as described below to be able to perform a reload even if global variable assignments
have been added:
While creating the user program, assign unused global variables to communication
protocols.
Assign safe value as initial value to unused global variables.
To a later time point, this assignment must only be changed and not added ensuring the
possibility to perform a reload.
WARNING
Physical injury due to forced values is possible!
Only force values after receiving consent from the test authority responsible for the
final system acceptance test.
Only remove existing forcing restrictions with the consent of the test authority.
When forcing values, the person in charge must take further technical and organizational
measures to ensure that the process is sufficiently monitored in terms of safety. HIMA
recommends to setting a time limit for the forcing procedure, see below.
NOTE
Use of forced values can disrupt the safety integrity!
Forced value may lead to incorrect output values.
Forcing prolongates the cycle time. This can cause the watchdog time to be
exceeded.
Forcing is only permitted after receiving consent from the test authority responsible
for the final system acceptance test.
During a reload, local and global force values as well as forcing times and force timeout
reactions continue to be valid.
Global force values and force switches can be set when a resource is stopped. The configured
values become valid after restarting the resource and forcing.
Local force values and force switches can be set when the user program is stopped. The
configured values become valid after restarting the user program and forcing.
Absolutely take the following restrictions into account when forcing or evaluating online
i tests performed with forced global variables:
Global Variables
To force a global variable, the following conditions must be met:
The corresponding force switch is set.
Forcing was started.
If forcing was started, a change to the force switch has an immediate effect.
If forcing was started and the force switch is set, a change to the force value has an immediate
effect.
Global forced variable have the following characteristics:
Outputs and communication protocols receive the force value as long as the variable is
being forced.
The following conditions apply for a user program reading and writing the variable:
- The force value is used until the user program writes a new process value. After that
moment, the process value applies for the remaining duration of the user program cycle.
The force value applies then again in the following user program cycle.
- If the user program does not write any process value, the force value continues to be
used as the new process value, even after the end of the forcing process! The previous
process value is no longer valid.
Time Limits
A time limit can be defined for global forcing. Once the defined time has expired, the controller
stops forcing values.
It is possible to define how the HIMatrix system should behave upon expiration of the time limit:
The resource stops.
The resource continues to operate.
Local Variables
Local variable forcing is limited to the Edit Local Process Value command. This command
directly changes the value of variables without the need to set a force switch or to start forcing.
Additionally, no time limit can be configured for defining the validity of a used value.
The new process value set with this command (i.e., the force value) applies until one of the
following events occurs:
The user program overwrites the value with a new process value.
A new value is entered.
The user program is stopped.
The user program is restarted.
Force Editor
The SILworX Force Editor displays all the variables for which forcing is allowed. Global and
local variables are grouped into two specific tabs.
The tab for global variables can be used to configure the force values and set the force
switches.
The tab for local variables can be used to define the local process value.
Absolutely take the following facts into account when forcing or evaluating tests
i performed with forced global variables:
Signal force values are only valid until overwritten by the user program!
However, if the user program does not overwrite the values, e.g., if an EN input is set to
FALSE, the force value is used as a process value in the ensuing calculations.
Online test fields associated with forced signals may therefore show the forced value, even if a
value generated by the user program has already been used in the ensuing calculations or is
effective on an output.
Forcing is terminated upon expiration of the force time or when forcing is intentionally stopped.
Provided that Stop at Force Timeout is set in the resource's properties (see also message in
the info field), the controller enters the STOP state after the force time has expired and the user
program continues to run with the process values.
If Stop at Force Timeout is not set, the controller is not stopped after the force time has
expired. Forcing is deactivated and the values previously forced (R force values) are replaced
with their process values.
This may have unintentional effects on the overall system.
To manually stop forcing, click the Stop button in the Force Editor. By doing so, the controller
maintains the RUN state since the timeout has not been attained and the Stop at Force Timeout
reaction was not defined.
WARNING
Physical injury due to forced signals is possible!
Remove all force markers from the user program prior to starting safety-related
operation or before an acceptance test is performed by a test institute!
7 Start-Up
Commissioning of HIMatrix compact systems comprises the following phases:
Mounting the devices at suitable places
Take the dissipation of the generated heat into account.
Electrical connection of power supply, earthing, sensors, and actuators
Configuration
- Writing the user program
- Definition of safety, communication and other parameters
The temperature within an enclosure can also be calculated in accordance with VDE 0660, Part
507 (HD 528 S2).
All considerations about heat must take every component within a cabinet or enclosure into
i account!
NOTE
Electrostatic discharge!
Failure to comply with these instructions can damage the electronic components.
Prior to working with HIMA components, touch an earthed object.
Make sure that the workspace is free of static and wear an ESD wrist strap.
If not used, ensure that the device is protected from electrostatic discharge, e.g., by
storing it in its packaging.
7.2.1 Mounting
The location for installing the HIMatrix system must be chosen observing the operating
requirements (see Chapter 2.2) to ensure a smooth operation.
Horizontal mounting (with reference to the label on the front plate) is prescribed for all systems
to ensure proper ventilation. Vertical mounting requires additional measures to ensure sufficient
ventilation.
Refer to the relevant manuals, for more information on the dimensions of the various devices.
The minimum clearances of the HIMatrix systems among one another, to external devices and
to the control cabinet enclosure are:
Vertically, 100 mm.
Horizontally, approx. 20 mm (with the F60, determined by the joint bars).
The mounting space (construction depth) must also be taken into account for attaching the
connectors for inputs and outputs, and for communication (see Chapter 7.2.3).
To ensure efficient cooling, the device must be mounted on a horizontal DIN rail.
i A distance of at least 100 mm above and below the device must be maintained.
The device must not be mounted above heating equipment or any heat source.
100 mm DIO
20/8 01
31
20 mm
DIO
20/8 01
2
100 mm
100 mm
40 mm 40 mm
If more than two HIMatrix systems are mounted one upon the other (even if the minimum
vertical clearance of 100 mm is maintained), additional ventilation measures are required to
ensure uniform temperature distribution.
The illustration below left shows the minimum clearances if no spacers are used for the
mounting rails:
DIO
20/8 01
80 mm
31
80 mm
L- can only be earthed on one place within the system. L- is usually earthed directly behind the
power supply unit, e.g., on the busbar. The earthing should be easily accessible and well
separable. The earthing resistance must be ≤ 2 .
7.2.5.2 Earthing Connections
All HIMatrix devices have labeled screws for earthing. The wire cross-section for the connection
to the screw is 2.5 mm2. The earth wires must be as short as possible.
Provided that the DIN rail is earthed in accordance with the standard, mounting the HIMatrix
compact systems on the DIN rail already ensures a sufficient earth connection.
These measures ensure a reliable earth ground and compliance with the current EMC
requirements for HIMatrix systems.
7.2.5.3 Shielding
Sensor or actuator wires for analog inputs and outputs used in HIMatrix systems with shrouds
(F3 AIO, F35 and F60) must be laid as shielded cables. The shielding must be connected to the
HIMatrix system and the sensor or actuator housing and earthed on one end to the HIMatrix
system side to form a Faraday cage.
To earth the cable shielding, the F3 AIO 8/4 01, F35 and F60 have rails on the front that are
electrically connected to the housing potential. A clamp is used to connect the cable shielding to
the rail.
In all other devices, the shielding must be positioned in the controller housing, terminal box,
control cabinet, etc.
The shield clamp must not be used as a strain relief for the connected cable.
i
7.2.5.4 EMC Protection
Windows in the enclosure in which the HIMatrix system is installed are permitted.
Increased EMC interferences outside the standard limit values require appropriate measures.
The operating voltage is connected using a detachable four-pole connector located on the
module's front plate. The connector can accept wires of up to a maximum of 2.5 mm².
Connec- Function
tion
L+ Power supply L+ (24 VDC)
L+ Power supply L+ (24 VDC)
L- Power supply L- (24 VDC ground)
L- Power supply L- (24 VDC ground)
Table 27: Power Supply Connectors
The two clamp terminals L+/L+ and L-/L- of the device are internally bypassed and intended for
use in a two-wire supply. If the clamp terminals are connected to other devices, the maximum
current of 10 A must not be exceeded.
Check proper polarity, voltage and ripple prior to connecting the operating voltage 24 VDC.
NOTE
Damage of the device possible!
Do not exchange the terminals L+ and L-, or connect them to other terminals of the
device!
In case of a false connection, a pre-fuse blows to prevent the device from being
damaged.
Allow Online ON: All the switches/parameters listed below OFF ON OFF is
Settings can be changed online using the PADT. recommended
OFF: These parameters may These parameters may
not be changed online be changed online if
System ID Reload Allowed is set
Autostart to ON.
Global Forcing Watchdog Time (for
Allowed the resource)
Global Force Safety Time
Timeout Reaction Target Cycle Time
Load Allowed Target Cycle Time
Reload Allowed Mode
Start Allowed If Reload Allowed is set
to OFF, they are not
changeable online.
Allow Online Settings can only be set to ON if
i the PES is stopped.
Autostart ON: If the processor module is connected to the OFF Application-
supply voltage, the user program starts specific
automatically
OFF: The user program does not start automatically
after connecting the supply voltage.
Start Allowed ON: A cold start or warm start permitted with the ON Application-
PADT in RUN or STOP specific
OFF: Start not allowed
Load Allowed ON: Configuration download is allowed ON Application-
OFF: Configuration download is not allowed specific
Reload Allowed Only applicable with F*03 devices/modules! ON Application-
ON: Configuration reload is allowed specific
OFF: Configuration reload is not allowed.
A running reload process is not aborted when
switching to OFF
Global Forcing ON: Global forcing permitted for this resource ON Application-
Allowed OFF: Global forcing not permitted for this resource specific
Global Force Specifies how the resource should behave when the global Stop Application-
Timeout Reaction force timeout has expired: Forcing specific
Stop Forcing
Stop the Resource
Minimum With this setting, code compatible to previous or newer SILworX Application-
Configuration CPU operating system versions in accordance with the V5 with specific
Version project requirements may be generated. new
SILworX The code is generated as in SILworX V2. With projects
V2 this setting, the use of the code on standard
devices and modules is supported for CPU
operating system V7.
SILworX Not applicable for HIMatrix controllers!
V3
SILworX The generated code is compatible to the CPU
V4 operating system V8.
SILworX Corresponds to SILworX V4. This setting
V5 ensures the compatibility with future versions.
safeethernet CRC SILworX The CRC for safeethernet is created as in Current Application-
V2.36.0 SILworX V2.36.0. This setting is required for Version specific
exchanging data with resources planned with
SILworX V2.36 or previous versions.
The following table describes the effect of Target Cycle Time Mode.
Target Cycle Effect on user programs Effect on reload of processor modules
Time Mode
Fixed The PES maintains the target cycle time Reload is not processed if the target cycle
and extends the cycle if necessary. If the time is not sufficient.
processing time of the user programs
exceeds the target cycle time, the cycle
duration is increased.
Fixed-tolerant The same as Fixed. At most, the duration of every fourth cycle
is increased to allow reload.
Dynamic- The same as Dynamic. At most, the duration of every fourth cycle
tolerant is increased to allow reload.
Dynamic HIMatrix maintains the target cycle time as Reload is not processed if the target cycle
well as possible and also executes the time is not sufficient.
cycle as quickly as possible.
Table 29: Effect of Target Cycle Time Mode
For help, compare the details provided by the version comparator with the module data
overview.
If a Minimum Configuration Version of SILworX V4 or higher is set for a resource, the Code
Generation Compatibility parameter must be set to SILworX V4 in every user program (see
below).
Global variables can be connected to these system variables; the value of the global variables is
modified using a physical input or the user program logic.
Table 34: System Parameters of the User Program - CPU OS V7 and Higher
3. Assign the global variable to the channel value -> Value [INT] of the input.
4. In the user program, define a global variable of the type needed.
5. In the user program, program a suitable conversion function to convert the raw value into a
used type and consider the measurement range.
6. In the user program, program a safety-related fault reaction using the error code -> Error
Code [Byte].
The user program can process the measuring in a safety-related manner.
If the value 0 for a channel is within the valid measuring range, the user program must, at a
minimum, evaluate the parameter Error Code [Byte] in addition to the process value.
To get additional options for programming fault reactions in the user program, assign global
variable to AI.Error Code and Module Error Code. For more information on the error codes, refer
to the manual of the corresponding compact system or module.
Use of Safety-Related Counter Inputs
The counter reading or the rotation speed/frequency can be used as an integer value or as a
scaled floating-point value.
In the following sections, xx refers to the corresponding channel number.
To get additional options for programming fault reactions in the user program, assign global
variable to AO.Error Code and Module Error Code. Refer to the manual of the compact system
or module for more details.
The signal can be named freely; the names used in this manual are examples. All parameters
have the Const attribute.
The following table specifies the switch variables used in the example:
Name Type Description Remark
S1_1_pulsed BOOL Value First and second contact of
S1_2_pulsed BOOL Value switch 1
S2_1_pulsed BOOL Value First and second contact of
S2_2_pulsed BOOL Value switch 2
FC_S1_1_pulsed BYTE Error code Error codes for first and second
FC_S1_2_pulsed BYTE Error code contact of switch 1
FC_S2_1_pulsed BYTE Error code Error codes for first and second
FC_S2_2_pulsed BYTE Error code contact of switch 2
Table 36: Switch Variables for Line Control
The following table specifies the slot numbers of modules with pulsed outputs when compact
devices are used.
Device DI Pulse Slot system parameter
F1 DI 16 01 1
F3 DIO 8/8 01 3
F3 DIO 16/8 01 3
F3 DIO 20/8 02 2
F20 3
F30 3
F31 3
Table 37: Module Slot with Pulsed Outputs
If the modular F60 system is used, the number of the slot in which the module with pulsed
outputs is inserted, must be used (3…8).
7.3.5.2 Configuring Pulsed Outputs
The pulsed outputs must begin in SILworX with channel 1 and reside in direct sequence, one
after the other.
SILworX Examples of permitted configurations ... ... of not permitted
Value [BOOL] ->
Channel no. 1 A1 Pulse_ON Pulse_ON Pulse_ON A1 Pulse_ON
Channel no. 2 A2 Pulse_ON Pulse_ON Pulse_ON Pulse_ON Pulse_ON
Channel no. 3 A3 Pulse_ON Pulse_ON Pulse_ON Pulse_ON A3
Channel no. 4 A4 A4 Pulse_ON Pulse_ON Pulse_ON Pulse_ON
Channel no. 5 A5 A5 A5 Pulse_ON Pulse_ON Pulse_ON
Channel no. 6 A6 A6 A6 Pulse_ON A6 Pulse_ON
Channel no. 7 A7 A7 A7 A7 A7 A7
Channel no. 8 A8 A8 A8 A8 A8 A8
Table 38: Configuration of Pulsed Outputs
The corresponding inputs can be freely selected, i.e., two consecutive pulsed outputs need not
be assigned to two adjacent inputs.
Restriction:
Two adjacent inputs may not be supplied from the same pulse to prevent crosstalk.
7.3.5.3 Configuration Example with SILworX
Fundamental Method for Assigning Variables
In SILworX, the global variables previously created in the Global Variable Editor are assigned to
the individual hardware channels.
Digital inputs (pulsed channels) may be arbitrarily connected to the pulsed outputs depending
on the hardware configuration.
Connecting the Variables to the Inputs and Corresponding Error Codes
Each input channel value -> Value [BOOL] contained in the DIxx: Channels tab located in the
input module's Detail View is allocated the corresponding error code -> Error Code [BYTE]. The
error code must be evaluated in the user program.
The following table shows the connection of the system variables in the input module's Detail
View to global variables:
System variable Global Variable
-> Value [BOOL] of the corresponding S1_1_Pulsed…S2_2_Pulsed (one variable for each
channel channel)
-> Error Code [BYTE] of the FC_S1_1_Pulsed…FC_S2_2_Pulsed (one variable
corresponding channel for each channel)
Table 40: Connection of the Global Variables to Input System Variables of the Input Module
NOTE
Failures during the code generation may occur due to the non-safe PC!
For safety-related applications, the code generator must generate the code two times
and the checksums (CRCs) resulting from the two code generations must be identical.
Only if this is the case, an error-free code is ensured.
Refer to the safety manual (HI 800 023 E) for further details.
Use <Ctrl>+A in the System Login dialog box to skip steps 4-6!
To load a resource configuration from the flash memory of the communication system
1. Log in to the required resource.
2. In the Online menu, select Maintenance/Service -> Load Configuration from Flash.
3. A dialog box appears. Confirm the action.
The controller loads the resource configuration from the flash memory for the communication
system into the NVRAM.
The user management scheme allocates the rights to the user groups. The user groups allocate
the rights to the user accounts assigned to them.
Characteristics of user groups:
The name must be unique within the project and must contain 1...31 characters.
A user group is assigned an authorization type.
A user group may be assigned an arbitrary number of user accounts.
A project may contain up to 100 user groups.
Note that the default settings cannot be maintained if new user accounts are defined.
i
SILworX represents the processor system and the communication system within a device or
i module as processor module and communication module.
For HIMatrix systems, set the Speed Mode [Mbit/s] and Flow Control Mode to Autoneg in the
Ethernet switch settings.
The parameters ARP Aging Time, MAC Learning, IP Forwarding, Speed [Mbit/s] and Flow
Control are explained in details in the SILworX online help.
The port settings of the integrated Ethernet switch on a HIMatrix resource can be configured
individually. In the Ethernet Switch tab, an entry can be created for each switch port.
In F*03 controllers, VLAN is available and allows one to configure the connection of the ports to
CPU, COM and one another. VLAN is important for proper configuration of redundant
safeethernet.
Name Explanation
Port Port number as printed on the housing; per port, only one
configuration may exist.
Range of values: 1...n, depending on the resource
Speed [Mbit/s] 10 Mbit/s: Data rate 10 Mbit/s
100 Mbit/s: Data rate 100 Mbit/s
Autoneg (10/100): Automatic baud rate setting
Standard: Autoneg
Flow Control Full duplex: Simultaneous communication in both directions
Half duplex: Communication in both directions, but only one
direction at a time
Autoneg: Automatic communication control
Standard: Autoneg
Autoneg also with fixed The Advertising function (forwarding the Speed and Flow Control
values properties) is also performed if Speed and Flow Control have
fixed values.
This allows other devices with ports set to Autoneg to recognize
the HIMatrix ports' settings.
Limit Limit the inbound multicast and/or broadcast packets.
Off: No limitation
Broadcast: Limit broadcast packets (128 kbit/s)
Multicast and Broadcast: Limit multicast and broadcast packets
(1024 kbit/s)
Default: Broadcast
Table 43: Port Configuration Parameters - CPU OS and Higher
To modify and enter these parameters in the communication system's configuration, double-
click each table cell. The parameters become operative for HIMatrix communication, once they
have been re-compiled with the user program and transferred to the controller.
The properties of the communication system and Ethernet switch can also be changed online
using the Control Panel. These settings become operative immediately, but they are not
adopted by the user program.
Refer to the SILworX communication manual (HI 801 101 E) for more details about configuring
safeethernet.
The parameters of the scalar events must be entered in a table with the following columns:
Column Description Range of values
Name Name for the event definition; it must be unique within the Text, max. 32
resource. characters
Global Variable Name of the assigned global variable (added using a drag&drop
operation)
Data Type Data type of the global variable; it cannot be modified. Depending on the
global variable type
Event Source CPU event The processor module creates the timestamp. It CPU, Auto
creates all the events in each of its cycles.
Auto event As CPU event
Default value: Auto Event
HH Alarm Text Text specifying the alarm state of the highest limit (HH). Text
HH Alarm Value Highest limit (HH) triggering an event. Condition: Depending on the
(HH Alarm Value - Hysteresis) > H Alarm Value or HH Alarm global variable type
Value = H Alarm Value
HH Alarm Priority Priority of the highest limit (HH); default value: 500 0...1000
HH Alarm Activated The user must confirm that the highest limit (HH) has Checkbox activated,
Acknowledgment been exceeded (acknowledgment). deactivated
Required Deactivated The user may not confirm that the highest limit (HH)
has been exceeded.
Default value: Deactivated
H Alarm Text Text specifying the alarm state of the high limit (H). Text
H Alarm Value High limit (H) triggering an event. Condition: Depending on the
(H Alarm Value - Hysteresis) > (L Alarm Value + Hysteresis) or H global variable type
Alarm Value = L Alarm Value
H Alarm Priority Priority of the high limit (H); default value: 500 0...1000
H Alarm Activated The user must confirm that the high limit (H) has Checkbox activated,
Acknowledgment been exceeded (acknowledgment). deactivated
Required Deactivated The user may not confirm that the high limit (H) has
been exceeded.
Default value: Deactivated
Return to Normal Text specifying the normal state Text
Text
Return to Normal Priority of the normal state; default value: 500 0...1000
Severity
Return to Normal The normal state must be confirmed by the user Checkbox activated,
Ack Required (acknowledgement); default value: Deactivated deactivated
L Alarm Text Text specifying the alarm state of the low limit (L). Text
L Alarm Value Low limit (L) triggering an event. Condition: Depending on the
(L Alarm Value + Hysteresis) < (H Alarm Value - Hysteresis) or L global variable type
Alarm Value = H Alarm Value
L Alarm Priority Priority of low limit (L); default value: 500 0...1000
L Alarm Activated The user must confirm that the low limit (L) has been Checkbox activated,
Acknowledgment exceeded (acknowledgment). deactivated
Required Deactivated The user may not confirm that the low limit (L) has
been exceeded.
Default value: Deactivated
LL Alarm Text Text specifying the alarm state of the lowest limit (LL). Text
LL Alarm Value Lowest limit (LL) triggering an event. Condition: Depending on the
(LL Alarm Value + Hysteresis) < (L Alarm Value) or global variable type
LL Alarm Value = L Alarm Value
LL Alarm Priority Priority of the lowest limit (LL); default value: 500 0...1000
NOTE
Faulty event recording due to improper parameter settings possible!
Setting the parameters L Alarm Value and H Alarm Value to the same value can cause an
unexpected behavior of the event recording since no normal range exists in such a case.
For this reason, make sure that L Alarm Value and H Alarm Value are set to different
values.
Refer to the HIMatrix system safety manual (HI 800 023 E) for more details on how to configure
a resource for safety-related operation.
The following table specifies the parameters for configuring the user program:
Parameter Range Description Default
value
Execution 0 ms For future applications in which a resource is able 0 ms
Time to process multiple program instances
simultaneously.
It determines the maximum cycle time portion that
must not be exceeded by the program instance. If
this time portion is exceeded, the program enters
the STOP state.
Note: Maintain the default setting 0 (no special
cycle time monitoring).
Autostart Off, Cold Start, The user program starts automatically after Cold Start
Enable Warm Start powering on
Memory model SMALL, BIG Structure of the resource memory required and SMALL
expected for performing a code generation.
SMALL Compatibility with previous controller
versions is ensured.
BIG Compatibility with future controller
versions.
Table 48: User program Parameters - up to CPU OS V7
The parameters specified above can be accessed via the ELOP II Factory Hardware
Management.
The signal can be named freely; the names used in this manual are examples. All signals have
the Const attribute.
The following table specifies the switch signals used in the example:
Name Type Description Remark
S1_1_pulsed BOOL Value First and second contact of
S1_2_pulsed BOOL Value switch 1
S2_1_pulsed BOOL Value First and second contact of
S2_2_pulsed BOOL Value switch 2
FC_S1_1_pulsed BYTE Error code Error codes for first and second
FC_S1_2_pulsed BYTE Error code contact of switch 1
FC_S2_1_pulsed BYTE Error code Error codes for first and second
FC_S2_2_pulsed BYTE Error code contact of switch 2
Table 50: Switch Signals for Line Control
The following table specifies the slot numbers of modules with pulsed outputs when compact
devices are used.
Device System signal DI Pulse Slot.
F1 DI 16 01 1
F3 DIO 8/8 01 3
F3 DIO 16/8 01 3
F3 DIO 20/8 02 2
F20 2
F30 2
F31 2
Table 51: Module Slot with Pulsed Outputs
If the modular F60 system is used, the number of the slot in which the module with pulsed
outputs is inserted, must be used (3…8).
7.7.4.2 Configuring Pulsed Outputs
The pulsed outputs must begin with DO[01].Value and reside in direct sequence, one after the
other:
The corresponding inputs can be freely selected, i.e., two consecutive pulsed outputs need not
be assigned to two adjacent inputs.
Restriction:
Two adjacent inputs may not be supplied from the same pulse to prevent crosstalk.
7.7.4.3 Configuration Example with ELOP II Factory
Basic Method for Assigning Signals
If ELOP II Factory is used, the signals previously defined in the Signal Editor (Hardware
Management) are assigned to the individual hardware channels (inputs and outputs).
Digital inputs (pulsed channels) may be arbitrarily connected to the pulsed outputs depending
on the hardware configuration.
Connecting the Signals to the Inputs and Corresponding Error Codes
For each useful signal DI[xx].Value, the relevant error code must also be evaluated
The following table shows the signals to be connected for each of the input channels to be
monitored:
System signals Signals
DI[xx].Value of the corresponding channel S1_1_pulsed…S2_2_pulsed (one of the signals
xx per channel)
DI[xx].Error Code of the corresponding FC_S1_1_pulsed…FC_S2_2_pulsed (one of the
channel xx signals per channel)
Table 54: Connecting Signals to the Input Module's Input Signals
NOTE
Failures during the code generation may occur due to the non-safe PC!
For safety-related applications, the code generator must generate the code two times
and the checksums (CRCs) resulting from the two code generations must be identical.
Only if this is the case, an error-free code is ensured.
Refer to the safety manual (HI 800 023 E) for further details.
4. Enter the MAC address valid for the controller in the MAC Address input box and click Set
via MAC.
The connection parameters and the system/rack ID configured in the project are set.
For further details, refer to the ELOP II Factory manual First Steps (HI 800 006 E).
6. Upon completion of the loading process, click the Resource Cold Start button to start
the user program.
After a cold start, CPU State, COM State and Program State are set to RUN.
The resource configuration is loaded from the PADT.
The functions Start, Stop and Load can also be performed using the Resource menu.
The controller's mode of operation 'STOP' is divided as follows:
Mode of Operation Meaning with remote I/Os Meaning with controllers
STOP/LOAD A configuration can be A configuration with user program can
CONFIGURATION loaded into the remote I/O. be loaded into the controller.
STOP/VALID The configuration was loaded The configuration with user program
CONFIGURATION into the remote I/O properly. was loaded into the controller
properly.
A command from the PADT can set
the controller into the RUN state. This
causes a loaded user program to
start.
STOP/INVALID No configuration available or the loaded configuration is corrupted.
CONFIGURATION In this mode of operation, the
controller is not able to enter the RUN
state.
Table 55: Sub-States Associated with STOP - up to CPU OS V7
Loading a new configuration with or without user program automatically overwrites all objects
previously loaded.
To load a resource configuration from the flash memory of the communication system
1. Move to the ELOP II Factory Hardware Management to load the resource configuration.
2. Select and right click the required resource.
3. Select Online -> Control Panel to open the Control Panel.
4. To restore the configuration and user program from the flash memory of the communication
system, click the Extra -> Load Resource Configuration from Flash menu function. The
user program is thus transferred from the flash memory of the user program into the working
memory of the processor system and the configuration into the NVRAM.
The resource configuration is thus restored.
To delete a resource configuration from the flash memory of the communication system
1. In ELOP II Factory Hardware Management, select and right click the required resource.
2. Select Online -> Control Panel from the context menu. The Control Panel appears.
3. Select Extra -> Delete Resource Configuration to remove the configuration and user
program from the flash memory of the communication systems.
Deleting the configuration has the following effects:
The controller adopts the STOP/INVALID CONFIGURATION state.
The access to the user program in the working memory of the processor system is inhibited
in this state.
System ID, IP address and user management still exist in the NVRAM of the processor
system such that a connection to the PADT can still be established.
Upon deletion, the controller can immediately be loaded with a new program. This action
deletes the previous program from the working memory of the processor system.
Refer to the ELOP II Factory manual First Steps (HI 800 006 E) for further details about
communication between PADT and controller.
External devices that should communicate with HIMatrix controllers must have the following
network settings:
Parameter Alternative 1 Alternative 2 Alternative 3 Alternative 4
Speed Mode Autoneg Autoneg 10 Mbit/s 100 Mbit/s
Flow Control Mode Autoneg Half Duplex Half Duplex Half Duplex
Table 56: Permissible Communication Settings for External Devices - CPU OS up to V7
COM OS V8.32 and Higher and ELOP II Hardware Management V7.56.10 and Higher:
The operating parameters of each Ethernet port on the integrated Ethernet switch can be set
individually.
For HIMatrix controllers and remote I/Os with extended settings, set the Speed Mode and Flow
Control Mode to Autoneg. To ensure that the parameters of this dialog box become effective,
the option Activate Extended Settings must be selected, see Figure 11.
The parameters ARP, MAC Learning, IP Forwarding, Speed Mode and Flow Control Mode are
explained in details in the ELOP II Factory online help.
The port settings of the integrated Ethernet switch on a HIMatrix resource can be configured
individually starting with the following versions.
V8.32 of the communication operating system and
V7.56.10 of ELOP II Hardware Management
Select Ethernet Switch -> New -> Port Configuration to define the configuration parameters
for each switch port.
Name Explanation
Port Port number as printed on the housing; per port, only one
configuration may exist.
Range of values: 1...n, depending on the resource
Speed [Mbit/s] 10 Mbit/s: Data rate 10 Mbit/s
100 Mbit/s: Data rate 100 Mbit/s
Autoneg (10/100): Automatic baud rate setting
Standard: Autoneg
Flow Control Full duplex: Simultaneous communication in both directions
Half duplex: Communication in both directions, but only one
direction at a time
Autoneg: Automatic communication control
Standard: Autoneg
Autoneg also with fixed The Advertising function (forwarding the Speed and Flow Control
values properties) is also performed if Speed and Flow Control have fixed
values.
This allows other devices with ports set to Autoneg to recognize
the HIMatrix ports' settings.
Limit Limit the inbound multicast and/or broadcast packets.
Off: No limitation
Broadcast: Limit broadcast packets (128 kbit/s)
Multicast and Broadcast: Limit multicast and broadcast packets
(1024 kbit/s)
Default: Broadcast
Table 58: Parameters of a Port Configuration - CPU OS up to V7
Click Apply to adopt the parameters in the communication system's configuration. The
parameters set in the properties of the communication system and Ethernet switch
(configuration) become operative for the HIMatrix communication, once they have been re-
compiled with the user program and transferred to the controller.
The properties of the communication system and Ethernet switch can also be changed online
using the Control Panel. These settings become operative immediately, but they are not
adopted by the user program.
The following commands can be used for the Connection Control signal:
Command Description
AUTOCONNECT After a peer-to-peer communication loss, the controller attempts to
reestablish communication in the following cycle. This is the default
setting.
TOGGLE_MODE_0 After a communication loss, the user program can re-establish the
TOGGLE_MODE_1 connection by changing the TOGGLE MODE.
If TOGGLE MODE 0 is active and the communication is lost
(Connection State = CLOSED), a reconnection is only attempted after
the user program switched the TOGGLE MODE to TOGGLE MODE_1.
If TOGGLE MODE 1 is active and the communication is lost, a
reconnection is only attempted after the user program switched the
TOGGLE MODE to TOGGLE MODE_0.
DISABLED Peer-to-peer communication is off
No attempt made to establish the connection
Table 61: The Connection Control Parameter - CPU OS up to V7
4. The system parameters Receive Timeout, Response Time, Connection State and Version
can be evaluated in the user program based on the signal assignment performed in the
Signal Editor.
The status signals can be evaluated in the user program.
Figure 15: Connection Control System Signal in the Outputs Tab - CPU OS up to V7
The user program can set the Connection Control system signal.
The parameters specified above determine the data throughput and the fault and collision
tolerance of the safeethernet connection.
Refer to the HIMatrix Safety manual (HI 800 023 E), Chapter Configuring Communication, for
details on how to calculate the ReceiveTMO, Response Time and Worst Case Reaction Time.
Profile
Due to the high number of parameters, the manual network configuration is very complex and
requires a thorough knowledge of the parameters and their mutual influence.
To simplify the parameter settings, six peer-to-peer profiles are available, among which the user
can select the most suitable for his application and network.
The profiles are combinations of parameters compatible with one another that are automatically
set when selecting the profile.
Profiles I through VI are described in details in the ELOP II Factory Hardware Management
online help.
By sending a signal value from a controller to another controller (PES1 -> PES2), the value is
i available in the second controller PES2. To be able to use the value, use the same signals in the
PES1 and PES2 logic.
7. Select the other tab in the P2P Process Signals window to switch the direction of the data
exchange and define the signals for the other transfer direction.
The program can only be started if the Start/Restart Allowed switch was activated.
i
7.9.3 Restarting the Program after Errors
If the program enters the STOP/INVALID CONFIGURATION state, e.g., due to unauthorized
access to operating system areas, it restarts. If the user program enters the STOP/INVALID
CONFIGURATION state again within roughly one minute since the restart, it remains in this
state. If this is the case, it can be restarted using the Control Panel's start button. After a restart,
the operating system checks the entire program.
WARNING
Property damage or physical injury possible due to actuators in unsafe state!
Do not use the test mode function during safety-related operation!
8 Operation
This chapter describes how to handle and diagnose the controller during its operation.
8.1 Handling
The controller needs not be handled during its normal operation. Only if problems arise, an
intervention with the PADT may be required.
8.2 Diagnosis
A first, rough diagnosis can be performed via the light-emitting diodes (LEDs). The diagnostic
history that can be displayed using the PADT provides a more detailed analysis of the operating
or error state.
CPU COM
Number of entries in the long term 300 230
diagnosis
Number of entries in the short term 210 655
diagnosis
Table 64: Maximum Number of Entries in the Diagnostic History - up to CPU OS V7
CPU COM
Number of entries in the long term 500 200/2501)
diagnosis
Number of entries in the short term 300 700/8001)
diagnosis
1)
Higher value for COM operating system version 4 and higher
Table 65: Maximum Number of Entries in the Diagnostic History - up to CPU OS V7
The long-term diagnosis of the processor system includes the following events:
Reboot
Changed mode of operation
(INIT, RUN, STOP/VALID CONFIGURATION, STOP/INVALID CONFIGURATION),
Changed program mode of operation
(START, RUN, ERROR, TEST MODE),
Configuration load or deletion
Configuration and reset of switches
Processor system failures
Operating system download
Forcing (setting and resetting the force switch is allowed)
I/O module diagnostics
Power supply and temperature diagnostics
The long-term diagnosis of the communication system includes the following events:
Reboot of the communication system
Changed mode of operation
(INIT, RUN, STOP/VALID CONFIGURATION, STOP/INVALID CONFIGURATION),
User log-in
Operating system load
If the memory for the long term diagnosis is full, all data older than three days is deleted
allowing new entries to be stored. If no data is older than three days, the new entries cannot be
stored and get lost. A message in the long-term diagnosis warns that it was not possible to store
the data.
The short-term diagnosis of the processor system includes the following events:
Processor system diagnostics (setting the force switches and force values)
User program diagnostics (cyclic operation)
Communication diagnostics
Power supply and temperature diagnostics
I/O module diagnostics
The short-term diagnosis of the communication system includes the following events:
safeethernet-related events
Start / stop while writing to the flash memory
Faults that can occur while loading a configuration from the flash memory
Unsuccessful time synchronization between the communication system and the processor
system
Parameter errors associated with the inputs or outputs are possibly not detected during the
code generation. If a parameter error occurs, the message INVALID CONFIG with the error
source and code are displayed in the feedback box for the diagnosis. This message helps
analyzing errors due to an incorrect configuration of the inputs or outputs.
If the memory for the short-term diagnosis is full, the oldest entries are deleted to allow new
data to be saved. No message appears warning that old entries are being deleted.
Diagnostic data recording is not safety-related. To read the data recorded in chronological
order, use the programming tool. Reading does not delete the data stored in the controller. The
programming tool is capable of storing the contents of the diagnostic window.
9 Maintenance
The maintenance of HIMatrix systems is restricted to the following:
Removing disturbances
Loading Operating Systems
9.1 Interferences
Disturbances in the processor system (CPU) mostly result in the complete shut-down of the
controller and are indicated via the ERROR LED.
Refer to the device-specific manual for the possible causes for activated ERROR indicators.
To turn off the indicator, start the Reboot Resource command located in the Extra menu
associated with the Control Panel. The controller is booted and re-started.
The system automatically detects disturbances in the input and output channels during
operation and displays them via the FAULT LED on the device's front plate.
Even if the controller is stopped, the PADT diagnostic history can be used to read out detected
faults, provided that communication was not disturbed as well.
Prior to replacing an I/O module, check whether an external line disturbance exists and whether
the corresponding sensor or actuator is ok.
NOTE
Disruption of the safety-related operation!
The controller must be in the STOP state to enable the programming tool to load new
operating systems.
During this time period, the operator must ensure the plant safety, e.g., by taking
organizational measures.
The programming tool prevents controllers from loading the operating systems in the RUN
i state and reports this as such.
Interruption or incorrect termination of the loading process has the effect that the controller
is no longer functional. However, it is possible to reload operating system.
The operating system for the processor system (processor operating system) must be loaded
before that for the communication system (communication operating system).
Operating systems for controllers differ from those for remote I/Os.
To be able to load a new operating system, it must be stored in a directory that can be accessed
by the programming tool.
9.2.3 Switching between ELOP II Factory and SILworX - not with F*03
HIMatrix controllers (except for F*03 devices and modules) can either be programmed with
ELOP II Factory or with SILworX, if the appropriate version for the operating system is installed.
The combinations of programming tool and operating system version are specified in the table.
Operating System Version for ELOP II Factory Version for SILworX
Processor system Up to V7 V7 and higher
Communication system Up to V12 V12 and higher
OS loader Up to V7 V7 and higher
Table 66: Operating System Versions and Programming Tools
HIMatrix controllers that can be programmed with SILworX, are only compatible with remote
i I/Os that can also be programmed with SILworX. For this reason, also ensure that the
appropriate remote I/O is used.
For F60 systems, no upgrade other than that of the processor module is required. The
operating system of the processor module determines the programming tool.
The user program cannot be converted from ELOP II Factory to SILworX and vice-versa.
Please contact HIMA service if it is not clear whether a given controller or remote I/O may
be upgraded.
F*03 controllers with CPU operating system V8 and higher cannot be changed to be
i programmed with ELOP II!
10 Decommissioning
Remove the supply voltage to decommission the device. Afterwards it is possible to pull out the
pluggable screw terminal connector blocks for inputs and outputs and the Ethernet cables.
11 Transport
To avoid mechanical damage, HIMatrix components must be transported in packaging.
Always store HIMatrix components in their original product packaging. This packaging also
provides protection against electrostatic discharge. Note that the product packaging alone is not
suitable for transport.
12 Disposal
Industrial customers are responsible for correctly disposing of decommissioned HIMatrix
hardware. Upon request, a disposal agreement can be arranged with HIMA.
All materials must be disposed of in an ecologically sound manner.
Appendix
Glossary
Term Description
ARP Address resolution protocol: Network protocol for assigning the network addresses to
hardware addresses
AI Analog input
AO Analog output
COM Communication module
CRC Cyclic redundancy check
DI Digital input
DO Digital output
ELOP II Factory Programming tool for HIMatrix systems
EMC Electromagnetic compatibility
EN European norm
ESD Electrostatic discharge
FB Fieldbus
FBD Function block diagrams
FTT Fault tolerance time
ICMP Internet control message protocol: Network protocol for status or error messages
IEC International electrotechnical commission
MAC Address Media access control address: Hardware address of one network connection
PADT Programming and debugging tool (in accordance with IEC 61131-3),
PC with SILworX or ELOP II Factory
PE Protective earth
PELV Protective extra low voltage
PES Programmable electronic system
R Read: The system variable or signal provides value, e.g., to the user program
Rack ID Base plate identification (number)
Interference-free Supposing that two input circuits are connected to the same source (e.g., a
transmitter). An input circuit is termed interference-free if it does not distort the signals
of the other input circuit.
R/W Read/Write (column title for system variable/signal type)
SELV Safety extra low voltage
SFF Safe failure fraction, portion of faults that can be safely controlled
SIL Safety integrity level (in accordance with IEC 61508)
SILworX Programming tool for HIMatrix systems
SNTP Simple network time protocol (RFC 1769)
S.R.S System.Rack.Slot addressing of a module
SW Software
TMO Timeout
W Write: System variable/signal is provided with value, e.g., from the user program
rPP Peak-to-peak value of a total AC component
Watchdog (WD) Time monitoring for modules or programs. If the watchdog time is exceeded, the
module or program enters the ERROR STOP state.
WDT Watchdog time
Index of Figures
Figure 1: Line Control 16
Figure 2: Pulsed Signals T1 and T2 16
Figure 3: safeethernet/Ethernet Networking Example 22
Figure 4: CPU Cycle Sequence with Multitasking 31
Figure 5: Multitasking Mode 1 34
Figure 6: Multitasking Mode 2 35
Figure 7: Multitasking Mode 3 36
Figure 8: Minimum Clearances with HIMatrix Compact Systems 47
Figure 9: Use of Cable Ducts and Spacers 48
Figure 10: Mounting without Spacers and Vertical Mounting 49
Figure 11: Communication System Properties - CPU OS up to V7 85
Figure 12: Creating a Port Configuration - CPU OS up to V7 86
Figure 13: Parameters of a Port Configuration - CPU OS up to V7 86
Figure 14: Peer-to-Peer Parameters in the Inputs Tab - CPU OS up to V7 88
Figure 15: Connection Control System Signal in the Outputs Tab - CPU OS up to V7 89
Figure 16: Setting the Parameters in the P2P Editor - up to CPU OS V7 89
Figure 17: Assigning Process Signals per Drag&Drop - CPU OS up to V7 90
Figure 18: Example of Process Signals - CPU OS up to V7 91
Index of Tables
Table 1: HIMatrix System Variants 8
Table 2: Additional Relevant Documents 8
Table 3: Environmental Requirements 12
Table 4: Standards for EMC, Climatic and Environmental Requirements 12
Table 5: General Requirements 12
Table 6: Climatic Requirements 13
Table 7: Mechanical Tests 13
Table 8: Interference Immunity Tests 13
Table 9: Noise Emission Tests 14
Table 10: Verification of the DC Supply Characteristics 14
Table 11: Supply Voltage 17
Table 12: Operating Voltage Monitoring 18
Table 13: Temperature Monitoring 18
Table 14: Specifications 20
Table 15: Connection of Controllers and Remote I/Os with Different Operating Systems 23
Table 16: Equipment of Fieldbus Interfaces with Fieldbus Submodules 25
Table 17: Fieldbus Submodule 25
Table 18: Functions of the Processor Operating System 27
Table 19: Modes of Operation for the Processor System 29
Table 20: User Program Modes of Operation 30
Table 21: Parameters Configurable for Multitasking 32
Table 22: Reloading after Changes 38
Table 23: Effect of the Force Deactivation System Variable 42
Table 24: Force Switches and Parameters up to CPU OS V7 43
Table 25: Installation Type 44
Table 26: Construction Depths 50
Table 27: Power Supply Connectors 51
Table 28: System Parameters of the Resource - CPU OS V7 and Higher 54
Table 29: Effect of Target Cycle Time Mode 54
Table 30: System Parameters of the Remote I/O - CPU OS V7 and Higher 55
Table 31: Hardware System Variables - CPU OS V7 and Higher 56
Table 32: Hardware System Variables for Reading the Parameters 59
Table 33: System Parameters of the Rack 59
Table 34: System Parameters of the User Program - CPU OS V7 and Higher 61
Table 35: Parameters for Line Control 63
Table 36: Switch Variables for Line Control 63
Table 37: Module Slot with Pulsed Outputs 64
Table 38: Configuration of Pulsed Outputs 64
Table 39: Connection of the Global Variables to Output System Variables of the Input Module 65
Table 40: Connection of the Global Variables to Input System Variables of the Input Module 65
Table 41: Authorization Types for the PADT User Management Scheme 68
Table 42: Parameters for User Accounts in the PES User Management Scheme 70
Table 43: Port Configuration Parameters - CPU OS and Higher 72
Table 44: Parameters for Boolean Events 73
Table 45: Parameters for Scalar Events 75
Table 46: Resource Configuration Parameters - CPU OS up to V7 76
Table 47: General System Signals and Parameters - CPU OS up to V7 77
Table 48: User program Parameters - up to CPU OS V7 77
Table 49: Signals for Line Control 79
Table 50: Switch Signals for Line Control 79
Table 51: Module Slot with Pulsed Outputs 79
Table 52: Configuration of Pulsed Outputs in ELOP II Factory 80
Table 53: Connecting Signals to the Input Module's Output Signals 80
Table 54: Connecting Signals to the Input Module's Input Signals 81
Table 55: Sub-States Associated with STOP - up to CPU OS V7 83
Table 56: Permissible Communication Settings for External Devices - CPU OS up to V7 85
Table 57: Impermissible Communication Settings for External Devices - CPU OS up to V7 85
Table 58: Parameters of a Port Configuration - CPU OS up to V7 86
Table 59: System Signals of a safeethernet Connection for Reading the Status - CPU OS up to V787
Table 60: System Signal of a safeethernet Connection for Setting the Connection Control - CPU OS
up to V7 87
Table 61: The Connection Control Parameter - CPU OS up to V7 88
Table 62: Manuals Describing the Communication LEDs 93
Table 63: Maximum Number of Entries in the Diagnostic History for F*03 93
Table 64: Maximum Number of Entries in the Diagnostic History - up to CPU OS V7 93
Table 65: Maximum Number of Entries in the Diagnostic History - up to CPU OS V7 94
Table 66: Operating System Versions and Programming Tools 97
Declaration of Conformity
For the HIMatrix system, declarations of conformity exist for the following directives:
EMC Directive
Low Voltage Directive
EX Directive
The current declarations of conformity are available on the HIMA website www.hima.com.
Index
alarm (see event) - F*03 ............................. 19 temporary in connection with I/Os .......... 28
analog inputs forcing......................................................... 39
use - CPU OS up to V7 ........................... 78 CPU OS up to V7 .................................... 42
use - CPU OS V7 and higher .................. 61 restriction to the use - CPU OS V7 and
analog outputs higher .................................................. 42
use - CPU OS up to V7 ........................... 78 switches and parameters - CPU OS up to
use - CPU OS V7 and higher .................. 62 V7 ........................................................ 43
communication V7 and higher ......................................... 39
configuration - CPU OS V7 and higher ... 71 forcing in connection with F*03 .................. 40
configuration - up to CPU OS V7 ............ 84 forcing in connection with standard devices 40
configuration of Ethernet interfaces - CPU Hardware Editor ......................................... 56
OS V7 and higher ................................ 71 line monitoring ............................................ 17
communication time slice monitoring the temperature state ............... 18
maximum ................................................. 23 noxious gases ............................................ 14
counter inputs online test ................................................... 92
use - CPU OS up to V7 ........................... 78 operating conditions
use - CPU OS V7 and higher .................. 62 ESD protection........................................ 15
de-energize to trip principle ......................... 11 operating system ........................................ 27
diagnostic history ........................................ 93 PADT user management ............................ 68
diagnostic indicators PES user management .............................. 69
ELOP II Factory ....................................... 95 processor system
SILworX ................................................... 95 modes of operation ................................. 29
digital inputs processor system ....................................... 28
use - CPU OS up to V7 ........................... 78 safeethernet ............................................... 21
use - CPU OS V7 and higher .................. 61 configuring signals - up to CPU OS V7 ... 90
digital ouputs profile - CPU OS up to V7 ....................... 89
use - up to CPU OS V7 ........................... 78 signals monitoring - CPU OS V7 and
digital outputs higher .................................................. 91
use CPU-OS V7 and higher .................... 62 system signals - up to CPU OS V7 ......... 87
energize to trip principle .............................. 11 temperature monitoring .............................. 18
Ethernet ...................................................... 21 test conditions ............................................ 12
connectors ............................................... 23 climatic .................................................... 13
Ethernet interfaces EMC ........................................................ 13
configuration - up to CPU OS V7 ............ 84 mechanical.............................................. 13
event power supply........................................... 14
creation - F*03 ......................................... 19 user account ............................................... 69
definition - F*03 ....................................... 72 user group .................................................. 69
general -F*03 ........................................... 19 user program .............................................. 30
recording – F*03 ...................................... 20 restart after errors ................................... 91
faults stop ......................................................... 92
internal..................................................... 28 test mode ................................................ 92
permanent in connection with I/Os .......... 28 voltage supply monitoring ........................... 18
reaction to................................................ 27