Interbus Practical Guide PDF

2
Alexander Bsing Holger Meyer

INTERBUS Practical Guide
Interbus Practical Guide
INTERBUS Basics ....................................................................... 9

1.1
Areas of Application of the INTERBUS System................. 10
1.2
INTERBUS System Specifications .................................... 12
1.2.1 INTERBUS - General..................................................... 12
1.2.2 INTERBUS Remote Bus ................................................ 13
1.2.3 INTERBUS Local Bus .................................................... 15
1.2.4 INTERBUS Installation Remote Bus .............................. 16
1.2.5 INTERBUS Loop (Installation Local Bus)....................... 16
1.2.6 INTERBUS Fiber Optics................................................. 17
1.3
INTERBUS in the ISO/OSI Reference Model .................... 19
1.4
INTERBUS Data Transmission.......................................... 20
1.4.1 Master/Slave Access Method......................................... 20
1.4.2 INTERBUS as a Distributed Shift Register..................... 21
1.4.3 Summation Frame Protocol ........................................... 22
1.4.4 Identification or Data Cycles .......................................... 23
1.4.5 Data Integrity in the INTERBUS System........................ 24
1.4.6 Identification and Length Code ...................................... 29
1.4.7 Standard Control Register ............................................. 32
1.4.8 Hybrid Data Transmission.............................................. 33
1.4.9 Advantages of the Process Data Channel Compared
With the Parameter Channel.......................................... 34
1.4.10 Compact PCP ................................................................ 35
1.4.11 Number of INTERBUS Cycles for the Transmission of
Process Data
........................................................ 36
1.4.12 INTERBUS Transmission Speeds ................................. 38
1.5
INTERBUS Protocol Chips ................................................ 39
1.5.1 Master Protocol Chip (IPMS) ......................................... 40
1.5.2 Slave Protocol Chips (SUPI) .......................................... 41
1.6
Generation 4 INTERBUS Firmware................................... 46
1.6.1 Startup Behavior for Generation 3 and Generation 4
Firmware ....................................................................... 47
1.6.2 Differences in Service Codes for Generation 3 and 4 .... 47
1.7
Multi-Port Memory (MPM).................................................. 48
1.7.1 Structure of the MPM ..................................................... 49
1.7.2 MPM Memory Management........................................... 50
1.7.3 Static RAM in the MPM .................................................. 51
1.7.4 MPM Status and Control Registers................................ 53
1.7.5 Serial Data Channel of the MPM.................................... 53
1.7.6 MPM Communication Options ....................................... 53
1.7.7 Data Interface (DTI) ....................................................... 54
1.7.8 Mailbox Interface (MXI) .................................................. 54
1.7.9 SysFail Request............................................................. 54

1.7.10 Signal Interface (SGI) .................................................... 54
1.7.11 Synchronization Request ............................................... 54
1.7.12 Extended Data Area (XDTA).......................................... 55
1.7.13 MPM Descriptor ............................................................. 56
1.8
Process Data Channel Operating Modes .......................... 57
1.8.1 Times for the INTERBUS Operating Modes................... 59
1.8.2 Parallel and Sequential Transmission of Process Data . 60
1.8.3 Asynchronous Operating Mode...................................... 61
1.8.4 Bus-Synchronous Operating Mode ................................ 65
1.8.5. Program-Synchronous Operating Mode ........................ 66
1.9
INTERBUS System Components ...................................... 67
1.10 Practical Tips ..................................................................... 68
1.11 Workshops......................................................................... 71
1.12 Questions for the "Basics" Section .................................... 71
2 INTERBUS Configuration .......................................................... 72
2.1
Planning INTERBUS Configurations ................................. 73
2.2
Power Supplies.................................................................. 84
2.2.1 Regulated Power Supplies............................................. 84
2.2.2 Non-Regulated Power Supplies ..................................... 87
2.2.3 Isolation of the Power Supply, Cable Cross Sections,
and Voltage Drop ........................................................... 88
2.2.4 Selecting Power Supplies .............................................. 89
2.3
INTERBUS Emergency Stop Configuration....................... 90
2.3.1 Emergency Stop Configuration for Power Supplies ....... 90
2.3.2 INLINE-SAFE The Emergency Stop Configuration for
Interbus Inline segments ................................................ 90
2.4
Improving EMC Through Surge Voltage Protection........... 91
2.4.1 Causes and Effects of Surge Voltage ............................ 91
2.4.2 Surge Voltage Protection Measures .............................. 91
2.4.3 EMI Protection Concept According to VDE 0100 ........... 92
2.4.4 Surge Voltage Interference due to Network
Disturbances .................................................................. 94
2.4.5 Lightning and ESD Protection ........................................ 96
2.4.6 Protection from Transient Voltages................................ 98
2.4.7 Cable Installation, Shielding, Grounding, and Equipotential
Bonding........................................................................... 98
2.5
Assembly Guidelines and Standards............................... 101
2.6
Practical Tips ................................................................... 101
2.7
Workshop ........................................................................ 104
2.8
Questions for the "Configuration" Section........................ 106
3 INTERBUS Diagnostics ........................................................... 107
3.1
Diagnostic Interfaces and Designations .......................... 108
3.2
Standard Function Registers ........................................... 111
3.2.1 Addresses of Standard Registers in the MPM ............. 112
3.2.2 Diagnostic Status Register........................................... 113
3.2.3 Diagnostic Parameter Register .................................... 114
3.2.4 Extended Diagnostic Parameter Register .................... 114
3.2.5 Diagnostic Registers in the Diagnostic Display ............ 115
3.2.6 Standard Function Start Register................................. 116
3.2.7 Standard Function Status Register .............................. 116
3.2.8 Standard Function Parameter Register........................ 117
3.2.9 Slave Diagnostic Status Register................................. 118
3.2.10 Field Controller Diagnostic Status Register.................. 118
3.2.11 Executing Services Using the Standard Function
Registers...................................................................... 119
3.3
Reset Behavior of the INTERBUS System ...................... 120
3.4
INTERBUS Error Diagnostics .......................................... 121
3.4.1 Representation of an INTERBUS Error in a G4
INTERBUS System...................................................... 121
3.4.2 Error Types .................................................................. 130
3.5
Local Bus Diagnostics ..................................................... 132
3.5.1 Time Conditions for Error Localization ......................... 135
3.5.2 Error Localization With Older SUPI Protocol Chips...... 136
3.5.3 Error Localization With INTERBUS Devices Using
SUPI 3 or Later ............................................................ 138
3.6
Diagnostics in SUPI 2, SUPI 3, and Combined Systems. 139
3.7
Transmission Quality ....................................................... 143
3.8
Evaluating INTERBUS Module Diagnostic LEDs............. 144
3.8.1 General Diagnostic LEDs............................................. 144
3.8.2 Procedure for Troubleshooting Using Diagnostic LEDs147
3.9
Evaluating the Controller Board LCD/Diagnostic LEDs ... 148
3.10 Diagnostic Programs ....................................................... 151
3.10.1 Integrated Diagnostics With CMD and PC WORX ....... 151
3.10.2 Diagnostics Using DIAG+ ............................................ 154
3.11 Diagnosing Complicated Error Descriptions .................... 155
3.12 Hardware Diagnostics ..................................................... 157
3.12.1 Measuring the Voltage Supply ..................................... 157
3.12.2 Checking Output Drivers for the RS-485 Interface....... 158
3.12.3 Checking INTERBUS Cables....................................... 160
3.12.4 Use of a Protocol Analyzer for Diagnostic Purposes.... 161
3.12.5 Questions for the "Diagnostics" Section....................... 162
4 INTERBUS Programming ........................................................ 163
4.1
Flowcharts for INTERBUS Programming ........................ 164
4.2 Programming an INTERBUS Master in
High-Level Language .......................................................... 167
4.2.1 INTERBUS PC Controller Boards ................................ 167
4.2.2 INTERBUS Ethernet Controller Boards ....................... 170
4.2.3 High-Level Language Interface (HLI) and Device Driver
Interface (DDI) ............................................................. 172
4.2.4 Startup Checklists for INTERBUS Controller Boards ... 176
4.2.5 Programming via the DDI............................................. 178
4.2.6 INTERBUS Controller Board Programming via the HLI181
4.2.7 Driver Development With the Device Driver Development
Kit (DDK)...................................................................... 182
4.2.8 Practical Tips ............................................................... 182
4.2.9 Questions for the "High-Level Language Programming"
Section......................................................................... 185
4.3
Programming in IEC 61131-3 Using PC WORX .............. 186
4.3.1 INTERBUS PC Field Controller.................................... 186
4.3.2 INTERBUS Remote Field Controller ............................ 187
4.3.3 INTERBUS Ethernet Remote Field Controller.............. 188
4.3.4 Programming in IEC 61131-3 Using PC WORX .......... 189
4.3.5 Mapping the Physical Hardware in PC WORX............. 199
4.3.6 Program-specific Elements in PC WORX .................... 202
4.3.7 Practical Tips ............................................................... 208
4.3.8 Questions for the "Programming Using PC WORX"
Section......................................................................... 210
4.4
Programming S7 INTERBUS Controller Boards.............. 211
4.4.1 IBS S7 300 DSC-T....................................................... 211
4.4.2 IBS S7 400 DSC/I-T..................................................... 216
4.4.3 Questions for the "Programming Using S7 Controller
Boards" Section ........................................................... 226
5 INTERBUS Specialist Knowledge............................................ 227
5.1
@utomationXplorer.......................................................... 228
5.2
IB Loader......................................................................... 229
5.2.1 Available Operating Systems ....................................... 229
5.2.2 Structure of the SVC File ............................................. 229
5.2.3 Creating an SVC File ................................................... 230
5.2.4 Installation of the IB Loader ......................................... 231
5.2.5 Calling the IB Loader ................................................... 231
5.2.6 IB Loader Error Messages ........................................... 232
5.3
Process Data Preprocessing ........................................... 233
5.3.1 PDP for Standard Controllers (SC) .............................. 233
5.3.2 PDP for PC WORX Controllers .................................... 234
Distributed Control Concept..................................................... 236

6.1
System Couplers ............................................................. 237
6.2
ILC 200 IB as Distributed Intelligence.............................. 238
6.3
Communication Options for a Distributed Control
System ............................................................................ 239
6.3.1 Communication via the Process Data Channel............ 239
6.3.2 Communication via the Parameter Channel................. 241
6.3.3 Communication via Variable Names ............................ 247
6.3.4 Read/Write MPM via the Management Channel
(PNM7)......................................................................... 255
6.3.5 Reading/Writing Slave Interface OPC Items ................ 261
6.4
Questions for the "Distributed Control Concept"Section.. 261
7 OPC and INTERBUS ............................................................... 262
7.1
Purpose of OPC .............................................................. 263
7.1.1 OPC Client/Server Architecture ................................... 263
7.2
Method of Operation of OPC Communication ................. 264
7.2.1 Access Method ............................................................ 264
7.2.2 Required INTERBUS OPC Client/Server Components 265
7.2.3 COM/DCOM Platform .................................................. 266
7.3
List of OPC Server Suppliers........................................... 266
7.4
INTERBUS OPC Server From Phoenix Contact.............. 267
7.4.1 Differences Between the INTERBUS OPC Servers..... 267
7.4.2 OPC Data Types and Default Items............................. 268
7.4.3 INTERBUS OPC Configurator ..................................... 269
7.4.4 Configuration File (*.clr) ............................................... 269
7.4.5 Error Log File (*.log) and IBOPCDiag .......................... 270
7.4.6 OPC Project File (*.vis) ................................................ 272
7.5
OPC Client....................................................................... 273
7.5.1 Diagnostic OPC Client ................................................. 273
7.5.2 Diagnostics of a New OPC Client/Server Connection.. 273
7.5.3 Diagnostics of a Faulty OPC Client/Server Connection274
7.5.4 Developing Your Own OPC Components .................... 274
7.5.5 Suppliers of Commercial OPC Clients ......................... 275
7.6
INTERBUS OPC Client/Server Configurations ................ 276
7.7
OPC Client/Server Connection Using the IB Loader ....... 278
7.8
Fast Alternative to the OPC Client/Server Connection .... 278
7.9
Practical Tips ................................................................... 279
7.10 Questions for the "OPC Communication" Section ........... 282
8 Ethernet and INTERBUS ......................................................... 283
8.1
Ethernet Connection to INTERBUS................................. 284
8.2
Why use TCP/IP and Ethernet?....................................... 284
8.3
Installing Ethernet in an Industrial Environment............... 286
8.4
Ethernet Components From Phoenix Contact ................. 287
8.4.1 Factory Line and INTERBUS Ethernet Controller ........ 287

8.4.2 Network Management Software: Factory Manager 2.0 289
8.4.3 OPC Configuration Software: FL IO Configurator ........ 290
8.4.4 SNMP-OPC Software: FL SNMP-OPC Gateway ......... 290
8.4.5 Web-Based Management ............................................ 290
8.4.6 Trap Receiver .............................................................. 291
8.5
Diagnostics in the Ethernet Network................................ 291
8.5.1 TCP/IP on a Windows Operating System.................. 291

8.5.2 Setting the IP Address and Subnet Mask .................... 291
8.5.3 Testing Ethernet Communication................................. 292
8.5.4 Typical Network Errors................................................. 295
8.5.5 Ethernet Troubleshooting............................................. 296
8.5.6 Important Commands Used for Network Analysis........ 298
8.5.7 SNMP (Simple Network Management Protocol) .......... 300
8.5.8 RMON (Remote Network Monitoring) .......................... 301
8.6
Prevention of Ethernet Problems..................................... 303
8.7
Ethernet Cable Types...................................................... 303
8.8
Ethernet Configuration Using INTERBUS ....................... 305
8.9
Redundant Ethernet With FL Switch................................ 307
8.10
"Ethernet and INTERBUS" Workshop ............................. 308
8.11
Practical Tips ................................................................... 309
8.12
Questions for the "Ethernet" Section ............................... 310
INTERBUS Basics
1 INTERBUS Basics
This section provides a general INTERBUS function and system description. A
certain level of knowledge of INTERBUS basics is required to enable applicationspecific use of the INTERBUS system. This knowledge enables the user to correctly
interpret information from the INTERBUS system during configuration, startup or
diagnostics. The user will also benefit from an understanding of the structure,
hierarchy, and interaction of INTERBUS components.
The INTERBUS system description only provides detailed information when this is
appropriate to the practical nature of this manual. This means that applicationspecific information is described in detail and the user is provided with a basic
knowledge of the system. This includes information on methods of optimizing the
INTERBUS system, the use of the MPM or the various applications of different
INTERBUS operating modes.
The aim of this section is to provide users with a practical understanding of the
INTERBUS system, its topology, its components, and wide range of properties,
enabling the use of the system in practical applications.
This section covers the following topics:
-
General system description of the INTERBUS system

INTERBUS in the ISO/OSI communication model
Basic method of operation of INTERBUS data transmission
Description of INTERBUS transmission reliability
Structure, function, and description of INTERBUS protocol chips
Behavior of and differences between firmware versions G3 and G4
Structure, function, and management of the central INTERBUS memory, the
MPM
Overview and method of operation of all INTERBUS operating modes
Components available for an INTERBUS system
Important cross references:
Dieses Dokument gehrt
H.Meyer u.
14.10.2002
What are the basic specifications for the INTERBUS system?

How does INTERBUS data transmission work?
How does the INTERBUS system detect data transmission errors?
How is the INTERBUS cycle and response time calculated?
What are the tasks of the protocol chips in the components?
What are the differences between firmware versions G3 and G4?
How is the Multi-Port Memory (MPM) structured?
What are the meanings of the individual INTERBUS operating modes?
How is MPM/XDTA access programmed with standard drivers?
Page 12
Page 20
Page 24
Page 36
Page 39
Page 47
Page 48
Page 57
Page 71
10
INTERBUS Basics
1.1 Areas of Application of the INTERBUS System

The INTERBUS system is a fieldbus at the lower pyramid level of the
communication hierarchy model in automation technology, as shown in Figure 1.1.
It performs the task of data transmission between PLCs, software, and robot
controllers on the one hand and between actuators, sensors, operator panels, and
drives in the field on the other hand. When an automation solution is near to the
process, as required in machine production for example, rapid data transmission (<
5 ms) between control systems and field devices is extremely important. Due to its
system properties, INTERBUS can transmit time equidistant signals, which provide
a high degree of data transmission security.
Levels
Operating level
Management level
Applications
Process
Visualization
System control
System level
SAP R/3
Local area
network
Genesis 32
OPC client/
server
IBS PCWORX
Control level
Data
processing
I/O level
Data input and

output
Process bus:
e.g., Ethernet
INTERBUS m aster
Fieldbuses:
e.g., INTERBUS
Sensors and actuators
Figure 1.1: INTERBUS in the communication hierarchy

The INTERBUS system was developed by Phoenix Contact and has been
available since 1987. Since the disclosure of the INTERBUS communication
protocol (1987), it has become established in sensor/actuator applications and has
developed to become an industry standard. It is a standardized fieldbus system for
the serial transmission of data from the sensor and actuator area according to
European standard EN 50254, international standard IEC 61158, and German
national standard DIN 19258.
Where in the past individual cables were laid between sensors, actuators, and the
control system, economic considerations have led to the introduction of fieldbus
systems such as INTERBUS, which replace parallel cabling.
INTERBUS Basics
11
As one of the leading fieldbuses in (factory) automation, the INTERBUS fieldbus

offers the following properties:
-
Low installation costs
Reduced planning costs
Easy maintenance
Flexible bus topology
Minimal downtimes
Easy startup
Very fast and effective data transmission
Manufacturer-independent hardware and software
Open communication protocol
Simple, easy to understand error diagnostics
Very large number of device manufacturers
Very reliable data transmission
Option of creating a redundant version
The properties that have particularly contributed to the success of INTERBUS are cost
savings, the high degree of reliability, very simple error diagnostics, and excellent
flexibility of the system.
With its disclosure of the INTERBUS communication protocol, Phoenix Contact has
interested over 600 manufacturers in the implementation of INTERBUS technology in
control systems and field devices. These manufacturers of INTERBUS-compatible
devices have joined together to form a user group, the Interbus Club e. V. Users can
rely on tried and tested, reliable technology and a high degree of availability for both
fieldbuses and components, and can benefit from the wide range of components
offered by suppliers and users.
Due to its technical stability, network security, EMC behavior, transmission reliability,
and transmission performance, INTERBUS is the ideal fieldbus for use as an industrial
automation solution. It has also been implemented successfully as a solution in
building automation.
The further technological development of INTERBUS involves the increase of the
INTERBUS data transmission speed from 500 kbaud to 2 Mbaud, connection to a
higher communication hierarchy via Ethernet, and the implementation of an
INTERBUS system with an emergency stop concept (INTERBUS Safety).
A detailed description of popular sensor and actuator fieldbus

technology is given in the book Sensor/Actuator Fieldbus
Technology Basics, published by Vogel-Verlag [1].
12
INTERBUS Basics
In addition to INTERBUS, there are other fieldbuses, such as PROFIBUS, Bitbus,

CAN, AS-Interface, and LON, which are used in the sensor/actuator level [39].
1.2 INTERBUS System Specifications

1.2.1 INTERBUS - General
The INTERBUS system specifications listed in this section should provide the user
with a quick overview of the entire system and of the specific data for individual
INTERBUS components. As can be seen in Figure 1.2 to Figure 1.5, the focus
here is on brief and succinct representations. Table 1.1 to Table 1.4 provide details
of basic INTERBUS system specifications in table format.
INTERBUS controller
board
INTERBUS
LOOP local bus, 200 m (656.17 ft.)

maximum
20 m
(65.62 ft)
20 m
(65.62 ft)
BK
M
-T
DI 32/2
BDO
8/
3
DO 16/
3
Remote bus at level 0
ST local
bus
AO 4/
SF4
Interface converter to fiber optics
IL local bus
RT
modules
PHOENI
X
CONTACT
1 2 3 4 5 6 7 89
B
A
R
C
R
D
PHOENI
X
CONTACT
1 1 1 1 1 1 1
0 1 2 3 4 5 6
1 2 3 4 5 6 7 89
ready
UB(1)
B
A
R
C
R
D
1 1 1 1 1 1 1
0 1 2 3 4 5 6
read
y
UB(1
)
Remote bus at level 1
Remote bus, 12.8 km (7.95 mi.) maximum
400 m
(1312.34 ft)
20 m
(65.62 ft)
Figure 1.2: INTERBUS topology with system specifications
INTERBUS Basics
13
Table 1.1: Basic INTERBUS system specifications

Standards
DIN EN 50254, DIN 19258, IEC 61158
Maximum I/O points
Firmware Version < 4.6 : 4096
Firmware Version 4.6 : 8192
When DIO modules (devices with IN and OUT registers) are
used, 4096 input data points and 4096 output data points
can be used.
Maximum number of data
Firmware Version < 4.6 : 256 data words
words in the summation
Firmware Version 4.6 : 512 data words
frame
Transmission speed
500 kbps
2 Mbps
Data protection
Protocol: Loop-back word check
Cyclic redundancy check
Hamming distance
Timeout check
SL (Select Line) check
Transmission: Spike suppression if spike < 125 ns
Start edge evaluation
Function start bit, flag bit, and stop bit
monitoring
Hamming distance 4
Maximum number of devices 512, with 254 on a remote bus line
Maximum physical expansion Copper: 12.8 km (7.95 mi.)
Glass fiber: 80 km (49.71 mi.)
Transmission media
Copper cable
Optical fibers: polymer fiber, HCS fiber, glass fiber
Slotted microwave guide
Infrared transmission path
Slip ring transmission
Maximum number of PCP
Firmware Version < 4.6 : 62
devices (communication
Firmware Version 4.6 : 126
devices) on INTERBUS
devices
Maximum INTERBUS levels
16
Maximum number of remote 254
bus segments
The remote bus segment refers to the remote bus cable with
the subsequent remote bus device, including any associated
local bus devices.
1.2.2 INTERBUS Remote Bus

The remote bus provides a long-distance connection between the INTERBUS
controller board and the remote bus devices and also interconnects the remote bus
devices. Usually, different workstations are connected together, and are generally
structured as a distributed unit. The remote bus devices are known as bus terminal
modules and are used to link the remote bus and local bus. The bus terminal
modules supply the I/O modules with voltage (communications power) and provide
a repeater function for updating the data signal. Although in theory the size of the
INTERBUS system is unlimited, the number of devices is restricted to a practical
amount. It is more difficult to create a remote bus device than a local bus device.
Figure 1.3 illustrates the INTERBUS remote bus with a remote bus branch.
14
INTERBUS Basics
INTERBUS controller board
1
1.0
2
1.1
3
1.2
4
1.3
5
2.0
Remote bus
branch
6
3.0
Remote bus
devices
9
4.0
10
4.1
11
4.2
7
3.1
8
3.2
12
4.3
Figure 1.3: Devices in the INTERBUS remote bus with remote bus branch
Table 1.2: Basic INTERBUS remote bus specifications

Physical interface
2-wire, often implemented using a 9-pos. D-SUB

connector
Electrical interface
RS-485
Optical fibers (polymer fiber, HCS fiber, glass fiber)
Copper, infrared, radio
Maximum distance
400 m (1312.34 ft.)
between two bus terminal

modules
Electrical segmentation
The remote bus can be electrically segmented at any time.
Remote bus branch
The remote bus branch offers the option of branching the

remote bus like the local bus. Remote bus branch nesting can
be used to create 16 INTERBUS (remote bus) levels. The
remote bus branch is used where parts of the INTERBUS
system have to be shut down without shutting down the rest of
the configuration.
INTERBUS Basics
15
1.2.3 INTERBUS Local Bus

The local bus is directly connected to the bus terminal module. As can be seen in
Figure 1.4, the local bus devices are connected together and are supplied with
communications power by the bus terminal module. The I/O device switching
voltages must be connected separately to the local bus modules. Most INTERBUS
modules are available as local bus devices. As local bus devices have a simpler
structure than remote bus devices, they are less expensive to implement.
Branching within a local bus is not supported.
1
1.0
5
2.0
2
1.1
3
1.2
Local bus
devices
Remote bus
branch
6
3.0
9
4.0
4
1.3
10
4.1
11
4.2
Figure 1.4: Devices in the INTERBUS local bus
7
3.1
12
4.3
8
3.2
16
INTERBUS Basics
Table 1.3: INTERBUS local bus

Bus terminal module
required
The bus terminal module supplies the bus logic and decouples
the local bus from the main ring.
Physical interface
ST range: 5-wire ST flat-ribbon cable IL range: contact pin
Single-ended TTL signal
Power supply
The communications power is provided by the bus terminal

module. The I/O devices can be supplied separately
electrical isolation.
Electrical segmentation is supported, e.g., in an Inline system

using segment or power IN terminals
Expansion within the local

bus
Normally local bus devices are mounted directly side by side.

The exception is Generation 1 local bus devices, which could
also cover distances of a few meters.
Maximum number of
63 - this is a theoretical figure. For example, in the ST range
devices within the local bus only 8 local bus devices can be mounted side by side in a
segment.
1.2.4 INTERBUS Installation Remote Bus

The installation remote bus works on the same principle as the remote bus. The
supply voltage for the installation remote bus is carried within the bus cable on
separate wires (hybrid cable). The installation remote bus is started with a special
bus terminal module. Devices with IP 65 protection are usually used.
Table 1.4: INTERBUS installation remote bus
Physical interface
2-wire, often implemented using a circular connector
RS-485
Electrical segmentation is supported
Maximum distance between bus

terminal module and last
installation remote bus device
50 m (164.04 ft.)
Maximum current load
4.5 A for 1.0 mm (17 AWG)
1.2.5 INTERBUS Loop (Installation Local Bus)

The INTERBUS Loop, which is illustrated in Figure 1.5, integrates sensors,
actuators, and other I/O devices directly into the INTERBUS system. The amount
of cable required is kept to a minimum. INTERBUS Loop devices are connected to
the INTERBUS system via a special bus terminal module (Loop BT module). The
Loop BT module converts the RS-485 logic to Loop signals. The modules are
connected to the bus terminal module, and to each other, via an unshielded twowire cable. The Loop cable supplies power and transfers data. Its main area of
application is direct use on machines. The INTERBUS Loop is a cost-effective local
bus system for connecting I/O points to INTERBUS.
INTERBUS Basics
17
Table 1.5: INTERBUS Loop

Mechanical interface
Insulation displacement connector method (QUICKON

connection method)
Loop transmission technology, current transmission
Topology
Ring structure; the ring begins and ends at the Loop BT
module
Electrical segmentation is not supported
Maximum length of the Loop ring 200 m (656.17 ft.)
Maximum distance between two 20 m (65.62 ft.)
Loop devices or Loop BT
module
Maximum number of Loop
63
modules on a bus terminal
module
Maximum current carrying
1.8 A (the current carrying capacity can be extended by
capacity
Power IN boxes).
3.2
Incoming
remote bus
3.1
3.3
3.0
Loop devices
3.4
3.5
Outgoing
remote bus
Figure 1.5: Bus terminal module and devices in the INTERBUS Loop
1.2.6 INTERBUS Fiber Optics

The use of fiber optics involves the conversion of copper-based serial interfaces
into optical interfaces. This measure is taken whenever the physical limits of
copper-based data communication are reached. Interface converters are used to
convert twisted pair cables (TP) for optical transmission. These converters provide
bidirectional and protocol-independent conversion of the electrical signals of the
serial RS-422 (V.11) interface into optical signals. Figure 1.6 shows the structure
of a fiber optic cable with two fibers.
18
INTERBUS Basics
The use of fiber optics offers the following advantages:

-
Protection against electromagnetic fields
Higher transmission speed than copper
Larger distances can be covered
Electrical isolation between transmitter and receiver
No compensating currents, due to different ground potentials
No crosstalk from adjacent cables
Lighter than copper cables
Can be used in potentially explosive areas
Fiber
Elastomer
Aramide fiber
Wire
Outer cable
sheath
Figure 1.6: Structure of a fiber optic cable

In practical control system applications, polymer and HCS fibers are generally
preferred. Glass fibers are only used in special applications, such as
telecommunications. Table 1.6 provides some characteristic values for the three
fiber types: polymer, HCS, and glass fiber. HCS and polymer fibers are described
in more detail, as they are more relevant in practice.
Table 1.6: Characteristic properties of fiber optic cable types
Fiber/Cable Type
Data
Polymer Optical Fiber
Core material: PMMA (polymethylmetacrylate)
(POF = plastic fiber)
Sheath material: fluorinated polymer
Maximum line lengths: 50/70 m (164.04/229.66 ft.)
Attenuation: < 160 dB/km (for monochromatic light, 650 nm)
o
o
o
o
Temperature range: -20 C...+70 C (-4 F to +158 F)
Hard Clad Silica (HCS)
Core material: silicate glass
Sheath material: hard polymer
Maximum line length: 300 - 500 m (984.25 - 1640.42 ft.)
Attenuation: < 10 dB/km (660 nm)/< 8 dB/km (850 nm)
o
o
o
o
Temperature range: -20 C...+70 C (-4 F to +158 F)
Glass fiber
Core material: silicate glass
Maximum line length for single mode fibers: > 10 km (6.21 mi.)
INTERBUS Basics
19
1.3 INTERBUS in the ISO/OSI Reference Model

The ISO/OSI reference model is mentioned frequently in later sections, and should
therefore be described briefly here. The purpose of the ISO/OSI reference model is
to describe different communication devices in a standard way. It must be possible
to describe every communication device using this model. For this reason, it has
been specified as a standard. This task was undertaken by the International
Organization for Standardization (ISO) and in 1978 they developed the Open
System Interconnection (OSI) reference model.
The ISO/OSI reference model uses seven layers to describe the stages of a
communication process. Each layer has an interface to adjacent layers in the form
of service primitives. Ideally, communication between two devices should occur
from Layer 7 of one device to Layer 7 of the other device. This means that in an
ideal scenario communication could be interrupted, for example, in Layer 2 of the
terminal device if an error was detected.
Table 1.7: The seven layers of the ISO/OSI reference model
7 Application Layer
The Application Layer is the interface between application and

communication. It provides the user with services, which can be
used to control the INTERBUS system.
6 Presentation Layer
Provides services for the Application Layer for the interpretation

of data that has been exchanged.
5 Session Layer
Synchronization between client and server. Also monitors the

start and end of a session, control of the data flow, dialog
control, and operation during a session.
4 Transport Layer
AC supply-independent transport services are provided. Error

checking and correcting for data packets from one device to the
next.
Separation of the transport-oriented part of communication from
the application-oriented part.
3 Network Layer
Finds the optimal path for data through the existing network.
Establishes and aborts network connections.
2 Data Link Layer
The Data Link Layer ensures secure transmission between two

adjacent OSI systems.
1 Physical Layer
Physical properties of the device, such as the type of signal,

connectors, and cables. The RS-485 transmission standard is
used in the INTERBUS system.
The ISO/OSI reference model can be used to provide a complete device

description. For communication, it is important that all layers are reflected in the
device or are replaced by other layers. For reasons of efficiency, only Layers 1, 2,
and 7 are reflected in the INTERBUS system. They are highlighted in gray in Table
1.7. To ensure that the communication model remains valid, the LLI (Lower Layer
Interface) performs the tasks of Layers 3 to 6. The LLI is a sublayer of Layer 7.
20
INTERBUS Basics
1.4 INTERBUS Data Transmission

1.4.1 Master/Slave Access Method
The INTERBUS system operates according to the master/slave access method,
i.e., the INTERBUS controller board (master) controls and monitors communication
between all INTERBUS devices (slaves). The communication process involves
initiating data transmission cycles. The controller board transmits its data to the
devices and receives data from the devices on the return path. The forward and
return line of the physical data transmission medium consists of a twisted pair
cable or a fiber optic cable. In terms of structure, the INTERBUS system operates
as a ring system, but behaves during installation as a line or tree structure. In
practice, this means that the INTERBUS cable is laid in the system in a particular
direction. Starting at the master, the INTERBUS cable connects the devices with
the input and output units in the periphery. To simplify system installation, the
INTERBUS ring, i.e., the forward and return line, is implemented in one cable. The
ring structure of the INTERBUS system can be seen clearly in Figure 1.7.
INTERBUS
master
Twisted pair cable
INTERBUS bus INTERBUS
INTERBUS
coupler
input module output module
INTERBUS
bus coupler
INTERBUS
bus coupler
INTERBUS
input module
INTERBUS
bus coupler
INTERBUS
INTERBUS
bus coupler output module
INTERBUS
bus coupler
INTERBUS
input module
INTERBUS
INTERBUS
bus coupler output module
Figure 1.7: INTERBUS ring structure
A shielded, twisted pair cable transmits INTERBUS data from

INTERBUS devices as differential signals according to transmission
standard RS-485.
INTERBUS Basics
21
1.4.2 INTERBUS as a Distributed Shift Register

The INTERBUS system is designed as a data ring with the central master/slave
access method and has the structure of a physically distributed shift register. Each
INTERBUS module, with its receive and transmit registers, is part of this shift
register ring, through which data is clocked serially from the INTERBUS master.
The INTERBUS system can therefore be seen as a shift register, which is
distributed across all INTERBUS devices. The use of the ring structure provides
the option of sending and receiving data simultaneously (full duplex). Figure 1.8
illustrates INTERBUS data transmission as a distributed shift register.
16
32
Output data
Master transmit
shift register
Master recieve
shift register
I
O
8 bits
16
32
Input data
I
O
16 bits
O
32 bits
INTERBUS devices with input and output shift registers
Figure 1.8: INTERBUS devices as a distributed shift register

The master transmit shift register shifts its output data through all the shift registers
of the INTERBUS devices, Figure 1.9, until it reaches the master receive shift
register. This continues until the master transmit shift register is empty and the
output data is at the INTERBUS devices and the input data from all the devices is
in the master receive shift register. Once this process is complete, all devices take
the output data and transfer it to the I/O devices. At the same time, the master
accepts the device input data, which is in the master receive shift register. This
process occurs in every cycle and is a quick and efficient method for transmitting
large amounts of input and output data.
The INTERBUS cycle is therefore dependent on the amount of user data, which
has to be shifted through the shift registers and can be calculated precisely in
terms of time (cycle time formula).
The INTERBUS system requires a closed, active data ring as the bus
architecture. This is due to the INTERBUS topology, which is
structured as a ring.
22
INTERBUS Basics
CRC generator
CRC register
Incoming data
DATA SHIFT REGISTER
Output register
Input register
Identification register
Control register
Outgoing data
CRC generator
CRC register
Returning data
Figure 1.9: INTERBUS device structure
Due to this cyclical method of operation, the INTERBUS system

operates in a deterministic way, i.e., the duration of every INTERBUS
cycle can be predicted and the cycle time remains constant unless the
configuration is modified.
1.4.3 Summation Frame Protocol

In order to transfer data successfully from the INTERBUS master to the INTERBUS
devices, INTERBUS uses the summation frame as the transmission protocol. The
summation frame is assigned to Layer 2 of the ISO/OSI reference model. This
summation frame protocol was specially developed for the lower sensor/actuator
data level. The summation frame contains all useful information from all connected
INTERBUS devices and has a predefined data area for every device, which
contains sensor and actuator data. To transfer this data, the information for every
device is divided into separate parts, which are transmitted in sequence. Figure
1.10 illustrates the summation frame, clearly showing the various parts: LBW
(Loop-back word), data, and FCS (Frame Check Sequence).
Data
Data
Data
Data
Data
Module 1
Module 2
Module 3
Module n-1
Module n
LBW
FCS
End
Figure 1.10: Summation frame transmission protocol

The individual data areas in the summation frame are assigned to every
INTERBUS device depending on the physical location of the device within the
configuration and not according to the device address as is the case in a messageoriented transmission system. In order to transmit data from the INTERBUS
controller board to an INTERBUS device, the controller board fills the data area
predefined for the device with the relevant data prior to sending. For data, which is
to be transmitted from the device to the controller board, the device fills the
predefined data area within the summation frame telegram. The controller board
INTERBUS Basics
23
sends the summation frame protocol to all devices and receives all process data
from the connected devices when the process is complete.
Every INTERBUS cycle is both an output and an input cycle, i.e., a write
and a read cycle.
Since all data is sent simultaneously within the summation frame protocol and the
data areas are detected efficiently by the INTERBUS devices, the sum of all
additional protocol information within the summation frame protocol is very low.
This protocol information only occurs as a single value. The method of grouping all
additional information together within the protocol increases the efficiency of the
cyclically transmitted summation frame protocol with an increasing number of
network devices. When compared with a message-oriented protocol, such as
PROFIBUS, which has a maximum of 30% user data efficiency, INTERBUS offers
60% user data efficiency. The time for the complete exchange of signals, i.e., for a
complete bus cycle, is the sum of the individual scanning cycles for all the sensors
and actuators connected in INTERBUS. By combining these properties, the
INTERBUS system offers time equidistance, synchronous data scanning, and
determinism.
In theory, the number of INTERBUS devices is virtually unlimited.

However, to ensure practical operation of the INTERBUS system, a limit
of 256 I/O words (firmware Version < 4.6) or 512 I/O words (firmware
Version 4.6) has been set.
1.4.4 Identification or Data Cycles

INTERBUS cycles consist of either identification or data cycles. The INTERBUS
master switches between identification and data cycles using the SL signal as
shown
in
Figure 1.11. Both cycles are the same in terms of the protocol. They differ only in
the transmitted data, the participating registers in the INTERBUS devices, and the
status of the SL signal.
The identification cycle (ID cycle) and the data cycle operate in the same way in
terms of transmission. First a loop-back word, and then the output data from the
INTERBUS master output shift register, is moved to the shift registers of the
individual INTERBUS devices. In the identification cycle, control information for the
output data is transmitted.
Identification cycles (SL signal = TRUE) are used to transmit error and
control information during operation or to read the INTERBUS
configuration in startup mode.
In data cycles (SL signal = FALSE), which are the actual INTERBUS
operating cycles, output data is transmitted from the INTERBUS master
to the INTERBUS devices and input data from the devices is transferred
to the master in the same cycle.
24
INTERBUS Basics
The INTERBUS master uses the CR signal to switch between the data shifting
(CR signal = FALSE) and data integrity (CR signal = TRUE) phases. This is called
the CR check.
Section
1
16 bus
clocks
2
32 bus
clocks
.........
Clock
1
SL signal
0
3
16 bus
clocks
.......
4
32 bus
clocks
.........
.......
Identification
cycle
Data cycle
Identification cycle
1
CR signal
Data
integrity
Data shifting
0
I/O data (I/O)

CR data (C)
I/O
I/O
I/O
I/O
Data
integrity
Data shifting
I/O
I/O
I/O
I/O
I/O
I/O
Figure 1.11: SL and CR signal curve
1.4.5 Data Integrity in the INTERBUS System

In order to ensure data integrity in the INTERBUS system, the following error
detection methods are used. It is important that INTERBUS does not correct errors,
but simply initiates a new data cycle if faulty data is detected.
-
Loop-back word check

CR check
SL and CR signal monitoring
Reset timeout check
1.4.5.1
Loop-Back Word (LBW)
The loop-back word is a component of the summation frame and is moved towards
the INTERBUS master during data transmission, i.e., during the shift operation.
After X shift operations, the loop-back word leaves the master shift registers. This
loop-back word is moved through all the INTERBUS devices and is received again
in the master at the end of the entire transmission process. If there is a difference
between the sent and the received loop-back word, then the received data is not
accepted. To prevent confusion, the other signals increment the last 4 bits of the
loop-back word in every transmission cycle. If the sent and received loop-back
word is the same, then the received data is accepted in the master.
The return of the loop-back word to the INTERBUS master indicates to

the master that the data has been received properly in the INTERBUS
devices.
The master can also determine how many devices are connected and can use
LBW time monitoring to detect a closed INTERBUS ring, a reduction in the bus or a
change in the configuration.
To ensure transmission reliability, general protection must be provided for the
INTERBUS Basics
25
transmitted data. An additional CR check is carried out to check the data

transmission. In this CR check, which is implemented in every INTERBUS device,
the data flow is monitored between two separate, adjacent INTERBUS modules.
1.4.5.2
Cyclic Redundancy Check (CRC)
To monitor error-free data transmission between two INTERBUS devices, the

Cyclic Redundancy Check, or CR check for short, is used as the data protection
method in the INTERBUS system. A CRC generator divides the transmitted data
into a polynomial specified by the CCITT (Comit Consultatif International
Tlgraphique et Tlphonique). The remainder after the division is the CR
checksum. The polynomial used is of the 16th order.
In this checksum comparison, every receiver calculates a checksum. Once all the
data has been shifted from the INTERBUS master to the devices and the loop-back
word has been detected, the checksum from the CRC generator must be the same
as the checksum from the CRC generator of the next device. This process uses a
CRC generator, which is included in every device, and a CRC tester. At the start of
the shifting process, a checksum transmission (polynomial) is triggered by the CRC
generator and compared by the CRC checker of the other device. The comparison
of the polynomial transmitted by the CR check provides definite confirmation that
the transmission from one device to another was completed successfully. However,
as the CR checks on transmission can only detect the validity between two
devices, this test result, the checksum status, must be sent to the master. Every
device, which now detects an error using the CR check, uses this checksum status
telegram to transmit its information to the master. If the checksum status telegram
is error-free, the input data is accepted in the master. At the same time, all devices
accept their output data. However, if a transmission error is detected in this
checksum status telegram, there is no guarantee that the data for this and all
subsequent devices is correct. As a result, no data is accepted from the shift
registers into the input and output areas of the devices and the master. Figure 1.9
illustrates the arrangement of CRC generators and CRC registers.
26
INTERBUS Basics
Principle of the Cyclic Redundancy Check

The generator polynomial used is a polynomial of the 16th order, which was
specified by the CCITT:
G ( x) = X 16 + X 12 + X 5 + 1
The remainder after the polynomial division is transmitted after the data or
identification code phase in the check sequence. The following boxes show the
equations required for calculating the CRC polynomial.
Message: N(x)
Generator polynomial: G(x), n is the highest power in G(x)
Remainder after division: R(x)
K: Number of data bits in a message
W(x): Comparison: 9/4=2 . W(x) corresponds to the integer
Equation 1: Generator polynomial register initialized with 0
X n N ( x)
R( x)
= W ( x) +
G ( x)
G ( x)
Equation 2: Generator polynomial register initialized with 1
n =1
X n N ( x) + x K x i
i =0
G ( x)
= W ( x) +
R( x)
G ( x)
As the division is performed with XOR elements in terms of hardware, the following
mathematical rule should be observed for the polynomial division:
x x = 0
Figure 1.12 illustrates the implementation of a general generator polynomial
division in terms of hardware. This implementation multiplies the message N(x) by
n
x and divides by the generator polynomial G(x). To make things simpler when
converting a generator polynomial to the hardware solution, the relevant powers
have been entered in the individual registers. The bit information, which is one
power lower than the entered powers, can then be taken from the registers.
INTERBUS Basics
27
N(x)
LSB
MSB
a0
x3
x2
a1
x n-1
a2
xn
a n-1
Figure 1.12: Implementation of a general generator polynomial division

The coefficients arise from the general representation of a polynomial. The register
number corresponds to the highest power of the generator polynomial.
G ( x) = an x n + a n1 x n1 + an 2 x n2 + ... + a1 x1 + a0
The general equation results in the following INTERBUS implementation as shown
in Figure 1.13.
N(x)
MSB
LSB
x x2 x3 x4 x5
x6 x7 x8 x9 x10 x11 x12
x13 x14 x15 x16
Figure 1.13: INTERBUS implementation from the general equation

Every INTERBUS device has a CRC generator at its receive and send side. The
checksum is formed during the data or identification phase and then compared with
the checksum from the previous device during the CRC phase.
In an INTERBUS system, the individual registers are preassigned with a 1 to
improve error detection.
Example: INTERBUS structure with 2 INTERBUS devices
As long as the data phase is running (SL bit = FALSE), device 1 calculates the
checksum for the current cycle at its receive and send side. During the CR phase
(CR bit = TRUE), the INTERBUS master transmits the master checksum to the
CRC register of device 1. Device 1 transmits its checksum to device 2, which in
turn transmits it to the master. If all of the separately determined checksums match
those of the other devices, the data or identification cycle is declared valid.
A theoretical derivation and a practical workshop, which deals with the

calculation of the CR check, can be found on the accompanying CDROM.
28
INTERBUS Basics
Efficiency of the CR Check
The polynomial of the 16th order leads to a Hamming distance of 4, enabling the
100% detection of group errors b < 16. Group errors b 17 have a 99.9%
probability of detection. A group error is an error, which is caused by a closely
positioned group of bit errors, known as an error group. Group errors are usually
easier to detect than errors, which are distributed over the entire message. In this
description, b is the number of bits, which belong to a group error. When
comparing two binary words of the same length, the number of bits that differ
between the two words forms the basis of the Hamming distance. If an error
correction method has a Hamming distance of 4, up to 3 errors are detected safely
at the same time.
HD = d = e + 1 (HD, d: Hamming distance; e: Number of errors that can be
detected safely).
1.4.5.3
SL and CR Line Monitoring
In order to detect line interrupts in the INTERBUS system, the INTERBUS master
scans the status of the SL (Select Line) signal in the INTERBUS system. The SL
line in the INTERBUS system is used to test the INTERBUS ring for interrupts
before every data cycle (SL signal = FALSE) and before every identification cycle
(SL signal = TRUE). For this test, the master sets this SL signal to a logical state
(TRUE) at the start of a cycle and scans it again at its input. The resulting signal
delay time, which is caused by the processing in the individual INTERBUS devices
and by the INTERBUS system runtime, indicates whether the signal was
transmitted by the INTERBUS system. If this signal exceeds a specific duration, a
transmission error has occurred, usually an interrupt on the INTERBUS ring.
In addition, the status of the CR line (Control Line) signal is monitored. The data
sequence for this signal differs from the CR check sequence of an INTERBUS
cycle and therefore its status must not change during the data sequence.
1.4.5.4
Reset Timeout Check
If the INTERBUS cable is interrupted at a particular point, then communication is

no longer possible in the entire INTERBUS system. Remote bus devices, which are
located after this interrupt, shut down the outgoing INTERBUS interfaces (short
reset) after 256 s (SUPI 2) or 2 ms (SUPI 3). If the INTERBUS interrupt lasts
longer than 25 ms, then all output words for devices located after this open
INTERBUS interface are set to zero. The INTERBUS master detects this and tries
to read the existing INTERBUS configuration with identification cycles. If the error
is not removed after a maximum of 32 INTERBUS identification cycles, then the
master triggers a reset (long reset). When this long reset is triggered, all devices
(including those located before the open bus cable) set their outputs to zero and
shut down the bus interfaces (I/O devices).
INTERBUS Basics
29
1.4.6 Identification and Length Code

The identification code (or ID code for short) provides the INTERBUS master with
an easy means of detecting the INTERBUS topology. After an ID cycle, the master
knows the precise position of the INTERBUS devices within the topology, as well
as the process data width and parameter channel width. The ID register is 16 bits
16
for all devices. 16 bits gives an information content of 2 = 65536. As there are
already many different INTERBUS devices and this number is growing all the time,
it is not possible to provide every device with its own ID code. An encoding system
is therefore used, which groups together devices of the same type.
The ID register offers more than just the specification of the process data and
parameter channel width. The ID code can also be used to determine
reconfiguration requirements, CRC errors, and modules errors on INTERBUS
devices. In addition to the standard ID registers, the IBS SUPI 3 chip has other ID
registers, which provide improved error localization. Figure 1.14 shows the
structure of the standard identification register.
15
14
13
Management bit
messages
12
11
10
Data width
Device class
Device type
Data direction
or PCP words
Figure 1.14: Structure of the standard ID register

Table 1.8 to Table 1.11 indicate the meanings of the individual bit combinations in
the standard ID register.
Table 1.8: ID0-ID1 data direction or PCP words
Bit 1
Bit 0 If (ID7 + ID6) <> 1 1 ID1 and ID0 specify the process data width
0
0
1
1
0
1
0
1
0
0
1
1
0
1
0
1
No process data (e.g., bus terminal module)

Only OUT process data
Only IN process data
IN and OUT process data
If (ID7 + ID6) == 1 1 ID1 and ID0 specify the number of PCP words
2 PCP words
4 PCP words
Reserved
1 PCP word
ID2 and ID3 specify the device type. Within a device class, a distinction can be
made, for example, between a DRIVECOM-compatible device or another device of
this class.
30
INTERBUS Basics
Table 1.9: ID4-ID7 device class

Bit 7 Bit 6
Bit 5
Bit 4
0
0
0
0
0
0
1
0
0
0
1
0
0
1
1
0
0
1
x
x
1
0
x
x
1
1
0
x
1
1
1
x
Device Class
Digital remote bus device
Reserved for bus master
Digital remote bus device
Analog remote bus device
Analog local bus device
Digital local bus device
Local bus device with PCP
Remote bus device with PCP
Table 1.10: ID8 - ID12 data width

Bit
Bit 11 Bit 10 Bit 9 Bit 8
12
0
0
0
0
0
0
1
0
0
0
0
0
1
0
0
1
1
0
0
0
0
1
0
0
0
0
1
0
1
0
0
1
1
0
0
1
1
0
1
0
Data Width
0 words
1 word
2 words
3 words
4 words
5 words
8 words
9 words
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
0
0
0
0
1
1
1
1
0
0
1
1
0
0
1
1
0
1
0
1
0
1
0
1
1 nibble
1 byte
3 nibbles
3 bytes
5 nibbles
5 bytes
6 words
7 words
1
1
1
1
1
1
1
1
0
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
0
0
1
1
0
0
1
1
0
1
0
1
0
1
0
1
Reserved
Reserved
16 words
24 words
32 words
10 words
12 words
14 words
Reserved
Table 1.11: ID13 - ID15 management bits

Bit 15 Bit 14 Bit 13
Management Bits
x
x
1
Reconfiguration request
x
1
x
CRC error
1
x
x
Module error, I/O error
Bits 0 to 12 are usually specified by the hardware, i.e., the INTERBUS protocol
chip is set to a fixed ID code. An exception to this rule is the system coupler (e.g.,
ILC 200 IB), which can be assigned an ID code via software (firmware command
Set_Value_Request). The length of the parameter and process data channel for
the slave interface can then be specified. During operation, when the INTERBUS
INTERBUS Basics
31
system is in the RUN state, this ID code must not be changed, as this would
change the summation frame.
The IBS SUPI 3 protocol chip offers a flexible option for setting the ID code
by setting the "P_Not_Ready" ID code. Using "P_Not_Ready" ID codes,
a microprocessor application can then initialize the IBS SUPI 3 without
problem.
Bits 13-15 in Table 1.11 are an exception. They are used for error localization
during operation and for the reconfiguration of individual INTERBUS devices. In the
event of an error, if a data cycle is faulty and an ID cycle is run immediately, the
devices can report the precise error location to the INTERBUS master using bits
13-15.
This is not the case for a reconfiguration request. In this instance there are no
actual errors, but a slave device wants to inform the master, for example, that a
specific part of the system can be started up again. The reconfiguration option is
also found on bus terminal modules. It enables the user to restart specific parts of
the system that have been shut down. A CRC error is generated internally in the
device. After the subsequent ID phase, the device sends the reconfiguration
request to the master via bit 15.
In summary, the INTERBUS master requires ID cycles for the following purposes:
-
To determine the INTERBUS topology
To detect reconfiguration requests
For error localization in the event of CRC and I/O errors
The Interbus Club e.V. is responsible for maintaining, checking, and

expanding the ID codes. An up-to-date list of ID codes can be found on
the accompanying CD-ROM and on the INTERBUS Club website at
www.interbusclub.com.
The length code is used to determine the register length, i.e., the process data
length used in the summation frame. Bits 8 to 12 pass on the data width in
encoded form. The length code, which is determined using bits 8 to 12, is
described in INTERBUS standard DIN EN 50254:1999-07. The length code used
by the user is generated in the master firmware. The main advantage of the user
length code is its easy operation. The length codes do not have to be determined
using a table, but are specified as shown in Figure 1.15.
32
INTERBUS Basics
15
14
13
12
11
Data length
10
Bit 15
0
1
0
1
Bit 14
0
0
1
1
Data length
Word (16 bits)
Byte (8 bits)
Nibble (4 bits)
Bit (1 bit)
Number
Figure 1.15: Structure of the length code

The length code, which is used in the master firmware, is represented in one byte.
Please note that the largest possible data type (word, byte, nibble or bit) must
always be used. For example, for a data length of 2 words, the length code 0x02
must be used, and not 0x82.
1.4.7 Standard Control Register

The INTERBUS system uses the full duplex transmission method. Whenever data
is received, data is also sent. This sent data is referred to as control data during the
ID cycle. Figure 1.16 shows the assignment of individual bits in the control word.
The standard control register is used as an example.
15
14
13
12
11
10
Reserved
Acknowledges module error
Sub ID mode
Extends active ID register in SUPI1
devices by 2 words
Local bus reset (bus terminal modules only)
Remote bus reset
Switches local bus interface, outgoing
interface (bus terminal modules only)
Switches remote bus interface, outgoing
interface (bus terminal modules only)
Alarm, signal on PIN alarm
Error, signal on pin error
Acknowledges the reconfiguration input
Masks the control register
Figure 1.16: Standard control register

The masking bit in bit 15 is used to avoid undesirable switching operations,
whereby 0 indicates the evaluation of the remaining control commands and 1
indicates no evaluation of the remaining control commands.
INTERBUS Basics
33
The standard control register is not the only control register, there are also five
other control registers. These registers will not be considered in detail, as they will
not aid your understanding of the INTERBUS system.
1.4.8 Hybrid Data Transmission

Hybrid data transmission is the simultaneous transmission of INTERBUS data via
the process and parameter data channels. The process data channel, as can be
seen in Figure 1.10, offers fast cyclic transmission of input and output data for the
controlling process. The speed and information content for the data exchange is
very important for the process data channel.
To ensure the optimum use of available resources in the INTERBUS master
(CPU), faulty INTERBUS cycles are not repaired. This is because the repair of a
faulty INTERBUS cycle would use up too many CPU resources. Instead, the old
INTERBUS cycle is rejected and a new INTERBUS cycle is sent.
In addition to the data for the sensors and actuators, i.e., the process data, the
INTERBUS system can also transmit parameter data to the INTERBUS devices.
This parameter transmission always takes place between the INTERBUS master
and a PCP-compatible INTERBUS device.
The parameter channel requires several INTERBUS cycles for one telegram. It
provides non-time-critical acyclic data transmission alongside the fast process data
channel. In an INTERBUS system, up to 8 bytes can be used for the parameter
channel, depending on the INTERBUS module. The user data width is usually
between 1 and 246 bytes. The parameter data is divided into blocks and inserted in
time slots in the summation frame protocol, as shown in Figure 1.17.
The parameter data is split and recombined by special PCP (Peripherals
Communication Protocol) software. Using this technology, extensive parameter
telegrams are transmitted in binary format over several INTERBUS cycles, which
means that they do not adversely affect the realtime-capable communication
properties of INTERBUS.
Header (1 byte)/
data (1, 3 or 7 bytes)
PD:
PCP:
LBW:
FCS:
END:
Header (1 byte)/
Process data
Parameter data
Loop-back-word
Frame check sequence
End identification
Header (1 byte)/
Data (PD)
Parameter data (PCP)
Data (PD)
Data (PD)
Data (PD)
M odule 1
M odule 2
M odule 2
M odule n-1
M odule n
FCS
LBW
End
Figure 1.17: Transmission of parameter data in the summation frame

The parameter channel is used, e.g., to download parameter data from frequency
inverters, devices such as HMIs (Human Machine Interface) or other intelligent
components. As a rule, the parameter channel is only used during startup or when
parameter data records are modified.
34
INTERBUS Basics
If no parameter data is transmitted via the parameter channel, the data areas in the
summation frame remain empty. The length of the summation frame always
remains the same and the deterministic behavior of INTERBUS does not change.
The parameter channel in the INTERBUS system is a message-oriented

communication link between the INTERBUS master and PCPcompatible INTERBUS modules.
A detailed description of the PCP working method and PCP

programming can be found in the IBS PCP UM E User Manual from
Phoenix Contact.
1.4.9 Advantages of the Process Data Channel Compared

With the Parameter Channel
INTERBUS devices, which use the process data channel, usually have a register
length of 2 bits (INTERBUS Inline I/O module) to 64 bits (analog I/O module). The
process data channel is not designed for larger register lengths, because it
drastically reduces the possible number of devices. For larger data volumes, the
INTERBUS system uses the parameter channel. Table 1.12 to Table 1.14 list the
key features of the process and parameter data channels.
Table 1.12: List of the key features of the process data channel
Time-critical data transmission < 10 ms
Cyclic data transmission
Low information content, 2 - 64 bits (except for system coupler)
No correction of telegram errors
Summation frame method for the transmission of process data
Transmission of fast process data: switch positions, motor speed, fast industrial process
Easy access to process data by the user
Data consistency only with synchronous operating modes
Table 1.13: List of the key features of the parameter channel

Non-time-critical data transmission > 10 ms
Acyclic data transmission
Average information content, 1 - 246 bytes
Summation frame method for the transmission of parameter data
Transmission of medium-speed process data: recipe data, parameter data records,
medium-speed industrial process
Correction of telegram errors from the error location (PCP V2.0 or later)
Data consistency over all parameter data
INTERBUS Basics
35
1.4.10 Compact PCP

A change can be seen in the use of the process data channel in practical
applications. Increasingly, users prefer to do without the parameter channel for I/O
and special function modules and instead to exchange all data via the process data
channel. This is because the parameter channel is more difficult to use and also
due to the speed of data transmission.
However, the number of special function modules is still increasing, and there is no
standard procedure for the transmission of parameter data. Many modules have
different communication models via the process data channel (proprietary
communication models). To remedy this problem, Phoenix Contact has
implemented the Compact PCP for the latest INTERBUS devices. Figure 1.18
illustrates the Compact PCP in the ISO/OSI layer model. The key features of the
Compact PCP are listed in Table 1.14.
Standard PCP
Compact PCP
Application
ALI
NMI
Application Layer
Interface
Network Management
Interface
PMS Layer 7
PNM7
Peripherals Message
Specification
Peripherals Network
Management
Application
LLI Layer 3..6

Lower Layer Interface
Encoder/Decoder
PDL Layer 2
PDL Layer 2
Peripherals Data Link
Peripherals Data Link
Figure 1.18: Compact PCP in the ISO/OSI layer model

Table 1.14: List of the key features of the Compact PCP
Safe Layer 2 transmission technology
Connectionless communication without connection establishment (no Initiate_Request
required)
PDU length (data packet) limited to 64 bytes
Supported communication services: Read, Write, and Information Report
Compatibility with existing applications when standard services are used
INTERBUS master firmware Version 4.6: full support of the Compact PCP
INTERBUS master firmware Version < 4.6: connection establishment (Initiate_Request)
required
127 Compact PCP devices are supported
Simple implementation for INTERBUS interface implementors
36
INTERBUS Basics
In firmware Version 4.6 or later, the connection is established in the initial
phase of the INTERBUS system by synchronization protocols. Thereafter
the user does not have to establish a connection. The logical PCP
channel is always connected.
1.4.11 Number of INTERBUS Cycles for the Transmission of

Process Data
Users often want to know about the transmission time and the associated response
time of the INTERBUS system. How many INTERBUS cycles are required in order to
see the set bit in the application at the output module, or how many INTERBUS
cycles are required in order to detect an input in the application program? This
question is answered in Figure 1.19.
The top half of Figure 1.19 illustrates the exchange of process data from the host
system to an output module. It can be seen that the output data arrives at the output
module (Latch out) after one INTERBUS cycle, with sequential transmission under
optimal conditions. In the worst-case scenario, two INTERBUS cycles are required.
Parallel transmission requires one more INTERBUS cycle under the same
conditions.
The transmission of the process data item from the input module to the application is
similar. Again, sequential transmission is one INTERBUS cycle faster.
INTERBUS Basics
37
Host application -> INTERBUS output module
Host application cycle
OUT data is copied
to the MPM
P1
S1
P2
S2
P3
S3
Host
Sequential data
exchange
S1
S2
S3
Parrallel data
exchange
P1
P2
P3
INTERBUS
cycle
S1 P 0
S2 P1
S3 P2
Latch out
Output module
PHOENIX
CONTAC
1 1 1 1 1 11
T re
B1 2 3 4 5 6 7 89
A
R
C
R
D
0 1 2 3 4 56
S 0 P -1
S1 P 0
S2 P 1
ad
y
U
B(
1)
INTERBUS input module -> Host application

Input module
B
A
R
C
R
D
PHOENIX
CONTAC
1 1 1 1 1 11
T
1 2 3 4 5 6 7 89
0 1 2 3 4 56
E1
E2
E3
E4
E5
re
ad
y
U
B(
1)
Latch in
E0
INTERBUS
cycle
E1
E2
E3
Parrallel data
exchange
E0
E1
E2
E0
Sequential data
exchange
E1
E2
E3
Host data transfer for parallel transmission

E -1
E0
E1
E2
Host data transfer for sequential transmission

Host
E0
E1
E2
E3
Figure 1.19: Number of INTERBUS cycles for the transmission of process data
38
INTERBUS Basics
1.4.12 INTERBUS Transmission Speeds

The speed and information content of the data exchange is very important. The
speed or protocol efficiency is one of the criteria used when comparing different
bus systems. It is therefore important to make optimum use of the available CPU
resources. The repair of a faulty INTERBUS cycle would use up too many of these
resources. Consequently, the old cycle is rejected and a new cycle is sent. The
INTERBUS system does very well in this comparison, as can be seen in Table
1.15 [12]. The reason for this is the summation frame telegram, which transmits a
header, FCS, and end telegram for all modules together in one data cycle. In
message-oriented protocols, a separate header, FCS, and end telegram is required
for each module.
Table 1.15: Data throughput for different bus systems [12]
ASI
CAN
PROFIBUS
User data in
3242=
328= 256
328= 256
bits
256
Header in bits
32212=
1254 +
12146+202
768
20100=
01= 5772
2648
Efficiency as %
256/
256/
256/
(256+768) (256+2648)= (256+5772)=
= 25
8.8
4
Baud rate
167 kbps
19 kbps
31.25 kbps
1 Mbps
1.5 Mbps
12.0 Mbps
Data
42 kbps
1.67 kbps
1.25 kbps
throughput
88 kbps
60 kbps
480 kbps
INTERBUS
328= 256
Ethernet
328= 256
1632+385=
238
648322=
32768
256/
(256+238)=
52
500 kbps
2 Mbps
256/
(256+32768)
= 0.77
10 Mbps
100 Mbps
1000 Mbps
77 kbps
770 kbps
7700 kbps
260 kbps
1040 kbps
Even with the comparatively low transmission speed of the INTERBUS system, a
relatively high data throughput can be achieved. Only the Ethernet system
achieves the data throughput of the INTERBUS system, but it requires much higher
data transmission speeds. This means that much greater technical demands are
placed on the Ethernet system.
By default, the INTERBUS protocol operates at a data transmission rate of 500
kbps, which corresponds to a data transmission rate without protocol header of 300
kbps. The technology and firmware of the INTERBUS master is designed so that it
tries to start up the INTERBUS system at 2 Mbps. If this does not work, it tries to
start up the INTERBUS system at 500 kbps. An increase in transmission speed
from 500 kbps to 2 Mbps depends on the system properties of the INTERBUS
modules.
As the protocol efficiency of the summation frame is very high, a lower

data transmission speed can be selected. This makes the system
more robust in terms of EMI in industrial applications. The INTERBUS
system is currently available in 500 kbps and 2 Mbps versions.
INTERBUS Basics
39
1.5 INTERBUS Protocol Chips

INTERBUS protocol chips are the most important electronic components within an
INTERBUS system and provide connections in the INTERBUS controller board and
in the INTERBUS modules. Due to the different requirements placed on the
INTERBUS protocol chips, separate solutions have emerged for the INTERBUS
controller board (master protocol chip) and for INTERBUS modules (slave protocol
chip).
As the INTERBUS system has evolved, a wide range of protocol chips has been
developed due to the continuous improvement of the properties of the INTERBUS
system. Consequently, this section only describes the method of operation,
features, and practical significance of the current protocol chips for Generation 3
and 4 in detail.
The example in Figure 1.20 shows INTERBUS protocol chips assigned to the
INTERBUS master (IPMS) and the remote bus and local bus modules (SUPI).
Remote
bus
IPMS
1
1.0
2
1.1
3
1.2
Local bus
SUPI
SUPI
Bus terminal
module
4
2.0
SUPI
IO
Remote bus
branch
SUPI
Bus terminal
module
5
3.0
Local bus
6
3.1
SUPI
SUPI
IO
Figure 1.20: Protocol chips in INTERBUS components
40
INTERBUS Basics
1.5.1 Master Protocol Chip (IPMS)

The master protocol chip or IPMS (INTERBUS Master Protocol Chip) is the central
element in every INTERBUS controller board. The latest version of the master
protocol chip is IPMS 3. The IPMS 3 is a CMOS gate array, and it has been
designed specifically for use with different processors, such as Motorola M68000,
M68332 or Intel 8051 (8044), 80186 or NEC V25.
The IPMS 3 provides the link between a microprocessor with RAM on one side and
the serial INTERBUS system on the other side. It has two interfaces, the processor
interface and the INTERBUS interface. Figure 1.21 shows the interfaces of the
IPMS 3.
Microprocessor
interface
Data transfer function and

format conversion
Parallel/Serial
Serial/Parallel
INTERBUS
interface
Figure 1.21: Interfaces of the IPMS 3 INTERBUS master protocol chip

The structure of the INTERBUS controller board reflects the ISO/OSI reference
model for fieldbuses, see Figure 1.22, i.e., the IPMS 3 chip provides Layer 2
functions. The serial INTERBUS interface provides the link between Layers 1 and
2. The software and firmware, which provide Layer 7 of the reference model, use
the processor interface of the IPMS 3. The implementation of Layer 2 in a gate
array and the automatic processing of the INTERBUS protocol enables high data
throughput without placing high demands on the firmware in an INTERBUS
controller board.
ISO/OSI
reference model
Layer 7
Firmware
Software
Firmware
INTERBUS
Level shifting
IPMS 3
Layer 2
CMOS/RS485
RS485/CMOS
Layer 1
Figure 1.22: How IPMS 3 reflects the ISO/OSI reference model
INTERBUS
remote bus
cable
INTERBUS Basics
41
1.5.2 Slave Protocol Chips (SUPI)

The slave protocol chip, also called SUPI (Serial Universal Protocol Interface), is
an electronic device, see Figure 1.23, and is the central element of every
INTERBUS remote bus and local bus device. It is required for the integration of
INTERBUS input and output modules into an INTERBUS network. The slave
protocol chip can be used to operate basic modules (e.g., I/O modules) without
additional software or processing power.
Figure 1.23: INTERBUS slave protocol chips

Modern INTERBUS modules primarily use the INTERBUS slave protocol chips
IBS SUPI 3, IBS SUPI 3 OPC, IBS SUPI 2, IBS LPC 2, IBS LPC 1 and the SUPI
expansion IBS SRE 1. Each of these protocol chips is described briefly below.
1.5.2.1
IBS SUPI 3
The IBS SUPI 3 chip (Serial Universal Protocol Interface for Generation 3) has
been available since 1996 and its use is widespread. For INTERBUS connection,
the IBS SUPI 3 can be used to configure the INTERBUS module as a remote bus,
installation remote bus or local bus device. The IBS SUPI 3 controls the entire
summation frame protocol and offers error and diagnostic management. The
hardware features of the IBS SUPI 3 are as follows:
-
Manufacturers: Motorola and Amtel/ES2
Distributors: Phoenix Contact, SEI Jermyn, and Amtel/ES2
Hardware and software-compatible further development of the IBS SUPI 2
ASIC in 0.7 m standard cell technology
Approximately 15,000 NAND gate equivalents (8031 core approximately 6000)
Housing options: PLCC 84-pos. or QFP 100-pos.
Industrial applications: (5 V 10%; -40C to +85C [-40F to +185F])
The IBS SUPI 3 consists of a 16 MHz quartz oscillator, a 16-bit multi-function pin
interface (MFP interface), a transmit and receive buffer for the identification
transmission cycle, a transmit and receive buffer for the data cycle, the diagnostics
and report manager with error detectors, two separate INTERBUS interfaces for
IN/OUT, and the interface to an external shift register. Figure 1.24 shows a block
diagram of the IBS SUPI 3.
42
INTERBUS Basics
The INTERBUS interfaces can be configured according to their requirements as

remote bus or I/O bus interfaces. Depending on the interface implementation
requirements, the MFP interface can be set via four configuration pins as an I/O
port or as a microprocessor interface in a CPU environment. It can be configured
as an INTERBUS bus terminal module interface, as an INTERBUS module
interface with 16 bit of outputs, 16 bits of inputs, 8 bits of inputs and 8 bits of
outputs, or as a microprocessor interface.
The shift register interface can be used to extend the IN and OUT data length of
the IBS SUPI 3. Using the connections ToExR and FromExR, the data registers
can be expanded by 12 bytes for IN and OUT data using external shift registers or
the serial register expansion chip (IBS SRE 1).
The key properties of the IBS SUPI 3 are as follows:
-
Using the diagnostics and report manager with on-chip diagnostics,

diagnostic events are stored until this information has been read and
acknowledged. Precise error and warning indications are given on the
forward and return path for fiber optic cables (MAU) and the CR check is
transmitted on the forward and return path during data transmission. The
detection of short-term voltage dips and the transfer of diagnostic
information to the INTERBUS controller board is better than for the
IBS SUPI 2.
It is possible to distinguish between I/O device and microprocessor

watchdog errors.
Internal filters are provided on all quasi-static inputs.
The IBS SUPI 3 uses fewer external components than the IBS SUPI 2, and
the external wiring is reduced.
The method of operation of the diagnostics and report manager in the IBS SUPI 3
can be described as follows. All event information, which is generated in the
INTERBUS system, must be transmitted to the INTERBUS master for the
diagnostic display. A distinction must be made here between high-priority events
such as CRC errors or power-up, which are transmitted to the INTERBUS master
immediately, and I/O errors, reconfiguration requests or MAU warnings, which are
low-priority events and are reported to the INTERBUS master in every 16th
INTERBUS cycle. All events remain stored in the report manager until they are
acknowledged by the INTERBUS master or a hardware reset is triggered.
The IBS SUPI 3 is supported by every INTERBUS controller board of

INTERBUS firmware Generation 2 to 4. However, it should be noted
that the controller board driver software supports IBS SUPI 3 modules.
INTERBUS Basics
43
MFP (0:15)
MFP interface
ID transmit/recieve
buffer
Oscillator
ID address
Data transmit/
recieve buffer
0 ID control
1
2
3
4
5
6
7
Address
0 Data control
1
2
3
4
5
6
7
To ExR
MAC sublayer
From ExR
Error detectors
Diagnostics
and report
manager
MIS sublayer
MDS
1
MDS
2
MAU
MAU
MDS
3
MAU warning
Transmission medium
Figure 1.24: IBS SUPI 3 INTERBUS protocol chip

1.5.2.2
IBS SUPI 3 OPC
The IBS SUPI 3 OPC (Optical Protocol Chip) is another slave protocol chip in the
SUPI 3 family. It can be used to develop all the same device classes (digital
modules, bus terminal modules, and intelligent I/O) as the IBS SUPI 3. The
difference between this chip and the IBS SUPI 3 is its high level of operational
reliability and diagnostic capability for optical signal transmission (fiber optics).
The IBS SUPI 3 OPC protocol chip is an ASIC in 0.6 m CMOS technology with
approximately 15,000 gate equivalents. It can be used to implement 2-wire remote
bus and 2-wire local bus devices. The IBS SUPI 3 OPC differs from the IBS SUPI 3
in particular through its support of optical transmission methods. These include:
44
INTERBUS Basics
Optical power regulation for fiber optic transmitters
Optical transmission diagnostics
Automatic bus connector recognition (RBST/LBST) for copper and fiber optic
transmission
Automatic recognition of the control function on other units or devices
Online regulation adapts the transmission power to modifications in the

transmission characteristics and ensures an adjustable system reserve.
The IBS SUPI 3 OPC offers optical path diagnostics, e.g., with IBS CMD >= 4.50,
as shown in Figure 1.25. The distances, the current power level, and the enable
status of the optical regulation can be read cyclically or automatically. The collected
data can be saved in ASCII files for later evaluation. To use this feature, please
activate the orm.dll in the IBSCMD menu.
Figure 1.25: Optical INTERBUS path diagnostics in IBS CMD 4.50

On optical transmission with the maximum permitted transmitter output
power (level 15), no further reserve is available to increase the power.
The transition to the maximum power level (from level 14 to level 15)
triggers the "MAU WARNING" diagnostic state. This signals a critical
power reserve, at which transmission is still (just) possible without
errors.
INTERBUS Basics
1.5.2.3
45
IBS SUPI 2 and Older Slave Protocol Chips
Older INTERBUS modules operate with slave protocol chips such as the SIOC
(from 1988), SUPI 1 (from 1990), and the IBS SUPI 2 (from 1992). As these slave
protocol chips are no longer up-to-date, this section only provides a brief
comparison of the properties of IBS SUPI 2 and IBS SUPI 3, in Table 1.16.
Table 1.16: Comparison of the IBS SUPI 2 and the IBS SUPI 3
IBS SUPI 2
IBS SUPI 3
1.0 m sea-of-gate technology
0.7 m standard cell technology
Approximately 7,000 NAND equivalents
Approximately 15,000 NAND equivalents
Standard Intel microprocessor interface
Universal Intel microprocessor interface
Unfiltered control inputs
Filtered control inputs
No mask separation
Clear mask separation
Standard driver outputs (2/4 mA)
Powerful driver outputs
for LEDs BA, RD, etc.
(12 mA) for LEDs BA, RD, etc.
Only hardware-controlled ID code
Additional ID code SET register
Available as SUPI 2 only from OKI
Second source available (Motorola,
AMTEL/ES2)
No diagnostics and report manager
Complex diagnostics and report manager
More cost-effective
1.5.2.4
IBS LPC 2 and IBS LPC 1
INTERBUS protocol chips IBS LPC 2 and IBS LPC 1 (Loop Protocol Chip) were
specifically designed for the INTERBUS Loop, which is a cost-effective solution
with a reduced amount of cabling for the direct integration of sensors, actuators,
and other I/O devices into the INTERBUS system.
The IBS LPC 1 is an ASIC in 0.7 m CMOS technology with approximately 6,800
gate equivalents and is a Generation 4 INTERBUS slave protocol chip. This means
that the IBS LPC 1 has a diagnostics and report manager to provide INTERBUS
diagnostics. In addition, the IBS LPC 1 has been adapted to meet the requirements
of the sensor and actuator level, which requires simple external wiring and a low
housing
weight.
Figure 1.26 shows the IBS LPC 1 and IBS LPC 2 Loop protocol chips.
Figure 1.26: IBS LPC 1 and IBS LPC 2 INTERBUS Loop protocol chips
The IBS LPC 2 is the further development of the IBS LPC 1 and has an extended
range of functions. For startup and diagnostics, monitoring functions have been
integrated, which enable device-oriented local bus diagnostics. The integration of
analog modules and the external wiring have also been simplified. The following
modifications also affect practical applications: a new diagnostics and report
manager, doubling of the cable path supported between two Loop devices to 20 m
(65.62 ft.), doubling of the total length of the Loop ring to 200 m (656.17 ft.),
46
INTERBUS Basics
doubling of the number of devices supported to 63, and an increase in the current,
which can be tapped from the Loop 2 ring, to 1.8 A (IBS LPC 1: 1.5 A).
Master firmware Version > 4.0 is required for the use of the IBS LPC 1
protocol chip in an INTERBUS system.
INTERBUS Loop modules (IBS LPC 1) cannot be operated in an
INTERBUS Loop 2 system (IBS LPC 2). However, INTERBUS Loop
modules can be operated in an INTERBUS Loop 2 system with master
firmware Version > 4.4.
1.5.2.5
IBS SRE 1
The IBS SRE 1 (Serial Register Expansion chip) was specifically developed in 1994 as
a register expansion for the IBS SUPI 2 INTERBUS slave protocol chip. However, it
can also be used for the IBS SUPI 3 and the IBS SUPI 3 OPC. The IBS SRE 1, as
shown in Figure 1.27, is an ASIC in 1.5 m CMOS technology with approximately
4,000 gate equivalents and has a serial input, a serial output, and an interface to the
microprocessor for loading and reading the INTERBUS memory area.
Its task is to extend the data length of the internal slave protocol chip. Using a
microprocessor, it provides access to a maximum of six additional IN and OUT data
words. The IBS SRE 1 is also used in other applications.
Figure 1.27: IBS SRE 1 INTERBUS protocol chip
1.6 Generation 4 INTERBUS Firmware

As shown in Figure 1.21 and Figure 1.22, the INTERBUS firmware is the responsible
software on the INTERBUS controller board and therefore the link between the
microprocessor with RAM on one side and the serial INTERBUS system on the other
side. Its main function is the control of INTERBUS data transmission.
INTERBUS Generation 4 (G4) firmware was released in 1996. It remains the valid
firmware for the current Version 4.6 (as at March 2002). G4 firmware is considerably
more powerful than the previous version G3 and has been developed to meet
additional requirements. The firmware services have been restructured, and the state
machine and startup behavior have been modified. These modifications are not
backward compatible, i.e., programs, which were created using G3 firmware cannot be
operated using G4 firmware. However, the huge advantages of G4 firmware easily
outweigh this small disadvantage. The service codes are valid for all Generation 4
INTERBUS controller boards, because the IPMS chip (INTERBUS Master Protocol
Chip) from Phoenix Contact is almost always used.
INTERBUS Basics
47
1.6.1 Startup Behavior for Generation 3 and Generation 4

Firmware
An important difference between G3 and G4 firmware is the startup behavior.
INTERBUS users can find a detailed description of all service codes for G4
firmware in the Phoenix Contact G4 firmware manuals.
The order designation for the G4 firmware manual is IBS SYS FW

G4 UM E - Firmware Services and Error Messages. The G3
firmware manual is IBS PC CB HW UM E - Controller Board
Hardware and Firmware for IBM-Compatible PCs.
Table 1.17: Startup behavior for Generation 3 and Generation 4 firmware

Firmware
Generation 3
firmware
Startup Behavior
After a power up or reset, Generation 3 firmware tries to physically read the
bus devices and to store a valid configuration frame in the RAM. If the bus
is not operable, the controller board starts up with an error.
The user can then send a Start_Interbus request to place the INTERBUS
system in the RUN state, provided that a valid configuration frame has
been generated.
Generation 4
firmware
After a power up or reset, Generation 4 firmware is in the READY

state and waits for further inputs. When the Create_Configuration
service is activated, the bus is physically read and stored in the
RAM as a valid configuration. The controller board is now in the
ACTIVE state. A subsequent Start_Data_Transfer request places
the bus in the RUN state.
1.6.2 Differences in Service Codes for Generation 3 and 4

Generation 3 Firmware:
There is no clear assignment in the command codes between confirmation and
request codes. As can be seen in Figure 1.28, the request code is the
Start_Interbus service 0001hex. The positive confirmation is 0088hex, and the
negative confirmation is 00E3hex.
Request: 0001(hex)
Client
Server
Confirmation: 0088hex (positive)

00E3hex (negative)
Figure 1.28: Request and confirmation for G3 firmware commands

The user must have an in-depth knowledge of the confirmation codes and be able
to distinguish between a positive and negative confirmation using the codes.
Services, which do not make sense to the user in the current controller board
status are acknowledged as positive. For example, if another Start_Interbus
48
INTERBUS Basics
request is sent while the system is in the RUN state, the service confirmation would
be 0088hex. Some service codes have no negative confirmation.
Generation 4 Firmware:
The command structure has been restructured. Each confirmation is clearly
assigned to the request code, as shown in Figure 1.29. In this example, the
request code for the Start_Data_Transfer service is 0701hex. The positive
confirmation is 8701hex, and the negative confirmation is also 8701hex. The result of
the service processing and other information is included within the confirmation.
Request: 0701(hex)
Client
Server
Confirmation: 8701hex (positve)

8701hex (negative)
Figure 1.29: Request and confirmation for G4 firmware commands
In Generation 4, bit 15 of the service code (request) is always zero. This bit is set
for the confirmation. The user can therefore always determine the confirmation
code by "logically ORing" the service code with 8000hex.
Services, which do not make sense to the user in the current controller board
status are acknowledged as negative. For example, if a Start_Data_Transfer
request is sent in the RUN state, the confirmation will indicate to the user that this
service is not permitted in the current controller board status.
1.7 Multi-Port Memory (MPM)

The MPM (Multi-Port Memory) is the transfer memory between the INTERBUS
master controller board and the host system, as shown in Figure 1.30. The host
interface is adapted to the relevant host system for every INTERBUS master
controller board, whereas the MPM and INTERBUS master core remain the same
for all controller boards. This common transfer memory can be provided in the form
of the DPM (Dual-Port Memory) for connecting two devices (INTERBUS master
and host system), or the MPM for connecting up to four devices (INTERBUS
master, host system, and coprocessor).
Note: On some INTERBUS boards (e.g., ILC 200 IB), the MPM or DPM is
completely emulated by the RAM. This applies to all controller boards, which only
have one node.
INTERBUS Basics
49
1.7.1 Structure of the MPM

From the user's point of view, the MPM has four main parts: memory management,
static RAM (SRAM), status and control registers, and the serial data channel.
1
1.0
2
1.1
3
1.2
4
1.3
5
2.0
Remote bus
branch
6
3.0
Remote bus
devices
9
4.0
10
4.1
11
4.2
7
3.1
8
3.2
12
4.3
Figure 1.30: MPM interfaces

The internal MPM control logic controls access to the MPM. Prioritized assignment
ensures access without conflicts. It is not permitted for every MPM accessor to
access the MPM at the same time. The MPM accessors must ask the MPM
controller for access permission. The MPM accessor then receives confirmation
from the MPM controller when access is permitted.
The accessor priority depends on the slot used and therefore on the device
number. The assignment of access ensures that every node can access the MPM
and will not be superseded by a higher-priority node. Node 0 can access the MPM
most often, followed by node 1. Node 2 and node 3 have the same level of access
after nodes 0 and 1.
50
INTERBUS Basics
Every access to the MPM is also monitored in terms of time. If an MPM accessor
takes too long for an access, a timeout is generated. The MPM is then enabled
again for the other accessors. The timeout flag can be requested in the MPM
registers.
This system does not have to follow the usual order, where the host
system is device number 0 and the coprocessor is device number 2. For
example,
the
IBS 24 RFC 486 DX-I/T controller from Phoenix Contact has the
coprocessor as node 0.
1.7.2 MPM Memory Management

As can be seen in Figure 1.31, the addressable area of the MPM is 512 KB. The
address area from 0x00000 to 0x0FFFF is of special importance. This area
consists of a static RAM, which contains the hardware and software registers. In
the remaining area, up to 256 pages can be displayed. Their size is not specified,
and they can be used to access various storage media (RAM, function decoder,
memory card). The hardware registers are used to switch between pages. The
address area from 0x00000 to 0x0FFFF cannot be accessed by switching between
the pages and is available to all MPM accessors as a communication area.
Page 0 - Page 255
0x7FFFF
256 KB, maximum
0x40000
0x3FFFF
192 KB
0x10000
0x0FFFF
64 KB, maximum
Static RAM (SRAM)
0x00000
Figure 1.31: MPM memory segmentation
INTERBUS Basics
51
1.7.3 Static RAM in the MPM

0xFFFF
XDTA Node 3
0xEC00
0xEBFF
MXA Node 3
0xD000
0xCFFF
XDTA Node 2
0xBC00
0xBBFF
MXA Node 2
0xA000
0xBFFF
XDTA Node 1
0x8C00
0x8BFF
MXA Node 1
Signal Interface or XDTA

The addresses from 0x0 to 0x3FFF must
be available to the MPM, all other areas
are optional. The precise segmentation of
the MPM for a controller must be read for
each controller board using the MPM
discriptor. However, the user does not
usually need to know the precise
segmentation because the DDI driver has
mechanisms, which enable it to address
the XDTA of a controller, see Section
1.11, Task 4.
0x7000
0x6FFF
XDTA Node 0
0x5C00
0x5BFF
MXA Node 0
0x4000
0x3FFF
0x3F00
0x3EFF
0x3200
0x31FF
Hardware register
Software register
Extended DTA and/or

mailbox area (MXA)
0x2000
DTA IN AREA
0x1000
DTA OUT AREA
0x0000
0x3EFF
0x3B60
0x3B5F
0x3840
0x383F
0x3520
0x351F
0x3200
0x1FFF
0x1C00
0x1BFF
0x1800
0x17FF
0x1400
0x13FF
0x1000
0x0FFF
0x0C00
0x0BFF
0x0800
0x07FF
0x0400
0x03FF
0x0000
Software register for Node 3

Accessor 1 -> Accessor 3

Accessor n -> Accessor 0
Accessor 0 -> Accessor n
Figure 1.32: Segmentation of the SRAM

The static RAM (SRAM) always occupies the address area 0x00000 to 0x0FFFF of
the MPM and is not covered by the memory management of the MPM. This means
that all MPM accessors can use this area as a communication interface. Data is
exchanged via the DTA (data area), XDTA (extended data area), and MXA
(mailbox area). The segmentation and size of these individual areas is specified by
the MPM firmware manager rather than being predetermined by the hardware. This
52
INTERBUS Basics
SRAM segmentation can be read via the MPM descriptor, which is generated by
the master firmware for every node. This should be taken into account during driver
development, because the SRAM segmentation might change.
Data, which is to be transmitted from one node to another node, can be written to
the relevant areas of the data area (DTA IN and OUT area), as shown in the righthand column in Figure 1.32.
The node to the left of the "-> - Operator" can write to this memory area and the
node to the right of the "-> -Operator" can read from this memory area.
For example, node 0 (host system) transmits data to node 1 (INTERBUS master).
Node 0 writes the data to the area 0x0000-0x03FF. Node 1 reads this data starting
from address 0x0000.
The exception is the ISA FC 486DX/I-T controller board. The areas from which
OUT and IN data can be read are shown in Figure 1.33.
0xFFFF
0xEC00
0xEBFF
Node 2:
ProConOS output data (Q)
Node 1:
INTERBUS master
input data
Node 0
0xD000
Node 1:
INTERBUS master
output data
Node 0
0xBC00
0xA000
Node 2:
ProConOS input data (I)
0x8C00
0x7000
Node 0
0x5C00
0x2000
0x1C00
Node 2:
ProConOS output
data (Q)
0x1800
0x1400
0x1000
0x0C00
Node 1:
INTERBUS master
input data
0x0800
0x0400
0x0000
Node 1:
INTERBUS master
output data
Node 0:
INTERBUS input data is read here
for PC processing
Node 2:
Input data (I) for
ProConS
Node 0:
INTERBUS input data is read here
for PC processing
Figure 1.33: MPM segmentation for the ISA FC 486DX/I-T
INTERBUS Basics
53
1.7.4 MPM Status and Control Registers

The address area from 0x03F90 to 0x03FFF contains a range of hardware
registers, which provide status information or can be used to generate interrupts
between the nodes. These status and control registers are available to all MPM
accessors.
1.7.5 Serial Data Channel of the MPM

The MPM has a serial channel, which can be used to read data serially into the
MPM registers and to output data from the MPM. A serial EEPROM and an I/O
shift register can be connected to the serial data channel. Configuration data can
be written, read or stored on the EEPROM or shift registers via the serial data
channel.
1.7.6 MPM Communication Options

Figure 1.34 illustrates the various communication options for the MPM. Although
this diagram only shows communication between two nodes, the INTERBUS
master and the host system, communication with other nodes is identical.
The following communication methods are used:
-
Data Interface
Mailbox Interface
SysFail requests
Signal Interface
Synchronization request
Synchronization
interrupt
SysFail interrupt
Signal interrupt
Mailbox handshake
interrupt
Application program on the host system
DTI
MXI
SGI
DDI
Data Area (DTI)
Mailbox area (MXA)
Signal area (SGA)
MPM
INTERBUS master firmware
Figure 1.34: Diagram of the various MPM communication options
54
INTERBUS Basics
1.7.7 Data Interface (DTI)

The DTI provides read or write access to the DTA or XDTA data area for all MPM
accessors. The DTA contains the process data for INTERBUS modules and the
XDTA contains application-specific data. The data in the DTA/XDTA is updated on
every INTERBUS cycle.
No handshake is specified for exchanging data via the DTI., which means
that while one node is reading, another node may overwrite this data,
causing a problem in terms of data consistency. To solve this problem, a
separate transmission protocol should be used, e.g., "Asynchronous with
synchronization pulse", see 1.8 "Process Data Channel Operating
Modes", or alternatively a data consistency of greater than 16 bits
(default) must be set for a specific data item.
1.7.8 Mailbox Interface (MXI)

The mailbox interface provides a protocol-oriented interface, which can be used to
exchange messages between nodes. A protocol is implemented in the MPM, which
is used to transmit and read messages safely.
The mailbox interface consists of the mailbox area (MXA) and the hardware and
software registers. These areas are specified by the MPM master firmware
manager and can be read by the MPM descriptor, see 1.7.13 "MPM Descriptor".
The mailbox area is divided into several mailboxes. Each of these mailboxes can
hold 1 KB of data. Communication is via service primitives (request, indication,
response, confirmation).
1.7.9 SysFail Request

The SysFail request is used to display serious system errors. The communication
partner can react to this SysFail request accordingly (e.g., stop the current action
and wait until the SysFail is reset). The SysFail signal can be triggered either by
hardware, via the MPM control lines or by software, by writing to the SysFail
register. All nodes receive the SysFail via an interrupt, which is reported by setting
a bit in an MPM register.
1.7.10 Signal Interface (SGI)

The signal interface enables the bit-controlled activation of parameterized firmware
services. The SGI can even receive bit-controlled messages. The signal interface
is divided into the standard signal interface (SSGI) and the extended signal
interface (XSGI). The SSGI contains services already parameterized by the master
firmware (standard function start register), while the XSGI offers the user the option
of controlling selected services using bits. The bit-controlled activation of
parameterized services is supported by the CMD/PC WORX software tools.
1.7.11 Synchronization Request

A synchronization interrupt can be sent to any node. The meaning of this signal is
left entirely to the user. In practice, this signal is used to synchronize the nodes
INTERBUS Basics
55
during data exchange. It can be implemented so that all data in the summation
frame is made available consistently to the application.
1.7.12 Extended Data Area (XDTA)

The XDTA is a special memory area in the MPM. This area was first provided for
use with the IEC 61131 controller, because external access to ProConOS is more
difficult than the use of standard high-level language drivers from Phoenix Contact.
Standard drivers can be used to access this memory area, which makes it easier to
use the XDTA. Users who already program SC controllers from Phoenix Contact
can therefore quickly program a visualization, for example in MS Visual Basic.
However, even inexperienced users can quickly program data exchange via the
XDTA.
Complete DDI programming examples for XDTA access can be found

on the accompanying CD-ROM as source code and as an operational
program.
Table 1.18: Basic specifications for the XDTA interface

Communication paths
ISA bus, Ethernet
Memory size
5 (4*) KB for both data directions, * ILC 200 IB
Data consistency
Byte consistency
Supported controller boards
All PC plug-in boards, all Ethernet controllers
Scope of validity of variables in PC

WORX
Only global variables

(VAR_EXTERNAL, VAR_EXTERNAL_PG)
Supported operating systems
MS-DOS, MS Windows NT, MS Windows 2000
Access to the Field Controller XDTA
In PC WORX (Version 2.02 or earlier), access to the XDTA is specified in

the "Connection Point" column in the Global Variables Explorer. A number
instead of a process data linkage (e.g., 1000) indicates to the I/O driver
that this data item should be shifted to the XDTA. The available area is
from 0 to 5119, which corresponds to an addressable data area of 5 KB.
The exception is the ILC 200 IB, with 4 KB of data.
56
INTERBUS Basics
1.7.13 MPM Descriptor

The MPM descriptor specifies the division of the mailbox area (MXA) and the
software registers for every node. The MPM descriptor is generated by the MPM
master firmware manager. Every node can read its valid MPM descriptor using the
slot number.
Address of the MPM descriptor for node 0:
0x3200 + (node no. * 0x320) + 0x240
Address of the MPM descriptor for nodes 1, 2, and 3:
0x3200 + (node no. * 0x320) + 0x26A
This data gives the following start addresses for the MPM descriptor for the
individual nodes:
Node 0: 0x3440
Node 1: 0x378A
Node 2: 0x3AAA
Node 3: 0x3DCA
Note for the development of your own device driver: The device driver for
the host system should be designed so that the MPM descriptor for the
INTERBUS controller board is read and the returned addresses are used
(because the master firmware could, in theory, reset the parameters for
individual areas of the SRAM).
In practice, the data from the relevant address is transferred to the following
structure (load pointer for the structure with the memory address of the MPM
descriptor):
typedef struct {
USIGN16 StartAddrDTA;
/* Start address of a DTA subrange*/
USIGN16 DTALength; /* Length of a DTA subrange*/
} T_DTA_ENTRY;
typedef struct {
USIGN16 StartAddrDTA;
USIGN16 DTALength;
USIGN16 StartAddrExDTA;
USIGN16 ExDTALength;
USIGN16 StartAddrMXA;
USIGN16 MXALength;
T_DTA_ENTRY Data[2][4];
USIGN16 SVR[2][4];
*/
USIGN16 AVR[2][4];
registers */
USIGN16 SNR[2][4];
} T_NODE_INFO;
/* Start address of the data area */

/* Length of the data area in bytes */
/* Start address of the extended data area */
/* Length of the extended data area*/
/* Start address of the mailbox area*/
/* Length of the mailbox area in bytes*/
/* Division of the data area */
/* Addresses of the send vector registers
/* Addresses of the acknowledge vector
/* Addresses of the subnode registers*/
INTERBUS Basics
57
The MPM descriptor for node 0 is given here as an example:

StartAddrDTA
DTALength
StartAddrExDTA
ExDTALength
StartAddrMXA
MXALength
Data[0][0]
Data[0][1]
Data[0][2]
Data[0][3]
Data[1][0]
Data[1][1]
Data[1][2]
Data[1][3]
0x0000
1024
0x5C00
5120
0x4000
7168
StartAddrDTA
DTALength
StartAddrDTA
DTALength
StartAddrDTA
DTALength
StartAddrDTA
DTALength
StartAddrDTA
DTALength
StartAddrDTA
DTALength
StartAddrDTA
DTALength
StartAddrDTA
DTALength
0xFFFF
0000
0x0000
1024
0x0000
1024
0x0000
1024
0xFFFF
0000
0x1000
1024
0x1000
1024
0x1000
1024
Table 1.19: Start addresses of the MPM descriptor for the individual nodes:
Node
0
1
2
SVR[0][0 - 3]
0x0000
0x342A
0x342C
SVR[1][0 3]
0x0000
0x3772
0x3A92
AVR[0][0 - 3]
0x0000
0x3432
0x3434
AVR[1][0 3]
0x0000
0x377A
0x3A9A
SNR[0][0 - 3]
0x0000
0x343A
0x343C
SNR[1][0 3]
0x0000
0x3782
0x3AA2
3
0x0000
0x0000
0x0000
0x0000
0x0000
0x0000
A tool and the source code for reading the MPM descriptor for every node
can be found on the accompanying CD-ROM. This tool can read the MPM
descriptor of every controller board. It uses the diagnostic interface (RS232) of the controller board and can be operated independently of the
host system.
1.8 Process Data Channel Operating Modes

The INTERBUS system offers several options for making the process data image
available to the application. In some applications, the selection of the correct
operating mode may even be decisive for the success of the process. The
operating modes differ in their update behavior for the process data from the
INTERBUS master to the application process. An overview of the possible
58
INTERBUS Basics
operating
modes
for
Figure 1.35 and Table 1.20.
the
INTERBUS
system
is
given
in
This section only describes the properties of the different operating

modes, and does not describe their implementation in a driver or the
conversion of an existing driver to another operating mode. Conversion
to or implementation of an operating mode other than "Standard
asynchronous" is very complex and requires support from Phoenix
Contact.
Asynchronous
- Sub-operating mode: "Asychronous with synchronization pulse"
- Sub-operating mode: "Asynchronous with signal protocol"
Bus-synchronous
Process data channel

operating modes
Program-synchronous
Figure 1.35: Overview of process data channel operating modes

Table 1.20: Process data channel operating modes
Operating Mode
Description
Asynchronous
The INTERBUS master process data update is synchronous to the
bus cycles, but asynchronous to the application process access
mechanisms to the process data image. In this operating mode, a
maximum data consistency of 64 bits can be achieved. However,
using the sub-operating modes of asynchronous transmission, the
process image of the entire summation frame for the application
process can be kept consistent. The INTERBUS master transmits the
Bus-synchronous
Programsynchronous
INTERBUS cycles equidistantly. The 1 s time-slot pattern is used to

initiate the bus cycles.
The process data update is again synchronous to the bus cycles.
However, the INTERBUS master transmits a synchronization pulse to
the application process at the start of every bus cycle. This enables
the application to synchronize with the process data. In this operating
mode, a data consistency of the entire summation frame can be
achieved. The INTERBUS cycles and the synchronization pulse are
equidistant and can be set to a time-slot pattern of 1 s.
The application process initiates every bus cycle with a trigger pulse.
The INTERBUS master transmits and updates the process data
synchronously to the trigger pulses from the application process. In
this operating mode, a data consistency over the entire summation
frame can again be achieved. The user must ensure the equidistant
transmission of process data.
INTERBUS Basics
59
Four times are particularly important for the INTERBUS operating modes. They are
the default cycle time, the bus warning time, and the bus and application timeout
times. To aid understanding of the operating modes, these times are described
overleaf.
1.8.1 Times for the INTERBUS Operating Modes

Default Cycle Time (Update Time)
The default cycle time is used in the asynchronous and bus-synchronous operating
modes. It must be greater than the minimum cycle time for the relevant bus
configuration. It is defined as the time that should elapse between the start of two
bus cycles. If the specified value is too low or if no value is selected, the minimum
cycle time is used as the default cycle time. The INTERBUS master calculates the
minimum cycle time using the connected configuration during an ID cycle. The
parameter value used is a 32-bit value, which can be set in a time-slot pattern of 1
s. In bus-synchronous operating mode, the synchronization pulse is generated
using this timer.
Bus Warning Time
If a data transmission error occurs in the INTERBUS system, a warning is
generated after the bus warning time has elapsed. The bus warning time is defined
as the maximum time that may elapse between two valid data cycles before the
warning bit in the diagnostic status register indicates to the application program
that the transmission quality has deteriorated. If this time is exceeded, the
INTERBUS system only enters the STOP state if the bus timeout time is exceeded.
By default, the bus warning time is deactivated, i.e., the standard value is 0. The
parameter value used is again a 32-bit value, with a time-slot pattern of 1 s.
Bus Timeout Time
If an error lasts longer than the bus timeout time, it is a fatal bus error. The outputs
are reset and the error is located. The bus timeout time is defined as the maximum
time that may elapse between two valid data cycles. By default, the bus timeout
time is set to 20 times the default cycle time, which must still be a minimum of
200 ms. Figure 1.36 illustrates these three monitoring times.
Data cycles
IBS
cycle
IBS
cycle
IBS
cycle
IBS
cycle
Default cycle
time
Bus warning time
Bus timeout time
Figure 1.36: Monitoring times
IBS
cycle
60
INTERBUS Basics
Application Timeout Time

The application timeout time is used only in "Asynchronous with synchronization
pulse" operating mode. It is defined as the maximum time that may elapse between
the synchronization pulse sent to the host system and the synchronization pulse
received by the INTERBUS master. If this time is exceeded, a fatal bus error has
occurred. This time cannot be set by the user. It is set to (0.8*bus timeout time) or
100 ms, whichever is lower.
The monitoring times can be edited easily using IBS CMD/PC WORX.
The dialog box for these settings, Figure 1.37, can be found in the
controller board context menu under "Settings".
Figure 1.37: "Bus Operation" settings dialog box in IBS CMD G4
1.8.2 Parallel and Sequential Transmission of Process Data

A description of the parallel and sequential transmission of process data will aid
understanding of the various operating modes. Using parallel or sequential
transmission, it is possible to determine the point in time at which the process data
is copied to or from the MPM, see Figure 1.38.
For sequential transmission, the process data is read from the MPM (host OUT
data) before the start of an INTERBUS cycle, and it is copied to the MPM
(INTERBUS device IN data) at the end of an INTERBUS cycle.
INTERBUS Basics
61
For parallel data exchange, the process data is read from the MPM (host OUT
data) and is written to the MPM (INTERBUS device IN data) after an INTERBUS
cycle has started.
INTERBUS system cycle time
Data cycle
INTERBUS
cycle
INTERBUS
cycle
INTERBUS
cycle
Parallel I/O
data exchange
IN
IN
OUT
OUT
IN
OUT
Sequential I/O
data exchange
OUT
IN:
IN
IN data is read
from the
INTERBUS master
OUT
OUT:
IN
OUT data is
transmitted to the
INTERBUS master
OUT
INTERBUS cycle: Complete INTERBUS I/0

cycle
Figure 1.38: Parallel and sequential transmission of process data

Parallel transmission is the basic setting for all process data. Firmware services
can be used to switch the process data transmission to sequential transmission.
A different transmission method can be set for each process data item.
This means that a combination of parallel and sequential transmission is
supported. In practice, this is hardly ever used.
Due to the copying procedures before and after an INTERBUS cycle, the
INTERBUS cycle time is longer for sequential transmission than it is for
parallel transmission. A better response time compensates for this
difference.
1.8.3 Asynchronous Operating Mode

Asynchronous operating mode is the most commonly used INTERBUS system
operating mode. This operating mode is sufficient for most application processes
where a data consistency of just a few process data objects is required. This
operating mode is the fastest mode in terms of the INTERBUS cycle time because
it does not use a handshake. The host system and INTERBUS master run
asynchronously.
In this operating mode, a data consistency of maximum 64 bits can be set via the
master firmware. These settings can be made easily, e.g., using IBS CMD
configuration software. The data consistency must be specified after the process
data address using ":Data consistency". An example of 32-bit data consistency
62
INTERBUS Basics
from address 100 is the assignment 100:32. Without the relevant configuration
software, the master firmware service 0x0325 (load process data reference list)
should be used. This entry is used to program the function decoder of the MPM,
which ensures the relevant data consistency. With the function decoder, several
accesses can be made to the MPM in succession. The function decoder locks the
MPM for the other nodes until all the accesses have been completed. If the MPM
timeout time is exceeded, an MPM timeout is triggered. An error message is
generated and the MPM is then enabled again. The adjustable data consistency
only applies to addresses 0x0000 0x01FFF (8 KB).
The relevant INTERBUS driver in the host system must also be set to the required
data consistency so that addresses are accessed accordingly.
With a data consistency of 64 bits on a PC host system on which the
INTERBUS driver is also running, please note that an interrupt from a
higher
IRQ
(e.g., NMI Non maskable interrupt) may take place while the driver is
copying data from the MPM.
Data consistency for PC WORX controller boards (Version 2.0x):

For standard data types, the data consistency is the same size as the
data type itself. For example, an integer variable has a data consistency
of
16
bits.
Table 1.21 below applies for user-defined data types.
Table 1.21: Data consistency for user-defined data types
Size of the data type in bits
Data consistency in bits
8
8
16
16
32
32
48
8
64
64
>64
8
The MPM timeout message to the host system is adjustable and is

deactivated by default. A set value request leads to the following
parameterization:
0x0750 Set value
0x0004 Parameter_Counter
0x0001 Variable_Counter
0x221A Variable_ID
0x0000 Value
0x0001 Value (1: enable, 0: disable)
In the rest of this section, the handshake bits are referred to by name in the
diagrams.
Table 1.22 shows the relevant registers with the appropriate handshake bits.
INTERBUS Basics
63
Table 1.22: List of the registers used in this section

Register Name
MPM Address
Note
Diagnostic status
register
0x3520
Standard function
start register
0x3524
Synchronization result
bit
Data cycle result bit
Cons activate bit
Application busy bit
Data cycle activate bit
Standard function
status register
0x3526
1.8.3.1
Bit
Bit 15
Bit 12
Bit 15 (asynchronous)
Bit 14 (bus-synchronous)
Bit 14 (programsynchronous)
Bit 15 (asynchronous)
Cons state bit
Synchronization pulse Bit 14 (bus-synchronous)
bit
Bit 14 (programData cycle state bit
synchronous)
Asynchronous With Signal Protocol Operating Mode
In this sub-operating mode of asynchronous operating mode, access to the

coupling hardware (MPM) is disabled so that the host system application can
access the entire process image consistently. A handshake is performed with the
INTERBUS master.
Section
1
1...
Cons active
bit (host)
Cons state bit
(INTERBUS
master)
Application
(host)
IN:
IN data is read from the

INTERBUS master
IN
O UT
OUT: OUT data is transmitted to

the INTERBUS master
Figure 1.39: Asynchronous with signal protocol sub-operating mode

In Section 1 of Figure 1.39, the INTERBUS master behaves as in standard
asynchronous operating mode. The process image in the MPM is updated by the
INTERBUS master synchronously to the cycle. In this section, the application can
only read IN data inconsistently.
In order to establish a handshake with the INTERBUS master, the application sets
the cons active bit in Section 2. This indicates to the INTERBUS master that the
application wants to read consistent IN data. The INTERBUS master responds in
Section 3 with the rising edge of the cons state bit, and the process data can be
read consistently, because the INTERBUS master is no longer accessing the
process data area. Once the copying procedures are complete, the host resets the
64
INTERBUS Basics
cons active bit in Section 4. Once the INTERBUS master has detected the falling
edge of the cons active bit, it can freely access the process data. The cons state bit
is reset when the host system OUT data is accepted, see Section 4.
This sub-operating mode is very easy to implement because it does not use
interrupts. The INTERBUS cycle time is highly dependent on the operating speed
of the host system.
Note: The INTERBUS master is always in the RUN state, even if the host is no
longer using the handshake. The process image update in the MPM is disabled.
Process data is still written to the input and output data memories, i.e., INTERBUS
cycles are run.
When the INTERBUS system is in the STOP state, the cons state bit is
no longer used. The application program or the driver must react
accordingly.
1.8.3.2
Asynchronous With Synchronization Pulse Operating Mode
This sub-operating mode is supported in master firmware Version 4.4x or later.

Once the INTERBUS master has accepted new IN data, the application receives a
synchronization pulse via the coupling hardware (MPM). The application now reads
the IN data and thus receives access to the process data synchronously to the
cycle. As the OUT process data should also be transmitted synchronously to the
cycle, it is transmitted to the MPM once the IN data has been copied. A
synchronization pulse is sent to the INTERBUS master to complete the access
from the host system, and the INTERBUS master can prepare and start a new
cycle.
In INTERBUS master firmware Version 4.6x or later, the "Asynchronous with
synchronization pulse" sub-operating mode is used as standard for some controller
boards (e.g., IBS PCI SC/RI/I-T) to ensure data consistency over the entire
summation frame. As the "Asynchronous with synchronization pulse" sub-operating
mode is set by default on many new and future controller boards, its
implementation in the INTERBUS driver is shown in detail in Figure 1.40.
Host system - INTERBUS application
Device Driver Interface (DDI)
DDI_DTI_WriteData
Process data write service
Driver
DDI_DTI_ReadData
Process data read service
Driver interrupt routine

Selector
Selector
Interrupt shift routine
Alternating
OUT buffer
Alternating
IN buffer
3
MPM
Figure 1.40: Implementation of the "Asynchronous with synchronization pulse"

operating mode in the driver
INTERBUS Basics
65
1.8.4 Bus-Synchronous Operating Mode

In bus-synchronous operating mode, the application process is synchronized with
the transmission of process data and the process image is disabled.
Section
2...
Synchronization
pulse bit (INTERBUS
master)
Application busy
bit (host)
IN
Host reads IN data
OUT
Host writes OUT data
OUT
Synchronization result
bit (INTERBUS master)
NOT VALID
VALID
NOT
VALID
Data cycle result bit

(INTERBUS master)
NOT VALID
VALID
NOT
VALID
IN:
IN data is read form the

INTERBUS master
OUT: OUT data is transmitted to the

INTERBUS master
Figure 1.41: Signal protocol for bus-synchronous operating mode

In Figure 1.41 Section 1, the INTERBUS master generates an edge change in the
synchronization pulse bit with an interrupt sent to the host system. The INTERBUS
master data cycle is started. From this point on, the host system can access the
OUT data. In Section 2, the host system confirms the synchronization pulse and
can still write OUT data. A falling edge of the synchronization pulse bit in Section 3
indicates the end of the data cycle and generates an interrupt at the host system.
The data cycle result bit indicates the validity of the data cycle. If the data cycle
result bit is not set, the IN data can be accepted by the application. At the start of
Section 4, the host system resets its application busy bit, which signals to the
INTERBUS master that the process data has been copied and a new data cycle
can be started.
The time-equidistant bus cycles are implemented on the INTERBUS master using
a hardware timer (TPU). If the INTERBUS master has not completed the copying
procedures before the next TPU interrupt, a synchronization error is triggered
(synchronization result bit).
66
INTERBUS Basics
1.8.5. Program-Synchronous Operating Mode

In this operating mode, the host system initiates the data cycles. The signal
protocol also disables the process data.
Section
1...
Data cycle activate

bit
Application busy bit

(host)
IN
Host reads IN data
OUT
Host writes OUT data
Data cycle reult bit

(INTERBUS master)
Interrupts sent to
INTERBUS master
Interrupts sent to host
OUT
NOT VALID
VALID
I
R
Q
NOT VALID
I
R
Q
I
R
Q
I
R
Q
INTERBUS cycle
complete
New INTERBUS cycle can be initiated
IN: IN data is read from the INTERBUS master
OUT: OUT data is transmitted to the INTERBUS master
Figure 1.42: Signal protocol for program-synchronous operating mode

At the start of Section 1 in Figure 1.42, the application initiates a data cycle with a
rising edge of the data cycle activate bit. The host system can now write OUT data
to the MPM. The end of the data cycle is indicated by the INTERBUS master by a
falling edge of the data cycle state bit in Section 2. The application can now accept
the IN data, provided the data cycle result bit indicates a valid data cycle. At the
end of Section 2, the application process enables the OUT process image again.
The INTERBUS master detects the edge change of the data cycle activate bit and
accepts the OUT data. The next data cycle is prepared. The data cycle state bit is
set, which signals to the host system that the INTERBUS master preparations are
complete and a new data cycle can be initiated. IN data can still be copied in
Section 4. The host system prepares the initiation of the next data cycle.
INTERBUS Basics
67
1.9 INTERBUS System Components

The range of INTERBUS system components includes numerous digital and
analog I/O modules, operator panels, valve manifolds, special modules such as
positioning modules and V.24 modules, and devices, which can be assigned to
specific user groups, such as DRIVECOM or ENCOM. The overview below is not
complete, because new components are being added to the INTERBUS system all
the time.
Table 1.21: INTERBUS components
Controller boards for control systems
- AEG Modicon
- Allen Bradley
- Bosch
- DEC MicroVax
- GE-Fanuc
- Hitachi
- IBM PC
- Indramat
- Klaschka
- Klckner-Mller
- Pilz
- Siemens
- VMEbus
Slave controller boards
Analog I/O modules
Digital I/O modules
Special function modules
Bus terminal modules
Frequency inverters
Servo amplifiers
Stepper motor controllers
Positioning controllers
Communication modules for Siemens
and Bosch PLCs and IBM PCs
Operator interfaces and display devices
Encoders
Sensors
Counter modules
Dosing devices
V.24 modules
Resolvers
Gateway modules
Motor starters
Servo drives
Identification systems
Encoders
Pneumatic valve manifolds
Hydraulic valve manifolds
Positioning controllers
Welding controllers
Weighing
and
dosing
systems
Cam-operated systems
PLC devices
PC boards
Gateway modules
Linear and rotating
transmission components
Infrared transmission paths
Radio transmission modules
Robot controllers
Multi-process control systems
Wrenching controllers
ID systems
Barcode reading systems
Scanner reading systems
Device control systems
Process controllers
68
INTERBUS Basics
1.10 Practical Tips

Tip 1: Determining INTERBUS cycle times
The INTERBUS cycle time (time for a complete INTERBUS cycle execution with all
outputs and inputs or write and read processes) can be calculated using the
following formula. It comprises the software runtime, transmission time, and delay
time.
t INTERBUS
Cycle time
= (1 . 15 13 (8 + n ) + 3 a ) t b + t s + 2 t p
Transmissi on time = 13 (8 + n )
Delay time = ( 3 a ) t b + 2 t p
n = Number of user data bytes of process and PCP data
a = Number of remote bus and local bus mod ule
t b = Bit duration = 0 .002 ms at 500 kbps
t s = Software runtime = 0 .7 ms ( G 4 ) and 0 . 34 ms (G 3)
t p = Runtime on the cable = 0 .016 ms / km
The PCP transmission time is calculated using the following practical formula:
b+n
tPCP transmission = tS 7 + ti + t I
a 1
b = Amount of user data in bytes
n = Overhead data for PCP command in bytes ( see PCP command )
a = Re quired data width in the parameter channel
ti = Transmission time for a PMS service ( 2 t I )
tS 7 = Software runtime for Layer 7 (1 ms )
z = Number of transmission cycles required
tI = INTERBUS cycle time

The Inline configuration table Excel file on the accompanying CD-ROM

contains the formula for calculating the INTERBUS cycle time and the
necessary data for calculating the time required by INTERBUS to fetch
all IN data and send all OUT data to the INTERBUS modules once.
The accompanying CD-ROM also contains the formula for calculating

the transmission time for PMS services (PCP services).
INTERBUS Basics
69
Tip 2: Determining INTERBUS response times

The response time cannot be calculated precisely. When a process data signal is
output from a control program, sent via an INTERBUS output module and a jumper
to an INTERBUS input module, and the signal is received in the control program,
the following components cause a time delay:
-
Control program runtime
INTERBUS Device Driver runtime
INTERBUS firmware runtime
INTERBUS cycle time
INTERBUS output module output filter
INTERBUS input module input filter
INTERBUS cycle time
INTERBUS firmware runtime
INTERBUS Device Driver runtime
Control program runtime
Tip 3: IBS SUPI 3 in a G3 and G4 INTERBUS controller board

To make full use of the extensive diagnostic features of the IBS SUPI 3, a G4
INTERBUS controller board must be used (Firmware 4.0 or later). With a G3
controller board and with SUPI 3 INTERBUS modules, the MAU warning is
unspecified, the microprocessor watchdog is not available, and the diagnostics and
report manager is deactivated.
Tip 4: Combined INTERBUS systems with IBS SUPI 3 and IBS SUPI 2 modules
During configuration, ensure that combined systems are not created (e.g., SUPI 2
and SUPI 3 INTERBUS modules in one INTERBUS configuration). For INTERBUS
diagnostics, a dedicated SUPI 3 INTERBUS system is the most effective solution.
Tip 5: Reading the SUPI types for the active INTERBUS configuration
In order to determine the IBS SUPI types for individual INTERBUS devices in a
running INTERBUS configuration, the IBS SUPI types can be read using a
firmware command. For Phoenix Contact controller boards, the Read_Value and
Read_Configuration firmware commands are used. The DIAG 40 diagnostic
software can also be used to read the SUPI types for Phoenix Contact controller
boards during INTERBUS operation.
The Variable_ID 2252 (hex) can be read to determine the following information
(Read_Value service):
Variable_ID
2252 hex
System Parameters Value/Note (32 Bits)

SUPI types for
0000 0000 Old devices only
current configuration 0000 0100 SUPI 3 devices only
0000 0200 SUPI 3 devices and old devices
70
INTERBUS Basics
The Read_Configuration service can be used to read the SUPI type for every
device. For Used_Attributes a "global_bus_error" (0100 hex) must be set. The
following 3 words are then read for every device:
Word 1: SUPI_Type (Byte) | Add_Info (Byte)
Word 2: Transmission_Error (Word)
Word 3: Device_Error (Word)
SUPI_Type
Bits 7...4: SUPI configuration (not important here)

Bits 3..0: SUPI type: 0 = Older SUPI and SUPI 2 | 1 = SUPI 1 | 3 = SUPI 3 or
later
Add_Info
A5: SUPI 3 | A4: SUPI 3-DPC | A3: LPC1 | A2: LPC2 | A0: IB8052 |
D0: SUPI 3-OPC | 00: SUPI older than SUPI 3 | FF: SUPI type not yet read
INTERBUS Basics
71
1.11 Workshops
1. Calculation of the CR check: If the message N(x) is 10101100 and the
7
5
generator polynomial G(x) is x +x +x then determine R(x). Calculate a solution
using XOR elements and use the mathematical version.
2. How long is the INTERBUS cycle time for a G4 INTERBUS configuration with
five INTERBUS devices and 20 bytes of process and parameter data?
3. What are the options for optimizing the INTERBUS process data in the
summation frame protocol?
4. Implement MPM access to the XDTA of the INTERBUS controller board from
the host PC using the application program (C, C++).
The solutions to the "Basics" workshop can be found on the

accompanying CD-ROM.
1.12 Questions for the "Basics" Section

1. What happens when the INTERBUS ring system is interrupted?
2. Is it possible for individual INTERBUS devices to exchange process or PCP
data with each other?
3. What are the tasks of the master and slave protocol chips in the INTERBUS
components?
4. What are the key features of the diagnostics and report manager in the IBS
SUPI 3?
5. Which diagnostic features of the IBS SUPI 3 are lost in combined systems
(IBS SUPI 2 and IBS SUPI 3 in one INTERBUS configuration)?
6. How many ID cycles are required to detect the entire INTERBUS topology?
7. How do the protocol chips behave in INTERBUS devices, which have two
remote bus interfaces? In these INTERBUS devices, are both remote bus
interfaces reset via bit 9 of the standard control register?
8. Why is bit 15 in the standard control register always set in the loop-back word?
9. How large is the data width of a bus coupler in the INTERBUS ring?
10. Describe the process for determining the connected bus configuration using
the INTERBUS master.
The answers to the questions for the "Basics" Section can be found on
the accompanying CD-ROM.
72
INTERBUS Configuration
2 INTERBUS Configuration
By carefully planning an INTERBUS configuration, it is possible to determine
whether system expansions will be easy to implement during later operation, and
how the entire system will respond to external interference.
Installation faults can lead to high interference and compensating currents, for
example in the INTERBUS cable shields. These currents can adversely affect bus
operation and lead to downtimes. These installation faults exist in many systems,
but are only detected when system downtimes occur.
With an understanding of the danger areas, an INTERBUS planning engineer is
faced with many questions, such as "What issues should be considered before
starting an INTERBUS project?", "Which installation faults have a particularly
negative effect on INTERBUS operation?, "Should a regulated or non-regulated
power supply be used?" - "How should the emergency stop concept be
implemented?" or "Which EMC measures should be taken to protect against surge
voltage, ESD, lightning, transients, and network disturbances?". These and other
questions are answered in detail in this section.
This section also provides the following information about the configuration of
INTERBUS systems and devices: a step-by-step list of procedures, acceptance
reports, test reports, applications examples such as emergency stop concepts, and
workshops and questions.
-
Practical procedure for implementing an INTERBUS project
Selection and application of power supplies
Implementation of an emergency stop concept using INTERBUS
Surge voltage protection concepts
EMI sources, effects, and preventative measures
What issues should be considered when configuring an

INTERBUS system?
Are there any tools that can help with INTERBUS configuration?
How is an INTERBUS system started up intelligently?
Which parameters are required for test reports and acceptance reports?
Which types of power supply should be used?
Which INTERBUS devices should be shut down on an emergency stop?
Which surge voltage protection measures should be implemented?
Page
Page
Page
Page
Page
Page
Page
73
74
79
83
89
90
91
What is the most effective way to protect the system from IBS errors?
How is redundancy created for the power supplies?
73
Page 92
Page 99
2.1 Planning INTERBUS Configurations

INTERBUS system configuration involves numerous steps, from planning through
mounting and startup to acceptance. The following descriptions document the
individual steps in order and describe their practical implementation. The steps do
not have to be completed in strict succession, as they can often be combined or
implemented simultaneously. The relevant tasks are explained here using a
hierarchical model with steps 1 to 18.
1. Planning the INTERBUS system and its topology
2. Preparing for the installation of a surge voltage protection concept
3. Mounting INTERBUS components
4. Mounting sensors and actuators
5. Laying INTERBUS and 24 V cables and wiring connectors
6. Testing and logging the INTERBUS cabling
7. Connecting INTERBUS, sensor, and actuator cables
8. Connecting the supply voltages
9. Mounting and starting up the INTERBUS controller board
10. Starting up INTERBUS using LEDs and AUTODEBUG
11. Tools for INTERBUS diagnostics
12. Checking INTERBUS module IN/OUT signals (I/O test)
13. INTERBUS addressing and device configuration
14. Starting up and testing INTERBUS using a program
15. INTERBUS module configuration by the control program
16. Continuous operation
17. Acceptance by report
18. For continued smooth operation: INTERBUS diagnostics and maintenance

This section contains detailed explanations, important details and notes for these
tasks.
Planning the INTERBUS System and its Topology
When planning an INTERBUS system and its topology, the legal regulations (VDE,
DIN, IEC, EN, etc.), the local conditions, and the technical requirements must be
taken into account.
74
The (distributed) control boxes and stations should be planned in advance to meet
the needs of the application. The IP code, which indicates the required degree of
protection against contact, foreign bodies, and water, should be considered. The
various degrees of protection (IP codes) are defined in DIN 40 050 and in IEC 144.
A table listing the degrees of protection (IP codes) can be found on the
When configuring an INTERBUS system, the basic system specifications apply,

such as the minimum and maximum figures for devices, I/O points, etc. These
figures are described in Section 1.2 "INTERBUS System Specifications". The
following technical parameters for INTERBUS should also be clarified in advance:
-
Required and maximum cycle time for the INTERBUS configuration (realtime)
Number of IN and OUT data points
Number of process and parameter data words
Number of devices (PD and PCP)
Dimensions of the entire system
Distance between devices
Current consumption of devices and segments
The "Inline configuration table" Excel spreadsheet provides support when

configuring INTERBUS systems with INTERBUS Inline components from Phoenix
Contact. You can easily put together an INTERBUS configuration from the wide
range of Inline modules and accessories. The total price is calculated according to
the specifications. In addition, a warning is displayed if the INTERBUS system
specifications (current consumption, number of devices, etc.) are exceeded. A "Bus
cycle time calculation" formula is also provided for calculating the cycle time
required by INTERBUS to fetch all IN data and send all OUT data to the
INTERBUS modules once.
INTERBUS configuration aid: the Excel spreadsheet for the configuration

of Inline components can be found on the accompanying CD-ROM.
When configuring an INTERBUS system, product catalogs from manufacturers are

always very useful. These catalogs, which are often available on CD free of charge
or on the Internet, provide information about all possible and available INTERBUS
components. An overview of all manufacturers and all INTERBUS components is
provided on the INTERBUS Club website. INTERBUS Club contact information is
listed in Appendix A.6 "List of Useful Information".
75
Configuration aids are often available free of charge in the form of

company product catalogs.
The following questions should also be considered during INTERBUS planning:

-
What type of voltage is available (national, international)?
Is INTERBUS redundancy required?
Where will the INTERBUS system and its cables be installed?
What type of control system (software or hardware PLC) should be used and
what programming language is required for this?
Which operating system will be used by the control program?
Is a link to a higher-level control system, visualization or similar system

required as part of the configuration? How are variables accessed in the
control system?
Which medium should be used to link to a higher-level control system,

visualization, server, etc.?
Are there large data packets, which require consistent transmission to higherlevel components? Can this transmission be achieved without problems?
Ensure that you select the correct cable type for your application. Select the
appropriate cables for indoor or outdoor use, for trailing cables or for protected
areas (potentially explosive areas or those prone to EMI). If INTERBUS is used in
areas prone to EMI, fiber optic cables should be used as the INTERBUS medium.
An overview of possible fiber optic technologies with cost/time

estimates can be found on the accompanying CD-ROM. A table listing
the fiber optic cable designations according to DIN VDE 0888 with
detailed descriptions is also provided.
Another important point is the considered use of combined INTERBUS systems. It

should be noted that combining INTERBUS devices with different protocol chips
(SUPI 2/3 and Loop 1/2) is not recommended.
2
Preparing for the Installation of a Surge Voltage Protection Concept
When implementing a surge voltage protection concept, several levels can be

used, depending on cost considerations or on the technical requirements of the
system. The following measures should be included in every INTERBUS project:
-
Shielding
Grounding
Equipotential bonding
76
EMI protection
Separate installation of cables (data and power supply cables)
Use of uninterruptible power supplies (UPS), if required
Section 2.4.7 "Cable Installation, Shielding, Grounding, and Equipotential Bonding"

provides all the relevant information for avoiding interference.
For INTERBUS systems, which require the integration of a comprehensive surge
voltage protection concept, the EMI protection zone concept should be used, as
described in Section 2.4.3 "EMI Protection Concept According to VDE 0100".
It is important to adapt the concept for the degree of protection to the power supply
network type (TN-C, TN-S, TN-CS, TT). The network types used in Germany are
described on the accompanying CD-ROM.
3
Mounting INTERBUS Components
When mounting INTERBUS devices, they should be well grounded. Often a metal
clip on the back of the module is connected to the control cabinet to provide the
ground connection. In this case, the user must then check that the DIN rail, the
control cabinet, and the built-in mounting plate are also grounded. If necessary, a
grounding terminal block should be installed on the DIN rail to connect the rail to
protective earth ground.
If the INTERBUS device is screwed directly onto a mounting surface, the grounding
connection is made via a mounting screw on the grounded mounting surface.
When mounting INTERBUS components, various options are available for reducing
the amount of "space" required in the summation frame protocol. The skilled
configuration of adjacent INTERBUS I/O modules and their process data width can
ensure optimal use of the summation frame. Depending on the INTERBUS system
(Inline, ST, RT, Loop, etc.), the process data in the summation frame is either byte
or nibble-oriented. The use of this "space" can be optimized with knowledge of the
process data width of the INTERBUS modules and by positioning them next to
each other. The information required to understand this concept can be found in
the workshop for Section 1.11 "Optimizing Process Data in the Summation Frame
Protocol".

4
The description of all product designations for Phoenix Contact

components (e.g., IB 24 STME AI/4SF) can be found on the
Mounting Sensors and Actuators
When laying cables for sensors and actuators, parallel cabling with (powerful)
conductive cables should be avoided. If the application side of the INTERBUS
module does not have electrical isolation, interference can be transmitted via the
sensor/actuator cables to the INTERBUS module and onward into the INTERBUS
77
data cable. This type of interference often occurs with frequency inverters,
protective circuits, and switching operations in power cables.
5
Laying INTERBUS and 24 V Cables and Wiring Connectors
The bus lines must not be laid parallel to power supply lines. They should be laid
separately in metal cable ducts, cable trays or jumpers. A minimum distance of 10
cm (3.94 in.) from power cables must be observed if isolated cable laying is
absolutely impossible. Interference voltages may be induced on power cables to
and from frequency inverters, motors, and other sources of interference. This
should be avoided wherever possible. In addition, bus lines should not be laid at
right angles to driving paths or machine movements. If particularly long bus lines
are used or lines are laid in adjacent buildings, a separate equipotential bonding
line should also be laid and contacted at the connection points. When a line is laid
to an adjacent building, it should be installed in a grounded metal conduit.
Always take the bending radius into account when laying cables, especially fiber
optic cables.
When connecting INTERBUS D-SUB connectors, cold junctions are

often the source of sporadic and serious errors. Make absolutely
sure that junctions are clean and the wires are connected accurately.
The wires must not be squeezed or damaged. In addition, they
should not be stripped too far. When selecting D-SUB connectors,
metal-plated, metal-coated or metal connectors with an electrical
connection to the strain relief should be used.
To ensure error-free INTERBUS operation, the power supplies for the INTERBUS
I/O devices and the INTERBUS module electronics should be isolated for all
INTERBUS devices. A separate primary switched power supply unit should supply
the voltage in each case. This prevents INTERBUS errors, which could arise from
the coupling of contaminated voltages (voltage peaks, transients, etc.) to the
INTERBUS communications power.

6
The assignment of wire pairs for all main INTERBUS cables and
connectors can be found on the accompanying CD-ROM.
Testing and Logging the INTERBUS Cabling
When testing and logging the INTERBUS cabling, the length, impedance,
attenuation, and crosstalk should be determined. The values given in the
acceptance and test reports and in the INTERBUS system specifications should be
used as reference values. For example, the ground or shield connection for the bus
cables must be checked for continuity.
78
All the data, which is required for a cabling test, can be found in the
submission for INTERBUS acceptance and in the fiber optics test
report. These documents are provided on the CD.
Connecting INTERBUS, Sensor, and Actuator Cables
When connecting the cables, ensure that as much of the shield as possible is held
underneath the strain relief. Tightening the screws correctly ensures a good
contact between the connector and the INTERBUS module. Whenever possible,
the connector should also be screwed to the coupling.
8
Connecting the Supply Voltage
When connecting the supply voltage, observe the isolation of voltages described
above for INTERBUS I/O devices and the INTERBUS module electronics, and the
assignment in an emergency stop concept. For some components, the correct
polarity may also be important for the voltage connection.
Once the modules have been connected and supplied with power, a measurement
can be taken to check the voltage. In general, this voltage measurement is not taken
using a multimeter or voltmeter. Due to the fact that the voltage must be within a
defined range, an oscilloscope should be used. For Phoenix Contact INTERBUS
modules, a voltage between 20.0 and 30.0 V is required, with a permitted voltage
ripple of +/- 3.6 V. Longer-term voltage triggering of over 30.0 V or under 20.0 V can
help to determine whether the AC supply is "contaminated" with voltage peaks. This
measurement is meaningful if the system is operated under "load" and all electrical
and electronic components are included in the configuration. This is why this
measurement is also part of the INTERBUS acceptance report.
In the event of critical voltage peaks during a measurement, proceed

as described in Section 2.4.7 "Cable Installation, Shielding, Grounding,
and Equipotential Bonding" and Section 2.4.6 "Protection from
Transient Voltages".
Mounting and Starting Up the INTERBUS Controller Board
Depending on the selected controller board (PLC, soft PLC or hard PLC), various
factors should be considered when mounting and starting up the INTERBUS
controller board. These factors are described in detail in the data sheets supplied
with the controller boards.
Once the voltage is powered up and the system started, electric

current flows through the INTERBUS modules. At this point at the
latest, the "5 Safety Regulations for Working in Electrical
Systems" according to DIN VDE 550 apply to the INTERBUS system.
79
The regulations specify the sequence of steps for working in the

system:
Disconnect safely
Ensure power cannot be switched on again
Verify safe isolation from the supply
Ground and short circuit
Cover or safeguard adjacent live parts
As INTERBUS systems may contain 240 V and 3*400 V as well as 5 V and 24 V

control voltages, increased vigilance is essential and the relevant safety measures
according
to
DIN VDE 550 must be followed.
However, a voltage of over 24 V is not required to start up the INTERBUS system
in the present state. The fuses and automatic cutouts for motors, 240 V and 400 V
loads should therefore not yet be activated.
After startup, the physical INTERBUS structure is complete and INTERBUS
operation is possible.
10 Starting Up INTERBUS Using LEDs and AUTODEBUG
When the INTERBUS configuration is started up, the INTERBUS modules are
supplied with 24 V control voltage. The LEDs for the module, segment, and I/O
voltages should now be lit on all connected INTERBUS modules. The description
of the LEDs can be found either on the package slip included with the module, the
relevant data sheet or in Section 3.9 "Evaluating LCD/Diagnostics LEDs on the
Controller Board".
If all voltage LEDs are not lit on the INTERBUS modules, then use a
voltage measuring instrument to determine whether the required voltage
of 24 V is present at the module. The fuse may not be present or may be
faulty.
At this point, the BA LED (Bus Active) on the INTERBUS modules should be unlit
or flashing, as the controller board is not yet operating the INTERBUS system. The
controller board is only in the "Ready" state and does not yet have an INTERBUS
configuration frame, i.e., there is no image of the INTERBUS configuration within
the controller board.
In order to check the INTERBUS configuration to ensure it functions correctly,
DEBUG, AUTODEBUG or test mode is available on the controller board (see data
sheet). The INTERBUS devices are (automatically) switched on one after the other.
In these test modes, ID and data cycles are run alternately. In the event of an error
on an INTERBUS module, the physical device number is displayed, e.g., in the
LCD on the controller board. If the INTERBUS system contains no errors,
INTERBUS cycles are run up to the last device. At this point it can be assumed that
80
the system does not contain any problems, which are the result of INTERBUS
hardware errors.
The DEBUG and AUTODEBUG functions are set in the LCD on the
controller board (MODE | DIAG | DEBG or ADBG) or in IBS PC WORX
or IBS CMD under the Monitor menu item. On some controller boards,
the test mode can be set via DIP switches.
DEBUG, AUTODEBUG or test mode functions are available on all

Phoenix Contact G4 controller boards. A description of the use of this
startup aid can be found in the INTERBUS Diagnostics Guide, IBS SYS
DIAG DSC UM E. Please note that these functions can also be used
later for effective INTERBUS troubleshooting.
11 Tools for INTERBUS Diagnostics

Even if all INTERBUS errors have been removed in the previous steps, errors and
interference can still occur in the INTERBUS system at a later date. An INTERBUS
error is often caused by different interlinked factors, such as the operation of an
adjacent system or operation under load. The following list details the tools, which
are available for INTERBUS diagnostics on G4 controller boards. A detailed
description of "INTERBUS Diagnostics" and the relevant procedures can be found
in Section 3.
-
LEDs on all INTERBUS devices
LCD on the controller board
DEBUG, AUTODEBUG or test mode on the controller board
DIAG40 (diagnostic software)
DIAG+ (diagnostic software)
Internal diagnostic tools in IBS CMD or PC WORX configuration software
Firmware commands
Evaluation of the diagnostic register in the controller board
Evaluation of transmission quality
For continuous INTERBUS operation, the complete INTERBUS ring

must be virtually free from errors. This depends on the physics of the
transmission method.
In the event of an INTERBUS error, one possible remedy is to
temporarily switch off or jumper the affected INTERBUS segment. This
enables further operation of the INTERBUS system. The program can
be written so that in the event of an error the relevant segment is
automatically removed from the running INTERBUS system. In this
81
case, data transmission stops for a short time. In a new firmware

version (Version 4.6), the "Switch off segment/device" without a stop
function is virtually seamless in the event of an error.
12 Checking INTERBUS Module IN/OUT Signals (I/O Test)
The next step when implementing an INTERBUS system is to check the IN and
OUT process data. On the application side, the test ensures that digital sensors
and actuators are correctly connected to INTERBUS. This I/O test verifies that the
outgoing (or incoming) process data goes to (or comes from) the right modules.
This is particularly important if the application program is adjusted and the
actuators activate or deactivate due to the sensor states. Motor operation due to an
incorrect sensor state or actuator connection can be dangerous and expensive.
The I/O test can be performed easily using a digital process data monitor.
This can be found in the CMD G4 and PC WORX software on the
accompanying
CD-ROM.
To carry out an I/O test, the INTERBUS system must now be started up (no longer
in test mode). This should no longer be a problem because all possible errors have
been removed in the previous steps. For INTERBUS operation a configuration
frame is now required, which must be transmitted to the controller board and
started. This step is called "Execute parameterization and startup". In the controller
board, the specified configuration frame is compared with the actual physical
INTERBUS configuration. After a successful comparison, the configuration frame is
switched first to ACTIVE and then to RUN. The INTERBUS system is now running
and is operated by the controller board cycle by cycle.
The practical implementation of the "Execute parameterization and

startup" process depends on the software used. However, in all versions it
consists of a long sequence of firmware commands, which are described
using a flowchart in Section 4.1 "Structure of INTERBUS Startup".
13 INTERBUS Addressing and Device Configuration

User-defined or automatic addressing is used to assign a device number to every
INTERBUS device within an INTERBUS configuration. For automatic addressing,
the numbering is specified by the controller board and assigned to the modules
one after the other (1, 2, 3, 4, etc.). For user-defined addressing, the user can
assign specific device numbers (1.1, 2.5, 12.25, etc.) to the modules.
User-defined process data addressing makes the fixed structure of the

summation frame protocol more flexible. The content of the IN and
OUT process data is copied to a memory area or onto variables. The
programmer must create this assignment.
82
User-defined addressing enables the user to assign bits, bytes, words, etc. of
process data to memory spaces or variables. However, this has no effect on the
assignment of process data within the summation frame protocol.
INTERBUS addressing is part of the "Execute parameterization and

startup" process and thus depends on the startup software used. Section
4.1 "Structure of INTERBUS Startup" includes descriptions of both types
of addressing using flowcharts.
14 Starting Up and Testing INTERBUS Using a Program

Like the "Execute parameterization and startup" process in the previous section,
the procedure for starting up and testing INTERBUS depends on the software used
or on the programmed code.
Code examples that provide startup support, such as user-defined

addressing and automatic addressing, PCP communication, INTERBUS
startup, etc. can be found on the accompanying CD-ROM.
15 INTERBUS Module Configuration by the Control Program

Some INTERBUS devices require configuration or a special setting for operation in
the INTERBUS system. For example, the measuring range must be set for analog
input modules and the operating mode must be set for counter modules. This
configuration is often set using process data. The relevant configuration is sent to
the INTERBUS module via assigned OUT process data. The module usually
responds to this "new" configuration by mirroring the assigned configuration value
in the IN process data.
However, the use of process data is not the only configuration option. Depending
on the module functions, a configuration can also be set using parameter data
(PCP). For example, for an INTERBUS-compatible frequency inverter, the
parameter records are transmitted via PCP. PCP or process data can then be used
to determine whether the new configuration has been set successfully.
The creation of groups, i.e., the grouping of different INTERBUS modules to form a
logical group, is also part of this step. When INTERBUS devices are divided into
groups, it is easy to activate or deactivate all the devices in a group. The devices
do not have to be in the same bus segment, they can be distributed in the
INTERBUS system.
The creation of alternative groups, enabling the user to switch between two
different INTERBUS configurations, must also be configured. The "Alternative
groups" configuration setting is used for example if robots work with different tools;
each tool is an INTERBUS device and is activated alternately in the INTERBUS
system.
83
Configurations for analog input modules, groups, and alternative groups

can be found in the form of code examples on the accompanying CDROM.
16 Continuous Operation
If the INTERBUS system is in the RUN state after the hardware and software has
been started up, then cycles are initiated continuously by the INTERBUS controller
board. The controller board fetches IN process data from the modules and sends
OUT process data to the modules in the same cycle. The cycle time always
remains the same. Determinism can therefore be specified using the cycle time. If
parameter data (PCP) is also transported in the INTERBUS system, this data is
transmitted sequentially in blocks and does not affect the cycle time.
A detailed description of the transmission method can be found in

Section 1.4 "INTERBUS Data Transmission". This section also
contains information for determining bus cycle and response times.
17 Acceptance by Report
During the INTERBUS system acceptance process, the parameters required for
safe and smooth operation should be logged.
A template for INTERBUS acceptance with copper or fiber optic cables

and a fiber optics test report are provided on the accompanying CD-ROM.
18 For Continued Smooth Operation: INTERBUS Diagnostics and Maintenance

As in all industrial systems, the initial technical conditions change over time.
Usually this means that the conditions required for smooth operation get worse
rather than better. There may also be rapid changes to the system configuration
due to a system expansion or conversion. If this is carried out by untrained or nonspecialist personnel, important requirements may no longer be met. For example,
power supplies are often shared or interference voltages introduced into the
previously clean network due to incorrect cable laying.
The maintenance personnel are responsible for ensuring error-free system
operation. Diagnostic and maintenance procedures are available to support
smooth INTERBUS operation. They include checking the most important
parameters at regular intervals. These parameters are listed in the template for
INTERBUS acceptance and, if fiber optics are used, in the fiber optics test report. A
check should be made each time the system configuration is modified. Even if a
84
complete system check cannot be carried out, the following values should at least
be determined using random tests:
-
Check control voltages using an oscilloscope
Check the grounding concept
2.2 Power Supplies

Due to technical developments, which focus on decentralization and distributed
logic, power supplies for 24 V and 5 V control voltages now perform a crucial role
and the function of the distributed electronics has also gained in importance. The
reliability of the power supplies, which are often installed remotely in distributed
locations, determines the availability and the safe operation of individual or more
complex systems.
When configuring new systems, the power supplies should be designed so that the
devices are loaded to about 85% with a coincidence factor of 1. This ensures that
reserves are available for later system expansions. Additional information about the
parallel connection of power supplies to increase power or to provide redundancy
can be found in the practical section at the end of Section 2.6.
When using power supplies, the most cost-effective and ideal technical solution is
to install the power supply units remotely at the load center and not to feed the 24
V voltages using supply lines. This solution reduces the voltage drop, which arises
over the cable length and is dependent on the current.
Power supplies are defined as current-using equipment and are divided into
Protection Classes 0, I, II, III in DIN VDE 0106 Part 1, where Protection Class 0 is
not permitted in Germany. Power supplies in Protection Class I are devices, in
which protection against electric shock is not only provided by basic insulation.
Parts are connected to the protective conductor of the fixed insulation. These
devices always have a protective ground. Power supplies in Protection Class II are
devices, in which protection against electric shock is again not only provided by
basic insulation. In this case, double and reinforced insulation is used. These
devices do not have a protective ground.
When selecting the correct power supply, the type of control and therefore the
method of operation of the power supply is of vital importance. Power supplies can
be divided into regulated and non-regulated devices. Regulated power supplies
include various different versions, such as linear regulated and primary switched
power supplies.
2.2.1 Regulated Power Supplies

Linear Regulated
For linear regulated devices, the voltage on the line side is transmitted via a 50 Hz
transformer and then rectified, as shown in Figure 2.1. The pulsating direct voltage
85
is smoothed and filtered using capacitors. It is then led through either a DC series
controller or a DC quadrature controller. Depending on the forward resistance of
the transistor in the controller, the current is regulated so that the voltage remains
constant. The main field of application for regulated power supplies with linear
regulation is the supply of electronic loads in the 24 V DC area.
In the event of a short circuit, the short circuit current is limited by the fuse on the
secondary side and by the controller. It may briefly amount to two or three times
the nominal output current of the power supply.
+
L
Input
(primary)
Output
(secondary)
Controller
50 Hz transformer
Rectification
Smoothing
Regulation
Smoothing
Figure 2.1: Linear regulated power supply

Advantages:
Disadvantages:
Precise regulation
High power dissipation, efficiency of 40-60%
-
No harmonics
Transistor must be larger
Very well smoothed output

voltage
Increased weight due to larger components
Low residual ripple and

switching peaks
Primary Switched
In primary switched devices, as shown in Figure 2.2, the AC supply voltage on the
primary side is first rectified, smoothed, and keyed. The resulting square-wave
voltage is transformed using a high-frequency transmitter and smoothed again on
the secondary side. Due to their universal use, the main field of application for
regulated power supplies with primary switched regulation is in automation and in
the provision of distributed supply voltages.
Controller
Electrical isolation
Output
(secondary)
Input
(primary)
N
Rectification
Smoothing
Keying
50 Hz transformer
Filter
Smoothing
86
Figure 2.2: Primary switched (regulated) power supply

Advantages:
Precise regulation
Disadvantages:
More components
Low weight
Higher price
Low power dissipation,

efficiency of 80-90%
Possible DC flow after

shutdown of primary side
Universal use
Small size
In the event of a short circuit, the short circuit current is shut down briefly by the
controller on the secondary side and reactivated after a few seconds. The current
on a short circuit may be about 1.1 to 1.5 times the nominal output current of the
power supply.
If primary switched power supplies are equipped with a U/I characteristic curve as
shown in Figure 2.3, the entire output current is provided on a short circuit and the
output voltage is reduced accordingly. The fuse positioned after the power supply
unit must therefore have a low level of internal resistance, so that it shuts down
reliably in the event of a short circuit. These power supply units are used to
connect any size of capacitive load when reliable selective triggering is required.
UOutput [V]
24V
I Output [A]
INominal 1,1*INominal
Figure 2.3: U/I characteristic curve for a power supply
If the controller for the primary switched power supply unit uses the fold-back
output characteristic curve, the voltage to current ratio is as shown below in Figure
2.4.
87
Overcurrent range
UOutput [V]
24V
IOutput [A]
INominal
1.1*INominal
2.4*INominal
Figure 2.4: Fold-back characteristic curve for a power supply

There are also controllers for primary switched power supply units that use the
extended fold-back output characteristic curve. These power supply units are used
to connect large capacitive loads. In this case, the voltage to current ratio is as
shown below in Figure 2.5.
UOutput [V]
24V
16.5V
I Output [A]
INominal
1.5*INominal
Figure 2.5: Extended fold-back characteristic curve for a power supply
2.2.2 Non-Regulated Power Supplies

For non-regulated devices, the AC supply voltage on the primary side is
transmitted via a 50 Hz transformer and then rectified. The resulting direct voltage
is smoothed and filtered using capacitors. The main field of application for nonregulated power supplies is the supply of electromechanical loads such as
contactors, electromagnetic switches, etc.
In the event of a short circuit, the short circuit current is limited by the fuse on the
secondary side. It may briefly amount to ten times the nominal output current of the
power supply. Figure 2.6 illustrates a non-regulated power supply.
88
+
L
Input
(primary)
Output
(Secondary)
N
50Hz transformer
Rectification
Smoothing
Figure 2.6: Non-regulated power supply

Advantages:
Simple structure
-
Few components
Long life
Efficiency of 80%
Disadvantages:
No control level
-
Possible fluctuations in the output

voltage
2.2.3 Isolation of the Power Supply, Cable Cross Sections, and

Voltage Drop
To ensure error-free INTERBUS operation, the power supply for the INTERBUS
I/O devices and the module electronics should be isolated and supplied by
separate primary switched power supply units. This prevents INTERBUS errors,
which could arise from the coupling of voltage peaks, contaminated voltages, etc.
to the INTERBUS communications power.
The cable cross section for insulated multi-wire cables, in relation to their current
carrying capacity, is defined according to VDE 0100 Part 523 in the Section
"Current Carrying Capacity of Lines and Cables". Table 2.1 below illustrates the
relationship between these figures.
Table 2.1: Cable cross sections and current carrying capacity
Nominal cross
1.5
2.5
4
6
section for
copper in mm
Current carrying
18
26
34
44
capacity in
Ampere [A]
10
16
61
82
The following formulae are used to calculate the voltage drop on the secondary
side, where is the conductivity (57 = copper, 36 = aluminum):
89
24 V DC:
Voltage drop u [%] =
200 Load power [W ] Cable length [m]

m
Cable cross sec tion [mm ]
U V 2
mm
[ ]
1~ 240 V AC:
200 I [ A] cos Cable length [m]

m
U [V ]
mm
3~ 400 V AC:
100 3 I [ A] cos Cable length [m]

m
U [V ]
mm
The workshop at the end of this section contains exercises for calculating the
voltage drops for AC and three-phase loads.
2.2.4 Selecting Power Supplies

Before selecting the power supply, the user should determine the answers to the
following technical questions:
-
What type of shock protection is required?
What type of humidity or water protection is required?
What level of resistance to shock and vibrations is required?
Is a regulated output voltage required? Not for electromechanical loads, but

probably for INTERBUS devices.
How much space is available?
What level of efficiency is required?
Table 2.2 below illustrates the differences between the types of power supply.
Table 2.2: Differences between various power supplies
Efficiency
Power dissipation with a load
power of 1000 W
Input range
Non-Regulated
80%,
approximately
200 W,
approximately
-10% < UN < +6%
Linear Regulated
40 - 60%,
approximately
600 W,
approximately
-10% < UN <
Primary Switched
90%, approximately
100 W,
approximately
-20% < UN < +15%
90
Non-Regulated
Output voltage
Residual ripple
Short circuit current
Field of application
Depends on input
voltage and load
2000 mVpp,
approximately
10 x IN,
approximately
Linear Regulated
+6%
Precisely
regulated
50 mVpp,
approximately
2 or 3 x IN,
approximately
Electromechanical Sensitive
loads
analog
technology
Primary Switched
Precisely regulated,
can be set
150 mVpp,
approximately
1.1 to 1.5 x IN,
approximately
(U/I characteristic
curve)
Universal,
INTERBUS
Power supplies with primary switched regulation have proven effective

for use with INTERBUS components. They provide a stable output
voltage of 24 V regardless of the fluctuations in the input voltage and
the system load (up to the current limit).
The future of power supplies for INTERBUS lies in regulated primary switched
power supply units. These power supply units offer clear advantages in the form of
reduced power dissipation, compact design, and multi-functional use.
2.3 INTERBUS Emergency Stop Configuration

2.3.1 Emergency Stop Configuration for Power Supplies
An emergency stop concept is often implemented so that when an emergency stop
is activated, the supply voltage on the primary side of the power supply is shut
down. However, depending on the power supply, but especially for primary
switched power supplies, direct current may flow on the secondary side for a short
period, although the primary side has already been shut down. This is because
manufacturers have implemented capacitors in the primary intermediate circuit in
order to jumper brief power failures. In power supplies with intermediate circuit
capacitors on the secondary side, the emergency stop concept should therefore be
implemented using a relay connection.
2.3.2 INLINE-SAFE The Emergency Stop Configuration for

Interbus Inline segments
Phoenix Contact SAFETY technology has efficiently implemented the emergency
stop concept with the INLINE SAFE safety terminal. Based on the standard
INTERBUS fieldbus, the integration of this bus terminal enables the transmission of
safety data.
INLINE SAFE safety terminals meet requirements for protection according to
Category 4 and intergarte safety technology into the Inline system. They are based
on standard EN 954-1. The IB IL 24 SAFE 1 safety terminal is used to connect
emergency stop switches, safety doors, and safety mats. It safely isolates the
subsequent 24 V segment circuit of the Inline system and reports the status of the
emergency stop inputs to the control system.
91
Figure 2.7 shows an INTERBUS configuration for the emergency stop concept
using a SAFETY bus terminal. The safe segment circuit starts at the
IB IL 24 SAFE 1 terminal and finishes at the last terminal before another power
supply unit or at the end of a station.
Figure 2.7: Emergency stop configuration INTERBUS-Safety
2.4 Improving EMC Through Surge Voltage Protection

2.4.1 Causes and Effects of Surge Voltage
Surge voltages are caused by switching operations, ESD (electrostatic discharge),
lightning, periodic interference frequencies, and network disturbances. Interference
voltages are coupled electrically, inductively or capacitively to electrical
components via connected power supply and data lines. The coupled voltages
disturb, damage or even destroy electrical systems because they exceed the
dielectric strength of the electrical parts. For example, an electronic component will
certainly be destroyed if a transient surge voltage of 80 times the nominal voltage
is coupled to it. For INTERBUS systems, ESD generally plays a lesser role.
2.4.2 Surge Voltage Protection Measures

Possible measures to protect against surge voltage include shielding, grounding,
equipotential bonding, EMI protection concepts, use of uninterruptible power
supplies (UPS), and separate installation of cables (control, data, and power
cables). Unfortunately these measures are not always sufficient in practice.
Basically, there are only two options that provide effective protection against surge
voltages: absolute electrical isolation or consistently implemented equipotential
bonding. In the first case, the inductors and capacitors have no effect due to the
92
electrical isolation. However, it is difficult to implement absolute electrical isolation

in practice.
Instead of absolute electrical isolation, the second option is fully implemented
equipotential bonding including all active cables and the use of surge voltage
arresters, as shown in Figure 2.8. In this diagram, the surge voltage arresters used
are Flashtrab and Valvetrab components from the Phoenix Contact Trabtech
range. In the event of a surge voltage, these protective components close the
connection points briefly (for a few s) and create a connection to the ground
potential. Circuits with electronic components such as spark gaps in air, gas-filled
surge voltage arresters, varistors, and suppressor diodes are used in the surge
voltage arresters. They divert the short-term surge voltages, currents, and
transients to ground and thus protect the electronics of the components.
Phoenix Contact offers the PC-based "Trabtech Select" program as

a configuration aid when planning a complete surge voltage
protection concept.
Power supply
company
Main
distribution
FLASHTRAB
Subdistribution
Termination
device
L1
L2
L3
N
PE
VALVETRAB
Device
protection
Figure 2.8: Surge voltage protection concept with surge voltage arresters in a TNC-S network
In the planning phase, a consistently implemented equipotential bonding concept
should be configured with a network that is as tightly meshed as possible.
However, when the complete equipotential bonding concept is later implemented,
star and line networks can also be installed.
2.4.3 EMI Protection Concept According to VDE 0100

One specific example for providing permanent system availability for
communication and data processing systems in system and building installations is
93
the use of an EMI protection concept (ElectroMagnetic Interference). This concept

involves EMI protection zones with different levels of sensitivity. When electrical
systems are installed in the EMI protection zones, surge voltage arresters are used
for the active wires of the EMI protection zone equipotential bonding. This reduces
electromagnetic interference to values that are so low that the electrical systems
can operate freely in the EMI protection zone.
In the configuration, the electrical and electronic components should be divided
into EMI protection zones (PZ). The electrical components are divided into EMI
protection zones of varying dielectric strength. Devices with the same or similar
dielectric strength are then physically grouped in the same EMI protection zone.
Figure 2.9 illustrates the protection zone concept.
Power supply
Data line
EMI PZ
(Lightning PZ)
Main distribution
Equipotential
bonding
Sub-distribution
Equipotential
bonding
Arrester
EMI PZ
Arrester
EMI PZ 2
Arrester
EMI PZ 3
Sub-distribution
Equipotential
bonding
Electrically conductive design parts

Grounding
Figure 2.9: Protection zone concept

Within the protection zone, all electrical circuits such as power supply, measuring,
control, data, network, telecommunications, and aerial cables are integrated into
the equipotential bonding by connecting suitable surge voltage arresters.
When selecting surge voltage arresters, information about the dielectric strength of
the device is required. This information can be determined from the device data
because, according to IEC 61000-4-5, the manufacturers of electronic devices
have to meet certain minimum values for dielectric strength and to document this
data in product data sheets.
94
The following classifications have been developed for the assignment of electrical
components in protection zones 0-3 (PZ):
PZ 0
PZ 1
PZ 2
PZ 3
Outside the building

Inside the building;
High-energy transients due to switching operations, lightning currents
Low-energy transients due to switching operations, ESD
No generation of transients that exceed the interference limit;
Shielding and separate installation of circuits, which could affect one
another
Using this protection zone concept, in which protection zones 1-3 may occur
several times, surge voltages can no longer be coupled to the electronics. In order
to also prevent different circuits from affecting one another, power supply and data
cables should be installed separately in shielded grounded metal ducts.
In addition, all conductive parts such as pipes are included in the equipotential
bonding.
The protection zone concept can also be used to create island solutions and thus
to protect only individual devices or systems/system parts from surge voltage. This
may be desirable if complete surge voltage protection is not cost-effective or is not
required. However, later modifications to provide surge voltage protection using the
protection zone concept should always be taken into account in the planning
phase.
DIN V VDE V0100 Part 534 specifies the regulations for the erection
of surge voltage protection equipment. It covers both the issue of
lightning protection and the requirements for lightning protection to
prevent the risk of fire and electric shock. The "3+1" circuit used in
TT and TN systems virtually eliminates the risks presented by circuit
connection errors. The conditions for the correct installation of surge
voltage protection equipment are clearly specified in DIN V VDE
V0100 Part 534 and the Directive for the Use of Surge Voltage
Protection Equipment Class B.
2.4.4 Surge Voltage Interference due to Network Disturbances

The direct voltages in the electronic INTERBUS circuits are generated from the AC
supply voltage using control circuits. In the event of malfunctions in these
INTERBUS devices or their electronic circuits, the supply voltage must be checked
and, if certain symptoms are present, the AC supply voltage must also be checked.
In general, interference voltages are caused by the effects of electrical equipment.
Possible causes include voltage changes (load changes), imbalanced voltages in
three-phase networks (single-ended load), harmonic voltages (frequency inverters)
or voltages from converter drives. In electronic circuits, these interference voltages
lead to changes in the rectified voltages and therefore to changes in the internal
resistance of the electronic circuits. If the voltages are outside the permitted control
95
range (permitted voltage difference), malfunctions may occur in the INTERBUS

modules. In electronically controlled single-phase power supply units, an
imbalanced voltage from the three-phase network leads to the same sort of
malfunctions as a change in the AC supply voltage.
The AC supply voltage or three-phase current can be diagnosed using an
oscilloscope. It should be noted that the AC supply voltage oscillates in a permitted
voltage range around the specified voltage. For Phoenix Contact INTERBUS
modules, this voltage is between 20 and 30 V, with a permitted voltage ripple of +/3.6 V. In Figure 2.10, the left-hand side shows a simplified representation of
interference signals and the right-hand side shows the voltage interference peaks
actually recorded in practice using a Fluke Scopemeter 99B. The diagram
illustrates disturbing pulses and voltage interference peaks in the AC supply
voltage, which can be caused by motor starters, thyristor controllers, sparks when
welding, the isolation of fuses or atmospheric discharge. The dashed box on the
left-hand side indicates a suppression of the voltage, which is wired to the supply
line.
[Time]
Figure 2.10: Voltage interference peaks caused by motor starters, thyristor

controllers, etc.
[Time]
Figure 2.11: Short-term voltage interrupts

An example of short-term voltage interrupts is given in Figure 2.11. The left-hand
side again provides the theoretical representation while the right-hand side is a
recording from a Fluke Scopemeter. These short-term voltage interrupts are
generated e.g., by phase compensation, overload or short circuits.
96
As a rule, protection from voltage peaks and disturbing pulses can be provided by
AC supply filters and interference suppression filters. Figure 2.10 shows the
voltage curve before and after an interference suppression measure, which is
connected in the supply line before the device. In general, to ensure error-free
operation of the electrical equipment connected to the supply network, the
operation of one device must not adversely affect that of another device; the Digital
modules may react even to relatively low interference signals at the inputs with
undesirable and unknown malfunctions. For example, a poor contact to the supply
line (poor soldering points or loose screw connections) or couples wiring may lead
to malfunctions.
2.4.5 Lightning and ESD Protection

Lightning protection can be divided into external and internal lightning protection.
External lightning protection includes lightning conductors, down conductors,
grounding systems, area shielding, and protection of buildings against fire and
mechanical damage, but does not include the protection of electrical equipment.
Internal lightning protection includes equipotential bonding, feeds, and area
shielding.
Lightning protection equipotential bonding connects all conductive parts within a
building such as connections for water, heating, air conditioning, ventilation, gas,
grounding, design elements, etc. and all conductive systems, which leave the
building, such as power and water connections, cable TV, telecommunications and
data cables. Active systems are connected using surge voltage equipment that can
safely carry lightning strikes.
As can be seen in Figure 2.12, when a lightning surge current from a lightning
strike is picked up and discharged, the external lightning protection causes EMI
problems for electronic and electrical devices located in the protected building.
Voltages of several thousand volts are induced in cables laid parallel and diagonal
to the lightning arrester. These surge voltages are transferred to the electrical
components via power supply and data lines. These coupled voltages even occur
in the event of a lightning strike near to an electrical system with lightning
protection.
97
Lightning strike
Power supply
INTERBUS
Coupling through
induction
Induction loop
Equipotential
bonding
Figure 2.12: EMI problems on a lightning strike

Wherever the current changes suddenly, voltages are induced in the adjacent
cables according to Faraday's law. This occurs, for example, when switching load
contactors and in the event of electrostatic discharge (ESD). Interference caused
by ESD is difficult to analyze. The time of the sporadic interference or the particular
season may provide clues when troubleshooting.
In order to protect low voltage systems, all plants must be included during planning
and implementation, and a central system should be responsible for their
consistent monitoring. When it comes to protecting electronic parts and
components and to extinguishing the AC supply follow current after a lightning
strike, fuse components are available, which divert the short circuit current that
would otherwise destroy the electrical parts. Phoenix Contact offers Flashtrab
components for this purpose, which are integrated into the main distribution after
the AC supply input as the first selective safety measure. When considering safety
measures, a distinction should be made between the following network types: TNC-S, TN-S, TN-C with PEN, TT, and IT.
Power distribution networks in Germany are usually operated as TN

networks and have common PEN conductors at least to the terminal
box. Representations of the TN-C-S, TN-S, TN-C with PEN, TT, and
IT network types can be found on the accompanying CD-ROM.
Surge voltage protection, as described above, must always be implemented in new

systems. Consistent and correctly installed safety measures increase the
availability and runtime of the system, and ensure its safe operation. A building with
a lightning protection system is also protected against fire and mechanical damage.
98
However, a lightning protection system does not protect the electrical equipment.
Additional safety devices must be installed to provide protection against
interference and surge voltages.
2.4.6 Protection from Transient Voltages

Transient voltages are very short-term voltages, which are several times the AC supply
voltage. These voltages have a negative effect on electrical INTERBUS components,
because electrical parts depend on their dielectric strength. For example, a coupled
transient voltage in a 5 V DC circuit, which is caused by an induction of an inductive
load, may be several hundred times the nominal voltage and will most probably destroy
the electronic parts. Transient voltages have very short response times (a few s) and
then drop again relatively slowly (10 to 100 s).
To prevent the destruction of electronic components by coupled transient voltages,
these transients must be discharged extremely quickly via the equipotential bonding
lines. Discharge currents may reach a level of several thousand amperes. The surge
voltage is discharged using components from the Trabtech range (Transient
Absorption Technology). This includes components such as spark gaps with arc
chopping technology, gas arresters, varistors, and suppressor diodes.
2.4.7 Cable Installation, Shielding, Grounding, and Equipotential

Bonding
When using inverters or frequency inverters, high-frequency interference can be
expected. In order to implement safety measures in advance, i.e., in the planning
phase, these cables must be physically isolated from the data, control, and 24 V power
supply lines in both the control cabinet and on the way to the load.
All data, control, and 24 V power lines should be installed in a

separate cable duct to the high voltage or "inverted" lines.
The shielding of power lines is also important. The line between an inverter and a
motor must be shielded and as much of the shield as possible must be connected on
both sides. When analog signal lines are used (for example in sensors and actuators
for analog input modules), unlike motor lines, as much of the shield as possible should
be connected but only on one side and with low resistance in the control cabinet.
However, if both shield ends, i.e., the shielding on the sensor and actuator side, are
connected then the measured values may be distorted. The shields in the INTERBUS
cables are connected using as much of the shield as possible on both sides with low
resistance.
The wires for shielded INTERBUS cables must be twisted to prevent interference
coupling. The individual wires for the digital signals DI (gray) and DO (yellow) are
twisted with their corresponding differential signal wires DI (pink) and DO (green). The
wire twisting keeps the differential signal virtually free from interference, even if external
interference signals affect the wire pair. An illustration of the signals/differential signals
is given in Figure 2.13 using the example of DO/DO. The fifth wire of the INTERBUS
remote bus, the GND, is normally brown.
99
DO
DO
Difference is always the same
Figure 2.13: Twisting INTERBUS wire pairs

In digital devices, the difference in resistance between these two connection points
should be noted. If there is a difference in potential, then separate potential output lines
should be installed.
In order to discharge interference in the control cabinet, the metal control cabinet
parts, the mounting plate holders for electronic components, etc. should have a
large surface connection with a very good level of conductivity to the protective
conductor potential. The grounding cable cross section must be a minimum of 2.5 mm
(14 AWG). For certain device types, depending on the nominal current consumption,
larger cross sections may be required for the grounding cables. Pipes such as gas or
water pipes must not be used as the protective conductor.
If electronic components, relays, contactors, and solenoid valves are integrated in a
circuit, and contain components with voltages that emit interference, these components
should be fitted with filters, RC combinations, spark extinguishing combinations, and
surge voltage limiting parts.
Disturbing induction voltages can often be reduced quickly by connecting the following
RC element shown in Figure 2.14 with the values R = 100-200 and C = 222-470 nF.
Coil,
winding
Resistor
100 - 200 Ohm
Capacitor
222 - 470 nF
Figure 2.14: RC element for connecting components that emit interference

Routing lines in the control cabinet should be short, and should be installed close to the
reference potential (metal walls or plates). This also reduces the EMI risk.
100
Electrical isolation is installed in Figure 2.15. The INTERBUS modules are supplied
with communications power and I/O voltage by separate power supply units. Every 0 V
power supply unit output (1) on the secondary side is fitted with a jumper to the
equipotential bonding, which creates a short circuit in the power supply unit on a
ground fault. In addition, the 0 V potentials (2) of the distributed control cabinets are set
to the same level using a 10 mm (8 AWG) RS-232 cable. This leaves the user with
nothing to worry about.
240 V/400 V power supply from main distribution with TN-S network type, star grounding, no jumper between PE and zero
L1-3, N, PE
Quint 5
Quint 5
DC o.k.
L
AC
N
L1-3, N, PE
Electrical isolation between communications power and I/O
Quint 5
- - + +
PE
1
EB, to equipotential
bonding in the control
cabinet
Quint 5
DC o.k.
L
AC
N
DC o.k.
- - + +
PE
10 mm2 conductor
(8 AWG)
AC
N
- - + +
PE
AC
N
- - + +
PE
EB
EB
EB
Control cabinet 2
Large distance
Control cabinet 1
0V
DC o.k.
L
0V
24 V
24 V
Communications
power
I/O supply voltage
INTERBUS
Figure 2.15: Danger points for secondary grounding

Although a jumper (1) according to VDE 0160 is permitted between 0 V and the
equipotential bonding, this removes the desired electrical isolation of the power
supply units. The danger that further "accidental" or "un-noticed" ground to ground
connections may occur is now very high. This leaves the way open to
"compensating currents" and all their associated side effects.
Therefore: A deliberate ground connection to the ground potential should be
avoided to prevent the creation of "meshes", in which external currents could flow
in some sections.
If the grounding concept in the rest of the system is poor, a very high compensating
current may flow through the equipotential bonding line between the distributed
stations (2). A sensible solution in this case is to improve the existing star
grounding measures instead of creating a meshed network using equalizing
conductors. Another ground cable, parallel to the supply line, should be installed
here.
101
However: It is very difficult to recommend a star grounding concept or simply an

additional equalizing conductor if existing structures such as high voltage I/O
devices are used. Optimizations to the grounding conditions should always cover
the entire plant, i.e., also the high voltage side.
Tip: In the event of long distances between different control cabinets connected via
INTERBUS, the use of fiber optics is a proven way of avoiding meshed
connections, especially in critical industrial environments.
2.5 Assembly Guidelines and Standards

Various regulations and standards must be observed when installing an
INTERBUS system. This section lists some of the applicable national and
international regulations. In addition, the regulations and standards in the land of
application must be followed, which may replace the standards listed here.
DIN VDE 0100
DIN VDE 0110

DIN VDE 0160
DIN VDE 0185
DIN VDE 0472-1
DIN EN 50100-1
TAB Directive
TAB 2000
DIN VDE 0106
DIN 40050
IEC 144
Erection of electrical power installations with a nominal

voltage of up to 1000 V, Part 410; Part 534; Part 540; Part
707
Insulation coordination for electrical equipment within low
voltage systems
Electronic equipment for use in electrical power installations
Lightning protection systems, Part 1
Degrees of protection provided by enclosures (IP code)
Safety of machinery electrosensitive protective equipment
Directive for the use of surge voltage protection devices in
requirement category B in primary current supply systems
(VDEW e.V., 1st Edition 1998)
Classification of power supplies as current-using equipment
and into Protection Classes 0, I, II, III
Part 1
Protection of electrical equipment using housing and covers.
Protection to prevent personnel from touching live or moving
parts within the housing and protection of the equipment
from the penetration of solid foreign bodies
2.6 Practical Tips

Tip 1: Parallel connection of power supplies on the secondary side
Two (different) power supplies or power supply units can be connected in parallel
to increase power or to create redundancy in the power supply units.
A parallel connection to increase power as shown in Figure 2.17 is often used if
existing systems, such as those in Figure 2.16, are expanded and the most
powerful load has a current requirement that cannot be covered by the existing
power supply. In other cases, it may be useful to distribute the individual loads over
independent power supplies as shown in Figure 2.18.
102
Power supply
unit 20 A
+
-
5A
5A
8A
Figure 2.16: Status prior to system expansion

Power supply
unit 20 A
Power supply
unit 20 A
+
-
5A
5A
25 A
Figure 2.17: System expansion after replacement of loads

When power supplies are connected in parallel, the total power must be distributed
evenly over the individual devices. When the adjustable output voltage is
compensated, the power supply units must be set so that the differential mode
voltage of both power supplies remains as low as possible and is thus
symmetrically divided. Compensation is carried out as follows: Only power supply
unit 1 (power supply unit 2 for no-load operation) is connected and the output
voltage is set using a voltmeter. The procedure is repeated for power supply unit 2.
Power supply
unit 20 A
Power supply
unit 20 A
5A
5A
8A
20 A
Figure 2.18: System expansion with an additional load

When both power supply units are connected in parallel on the secondary side, the
(cable) connections to the loads should be the same length and have the same
cross section.
103
A parallel connection to create redundancy in the power supplies is often used if a

particularly high level of operational reliability is required. In the event of a failure in
one of the primary circuits, the second device automatically takes over the entire
power supply without interruption. This principle is illustrated in Figure 2.19. N-fold
redundancy can be achieved by connecting (n+1) power supplies in parallel.
During configuration it is important to ensure that every power supply can meet the
total requirements of all loads. The connections on the primary side should be
made independently of the failure of a phase (L1 for power supply unit 1, L2 power
supply
unit 2). External phase protection for every device increases the operational
reliability of the system enormously. In order to ensure operation in the event of
short circuits on the secondary side, decoupling diodes on the power supply unit
output side should be used for some power supplies.
L1
L2
N
PE
Power supply
unit 20 A
Power supply
unit 20 A
+
-
5A
5A
25 A
Figure 2.19: Parallel connection of power supplies to create redundancy
104
Tip 2: Series connection of power supplies on the secondary side

Power supplies are connected in series to increase the output voltages of the
individual power supplies. For example, two 24 V power supplies connected in
series gives a total output voltage of 48 V.
During configuration, note that only specially designed power

supplies should be used. The power supplies in the Phoenix Contact
CM and Quint ranges can be used without restriction for series
connections. Isolating diodes do not have to be installed.
Tip 3: Checking power supply functions

During configuration, system safety can be increased by programming an
automatic function check for the power supplies. Power supplies in the Phoenix
Contact CM and Quint product ranges have a "DC OK" switching output.
Tip 4: Selective protection of power supplies
If the secondary circuit of the 24 V power supply unit is distributed over several
loads, each output should be protected with its own fuse. This ensures that, if a
fuse blows, only one path is shut down and the remaining loads still receive power.
Tip 5: Design of a comprehensive surge voltage protection concept
In practice, two steps have proven useful when configuring a surge voltage
protection concept:
1. Selecting arresters according to the dielectric strength of the electrical and
electronic systems and devices
2. Defining the correct installation location by dividing the whole area to be
protected into surge voltage protection zones (PZ)
Tip 6: "Sniffing out" harmonics (waves) and EMI
It is not easy to identify sources of electromagnetic interference. The following
devices can help in tracing these sources of interference and a little detective work
is required. A long-wave radio, a tong-test instrument with old-style connected
headset (internal resistance of 2 k) or a copper coil with coaxial cable can be
used to "sniff out" interference. Measurements are made on a measuring
instrument with BNC connection.
2.7 Workshop
1. As shown in Figure 2.20, a power supply with the output values Ia = 4 A and
Ua = 24 V supplies a load via a 10 m (32.81 ft.) copper cable. The cable has a
cross section of 2.5 mm (14 AWG).
Task: How high is the voltage drop and the voltage at the load?
105
u=?
Ia = 4 A
+
Ua = 24 V
Power supply
Ua = ?
Load
-
1 = 10 m (32.81 ft.) with cross

section of 2.5 mm2 (14 AWG)
Figure 2.20: Determine the voltage drop and the voltage at the load
2. As shown in Figure 2.21, a 3-phase power supply of 20 A/3*400 V is
connected from a sub-distribution in a TN-S network via a 100 m (328.08 ft.)
copper cable (cross section = 2.5 mm [14 AWG]). At the sub-distribution, the
voltage between the wires UL = 400 V.
Task: How high is the voltage drop U and the voltage between the wires on the
input side of the power supply Ua?
u=?
L1 } UL1L2 = 400 V AC
L2
Sub-distribution L3
N
PE
Ua = ? {
L1
L2
L3 Power supply
N
PE
+
-
I = 100 m (328.08 ft.) with cross

section of 2.5 mm2 (14 AWG)
Figure 2.21: Determine the voltage drop and the voltage at a 3-phase power
supply unit
3. Configure a surge voltage protection concept for the Inline segment shown in
Figure 2.22.
Bus
terminal AI AO
DO
DI
Figure 2.22: Configure a surge voltage protection concept for the Inline
segment
106
4. Configure a surge voltage protection concept for an INTERBUS ST remote bus

segment as shown in Figure 2.23.
Power Bus
supply terminal
L
N
PE
BK-T
AO
AO 4/SF4
AI
AI 4/SF4
AI
AI 4/SF4
Figure 2.23: Configure a surge voltage protection concept for the ST segment
The answers to the "Configuration" Workshop can be found on the

2.8 Questions for the "Configuration" Section

1. What are the differences between regulated and non-regulated power
supplies? Which power supply unit functions are particularly important for the
automation sector?
2. How can short-term voltage dips on the primary side be prevented in primary
switched power supplies?
3. How many INTERBUS local bus devices can be connected together?
4. Why is a jumper required between contacts 5 - 9 in the outgoing INTERBUS
remote bus connector?
5. How should the power be supplied to the I/O device and logic part of remote
and local bus devices?
6. How is immunity to interference provided in INTERBUS cables?
7. How is immunity to interference provided in INTERBUS devices?
8. Describe the 9-pos. D-SUB shield connection for remote bus devices.
The answers to the questions for the "Configuration" Section can be

found on the accompanying CD-ROM.
INTERBUS Diagnostics
107
3 INTERBUS Diagnostics
The diagnostic properties of the INTERBUS system are often praised by both
practical experts and theorists. In fact, the great market success of the INTERBUS
system is due in no small part to its diagnostics, which enable the location and
cause of an error to be determined precisely.
This section first provides a general description of INTERBUS system diagnostics,
from segment designation to device number, and then continues with explanations
of more complex diagnostic topics. The accompanying CD-ROM contains an
introduction to the use of the DIAG40 software tool, which the practical expert can
use to read all INTERBUS master information.
After working through this section, you will be able to understand the limitations of
diagnostics using LEDs and how even serious error descriptions can be controlled
using suitable methods.
The following topics are covered:
- Use of standard registers for diagnostic purposes
- Reset behavior of the INTERBUS system
- INTERBUS system error types
- Error localization with SUPI 3 INTERBUS devices and older SUPI chips
- Representation of an error in INTERBUS Generation 4
- Diagnostic options in SUPI 2, SUPI 3, and combined systems
- Transmission quality
- Evaluation of INTERBUS module diagnostic LEDs
- Introduction of the diagnostic programs PC WORX/CMD and DIAG+
- Serious error descriptions (E0X errors)
- Hardware diagnostics
Programming using standard registers

Page 109
Circuit versions for programming using standard registers
Page 117
Device representation with forward and return paths
Page 134
Device representation with forward and return paths in the Loop Page 139
system
Page 147
Procedure for troubleshooting using diagnostic LEDs
Page 151
Diagnostic programs
Page 156
Flowchart for troubleshooting
Page 159
Measuring circuit for checking an RS-485 driver
108
The diagnostic properties of INTERBUS slave chips are being continuously

improved. The SUPI 3 or later (new SUPI 3-OPC) provides 100% diagnostics of
CRC errors, see also Section 1.5 "INTERBUS Protocol Chips". Generation 4
master firmware supports the following types of slave system:
-
INTERBUS systems for SUPI 3 or later
INTERBUS systems with slave chips older than SUPI 3
INTERBUS combined systems consisting of both earlier versions
3.1 Diagnostic Interfaces and Designations

INTERBUS diagnostics are not only hugely powerful, but also quick and easy to
use. The user has easy access to the diagnostic data using the application
program and diagnostic tools.
The following diagnostic interfaces are available to the user, see Figure 3.1:
Software
Diagnostic programs
- Integrated diagnostics in
CMD/PC WORX
- DIAG+
- DIAG40
Diagnostic registers
- Use of diagnostic registers
- in the application
Hardware
Controller board diagnostics
- Central diagnostic display on the
jjjINTERBUS controller board
INTERBUS device diagnostics

- Distributed diagnostic display on the
jjINTERBUS modules
- Use of the INTERBUS

- master command and
message interface
Figure 3.1: Diagnostic interfaces

Optical indication on the controller board and INTERBUS modules: the current
status of the INTERBUS system can be determined using the diagnostic display on
the controller board or diagnostic LEDs on the INTERBUS modules without the use
of diagnostic software. This method can be used to remove simple bus errors.
Diagnostic interface between application program and controller board: this
interface consists of the diagnostic registers and a command and message
interface. The most important diagnostic information can be accessed via the
diagnostic registers. The standard function registers and the mailbox interface can
be used to influence the INTERBUS master.
109
Diagnostic information can be accessed via the RS-232, Ethernet, ISA or PCI
interface. Diagnostic software (CMD/PC WORX, DIAG+ or DIAG40) can access all
diagnostic data using these interfaces.
INTERBUS Designations for Diagnostic Purposes
As this section frequently refers to device numbers, physical numbers, segment 1,
OUT1, etc., Figure 3.2 provides an overview of these terms.
Physical number/
logical number
0/0.0
OUT 1
Level 0
Remote bus device

PHOENIX
r
CONTACT
e
11 1 1111
B1 2 3 4 5 6 7 8 90 1 2 3 4 5 6
A
R
C
R
D
a
d
y
U
B
(
1
)
1/1.0
Segment 4 includes
device 4.0 and the
RS-485 output driver
for device 2.0
(highlighted area segment 4)
B
A
R
C
R
D
Note: 16 levels are

supported in the
INTERBUS system,
Level 0 - Level 15
OUT1
P
l
St
a
A
Bu
a ti s
n
d g
Se
PHOENIX
to
d n.
m
CONTACT
r.
1 2 34 56
re
ad
y
E
LD
OUT2
Level 1
Level 2
P
lSt
a
At s
Bu
n
do g
iSe
tn
d .
m
r.
B 12 3 456
A
R
C
R
D
PHOEN IX
C ONTAC
T re
PHOENIX
r
CONTACT
e
2/2.0
1 1 11 111
B1 2 3 4 5 6 7 8 9
0 1 23 456
A
R
C
R
D
a
d
y
U
B
(
1
)
a
d
y
E
L
D
3/3.0
PHOENIX
r
CONTACT
e
11111 11
B1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
A
R
C
R
D
a
d
y
U
B
(
1
)
BK-T
4/4.0
OUT2
Level 1
Local bus device
BK-T
DO 16/3
DI 32/2
AI 4/SF4
5/5.0
6/5.1
7/5.2
8/5.3
Level 1
9/6.0
10/6.1 11/6.2 12/6.3
Local bus device
Figure 3.2: INTERBUS topology with various designations

Physical and Logical Device Numbers
BDO 32/2
110
Device numbers are frequently encoded in a word. This is true, for example, for all
firmware services, which are required for programming the bus configuration or in
1
the diagnostic parameter register. The segment number is given in one byte and
the local bus number is given in the other byte.
Example: Device 6.1 0x0601
Values from 0x80 of the low byte are an exception. They do not indicate a local bus
number, and are reserved for additional information. 0x80 (OUT 1) designates the
remote bus interface and 0x81 (OUT 2) designates the local bus interface of a bus
terminal module, see Figure 3.2.
Example: Error in the local bus at bus terminal module 6.0 0x0681
A distinction is made between physical and logical device numbers. In most case,
logical device numbers are used rather than physical device numbers. A logical
device number consists of the segment and local bus position. The user can freely
designate this number, see Figure 3.3. Physical device numbers reflect the
physical location of devices in the INTERBUS ring; devices are numbered
consecutively in their physical order.
0
0.0
Physical numbering
BK
MT
DO 16/3
Logical numbering
DI 16/3
13.0
2
DIO 8/8/32A
DO 16/3
DI 16/3
13.1
7
BK-T
BK
MT
AO 4/SF4
BK-T
7.0
6
DIO 8/8/32A
7.1
13.2
1.1
40.0
40.1
7.2
10
Figure 3.3: Logical and physical device numbers
1.0
AO 4/SF4
The position of the low and high byte is described in Section 3.2.
111
3.2 Standard Function Registers

Some of the most important registers in the INTERBUS system are the standard
registers. These registers are used for diagnostic purposes and to influence
INTERBUS. Frequently used firmware services, e.g., start and stop data cycles,
can be executed by setting a bit. This enables the user to create a simpler
program, because it is easier to implement the manipulation of a bit than it is to
send a firmware command to the INTERBUS master via the mailbox interface.
Technically, individual firmware commands are already preconfigured on the
controller board and are activated via the signal interface.
The standard function registers are located on fixed addresses in the MPM and can
be copied or moved to any addresses in the DTA (Data Area, see MPM
segmentation in the Basics section) of the MPM using a set value request
(firmware service). The diagnostic registers are copied because they are outputs
for the INTERBUS master. The standard start and parameter registers must be
moved, otherwise requests will be sent to the INTERBUS master from two different
points. PC WORX does not copy or move the standard registers to the DTA, but
instead moves them to the XDTA.
In practice, the standard registers can be parameterized via CMD/PC WORX
software. The user specifies the DTA address/XDTA address, which is then copied
from the relevant host system driver to the corresponding data areas in the host
system.
Figure 3.4 shows the parameterization of the diagnostic registers using CMD in a
S7 controller board. In high-level language applications, the "Set_Value" service is
used because the parameterization is usually carried out by the application
program and not by CMD/PC WORX. CMD/PC WORX use the "Set_Value" service
internally.
In CMD/PC WORX (Version 2.02 or earlier), the settings dialog box for the
standard registers can be found in the context menu for the controller board under
"Settings", see Figure 3.4.
112
Figure 3.4: Setting the standard registers using CMD
3.2.1 Addresses of Standard Registers in the MPM

The addresses of standard registers are identical for all G4 controller boards. The
only exception is controller boards, which do not have a complete MPM. These
controller boards use a DPM (Dual-Port Memory). The DPM is only 2 or 4 KB, unlike
the complete MPM, which is 64 KB. The standard registers are still available in a
DPM, but are at other addresses.
Table 3.1: Addresses of standard registers in the MPM
Standard Register
Address (hex)
Diagnostic status register
3520
Diagnostic parameter register
3522
Extended diagnostic parameter register
37E6
Standard function start register
3524
Standard function status register
3526
Standard function parameter register
3528
Slave diagnostic status register
37EC
Field Controller diagnostic status register
Motorola Target (M68) : 37E8
Intel Target (IPC) Node 0: 349E
Intel Target (IPC) Node 2: 3B08
113
3.2.2 Diagnostic Status Register

Byte n
Byte n+1
0 : BSA BIT:
Bus segment aborted (switched off). One or more bus
segments have been switched off.
0 : USER ERROR:
Error in the user program.
1 : SYSFAIL:
The controller board has activated the SysFail signal.
The output data is reset.
1 : PERIPHERAL FAULT:
An INTERBUS device has detected an error in the I/O
area.
2 : RESULT BIT:
The result of the processing, a service sent by the standard
functions, was negative.
2 : BUS ERROR:
A remote bus or local bus error has ocurred.
3 : Synchronization error:
The INTERBUS master is not recieving a
synchronization pulse. This error only occurs in a
synchronous operating mode.
3 : CONTROLLER ERROR:
The controller board has detected an internal error.
4 : Data cycle error:

Error when operating a data cycle. This error only occurs in
a synchronous operating mode.
4 : DETECTION BIT:
Error localization is running. LOOK FOR FAIL
appears on the diagnostic display.
5 : Bus warning time:

The bus warning time has elapsed
(can be parameterized).
5 : RUN BIT:
The controller board is in the RUN state. Data cycles
are being exchanged.
6 : Quality bit:
The bus quality has deteriorated (can be parameterized).
6 : ACTIVE BIT:
The controller board is in the ACTIVE state. A
configuration frame has been activated.
7 : Message in SSI:
There is a message in the standard signal interface.
7 : READY BIT:
The controller board is in the READY state.
The internal selftest is complete, and the controller
board is ready for operation.
Figure 3.5: Diagnostic status register

Every bit in the diagnostic status register corresponds to a specific status of the
bus system. In the diagnostic parameter register, the controller board provides
additional information about the current status of the diagnostic status register.
Not every operating system permits unlimited access to all memory

addresses. A Dynamic Link Library (DLL) with a kernel mode driver is
required for Windows NT and Windows 2000. This means that the
diagnostic registers can only be accessed via the functions of the DDI
(Device Driver Interface) or corresponding firmware commands. The
DDI provides functions for transmitting firmware commands to the
controller board.
114
3.2.3 Diagnostic Parameter Register

Byte n
Byte n
Byte n
Byte n+1
Byte n+1
Error code: 0x0A02

User error. The controller board could not process the last
called service.
Byte n+1
Device number: 0x0208

E.g., specification of the error location after successful error
localization. Segment number and position in the segment of the
located device.
Figure 3.6: Diagnostic parameter register

The diagnostic parameter register contains either error locations or error codes,
depending on the type of error.
3.2.4 Extended Diagnostic Parameter Register

The extended diagnostic parameter register contains additional information about
the current status of the diagnostic status register. In the event of a remote bus
error, it contains, e.g., the error code for the master firmware, while the diagnostic
parameter register indicates the segment and the position of the error.
This register is also used in connection with single-channel diagnostics in some
INTERBUS modules. This enables the user to diagnose the channel status, the
initiator supply, and the power supply of the INTERBUS module.
Not all INTERBUS modules offer single-channel diagnostics. These modules are
usually used when a very high level of availability is required, e.g., in the
automotive industry. The Phoenix Contact Rugged Line product range ensures the
optimal use of these extended diagnostic options.
115
Byte n
Byte n+1
Channel-specific diagnostic message

KKKKK: Channel number
T=0: Error removed
T=1: Error present
Group-specific diagnostic message

G: Group number
U: Supply voltage number
Bit=0: No error
Bit=1: Error
G4
G3
G2
G1
G8
G7
G6
G5
U4
U3
U2
U1
Figure 3.7: Extended diagnostic parameter register
Single-channel diagnostics is available in firmware Version 4.4 or later

and must be enabled before use.
3.2.5 Diagnostic Registers in the Diagnostic Display

INTERBUS
Byte
n+1
0
1
2
3
4
5
6
7
Error type
Display in diagnostic status register
Segment and position of the error
Display in diagnostic parameter register
n
0
1
2
3
4
5
6
7
Error code
Display in extended diagnostic parameter register
Figure 3.8: Diagnostic registers in the diagnostic display
116
Figure 3.8 shows which information from the diagnostic display is given in the
diagnostic registers.
3.2.6 Standard Function Start Register

The standard function start register makes it easy to execute frequently used basic
functions of the INTERBUS system with and without parameter transfer.
Byte n
Byte n+1
Can only be used with synchronous

operating modes
Remove device jumpering*

Jumper device*
Swith on deactivated segment*
Switch off segment*

Clear diagnostic display
Stop the INTERBUS system, reset

outputs and request a new configuration.
This service requires the entry of the
configuration frame number in the parameter
register for the new configuration.
Start the INTERBUS system
* The device number must also

be entered in the parameter
register.
Figure 3.9: Standard function start register
3.2.7 Standard Function Status Register

The progress of services activated by the standard function start register can be
tracked in the standard function status register. While the action is being
processed, the bit in the same position in the status register is set. Successful or
unsuccessful service processing is indicated in the result bit in the diagnostic status
register. If the result bit is set, the result of the service processing is negative.
117
The status register is frequently used to reset the service request from the
start register. An RS-Flip-Flop or similar circuit can be used for easy
operation, see Figure 3.13. This example was created using PC WORX
and does not use the standard registers as individual bit objects but
instead uses a different word variable for each register. In practice, there
are often difficulties working with word objects according to IEC 61131-3
and manipulating individual bits within the word object.
3.2.8 Standard Function Parameter Register

The standard function parameter register contains the parameters required for the
successful execution of services activated in the start register, e.g., the device
number.
Byte n
Byte n
Byte n+1
Byte n+1
Device 2.8 should be switched off. The device number

must be entered in the standard function parameter
register.
Figure 3.10: Standard function parameter register
118
3.2.9 Slave Diagnostic Status Register

For system coupler applications, knowing the status of the higher-level INTERBUS
system is important. The slave diagnostic register can be used to introduce suitable
measures in the event of errors in the higher-level INTERBUS system.
Byte n
Byte n+1
Reserved
Process control:
For a system coupler with redundant slave, this bit indicates
which slave is controlling the process.
0 - Slave 1 is controlling the process
1 - Slave 2 is controlling the process
Slave is in the READY state:
The slave diagnostic status register is initialized.
Power ON:
The slave part is supplied with power.
Slave part is initialized:
The slave parameterization was completed successfully. The
higher-level INTERBUS system is not in the RUN state.
Fail:
No data transmission to/from slave. The higher-level
INTERBUS system is in the Reset state (alarm stop, bus
error). The slave output data is set to zero.
Slave data transmission:

INTERBUS data transmission to/from slave. The
higher-level INTERBUS system is in the RUN state.
Figure 3.11: Slave diagnostic status register
3.2.10 Field Controller Diagnostic Status Register

The Field Controller firmware describes the Field Controller diagnostic status
register, which maps the state machine of the ProConOS control system.
In ProConOS, this register can be accessed via the system flags. Users, who do
not want to use PC WORX communication methods, can access the MPM directly
to determine the status of the control system.
119
Byte n
Byte n+1
Reserved
Loading:
A permanently stored boot
project is started.
Reserved
Halt:
ProConOS in HALT state
Stop:
ProConOS in STOP state
Run:
ProConOS in RUN state
Power ON:
ProConOS initialized successfully.
Status bits can be transferred
Figure 3.12: Field Controller diagnostic status register
3.2.11 Executing Services Using the Standard Function

Registers
Function activation in the
start register
Removal of request, otherwise the function

would be executed again after 7 s.
Display of processing
in status register
1
0
Standard function start bit
1
0
Standard function status bit
1
0
Standard function result bit

Value
If the service requires another

parameter in the parameter register,
it must be transferred to the
parameter register before the start
bit is activated.

The result bit indicates the success of the service
processing.
Result bit = TRUE : Function processed negatively
Result bit = FALSE : Function processed positively
Figure 3.13: Timing of a function execution with parameter transfer
120
Figure 3.13 describes the timing of a function execution via the standard function
registers.
Figure 3.14 illustrates a circuit version created using PC WORX as a practical
example of function execution with parameter transfer. Two inputs (start and stop)
can be used to start or stop the data cycles. This example uses the status bits to
reset the service request (here the start and stop command).
Figure 3.14: Use of the standard registers
3.3 Reset Behavior of the INTERBUS System

Before the INTERBUS system error types are described, the reset behavior must
be explained, as knowledge of this is required for understanding later sections.
The reset behavior plays a very important role in the application for bus systems,
especially INTERBUS. It must always be possible to place an automation system in
a safe state in the event of an error or through a deliberate user action. Nothing is
worse than an automation process, which continues production despite
uncontrollable states.
The INTERBUS system uses a graded reset, which not only places the system in a
safe state but also performs error localization until the system reaches the safe
state.
A reset here is not a controller board hardware or software reset, but the internal
reset mechanism in all INTERBUS devices, which ultimately resets the outputs of
all devices.
The INTERBUS system starts a
timer to measure the interrupt
time if no activity is detected on
the two-wire cable after 26s.
121
The INTERBUS system triggers a

"short reset". The outgoing
interface of the device is closed.
The output data is not reset.
M easurement of
interrupt time
0 26 s
The INTERBUS system triggers

a "long reset". In addition to
the measures implemented on a
"short reset", the output data is
also reset.
M easurement of interrupt time is continued
256 s (SUPI 2 or earlier)

2 ms (SUPI 3 or later)
25 ms
Short reset
Long reset
Figure 3.15: Graded reset
In the INTERBUS system, physical data transmission is via a two-wire

cable. An additional reset cable is not used. In order to ensure the
availability of the reset function, the connection is monitored. Status
telegrams sent during breaks in transmission ensure that the connection
monitoring counter is constantly reset. After 26 s without cable activity,
the connection monitoring counter is activated.
The "short reset" is triggered at different times in a SUPI 3 or SUPI 2 chip. This
behavior improves error localization options.
3.4 INTERBUS Error Diagnostics

3.4.1 Representation of an INTERBUS Error in a G4 INTERBUS
System
If an error occurs during operation or startup, it can be specified by the INTERBUS
master using an error code or error location. Various different types of error can
occur. They are divided into groups and identified by abbreviations. The length of
the abbreviation is limited to four characters, as it must fit on the diagnostic display
of a controller board. The following error types are possible:
-
CTRL
Error on the controller board
BUS
No clear error localization, just an error area
RBUS
Error in specified INTERBUS segment
LBUS
Error in specified local bus segment
DEV
Device error
OUT1
Error on the outgoing remote bus interface
122
OUT2
Error on the branching interface (remote or local bus)
PF
Peripheral fault (I/O error)
EVNT
Event error
FC
Field Controller error

Phoenix Contact provides a Diagnostics Guide [25], which describes

all error codes and practical tips for removing the error. This
Diagnostics Guide can be downloaded free of charge from the
Phoenix Contact website or can be purchased in a handy pocketsized format. This guide should always be kept to hand.
The accompanying CD-ROM provides a list of all firmware errors in
compressed format. This error list also includes errors, which are not
normally listed in available documentation.
An INTERBUS device is always assigned its incoming bus cable.

Errors on the transmission path to the device or at the device itself are
reported by indicating the device number. This is known as segment
representation.
The basic error types are described here. Six of these error types are considered in
more detail later.
INTERBUS
In the event of an error in
the INTERBUS system, the
diagnostic routine is started
automatically. During error
localization, the message
"LOOK FOR FAIL" is
Segment 1
displayed on a controller
board
with
diagnostic
display. The DETECT bit in
the
diagnostic
status
Segment 2
register is set during
troubleshooting.
Once troubleshooting is
complete, the detected
Segment 3
error is indicated in the
diagnostic
display
or
diagnostic register. Data Figure 3.16: Error type: Troubleshooting (LOOK FOR FAIL)
transmission
on
the
INTERBUS
system
is
stopped. The outputs are
reset.
All error types are explained using an example with the corresponding INTERBUS
topology. The possible error area is indicated in the INTERBUS topology.
Byte
n+1
0
1
2
3
4
5
6
7
0
1
2
3
4
5
6
7
123
INTERBUS-S
The CTRL message

(controller
error)
indicates an error on the
controller board. This is
an internal hardware or
firmware error. This often
means there is also a
problem
with
the
parameterization
memory.
The controller board
should be checked.
Segment 1
Segment 2
Segment 3
Figure 3.17: Error type: Controller board error (CTRL
ERROR)
Remote bus error in the

specified
INTERBUS
segment. The error area
includes the outgoing
interface of the previous
device (here INTERBUS
device
2.0),
the
transmission
path
between device 2.0 and
device 3.0, and device
3.0 itself. On a remote
bus error, the outputs are
reset. Data transmission
is stopped.
INTERBUS
Byte
n+1
0
1
2
3
4
5
6
7
Segment 1
n
0
1
2
3
4
5
6
7
Segment 2
Segment 3
Figure 3.18: Error type: Remote bus error (RBUS)
124
Possible causes of a remote bus error:

-
INTERBUS device is faulty
Communications power not present (fuse faulty or voltage supply not present)
The transmission medium is faulty (e.g., faulty remote bus cabling, faulty fiber
optic converter, infrared transmission path or slip ring rotor)
Bus cable shielding
Grounding/equipotential bonding
Electromagnetic interference
Faulty connectors or cold junctions
Voltage dips on the communications power of the specified remote bus device
Missing or faulty RBST jumper in the outgoing bus connector of the previous
device
Driver block in previous device is not OK
Electronics module not securely placed in the base (e.g., ST module)
Local bus error in the

specified
INTERBUS
segment or segment
position.
Data
transmission is stopped
and the outputs are
reset. The error area
includes the outgoing
interface of the previous
device
1.1),
the
transmission
path
between device 1.1 and
device 1.2, and device
1.2 itself.
INTERBUS
Byte
n+1
0
1
2
3
4
5
6
7
Segment 1
n
0
1
2
3
4
5
6
7
Segment 2
Segment 3
Figure 3.19: Error type: Local bus error (LBUS)
Possible causes of a local bus error:

-
INTERBUS device is faulty
Communications power not present (fuse faulty or voltage supply not present)
Faulty connectors or cold junctions
125
Missing or faulty LBST jumper in the outgoing bus connector of the previous
device
Bus cable shielding
Grounding/equipotential bonding
Electromagnetic interference
Driver block in previous device is not OK
Electronics module not securely placed in the base (e.g., ST module)
INTERBUS
Error on the outgoing
interface of the specified
INTERBUS device. This
error always occurs if the
cause of the error is not
clear. During normal
Segment 1
operation,
the
error
occurs in test mode for
bus
errors
on
the
outgoing interface during
startup, because the
Segment 2
INTERBUS configuration
is not yet known. It also
occurs if an unconfigured
remote bus interface is
Segment 3
connected
to
an
INTERBUS module.
Figure 3.20: Error type: Remote bus error at OUT1
Data transmission is
stopped and all outputs
are reset.
Byte
n+1
0
1
2
3
4
5
6
7
0
1
2
3
4
5
6
7
The causes of an OUT1 error are the same as for a remote bus error (see above).
126
Error on the branching

interface (remote bus or
local
bus).
Data
and all outputs are reset.
The INTERBUS master
was unable to determine
an exact error location.
The error area is all
INTERBUS
modules
connected
to
the
outgoing
interface,
including
the
output
driver for the outgoing
interface.
INTERBUS
Byte
n+1
0
1
2
3
4
5
6
7
Segment 1
n
0
1
2
3
4
5
6
7
Segment 2
Segment 3
Figure 3.21: Error type: Remote bus error at OUT2
The causes of an interface error at OUT2 are the same as for a remote bus or local
bus error, depending on the connected interface type.
A bus error is indicated if

INTERBUS
the diagnostic routine
cannot clearly determine
the error location. Data
transmission on the bus
is stopped. All outputs
Segment 1
are reset. The error
location is the specified
device 2.0), the previous
device (here 1.0), and all
Segment 2
the devices connected to
its branch (here 1.1
1.3). The transmission
paths between these
Segment 3
devices are also included
in the error area.
Figure 3.22: Error type: Bus error (BUS)
Byte
n+1
0
1
2
3
4
5
6
7
0
1
2
3
4
5
6
7
The causes of this error are the same as for a local or remote bus error. It should
be noted that this error usually occurs in the event of short-term voltage dips or
strong electromagnetic interference.
127
User errors refer to

operating errors made by
the INTERBUS user. An
error has been made
when sending services in
the application program
or commands via a
command interface (e.g.,
CMD). Data transmission
is not interrupted by a
user error.
INTERBUS
Byte
n+1
0
1
2
3
4
5
6
7
Segment 1
n
0
1
2
3
4
5
6
7
Segment 2
Segment 3
Figure 3.23: Error type: User error (USER ERROR)
The
PF
message
indicates a module error.
INTERBUS devices may
report peripheral faults
under various conditions.
They usually occur after
a failure of the I/O
voltage
(for
input
modules) or overload of
an input or output. Data
transmission
is
not
interrupted
on
a
peripheral fault.
INTERBUS
Byte
n+1
0
1
2
3
4
5
6
7
n
0
1
2
3
4
5
6
7
Segment 1
Segment 2
Segment 3
Figure 3.24: Error type: Peripheral fault (PF)
Possible causes of a peripheral fault:

-
Failure of the I/O voltage
I/O voltage switched off
Short circuit at an input or output
Overload of an output module
128
-
Data transmission of the second bus system to an INTERBUS gateway not
active
The peripheral fault is still displayed after the cause of the error has been
removed. A peripheral fault must be acknowledged by the user or
application program. Automatic acknowledgment by the application
program is recommended. Some modules even require special
acknowledgment because the peripheral faults are saved.
Refer to the INTERBUS device data sheet to determine when the device
indicates an peripheral fault.
Note: An IDENT cycle must be run in order to locate the peripheral fault.
The event error message is assigned

lowest priority. An error has occurred,
which does not force the INTERBUS
system to shut down and does not
adversely affect INTERBUS operation.
The cause of an event error could be,
e.g., triggering an illegal interrupt or
violating the data consistency.
INTERBUS-S
Figure 3.25: Error type: Event error (EVNT)
129
INTERBUS-S
A device error is an error,

which is directly assigned
to an INTERBUS device.
There
are
no
transmission errors. Data
and all outputs are reset.
This message appears,
e.g., when an incorrect
length code is allocated
for
this
INTERBUS
device.
Segment 1
Segment 2
Segment 3
Figure 3.26: Error type: Device error (DEV-ERROR)
Even after the diagnostic

routine, the error location
could not be determined.
These
are
usually
temporary errors, which
cannot be detected by
the diagnostic routine. In
a dedicated SUPI 3
system, this type of error
no longer occurs.
INTERBUS
Byte
n+1
0
1
2
3
4
5
6
7
Segment 1
n
0
1
2
3
4
5
6
7
Segment 2
Segment 3
Figure 3.27: Error type: Bus error E1 - E9
Table 3.2: E-errors
E-Error
Meaning
E1
No error was found on acquiring and comparing the configuration.
E2
The maximum INTERBUS configuration has been exceeded.
E3
Reserved
E4
The bus configuration could not be acquired using the
"Create_Configuration_Request" service.
E5
Reserved
E6
Data cycles cannot be started. No error found on acquiring and comparing the
130
E-Error
E7
E8
E9
Meaning
configuration.
The INTERBUS master cannot activate the configuration.
The configuration could not be acquired on startup of diagnostic cycles.
Configuration change during active diagnostics
The causes of an E-error are the same as for a remote bus or local bus error.
3.4.2 Error Types

In an INTERBUS system, six main types of error can occur. They are:
1. Temporary errors
2. Bus reductions
3. Errors in the bus configuration
4. Error on the transmission path
5. Device errors
6. Failure of the supply voltage
1.
Temporary errors are statistically recorded and do not interrupt bus operation.
The most frequent error locations are stored in the diagnostic memory in the
1
form of a Top Ten list. In the event of serious error descriptions, the Top Ten
list can provide information about the error location. This list is particularly
important for SUPI 2 systems. As there is no CRC checker on the return path,
2
the INTERBUS master cannot specify the error location (E-error classes ).
The faulty device is often already in the Top Ten list, because this device has
already caused single errors over a long period of time.
2.
Bus reductions are detected by the premature return of the loop-back word.
They are often caused by a short reset (256 s, 2 ms) triggered on an
INTERBUS device. This closes the outgoing interfaces of the device and
reduces the bus. Timeout errors (TO errors) usually occur before the error is
detected. Interference on the RBST or LBST signals, which indicate a
subsequent remote bus (RB) or local bus (LB), also causes a bus reduction.
The bus reduction is detected by all SUPI types. However, for SUPI types
prior to Version 3, only an error area can be specified. This area comprises
the specified device, including its outgoing interfaces, and the previous device,
including the devices connected to its branch (OUT 2). Precise error
localization on a bus reduction is only provided by SUPI 3 devices.
3.
This type of error can be detected by all SUPI types through the sequential
connection of the INTERBUS configuration.
The Top Ten list is part of the INTERBUS diagnostics. It records the ten most frequent
CRC errors. It can be read via the LCD or using DIAG40.
2
Firmware errors 0BE0 - 0BE9 belong to the E-error class.
4.
131
The causes of INTERBUS errors on the transmission path can be divided into
two groups:
-
Errors caused by broken cable or wire short circuit
Errors caused by electromagnetic and/or electrostatic interference

(EMI). These are particularly prevalent in the event of poor shielding,
potential differences, etc. transmission errors (see Section 2
"INTERBUS Configuration").
Transmission errors can lead to CRC errors, SL line errors (SLL), CR line
errors (CRL), loop-back word errors (LBW), and timeout errors (TO). The
majority of these errors are CRC errors, while the other errors occur with more
or less equal frequency.
In the event of a broken cable, the data flow may be completely interrupted. In
the INTERBUS diagnostics, this is characterized by a string of TO errors.
In this situation, the full diagnostic advantages of SUPI 3 devices are clear. A
SUPI 3 device can locate all errors and even distinguish between transmission
errors and broken cables. Devices prior to SUPI 3 cannot always assign CRC
errors to the relevant device, because they do not have detection on the return
path.
A broken cable or wire short circuit leads to single errors if there is a loose
contact or one wire in a twisted pair connection is broken. The transmission
path is then prone to errors. A special connection, see Figure 3.28, at the
input of the RS-485 receiver, known as a 1-polarization, detects every wire
break and every wire short circuit (1-polarization is also used in SUPI 3
devices to distinguish between transmission errors and broken cables).
INTERBUS switches to the STOP state.
The error description for a broken cable or short circuit is also a string of TO
errors and usually a simultaneous bus reduction. The device after the faulty
device interprets the break in the connection as a bus reset and closes its
outgoing interfaces.
VCC
VCC
Optocoupler
DO
DO
RS-485
/DO
1-polarization
Figure 3.28: Connection for 1-polarization

5.
Device errors can be detected as devices errors on faulty INTERBUS

devices or transmission errors. It is only if the SUPI or a connected CPU
detects a device error and it is reported to the master via the SUPI that it is
classified as a true device error (DEV-ERROR). Most device errors are
132
6.
caused by incorrect parameterization of SUPIs and faulty data paths or data
paths of incorrect length.
INTERBUS devices have a voltage monitoring block, which controls the
communications power. If the voltage falls below a certain value, a device
reset is triggered for at least 50 ms. In currently available standard
INTERBUS devices (e.g., ST, Inline or Rugged Line), this time has been set
to 2 sec to improve error localization.
While the device is in the reset state, only TO errors are diagnosed. If the
voltage reset occurs during bus operation, the INTERBUS device has open
interfaces. The subsequent device would interpret this reset as a bus reset
and close its interfaces bus reduction. The master can begin error
localization.
3.5 Local Bus Diagnostics

Local bus diagnostics and remote bus diagnostics are the same for all versions
prior to the SUPI 3 OPC. In the SUPI 3 OPC chip, local bus diagnostics has been
improved. At present, the SUPI 3 OPC chip is used as the protocol chip in the
Inline and Loop 2 system. One of the special features of OPC local bus diagnostics
is the safe detection of errors, which occur for > 40 ms. As mentioned above, the
INTERBUS master cannot read SUPI 3 information if the INTERBUS device is
damaged during the troubleshooting algorithm. OPC local bus diagnostics can be
used to determine the error location in a known configuration.
The following example can be used to explain local bus diagnostics.
Error on the data forward path: In the event of an error on the data forward path,
the INTERBUS device after the error location becomes the local bus diagnostics
master (in Figure 3.29 the transmission path between INTERBUS device 1.1 and
INTERBUS device 1.2 is damaged. INTERBUS device 1.2 takes on the role of LBD
[local bus diagnostics] master), i.e., it sends an emergency telegram to the next
device, which is then incremented by every subsequent device. Since the return
path is not faulty, this emergency telegram can be sent to the next device. This
procedure continues until the telegram reaches the bus terminal module. The data
item is then transmitted to the INTERBUS master, which can display the error
location if the INTERBUS configuration is known. If the configuration is not known,
the data item is negated. In the example in Figure 3.29, the INTERBUS error
message for an unknown configuration is OUT2, 1.0, -8.
133
0.5 Hz 4.0 Hz 0.5 Hz 0.5 Hz 0.5 Hz
+1
+1
+1
+1
+1
+1
+1
+1
+1
1.1
1.2
1.3
1.4
1.5
Figure 3.29: Extended local bus diagnostics, error on the forward path
Note that the last local bus device is only counted once.
The bus terminal module also sends a data item to determine the local
bus configuration. This data item, 0x80, is incremented by the
INTERBUS devices in the connected local bus and, when it reaches the
bus terminal module again, provides information about the configuration.
In the event of an error, the error location can also be determined in this
way.
Extended OPC local bus diagnostics only works if it has been
implemented in the hardware. If the OPC chip is incorrectly connected in
the bus terminal module, this feature is not available. The DIAG40
documentation contains information about whether the bus terminal
module and its connected devices have local bus diagnostics. This
information is in Part 3/Section II of the DIAG40 explanation, see
accompanying CD-ROM "Diagnostics with DIAG40".
Error on the data return path: The damaged local bus device cannot pass on the
status telegram it receives from the previous INTERBUS device, because there is
an error on the return path (this explanation refers to Figure 3.30). INTERBUS
device 1.2 then closes its outgoing interface, while the outgoing interface is
considered not connected. If the INTERBUS master does not know the
configuration frame, INTERBUS changes to the RUN state, although INTERBUS
modules 1.3 1.5 cannot be operated. This should be taken into account when
reading the bus configuration or during test mode.
134
0.5 Hz 0.5 Hz 4.0 Hz 0.5 Hz 0.5 Hz
+1
+1
+1
+1
+1
1.1
1.2
+1
+1
+1
1.3
1.4
1.5
Figure 3.30: Extended local bus diagnostics, error on the return path
Test mode: Test mode enables automatic reading of the INTERBUS

configuration. On most controller boards, it can be activated via a DIP
switch.
Figure 3.31 illustrates the counting mode in an Inline local bus with Loop branch.
The diagnostic display indicates an OUT 2 error with local bus position 6. To
determine the error location, start at the bus terminal module and move 6 steps
against the direction of transmission. The error area is between the output of
device 3.5 and the input of module 3.6. This error must have occurred during the
startup process on an unknown INTERBUS configuration, otherwise the logical
device number would have been given.
135
4.0 Hz
+1
0.5 Hz 0.5 Hz 0.5 Hz 0.5 Hz
3.0
+1
+1
+1
+1
+1
+1
+1
+1
3.1
3.2
3.3
3.4
3.7
+1
Return
path
Foward
path
0.5 Hz
3.5
+1
0.5 Hz
3.6
Figure 3.31: Local bus diagnostics in an Inline local bus with Loop branch
3.5.1 Time Conditions for Error Localization

As only SUPI 3 devices can locate all errors without time conditions, the diagram
below illustrates the localization of errors in relation to the error duration. This
diagram only applies to devices prior to SUPI 3.
50% of CRC
errors can be
located
If the startup algorithm

is not complete, the
error cannot be clearly
located
The error can

be clearly
located
Special INTERBUS
master diagnostic
firmware startup
algorithm
Start of error
Bus timeout
Startup algorithm
complete
Error
duration
Figure 3.32: Time behavior for localization of errors using a < SUPI3 Version
136
Bus reductions are detected during the running bus timeout. The bus timeout can
be set by the user via a firmware command (can be set using CMD/PC WORX).
The default value is twenty times the bus cycle time, or a minimum of 200 ms.
If a transmission error affects the bus timeout, the error can only be located if it
remains in place until it is reached by the startup algorithm.
SUPI 3 systems can locate all errors, as they offer extended error detection and
save error information. All devices should have a SUPI 3 chip or newer.
In a SUPI 3 system, if the internal reset of a device lasts longer than the
startup routine, then diagnostic information cannot be read from this
device. This means it is not possible to determine a precise error cause.
However, the error location is detected safely.
3.5.2 Error Localization With Older SUPI Protocol Chips

Older slave chips up to and including SUPI 2 V3 have a CRC check on the data
forward path. This CRC check is used for error localization. The devices do not
require a CRC checker on the data return path to ensure data integrity, because
the information from the last device is clocked through to the controlled board. This
means that not all CRC errors can be assigned to a transmission path. Figure 3.33
and Figure 3.34 illustrate error diagnostics in a SUPI 2 system.
To aid understanding, the CRC generators or CRC checkers are included in the
diagram.
Note for Figure 3.33 and Figure 3.34: a Generation 3 INTERBUS master
with a dedicated SUPI 3 system would indicate the same error location,
because the SUPI 3 diagnostics cannot be activated by a G3 master.
137
CRC transmission error on data

return path between device 2.3
and device 2.2. The error is
registered at device 3.0 because
this is where the next CRC check
is made. The user knows that the
source of the error is in segment
2.0 or 3.0.
1.0
G
2.1
CG
2.2
G
2.3
G
2.0
3.0
C = CRC checker
G = CRC generator
The error is clocked

through from device to
device because there is no
CRC checker.
Figure 3.33: Error diagnostics in SUPI 2 systems on the data return path
1.0
CRC transmission error on data

foward path to device 2.0.
Segment 2.0 is indicated as the
error location because this is
where the next CRC check is
made.
C
G
2.1
CG
2.2
G
2.3
G
2.0
3.0
C = CRC checker
G = CRC generator
Figure 3.34 Error diagnostics in SUPI 2 systems on the data forward path
138
3.5.3 Error Localization With INTERBUS Devices Using SUPI 3

or Later
The SUPI 3 chip also has a CRC checker on the data return path. This means that
all errors can be clearly assigned to a device. In addition, the diagnostics in SUPI 3
systems can provide a more precise description of the error. The following
distinctions are possible:
-
Transmission error on data forward path
Transmission error on data return path
Line interrupt on data forward path
Line interrupt on data return path
RBST/LBST edge detection
Power-on reset
Reconfigure
Module error
Microprocessor watchdog, watchdog error on microprocessor applications
MAU warning on data forward path, warning for poor transmission quality on
fiber optic cables
MAU warning on data return path, warning for poor transmission quality on
fiber optic cables
DEV (X-1).0
Return path X.0

Foward path X.0
Transmission path
BK-T
BK-T
RBUS X.0
BDO 8/
3
DI 32/2
DEV X.0
Return path X.1
Foward path X.1
DEV X.1
DEV X.2
LBUS X.2
OUT2 X.0
OUT1 X.0
Figure 3.35: Device representation with forward and return paths
139
In error descriptions, reference is often made to forward or return paths. Figure

3.35 provides an overview of how to find these errors.
REMOTE IN
Figure 3.36 illustrates the fact that the device representation and the interpretation
of forward and return paths is different in the Loop system.
DEV X.1
Foward path
DEV X.2
Foward path
Foward path
REMOTE OUT
LOOP IN
DEV X.5
DEV X.4
Foward path
DEV X.3
DEV X.0
LOOP-BK
LOOP OUT
Return path
Foward path
Figure 3.36: Device representation with forward and return paths in the
INTERBUS Loop system
Every Loop device has a forward path, but only the last device has a return path.
If the return path from device X.5 to the bus terminal module is faulty,
no error is indicated on an unknown configuration. The Loop bus
terminal module cannot detect the Loop devices and assumes the Loop
branch is unconnected.
3.6 Diagnostics in SUPI 2, SUPI 3, and Combined

Systems
The diagnostic options are different for dedicated SUPI 2 and SUPI 3 systems. In
addition, a combined SUPI 2/SUPI 3 system behaves differently. The following
examples illustrate the diagnostic properties of the INTERBUS system using
different SUPI constellations.
140
Error detection options:
PHOENIX
CONTACT
1 11 111 1
B1 2 3 4 5 6 7 8 90 1 2 3 4 5 6
A
R
C
R
D
re
a
d
y
U
B(
1)
Foward path: CRC errors are detected by

the CRC checker.
Return path: No CRC error detection as
there is no CRC checker on the return path.
Foward path
Return path
SUPI 2
Device errors: Module error,

reconfiguration request
SUPI 2
PHOENIX
CONTACT
1 11 111 1
B1 2 3 4 5 6 7 8 90 1 2 3 4 5 6
A
R
C
R
D
re
a
d
y
U
B(
1)
Figure 3.37: INTERBUS segment with SUPI 2 devices
*
Return path:
- CRC errors are detected safely by an additional
CRC checker on the return path.
- A distinction can be made between cable
interrupts and transmission errors.
Foward path
Return path
SUPI 3
Foward path:
- CRC errors are detected by the CRC checker.
Device errors: Module error,

reconfiguration request.
Microprocessor reset, Power ON reset.
SUPI 3
* Changes in the RBST/LBST signal (signals

for the outgoing remote or local bus) are
detected.
Figure 3.38: INTERBUS segment with SUPI 3 devices
141

Foward path:
- CRC errors are detected by the CRC checker
*
Foward path
Return path
SUPI 3
Device errors:
SUPI 2: Module error, reconfiguration request
SUPI 3: Module error, reconfiguration request,
microprocessor reset, Power On reset
SUPI 2
PHOENIX
CONTACT
1 11 11 11
B1 2 3 4 5 6 7 8 90 1 2 3 4 5 6
A
R
C
R
D
Return path:
- CRC errors are detected by an additional CRC
checker on the return path. These errors can be
clearly identified using appropriate diagnostic
software (e.g., DIAG+, DIAG40).
re
a
d
y
U
B(
1)

detected.
Figure 3.39: INTERBUS segment with SUPI 3/SUPI 2 devices

PHOENIX
CONTACT
111 11 11
B1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
A
R
C
R
D
Foward path:
- CRC errors are detected by the CRC checker
re
a
d
y
U
B(
1)
Return path:
- No CRC error detection as there is no CRC checker
on the return path.
Foward path
Return path
SUPI 2
Device errors:
SUPI 2: Module error, reconfiguration request
SUPI 3: Module error, reconfiguration request,
microprocessor reset, Power On reset
SUPI 3

detected.
Figure 3.40: INTERBUS segment with SUPI 2/SUPI 3 devices

The INTERBUS segments cannot be considered on their own. In a combined
system with SUPI 2 and SUPI 3 devices, the SUPI 2 devices affect the options for
localization for the entire system. The physical location of the SUPI 2 devices must
also be taken into account.
142
The diagnostics available in a combined system are often restricted to those of a

SUPI 2 system. However, it is possible to benefit from the advantages of a SUPI 3
system between two SUPI 3 devices.
There can be no simple description of diagnostics in a combined system because
there are too many different options for the INTERBUS structure.
Figure 3.41 provides an example of error diagnostics in a combined system.
1.0
C
SUPI 3
C G
2.1
CG
2.2
G
2.3
G
2.0
SUPI 2
3.0
C = CRC checker
G = CRC generator
4.0
C
G
Figure 3.41: Error localization in a combined INTERBUS system

A CRC error on the data return path between device 3.0 and device 4.0 is clocked
through to device 1.0 (device 1.0 has a SUPI 3 chip and a CRC checker on the
return path). The controller board should indicate a remote bus error in segment
2.0. However, this indication would be misleading, because the actual error
location could be in segment 2.0, 3.0 or 4.0. Consequently, this error is not
displayed. In the DIAG40 printout, the error is assigned to device 2.0 as a
transmission error. An experienced user can interpret the error description using
the position of the SUPI 2 and SUPI 3 devices and thus specify the error location
143
more precisely. The diagnostics provided in this INTERBUS combined system are
the same as SUPI 2 diagnostics.
3.7 Transmission Quality

The transmission quality is an important tool for evaluating the reliability of an
INTERBUS system and carrying out preventive maintenance. The INTERBUS
system sets a quality bit as soon as a specified error density is reached, see
section on standard registers. The quality bit is set if 20 out of 1,000,000 data
cycles are faulty. The quality bit is updated every 100,000 cycles, starting after
100,000 cycles.
The statistics can be read using the integrated diagnostic tools in CMD and PC
WORX. Figure 3.46 shows the statistics screen for this integrated diagnostic
software.
The following static INTERBUS data is required to determine the transmission
quality:
cycle_counter
id_cycle_counter
data_cycle_counter
cycle_error_counter
id_cycle_error_counter
data_cycle_error_counter
Cycle counter
(number of data and ID cycles)
ID cycle counter (number of ID cycles run)
Data cycle counter
(number of data cycles run)
Cycle error counter (faulty ID and data cycles)
ID error counter (number of faulty ID cycles)
Data error counter
(number of faulty data cycles)
A "Set_Value_Request" can be used to set the number of faulty data

cycles that are permitted in every 1,000,000 data cycles before the
quality bit is set.
Mailbox syntax
0x0750
0x0004
0x0001
0x2254
0x0000
0x0064
Set value request

Parameter count
Number of variables
Variable ID
Data item (32-bit value)
Data item, value is set to 100
Practical Tip
Request the quality bit in your application and display it using either a
visualization system or operator interface. A gradual error can be
removed when production is not in progress before it leads to a costly
system downtime. The quality bit is part of the diagnostic status register.
144
3.8 Evaluating INTERBUS Module Diagnostic LEDs

During the startup phase, the diagnostic options provided by LEDs on the
INTERBUS devices are an important tool for finding errors at an early stage, even
without diagnostic programs.
This section starts with a description of the generally valid diagnostic LEDs. As the
module diagnostics can vary from one module range to another, the special
features are described separately for each module range. Only products from
Phoenix Contact are used. However, the module diagnostics for other
manufacturers do not really differ from the diagnostics described here.
3.8.1 General Diagnostic LEDs
Figure 3.42: INLINE bus terminal with typical diagnostic LEDs

Table 3.3: General diagnostic LEDs
LED
Designation
UL
RC
LED
Color
Green
Green
Status
Meaning
ON
Supply voltage for the module electronics present
OFF
Supply voltage for the module electronics not

present.
Remote cable check successful.
This checks the connection between two devices.
The first device permanently sends a status telegram
to the second device (which is physically located
directly after the first device). Status telegrams are
only sent once device 1 has registered that another
device follows it (e.g., using the RBST jumper in the
ON
LED
Designation
LED
Color
145
Status
Meaning
outgoing remote bus cable).
OFF
BA
Green
ON
No remote check signal from the previous device.

If the RC LED is not active even though a cable is
connected, this is usually due to faulty cabling not an
RBST jumper.
If the INTERBUS master has activated the RESET
signal, this LED is not lit.
Bus active, INTERBUS in the RUN state.
OFF
Bus not active.
Red
Flashing
ON
LD
Red
OFF
ON
No error in the branching local bus.

Local bus disabled.
RD
Red
OFF
ON
Local bus not disabled.

Outgoing remote bus disabled.
OFF
Outgoing remote bus not disabled.
INTERBUS is in the ACTIVE state.

Error is present in the branching local bus.
The "E" diagnostic LED is only supported in INTERBUS Generation 3.

The LD and RD diagnostic LEDs cannot be used for troubleshooting.
However, in master firmware 4.60 or later, faulty INTERBUS paths can
be disconnected in isolation. The disabled INTERBUS segments then
indicate the error location. However, this must be configured.
Many users check the status of the RD and LD diagnostic LEDs after a
bus error to obtain information about the error location. However, this is
not advisable because the INTERBUS master startup routine switches
the interfaces according to the INTERBUS diagnostics. A red LD or RD
LED only means that the remote bus or local bus interface is closed.
Table 3.4: Diagnostic LEDs for ST modules

LED
Designation
CC
LED
Color
Green
Status
Meaning
ON
Cable check OK.

Incoming ST cable connection is checked. The
response is the same as the RC LED.
Us
Green
OFF
ON
Connection between the devices is faulty.

Supply voltage for the function group present.
Red
OFF
ON
Supply voltage for the function group not present.

Error in a function group. A function group can consist
of 4, 8, 16 or 32 I/O points.
OFF
No function group error.
146
LED
Designation
I/O status
indication
LED
Color
Yellow
Status
Meaning
ON
I/O point is active, signal present.
OFF
I/O point is not active, signal is FALSE.
Table 3.5: Diagnostic LEDs for INLINE modules

LED
Designation
D
LED
Color
Green
Status
ON
Meaning
INTERBUS
is
in
the
RUN
communications power is present.
state,
Flashing 0.5 Hz
INTERBUS is in the READY or ACTIVE state,

communications power is present.
Flashing 2 Hz
INTERBUS is in the RUN state, there is a

local bus error.
Flashing 4 Hz
No signal from the previous terminal.

The INTERBUS device after the terminal that
is flashing (4 Hz) is no longer in the
configuration frame.
Communications power is present.
OFF
Communications power is not present.
Table 3.6:Diagnostic LEDs for Loop modules

LED
Designation
USL
LED
Color
Green
Status
Meaning
ON
Supply voltage for INTERBUS Loop present.
OFF
Supply voltage for INTERBUS Loop not

present.
Actuator supply voltage present.
Us
Green
ON
DIAG
Green
OFF
ON
Actuator supply voltage not present.

Communications power UL is
INTERBUS active, no module error.
present,
Flashing 0.5 Hz Communications power present, INTERBUS

not active.
Flashing 2 Hz
Communications power UL present, module

error
(INTERBUS can be active or not active).
Flashing 4 Hz
Communications power UL present, local bus
error
OFF
Status indication
Yellow
ON
OFF
Communications power UL not present.

I/O point is active, signal present.
I/O point is not active, signal is FALSE.
147
Table 3.7: Diagnostic LEDs for Rugged Line modules

LED
Designation
IB DIAG
LED
Color
Green
Status
Meaning
ON
Supply voltage present, bus active, no module

error.
Flashing 0.5 Hz Supply voltage present, bus not active.
Flashing 2 Hz
Supply voltage present, module error

Table 3.8: Diagnostic LEDs for INLINE modules

LED
Designation
US
LED
Color
Green
UM
Green
Status
Meaning
ON
Segment voltage present.
OFF
ON
Segment voltage not present.

Main power present.
OFF
Main power not present.
RT modules, SAB modules, and CT modules: The LEDs for these modules are the
same as the general diagnostic LEDs.
3.8.2 Procedure for Troubleshooting Using Diagnostic LEDs

The procedure for troubleshooting is limited to the RC or CC signal and the
diagnostic LEDs for Inline, Rugged Line, and Loop. In the remote bus, only the RC
signal can be used as an indicator for the error location. If the RC signal is not
present, the previous device, the path or the device itself could be the source of the
error.
In the local bus, the diagnostic LEDs and the CC signal help with diagnostics.
Again, do not forget that a segment includes two devices and that either or both of
them may be faulty. The optical local bus diagnostics provided in the Inline system
should be used where possible because most errors can be described using the
various flashing rates.
The Us1 LED in the Rugged Line system is also very useful because it monitors
the module communications power and can even indicate to the host system if the
voltage is exceeded.
148
3.9 Evaluating the Controller Board LCD/Diagnostic

LEDs
Controller boards are available with and
without LCD diagnostic displays. The
controller board diagnostic LEDs also differ. A
precise description of the individual diagnostic
LEDs can be found in the specific data sheet
for the controller board. This section only
describes the most important LEDs, and
illustrates a selection of the most important
menus for controller boards with display. Only
menus, which contain relevant information for
error diagnostics are described.
Figure 3.43: Diagnostic information for controller boards with/without LCD
Diagnostic LEDs for Phoenix Contact controller boards

Table 3.9: Standard diagnostic LEDs for controller boards
LED
Designation
RDY/RUN
LED
Color
Green
BSA
Red
FAIL
Red
PF
Green
STOP
Red
SYSFAIL
Red
Status
Meaning
ON
Flashing
ON
OFF
ON
Bus active
Bus ready to operate
At least one bus segment is aborted.
No bus segment aborted.
Group error message for errors on the controller
board, parameterization errors or bus errors.
No error.
Module error
No module error
Control system in STOP state.
Control system not in STOP state.
Controller board SysFail signal active.
Controller board SysFail signal inactive.
OFF
ON
OFF
ON
OFF
ON
OFF
149
Diagnostic Display
The diagnostic display can be used to access important diagnostic and status
information for the INTERBUS master from various menus. A detailed description
of the operation of the diagnostic display can be found in the Phoenix Contact
Diagnostics Guide [25]. The INTERBUS user should be proficient in the operation
of the diagnostic display and know every menu item within the integrated functions.
The diagnostic display can also be accessed for controller boards, which
do not have a hardware display. The configuration tools CMD and PC
WORX provide a software display via the controller board context menu.
This display is operated in exactly the same way and offers all the same
functions as the hardware version.
Figure 3.44 provides an overview of the menu items that can be accessed using
the diagnostic display.
Menu (Mode)
MODE
CFG
DIAG
STAT
MONI
OPT
SCANTIME
ERRHIST
ID
MPM
DEBG
LEN
LEVL
OPTITIME
FW-V
HW-V
SER-No.
REC
PF
CRC
ADBG
QFLG
WFLG
SNGL
ACTV CFG
SAVE CFG
SWTC
BRDG
PF TEN
RSET
LCD TEST
BUS DEV
CRC TEN
* Only available in
test mode
Figure 3.44: Total overview of the menu items within the diagnostic display
The DIAG (diagnostics) and STAT (statistics) menus are described in this section,
because they are used frequently in the event of a bus error.
The DIAG menu provides diagnostic information about the current INTERBUS
status. For troubleshooting, it is possible to start up the bus successively (one
device at a time) using the "Debug" function.
MPM: In the event of an error, this contains very detailed error information for user
errors (USER), peripheral faults (PF), bus errors (BUS), and controller errors
(CTRL).
150
DEBG (Debug): Can be used to start the bus step by step. The INTERBUS master
must be in the READY state. This menu item is particularly useful in the event of an
error because devices can be started successively until the error location is
reached.
ADBG (Auto Debug): Offers the same functions as the DEBG menu item, but the
function is executed automatically. Once this menu item is selected, the system
tries to start up the bus. If the startup is successful, ID and data cycles are run after
1 second. In the event of an error, the error location is indicated on the display.
After 1 second, another attempt is made to operate the bus until the startup is
carried out successfully.
QFLG (Quality Flag): Status of the quality flag. Parameterization of the quality flag
(quality bit) is described in 3.7.
WFLG (Warning Flag): If no INTERBUS cycles are transmitted without errors within
a parameterizable time frame, the warning flag (bus warning time) is set. This bit
can be reset using the standard "Confirm diagnostics" function, see 3.2.6 or the
relevant firmware command. The warning flag is parameterized using CMD/PC
WORX or a "Set_Value" service. A precise description of the bus warning time can
be found in 1.8.
SNGL (Single Error): Displays all single errors that have occurred. A single error
does not shut down the bus. It provides information about the quality of the bus
system.
The statistics menu (STAT) provides statistical information about the bus status.
ERRHIST (Error Protocol): This contains an error protocol of the last ten errors.
The most recent error is stored as number 1.
REC (Reconfiguration): The number of reconfiguration requests for a bus terminal
module. Bus terminal modules can trigger a reconfiguration request to the
INTERBUS master. A CRC error is generated, which the INTERBUS master
recognizes as a reconfiguration request. This enables the user, for example, to
start up system parts that have been switched off.
PF (Peripheral Fault): Error counter for peripheral faults.
CRC (Transmission Error): Counter for all cyclic redundancy check errors.
PF TEN (Top Ten List of Peripheral Faults): List of the last ten devices with
peripheral faults. The most recent peripheral fault is number 1.
CRC-TEN (Top Ten List of CRC Errors): List of the ten devices with the most
transmission errors.
151
3.10 Diagnostic Programs

3.10.1 Integrated Diagnostics With CMD and PC WORX
The integrated diagnostics in IBS CMD and IBS PC WORX (Version 2.02 or
earlier) is identical. It can be used to read a range of diagnostic data, which is
sufficient for troubleshooting in most cases. Only persistent errors, which are
described in the complicated error descriptions section, can be diagnosed more
effectively using DIAG40.
Diagnostics can be accessed using the Diagnostics menu item (in PC WORX
Version 2.02 or earlier, this is possible in SYSTEM WORX).
Figure 3.45: Main diagnostic screen

The main diagnostic screen, Figure 3.45, can be used to make settings for the
diagnostic tool and cycle time, and create a diagnostic file, etc. The start screen
(Statistics Online) can be used to access the statistics part, which contains the
latest diagnostic data for the controller board. All transmission cycles, identification
cycles, and data cycles since the last controller board reset are displayed. An
interesting figure here is the number of faulty cycles. Using bus segment statistics
and device statistics, the user can gain an overview of assigned transmission
errors.
152
Figure 3.46: Statistics Online for CMD/PC WORX

During troubleshooting the statistics data should be evaluated consistently. If an
error only occurs sporadically, the user should try to investigate every transmission
error and device message. The relevant segments should be checked. This
diagnostic tool does not supply all the diagnostic information, which is provided by
the diagnostic firmware. For example, on a transmission error there is no indication
as to whether the error is on the forward or return path. However, for most error
descriptions (> 90%) the diagnostic data is sufficient because the INTERBUS
master can assign virtually all errors correctly within the INTERBUS diagnostics in
CMD/PC WORX. In a dedicated SUPI 3 system, special tools such as DIAG40 are
rarely required, but can still be used if necessary.
As well as this diagnostics option, process data information can be received via the
process data monitor and the MPM can be accessed via the address monitor. The
process data monitor is very helpful when checking the operation of individual
INTERBUS devices after installation before starting with programming. This is the
wiring test or I/O check. This tool can also be used to monitor whether individual bit
objects are set or to set individual bit objects. In the address monitor, the process
data objects at a specific MPM address can be viewed and described. The address
monitor is not just limited to one module like the process data monitor, but indicates
the contents of the selected MPM address.
153
The process data monitor is accessed via the context menu of the device, and the
address monitor is accessed via the context menu of the controller board.
Practical Tip
The standard function registers are often assigned to MPM addresses. This means
they can be viewed via the address monitor. Parameterized services can also be
viewed in the address monitor using the standard function registers, see 3.2.
In CMD/SYSTEM WORX, all firmware commands can be executed via an
integrated command interface. This means that firmware services can be tested
before use in a program. This dialog box can be accessed via the controller board
CMD menu or context menu. Figure 3.47 illustrates access via the CMD menu.
Figure 3.47: Accessing the Control dialog box via the CMD menu
The process data monitor does not read information from the MPM, but
reads from the input or output data memory of the controller board. The
bus data is copied from this memory to the MPM or transmitted to the
devices, see Figure 3.48.
154
Controller board
Output data memory
Input data memory
IPMS
I/O module 9
I/O module 1
I/O module 2
PHOENIX
C ONTAC T
1 2 3 4 5 6 7 8 9 1 0 1 112 1 3 14 1 5 16
INTERBUS
summation frame
BA
RC
RD
re a d y
UB(1 )
I/O module 8
PHOEN IX
C ON TA C T
DIO 8/8/3-2A
1 2 3 4 5 6 7 8 9 1 011 1 2 1 31 41 5 16
BA
RC
RD
re a dy
UB(1)
DO 16/3
AO 4/SF4
I/O module 7
I/O module 3
I/O module 4
I/O module 5
I/O module 6
Figure 3.48: Input or output data memory of the controller board

Summary: The standard integrated diagnostics option offers sufficient diagnostic
software for most errors, although it does not provide enough diagnostic
information for an expert user. As this tool is already supplied as standard with
CMD/PC WORX, it makes sense to use it. The process data monitor and address
monitor are helpful tools, which cannot be replaced by DIAG40.
3.10.2 Diagnostics Using DIAG+

The DIAG+ diagnostic tool illustrated in Figure
3.49 can be used independently of CMD/PC
WORX. This tool offers far more diagnostic
options than the standard integrated tools in
CMD/PC WORX. The often cryptic data in the
DIAG40 text file is provided in a clear form, so
that even a beginner can quickly learn about
INTERBUS system diagnostics. A special
Solution section provides suggestions for
concrete solutions to the current bus problem.
This database can be expanded by the user
after the error has been removed successfully,
enabling users to add their own experiences to
the database. Not all diagnostic information is
evaluated in this diagnostic tool, but this is only
important for an INTERBUS diagnostics expert.
User hierarchies can also be created so that
specific groups of people have full access to all
functions of the DIAG+ tool, because this tool
can be used to control INTERBUS.
Figure 3.49 DIAG+
155
During startup, this tool can be used to test installed buses. Commands such as
start the bus, acknowledge peripheral faults, switch devices on and off, and stop
the bus using an alarm stop are standard commands, which can be sent from the
application.
A special feature of DIAG+ is its ActiveX capability. This means that DIAG+ can be
integrated in every visualization or high-level language application.
Interested users who want to access the methods and properties of ActiveX
Control can enable this function by purchasing a programming interface (PI).
A small example of the methods and properties of ActiveX Control is

provided on the accompanying CD-ROM.
Summary: This diagnostic software is equally interesting for both beginners and
experts. The ActiveX interface provides user-friendly options for embedding in
user-specific programs/visualizations.
3.11 Diagnosing Complicated Error Descriptions

Complicated error descriptions occur when the INTERBUS diagnostics cannot
determine an error location. They are known as E-errors (E0 - E8). The source of
the error disappears before the startup routine for error localization can reach the
error location. The following are frequent causes of this error description:
Loose contact on the data line: Cold junction, connector not securely fixed, no
strain relief, etc.
Short-term voltage dips: EMI, inductive feedback, weak power supply unit, etc.
Faulty INTERBUS device: SUPI interference, faulty RS-485 driver, etc.
Incorrect SUPI implementation.
Procedure to remove the error:
The flowchart shown in Figure 3.50 should not be considered as a binding solution
for all bus errors. It is designed to provide the user with support when searching for
a solution. Of course, for some errors this flowchart is not necessary, but it should
be a useful guide for beginners. As users gain experience, they will no doubt find
their own ways of managing errors.
156
Static INTERBUS
error
Short-term
INTERBUS error
INTERBUS
diagnostics was
able to determine
error location ->
remove error.
Diagnostics
indicates error
location or E-error
Error
removed?
Error removed
Yes
No
Error
removed?
No
Yes
Error removed
E-error?
Error location is
indicated.
Remove error.
Yes
No
Reduce bus successively.

Restart bus and read
diagnostics after every
reduction.
Error location is identified
when no transmission
errors appear after a
device has been hidden.
Does error
only occur during
operation?
No
Reduce bus successively.

Restart bus and read diagnostics
after every reduction.
Error location is identified when
no transmission errors appear
after a device has been hidden.
Yes
Read diagnostics.
Check whether a
transmission error
was assigned.
This usually
corresponds to the
error location.
Was a
transmission error
assigned?
Yes
No
Check communications
power using oscilloscope.
Set trigger points for the
minnimum voltage
specified in the data
sheet.
Check all data lines.

Insert cable tester.
Check connector, cold
junctions, realign infared
transmission paths, etc.
Use DIAG40 again and

evaluate all notes.
No
Error
removed?
Yes
Error removed
Figure 3.50: Flowchart for troubleshooting
Check specified segment.

Remove error.
Restart bus.
157
3.12 Hardware Diagnostics

This section introduces hardware diagnostic systems and their application. This
hardware could be a complex device such as a protocol analyzer or a simple item
of hardware, e.g., a varistor.
3.12.1 Measuring the Voltage Supply

The simplest and also most important device for tracing bus errors is the
oscilloscope. An oscilloscope is the only practical option for checking the
communications power UL (internal voltage supply for SUPI, RS-485, etc.). The
voltage is often measured using a digital voltmeter. However, this is not advisable
because outlying voltages cannot be detected due to the mean-value generation
(effective value). It is these outlying voltages that often have an adverse effect on
the SUPI communications power.
During voltage measurement, the voltage range specified in the module data sheet
should always be taken into account. This value, including the ripple, must be
observed. The most common values for the communications power are 24 V (3.6
VPP).
Practical Tips
Tip: Determine the voltage values for each module range, because these values
can differ from one module range to another. The voltage values can be found in
the relevant data sheet.
Tip: First look at the waveform and then set trigger points, usually Umin values.
Once the trigger point is activated, the waveform can be recorded. This procedure
is particularly suitable for voltage problems that occur sporadically. A suitable
oscilloscope (100 MHz, minimum) is required. Umax values should also be taken
into account because the RS-485 drivers start to overdrive above a certain voltage
(30 V, approximately).
Tip: Some oscilloscopes offer long-term recording with Umin and Umax logging.
Recordings over a long period provide excellent information about voltage
problems. The time is often saved with the data, so that events occurring at a
particular point in time can be considered.
Tip: RC combinations, varistors, and other electronic components can be used to
compensate voltage peaks. This topic is covered in more detail in Section 2
"INTERBUS Configuration".
158
3.12.2 Checking Output Drivers for the RS-485 Interface

Faulty output drivers lead to single errors or may stop the bus system. The fault
often begins only gradually, but intensifies until the bus system can no longer be
started.
Figure 3.51 illustrates the most important data for measuring the output driver.
Oscilloscope images of intact and faulty output drivers complete this topic, and a
measuring circuit is also shown.
In practice, the RS-485 driver is rarely used to remove a system error. The faulty
device is usually visible in the diagnostics and is then completely replaced. If
enough time is available for troubleshooting or for later investigation, the RS-485
interface is checked.
Measurement:
The voltage is
measured between DO
and /DO, and between
DI and /DI.
/DO
/DI
DO
DI
1.0
/DO
/DI
DO
DI
2.0
Important:
The voltages should
be measured as close
to the RS-485 as
possible.
RS-485 driver
Colour coding the INTERBUS cables:
Scope setting:
DO yellow, /DO green, DI grey, /DI pink
Voltage
Time
: DC,2 V/DIV
: 2 s/DIV
Figure 3.51: Checking RS-485 drivers

The features of a faulty output driver include no voltage symmetry, insufficient
output voltage, and a poor signal without enough edge steepness. Figure 3.52
shows a faulty output driver in which the DO-/DO signal is subject to extreme
interference. Both oscilloscope images should provide an idea of the waveform.
159
The voltage measurement during INTERBUS operation must not fall below 1.5 V,
and a typical minimum value is 2 V. A voltage measurement if the module is not
integrated in INTERBUS will deviate from the oscilloscope images illustrated here.
For this measurement, note that the interface is measured without load, i.e., the
100 terminal resistance of the next module is not present. The measured values
are therefore higher than those described here. The waveform cannot be evaluated
because no automatic edge change is generated.
Figure 3.52: Oscilloscope images for RS-485 output driver (left: OK, right: NOK)
The measurements should be made using a battery-operated

oscilloscope (e.g., Fluke Scopemeter) because battery operation
provides better electrical isolation from the measured object.
A measuring circuit as shown in Figure 3.53 is recommended for RS-485 driver

measurements.
Measuring point 3
DO - Pin 1
DO - Pin 1
Measuring point 1
DI - Pin 2
DI - Pin 2
Measuring point 0
COM - Pin 3
Measuring point 6
COM - Pin 3
Measuring point 5
/DO - Pin 6
/DO - Pin 6
Measuring point 2
/DI - Pin 7
Figure 3.53: Measuring circuit for RS-485 driver
Measuring point 4
/DI - Pin 7
160
This circuit can be implemented as a compact module for service purposes, which
can be inserted between an existing INTERBUS cable during servicing.
The relevant signals are tapped off at the measuring points. INTERBUS remains in
the RUN state during the measurement process.
The most important measuring points for measuring the RS-485 output driver are
as follows:
Measuring point 1 (DI) measuring point 2 (/DI) or measuring point 3 (DO)
measuring point 6 (/DO): The data lines are measured. The following points should
be noted: symmetrical signals, no spikes, no peaks, no (over)swings above the
range of 3 V->+3 V.
Measuring point 5/6 - measuring point 0: Measurement to ground signal. The
following should be noted: half operating voltage (~2.5 V) is OK, only small peaks
in 1s range are permitted. If the voltage is greater than ~2.5 V, the probable
cause is a voltage shift (offset voltage) due to faulty driver blocks in the device. An
offset voltage is usually generated by an operation amplifier when summing the
single transistor errors, and moves in the range from 1/20000.
The COM cable is not the mass or ground, but the reference potential
for the OP amplifier.
3.12.3 Checking INTERBUS Cables

INTERBUS cables should not only be checked for a fault on the outer sheath or
incorrect connector pin assignment. A cable measuring device should be used,
which is set with the specific values for INTERBUS cables.
During startup, a test report should be created for the entire INTERBUS
cable. This ensures that wiring errors are detected immediately instead
of on system startup. This is also advisable for providing evidence in the
event of later problems.
A test report for checking INTERBUS copper cables is provided on the

Practical Tip
Pay particular attention to jumper 5 - 9 in the outgoing INTERBUS remote

bus connector of many remote bus cables. This is a common error, which
means that all subsequent devices cannot be detected.
161
3.12.4 Use of a Protocol Analyzer for Diagnostic Purposes

Sometimes the demands for better error monitoring options in bus systems are
very high. If possible, every bit in the INTERBUS system summation frame should
be monitored. One example would be to detect application errors without having to
debug the application program or to test slave protocol chips (SUPI chips).
Method of operation: A protocol analyzer basically consists of a piece of hardware
and the associated software. The hardware, also called a tracer module, is usually
positioned directly after the controller board so that the data can be assigned more
precisely, see Figure 3.54.
Recording device
Tracer module
BK-T
BDO 32/2
Figure 3.54: Use of an INTERBUS protocol analyzer

The relevant software prepares the data from the INTERBUS data flow. The tracer
module does not change the INTERBUS summation frame because it only
passively accesses the summation frame.
What data can be analyzed?
Basically all information, which is sent via the data line can be recorded. It is
possible to trigger individual data from a module or wait for a "long reset". The data
preparation largely depends on the software, and individual manufacturers may
have different aims when it comes to software functions. Some manufacturers
specialize in the long-term recording of process data information, which is detected
in a large ring memory and enables the data for an entire day to be recorded. In
the event of an error, the process data information can be read back. Other
manufacturers prefer to offer a tool, which provides all protocol analysis options but
is not suitable for long-term recording.
The choice of tool depends primarily on the application. The following table lists
two suppliers of protocol analysis devices.
162
Supplier
Phoenix Contact GmbH & Co. KG
Name of Tool
IBS Analyzer
Address
Flachsmarktstrae 8
32825 Blomberg
ProDatas Gesellschaft zur

Prozessdatenanalyse mbH
Primas
Otto-Lilienthal-Str. 36
71034 Bblingen, Germany
LP Elektronik GmbH
Ramses
Ettishoferstr. 8
88250 Weingarten, Germany
3.12.5 Questions for the "Diagnostics" Section

1. What is the reset behavior for two-wire transmission?
2.
How can all INTERBUS devices enter the reset state on a long reset?
3. What is shown in the diagnostic display for the following error (indicated by a
lightning strike in Figure 3.55)?
0.5 Hz
+1
3.5
Foward
path
0.5 Hz
0.5 Hz 4.0 Hz 0.5 Hz 0.5 Hz
Return path
3.0
3.7
0.5 Hz
3.6
+1
+1
0.5 Hz 0.5 Hz
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
3.1
3.2
3.3
3.4
3.8
+1
3.9
Figure 3.55: Test for troubleshooting

4. How can a SUPI 2 device be identified in the DIAG40 printout?
5. Which error has occurred if the RC LED is not active on a remote bus device?
6. What is an E-error, and what are the possible causes of E-errors?
7. What is the purpose of jumper 5 - 9 in an outgoing remote bus cable?
8. What is the status of the diagnostic LEDs during slave device startup?
The answers to the questions for the "Diagnostics" Section can be

found on the accompanying CD-ROM.
INTERBUS Programming
163
4 INTERBUS Programming
The programming of an INTERBUS system covers a wide field with a lot of details,
as there are a number of host systems with different programming languages. This
is why this section covers the basics of the three areas PC, IEC 61131 (PC
WORX), and conventional PLC (S7), which provides a comprehensive introduction
to the relevant host system. Programming examples and detailed listings for the
different topics can be found on the accompanying CD-ROM, which can be used
directly as a template for your own automation solutions.
PC programming is deliberately described at the start of this section, as some of
the aspects discussed here are also important for PC WORX controller boards.
The drivers for the host system, which communicate with the controller board, are
identical, i.e., all programming interfaces, driver models, practical tips, etc. also
apply here.
-
Programming interfaces and operating systems
INTERBUS PC driver and INTERBUS Ethernet driver concept from Phoenix

Contact
High-Level Language Interface (HLI) and Device Driver Interface (DDI)
INTERBUS controller board programming via the DDI and HLI
Driver development with the Device Driver Development Kit (DDK)
ProConOS
Keywords for variable declaration in PC WORX
Instantiation
Programming languages in PC WORX
Mapping the physical hardware in PC WORX
S7 300 DSC-T and S7 400 DSC/I-T hardware connection
INTERBUS PC Driver Concept

Remote Procedure Call Process
Accessing a PC Controller Board via the DDI
Accessing a PC Controller Board via the HLI
Keywords for Variable Declaration in PC WORX
Data Types in PC WORX
IBS S7 300 DSC-T Data Areas Within the S7
S7 400 Operating Modes
Page 169
Page 172
Page 178
Page 181
Page 194
Page 204
Page 212
Page 218
164
4.1 Flowcharts for INTERBUS Programming

The following flowcharts cover the topics of "INTERBUS startup with cyclic
program part and program end", "PCP with INTERBUS", and "INTERBUS
diagnostics". They illustrate the conventional method of operation when
programming these topics. The flowcharts can be applied to all INTERBUS
systems. With PC WORX and PLC controller boards, not every detail is visible to
the user because the configuration tools complete the work for the user. The highlevel language user obtains the clearest view of the process if no configuration
tools are used.
Diagnost ic start
Diagnost ic status regist er

Status register
<> 0x00E0
Yes
Yes
If the detect bit has been set,

no firmware or PCP
command can be execut ed.
Detect bit set
No
Evaluation of
diagnostic stat us
register
No
Evaluation of
diagnostic
parameter register
Bus quality
poor
Yes
Program-internal
error response
Screen error output
Program-internal
error response
Screen error output
No
Diagnostic block
end
Figure 4.1: INTERBUS diagnostics flowchart
Close all nodes of DDI
Only open essential

nodes
165
Close Nodes ()
Open nodes
OK?
No
Yes
Software reset
Nodes remain open.
MPM reset.
Reset controller
board - 0956hex
- Warm start -
Logic addressing of
controller board or
physical reading
Load
configuration
No
Error evaluation:
Configuring syntax
incorrect
No
Error evaluation:
Configuration
incorrect
No
Error evaluation:
Yes
The controller board
checks the connected
configuration.
For physical reading purposes,
this step is not essential since
service 0710hex includes it.
Activate
configuration
711hex
Screen output of
error source
Terminator:
program stopped
Yes
Bus start: the controller
board activates the cyclic
data traffic.
Status: RUN
Start
data transfer
701hex
Yes
Protection against
exhaustive running of
program by starting the
watchdog
Evaluate PCP
telegrams
Evaluate firmware
telegrams
Activate program
watchdog
Cyclic
Trigger program
watchdog
Evaluate SysFail
Register
PCP cycle
PCP FUNCTION
Transfer
information
Read indication
and confirmation
Evaluate IN
messages
Transfer
information
In the event of an
error: screen output
Figure 4.2: Flowchart for INTERBUS startup, cyclic program, and program end
part 1
166
Read INTERBUS
input data
Read process data
Evaluation of
INTERBUS status
Diagnostic
evaluation
Customer-specific
program start
Start application
program
Customer-specific
program end
End application
program
Write INTERBUS
output data
Output process
data
Controlled exit
from cyclic
program
Request abort
condition in
program
Shut down PCP

communication
PCP shut down
This service triggers a

reset. The data traffic is
stopped. Process data
outputs are set to ZERO.
Status: READY
Alarm stop req.

1303hex
Close all open nodes
Close nodes ()
End
DIAGNOSTIC
FUNCTION
Start cyclic
shutdown program
Terminator
Figure 4.3: Flowchart for INTERBUS startup, cyclic program, and program end
part 2
167
Invite request for

all CRs
Waiting time
approximately
15 ms
Send PCP service
Timeout?
Yes
Internal processing
of program
Terminator
No
Abort?
Yes
Increment counter_2
No
Negative
PCP service
Yes
Error evaluation
- Error code/error class
- Transmit/receive buffer
Counter_2= 3?
No
Activate next PCP

service
No
Activate initiate req.

on the CR
Yes
1. End PCP program
2. External error output
3. Execute INTERBUS
diagnostics
Increment counter_1
Terminator
Counter_1 = 3?
Yes
No
1. End PCP program

2. External error output
3. Execute INTERBUS
diagnostics
Activate next
PCP service
Terminator
Figure 4.4: Flowchart for PCP communicationProgramming an INTERBUS Master

in High-Level Language
4.1.1 INTERBUS PC Controller Boards

Due to global rationalization measures and the savings that can be made, the
industrial PC has become established as a control system throughout the world.
The resulting advantages include the use of globally accepted, flexibly expandable,
modular, and industrially hardened PC hardware and software. This means that
these systems can be connected to other communication levels using Ethernet
TCP/IP with little effort or expense. For this area of application, Phoenix Contact
168
offers a wide range of PC INTERBUS controllers, some of which can also be

programmed via Ethernet.
4.1.1.1
Available INTERBUS PC Controller Boards
Table 4.1 lists the INTERBUS controller boards for PC systems available from
Phoenix Contact and provides details of supported operating systems and drivers.
Table 4.1: Overview of PC controller boards from Phoenix Contact
INTERBUS PC
Controller Board
IBS ...
PC ISA SC/I-T
PC 104 SC-T
ISA SC/RI/RT/LK
ISA SC/RI/RT/I-T
ISA SC/486DX/I-T
ISA RI/I-T
PCI SC/I-T
PCI SC/RI-LK
PCI SC/RI/I-T
PCCARD SC/I-T
Directory
Containing
Device Driver
Name of
Device Driver
Interface
(DDI)
Directory
Containing
Device Driver
Interface
Supported
Operating
Systems
Name of
Device Driver
(DD)
MS-DOS 6
Win 3.X
Win 95/98
Win NT4.0
Win 2000
MS-DOS 6
Win NT4.0
Win 2000
MS-DOS 6
Win NT4.0
Win 2000
Win NT4.0
Win 2000
ibsisa.exe
ibsisasc.dll
vibsscd.vxd
ibsisasc.sys
ibsisasc.sys
ibsisa.exe
ibsisasc.sys
ibsisasc.sys
ibdpmdrv.exe
ibdpmdrv.sys
ibdpmdrv.sys
ibpcimpm.sys
ibpcimpm.sys
win/system
win/system32/driver
winnt/system32/driver
lddi_tsr.lib
ibddiwin.dll
ibddiw95.dll
ibddiwnt.dll
ibddiwnt.dll
lddi_tsr.lib
idddiwnt.dll
idddiwnt.dll
dpmdrvtl.lib
idddiwnt.dll
idddiwnt.dll
idddiwnt.dll
idddiwnt.dll
win/system
winnt/system32
winnt/system32
winnt/system32
winnt/system32
winnt/system32
winnt/system32
winnt/system32
winnt/system32
winnt/system32
Win NT4.0
ibpccard.sys
idddiwnt.dll
winnt/system32
The latest drivers for Phoenix Contact controller boards can be

found in the InfoService on the Internet at www.phoenixcontact.com.
4.1.1.2
Programming Interfaces and Operating Systems
Depending on the operating system used, PC controller boards can be

programmed using C, C++, Delphi, Pascal or Visual Basic programming
language. Table 4.2 and Table 4.3 list the available programming interfaces
for INTERBUS PC controller boards IBS PC ISA SC/I-T and IBS PCI SC/I-T,
depending on the operating systems used. Programming interfaces for all
listed operating systems are available in C and C++ programming languages for
the IBS PC ISA SC/I-T.
Table 4.2: DDI programming interfaces for IBS PC ISA SC/I-T
Programming Language
MS-DOS
Win95/98
Win NT 4.0
Win 2000
C, C++
Delphi
Pascal
Visual Basic
X
X
-
X
X
X
X
X
X
X
X
X
X
X
169
Table 4.3: DDI programming interfaces for IBS PCI SC/I-T

C, C++
Delphi
Pascal
Visual Basic
4.1.1.3
Win NT 4.0
X
X
X
X
Win 2000
X
X
X
X
INTERBUS PC Driver Concept From Phoenix Contact
The control application accesses an INTERBUS PC controller board via the MultiPort Memory (MPM) or in the case of slave interface boards via the Dual-Port
Memory (DPM). Both the MPM and DPM are memory blocks on the PC controller
board. As the term Multi-Port Memory already indicates, it is possible for several
applications (MPM accessors) to access the MPM and exchange data. MPM
accessors are control applications on the PC, the INTERBUS master controller
board, and the INTERBUS coprocessor. Figure 4.5 shows a simplified access
route of the MPM.
PC host, with an
INTERBUS application
INTERBUS PC
controller board
INTERBUS PC
copressor
Read/write access on
both sides
MPM
Figure 4.5: Accessing the INTERBUS PC controller board via the MPM
The DPM differs from the MPM in terms of the maximum number of applications
(nodes) that can access it, the size of the DPM memory, and the driver, which
supports fewer boards in the PC. Table 4.4 compares INTERBUS PC controller
boards from Phoenix Contact with an MPM or DPM memory.
Table 4.4: Differences between MPM and DPM for PC controller boards
PC Controller Boards
Driver Supports Maximum
Driver Type
From Phoenix Contact
x Boards in the PC
IBS PC ISA SC/I-T
IBS PC 104 SC-T
IBS ISA SC/RI/RT/LK
MPM
8
IBS ISA SC/RI/RT/I-T
IBS ISA SC/486DX/I-T
IBS PCI SC/I-T
IBS PCI SC/RI-LK
MPM
8
IBS PCI SC/RI/I-T
IBS ISA RI/I-T
DPM
4
IBS PCCARD SC/I-T
DPM
1
170
Additional detailed information on the MPM can be found in 1.7

"Multi-Port Memory".
All data and information is exchanged between the individual MPM accessors,
such as the host PC and the INTERBUS controller board via the MPM. Figure 4.6
shows the access paths between a control program and a controller board via the
Device Driver Interface (DDI), the Device Driver (DD), and the Multi-Port Memory
(MPM).
Host PC
INTERBUS
controller board
Control program
INTERBUS
MASTER
Device Driver Interface
Device Driver
MPM
Figure 4.6: Accessing the PC controller board via the DDI, DD, and MPM
Additional information on the software interfaces for INTERBUS PC

controller boards can be found in the "Driver Reference Manual for
PC Controller Boards", IBS PC SC SWD UM E.
4.1.2 INTERBUS Ethernet Controller Boards

4.1.2.1
Available INTERBUS Ethernet Controller Boards
Table 4.5 lists the controller boards for Ethernet systems available from Phoenix
Contact and provides details of supported operating systems and drivers.
Table 4.5: Overview of Ethernet controller boards from Phoenix Contact
INTERBUS
Ethernet Controller
Board
IBS ETH DSC/I-T

FL IBS SC/I-T
Supported
Operating
Systems
Win NT4.0 wsock32.dll

Win 2000 wsock32.dll
Sun
Solaris
Directory
Containing
Socket
Name of
Socket
bsdsocket
winnt/system32
winnt/system32
-
Name of
Device
Driver
Interface
(DDI)
ibddiwnt.dll
ibddiwnt.dll
ibseth.lib,
eth.a
Directory
Containing
Device Driver
Interface
winnt/system32
winnt/system32
-
The latest drivers for Phoenix Contact Ethernet controller boards can
be
found
in
the
InfoService
on
the
Internet
at
www.phoenixcontact.com.
4.1.2.2
171
Depending on the operating system used, Ethernet controller boards can be

programmed using C, C++, Delphi or Visual Basic programming language. Table
4.6 and Table 4.7 list the available programming interfaces for Ethernet controller
boards IBS ETH DSC/I-T and FL IBS SC/I-T, depending on the operating systems
used.
Table 4.6: DDI programming interfaces for IBS ETH DSC/I-T
Programming
Language
Win NT 4.0
Win 2000
Linux
SUN Solaris
2.4
Other Unix Systems
C, C++
Delphi
Visual Basic
X
X
X
X
X
X
X
-
X
-
Table 4.7: DDI programming interfaces for FL IBS SC/I-T

Programming
Language
C, C++
Delphi
Visual Basic
4.1.2.3
Win NT 4.0
Win 2000
Linux
X
-
X
-
X
-
SUN Solaris
2.4
X
-
Other Unix Systems

1
1
INTERBUS Ethernet Driver Concept From Phoenix Contact
A control application communicates with an Ethernet controller board via the MultiPort Memory (MPM) in the same way as a normal PC controller board does. The
Device Driver Interface (DDI) for the Ethernet controller board operates as a
remote procedure call and does not use the standard libraries due to time
constraints. A remote procedure call means that the relevant function is not
executed on the host PC of the user, but on the INTERBUS Ethernet controller
board. The user does not notice anything different about this working method
except that it is faster. Figure 4.7 shows the access structure for INTERBUS
Ethernet controller boards.
The software interface kit IBS ETH DDI SWD E is used to adapt the Device Driver
Interface (DDI) to other UNIX operating systems.
172
Host PC
INTERBUS
MASTER
Control program
INTERBUS
Ethernet
controller board
P HOE NI
X
CONTAC
Firmware
ULT
100
CO
L
XM
MPM
T
RC
V
UL
RDY/
RUN
BSA
FAI
L
PF
INTERBUS
REMOTE
10/
100
FLIBSSC/I-T
Ord.No.:28 3 10 60
Socket
TCP/IP
Socket
Ethernet
TCP/IP
Figure 4.7: Accessing the INTERBUS Ethernet controller board via TCP/IP
4.1.2.4
Remote Procedure Call Process
When a function is called, all the transfer parameters for the DDI function and an ID
for the function to be executed are copied into a network telegram in the control
program of the host PC and sent to the Ethernet controller board via the Ethernet
network (TCP/IP). The controller board decodes the received telegram, accepts the
parameters for the function, and calls the function using these parameters. While
the function is being executed by the Ethernet controller board, the control program
on the host PC is blocked until a response arrives from the Ethernet controller
board.
Once the function has been executed on the Ethernet controller board, the read
data and the return value for the function are copied into a telegram in the control
program and sent back to the Ethernet controller board. The controller board
decodes the telegram and makes the return values for the function available in the
program.
4.1.3 High-Level Language Interface (HLI) and Device Driver

Interface (DDI)
The DDI is the programming interface of the application program and must be
available for the compiler being used (e.g., MS Visual C++, Borland C++, etc.).
Figure 4.6 and Figure 4.7 and also Table 4.2, Table 4.3, Table 4.6 and Table 4.7
show the available programming interfaces for the INTERBUS controller boards
listed below. The Device Driver or Socket Interface establishes the connection
between the host PC and the MPM via TCP/IP and is dependent on the operating
system. Table 4.1 and Table 4.5 give an overview of the Device Driver for all
INTERBUS controller boards from Phoenix Contact.
The HLI is a simplified programming interface for developing control applications
on INTERBUS controller boards from Phoenix Contact. It is based on the existing
Device Driver Interface (DDI) and is available for MS-DOS and Microsoft
Windows 95/98, NT 4, and 2000. The HLI acts as an intelligent application
interface for the provision of INTERBUS functions, converting function calls made
by the application into complex communication procedures with the controller
173
board. It is passive in terms of the application , i.e., its functions are only controlled
by the relevant application calls. Table 4.8 lists INTERBUS controller boards from
Phoenix Contact, which have a HLI programming interface and can be addressed
by C, C++ and Delphi compilers or MS Visual Basic.
Table 4.8: INTERBUS controller boards with HLI programming interface
Controller Boards
IBS PC ISA SC/I-T
IBS PCI SC/I-T
IBS PC 104 SC-T
IBS PCCARD SC/I-T
IBS ETH DSC/I-T
IBS ISA SC/486DX/I-T
(program running on the
coprocessor)
MS-DOS
Windows 95/98
Windows NT 4.0/2000
g4hlidos.lib
g4hliw16.dll
g4hliw32.dll
g4hliw32.dll
g4hlicop.lib
Figure 4.8 shows the driver structure when using HLI software.
Host PC
INTERBUS
controller board
Control program
High-level language interface
INTERBUS
MASTER
Device Driver
MPM
Figure 4.8: Accessing the PC controller board via the HLI, DDI, DD, and MPM
IBS CMD G4 software with integrated HLI export filter can be used to simplify HLI
programming through intelligent source code generation. The code generated in
IBS CMD G4 is inserted in an existing high-level language program and contains
INTERBUS initialization and startup. Other advantages of using HLI include:
-
Simple software interfaces for fast programming

Easy access to INTERBUS functions
Automatic PCP communication establishment
Direct assignment of process data objects to variables
Integrated error and event window
Using the High-Level Language Interface (HLI) and the HLI export
filter from IBS CMD G4, an INTERBUS system can be started up
in five minutes with an application program written by the user.
Additional information on the software interfaces for INTERBUS
controller boards from Phoenix Contact can be found in the "Driver
Reference Manual for PC Controller Boards" IBS PC SC SWD UM
174
E and in the "User Interface Version 2.x for High-Level Language
Programming" User Manual, IBS PC SC HLI UM E.
Figures Figure 4.9 to Figure 4.11 show the access paths for 16-bit and 32-bit
applications on INTERBUS controller boards from Phoenix Contact under
Windows 3.1/95/98 and Windows NT 4.0/2000.
IBS PCI SC/I-T
32-bit applications under Windows NT4.0/2000

32 bit HLI application
HLI:
g4hliw32.dll
c:\winnt\system32
32 bit DDI application
DDI:
ibddiwnt.dll
c:\winnt\system32
DD:
ibpcimpm.sys
c:\winnt\system32\
drivers

32 bit HLI application
32 bit DDI application
HLI:
g4hliw16.dll
c:\winnt\system32
ibddiwnt.ini
c:\winnt
16/32-Bit
DDI:
thkwnt.dll
ibddiwin.dll
c:\winnt\system32 c:\winnt\system32
Figure 4.9: Accessing the IBS PCI SC/I-T under Windows NT4.0/2000
175
Label1
32-bit HLI application
HLI:
g4hliw32.dll
c:\windows\system(32)
32-bit DDI application
DDI:
ibddiw95.dll
c:\windws\system(32)
DD:
vibsscd.vxd
c:\windows\system(32)\drivers
Parameters from the registry!
16-Bit-Anwendungen unter Windows 3.1/95/98

HLI:
g4hliw16.dll
c:\windows\system
DDI:
Parameters from
DD:
ibddiwin.dll
ibsisasc.dll
ibddiwnt.ini
c:\windows\system c:\windows\system
c:\windows

E.g., CMD, < PC WORX 2.x
IBS PC ISC SC/I-T

HLI:
g4hliw32.dll
c:\winnt\system32
DDI:
ibddiwnt.dll
c:\winnt\system32
DD:
ibsisasc.sys
c:\winnt\system32\drivers
Parameter aus der Registery!

HLI:
g4hliw16.dll
c:\winnt\system32
ibddiwnt.ini
c:\winnt
DDI:
16/32-Bit:
thkwnt.dll
ibddiwin.dll
Figure 4.10: Accessing the IBS PCI SC/I-T under Windows

3.1/95/98/NT4.0/2000
HLI:
g4hliw16.dll
c:\winnt\system32
16/32-Bit:
thkwnt.dll
c:\winnt\system32
PHOENIX
CONTACT
FL IBS SC/I-T
UL
R DY/RU N
BSA
FAIL
PF
100
IBS ETH DSC/I-T
COL
INTER BUS
R EMOTE
XMT
RC V
UL
10/100
F LIBSSC/I-T
Ord .-No.:2831 060

HLI:
g4hliw32.dll
c:\winnt\system32
DDI:
ibddiwnt.dll
c:\winnt\system32
Ethernet
DDI:
TCP/IP socket:
ibseth.dll
wsock32.dll
Figure 4.11: Accessing the FL IBS SC/I-T and IBS ETH DSC/I-T under Windows
NT4.0/2000
176
4.1.4 Startup Checklists for INTERBUS Controller Boards

In general, the minimum PC hardware and software requirements for high-level
language-programmable INTERBUS controller boards from Phoenix Contact are
easily met. Every item of PC hardware and software purchased in the last five
years meets the prerequisites for the operation of an INTERBUS controller board.
What is important when using a controller board is the existence of available
system resources such as interrupts (IRQ), I/O, and MPM addresses. Table 4.9 to
Table 4.11 provide startup checklists for the most popular INTERBUS PC and
Ethernet controller boards from Phoenix Contact.
Table 4.9: Startup checklist for all IBS PC ISA boards
Have available system resources for the IBS PC ISA controller board been identified?
In Windows 2000, the resource assignments for IRQ, I/O, and MPM addresses are under Start |
Settings | Control Panel | Management | Computer Management | System | System Information
In Windows NT 4.0, the resource assignments for IRQ, I/O, and MPM addresses are under
Start | Programs | Management | Windows NT Diagnostics | Resources
In Windows 95/98, the resource assignments for IRQ, I/O, and MPM addresses are under
Start | Settings | Control Panel | System | Device Manager | Computer | Properties
Is the IBS PC ISA controller board installed in a free ISA slot on the PC?
When installing the controller board, check for any existing BIOS settings, in which ISA slots are inhibited
or linked with a specific IRQ. The BIOS directory can usually be accessed during PC startup by pressing
the DEL key.
Set the free I/O address on the IBS PC ISA board using the DIP switch.
Has the latest driver software (DD, DDI, and HLI if selected) been installed successfully?
The latest drivers can be downloaded from the InfoService at www.phoenixcontact.com
During setup, ensure that the system resources that were identified as available are used
Does the driver start successfully after a PC restart?
In Windows 2000, you can check for successful driver startup under:
Start | Settings | Control Panel | Management | Computer Management | Device Manager
Select Display Hidden Devices using the right mouse-button to access the
Non-PnP Drivers folder, which contains the IBSISASC INTERBUS driver. If the IBSISASC driver cannot
be started up successfully, this is probably because hardware resources (IRQ, I/O, and MPM address) have
not been selected correctly. You can adjust these resources in the registry editor under:
H_Key_Local_Machine/System/CurrentControlSet/Services/IBSISASC/Parameter/
Once you have modified the resource parameters, you do not have to restart the PC and can continue
immediately in the device control with a driver restart.
In Windows NT 4.0, you can check for successful driver startup under:
Start | Settings | Control Panel | Devices | IBSISASC Then proceed as for Windows 2000.
In Windows 95/98, you can only determine whether the INTERBUS driver has been started successfully
by attempting to establish a communication link (described in the next point).
Is it possible to establish a communication link to the IBS PC ISA board?
The following programs can be used to quickly and easily determine whether communication can be
established with the IBS PCI. In IBS CMD G4 and PC WORX, select the relevant controller board,
press F3, and select the Online option
IBS CMD G4
PC WORX
HLICHK16.EXE when using the HLI interface
It is also possible to establish a communication link via a serial cable from the serial PC COM interface to
the IBS PC ISA controller board.
The IBS PC ISA controller board is now ready for operation
IBS CMD G4 and PC WORX are available as monitor programs
Why can't the system establish a communication link?
Resource assignment for IRQ, I/O, and MPM address not freely available, use Microsoft System
diagnostics
Entries in the registry editor for this IBS PC ISA controller board do not correspond (InUse, etc.)
Device Driver, Device Driver Interface, and High-Level Language Interface are not correct
In Windows 3.x/95/98, the FIFO buffer is still activated
To identify other possible reasons, search the event log in Windows NT 4.0/2000 for relevant entries
IBS PC ISA driver software does not correspond to the IBS PC ISA controller board (firmware?)
IBS PC ISA board faulty
PC ISA slot faulty or inhibited by the BIOS
Host PC faulty
177
Table 4.10: Startup checklist for all IBS PCI boards

1
Is the IBS PCI controller board installed in a free PCI slot on the PC?
When installing the controller board, check for any existing BIOS settings, in which PCI slots are inhibited
or linked with a specific IRQ. The BIOS directory can usually be accessed during PC startup by pressing
the DEL key.
Set the board number on the IBS PCI board using the DIP switch. The first IBS PCI board should be set to
board number 0.
Does the driver start successfully after a PC restart?
In Windows 2000, you can check for successful driver startup under:
Start | Settings | Control Panel | Management | Computer Management | Device Manager
In the folder, the INTERBUS driver PCI MPM INTERBUS Controller appears under
INTERBUS Class Driver. Double click on the driver to access a Windows window, which describes the
status of the driver. If the driver cannot be started up successfully, this is probably because the settings
such as the board number have not been selected correctly. You can adjust these resources in the registry
editor under: H_Key_Local_Machine/System/CurrentControlSet/Services/IBSPCIMPM/Parameter/
Once you have modified the resource parameters, you do not have to restart the PC and can continue
immediately in the device control with a driver restart.
In Windows NT 4.0, you can check for successful driver startup under:
Start | Settings | Control Panel | Devices | IBSPCIMPM Then proceed as for Windows 2000.
Is it possible to establish a communication link to the IBS PCI board?
established with the IBS PCI. In IBS CMD G4, select the relevant controller board, press F3, and select the
Online option
IBS CMD G4
the IBS PCI controller board.
The IBS PCI controller board is now ready for operation
IBS CMD G4 is available as a monitor program
The selected IBS PCI board number on the board or in the registry editor is not correct
Entries in the registry editor for this IBS PCI controller board do not correspond (InUse, etc.)
Device Driver, Device Driver Interface and High-Level Language Interface are not correct
IBS PCI driver software does not correspond to the IBS PCI controller board (firmware?)
When using IBS CMD G4, the appropriate host adaptation for the IBS PCI board is not available. The
appropriate host adaptation is available in the InfoService on the Internet at www.phoenixcontact.com
IBS PCI board faulty
PCI slot faulty or inhibited by the BIOS
Host PC faulty
Table 4.11: Startup checklist for Ethernet controller boards
Are the INTERBUS Ethernet controller board and host PC linked in Ethernet?
Assign the INTERBUS Ethernet controller board a free IP address and an appropriate subnet
mask address. For Factory Line components such as the FL IBS SC/I-T, you can use the Factory
Manager provided on the accompanying CD-ROM.
Use the LINK LED on the INTERBUS Ethernet controller board. This indicates the correct
configuration of the Ethernet cable.
Use the "ping" command to check whether the Ethernet controller board and the host PC
exist at network hardware level.
For more detailed network diagnostics, refer to Section 8 Ethernet and INTERBUS Procedure.
During driver installation, entries are made in the registry. Refer to
H_Key_Local_Machine/SOFTWARE/PhoenixContact/IBSETH/Parameters to determine parameters such
as IP address, communication string, InUse, timeout, etc.
Is it possible to establish a communication link to the INTERBUS Ethernet controller board?
established with the INTERBUS Ethernet controller board. In IBS CMD G4, select the relevant
controller board, press F3, and select the Online option
IBS CMD G4
ETHERNET MONITOR on the accompanying CD-ROM
178
the INTERBUS Ethernet controller board.
The INTERBUS Ethernet controller board is now ready for operation
IBS CMD G4, ETHERNET MONITOR, and the Factory Manager are available as monitor programs
IP and subnet mask address not freely available or do not correspond
Entries in the registry editor for this Ethernet controller board do not correspond (InUse, etc.)
Device Driver, Device Driver Interface, and High-Level Language Interface are not correct
Driver software does not correspond to firmware for INTERBUS Ethernet controller board (firmware?)
INTERBUS Ethernet controller board faulty
Host PC faulty
Communication problems due to Ethernet overload
4.1.5 Programming via the DDI

The following DDI functions are available for creating user-specific INTERBUS
applications in a programming language such as C, C++, Delphi, Pascal or Visual
Basic:
-
Functions for opening and closing data and mailbox channels

Functions for writing commands and reading messages via the Mailbox
Interface (MXI)
Functions for reading and writing I/O data via the Data Interface (DTI)
Diagnostic functions to check the operating state of the controller board
Watchdog and monitoring functions
These functions are implemented in the Device Driver Interface (DDI) and are
virtually the same for all INTERBUS controller boards. Figure 4.12 shows the
hardware, which can be accessed via the DDI communication channels.
Host PC
INTERBUS
controller board
Control program
Device Driver
Diagnostic
functions
Data
Interface
Mailbox
Interface
Management
of
data channels
Device Driver nterface

INTERBUS
MASTER
MPM
Figure 4.12: Accessing a PC controller board via the various channels of the DDI
When creating a user-specific high-level language program, the Device Driver
Interface must be integrated in the high-level language project. The Device Driver
Interface, which consists of libraries (*.LIB, *.DLL) and include files (*.h), is made
available with the INTERBUS controller board and depends on compilers or
interpreters (MS C++, Borland C++, Borland Delphi, MS Visual Basic, etc.). Table
4.12 and Table 4.13 list the DDI libraries and include files for the various
programming languages used by INTERBUS PC and Ethernet controller boards.
They are inserted in the high-level language project and provide an interface to the
INTERBUS driver (DD) and therefore to the INTERBUS controller board.
179
Table 4.12: DDI libraries and include files for Ethernet controller boards
Programming
Library
Include Files
Language
MS Visual C, C++,
ibseth.lib
ddi_err.h, ddi_macr.h, ddi_usr.h, ibs_util.h,
Borland C, C++
eth.a
stdtypes.h, svc_code.h, ddi_eth, ddi_win.h,
under MS-DOS, SUN
eth_err.h, eth_mng.h, eth_secu.h, eth_unix.h,
Solaris 2.4,
ethwin32.h, iocrtl.h
Windows
95/98/NT/2000
Table 4.13: DDI libraries and include files for PC controller boards
Library
Include Files
ibs_dos.h,
ddi_err.h,
MS Visual C, C++ to 1.52, lddi_tsr.lib
Borland C, C++
ddi_macr.h, ddi_usr.h, ibs_util.h,
under MS-DOS
opmode.h, stdtypes.h,
svc_code.h
ibsg4uti.h, console.h
ibs_win.h, ddi_win.h, ddi_err.h,
MS Visual C, C++ to 1.52, ibddiwin.lib
Borland C, C++
win16con.lib ddi_macr.h, ddi_usr.h, ibs_util.h,
under Windows 3.X
opmode.h, stdtypes.h,
(16-bit)
svc_code.h, ibsg4uti.h,
win16con.h, console.h
ibddiw95.h, ddi_win.h,
MS Visual C, C++,
ibddiw95.lib
ddi_err.h, ddi_macr.h, ddi_usr.h,
Borland C, C++,
C-Builder under
ibs_util.h, opmode.h, stdtypes.h,
Windows 95/98 (32-bit)
svc_code.h, ibsg4uti.h,
console.h
ibddiwnt.h, ddi_err.h,
MS Visual C, C++ under
ibddiwnt.lib
Windows NT 4.0/2000
ddi_macr.h, ddi_usr.h,
ddi_win.h, ibs_util.h, opmode.h,
stdtypes.h, svc_code.h
ibsg4uti.h, console.h
Borland Delphi under
bpisawin.pas Windows 3.x/95/98
(16-bit)
Borland Delphi
bpisaw95.pas under Windows 95/98
(32-bit)
Borland Delphi
bpisawnt.pas under Windows NT
4.0/2000
MS Visual Basic under
Windows 3.x/95/98
(16-bit)
MS Visual Basic
under Windows 95/98
(32-bit)
MS Visual Basic
under Windows NT
4.0/2000
Utility Files
ibsg4uti.c
ibsg4uti.c
ibsg4uti.c
ibsg4uti.c
g4utiwin.pas
g4utiw95.pas
g4utiwnt.pas
g4utiwin.bas
g4utiw95.bas
g4utiwnt.bas
The most important functions in the DDI are the calls for opening and closing the
data and mailbox channel (DDI_DevOpenNode, DDI_DevCloseNode), the
180
functions
for
transferring
messages
(DDI_MXI_SndMessage,
DDI_MXI_RcvMessage), and the functions for transferring INTERBUS input and
output data (DDI_DTI_WriteData, DDI_DTI_ReadData). The integration of the
supplied utility files (e.g., ibsg4uti.c and ibsg4uti.h for C/C++) makes it easier to
access the DDI functions. The utility files group DDI functions, which experience
shows are used together. For example, a utility function OpenHandles can be used
to open the communication channels for the data and the mailbox. In order to use
the utility functions, the relevant utility files must be added, see Table 4.12 and
Table 4.13. Table 4.14 lists the individual functions of the ibsg4util.c utility file.
Additional information on the DDI software interface for INTERBUS

controller boards from Phoenix Contact can be found in the "Driver
Reference Manual for PC Controller Boards", IBS PC SC SWD UM E.
Table 4.14: INTERBUS functions of utility files

Open communication
channels
Close communication
channels
Send messages without
parameters
Send messages with
parameters
Poll for messages
Poll for an expected
message
Poll for a positive
confirmation
Check a confirmation
Write process data to
INTERBUS (word-oriented
with INTEL/Motorola rotation)
Read process data from
INTERBUS (word-oriented
with Motorola/INTEL rotation)
Write process data to
INTERBUS (byte-oriented
without INTEL/Motorola
rotation)
Read process data from
INTERBUS (byte-oriented
without Motorola/INTEL
rotation)
INTERBUS diagnostics
PCP connection
establishment
PCP connection release
Check a positive PCP
confirmation
OpenHandles (USIGN16 BoardNo, USIGN16 Direction, IBDDIHND

IBPTR * D_Handle, IBDDIHND IBPTR * M_Handle)
CloseHandles (IBDDIHND D_Handle, IBDDIHND M_Handle)
CommandIBS (IBDDIHND Handle, USIGN16 code)
RequestResponse (IBDDIHND Handle, USIGN16 IBPTR * Msg)
ConfirmationIndication (IBDDIHND Handle, USIGN16 IBPTR * Msg)
WaitForMessage (IBDDIHND Handle, USIGN16 TrueMsg, USIGN16
timeout, USIGN16 *Msg)
WaitForPosCnf (IBDDIHND Handle, USIGN16 TrueMsg, USIGN16
timeout, USIGN16 *Msg)
CheckPosCnf (USIGN16 CNF, USIGN16 IBPTR * MSG)
WriteData_I2M (IBDDIHND Handle, USIGN16 AtByteAddr, USIGN16
nWords, USIGN16 IBPTR * Data)
ReadData_M2I (IBDDIHND Handle, USIGN16 FromByteAddr,
USIGN16 nWords, USIGN16 IBPTR * Data)
WriteData (IBDDIHND Handle, USIGN16 AtByteAddr, USIGN16
nbytes, USIGN8 IBPTR * Data)
ReadData (IBDDIHND Handle, USIGN16 FromByteAddr, USIGN16

nbytes, USIGN8 IBPTR * Data)
IBSState (IBDDIHND NodeHdMXI, INT16 IBPTR * state, INT16 IBPTR

* para)
InitiatePCPModule (IBDDIHND NodeHdMXI, USIGN16 KR)
AbortPCPModule (IBDDIHND NodeHdMXI, USIGN16 KR)
CheckPosPCPCnf (USIGN8 KR, USIGN16 CNF, USIGN16 IBPTR *
MSG)
The implementation of an INTERBUS application programmed in high-level

language requires extensive knowledge of the programming language and the
compiler/interpreter. To enable users to quickly program an operational INTERBUS
181
application, DDI programming examples with comments in C, C++, Visual Basic or

Delphi are provided on the accompanying CD-ROM.
4.1.6 INTERBUS Controller Board Programming via the HLI

The HLI (High-Language Interface) is, as previously described, a plug-on part for
the DDI, which requires files for the Device Driver Interface and the Device Driver.
Figure 4.13 shows how to access the hardware via the HLI and the DDI
communication channels.
Control program
Host PC
INTERBUS
controller board
High-level language interface
Diagnostic
functions
Data
Interface
Mailbox
Interface
Management
of
datachannels
Device Driver
INTERBUS
MASTER
MPM
Figure 4.13: Accessing a PC controller board via the various channels of the HLI
When using the HLI to program user-specific INTERBUS

applications, many DDI functions are replaced by simpler
instructions. During programming, complex instructions are often not
required, as they are already implemented in the HLI.
The HLI is integrated in the high-level language project as a library, see Table 4.8,
and the HLI functions from the HLI library are virtually the same for all INTERBUS
controller boards. A wide range of function calls are available for creating a userspecific HLI application in a programming language. Table 4.15 lists the most
important functions of the g4hliw32.lib HLI library.
Table 4.15: INTERBUS functions of the HLI library
Initialize INTERBUS
(physical)
Initialize INTERBUS
(with configuration
specification)
Deinitialize INTERBUS
Run state machine (all
messages are fetched)
IBS_HLI_Init (USIGN16 CID, T_HLI_STATE REF lpIbsState, USIGN16

ibs_mode);
IBS_HLI_Init_CFG (USIGN16 CID, T_HLI_STATE REF lpIbsState,
USIGN16 ibs_mode, USIGN16 nDevices, T_HLI_DEVICE_DATA REF
lpDeviceList);
IBS_HLI_Exit (USIGN16 CID);
IBS_HLI_Process (USIGN16 CID);
Register process data

objects
IBS_HLI_RegisterPD_ (USIGN16 CID, USIGN16 PD_Type, USIGN16

segment_nr, USIGN16 segment_pos, USIGN16 PDOType, USIGN16
ByteOffset, USIGN16 BitOffset, USIGN16 Length, VOIDREF lpAppVar,
HLIBOOL REF lpChangedInd);
182
Read INTERBUS input data

Write INTERBUS output
data
Start INTERBUS
Stop INTERBUS
INTERBUS alarm stop
Read PCP device data
Write PCP device data
Read statistical data from
INTERBUS
Activate the watchdog
IBS_HLI_PD_Input (USIGN16 CID, VOIDREF lpAppVar);

IBS_HLI_PD_In (USIGN16 CID);
IBS_HLI_PD_Output (USIGN16 CID, VOIDREF lpAppVar);
IBS_HLI_PD_Out (USIGN16 CID);
IBS_HLI_StartBus (USIGN16 CID);
IBS_HLI_StopBus (USIGN16 CID);
IBS_HLI_AlarmStop (USIGN16 CID);
IBS_HLI_PCP_ReadRequest (USIGN16 CID, T_HLI_PCP_RW REF
lpRRQ);
IBS_HLI_PCP_StartRequest (USIGN16 CID, T_HLI_PCP_PRG REF
lpPRG);
IBS_HLI_GetDiagnosticInfo (USIGN16 CID, T_HLI_SC_DIAG REF DI);
IBS_HLI_ActivateWatchdog (USIGN16 CID, USIGN16 WD_Timeout);
Additional information on the HLI software interface for INTERBUS

controller boards from Phoenix Contact can be found in the "User
Interface Version 2.x for High-Level Language Programming" User
Manual, IBS PC SC HLI UM E.
The implementation of an INTERBUS application programmed in high-level

language requires extensive knowledge of the programming language and the
compiler/interpreter. To enable users to quickly program an operational INTERBUS
application, HLI programming examples with comments in C, C++, Visual Basic or
Delphi are provided on the accompanying CD-ROM.
4.1.7 Driver Development With the Device Driver Development

Kit (DDK)
The information on operating system and driver support for INTERBUS PC and
Ethernet controller boards listed in Table 4.1 and Table 4.5 refers to software that
was approved as of March 2002. It can be seen that driver software is not available
for all operating systems.
The Device Driver Development Kit (DDK) for INTERBUS controller boards from
Phoenix Contact enables users to develop their own drivers, for example a driver
for another PC operating system. This kit contains the driver sources in C
programming language, and therefore can be used to develop specific INTERBUS
drivers for G4 controller boards under VxWorks, Linux, Solaris, etc.
The driver programming for the relevant interface for INTERBUS

controller boards from Phoenix Contact is described in the user
manuals "Device Driver Development Kit for Controller Boards in PC
Systems With PCI Bus", IBS PCI DDK UM E and "Device Driver
Development Kit for Controller Boards in PC Systems With ISA
Bus", IBS ISA DDK UM E.
4.1.8 Practical Tips

Tip: How to control several INTERBUS controller boards simultaneously from one
program
183
It is possible to control several INTERBUS controller boards in a host PC from one

application. The number of PC controller boards that can be controlled depends on
the PC slots or Ethernet entries, the free system resources, and the Device Driver.
Table 4.4 lists the maximum number of PC controller boards from Phoenix
Contact, which are supported by the Device Driver.
The PC controller boards must be controlled either by INTERBUS programs, which
can be started several times and can establish online links to different INTERBUS
controller boards with new communication parameters or by programs, which
support independent communication links to several INTERBUS controller boards.
Although the creation of several communication links is no different to that of
"simple" links, this function must be implemented in the source code. The use of
different communication handles must be noted, as each MXI and DTI
communication link has its own handle.
Tip: How to implement MPM accesses for fast communication
On many INTERBUS controller boards, user-programmed applications can be

used to access the coupling memory of the INTERBUS controller Multi-Port
Memory (MPM) and its accessible memory areas. This means that it is possible to
manipulate address contents with read and write access or just to read data via
communication links such as Ethernet, ISA port, PCI port or serial interface.
Tip: How to activate the HLI export in IBS CMD G4
The file Hliexpe.dll (English) or Hliexpd.dll (German) must be copied from the HLI
directory into the CMD/BIN directory and the path under CMD | Tools | Activate
Add-On Programs must be set accordingly. The export file can then be activated
under CMD | TOOLS | ADD-ON PROGRAMS. The HLI export file for high-level
language programs can then be created under CMD | Write Parameterization
Memory | File | HLI Export File. In this export file, all necessary process data is
predefined as variables, HLI-specific variables, and user functions.
Tip: Ensure sufficient bandwidth for INTERBUS Ethernet controller boards
To ensure error-free operation between an INTERBUS Ethernet controller board

and a control program, a sufficient transmission bandwidth is required. This is
particularly important when the network covers a large area and the network load
can be very high for short periods. This could then trigger the DTI and host
watchdogs.
184
Tip: How to convert the Microsoft-compatible dynamic library ibddiwnt.dll into a

Borland-compatible library: ibddiwnt.lib, so that it can be used in a Borland project.
Two files from the Borland/Bin directory are required for the conversion: impdef and
implib. Use the command: c:\impdef ibddiwnt.def ibddiwnt.dll to create a definition
file and then the command: c:\implib ibddiwnt.lib ibddiwnt.dll to generate a Borlandcompatible library. This library can be processed in a Borland compiler.
Tip: How to set an interrupt on IBS PC ISA controller boards to 0
A faulty communication link to an IBS PC ISA controller board may be due to a

parameter in the system resources. Even if you have determined free resource
assignments for IRQ, I/O, and MPM under Windows NT 4.0/2000, this may not
mean that these areas are actually free.
In order to determine whether the interrupt is the parameter, which is causing the
communication link to fail, it can be set to 0 in the registry editor as a test (see
checklists). However, the Device Driver does not interpret this interrupt setting as
0, but polls continuously for messages from the IBS PC ISA board.
Tip: How to access a lower-level INTERBUS controller board
Figure 4.14 shows an INTERBUS configuration, in which an INTERBUS master

controller board and an INTERBUS master/slave controller board are integrated
into INTERBUS. To access the INTERBUS master/slave controller board and the
lower-level INTERBUS system, a communication management connection is
required via the PNM7 communication channel. This PNM7 connection can be
parameterized "manually" or configured using the @utomationXplorer. Details of
how to use the @utomationXplorer can be found in Section 5 "INTERBUS
Specialist Knowledge".
Industrial PC
INTERBUS High-level
language application
Access to a PCP device
PHOENIX
CONTACT
UL
RD Y/R UN
BSA
FAIL
PF
100
COL
XMT
INTER BU S
R EMOTE
Creation of a
communication
connection
Creation of a
management
connection
INTERBUS
RC V
UL
Ethernet
10/100
FLIBSSC/I-T
Ord .-No.:2 83106 0
INTERBUS
FL IBS SC/I-T
IBS PCP device

IBS ISA SC RI/RT-LK
master/slave IBS card
Figure 4.14: Accessing a master/slave controller board
185
4.1.9 Questions for the "High-Level Language Programming"

Section
1. Which communication path do application programs use to access INTERBUS
PC controller boards such as the IBS PCI SC/I-T?
2. Which communication path do application programs use to access INTERBUS
Ethernet controller boards such as the FL IBS SC/I-T?
3. What are the advantages of the Device Driver Interface (DDI) compared with
the High-Level Language Interface (HLI)?
The answers to questions for the "Programming INTERBUS Controller

Boards in High-Level Language" section can be found on the
186
4.2 Programming in IEC 61131-3 Using PC WORX

Phoenix Contact offers powerful Field Controllers for PC applications and Remote
Field Controllers, which are used as stand-alone devices on the DIN rail. An IEC
61131 runtime system is used, which is programmed as the control software using
PC WORX. All Field Controllers provide comprehensive networking options with
INTERBUS or Ethernet.
4.2.1 INTERBUS PC Field Controller

Powerful Field Controllers are used in a PC to manage complex control and
automation tasks. The Field Controllers provide an IEC 61131 performance, which
is independent of the host system. The runtime system runs on the PC board and
does not overload the PC system, which is able to focus primarily on its own
application programs, e.g., a visualization system. The Field Controller boards offer
a scaleable performance for various different tasks.
4.2.1.1
Available INTERBUS PC Field Controllers
Table 4.16 shows the INTERBUS PC Field Controllers from Phoenix Contact that
are currently available. Like Table 4.1, the table below also specifies the driver
data and supported operating systems.
Table 4.16: Overview of PC Field Controller from Phoenix Contact
INTERBUS PC Field
Controller
IBS ...
ISA FC/I-T
ISA FC/486DX/I-T
4.2.1.2
Supported
Operating
Systems
Name of
Device Driver
(DD)
WinNT4.0
Win 2000
Win NT4.0
Win 2000
ibsisasc.sys
ibsisasc.sys
ibsisasc.sys
ibsisasc.sys
Directory
Containing
Device Driver
Name of
Device Driver
Interface
(DDI)
ibddiwnt.dll
ibddiwnt.dll
ibddiwnt.dll
ibddiwnt.dll
Directory
Containing
Device Driver
Interface
winnt/system32
winnt/system32
winnt/system32
winnt/system32
Both Field Controller boards are programmed using the control software PC
WORX, regardless of the operating system being used. Users can access process
data or the XDTA area (see Section 1.7 "MPM"), using the standard drivers, which
are already installed. Table 4.17 lists the available programming interfaces for
INTERBUS PC Field Controllers IBS ISA FC/I-T and IBS ISA FC/486DX/I-T,
depending on the operating systems used.
Table 4.17: DDI programming interfaces for IBS ISA FC/I-T and IBS ISA FC/486DX/I-T
Programming
Win NT 4.0
Win 2000
Language
C, C++
X
X
Delphi
X
X
Pascal
X
X
Visual Basic
X
X
4.2.1.3
187
INTERBUS PC Field Controller Driver Concept From Phoenix

Contact
The driver concept has already been described in 4.1.1.3. Table 4.18 gives the
INTERBUS PC Field Controllers from Phoenix Contact together with their
corresponding driver types.
Table 4.18: Differences between MPM and DPM for PC controller boards
PC Controller Boards
From Phoenix Contact
IBS ISA FC/I-T
IBS ISA FC/486DX/I-T
Driver Type
Maximum Number of Boards

Supported by the PC Driver
MPM
All data and information is exchanged between the individual MPM accessors,
such as the host PC, the INTERBUS master and the runtime operating system
ProConOS via the MPM. Figure 4.15 shows the access paths between a
visualization and an INTERBUS controller board via the Device Driver Interface
(DDI), the Device Driver (DD) and the Multi-Port Memory (MPM).
Host PC
INTERBUS
controller board
Visualization
Device Driver
INTERBUS
MASTER
MPM
ProConOS
Figure 4.15: Accessing the PC controller board via the DDI, DD, and MPM
4.2.2 INTERBUS Remote Field Controller

Remote Field Controllers are used to directly connect I/O modules to the
INTERBUS master housing or to connect a number of INTERBUS devices to the
remote bus output. Remote Field Controllers are mainly used for distributed
control. As far as performance is concerned, they have the same low performance
class as PC Field Controllers. The controller is programmed in IEC 61131 using PC
WORX.
4.2.2.1
Available INTERBUS Remote Field Controllers
Table 4.19 gives an overview of the INTERBUS Remote Field Controllers from
Phoenix Contact that are currently available. The driver data and support operating
systems are also listed.
188
Table 4.19: Overview of Remote Field Controllers from Phoenix Contact

INTERBUS PC Field
Controller
IBS ...
IBS ST 24 RFC-T
ILC 200 IB
4.2.2.2
Supported
Operating
Systems
Name of
Device Driver
(DD)
WinNT4.0
Win 2000
Win NT4.0
Win 2000
ibsisasc.sys
ibsisasc.sys
ibsisasc.sys
ibsisasc.sys
Directory
Containing
Device Driver
Name of
Device Driver
Interface
(DDI)
ibddiwnt.dll
ibddiwnt.dll
ibddiwnt.dll
ibddiwnt.dll
Directory
Containing
Device Driver
Interface
winnt/system32
winnt/system32
winnt/system32
winnt/system32
Programming Interfaces, Operating Systems, and Driver

Concept
The programming interfaces and supported operating systems do not differ from
the data of the PC Field Controller and should therefore be used. The same
applies to the driver concept.
4.2.3 INTERBUS Ethernet Remote Field Controller

Ethernet Controllers from Phoenix Contact offer a distributed, modular automation
with IEC 61131 control system technology and network connection. Control
performance is achieved by the PC/104 standard, starting with the performance of
the powerful PC Field Controller board. The RFC 450 ETH-IB exceeds this
performance level and represents the current "Flagship" of the Field Controller. All
Remote Field Controllers are seamlessly programmed using PC WORX.
4.2.3.1
Available INTERBUS Ethernet Remote Field Controllers
Table 4.20 lists the INTERBUS Remote Field Controllers for Ethernet systems
from Phoenix Contact and provides details of supported operating systems and
drivers.
Table 4.20: Overview of Ethernet Remote Field Controllers from Phoenix Contact
INTERBUS Ethernet
Controller Board
RFC 430 ETH-IB

RFC 450 ETH-IB
4.2.3.2
Directory
Containing
Socket
Name of
Device Driver
Interface
(DDI)
Directory
Containing
Device Driver
Interface
Supported
Operating
Systems
Name of
Socket
Win NT4.0
Win 2000
wsock32.dll
wsock32.dll
winnt/system32
winnt/system32
ibddiwnt.dll
ibddiwnt.dll
winnt/system32
winnt/system32
Sun Solaris
bsdsocket
ibseth.lib,eth.a
Depending on the operating system used, Ethernet controller boards can be

accessed using C, C++, Delphi or Visual Basic programming language for
visualization purposes.
Table 4.21 lists the programming interfaces of the INTERBUS Ethernet Remote
Field Controller RFC 430 ETH-IB and RFC 450 ETH-IB, depending on the
operating systems used.
189
Table 4.21: DDI programming interfaces for RFC 430 ETH-IB and RFC 450 ETH-IB
Programming
Language
Win NT 4.0
Win 2000
Linux
SUN Solaris
2.4
C, C++
Delphi
Visual Basic
X
X
X
X
X
X
X
-
X
-
4.2.3.3
Other Unix Systems

1
1
INTERBUS Ethernet Driver Concept From Phoenix Contact
The driver concept has not changed in relation to the dedicated high-level
language controller boards, as referred to in Section 4.1.2.3.
4.2.4 Programming in IEC 61131-3 Using PC WORX

Today, programmable logic controllers still have a central role in automation
technology. A uniform PLC concept has therefore been designed over the last few
years, in which even the programming languages are standardized for all PLC
systems. The PLC Standard IEC 61131 has thus been developed under the
umbrella of the International Electrotechnical Commission (IEC). IEC 61131 not
only standardizes the programming languages, but also the interfaces between the
PLC and the programming system, and the structure and processing of projects. If
all PLC manufacturers comply with this standard, the benefits of portability can be
used to the full.
This section details the programming languages described in the third section of
the standard, when using PC WORX.
4.2.4.1
ProConOS
ProConOS is a software PLC runtime system, which runs on different processor

systems such as Intel or Motorola. It is then used as a task by a realtime operating
system. The realtime operating system used for PC WORX controller boards for an
IPC target is VxWorks and for an M68 target is VRTXsa. The different targets
are detailed in Section 4.2.5.2.
Figure 4.16 shows the development process of a PC WORX project with
subsequent control of the process using ProConOS.
The software interface kit IBS ETH DDI SWD E is used to adapt the Device Driver
Interface (DDI) to other UNIX operating systems.
190
BDO 32/2
AO 4/SF4
Send project
ProConOS
control system
PC WORX
programming system
BAI 8/U
Control
system
Automation process
Signals from field
Editors
Bus configuration
PLC programming
Data management
Service programs
Compiler
Online display
Online changes
PLC program blocks

I/O interface
Communication
System manager
Error manager
Debug driver
Data management
Task sheduling
Program memory
Data memory
Buffer memory
I (inputs)
Q (outputs)
M (bit memory)
Retain
Boot project
ProConOS memory
Figure 4.16: Components of the PC WORX environment

4.2.4.2
Project Tree in PC WORX
Project folder
Library folder:
Functions, programs, and function blocks that have
already been created for reuse.
User-defined data types:
Arrays, matrixes, etc.
Program organization units:

Creation of functions, programs and
function blocks.
Instances
Hardware
Libraries
POUs
Project view
Physical hardware:
Configuration, resource, and task handling for
set controller board.
Figure 4.17: Project tree in PC WORX
191
The project tree is the basis of a PC WORX program. All programming tasks are
performed and managed in the project tree. Figure 4.17 shows the project tree
with the individual components and a brief description (PC WORX 3.0x). Use the
tab at the bottom of the window to quickly switch between the views for project,
POUs, libraries, hardware, and instances.
4.2.4.3
Program Organization Unit (POU)
The POU is the language element of an IEC 61131 PLC program, which contains
the program code. It forms a small software unit, which must be clearly identifiable
within the project, in other words, a POU name can only be assigned once within
the whole project.
4.2.4.3.1 Programs, Function Blocks, and Functions
A distinction is made between the following POU types:

-
Programs
Function blocks
Functions
Each of these POU types is then divided again into a description section (notepad
used to describe the POU), declaration section (variable declaration), and an
instruction section (programming environment).
Figure 4.18 shows the structure of a POU in the project tree window of PC WORX.
POU folder
POU header
Descriptive system
Declaration section
Instruction section
Figure 4.18: POU structure
192
Program
Program
Function block
Function block
Function
Function
Figure 4.19: Call options of POUs

Table 4.22: Programs, function blocks, and functions
POUs
Programs
Function blocks
Meaning
Upper level of the POU. Consists of functions and function blocks and
the required control structures.
Programs are called by a single task, which was previously assigned to
the program.
Recursive calls are not permitted.
At the hierarchical level, function blocks come directly after the
programs. All functions, which are also possible in programs, can be
integrated. Function blocks, however, are called by programs or other
function blocks. A task cannot call a function block.
It is possible to parameterize input and output parameters, so that all
values used by the block can be transferred.
Function blocks have a storing capacity, which is why they are
instantiated -> The same input values may produce different output
values.
Recursive calls are not permitted.
A distinction is made between the standard function blocks, which
originate from the system and are defined in IEC 61131-3, and function
blocks written by the user.
Functions
193
Functions can have several input parameters, but only one output
parameter, the return value. They have no storing capacity, so that the
same input parameters always produce the same result. The advantage
is that functions require less memory.
A function on the other hand can call another function, but not a function
block or certainly not a program.
IEC 61131-3 defines the standard functions. The user, however, can
create his own functions.
In PC WORX the return value must be an elementary data type.
All function blocks, which can be used in PC WORX, are detailed in the
"PROGRAM WORX - Functions and Function Blocks" User Manual
IBS PROGRAM WORX 2.0 FUB UM E (or 3.0). This manual should
always be kept to hand when using PC WORX.
Figure 4.19 details the call options of POU types. Programs cannot be called by
programs. Programs must be assigned to a task, which then calls the program
following the set cycle time.
A comparison is often made between PC WORX and other PLC systems. An
important factor is the recognition effect of known structures. Figure 4.20 shows
how to identify terms used by other control system manufacturers in PC WORX.
Conventional PLC
OB organizational
block
SB system
block
IEC
Task
Program
FB function
block
PB program
block
Function
Function block
DB data block
User-defined data types

Fields and structures
Figure 4.20: Comparison of conventional PLC IEC 61131
194
4.2.4.4
Absolute and Symbolic Addressing
With PC WORX, the memory of the control system is not permanently linked to the
I/O devices. For conventional PLC control systems, the same bits can be randomly
addressed in the memory, either as a bit, byte or double word and are directly
linked to the I/O devices. The IEC standard and PC WORX both specify that a
memory cell can only have one data item with a set data type. It is possible to
convert it to another data type via special type conversions (these functions are
known as *_TO_**, e.g., WORD_TO_BOOL).
A variable can be given a symbolic address or an absolute address with PC
WORX. Symbolic addressing is the standard addressing for PC WORX. A user
declares a variable in the POU and then assigns the data direction in the global
variable explorer at a later date. A process data item is then assigned to the
variable, i.e., it links the variable to the INTERBUS I/O devices. To perform this
task, you need specific tools such as SYSTEM WORX in PC WORX (PC WORX
2.0x) or a special bus configurator in PC WORX 3.0x. The system knows the
memory segmentation of the hardware and therefore performs the assignments in
a controlled manner.
This is not the case for absolute addressing. Here it is the user who determines the
memory location of variables. In general, there is no checking of possible
overlapping.
Symbolic addressing: Variable name / Data type / Data direction / Scope / Process
data item
For example, Not_Aus / BOOL / I / VAR_EXTERNAL / 1.1.1_IB IL 24 DI 8 1.2
Absolute addressing: Variable name / Data type / Data direction / Scope / Address
For example, Not_Aus / BOOL / I / VAR_EXTERNAL / %IX10.3
Symbolic Addressing
Data direction:
I:
Input
Q:
Output
M:
Bit memory
R:
Retain (remanence)
4.2.4.5
Absolute Addressing
1. % initiates absolute addressing
2. Data direction
I:
Input
Q:
Output
M:
Bit memory
R:
Retain (remanence)
4. Data type
X:
Bit
B:
Byte
W:
Word
D:
Double word
Keywords for Variable Declaration in PC WORX
Appropriate keywords must be used for variable declaration. The assignment of

keywords to the POU types is shown in Table 4.23. The meaning of the different
keywords can be found in Table 4.24.
195
The keyword determines the local or global validity of the variable.
Table 4.23: Assigning keywords (types) to POU types

Variable Type
Programs
Function block
Global variable
VAR_EXTERNAL
VAR_EXTERNAL
VAR_EXTERNAL_PG
VAR_EXTERNAL_PG
VAR_EXTERNAL_FB
Local transfer
Not possible
VAR_INPUT
variable
VAR_OUTPUT
VAR_IN_OUT
Local variable
VAR
VAR
Function
Not possible
VAR_INPUT
VAR
Table 4.24: Keywords (types) for variable declaration

Key Word
Description
VAR
Internal, local variable. Only valid within POU.
VAR_INPUT
Input variable for function blocks and functions. The variable is
treated in the same way as a local variable.
VAR_OUTPUT
Output variable for function blocks and functions. The variable is
treated in the same way as a local variable.
VAR_IN_OUT
Input and output variable for function blocks and functions. The
address of variables is also transferred (reference parameters).
Main field of application is the transfer of fields and structures.
VAR_EXTERNAL
Global variable for programs and function blocks. Data exchange
possible across all POUs.
The variable is visible to all POUs that are instantiated in the same
resource (hardware tree).
Access to the INTERBUS process data is possible.
VAR_EXTERNAL_PG
Global variable for programs and function blocks. Data exchange
is not possible across all POUs.
The variables are only visible in the program instance. Function
blocks in this program instance can also access this variable, but
not vice versa.
Global variable for function blocks. Data exchange is not possible
VAR_EXTERNAL_FB
across all POUs.
VAR_GLOBAL
For global variables, which can be used in all programs and
function blocks of the project. This type is created directly in PC
WORX in the global variable explorer. All variables with the
keyword VAR_EXTERNAL_... change to VAR_GLOBAL_... in the
global variable explorer.
196
4.2.4.5.1 Global Variable Validity in PC WORX
Figure 4.21 shows the scope of validity for global variables. The project tree shows
the MAIN program which is created and which calls a MAIN_FB function block. The
function block contains definitions of variable types VAR_EXTERNAL_PG and
VAR_EXTERNAL_FB. The project tree also shows the correct structure of the
hardware tree, if an integrated function block contains these variable types.
Resource
VAR_EXTERNAL
Program 1
VAR_EXTERNAL_PG
FB
FB
VAR_EXTERNAL_PG
VAR_EXTERNAL_FB
VAR_EXTERNAL_PG
VAR_EXTERNAL_FB
Program 2
VAR_EXTERNAL_PG
FB
Global variables
(VAR_EXTERNAL)
VAR_EXTERNAL_PG
VAR_EXTERNAL_FB
FB
VAR_EXTERNAL_PG
VAR_EXTERNAL_FB
Program global variables

(VAR_EXTERNAL_PG)
FB global variables
(VAR_EXTERNAL_FB)
Figure 4.21: Scope of validity for global variables

The scope of validity for these global variables is shown next to the project tree
diagram.
In principle, you can access a variable of the POU where it is declared, and in all
lower-level units (this only applies to function blocks, since it is not possible to
define global variables in functions). The function block can access variables of the
higher-level program, but not vice versa.
Example: Both programs can access the global variables (VAR_EXTERNAL). The
programs themselves cannot access their VAR_EXTERNAL_PG variables.
Function blocks within the programs have access to the VAR_EXTERNAL_PG
variables of the programs. Vice versa access is not possible. A program cannot
access the PG or FB variables of subprograms.
197
Note: In order to access a local or program global variable of another POU, the
instance name must precede the variable name. Example: Instance_1.door_open,
Instance_1: Program instance.
Structure elements can only be accessed via the RD_*_BY_SYM (*: data type)
functions. These functions can be used for all types of access.
4.2.4.6
Instantiation
When IEC 61131-3 is referred to, the term instantiation is often used. Instantiation
means, that an object (e.g., function block) is created once and can then be used
several times. Since the function block has an internal data area, memory space
has to be reserved by the PLC system for each copy of the function block. This
requires a name, so that the reservation can be assigned in the memory, in other
words, an instance name.
Example: The standard function block for an RS-FlipFlop is called RS. The
instance name is created by default by PC WORX as RS_1.
4.2.4.7
Programming Languages in PC WORX
IEC 61131 details the graphical and textual languages, which can also be used in
PC WORX. Table 4.25 gives an overview of the IEC languages used in PC WORX.
Table 4.25: Programming languages in PC WORX
IEC Language
Meaning
Instruction list (IL) Textual programming language which is similar to the conventional IL
languages of other manufacturers. The code is a sequence of instructions,
with each instruction starting on a new line.
Example:
LD
AND
ST
Structured text
(ST)
Bit memory1 (* Loads bit memory1 into the accumulator *)

Bit memory2 (* Process accu with AND operation *)
Bit memory3 (* Save accumulator contents in bit memory3 *)
Textual programming language, which is similar to the high-level language

Pascal. The code is made up of instructions and expressions. Typical
IF..THEN..ELSE, FOR..NEXT and CASE structures are possible.
Example:
IF bit memory1=FALSE THEN
Bit memory3 := bit memory2;
END_IF;
198
Function block
language (FBD)
Graphical programming language, which represents all functions and

function block as a rectangular block. The blocks can be connected with
each other using lines or they can be directly connected to a variable. All
connected objects form an FBD network. Example:
Ladder diagram
(LD)
Graphical programming language, which is based on the conventional

circuit diagram. The program code is made up of contacts and coils. The
contacts move the current from left to right and the coils save the input
value as a Boolean variable.
Example:
Sequential function Graphical programming language, where the program code is made up of
chart (SFC)
steps and transitions. A step can perform several actions. The transition
contains the next switching requirement for the next step. This
programming language is similar to a flowchart.
Example:
199
4.2.5 Mapping the Physical Hardware in PC WORX

4.2.5.1
IEC Hardware Model
IEC 61131 describes the hardware structure of a PLC system as an automation

system, consisting of several configurations (PLC rack), which can communicate
with each other. The configuration consists of one or more resources (CPU). A
resource can have tasks assigned to it, which can call programs. Programs are
made up of functions and function blocks. Figure 4.22 gives a graphical
representation of the IEC hardware model.
Configuration
Resource 1
Resource 2
Task 1
Task 1
FB
FU
FU
FB
FB
FB
Task 2
FU
Task 2
FB
FU
FB
FU
FU
Figure 4.22: IEC hardware model

4.2.5.2
Hardware Structure in PC WORX
PC WORX controller boards are compact controllers, which cannot be expanded in

the hardware. In other words, the number of configurations and resources per
controller is predefined. For current controller board types, there is always one
configuration and one resource. The resource however can consist of an INTEL
(IPC) or MOTOROLA (M68) target. Figure 4.23 gives an overview of how to
classify Phoenix Contact hardware for each type of configuration.
200
Configuration IPC
IBS ISA FC/
486 DX/I-T
PLC rack
RFC 430
ETH-IB
Configuration M68
IBS ISA FC/I-T
PLC rack
ILC 200 IB
RFC 450
ETH-IB
IBS ST 24 RFC-T
BK-FT-T
RFC-T
Figure 4.23: Classification of Phoenix Contact hardware in IPC and M68
Folder for hardware directory

Configuration: PLC rack
Resource: SPS CPU
Tasks: CPU management
Global variables:
Global variables of configuration
I/O configuration:
Assignment of IBS process data
2. Configuration
Figure 4.24: Hardware structure in the project tree of PC WORX

The hardware structure in PC WORX is configured in the project tree, see Figure
4.24.
With PC WORX Version 3.0 or later, it is possible to configure several
configurations and the corresponding resources in a project. An M68_32
configuration and an IPC_32 configuration have been created in the project tree in
Figure 4.24.
4.2.5.3
System Tick
The system tick plays an important role in ProConOS. It is used to control task
calls, and is used as a timer in ProConOS. It is formed by a timer unit of the
hardware. The pulses per second are dependent on the hardware being used.
IPC target: 1/1024 1/s= 0.98 ms
M68 target: 1/200 1/s = 5 ms
4.2.5.4
201
Task Types in PC WORX
In PC WORX, the user can distinguish between a cyclic task, event task, and a
system task. The special characteristic of this control system would have to be the
cyclic task, which enables the user to specify a cycle time. For most conventional
PLC systems, the cycle time is determined by the PLC program, free running tasks.
This type of task is referred to as default task in PC WORX.
Task Type
Cyclic task
Feature
This type of task is called within a set time interval, a multiple of the system
tick. The valid value range is between 1 and 32767 ms. The average must
be the set cycle time. If there are several cyclic tasks, the priority of the task
is determined by the processing sequence. The priority values are between
0 and 31, where 0 is the highest priority.
The event task is activated by a hardware event. Possible events are, for
example, the fast inputs and outputs of the ILC 200 IB controller or the
process data preprocessing.
ProConOS can process up to 16 events.
System tasks can be used as start, stop, and error tasks. For example, a
program can only be processed if the control system has been started, in
order to initialize the array data types.
System tasks are not monitored by a watchdog, as they are not used
permanently.
System program numbers (SPG number) are transferred to the system
task, which characterize the event and indicate when the system task is to
be started. SPG1 for instance is run if the control system undergoes a cold
restart. The system program numbers can be found in the online help or in
the PROGRAM WORX User Manual.
Event task
System task
4.2.5.5
Task Scheduling
Task scheduling defines the control of the capacity of a processor. This also
includes the assignment of individual tasks after a specific time. Task scheduling is
used to fully utilize the resources of a processor.
The quasi-parallel execution of tasks at different times is one of the main features
of PC WORX. This is possible by using the multitasking operating system
ProConOS.
Figure 4.25 shows the principle of task scheduling in an example. Four tasks with
different interval times share the processing power in order of priority.
Task
priority
Task 1
Priority: 0
Interval: 10 ms
T1
T1
T1
T1
T1
EVENT task
Priority: 1
Task 2
Priority: 2
Interval: 5 ms
T2
DEFAULT
DEFAULT task
T2
T2
DEFAULT
10
15
DEFAU
20
Figure 4.25: Task scheduling in PC WORX
25
T2
DEFAU
30
35
DEFAU
DEFAU
40
45
t / ms
202
The priority levels of user tasks are always greater than the priority levels of default
tasks. Figure 4.26 shows the classification of the priority of different task types in
ProConOS.
Priority
Monitoring task
User task
Default
task
ProConOS
task
System task to determine errors during

runtime. Relevant system tasks are
activated by monitoring task.
All tasks configured by the user are

included in the user tasks: cyclic task,
default task, event task, and system task.
Special user task with lowest priority

(free running task).
Combination of all ProConOS-specific tasks:

communication task, debug task, memory
management task, and system control task.
Figure 4.26: Priority levels of tasks in ProConOS
4.2.6 Program-specific Elements in PC WORX

4.2.6.1
Arrays, Matrixes, Structures, Nesting
For high-level languages it is possible to form other data types from simple data
types. PC WORX permits combined data types such as fields (ARRAY) and
structures (STRUCT).
Fields and structures are created in the project tree of PC WORX with the
DATA TYPES.
Fields (Arrays)
Declaration:
TYPE
(*Type name*) : ARRAY [(*From..to*)] OF (*DATA TYPE*);
END_TYPE
203
Example:
Task: An array with 10-word elements is to be created.
Solution:
TYPE
WORD_10 : ARRAY [1..10] OF WORD;
END_TYPE
Structures (STRUCT)
Declaration:
TYPE
(*Typename*):
STRUCT
(*Element 1 Name*):
(*Element 2 Name*):
(*Element 3 Name*):
(*
. :
. *)
(*
. :
. *)
(*Element n Name*):
END_STRUCT;
END_TYPE
(*DATATYPE*);
(*DATATYPE*);
(*DATATYPE*);
(*DATATYPE*);
Example:
Task: A structure with the elements NAME: Data type STRING, Zip code: Data
type INT and LOCATION: Data type STRING is to be created.
TYPE
Person :
STRUCT
NAME
:
Zip code
:
LOCATION :
END_STRUCT;
END_TYPE
STRING
INT
STRING;
204
4.2.6.2
Data Types in PC WORX
Elementary data types, which are defined in IEC 61131-3 and which can be used
in
PC WORX.
Table 4.26: Data types in PC WORX
Data Type
Description
BOOL
SINT*
INT
DINT
Boolean
8-bit integer
Integer
Double integer
USINT*
8-bit integer
without sign bit
Integer without
sign bit
Double integer
without sign bit
Floating-point
number
UINT*
UDINT
REAL
Size in
Bits
1
8
16
32
Range
Default Start
Value
0
0
0
0
0...1
-128...127
-32768...32767
-2.147.483.648 to
2.147.483.647
0 to 255
16
0 to 65535
32
0 to 4.294.967.295
32
-3.402823466 E+38 to
-1.175494351 E-38 and
+1.175494351 E-38 to
+3.402823466 E+38
0... 4.294.967.295
0...255
(16#00...16#FF)
0...65.535
(16#00...16#FFFF)
0...4.294.967.295
(16#00....16#FFFFFFFF)
0.0
TIME
BYTE
Time
8-bit string
32
8
WORD
16-bit string
16
DWORD
32-bit string
32
T#0s
0
0
0
The data type STRING may be an elementary data type, but it has a special
position, as is shown in the following.
The data type designation is an important piece of information for IEC blocks. A
supplier of blocks can only permit function blocks/functions for specific data types.
The character description of the block details the supported data types. Table 4.27
shows the data types used with PC WORX.
This data type is not available in PC WORX 2.0x or earlier. It is only implemented in
PC WORX 3.0x or later.
205
Table 4.27: Hierarchy of general data types for PC WORX

ANY
ANY_NUM
ANY_REAL
REAL
ANY_INT
DINT
UDINT
INT
UINT
SINT
USINT
All data types permitted

Numeric data types
REAL data types (floating-point number)
INTEGER data types (integer)
ANY_BIT
DWORD
WORD
BYTE
BOOL
Bit data types
STRING
TIME
User-defined data types
Array
Struct
Character string
Time data type
Combined user data types
The String Data type

The string data type in PC WORX by default occupies 85 bytes or can store 80
characters, since 5 bytes are used as header information.
String: Header | Character string | ZERO
The header is made up of two 16-bit values. The maximum length of the string
minus 80 is entered in the first word. This means that a standard string can be zero
in the first word. Maximum length (80) 80 is zero. The length of the real character
string is entered in the second word. The final ZERO at the end of the string
indicates the end.
Example: The standard string contains the text "Hello".
0x0000 | 0x0005 | 'H' | 'e' | 'l' | 'l' | 'o' | 0x00
The PC WORX user has the option of declaring personalized string data types.
This is done in the data type directory in the project tree of PC WORX. The
declaration must be as follows:
TYPE
(*Typename*):STRING((*String length*));
END_TYPE
Example: A string of length 40 is to be created.
206
TYPE
STRING_40: STRING(40);
END_TYPE
If this string contains the text "Hello", the following image is created in the
ProConOS memory:
0xFFD8 | 0x0005 | 'H' | 'e' | 'l' | 'l' | 'o' | 0x00
4.2.6.3
Instructions in ST
Instructions can be used in ST program codes in accordance with Table 4.28.

Table 4.28: Instructions in ST
Key Word
IF
RETURN
CASE
FOR
Code Example
IF x < y THEN
a:=1;
ELSIF x=y THEN
a:=2;
ELSE
c:=3;
END_IF;
RETURN;
CASE x OF
1:
a:=1;
2..3: a:=3;
4:
a:=4;
b:=1;
ELSE a:=0;
END_CASE;
FOR x:=1 TO 5 BY
1 DO y[x] :=a;
END_FOR;
WHILE
WHILE b > 1 DO
b:= b/2;
END_WHILE;
REPEAT
REPEAT a := a*b;
UNTIL a<10000
END_REPEAT;
EXIT
EXIT;
Description
Conditional execution: An instruction is only
executed if the assigned Boolean expression "x<y" is
TRUE. If the condition is FALSE, either no instruction
is executed or the group of instructions that follow
ELSE are executed.
Return instruction: The called function, called

function block or the called program are exited
immediately.
Selection instruction (jump bar): A group of
instructions is executed according to the value of the
expression that follows the keyword CASE. The
variable or expression "x" must be data type INT.
Repeat instruction (For loop): A group of instructions

is executed again, variable "x" is increased by one,
always starting at one. Once the value of x has
reached "10", the For loop is stopped. All values
must be data type INT.
Repeat instruction (While loop): The expression b>1
is evaluated before each possible entry into the body
of the loop. If there expression is FALSE, the loop is
executed.
Repeat instruction (Repeat loop): A group of
instructions is executed repeatedly until the assigned
Boolean expression "a<10000" is TRUE. The
condition of the instruction is at the end of the body
of the loop. If the condition is FALSE, the loop is
carried out at least once.
EXIT instruction. The EXIT instruction is used to
interrupt a repeat instruction.
4.2.6.4
207
Task Info - Capacity of ProConOS Task (s)
The task info is a useful tool, which is used to obtain runtime information of the
individual tasks. The processing time of the program(s) can, for example, be
determined via the task info.
The required data types are already set up under the data types in PC WORX by
way of default:
TYPE
Task_Name_Type: ARRAY[0..9] OF BYTE;
Extended_Task_Info :
STRUCT
TaskName
: Task_Name_Type; (* Name of the Task as ARRAY OF BYTE,
ZERO terminated *)
TaskPrio
: INT; (* Priority of the task *)
undocumented_0
: INT;
TaskPeriod
: INT; (* Period of the task in milliseconds *)
TaskStack
: INT; (* Stack size of the task *)
unused_1
: INT;
TaskWatchdog
: INT; (* Watchdog time in milliseconds *)
undocumented_2
: INT;
undocumented_3
: INT;
undocumented_4
: INT;
CurDuration
: INT; (* Current task duration in ticks including preemption *)
MinDuration
: INT; (* Minimum task duration in ticks including preemption *)
MaxDuration
: INT; (* Maximum task duration in ticks including preemption *)
undocumented_5
: INT;
CurDelay
: INT; (* Current task delay in ticks including preemption *)
MinDelay
: INT; (* Minimum task delay in ticks including preemption *)
MaxDelay
: INT; (* Maximum task delay in ticks including preemption *)
END_STRUCT;
END_TYPE
Corresponding variables with this data type are preassigned under the name
PLC_TASK_1..16 for global variables in the global variable editor
(Global_Variables).
To view the content of these variables, you must use the watch list. In
Debug mode, the variable can be copied to the watch list using the context
menu of the variable in the variable worksheet. There you can open userdefined data types.
In versions of PC WORX earlier than Version 3.x, the task info was not yet
enabled by default. This can be done using the PWX20(0,1,2)V(E,D).ini
file in the Windows directory. Under section [PLCPG], the entry
TaskInfoSupported=1 must be added.
The assignment of defined tasks to describe PLC_TASK_1..16 depends
on the priority of the task. In PLC_TASK_1, for example, the task is stored
as being high priority.
208
The conversion of a PC WORX INTERBUS application requires knowledge of IEC

languages and the programming environment. Programming examples with
comments on the different topics, which make the introduction process easier can
be found on the accompanying CD.
4.2.7 Practical Tips

Tip: Use matrixes with PC WORX
(* Matrix with 10 rows and 10 columns *)

TYPE
ROW
: ARRAY[1..10] OF WORD;
MATRIX : ARRAY[1..10] OF ROW;
END_TYPE
Tip: Use user-created functions/function blocks as the protected library in PC
WORX
PC WORX 2.0x: Compile the project with tested blocks. Delete all POUs, which are
no longer required, and the hardware tree and code worksheets of the blocks to be
protected. Save project as library and call as library in new project.
Tip: Assign update time of global variables to a specific task
PC WORX 2.0x: In the global variable explorer, from the context menu of the
resource in the hardware tree, you can call menu item "Select Task ". All
available tasks are listed in a drop-down menu. The task shown here is used to
update all global variables (VAR_EXTERNAL).
PC WORX 3.0x: A selection is no longer possible. All global variables are updated
by the DEFAULT task.
Tip: Display system reserves
The control dialog box (PC WORX 2.0x) or project control dialog box (PC WORX
3.0x) in PC WORX is used to operate the ProConOS control system. Use the Info
button to view up-to-date information of the current project (project name, available
memory on the control system, current CPU capacity, cycle time of DEFAULT task,
etc.).
Tip: Constants in PC WORX
Constants in the programming environment, syntax: Data type#Value basis#Value

Examples:
Binary:
Octal:
Decimal:
Hexadecimal:
BYTE#2#0000_1111
BYTE#8#6743
BYTE#120
BYTE#16#FEAF
Time:
209
TIME#5s
Note: No value basis is given for the decimal constant.

Tip: Use library BIT_UTIL
PC WORX already has a library in the firmware library directory with useful
functions. Every user should call this library for his project.
Path (PC WORX 2.0x): pcworx2 / MWT / PLC / FW_LIB / BIT_UTIL / Bit_Util.fwl
Path (PC WORX 3.0x): pcworx3 / MWT / PLC / FW_LIB / BIT_UTIL / Bit_Util.fwl
Tip: Programming techniques in PC WORX
Programming a PC WORX program is different to programming a conventional

PLC. The user should not try to copy the model of the conventional PLC in PC
WORX, but should apply the benefits of the system.
We would not recommend that you create a program (this program is often called
OB 1) and that you call all function blocks and functions from this program. It is
better to use several programs for different tasks (multitasking operating system) in
order to optimize the different runtimes of tasks for the application process. A slow
task, for example, can be used to detect analog values and a fast task for quick
response times in the I/O area.
When creating user-defined data types, the benefits of IEC can also be fully
utilized. A structured data management system can therefore be stored on the
control system using fields and structures.
When creating separate function blocks, we recommend using the programming
language ST, as it represents the most powerful language of all IEC languages.
Loop, condition, and repeat instructions can be programmed very easily. Other
programming languages pose a bigger problem or cannot even be used. Usercreated function blocks can then be called in a graphic programming language, in
order to obtain a better overview.
210
4.2.8 Questions for the "Programming Using PC WORX"

Section
1. What components make up a POU?
2. Which programming languages are supported by PC WORX?
3. Can function blocks be called in functions?
4. How can a data block of a conventional PLC control system be reproduced in
PC WORX?
5. What is the meaning of instantiation?
6. What task types are available in PC WORX?
7. What does the string "Hello" look like in the ProConOS memory? This is a
standard string.
8. The variables Lock_1: BOOL (VAR_EXTERNAL) and Lock_2: BOOL
(VAR_EXTERNAL_PG) are declared in a program. Does a function block,
which is called in this program, have access to both variables?
The answers to the questions for the "Programming INTERBUS Controller

Boards in PC WORX" section can be found on the accompanying CDROM.
211
4.3 Programming S7 INTERBUS Controller Boards

This section only covers SIMATIC S7 controllers from Phoenix Contact. The main
focus is on one board for the S7 300 controllers and one for the S7 400 controllers.
An S7 controller has been selected from the wide range of INTERBUS PLC
controller boards, as it widely known throughout the German automation market.
The conventional PLC is still the industrial standard in some areas of automation
technology. Ethernet additions to the PLC systems ensure that PLCs take a further
step forwards in today's modern world of technology. Controller boards for PLC
systems are also fitted with an Ethernet connection, which is used to create an
Ethernet network amongst several controller boards.
Table 4.29 lists the INTERBUS controller boards from Phoenix Contact that are
available for S7 systems. Further details of the selected boards can be found
below.
Table 4.29 Overview of S7 controller boards from Phoenix Contact
S7
System
S7 300
S7 400
INTERBUS S7 Controller Board IBS ...

IBS S7 300 BC-T
IBS S7 300 DSC-T
IBS S7 400 DSC/I-T
IBS S7 400 ETH DSC/I-T
4.3.1 IBS S7 300 DSC-T

The S7 300 DSC-T controller board is fully compatible with the Siemens
SIMATIC S7 300 controller. It is an extension of the basic version IBS S7 300
BC-T with the following additional functions: data preprocessing, synchronous
mode (asynchronous with synchronization pulse), operation of parameter channel
(PCP), and extended parameterization via CMD.
4.3.1.1
General Data
Permissible CPU types: CPU 313 to CPU 318
Data interface to host system: SIMATIC S7 300 I/O

bus
INTERBUS interface: 9-pos. D-SUB remote bus

output; complete G4 master
Address areas in control system: I/O area, bit

memory and data block areas
Occupied analog address area: 16-byte input

area and 16-byte output area
Figure 4.27:IBS S7 300
DSC-T
212
4.3.1.2
Hardware Slots in the Rack
The base address of the INTERBUS master controller board is taken from the slot
system of the S7 300 environment, see Figure 4.28. The S7 300 controller is roworiented with a maximum of four rows (rows 0 to 3). The column is used for the slot
number of the rack.
The S7 300 DSC-T controller board can be used in rows 0 to 3 in slots 4 to 11. It is
integrated as a hardware component from the hardware catalog of Step 7
software: FM353 F.STEPPER MOTOR (6ES7 353-1AH00-0AE0). The controller
board occupies one slot in the analog address area of the S7 controller (16 bytes
of inputs and 16 bytes of outputs).
The number of S7 300 DSC-T controller boards depends on the

performance of the rack power supply unit. The current consumption of
the S7 300 controller board is usually 300 mA for an operating voltage of
24 V.
PS
PS
IM
3
Row
IM
3
PS
PS
1
CPU
2
IM
3
IM
3
10
11
640
656
672
688
704
720
736
752
10
11
512
528
544
560
576
592
608
624
10
11
384
400
416
432
448
464
480
496
10
11
256
272
288
304
320
336
352
368
Slot number
Analog address
Column
Figure 4.28: Slot system of S7 300 environment
4.3.1.3
IBS S7 300 DSC-T Data Areas Within the S7
The data area of the S7 300 controller is divided roughly into two areas, the digital
and the analog address area, see Figure 4.30. The lower address area (addresses
0 to 127) of the S7 controller is copied upon every S7 cycle, using special system
calls, into a separate memory area, the PII, PIO area (PII/PIO: process image of
inputs/outputs). This area is preferred for digital hardware cards, as bit-by-bit
213
access is possible. Addresses in the analog area can only be accessed via load
and transfer commands.
Data is exchanged between the S7 controller and the INTERBUS controller board
in the PII/PIO area via driver blocks from Phoenix Contact. The standard registers
in the analog address area can be accessed directly via the analog address.
The following data areas are available for the exchange of information between the
S7 controller and the S7 300 INTERBUS controller board:
-
PII/PIO (address 0 to 127)
Data blocks
Bit memory
Analog area (16 bytes for the INTERBUS standard registers and the
communication register).
Figure 4.29 gives a graphical representation of the various areas.

Data block area
INTERBUS
input area
(maximum of
512 bytes
of inputs)*
Bit memory area
INTERBUS output
area
I/O area
(process image)
(maximum of
512 bytes of
outputs)*
* Firmware 4.6 or earlier
Figure 4.29: Addressable areas of the SIMATIC S7 300

The address areas are set using the CMD configuration software as data records.
Different data areas can be used at the same time for this (PII/PIO, data blocks, bit
memory).
214
768, maximum*
752
736
Slot 11/row 3
Slot 10/row 3
304
288
272
256
analog area
.
.
.
.
Slot 6/row 0
Slot 5/row 0
Slot 4/row 0
Reserved
digital area
128, maximum*
PII/PIO (process image of
inputs/outputs)
Data blocks
Bit memories
0
*The size of the process image and of the analog
area is dependent on the CPU
Figure 4.30: Data areas of the S7 300 controller

4.3.1.4
Division of Analog Address Area (INTERBUS Standard

Register)
The analog address area of the S7 300 controller is determined via the slot in the
rack of the S7 system, see 4.3.1.2. The analog area contains the INTERBUS
standard registers (a detailed description of these registers can be found in 3
"Diagnostics") and the communication register. Figure 4.31 shows the division of
the analog area.
Offset to base
address
Offset to base
address
IN area
15
12
10
8
6
4
2
0
Communication register (4 bytes)

Reserved (2 bytes)
Standard function status register (2 bytes)
Standard function parameter register (2 bytes)
Standard function start register (2 bytes)
Diagnostic parameter register (2 bytes)
Diagnostic status register (2 bytes)
OUT area
15
12
10
8
6
4
2
0

Reserved (2 bytes)
Reserved (2 bytes)
Standard function parameter register (2bytes)
Reserved (2 bytes)
Reserved (2 bytes)
Figure 4.31: Position of INTERBUS standard registers in the analog area S7 300
The communication register is used as an interface for the driver blocks.

This register must not under any circumstances be overwritten.
4.3.1.5
215
I/O Data Traffic via Driver Blocks
Data is only exchanged between the controller board and the S7 300 system via
the driver blocks.
OB 100
FC 20
INIT_IB
OB 1
FC 24
IB_DIAG
IBDB
FC 21
MEM_READ
Application
FC 25
IB_SERV
FC 27
IB_FUNCT
FC 22
MEM_WRIT
Figure 4.32: Driver blocks in asynchronous mode of operation S7 300

Figure 4.32 shows a typical driver constellation in asynchronous mode.
When starting up the controller (OB 100), driver block FC 20 is called. This block
synchronizes the controller board with the S7 system and enters important
operating parameters into the INTERBUS data block. These operating parameter
are used by other INTERBUS function blocks.
The cyclic program part (OB 1) must at least include the functions FC 21
"MEM_READ" and FC 22 "MEM_WRITE".
Function FC 21 reads consistent data blocks (data records) from the controller
board and copies them to the specified destination area of the S7 controller.
216
Function FC 22 writes consistent data blocks (data records) from the specified
address area of the S7 controller to the specified destination area of the controller
board.
Function FC 21 should be called at the start of the cyclic program part

(OB 1) and FC 22 at the end.
It is sufficient to use the three blocks FC 20, FC 21, and FC 22 for basic
communication with the controller board (reading and writing INTERBUS process
data). Only blocks FC 24, FC 25, FC 27, and FC 28 enable you to operate all
functions of the INTERBUS system.
An overview of the driver blocks and a brief description can be found in Section
4.3.2.5. More detailed information about the INTERBUS operating mode
"Asynchronous with synchronization pulse" can be found in this section.
4.3.2 IBS S7 400 DSC/I-T

The S7 400 DSC/I-T controller board is fully compatible with the Siemens
SIMATIC S7 400 controller. It is the base board for S7 400 controllers.
INTERBUS functions are identical to those of the IBS S7 300 DSC-T controller
board.
4.3.2.1
General Data
Permissible CPU types: no restrictions
Data interface to host system: SIMATIC S7 400 P

bus
INTERBUS interface: 9-pos. D-SUB remote bus

output; complete G4 master
Address
area
in
controller:
Complete
SIMATIC S7 400 address area. These can be
divided into several coupling area with up to 512
bytes.
Figure 4.33: IBS S7 400

DSC/I-T
4.3.2.2
217
Slot Assignment of S7 400 Controller Board
Slot
10
11
12
13
14
15
16
17
18
10
11
12
13
14
15
16
17
18
UR 1
Universal rack
Slot
UR 2
Universal rack
Slot
ER 1
Expansion rack
Slot
Permissible slots
ER 2
Expansion rack
In direct I/O mode, the controller board can only be operated in the universal rack.
Extended I/O mode is possible in the universal and expansion rack.
Figure 4.34: Permissible slots in S7 rack

Figure 4.34 shows the permissible slots for the INTERBUS S7 400 master
controller board. Two slots are occupied by the controller board in a universal or
expansion rack.
4.3.2.3
Address Area of the SIMATIC S7 400
The usable I/O address area of the SIMATIC S7 400 is dependent on the CPU
being used. It is divided into an input and output address area, in which the I/O
boards are located. Figure 4.35 shows the division of the address area.
n
128*
127*
Input area of
control system
PII (inputs)
process image of
inputs
128*
127*
Output area of
control system
PIO (outputs)
process image of
outputs
* The process image of the inputs and outputs

always starts at address 0.0. Its size is
dependent on the CPU used (128 bytes,
minimum; 1024 bytes, maximum)
Figure 4.35: Address area of the SIMATIC S7 400
218
Of particular importance is the process image of the inputs and outputs (PII/PIO).
Within it, system-internal routines are used to automatically copy the input and
output signals to this process image before calling OB 1 or after finishing OB 1.
During the execution of OB 1, the input signals remain unchanged.
PII/PIO is preferred for digital I/Os, since bit operations are permitted here. In
addition to the PII/PIO, only byte or word access is permitted, so that the analog
values are stored here as usual.
4.3.2.4
Operating Modes
The DIP switch on the controller board is used to set the operating mode of the I/O
data traffic. The following operating modes can be selected using the DIP switches:
-
Test mode: This operating mode is used to test the INTERBUS devices. The
connected I/O device is automatically read after a power up or reset and
attempts are made to start INTERBUS. The device numbers and INTERBUS
addresses are automatically assigned in test mode. A project that has been
saved on the parameterization memory of the controller is not used. For this
operating mode there is no acknowledgment of PLC addresses, which means
that inputs cannot be read and outputs cannot be written.
Direct input/output mode: In this operating mode, the user is provided with up
to 4 coupling areas (designation of S5 adapter for the S7 400 board). The I/O
data is exchanged directly between the S7 controller and the INTERBUS
controller board without the use of any special INTERBUS driver blocks.
Extended input/output mode: In this operating mode, the I/O data is transmitted
via special INTERBUS driver blocks to bit memory areas or data blocks of the
S7 controller. The S5 adapter is no longer used on this occasion. This
operating mode is identical to that of S7 300 controller boards.
4.3.2.4.1 Direct Input/Output Mode
The following 4 coupling areas are provided in this operating mode: P, Q, IM3, and
IM4. The areas are to be addressed separately as P, Q, IM3 or IM4 or as P/Q or
IM3/IM4 combinations. Figure 4.36 shows the coupling areas in direct mode.
219
Address area of S7
controller
n
Communication register
IBS S7 400 DSC/I-T
I/O area (MPM)
2E
1E
Coupling areas
(S5 adapter)
4 bytes
124 bytes
Q / IM4 **
Q / IM4 **
128 bytes
128*
127*
4 bytes
124 bytes
P / IM3 **
Process image
P / IM3 **
128 bytes
0
* Dependent on the CPU used
** Dependent on the DIP switch
Figure 4.36: Coupling areas in direct mode

The top four bytes of each coupling area are reserved for the communication
register of the INTERBUS controller board. This area must not be overwritten by
I/O data.
The S5 adapter only permits data blocks of a maximum of 128 bytes to be copied.
This is why a coupling area is usually addressed to two different areas in the S7
address area. The communication register is also copied separately to the S7
address area.
The communication register must be assigned outside the process

image.
As Figure 4.36 shows, areas 1E and 2E can still be used. Which areas are these?
1E and 2E are memory areas on the controller board, which each contain 256
bytes. There is no direct mapping in the S7 system, so that the I/O data is
exchanged with the controller via special driver blocks from Phoenix Contact.
220
Where a coupling area is used by a controller board, the coupling area is then
reserved exclusively for this controller board. This produces a maximum number of
4 controller boards in direct I/O mode.
Address area of S7
controller
Coupling areas
(S5 adapter)
Maximum of 504 bytes

of I/O data per
controller board
Maximum of 252 bytes

of I/O data per
controller board
4 bytes
124 bytes
IM4
IM4
128 bytes
IM3/IM4
4 bytes
124 bytes
IM3
IM3
128 bytes
4 bytes
124 bytes
Q
128 bytes
128*
127*
P/Q
4 bytes
124 bytes
P
Process image
P
128 bytes
0
* Dependant on CPU used
Figure 4.37: Number of controller boards in direct mode

Figure 4.37 shows, that a maximum of 4 controller boards can be used in direct
mode. Each of the 4 controller boards is given a different coupling area. The
maximum number of I/O data per controller board varies depending on the number
of supported coupling areas per controller board. Where 4 controller boards are
used, each can map a maximum I/O data area of 252 bytes in the S7 address
area. For 2 controller boards in the coupling area combination P/Q or IM3/IM4,
each controller board maps 504 I/O bytes in the S7 address area.
Function blocks of the controller board in direct I/O mode:
In this operating mode, only the initialization block is required in the asynchronous
mode. It synchronizes the controller board with the S7 system when the controller
is started up.
FC 20
INIT_IB
OB 100
221
IBDB
Figure 4.38: Essential driver calls in asynchronous mode

The remaining blocks can be added as an option.
4.3.2.4.2 Extended Mode
In this operating mode, the I/O data is transmitted via driver blocks to data blocks
or bit memory areas of the S7 controller (like with the S7 300 controller board), see
Figure 4.38.
The controller board must be integrated as S7 hardware components from the
hardware catalog: FM 451 FIXED SPEED POS (6ES7 451-3AL00-0AE0). It
therefore occupies 24 bytes of I/O in the analog area of the S7 400 controller.
The analog area contains the INTERBUS standard registers (a detailed description
of these registers can be found in Section 3 "Diagnostics") and the communication
register.
Figure 4.39 shows the division of the analog area. This operating mode is identical
to that of the S7 300 controller board.
Offset to base
address
Offset to base
address
IN area
15
12
10
8
6
4
2
0

Reserved (2 bytes)
Standard function status register (2 bytes)
Diagnostic parameter register (2 bytes)
Diagnostic status register (2 bytes)
OUT area
15
12
10
8
6
4
2
0

Reserved (2 bytes)
Reserved (2 bytes)
Reserved (2 bytes)
Reserved (2 bytes)
Figure 4.39: Position of INTERBUS standard registers in the analog area S7 400
The communication register is used as an interface for the driver blocks.

This register must not under any circumstances be overwritten.
Software drivers are used to read or write data records created in bit memory
and/or data blocks using CMD. For the S7 300 controller, it was possible to use bit
memories, data blocks, and the I/O area. Only bit memories and data blocks are
permitted here.
222
Figure 4.40 shows the addressable areas of the S7 400 controller board.
Data block area
INTERBUS
input area
(maximum of
512 bytes of
inputs)*
Bit memory area
INTERBUS output
area
(maximum of
512 bytes of
outputs)*
* Firmware 4.6 or earlier
Figure 4.40: Addressable areas of the SIMATIC S7 400

The driver blocks to be used are identical to those of the S7 300 controller board,
and details can be found in 4.3.1.5. The note relating to the INTERBUS operating
mode "Asynchronous with synchronization pulse" also applies to the S7 400
controller.
The number of S7 400 DSC-T controller boards in extended operating

mode depends on the performance of the rack power supply unit. The
current consumption of the S7 400 controller board is usually 900 mA for
an operating voltage of 5 V.
4.3.2.5
223
Overview of S7 Standard Blocks
OB 100
FC 20
INIT_IB
Initialization FB
OB 1
FC 24
IB_DIAG
INTERBUS diagnostic
function block
IBDB
INTERBUS data block
FC 21
MEM_READ
Reads consistent data
blocks
Application
Application
FC 25
IB_SERV
Operates parameter
channel
FC 27
IB_FUNCT
Executes parameterized
user functions
FC 28
IB_SYNC
Asynchronous with
synchronization pulse
FC 22
MEM_WRIT
Writes consistent data blocks
These blocks are included in the

driver software from Phoenix
Contact.
S7 system blocks
Figure 4.41: Overview of IBS S7 400 DSC/I125-T standard blocks
224
Figure 4.41 details the standard blocks from Phoenix Contact, see Table 4.30. The
InfoService section on the Phoenix Contact homepage provides a selection of
additional function blocks for the various application purposes. For example, an
even more powerful diagnostic module is available, the FC 126 (DEVMOD). This
block is responsible for the diagnostics and error acknowledgment of the
INTERBUS system and provides easy switching and jumpering of INTERBUS
devices. Faulty INTERBUS devices can be automatically disconnected from FC
126, if the DEVMOD has already been parameterized.
Table 4.30: Brief description of standard function blocks
Standard Function
Description
FC 20: INIT_IB
This block synchronizes the INTERBUS controller board with the S7
system and enters important operating parameters into the
INTERBUS data block. These operating parameter are used by
other INTERBUS function blocks.
FC 21:MEM_READ
The function FC 21 reads consistent data blocks (data records) from
the controller board and copies them to the specified destination
area of the S7 controller.
FC 22:MEM_WRIT
Function FC 22 writes consistent data blocks (data records) from the
specified address area of the S7 controller to the specified
destination area of the controller board.
FC 24: IB_DIAG
This block is used so that the INTERBUS user can manually or
automatically acknowledge INTERBUS errors.
FC 25: IB_SERV
This block enables the PCP and PNM7 channel to be used, i.e., the
parameter channel. Only through using this block can the user
operate the parameter channel.
FC 27: IB_FUNCT
The configuration software CMD enables the user to create user
functions. These may be complex firmware commands, which are
pre-parameterized and launched via a bit in the MPM. Use the
Configuration -> IB Function Blocks menu to create these user
functions.
The FC 27 block can be used to process such user functions.
FC 28: IB_SYNC
The asynchronous mode of the INTERBUS system is not sufficient
for some applications, since the data consistency for the present
application process is insufficient. In this case, you should use
synchronous modes. The FC 28 block should be used for
"Asynchronous with synchronization pulse" mode.
4.3.2.6
Driver Call for "Asynchronous with Synchronization Pulse"

FC 28
IB_SYNC
OB 1
225
OB 40
FC 28
IB_SYNC
FC 50
FC 21
MEM_READ
FC 51
FC 22
MEM_WRIT
IBDB
OB 40
FC 28
IB_SYNC
Figure 4.42: Call structure in "Asynchronous with synchronization pulse" mode

"Asynchronous with synchronization pulse" mode is a synchronous mode, which
has been covered in some detail in 1 "Basics". To achieve data consistencies
greater than 16 bits, it is also required in the S7 system. Figure 4.42 shows the call
structure of the INTERBUS drivers in an S7 system.
The FC 28 waits in OB 1 for a synchronous interrupt of the controller board once
the bus cycle has been completed. Following the branching to the OB 40, an
acknowledgment of the synchronization process is sent to the controller board by
FC 28. Blocks FC 50 and FC 51 ensure consistent transmission of I/O data.
4.3.2.7
Starting Up S7 Controller Boards
A description of how to start up the controller boards is not included in this section,
as this information can be found in the standard literature from Phoenix Contact.
For a quick introduction, please refer to the Quick Start Guide, which gives a brief
introduction to the startup process (practical tips). For a full introduction, please
refer to the driver software user manual.
User Manual
Quick Start Guide IBS S7 300 DSC-T [26]
Quick Start Guide IBS S7 400 DSC/I-T [27]
User manual for controller board driver software for Siemens SIMATIC S7
300 controllers [28]
User manual for controller board driver software for Siemens SIMATIC S7
400 controllers [29]
226
The listed user manuals and corresponding driver software can be
downloaded from the download area of the InfoService on the Phoenix
Contact homepage.
Practical tip: Application examples are given in the IBS S7-300 UM E and
IBS S7-400 UM E User Manuals on the supplied disk. These examples are also
available on the Phoenix Contact homepage. The examples are provided in the
form of executable programs, which make the whole setup process easier.
I/O data transport in asynchronous bus mode
I/O data transport in asynchronous with synchronization pulse bus

mode
PCP communication via the IB_SERV (FC 25) driver
PCP communication via the IB_FUNCT (FC 27) driver
4.3.3 Questions for the "Programming Using S7 Controller

Boards" Section
1. What is the maximum number of controller boards that can be used in the
direct mode of an S7 400 controller board in an S7 system?
2. An operator interface with a 64-bit process data width should be used with an
S7 300 DSC-T controller board. The MMI-COM protocol mapped on the
process data only functions correctly if there is data consistency across all 64
bits. Which operating mode and function block should be used to operate the
controller board?
3. Can two controller boards be used at the same time in direct mode and two
controller boards in extended mode?
The answers to questions for the "Programming INTERBUS Controller

Boards in S7" section can be found on the accompanying CD-ROM.
INTERBUS Specialist Knowledge
227
5 NTERBUS Specialist Knowledge

This section deals with applications, programs and questions, which are not
typically used or referred to when working with INTERBUS. The topics covered
provide extensive solutions and procedures for effectively configuring and
operating INTERBUS systems.
This enables easy and user-friendly configuration and handling of INTERBUS
projects with lower-level master/slave configurations using the well-thought-out
@utomationXplorer from Phoenix Contact. The IB loader software tool, also from
Phoenix Contact, is of great use when executing INTERBUS parameterizations
without using popular software tools such as IBS CMD G4 or PC WORX.
In addition, the topic of preprocessing on INTERBUS controller boards is also
covered. This feature of G4 INTERBUS controller boards should not be
underestimated, as it ensures very fast program processing directly on the
INTERBUS master board. Preprocessing is often used to process INTERBUS input
signals quickly as well as to resend them to the INTERBUS actuators.
-
Using @utomationXplorer
Using the IB loader to execute INTERBUS parameterizations
Description of the preprocessing of INTERBUS controller boards
Tasks and functions of @utomationXplorer

Creating the SVC file for the IB loader
Calling the IB loader with various communication parameters
Process data preprocessing for standard controllers
Process data preprocessing for PC WORX controllers
Differences between sequential and parallel preprocessing
Page 228
Page 230
Page 231
Page 233
Page 234
Page 235
228
5.1 @utomationXplorer
@utomationXplorer from Phoenix Contact is a software tool used to parameterize
INTERBUS systems with lower-level INTERBUS configurations easily and
effectively. In addition, it is possible to communicate with all INTERBUS devices via
the PCP and PNM7 communication channel. Figure 5.1 illustrates an example of
an INTERBUS configuration with higher and lower-level INTERBUS with the option
of communication. @utomationXplorer acts as the communication platform from
which individual applications (IBS CMD, etc.) can be started directly.
@utomationXplorer
IBS CMD G4 (16-bit)
INTERBUS OPC
server
High-level language
application
MS Visual C++ 6.0 (32-bit)
netcfg.dat
communication
strings
Lower-level
INTERBUS
Ethernet
High-level
INTERBUS
IBS S7 400 DSC ETH
Master/slave IBS board

IBS ISA SC RI/RT-LK
Intelligent INTERBUS device
Figure 5.1: @utomationXplorer communication options

The @utomationXplorer application is particularly suitable for industrial systems
with decentral intelligence. All devices can be addressed directly and, for example,
parameter records can be uploaded or downloaded from one point.
@utomationXplorer requires the application versions listed in Table 5.1 to be
installed on the PC.
Table 5.1: Applications required for @utomationXplorer
Operating system
Windows NT 4.0 with Service Pack > 4
@utomationXplorer
Version 1.0 (22)
IBS CMD
Version 4.50 (20) or Version 4.51 (4)
@utomationXplorer stores the communication parameters for all INTERBUS

devices that can communicate in the netcfg.dat file. Therefore it is also possible for
applications not manufactured by Phoenix Contact to connect to this platform and
establish communication with INTERBUS devices.
229
5.2 IB Loader
The IB loader is an additional tool from Phoenix Contact, which can be used to
send the bus parameterization and/or PC WORX programming to the controller
board. The information to be sent must be available as an SVC file (ASCII format)
so that it can be processed by the IB loader.
Originally the IB loader was developed for INTERBUS controller boards that did not
have a parameterization memory. In practice, the IB loader is also used for
INTERBUS controller boards that have a parameterization memory to execute the
bus parameterization of a high-level language application at a specific point in time.
All available communication paths (serial, Ethernet, ISA bus, etc.) are available to
the IB loader. Even parameterization via INTERBUS (PNM7 channel) is possible.
5.2.1 Available Operating Systems

At present the IB loader supports five operating systems. Table 1.22 provides an
overview of the supported operating systems and the required files.
Table 5.2: Operating systems supported by the IB loader
Operating System
Required Files
MS-DOS
IB-Loader.EXE
Windows 3.11/95/98
IB-Loader.DLL, Ibloader.lib, IBLOAD16.EXE
Windows NT
IBLOAD32.DLL, Ibload32.lib, Ibsubc32.dll, Pri10w32.dll,
IB-Loader.EXE
The IB loader is usually provided on all IBS CMD and PC WORX

installation CDs, and can also be found on the accompanying CD-ROM
5.2.2 Structure of the SVC File

The SVC file is an ASCII file, which contains the hexadecimal codes of the
firmware services. In this file, each firmware service is enclosed by two hash
symbols. The start of each service block is indicated by #CMD#.
Example:
#CMD# ;Service start
#0x1303# ;Service code (Alarm_Stop_Request)
#0x0000# ;Number of parameters
#CMD# ;Service start
#0x0760# ;Service code (Confirm_Diagnostics_Request)
#0x0000#
230
5.2.3 Creating an SVC File

CMD/PC WORX (2.0x): In PC WORX (2.0x)/CMD, the SVC file is created via the
Parameterization Memory menu items, see Figure 5.2.
Figure 5.2: Creating the SVC file using IBS CMD of IBS PC WORX 2.0x
When creating the SVC file, the INTERBUS startup procedure, which was
assigned the boot cross under Configuration | Parameterization | Edit, is
used.
The user can decide whether to write to the controller board RAM or to the
parameterization memory via the boot project cross in the "Write SVC
File" dialog box.
PC WORX (3.0x): In PC WORX 3.0x, it is currently not possible to create an SVC

file by explicitly calling functions. The SVC files can be copied directly from the PC
WORX directory using the Windows Explorer. Figure 5.3 shows the directory
structure and the directory from which the SVC file is to be copied.
231
Figure 5.3: Path of the SVC file for PC WORX 3.0x
5.2.4 Installation of the IB Loader

The installation of the IB loader has been made very easy. The files listed in Table
5.2 must only be copied to one directory. The IB loader can be started directly from
the directory.
The DDI must be installed on the PC that starts the IB loader. PC

WORX and CMD install the DDI by default.
5.2.5 Calling the IB Loader

The IB loader can be started directly from the prompt. The command line with
optional call parameters, as shown in Table 5.3, is as follows:
IB-Loader MXI-Device-Name SVC-Filename [/V] [/S] [/T:xx] [/BRK_IB_ERR]
[/NO_KEY] [/TIMEOUT:xxx] [/PRI]
Table 5.3: Possible MXI device names for the IB loader
MXI Device Name
Mailbox Device Name (Communication Path)
IBCOM1
(COM1)
IBCOM2
(COM2)
IBB1N1_M
(MPM Node1)
IBB1N2_M
(MPM Node2)
IBETH01N1_M
(MPM Node1)
232
The IB loader also supports the management channel of the INTERBUS system.
The parameterization can be sent to a lower-level INTERBUS system. For this, the
"/PRI" option must be set and the communication reference number attached.
Example MXI device name: IBCOM1#CR02
SVC-Filename
/V
/S
/T:xx
/BRK_IB_ERR
Filename of the SVC file to be sent.

Verbose mode. After each transmission the service code is output.
Single step. A key must be pressed after each transmitted service.
Delay time in ms between transmission of the individual services.
Transmission is canceled when a negative service confirmation is
received. This excludes ProConOS on the PLC runtime system, for
which
the negative service confirmations contain status messages.
/NO_KEY
When an error has been detected, the program does not wait for a
key
to
be pressed. This excludes errors during parameter transfer.
/TIMEOUT:xxx Maximum waiting time in ms for a service confirmation.
The default value is 60,000 ms, value range of 50 ms to 65,000
ms.
/PRI
Procedure Interface. This option must be set if a 32-bit application
is
running in parallel to the IB loader with the controller board or if the
services are to be sent to a lower-level INTERBUS system.
5.2.6 IB Loader Error Messages

All error codes that are specifically generated by the IB loader are listed in Table
5.4. For the DDI error codes, which also appear in the output window, please refer
to the "Firmware Services and Error Messages" [14] User Manual from Phoenix
Contact.
Table 5.4: IB loader error messages
Error Code in hex Error Code
0x00
ERR_OK
0x02
ERR_INV_PARAMETER
0x03
ERR_SEND_MESSAGE
0x04
ERR_EXCEPTION
0x05
0x06
0x07
ERR_LOAD_PRI_DLL
ERR_READ_STREAM
ERR_NEG_IBS_CNF
0x08
ERR_TIMEOUT
Meaning
No error
Invalid parameter transferred
A message could not be sent
Exception occurred during data
transmission
The PRI DLL could not be transferred
Error reading data from the file
Negative IBS service confirmation
received
No service confirmation received within
the specified timeout period
233
5.3 Process Data Preprocessing

Process data preprocessing (PDP) is an easy method of linking INTERBUS signals
to other INTERBUS signals or program constants. With an SC controller from
Phoenix Contact this link is not established on the host system, but is carried out
by the INTERBUS controller board between INTERBUS cycles. The advantage of
this is that the host system is offloaded and the I/O response time can be
improved, as for the most part, the bus cycle time is far below the cycle time of
some PLC systems. In general, it offers the advantage of consistent data
transmission.
5.3.1 PDP for Standard Controllers (SC)

Figure 5.4 illustrates conventional preprocessing, which is used for all standard
controllers (SC) from Phoenix Contact. The INTERBUS controller board and
application program process their process data separately from one another. Data
exchange between the host system and INTERBUS controller board takes place
exclusively via the MPM. The preprocessing task can read and write the INTERBUS
data directly from the I/O memory of the IPMS chip (INTERBUS master protocol chip)
and does not have to access the data via the MPM.
Write OUT data to
the MPM
Process image of the inputs

and outputs
Read IN data from

the MPM
Application
OUT
IN
Application
OUT
IN
Application
OUT
IN
Application
Host system
MPM
Read OUT data
from the MPM and
write it to the output
modules
Write IN data to
the MPM
IBS cycle
Master
IN
PDP
OUT
IBS cycle
IN
PDP
OUT
IPMS
I/O memory
PDP:
Preprocessing task
Application
PLC program
Figure 5.4: Conventional preprocessing (INTERBUS controller board without

coprocessor)
For all standard controllers (SC) the IBMS CMD configuration tool from Phoenix
Contact is used to configure a preprocessing task. The preprocessing task is a
ProConOS task on the M68 controller and is programmed in function block diagram
(FBD) via an IEC 61131 tool integrated in CMD.
234
The creation of variables and the programming is similar to the PC WORX

interface.
The INTERBUS cycle time is increased by the process data
preprocessing. Therefore a fixed INTERBUS cycle time should be
specified. This would be indicated by a waiting time after the PDP block in
Figure 5.4. Specifying a fixed cycle time is also required so that the
determinism of the INTERBUS system is not adversely affected. This
determinism is required for certain applications. One of the great
advantages of the INTERBUS system compared to other bus systems is
the deterministic data transmission, due to the summation frame protocol.
Remark: An INTERBUS cycle time must be specified when using process data
preprocessing.
Note: The INTERBUS cycle time is the time between the start of two INTERBUS
cycles including data transfer and preprocessing.
5.3.2 PDP for PC WORX Controllers

For PC WORX controllers a distinction is made between sequential and parallel
preprocessing. The main difference between these two methods is whether the PC
WORX task is processed during the INTERBUS cycle or between the INTERBUS
cycles.
Figure 5.5 and Figure 5.6 illustrate the two different methods, which can be
created by the user using the event number of the task property. These differences
are again summarized in Table 5.5.
IN
ProConOS
PDP
OUT
Application
Wait
IN
IRQ
IRQ
PDP
OUT
Wait
IRQ
IRQ
Master
INTERBUS cycle
Application
INTERBUS cycle
INTERBUS cycle
Cycle time of the INTERBUS

system
t
IN:
IN data of the
INTERBUS master
is read
OUT:
OUT data is
transmitted to the
INTERBUS master
Application
PLC programm
PDP:
Preprocessing task
WAIT:
Wait until INTERBUS

cycle has finished
INTERBUS
cycle
Complete INTERBUS
cycle
Figure 5.5: Sequential preprocessing

ProConOS
IN
PDP
Application
IRQ
235
Wait
OUT
IN
IRQ
PDP
Application
IRQ
Wait
OUT
IN
IRQ
Master
INTERBUS cycle
INTERBUS cycle
Cycle time of the INTERBUS

system
IN:
PDP:
IN data of the
INTERBUS master
is read
Preprocessing task
OUT:
OUT data is
transmitted to the
INTERBUS master
Application
SPS program
WAIT:
Wait until INTERBUS

cycle has finished
INTERBUS
cycle
Complete INTERBUS
cycle
Figure 5.6: Parallel preprocessing

Table 5.5: Sequential and parallel preprocessing
Sequential Preprocessing
Parallel Preprocessing
At the end of the bus cycle the ProConOS At the start of the PDP task the next INTERBUS
event task is initiated to read the cycle is started per interrupt. The PDP task and
INTERBUS IN data. The PDP task works the rest of the application run during the bus
with the new IN data and writes the cycle. After a successful bus cycle an
current OUT data to the MPM. An interrupted is generated at the host system. The
interrupt initiates the INTERBUS master current OUT data is written to the MPM and the
to start the next bus cycle with the new IN data is read from the MPM.
OUT data. The rest of the PC WORX The INTERBUS IN data is only available in the
preprocessing one bus cycle later and the OUT
application runs during the bus cycle.
data is output to the bus one cycle later.
Not all PC WORX controllers support both preprocessing types. In general, an M68
controller can only support sequential preprocessing. Both methods can be set for
IPC controllers (Event no. 0: sequential preprocessing; Event no. 1: parallel
preprocessing).
A preprocessing task is created in the PC WORX project tree under the hardware
description.
Process data preprocessing is a method used to increase the data

consistency of process data. All process data which is processed within
the preprocessing task is consistent. This applies to both standard and
PC WORX controller boards.
For an M68 target (Motorola 68332 processor processes INTERBUS

master task and ProConOS task) the process data for the
preprocessing task is read directly from the IPMS memory of the
INTERBUS master -> data consistency.
For an IPC target (ProConOS runs as a task on an Intel coprocessor
and the INTERBUS master as a task in a Motorola 68332 processor)
data consistency for the preprocessing task is achieved by initiating the
preprocessing task on the coprocessor per interrupt.
236
Distributed Control Concept
6 Distributed Control Concept

Distributed control concepts are increasingly offered as they are frequently requested
by customers. The INTERBUS system provides a very easy means of implementing
this decentral intelligence. As the scope of distributed control technology is very
wide-ranging and various distributed concepts can be implemented using the
available range of INTERBUS products, this section describes the use of a system
coupler in a higher-level INTERBUS system. This section primarily deals with the
different communication options provided by the two connected INTERBUS systems.
In this section, the ILC 200 IB Field Controller from Phoenix Contact is used as the
system coupler, as it is frequently used in practical applications.
Other system couplers can of course also be used to create a distributed control
concept, e.g., the IBS VME6H SC/RI/I-T system coupler for VMEbus systems. The
methods described in this section can be easily applied to other control systems,
as they all follow the same basic principle.
-
System couplers
The ILC 200 IB Field Controller
Typical topology of a higher-level INTERBUS system with a lower-level Field

Controller as the distributed control system
Communication options using decentral intelligence
Communication via the process data channel

Communication via the default index
Direct access to a PCP device in the lower-level INTERBUS system
Communication via variable names
Writing a local ProConOS variable
Reading a local ProConOS variable
Example of communication with PC WORX controllers
Read/write MPM via the management channel (PNM7)
Assignment of the PNM7 communication reference to a system coupler
Overview of PNM7 services
Application example for the SER request
Reading/writing slave interface OPC items
Page 239
Page 241
Page 244
Page 247
Page 251
Page 252
Page 253
Page 255
Page 256
Page 257
Page 258
Page 260
237
6.1 System Couplers

System couplers are INTERBUS controller boards, which contain a master and a
slave interface in one controller board. They are used to connect two INTERBUS
systems. Several system couplers can be used in one INTERBUS network to
create a very branched structure. Communication with the higher-level INTERBUS
system does not affect the rest of the system. Every system coupler master bus
can control machine parts independently. This means that the intelligence for
machine control has been transferred to the field decentral intelligence. The
higher-level control system is usually only responsible for data management or for
loading new recipes to the terminal blocks with decentral intelligence.
A typical application for a system coupler is, for example, the internal control of a
robot and its connection to the system network.
0.0
Higher-level control system:
RFC 430 ETH-IB controller
1.0
1.1
1.2
ILC 200 IB as
Sub master
2.0
0.0
1.0
1.1
1.2
Slave interface with

variable ID code
2.0
2.1
2.2
Remote bus branch for additional

remote bus segments
3.0
BK-T
3.0
BK-T
3.1
3.2
DO 16/3
DI 32/2
3.1
AI 4/SF4
3.2
AO 4/SF4
Figure 6.1: Topology for decentral intelligence
238
The main advantage of a distributed architecture is the improved operation of small

automation tasks, such as those of the distributed system couplers, which are
easier to operate than one large program for the entire automation complex. One
disadvantage is the communication between the higher-level and the lower-level
control system, as this is usually restricted in terms of size and transmission speed.
A typical INTERBUS topology with a master/slave system is shown in Figure 6.1.
This topology has been kept very simple, but shows the basic principle. A
master/slave controller is connected to the higher-level control system at the slave
interface and can use this interface to exchange data. The lower-level master
system (here the ILC 200 IB) can in turn create a complete master system.
The ID code, and therefore the process data width and PCP capability, should be
tailored to the specific system. The requirements for the data volumes to be
transmitted to the host system must be determined.
6.2 ILC 200 IB as Distributed Intelligence

The ILC 200 IB Field Controller is often used as a stand-alone device to provide
decentral intelligence or alternatively several controllers can be integrated to
provide separate intelligence in an INTERBUS system. These controllers are often
selected due to their attractive price and ease of operation.
Table 6.1: Basic specifications for the ILC 200 IB Field Controller
-
Automation and control functions

according to IEC 61131-3
Configuration and programming using
PC WORX
Project and program download via
INTERBUS or RS-232 interface
Preprocessing and application program
on the INTERBUS Inline Controller
INTERBUS protocol EN 50254
System coupler properties (master
and/or slave functions)
Complete range of Generation 4
functions
Comprehensive system diagnostics
Firmware download via RS-232
PCP 4.x support
Direct connection of INTERBUS Inline
I/O modules
Remote bus devices can be connected
via a branch bus terminal
Fast inputs and outputs for special
processes (2 outputs, 4 inputs)
Maximum of 10 process data words for
the slave interface
ID code 3, 232, 233 or 235 supported
Figure 6.2 ILC 200 IB
239
Fields of application of the Inline controller:

-
Modular distributed control system
Completion of fast processes locally, e.g., regulation processes
Use as an intelligent bus terminal module, e.g., for a replacement strategy

in the event of operating errors
Central compact control system
6.3 Communication Options for a Distributed Control

System
The available communication options play a very important role and can cause
some planned distributed control concepts to fail. The most important
communication options, and those used most frequently in practice, are discussed
here.
Communication options:
-
Process data channel
Parameter channel
Read/write with name (identification via variable name)
Read/write MPM via the management channel (PNM7)
OPC (read/write slave interface objects)
6.3.1 Communication via the Process Data Channel

Communication via the process data channel (PD channel) is the simplest type of
data exchange. The slave interface of the DCI controller (Decentral Intelligence
controller) is set to an ID code and the relevant process data width, so that process
data objects can be exchanged. These process data objects can be addressed by
the higher-level and lower-level INTERBUS master. One output process data item
in the higher-level system corresponds to one input process data item in the lowerlevel system. The submaster and the higher-level INTERBUS system can be
configured either using PC WORX/CMD or with the relevant firmware commands.
Figure 6.3 summarizes the key features of communication via the PD channel
(process data channel).
240
Process data for

INTERBUS device 1.0:
160 bits IN data
160 bits OUT data
Cyclic process data exchange on

every bus cycle
The slave IN data of the system coupler is the

OUT process data of the higher-level
INTERBUS master and vice versa.
1.0 ID:03 PD:160 bits 1.0

2.0
2.1
Slave process data:

160 bits IN data
160 bits OUT data
2.0
2.1
INTERBUS
devices in the
higher-level
INTERBUS
system
INTERBUS
devices in the
lower-level
INTERBUS
system
Figure 6.3: Communication via the PD channel

The firmware command for setting the ID code and the process data width of the
slave interface is a Set_Value_Request with the following parameters:
Mailbox Syntax
SET_VALUE_REQUEST
Message-Code (0x0750)
Parameter-Counter
(0x0003)
Variable-Count (0x0001)
Value
Value: Indicates the length and ID code

Example: 0x01EB | 01 : 16 bits, EB : ID code 235
The slave process data is updated and exchanged with the higher-level
control system on every INTERBUS cycle very rapid communication
process. The higher-level control system determines the update time for
the process data for the entire system.
The higher-level and the lower-level INTERBUS system usually differ in

terms of the cycle time for the I/O data. This must be taken into account
as, in some circumstances, data, which only appears for one cycle, may
not be seen by the other INTERBUS system.
241
6.3.2 Communication via the Parameter Channel

This section describes two different options for communication via the parameter
channel (PCP channel).
-
Access to the default index of the system coupler: The higher-level control
system sends requests to the lower-level system via the default index. The
lower-level system responds to these requests. The user data is contained in
the response. Data management is controlled by the subsystem application
program, i.e., the data is kept in the program memory of the system controller.
The PCP connection controls access to the data. Both systems can be
operated as clients or servers. If the higher-level system performs the client
function, the subsystem must act as the server.
Direct access to a PCP device in the lower-level system: A communication

relationship for a PCP device in the lower-level system must be added to the
CRL (communication relationship list) of the higher-level master. The higherlevel master can then treat this device as if it were a device in its own bus.
Communication via the PD channel is often preferred to communication via the PCP
channel, as the configuration is easier. Access and handling using process data
objects is far easier and quicker. For data volumes of more than ten words,
communication via the PD channel usually fails because the slave interface can only
be set to 10 words (except for the IBS ST 24 RFC-T, which can be set to 26 words).
Multiplex operation is not advisable in this case, and instead the parameter channel
should be used.
6.3.2.1
Communication via the Default Index
The firmware of the INTERBUS master controller from Phoenix Contact contains
two default indices. These indices can be used as an octet string with a length of
240 bytes. During communication, for example, the higher-level control system
(system 1) can access the default index of the lower-level system (system 2) using
a read request. The read request is detected by system 2 as a read indication.
System 2 must process the request and send back the response to system 1 as a
read response. System 1 receives this response as a read confirmation with the
desired data.
Default index: 0x5FFF and 0x5FFE, each an octet string of 240 bytes
The system coupler must be PCP-compatible and the ID code should be

selected accordingly. The following ID codes can be set for the system
coupler:
ID 3
ID 232
ID 233
ID 235
| PD channel 0 - 160 bits

| PCP channel 0 bits

242
Tip: To ensure that data is exchanged as quickly as possible, the PCP data width
should not be set too low.
The implementation is based on the use of the relevant service primitive on the
client and server side. The necessary firmware services can be sent via the host
system drivers.
In a PC WORX controller, the relevant function blocks must be used for

PCP communication: PCP_CONNECT, PCP_READ, PCP_WRITE,
PCP_CLIENT, and PCP_SERVER.
The example shown in Figure 6.4 illustrates the procedure for the INTERBUS
topology shown. The relevant service primitives are shown in the mailbox syntax.
243
The only INTERBUS device in the bus

configuration of the higher-level control system is
the ILC 200 IB controller. This device is also the
only PCP device and therefore has communication
reference (CR) 2.
0.0
Octet string of 240 bytes

Byte 1
Byte 2
...
Byte 240
Read_Write
request for
reading/
writing the
index
PCP communication via

the default index
Octet string of 240 Bytes

1.0 / CR 2
PCP_SERVER
to reply to the
indication
Byte 1
Byte 2
...
Byte 240
In this example the

ILC 200 IB only operates
local bus devices
Read request
Command_Code
Parameter_Count
Invoke_ID | CR
Index
Subindex | -
Read indication
0x0081
0x0003
0x0002
0x5FFF
0x0000
Read request
Message_Code
Parameter_Count
Invoke_ID | CR
Index
Subindex | -
Read indication
IBS System 1
IBS System 2
Read confirmation
Read response
Read confirmation
Message_Code
Parameter_Count
Invoke_ID | CR
Result (+)
- | Length
Data (1)
Data (2)
0x4081
0x0003
0x0002
0x5FFF
0x0000
0x8081
0x0005
0x0002
0x0000
0x0004
0x1234
0x5678
Figure 6.4: Communication via the default index
Read response
Command_Code
Parameter_Count
Invoke_ID | CR
Result (+)
- | Length
Data (1)
Data (2)
0xC081
0x0005
0x0002
0x0000
0x0004
0x1234
0x5678
244
In the Read_Response, the number 2 is used as the CR (Communication

Reference), although no PCP device is available in the subsystem. The
CR number refers to the slave interface of the subsystem. It is one
number greater than the highest PMS CR number. It is also a PMS
connection. For example, if CR2, CR3, and CR4 are used in the bus, the
slave interface is CR5.
A demo program for communication via the default index can be found on
the accompanying CD-ROM.
Required software: PC WORX
Project name: ETH_DI (higher-level control system), ILC_DI (lower-level
control system)
6.3.2.2
Direct Access to a PCP Device in the Lower-Level INTERBUS

System
The communication relationship list for the higher-level control system does not
contain the connection data for a PCP device in the lower-level INTERBUS system.
This is because the higher-level and lower-level INTERBUS systems are treated
separately. The INTERBUS masters are configured separately using the CMD/PC
WORX configuration tool, and it is not possible to read the other project to access
its communication relationship list. However, it is possible to reload a
communication relationship list in the startup sequence. This communication
relationship list is reloaded as a file and must adhere to a specific format. The file
contains the connection data for one or more PCP devices. The higher-level
INTERBUS system then accesses this PCP device directly via the submaster.
Figure 6.5 illustrates the problem using a typical topology.
The only device in the bus configuration of the higher-level control system is the ILC
200 IB system coupler. The system coupler is operating a PCP device at local bus
position 0.3. The aim is to create a logical PCP channel from the higher-level control
system via the system coupler to device 0.3 in the sub-bus. To do this, the higherlevel control system requires the PCP data for the PCP device in the subsystem. In
addition to standard information, such as the connection monitoring time or
supported PCP services, the position in the subsystem and the CR number are
required (routing information). Table 6.2 shows the file (a *.LLS file) for reloading the
PCP connection for INTERBUS device 0.3 in Figure 6.5.
It is not recommended that the user tries to manually configure a PCP connection.
Various tools are provided, which can perform this task more effectively. In PC
WORX Version 3.0x or later, the bus configuration of both INTERBUS systems (the
higher-level and lower-level INTERBUS system) can be mapped in one project.
The higher-level master automatically receives the information from the lower-level
bus system. For users who do not have PC WORX controller boards, the
Automation Explorer performs this function. However, @utomationXplorer is only
approved for certain types of controller board.
245
Direct access to a PCP device in the lower-level INTERBUS system is

only recommended for PC WORX controller boards or for controller
boards, which are supported by Automation Explorer.
@utomationXplorer is a configuration tool from Phoenix Contact.
Logical device number /
System number format
0.0 / 1.0.0
System number format:

System number . Segment number . Position number
D1.1.0
Direct logical connection to PCP device
1.0 / 2.0.0
PMS-CR 2 / PNM7-CR 3
1.1
1.2
1.3
D0.0.0
(CR 2) / CR 4
CR in the Submaster
Figure 6.5: Logical PCP connection via a system coupler
CR from the view of the

higher-level master
246
Table 6.2: *.LLS file

Firmware
Meaning
Command
#CMD#
#0x0200#
Initiate-Load-CRL // Initiate CRL loading // Firmware command
#0x0000#
Parameter counter
#CMD#
#0x0201
Load-CRL-Hdr // Load CRL header // Firmware command
#0x0005#
Parameter counter
#0x0004#
CR number (0 = header) | CRL entries
#0x8000#
poll-list-SAP
| ASS-CI(1)
#0x0003#
ASS-CI(2)
| ASS-CI(3)
#0xE80B#
ASS-CI(4)
| symbol-length
#0x0000#
VFD-pointer-supported
| DUMMY
#CMD#
#0x0201#
Load-KBL-PMS CR4 // PMS CR2 and PNM7 CR3 are defaults
#0x0011#
Parameter counter
#0x0402#
CR
| System number
#0x0003#
Segment number
| Position in the segment
#0x8001#
Sub-bus number (routing info)
| remote address
#0x0000#
connection type
| LLI-SAP // PMS (0) or PNM7 connection
#0x0001#
(1) connection attribute
| max. SCC
#0x0101#
max. RCC
| max. SAC
#0x0100#
max. RAC
| max. ACI(1)
#0x0000#
ACI(2)
| ACI(3)
#0x0080#
ACI(4)
| multiplier (0x80 = NIL, no meaning)
#0x0040#
max. PDU send high
| max. PDU send low
#0x0040#
max. PDU recv high
| max. PDU recv low
#0x0030#
services supported(1)
| services supported(2)
#0x009A#
#0xB081#
#0x0000#
symbol length
| VFD-pointer(1)
#0x0000#
VFD-pointer(2)
| VFD-pointer(3)
#0x0000#
VFD-pointer(4)
| DUMMY
#CMD#
Terminate-Load-CRL
#0x0202#
Parameter counter
#0x0000#
CRL entries:
Number of entries in the CRL is increased to 4. The header is CR 0.

Connection establishment monitoring time for INITIATE_REQ*10 ms
ASS-CI(1)-(4): VFDpointer-supported:
Virtual Field Device (PROFIBUS DP standard). INTERBUS only

supports one VFD (0 = disabled)
DUMMY:
Filler byte, used to create an even word limit
Remote address:
Physical PCP address, only PCP devices are counted
Connection type:
Only one master/master relationship is supported for INTERBUS

(0 = master/master relationship)
Connection attribute:
0 = Defined connection
max. SCC:
Send Confirmed Request Counter, number of parallel services

max. RCC:
Receive Confirmed Request Counter
max. SAC:
Send Acknowledge Request Counter, unconfirmed services
max. RAC:
Receive Acknowledge Request Counter
max. ACI(1)-(4):
Acyclic Control Interval, not used. (0 = deactivated, F = activated

(only supported in PCP 2.0 or later)
247
6.3.3 Communication via Variable Names

The "read/write with name" services provide direct access to a variable in
ProConOS (PLC runtime system for Field Controllers from Phoenix Contact). All
variables can be read, even fields and structures. However, the variable must be in
the PDD (Process Data Directory) of ProConOS for access to be supported.
Communication between two Field Controllers is easier, because the entire
communication is processed via the internal PCP blocks. If the controller used is
another controller type, the user must process the communication using the
read/write with name firmware services.
The read and write with name services are illustrated below in mailbox syntax. The
examples given provide details on handling using the services.
For the interpretation of error messages, refer to the PCP Reference

Manual from Phoenix Contact [13].
6.3.3.1
Mailbox Syntax for Write With Name Request
Mailbox Syntax
WRITE_WITH_NAME_REQUEST
Parameter-Counter
Invoke-ID
Communication
reference
Access-Choice
More-Follows
Variable-Name-Length
Variable-Name(1)
Variable-Name(n)
Data-Length
Data(1)
Data(n)
Invoke-ID: Order number for parallel services. Default: 0x00

Communication reference: The CR number (CR: Communication Reference)
depends on the topology of the INTERBUS system. In the higher-level master
system, the PMS CR of the system coupler is used. In the lower-level project, the
CR number depends on the number of PCP devices in the sub-bus. Number of
PCP devices + 2 = CR number to the higher-level control system.
248
Access-Choice: This section only deals with the version Access-Choice = 0,

because this is the one that the user encounters most often. In this version, a prefix
is added before the actual variable name, so that the variable can be found in the
PDD.
Global variable: @GV.Variable_name
Local variable: Instance_name.Variable_name
Example:
The variable name
@GV.close_doors
for
the
global
variable
"close_doors"
would
be:
For a local variable, the program instance name of the POU should be added. The
POU is instantiated with the name MAIN_I. The local variable is "open_doors", so
the variable name would be: MAIN_I.open_doors.
If you are unsure about the allocation of a variable name, you can use PC
WORX to generate it. To do this, designate the variable as a CSV variable
and compile the project. Then use Windows Explorer to search for the
sr.csv file in the PC WORX project directory. This file has the correct file
name.
More-Follows: The More-Follows element is always 0 for standard data types.

User-defined data types may exceed the PDU size of the PCP connection. In this
case, the data must be transmitted in segments. The More-Follows element is then
set to TRUE (0xFF). When a variable name is segmented, the Data-Length
parameter is assigned the value 0.
Variable-Name-Length: Length of the variable name in bytes.
Data-Length: Length of the following data buffer in bytes. The variable is assigned
this value. The Data-Length element is designed as a byte stream.

6.3.3.2
249
Mailbox Syntax for Write With Name Confirmation
1. Positive Confirmation, Param-Follows = TRUE, Data-Length <> 0

Mailbox Syntax
WRITE_WITH_NAME_CONFIRMATION
Parameter-Counter
Invoke-ID
Communication
reference
Result
--Param-Follows
Index(1)
Index(2)
Index(3)
Index(4)
Handle
2. Positive Confirmation, Param-Follows = FALSE, Data-Length = 0

Mailbox Syntax
Parameter-Counter
Invoke-ID
Communication
reference
Result
--Param-Follows
3. Negative Confirmation
Mailbox Syntax
Parameter-Counter
Invoke-ID
Communication
reference
Error-Class
Error-Code
Additional-Code
Param-Follows: This parameter indicates that other parameters follow. These

parameters are an index and a handle.
Index: This index is linked to the variable name. As soon as the index is displayed,
the next request with this index should be made.
Handle: The handle is used to segment the data. It does not equal 0 if the MoreFollows parameter was set to TRUE and the Data-Length was uneven. The handle
changes each time the data is segmented. It remains constant during
segmentation.
250

6.3.3.3
Mailbox Syntax for Read With Name Request
Mailbox Syntax
READ_WITH_NAME_REQUEST
Parameter-Counter
Invoke-ID
Communication
reference
Access-Choice
More-Follows
Variable-Name-Length
Variable-Name(1)
Variable-Name(n)
The meaning of the parameters can be found in Section 6.3.3.1.

6.3.3.4
Mailbox Syntax for Read With Name Confirmation
1. Positive Confirmation, Param-Follows = TRUE, More-Follows = FALSE

Mailbox Syntax
READ_WITH_NAME_CONFIRMATION
Parameter-Counter
Invoke-ID
Communication
reference
Result
More-Follows
Param-Follows
Index(1)
Index(2)
Index(3)
Index(4)
Handle
--Data-Length
Data(1)
Data (n)
2. Positive Confirmation, Param-Follows = FALSE, More-Follows = TRUE

Mailbox Syntax
Parameter-Counter
Invoke-ID
Communication
reference
Result
More-Follows
Param-Follows
--Data-Length = 0
3. Negative Confirmation
Mailbox Syntax
Parameter-Counter
Invoke-ID
Communication
reference
Error-Class
Error-Code
Additional-Code
251
More-Follows: This parameter is always 0 for standard data types. For user-defined
data types, which exceed the PDU size, the data must be transmitted in segments.
The More-Follows parameter is then set to TRUE and a value not equal to 0 is set
in the Data-Length parameter. If the variable name is transmitted in segments, the
More-Follows parameter is set to TRUE and the Data-Length is assigned the value
0.
Param-Follows: If the value is set to TRUE, this indicates that the next request
should use the index. An index value of 0xFFFFFFFF or 1 indicates an invalid
index.
Data-Length: Length of the following buffer in bytes.
6.3.3.5
Examples of Using the Mailbox Syntax
IBS PC ISA SC/I-T
Read/write with
name request
1.0 / CR 2
ILC 200 IB
ProConOS variable
Figure 6.6: Topology for the application examples

The examples for using the mailbox syntax are based on the INTERBUS topology
shown in Figure 6.6. One example is given for reading and one for writing a
ProConOS variable.
Writing a Local ProConOS Variable
The local ProConOS variable "open_rear_doors" should be set to TRUE. The
variable is instantiated using the program instance name "INS_1". It is also
assumed that the PDU size of the slave interface is not sufficient to transmit the
variable name in one segment.
252
Variable name: INS_1.Hintere_Tueren_oeffnen

1. Request
Mailbox Syntax
0x0097
0x000C
0x00
0x02
0x00
0xFF
0x11
I
N
S
_
1
.
H
i
n
t
e
r
e
_
T
u
e
0x00
---
2. Request
Mailbox Syntax
0x0097
0x0009
0x00
0x02
0x00
0x00
0x0B
r
e
n
_
o
e
f
f
n
e
n
0x01
0x01
1. Confirmation
Mailbox Syntax
0x8097
0x0003
0x00
0x02
0x0000
--0x00
2. Confirmation
Mailbox Syntax
0x8097
0x0006
0x00
0x02
0x0000
--0xFF
0x00
0x00
0x00
0x09
0x0000
Reading a Local ProConOS Variable

The global ProConOS variable "STOP_state" should be read. It is also assumed
that the PDU size of the slave interface is sufficient to transmit the variable name in
one segment.
253
Variable name: @GV.STOP_Zustand

1. Request
Mailbox Syntax
READ_WITH_NAME_REQUEST
0x0098
0x000B
0x00
0x02
0x00
0x00
0x10
@
G
V
.
S
T
O
P
_
Z
u
s
t
a
n
d
---
1. Confirmation
Mailbox Syntax
0x8098
Parameter-Counter
0x00
0x02
0x0000
0x00
0xFF
0x00
0x00
0x00
0x03
0x0000
--0x01
0x01
---
Example of Communication With PC WORX Controllers

The higher-level control system uses the PCP_CONNECT block to establish the
logical connection to the lower-level ILC 200 IB controller, see Figure 6.7. CR 2 is
transferred here as the communication reference number. The variable name can
be added directly to the PCP_READ block as a string. The data item is read when
the REQ input is triggered. This example uses a complete array with 1 KB of user
data.
Figure 6.7: Read with name using PC WORX (higher-level control system)
The lower-level control system establishes communication with a PCP_CONNECT
block. The system number (D0.0.0 -> higher-level control system) is transferred as
the partner address (communication reference), as shown in Figure 6.8.
If the MY_ARRAY variable is available in the PDD of ProConOS, the data item is
automatically passed on. This completes the communication for the user.
254
Figure 6.8: Read with name using PC WORX (lower-level control system)
6.3.3.6
Overview of the Controller Board Types, Which Support the

Read/Write With Name Service
Table 6.3 provides an overview of the types of controller from Phoenix Contact
(and their relevant firmware versions), which support communication via variable
names.
Table 6.3: Types of controller for the read/write with name service (as at February, 2002)
Controller Type
All Field Controllers (FC controllers)
All standard controllers (SC controllers)
except for the following controller types:
IBS S7 400 ETH DSC/I-T
IBS ISA RI/I-T
Firmware Version
Firmware version 4.3G or later
Firmware version 4.47 or later
FC controllers are all types of controller board, which include the letters "FC" in the
order designation or are described as Field Controllers in the data sheet. The same
applies for SC controllers.
As this communication mechanism is used frequently in practice, it is unlikely that a
newer firmware version would no longer support the read/write with name service,
certainly not for Field Controllers.
255
To enable the variable to be read by ProConOS, the PDD flag for this
variable must be set.
The slave interface, from the point of view of the higher-level control
system, must have read/write with name activated in the description
dialog box for the supported PCP services.
Practical Tip: Read/write with name directly from the host system to the controller
board
It is not only possible to send read/write with name requests to a PCP device
(controller board), but they can also be sent directly between the host system and
controller board. CR 0 is used as the CR number in the read/write with name
request. This information in the request code ensures that the data is not transferred
to the PCP stack, but is processed directly in the master firmware/ProConOS.
A logical connection establishment between the host system and the controller
board using an initiate request is not necessary/not permitted.
6.3.4 Read/Write MPM via the Management Channel (PNM7)

In the master firmware, services are implemented, which enable access to every
address in the MPM (area from 0x0000 - 0xFFFF). These services are deliberately
not documented because the process data areas and other sensitive data areas
could be overwritten by a programming error.
Consequently, only the READ MPM service is described in this section. The
WRITE-MPM service should only be used by users, who have specific advice from
Phoenix Contact. However, for an automation solution the use of these services is
not recommended. INTERBUS drivers and the INTERBUS firmware provide all the
necessary functions/services for optimal operation of the INTERBUS system. For
users who want or need to read specific areas of the MPM (perhaps for service
purposes) without a great deal of effort, the READ MPM service can be used.
6.3.4.1
Mailbox Syntax for the READ_MPM_REQUEST
Mailbox Syntax READ_MPM

Service
Meaning
Code
0x0331
READ_MPM_REQUEST
0x0002
Parameter_Counter
0x????
MPM address
0x????
Amount of data to be read
Example: Input data is to be read directly from the MPM. The DTA input area
begins at address 0x1000 and ends at address 0x1FFF. Ten words should be read
from address 0x1000.
256
Service
Code
0x0331
0x0002
0x1000
0x000A
Meaning
READ_MPM_REQUEST
Parameter_Counter
MPM address, DTA input data
10 words are read
How can the READ_MPM service for reading system coupler data objects be
used?
As the firmware services usually have a local effect on the relevant INTERBUS
controller board, there must be an option to execute services remotely. This option
is provided by a remote management connection (PNM7). Only PNM7 services can
be transmitted via this connection; it does not transmit PMS services. However, it is
possible to send commands such as Start_Data_Transfer, Stop_Data_Transfer or
even Read_MPM via this connection. This enables remote control of the system
coupler.
6.3.4.2
Assignment of the PNM7 Communication Reference to a

System Coupler
The Peripherals Network Management channel is assigned to Layer 7 of the

ISO/OSI layer model. It is designed for INTERBUS devices in which remote
services can be executed. At present, these devices are the system couplers. In an
INTERBUS system, the numbering for the PNM7 CRs starts after the PMS CRs
(Peripherals Message Specification), and at present they are only generated for
system couplers. Figure 6.9 illustrates the allocation of PNM7 CRs, if there are
another three PCP devices in the INTERBUS topology.
CRs 2 to 6 are PMS CRs. The PNM7

CRs are assigned after the PMS CRs.
CR2 CR3
CR4 / PNM7-CR7
Figure 6.9: Assignment of PNM7 CRs
CR5
CR6 / PNM7-CR8
257
In an existing application, the assignment may differ from the methods

shown here. This is due to the user-defined assignment of communication
references using a firmware command. The firmware command 0x264
(Load_CRL_Attribute_Loc_Request) enables the user-defined assignment
of communication references.
PC WORX 3.0x does not assign the PNM7 CRs using this standard, but
instead assigns the PNM7 CRs before the PMS CRs. This is due to the
easier handling within the tool for DCI projects. In this case, the user no
longer has to worry about the internal assignment of these CR numbers,
because the device can be addressed using a system number.
If PC WORX 3.0x is not used, the standard mentioned here should be
observed, because the firmware assigns the CRs using this standard
when reading the bus configuration independently.
6.3.4.3
Overview of PNM7 Services
PNM7 Initiate Request

Mailbox Syntax PNM7_Initiate_Request
Message-Code (0x00A0)
Parameter-Counter (0x0001)
--Communication
reference
Communication reference: The PNM7 communication reference. These start after

the PMS communication references.
PNM7 Initiate Confirmation
Positive Confirmation:
Mailbox Syntax
PNM7_Initiate_Confirmation
Parameter-Counter (0x0002)
--Communication
reference
Result (0x0000)
Negative Confirmation:
Mailbox Syntax
PNM7_Initiate_Confirmation
Parameter-Counter
--Communication
reference
Error-Class
Error-Code
Additional-Code
PNM7_
PNM7_
PDU_Sending_Low
PDU_Receiving_Low
PNM7_
PNM7_
Services_Supported
Services_Supported
(1)
(2)
PNM7_
PNM7_
Services_Supported
Services_Supported
(3)
(4)
PNM7_
PNM7_
Services_Supported
Services_Supported
(5)
(6)
Service_Execution_Remote_Request (SER request)
258

Mailbox Syntax
Service_Execution_Remote_Request
Message-Code (0x00C1)
Parameter-Counter
Communication reference
Remote-Service
...
Communication reference: See above.

Remote-Service: Packaged service, which should be executed remotely.
Service_Execution_Remote_Confirmation
Positive Confirmation:
Mailbox Syntax
Parameter-Counter
Result (0x0000)
Remote-Service
Negative Confirmation:
Mailbox Syntax
Parameter-Counter
Error-Class
Error-Code
Additional-Code
PNM7 Abort Request

Mailbox Syntax PNM7_Abort_Request
Parameter-Counter
--Communication
reference
Abort-Detail-Length
Abort-Detail (1)
--Abort-Detail (n)
Communication reference: See above.

Abort-Detail-Length: Number of subsequent Abort-Detail words, default value =
0x00.
Abort-Detail: Reason for the abort. Assigned by the user.
6.3.4.4
Application Example for the SER Request
Before a firmware service can be executed remotely, a logical connection must be

established between the higher-level controller board and the lower-level system
coupler. This connection is established using a PNM7 initiate request, see Section
6.3.4.3. The firmware service to be executed can now be packaged in the SER
request and executed remotely. After successful data transmission, the logical
channel can be disconnected again using a PNM7 abort request.
259
The following example shows the use of the SER request in mailbox syntax for the
remote execution of a Stop-Data-Transfer:
Mailbox Syntax
Stop_Data_Transfer_Request
Parameter-Counter
Stop-Type
Mailbox Syntax
Parameter-Counter
Remote-Service
...
Firmware service Stop_Data_Transfer_Request embedded in the SER request:

Mailbox Syntax
Parameter-Counter
Parameter-Counter
Stop-Type
6.3.4.5
Command Interface for Firmware Services
Users often ask which command interface can be used to send the firmware
services. The CMD/PC WORX (Version 2.0x or earlier) tools are ideal for this task.
The menu item "Configuration / (Controller Board) / Control / Other Services ...",
see Figure 6.10, starts a service editor (Figure 6.11) for sending firmware
commands. If the service code is known, every service can be sent to the controller
board.
260
Figure 6.10: Calling the service editor via the menu
Figure 6.11: Action/service editor
261
6.3.5 Reading/Writing Slave Interface OPC Items

The process data objects of the slave interface can be addressed using the OPC
server from Phoenix Contact. An OPC client reads/writes the slave interface OPC
items.
This communication method is similar to data exchange via the process data
channel. The only difference is the OPC connection.
The use of the OPC server is described in section 7 "OPC and

INTERBUS".
6.4 Questions
for
Concept"Section
the
"Distributed
Control
1.
What is a system coupler?
2.
Name three options for communication between a lower-level and higher-level

INTERBUS system.
3.
The read/write with name service is used to read objects in ProConOS. Is it

possible to read these objects in ProConOS directly from the application
program to the host system (e.g., PC)?
262
OPC and INTERBUS
7 OPC and INTERBUS

In today's automation sector, information is very often exchanged between
INTERBUS controller boards, controllers, visualizations or data base computers
using manufacturer-independent OPC interfaces. Users of OPC technology will
benefit from an understanding of the general structure, hierarchy, and interaction of
OPC components. Only then is it possible to assess the complex interaction of the
individual OPC components.
This section describes the general OPC functions and installation, followed by
some methods for diagnosing and optimizing these communication links. Various
configuration options for OPC client/server applications are described in
conjunction with INTERBUS controller boards. The INTERBUS OPC server from
Phoenix Contact is applied in a practical way in this section.
Using this description you will be able to configure your INTERBUS OPC
connection and make modifications to optimize it.
- Purpose of OPC and how its advantages can be used in automation

- Basic method of operation of OPC communication
- Components required for an INTERBUS OPC connection
- Application of the COM/DCOM platform
- Performance of the INTERBUS OPC server from Phoenix Contact
- Configuration of OPC communication with an INTERBUS OPC server
- Diagnostics of an OPC connection with the INTERBUS OPC server
- Programming and creating your own OPC clients
- Possible OPC client/server combinations
- Alternatives to OPC client/server connections, specifically for INTERBUS
Function, items, and differences between the INTERBUS OPC server

OPC entries found in the Windows registry
Description of the *.clr configuration file
Evaluation of the *.log error log file
OPC diagnostics for OPC_QUALITY_BAD
Instructions for configuring the DCOM platform
Improving the performance of INTERBUS OPC communication
Page 267
Page 269
Page 269
Page 270
Page 273
Page 279
Page 280
OPC and INTERBUS
263
7.1 Purpose of OPC

7.1.1 OPC Client/Server Architecture
OPC (OLE for Process Control, Object Linking and Embedding for Process
Control) is a standardized interface for the connection of various hardware
components to HMI/SCADA applications. It is based on the specification of the
OPC Foundation (as at April 2, 2001). An OPC connection enables network-wide
communication between distributed computer systems for a basic and standard
interface between automation/control applications and higher-level software
applications (e.g., visualizations). Automation hardware manufacturers supply the
required OPC server with their hardware components. The OPC client is
implemented in the visualizations as an interface to the OPC server. Objects and
methods implemented using the OPC specification are used to exchange
information. OPC communication takes place via the Microsoft COM/DCOM
platform.
CALL-E
Figure 7.1 illustrates the OPC architecture with the INTERBUS OPC server from
Phoenix Contact according to the OPC client/server principle.
INTERBUS OPC client,
e.g., Genesis (ICONICS)
INTERBUS OPC
diagnostics client
User-programmed
INTERBUS OPC client
COM/DCOM Microsoft platform for client/server application
OPC automation
interface
INTERBUS OPC server
generates
OCI server
ds
PRI (Procedure Interface)
re
a
CALL-R
log file
OPC custom
interface
DDI (Device Driver Interface)

clr file
CALL-P
communicates
generates
OPC configurator
IBS PC WORX/CMD
reads INTERBUS
configuration
INTERBUS I/Os
INTERBUS
controller board
Figure 7.1: OPC client/server architecture in conjunction with INTERBUS
264
OPC and INTERBUS
The OPC server and the OPC client can be installed on the same or different PCs.
Only one OPC server must be operated on a PC at a time. In addition, several
OPC servers and OPC clients can run within the distributed system and can have
communication relationships with one another.
Advantages of OPC
In the past, when detecting and processing I/O data in automation processing, the
user quickly became aware that almost every hardware component had its own
programming interface. As the majority of these interfaces do not have a common
communication standard, different and often numerous drivers had to be installed.
A group of leading manufacturers in the automation sector joined together and
through the OPC standard have eliminated the disadvantages associated with
automation components. Since then OPC has become the standard
communication platform and provides users with the following advantages:
-
Reduced costs through independence from hardware and software
Independence from suppliers thanks to a large number of OPC client

manufacturers
Optimum OPC server power through direct manufacturer development
Independence from the operating system (at present only Windows operating
systems)
Plug & play configuration between server and client
Optional multi-client access
Network compatibility
7.2 Method of Operation of OPC Communication

7.2.1 Access Method
At the start of access, the OPC client, i.e., a software application such as a
visualization, establishes a communication link to the OPC server via the
COM/DCOM platform and creates a server object in the OPC server. Private
groups and public groups must be created in this server object. Private groups are
only detected by the OPC client that created them. However, public groups can be
used by all OPC clients. The items to be transmitted (variables with path
specification) are assigned in these groups (usually the private groups). Access to
a group and therefore an item is gained using a handle generated by the server.
A group may comprise several items and an item may also belong to several
groups. The items in a group have the same update rate. The client and server
communicate via synchronous and asynchronous read/write access to the groups
and items. For synchronous access, the read/write function is only disabled after
the process has been completed. Asynchronous calls return to the client once the
task has been sent to the server.
OPC and INTERBUS
265
Figure 7.2 shows the various access methods OPC clients use to access the
Phoenix Contact INTERBUS OPC server. It is also possible to update the data
blocks using event-dependent callback functions.
Synchronous writing
Synchronous reading
OPC client
OPC client
OPC server
OPC server
Data cache
Data cache
Control variables
Digital var.
Analog var.
Hardware: INTERBUS controller board
Data cache
Cycle comparison
Group
Callback
Data cache
Data cache
OPC server
OPC server
Asynchronous
callback
Asynchronous
callback
OPC client
OPC client
OPC client
Asynchronous group update
Asynchronous reading
Asynchronous writing
Figure 7.2: Access methods used by the INTERBUS OPC server to access groups
and items
The OPC server provides a custom and automation interface as programming
interfaces, as shown in Figure 7.1. The custom interface is used for programming
languages such as C or C++. The automation interface enables OPC client access
to OPC data for the following programming languages: MS Visual Basic, Borland
Delphi, VB script or MS Excel. The OPC specification shows that an OPC
server does not necessarily have to implement the automation interface. The OPC
Foundation provides an automation interface, the wrapper, which generates an
automation interface.
7.2.2 Required INTERBUS OPC Client/Server Components

The following components are required to implement OPC client/server
communication with an INTERBUS connection:
-
Windows-based operating system, Windows NT/2000 recommended
COM/DCOM on the Windows PC
INTERBUS OPC server
OPC browser (Opcenum) for remote access
266
OPC and INTERBUS
Operational INTERBUS structure (controller board with device)
OPC client, e.g., Genesis 32 from Iconics Inc.
If the INTERBUS OPC server from Phoenix Contact is used, the following software
applications are also required:
-
*.clr configuration file generated by the OPC configurator
Diagnostic OPC client for startup and diagnostics
On Windows-based PCs the opccomn_ps.dll and opcproxy.dll files in the Windows

System32 directory are required to execute OPC components. These files are
installed during installation of the INTERBUS OPC server from Phoenix Contact.
The commands REGSVR32 opccomn_ps.dll and REGSVR32 opcproxy.dll are
used to register these files.
The individual OPC components and their configuration options are described in
later sections.
7.2.3 COM/DCOM Platform

DCOM stands for Distributed COM (Component Object Model). The COM specifies
the working method for components (classes for ActiveX elements, OLE DB, ADO,
etc.) in Windows. It is thus possible to use individual components from other
applications in your own application. The DCOM is a plug-on part for the COM, via
which COM components can also communicate in the network.
DCOM provides access to its functions and data using methods at interfaces.
DCOM is installed as part of Windows NT, 98, ME, SE, and 2000. Under
Windows NT, Service Pack 4 or later is required. Under Windows 95, DCOM
must be installed separately.
The configuration options of the DCOM platform can be found on the

7.3 List of OPC Server Suppliers

In addition to the INTERBUS OPC server from Phoenix Contact, there are
numerous suppliers of OPC servers. These OPC servers are hardware-dependent
and not compatible with INTERBUS controller boards from Phoenix Contact. A
selection of suppliers and their OPC server products are given in Table 7.1.
OPC and INTERBUS

Table 7.1: OPC server suppliers
Supplier
Comsoft
ETM
HIMA
Hartmann & Braun (ABB)
Intellution
ICONICS
Siemens Automation
Softing
Trebing & Himstedt Prozeautomation
USDATA
Wonderware Corporation
267
Product Name
Comsoft Sinec L1 OPC Server, OPC Testclient
Comsoft PROFIBUS DP V1 OPC Server
ETM Server
HIMA OPC Server
Freelance 2000 OPC Server
ABR Driver
Modbus OPC Server, Build 64
SIMATIC WinAC (Soft PLC, Slot PLC),
SIMATIC NET (PROFIBUS DP, FMS, S7,
Send/Receive-S5), SIMATIC WinCC
OPC Server PROFIBUS DP, 4Control,
OPC Server Toolkit, CANopen OPC Server
OPC PROFIBUS Server
FactoryLink
OPCLink, OPCBrowser
7.4 INTERBUS OPC Server From Phoenix Contact

The INTERBUS OPC server from Phoenix Contact is based on OPC specification
2.04 and 1.0a, and is used to exchange process data (PD), program variables
(CSV), and directly addressed variables (DA) between the INTERBUS controller
board and OPC clients. The OPC server does not have its own user interface and
is started by the OPC client. For this, the OPC client establishes a communication
link to the OPC server, which in turn establishes a connection with the controller
board. The controller board makes the required OPC item values available in the
MPM memory. The OPC server reads or writes the INTERBUS I/O data to which
the OPC client has access via specified methods.
In each OPC configuration several OPC servers can be started, however only one
per PC.
A demo version of INTERBUS OPC server 2.01 from Phoenix Contact is

provided on the accompanying CD-ROM.
7.4.1 Differences Between the INTERBUS OPC Servers

The differences between INTERBUS OPC server 1.28 and 2.0x from Phoenix
Contact are given in Table 7.2.
Table 7.2: Differences between INTERBUS OPC server 1.28 and 2.0x
Feature
OPC Server 1.28
OPC Server 2.0x
Name of the server
OPC.Interbus.1
PhoenixContact.Interbus.2
OPC specification
OPC DA 1.0a
OPC DA 1.0a and 2.04
Status items
None
See default items
Diagnostic information
Log file
Log file, OPC diagnostic client
Communication paths
ISA, Ethernet, serial PCI, ISA, PC/104, PC card,
serial, Ethernet, INTERBUS
Number of PC controller boards
2
4
268
Feature
Number of ETH controller boards
Signal paths for SC boards
New data types
Password protection for
RFC/486DX/ETH/I-T
OPC server access to process
data outputs for FCs
OPC and INTERBUS

OPC Server 1.28
8
No
No
OPC Server 2.0x

16
Yes
See OPC data types
Yes
No
Yes, read access
7.4.2 OPC Data Types and Default Items

The INTERBUS OPC server from Phoenix Contact works with the data types given
below in Table 7.3. The VT_I1, VT_UI2, and VT_UI4 data types are only supported
by INTERBUS OPC server 2.0x. Structures, arrays, and strings with user-defined
lengths are displayed by the OPC server as a byte stream with the VT_ARRAY |
VT_UI1 data type.
Table 7.3: INTERBUS OPC server data types
Data Type in PC WORX and
Variant Data Type
CMD
SINT
VT_I1
BYTE
VT_UI1
INT
VT_I2
WORD
VT_UI2
DINT
VT_I4
DWORD
VT_UI4
REAL
VT_R4
BOOL
VT_BOOL
STRING(80)
VT_BSTR
Data Description
8 bits, signed
8 bits, unsigned
16 bits, signed
16 bits, unsigned
32 bits, signed
32 bits, unsigned
32 bits, float
1 bit
80 bytes
The OPC client uses default items to retrieve information about the status of the
OPC server, INTERBUS configuration, the PROGRAM WORX controller, and the
project name. Table 7.4 gives the possible default items of INTERBUS OPC server
2.0x.
Table 7.4: Default items of the INTERBUS OPC server
Default Item Name
Data Type
Function of the Default Item
SERVER_CTRL/
VT_BSTR
Array is divided into: Time stamp, controller
ServerStatus
VT_ARRAY
number, error/information, error code, description
DiagStateReg
VT_UI2
DiagParaReg
VT_UI2
DiagParaExtReg
VT_UI2
Extended diagnostic parameter register
StdFktStartReg
VT_UI2
Standard function start register
StdFktStatusReg
VT_UI2
Standard function status register
StdFktParaReg
VT_UI2
PLC_RUN
VT_BOOL
Controller in the RUN state
PLC_ON
VT_BOOL
Status of the controller after a reset
PLC_STOP
VT_BOOL
Controller in the STOP state
PLC_HALT
VT_BOOL
Controller in the HALT state
PLC_TIMEOUT
VT_BOOL
Timeout flag set
PLC_ERROR_ON_PLC VT_BOOL
An error has occurred in the controller
ProjectName
VT_BSTR
Current project name
OPC and INTERBUS
269
7.4.3 INTERBUS OPC Configurator

Once the INTERBUS system has been fully configured and is operational, the
desired variables, process data, and data points must be reported to the
INTERBUS OPC server. This procedure is described in the provided installation
description.
In general, the OPC server must find the path and the memory cell of the
requested INTERBUS data on the controller board. All information for the
communication link must therefore be available in a suitable file. This configuration
file is created using the OPC configurator in IBS CMD or PC WORX and is in *.clr
format. The format of the configuration file is specific to Phoenix Contact and
cannot be used with an OPC server made by any other manufacturer.
7.4.4 Configuration File (*.clr)

The configuration file (*.clr) contains information about controller boards and
variable definitions of one or more INTERBUS projects that are to be displayed by
the INTERBUS OPC server. The selected OPC items (item = INTERBUS variables
including communication path) are available in the configuration file. The header of
the configuration file contains information about the controller board, the
communication paths, and additional parameters that are required for DDI
communication. These include entries for each OPC item. The configuration file
can contain several INTERBUS projects.
To view the information contained in the configuration file, open this file with a text
editor (e.g., Notepad).
To enable the OPC server to find the configuration file, the following
information
is
stored
in
the
registry
under
KEY_LOCAL_MACHINE/Software/Phoenix Contact/Call-r Server
during server registration of MS Windows NT (path information is
specific to the PC):
ConfigFile
MutexTimeout
ProtocolFile
SN
StartType
e:\PCWORX\Project\OPC.clr
0x000186a0 (100000)
e:\PCWORX\Project\IBSOPC.LOG, 50000, ON
12345678
CONFIG_FILE
The "ConfigFile" parameter contains the name and path of the configuration file
(*.clr) and the "ProtocolFile" parameter contains the name and path of the error log
file (*.log). The "50000" attribute defines the possible file size of the log file in bytes.
The "ON" attribute enables (ON) or disables (OFF) the log file function.
270
OPC and INTERBUS
Example of a configuration file (*.clr) with detailed parameter description:

[Controller Header]
ConfiguratorVersion = 2.0.0.2
Bussystemnumber = 1
Controllertyp = IBS 24 RFC/486DX/ETH-T
ActDevMxi = IBETH01N1_M@05
ActDevDti = IBETH01N1_D
ActDevMwt = DLL PLCOMD32.DLL IBETH01N0_M@01
UniqueItemName = TRUE
ProcessVariables = TRUE
XDTAVariables = TRUE
CSVVariables = TRUE
MPMCacheRate = 100
CSVCacheRate = 100
Projectname = D:\PCWORX\PROJECT\Band1\Eti
ProjectPrefix = 1
Active = TRUE
AutomaticConfiguration = TRUE
DefaultVariables = FALSE
Password = 6B9F3612B629A662934F3C7F7AD185B
VarCount = 30
[Var0001]
Name = 1.1.0/IBS_IO/byte01
DataType = VT_UI1
ArrayDimension = 0
ArrayDimSize =
StructElemTypes =
StructElemNames =
InternalAddr = 1@1.1.0.0.0
AccessMode = 2
AccessLevel = 0
VariableClass = 3
RawValMin =
RawValMax =
PhysValMin =
PhysValMax =
InvertBoolValue = FALSE
Interactor version (creator)

Number of the INTERBUS project in this clr
file
Controller type
Open node string to the Mailbox Interface
Open node string to the Process Data
Interface
Node string to the ProConOS variables
Unique item names are used
Process data is used as OPC items
XDTA (DA) variables are used as OPC
items
CSV variables are used as OPC items
Cache refresh rate of XDTA (DA) variables
Refresh rate for ProConOS variables (OCI)
Project path
Prefix for OPC items
Activate or deactivate individual projects
Activates loading of a SVC file
Use default variable
Encoded Ethernet password
Number of OPC items in this file
Number of the OPC item in this configuration file

Path information and name of the item without spaces
OPC variable type
0 - tag is not an array, 1 - tag is an array
Size of the array
Structures are not supported
Structures are not supported
(First) address of the day in the system
Physical access right for data:
1 - write, 2 - read, 3 - read/write, 4 - reread
Process data: CMD OUT data - 1, PC WORX OUT
data - 4, IN data - 2; XDTA (DA): IN data - 1, OUT
data - 2
ProConOS: All data - 3; default items - 2
Not supported
Not supported
Not supported
Not supported
Not supported
Not supported
Not supported
After each modification to the PC WORX/CMD project on the controller, a new

configuration file has to be created, otherwise the assignment of the variables in
the OPC server to the variables on the controller cannot be ensured.
7.4.5 Error Log File (*.log) and IBOPCDiag

The *.log error log file is activated by the OPC configurator or can be modified in
the Windows registry (see 7.4.4: *.clr configuration file). Any communication
errors that occur are written to this error log file by the INTERBUS OPC server.
When troubleshooting or in the event of an OPC communication problem, this error
OPC and INTERBUS
271
log file enables you to check communication between the OPC server and the
controller board. The file can be opened with an editor such as Notepad.
Example of a successful *.log error log file for an OPC server 2.0x:
Thu May 10 16:31:03,527 : ***** Call-r Server protocol file *****
Thu May 10 16:31:03,527 : Server File Version V 2, 0, 0, 6
Thu May 10 16:31:03,527 : ActiveCachingOCI = FALSE
Thu May 10 16:31:03,527 : OCIMutexTimeout = 0x186A0
Thu May 10 16:31:03,527 : MaxServerStatusLines = 0x32
Thu May 10 16:31:03,527 : ->StartType: START_CONFIG_FILE
Thu May 10 16:31:03,527 : D:\PCWORX\PROJECT\OPC.CLR
Thu May 10 16:31:03,527 : HostAdaption = 0x24
Thu May 10 16:31:03,527 : IBS PCI SC/I-T
Thu May 10 16:31:03,527 : IBB1N1_M@05
Thu May 10 16:31:03,527 : IBB1N1_D
Thu May 10 16:31:03,527 :
Thu May 10 16:31:03,527 : dwOffsetDTAIn = 0x1000
Thu May 10 16:31:03,527 : dwOffsetDTAOut = 0x0
Thu May 10 16:31:03,527 : dwOffsetXDTAIn = 0xFFFF
Thu May 10 16:31:03,527 : dwOffsetXDTAOut = 0xFFFF
Thu May 10 16:31:03,527 : *1* AutomaticConfiguration = FALSE
Thu May 10 16:31:03,527 : *1* ErrCode = 0x0 (Open Node DTI: IBB1N1_D)
Thu May 10 16:31:03,527 : ItemName, AccRights, PhysLoc, PhysDir, PhysAdr, mask,
VT, arrayType, OCIAccessString
Thu May 10 16:31:03,527 : number of installed controllers = 0x1
Thu May 10 16:31:03,527 : *1* Cache Thread ID: = 0x7B
Thu May 10 16:31:03,527 : *1* OCICache Thread ID: = 0x6E
Thu May 10 16:31:03,527 : Initialize server END
Thu May 10 16:31:03,527 : *1* DTA/XDTA InitUpdateThread
Thu May 10 16:31:03,527 : *1* OCI InitUpdateThread
Thu May 10 16:31:03,527 : *1* OCI Number of entries = 0x0
Thu May 10 16:31:03,537 : *1* OCI Update thread in sleep mode
Thu May 10 16:32:42,239 : *1* Terminate Cache Thread: = 0x84
Thu May 10 16:32:42,289 : *1* DTA/XDTA Update thread killed!
Thu May 10 16:32:42,289 : *1* Terminate OCICache Thread: = 0x88
Thu May 10 16:32:42,289 : *1* OCI Update thread killed!
Thu May 10 16:32:42,389 : Terminate server END
The IBOPCDiag program, see Figure 7.3, is a diagnostic tool for OPC
communication and can be found in the INTERBUS OPC directory. This program is
used to display states, errors, information, and warning messages for the
INTERBUS OPC server and the PD, DA, and CSV variables online.
Figure 7.3: Error evaluation in OPC diagnostics using IBOPCDiag
272
OPC and INTERBUS
All error codes that appear in the error log file are described in
Appendix A.3 "INTERBUS OPC Server Error Codes".
7.4.6 OPC Project File (*.vis)

In PC WORX 3.0, the OPC configurator uses the OPC project file (*.vis) to create
the configuration file (*.clr). This project file is generated by the OPC broker in CSV
format from an existing PC WORX 3.0 project. The OPC project file contains all the
information for the variable, such as the address, data direction, and variable type.
First, the item name is compiled in the OPC configurator, as this is where the user
specifies the format. With the OPC project file it is possible to import other software
tools (MS-Excel, etc.). Using the OPC project file, as shown in Figure 7.4, has the
following advantages:
-
Import function of items in other software applications
Integration of items in the visualization without OPC browser interface
Independent and spatially distributed creation of the OPC client through

separate application of the OPC project file. Therefore the OPC client can be
created by various programs, as the OPC project file only relates to one PC
project.
PC WORX 3.0
Project 1
PC WORX 3.0
Project 2
PC WORX 3.0
Project 3
PC WORX 3.0
Project file 1
(1.vis)
PC WORX 3.0
Project file 2
(2.vis)
PC WORX 3.0
Project file 3
(3.vis)
OPC configurator
Import
Other tools
Configuration file (*.clr)
IINTERBUS OPC server
Figure 7.4: Using the OPC project file (*.vis) in PC WORX 3.0
OPC and INTERBUS
273
7.5 OPC Client

7.5.1 Diagnostic OPC Client
To verify a successful OPC communication link, Phoenix Contact supplies
Diagnostic OPC Client, (DiagnosticOPCClient.exe). The correct operation of the
INTERBUS OPC server and the availability of OPC items can be tested using this
OPC test client. During communication startup, Diagnostic OPC Client can be used
to quickly determine whether the OPC client/server link is operating correctly.
Figure 7.5 shows a screen shot of Diagnostic OPC Client.
Instructions for using Diagnostic OPC Client are provided in the accompanying
help files. To carry out a quick communication test, proceed as follows: In
Diagnostic OPC Client connect to the INTERBUS OPC server, create a private
group, and add all OPC items to the group. It is then possible to read and write
items. Successful OPC communication is checked using the item quality (C0h
indicates a valid connection) and its valid item values.
Figure 7.5: Diagnostic OPC Client from Phoenix Contact
7.5.2 Diagnostics of a New OPC Client/Server Connection

If the OPC items are not displayed in the client/server connection under "Add All
Items", this may be due to one of the following:
-
Communication path for the configuration file is incorrect

Repeat/check registration in the OPC configurator
274
OPC and INTERBUS
Configuration file not created or updated

Create, update or check configuration file
Communication path (Ethernet) for the configuration file is incorrect

Execute ping on the PC/Ethernet adapter, check the rights for the
INTERBUS OPC server (DCOM properties)
INTERBUS OPC server not installed (correctly)

Execute IBOPCDiag.exe
Check or repeat OPC server installation
7.5.3 Diagnostics of a Faulty OPC Client/Server Connection

If, during active operation, the OPC items are not (or no longer) displayed, updated
or contain the OPC_QUALITY_BAD attribute, this may be due to one of the
following:
-
Communication path (Ethernet) interrupted

Check Ethernet connection
Controller in the Stop or Reset state

Return the controller to the Run state
INTERBUS driver stopped

Check the driver: e.g., ibsisasc.sys (ISA) or ibpcimpm.sys (PCI)
Communication fault due to online debugging

For CSV variables, an online connection to PROGRAM WORX is not
possible.
7.5.4 Developing Your Own OPC Components

If you wish to develop your own OPC client/server, in addition to the OPC
specification, you must have knowledge of a high-level programming language.
These include all current languages such as C, C++, Borland Delphi, MS Visual
Basic, MS VB for Applications (VBA), etc. For OPC client development with VB,
VBA, Scripts or Delphi, the server-side automation interface is used as a
communication interface. C and C++ use the custom interface, as they support the
concept of the function pointer. The automation interface uses methods with names
instead of methods with function pointers. Figure 7.6 illustrates the method the
OPC client application uses to access the server via the automation and custom
interface.
To make programming an OPC server or client considerably easier, it is
recommended you purchase an OPC toolkit. This includes client and server
examples, software for OPC interface configuration/diagnostics, and OPC methods
and classes that can be imported in your compiler/interpreter. The price of an OPC
client toolkit is approximately 500.
OPC and INTERBUS
275
Documents required for OPC software development can be found on

the
European
(www.opceurope.org)
and
international
(www.opcfoundation.org) OPC Foundation websites. In addition,
help is also available on other websites. These websites are listed in
the information section of A.6.6 "Useful OPC Websites".
Custom
interface
OPC client in C/C++
INTERBUS OPC server
OPC client in Visual Basic,

Delphi, VB script
Automation
interface
Figure 7.6: Communication interfaces from the OPC client to the OPC server
Developing your own OPC applications requires effort, however it ensures the
highest level of flexibility and adaptable communication speeds. Table 7.5 lists
various OPC toolkits and compatible programming languages.
Example programs in source code for creating your own OPC clients in
MS VB and VBA (MS Excel) can be found on the accompanying CDROM.
Table 7.5: Tools for clients and servers

Visual C++ 6.0
C++ toolkits
Xpress OPC Server
Tool
OPC Client Control
OCS toolkit
Borland Delphi 5
X
X
Borland C++
4.0
X
X
X
X
X
X
X
-
VB
6.0
X
7.5.5 Suppliers of Commercial OPC Clients

There are a large number of commercial OPC client suppliers. Even in the
visualization sector, OPC communication as an interface is preferred. Table 7.6
lists a small number of OPC clients that can be purchased.
276
OPC and INTERBUS
Table 7.6: OPC client suppliers

Supplier
OPC Client
ICONICS
Genesis 32
Wonderware
Factory Suite 2000
Intellution
IFix
GefaSoft
GraphPic
Siemens
WinCC
CI Technologies
Citect 5
Progea
Movicon
Inosoft
VisiWinStudio
Rockwell Software RSView
National
BridgeView
Instruments
Website
www.iconics.com
www.wonderware.de
www.intellution.de
www.gefasoft.de
www.it4industry.de
www.citect.de
www.progea.de
www.visiwin.de
www.rockwell.com
www.ni.com/bridgeview
7.6 INTERBUS OPC Client/Server Configurations

The diagrams below in Figure 7.7 to Figure 7.11 illustrate OPC client/server
configurations in conjunction with INTERBUS controller boards from Phoenix
Contact, which are connected or networked via Ethernet, serial or ISA bus
communication paths.
Visualization monitor
IBS master
PC containing the OPC
server, the OPC client, the
clr file, the controller, and the
control program
Figure 7.7: Configuration with serial/ISA connection between OPC server and
client
DCOM
Visualization
monitor
OPC client
Firewall
VPN internet
DCOM
Firewall
PC containing the OPC server, the OPC client, as

well as the clr entries and control programs (for csv
variables) for both
OPC server
IBS RFC450-IB
Diagnostics notebook
Figure 7.8: Configuration with OPC server and Client, connected via a firewall
OPC and INTERBUS
277
Hub
Visualization
monitor
OPC client
OPC server PC containing the clr

file, the controllers, and the
control programs
OPC server 1 IBS master 1
OPC server 2
IBS master 2
Figure 7.9: Configuration with 2 OPC servers and 1 OPC client via Ethernet
Hub
Visualization
monitor
IBS RFC450-IB
PC containing the OPC server, the OPC client, as well

as the clr entries and control programs
(for csv variables) for both
IBS RFC450-IB
Figure 7.10: Configuration with 1 OPC server, 1 OPC client, and 2 INTERBUS
controllers
Hub
Visualization
monitor
PC containing the
OPC server, the
OPC client, as
well as the clr
entries and
control programs
(for csv variables)
for both
OPC client
IBS RFC450-IB
Serial
Diagnostics notebook
OPC server
Figure 7.11: Distributed configuration of the OPC server and Client
278
OPC and INTERBUS
7.7 OPC Client/Server Connection Using the IB Loader

The IB loader software tool from Phoenix Contact enables automatic INTERBUS
startup when the PC is started. The INTERBUS system can be operated via the
OPC connection using the standard function register to be configured. The IB
loader is easy to use and user-friendly for untrained personnel.
The IB loader is provided on the accompanying CD-ROM as a

program.
A detailed description of the IB loader and its application can be found in Section
5.2 "INTERBUS Specialist Knowledge".
7.8 Fast Alternative to the OPC Client/Server

Connection
In the visualization, it is often necessary to transmit extensive data and parameter
records on the controller. The disadvantage of transmitting large data volumes
(> 100 KB) via the OPC interface is the relatively long load time required (two-digit
seconds).
To make loading quicker, it is possible to directly access the MPM memory area of
the INTERBUS controller board. This access is gained in parallel to the OPC
connection on the controller hardware. With hardware write access to the XDTA
memory area of the MPM, it is also possible to write large data packets (up to 5
KB). Data packets larger than 5 KB can be transmitted in separate sequences with
user-defined handshake protocols.
During programming, ensure that the addresses of the OPC server

and that of the DDI access do not overwrite one another.
Unexplainable error states can therefore occur because the OPC
server assumes that the data is no longer being manipulated on the
PC side.
A data write access of 150 KB with DDI functions via a 10-Mbps Ethernet
connection on an IBS RFC ETH 486DX/I-T is therefore shortened from 45 s (OPC)
to 2 s (DDI) including program runtime.
A detailed description of access to the MPM using DDI functions can

be found in the Basics Workshop and in the program code of the
example application on the accompanying CD-ROM.
OPC and INTERBUS
279
7.9 Practical Tips

Tip 1: Configuring the DCOM platform
The DCOM platform can be configured using the DCOM properties window, which
is started under Windows NT/2000 with START | Run | "dcomcnfg".
A detailed description of the OPC and PC configuration including

settings for the Windows NT network, the DCOM platform, and the
user settings can be found as a file on the accompanying CD-ROM.
Tip 2: Installation of the INTERBUS OPC server

The INTERBUS OPC server form Phoenix Contact should always be installed with
the INTERBUS drivers provided. This also applies if the server has previously been
installed. The OPC server should always be installed after IBS PC WORX or CMD.
Installation of the required Service Pack (SP 4 and later) under Windows NT is
also important in this context. This information must be referred to and can be
found in the installation description.
Tip 3: Registering the INTERBUS OPC server
Error-free registration of the OPC server in the Windows NT system can be
ensured if all the tests for the OCS Registry Checks (under: Start | INTERBUS
OPC Server 2.0x | Add-On Programs | Check Registration) are selected. If not all
of the option fields are selected or if an error occurs, the OPC server can be
reregistered in the Windows registry using the "IBOPCServer.EXE /INSTALL"
command. The command can be entered via "Start | Run" or in an MS-DOS box.
Tip 4: Adapting the DCOM configuration, so that a remote OPC client can establish
a communication link with the INTERBUS OPC server without the user having to
be logged into Windows NT.
The OPC server and the OPC client are installed on different PCs, and a user is
not logged in on the OPC server PC. The following modifications must be made on
the OPC server PC:
-
Call the OPC server settings in DCOM under Start | Run | dcomcnfg
Select the properties of the OPC server in the "Applications" window
In the "Identity" window, enter a valid user with the rights for starting,
accessing, and configuring the OPC server with a password
In the "Default Security" window of the DCOM properties add the access rights
under all rights, e.g., for "Everyone" (optional).
Tip 5: Adapting the DCOM configuration, when the INTERBUS OPC server is in a
domain and the OPC client is in a workgroup under a local account, which is not
known by the domains of the OPC server.
280
OPC and INTERBUS
To establish an OPC client/server connection, it is recommended that the following

settings are made globally:
-
Authentication to "None"
Identity to "Anonymous"
Rights to "Everyone"
If the OPC communication link has been successfully established, the settings can
be modified step-by-step as follows:
-
Authentication to "Connect"
Identity to "Identify"
Rights to "Select Account"
Please note that the settings made may also affect other
applications (also local).
Tip 6: Data consistency

There is no data consistency between the OPC client and the INTERBUS OPC
server from Phoenix Contact. All elementary data types are transmitted
consistently. Inconsistencies can only occur when accessing the controller, i.e., in
the driver. Process data (PD) and directly addressed variables (DA) are consistent
for the PCI INTERBUS controller boards by using "With Synchronization Pulse"
mode.
The CSV variables, which are executed as arrays or strings, may be transmitted
inconsistently. This data transmission must be defined consistently with a specific
software handshake.
Tip 7: Improving OPC item performance
The following describes how to improve the OPC data transmission speed, which
the user can set if the update performance of the OPC item does not correspond to
the requirements for the INTERBUS OPC server from Phoenix Contact.
PD/DA cycle time

This PD/DA cycle time (set in the OPC Configurator window in IBS PC
WORX/CMD) refers to the process data and the directly addressed variables.
These variables are updated directly from the coupling memory of the controller
board. The following is a guide for the update time: 1000 variables require a cycle
time of more than 50 ms.
The time intervals at which the variables are updated are specified via the cycle
times (PD/DA cycle time, CSV cycle time) in the OPC configurator. If no
modifications have been made to the cycle times, the data with the shortest
possible cycle time is updated. Due to the required processing effort, this can
cause a considerable load on the system.
OPC and INTERBUS
281
CSV cycle time

This cycle time refers to the variables, which are defined as local variables in
PROGRAM WORX. These variables are updated from the IEC-61131 runtime
system on the controller board. The following is a guide for the cycle time: 1000
variables require an update time of more than 500 ms.
Not only the update time of the instance variables, but also the update time of the
CSV items for the OPC server are set in the PROGRAM WORX Information
window under "Time Between Transmission".
Directly addressed variables (DA)
Using only directly addressed variables greatly improves the update speed.
Addressing in the entire block
The memory addresses of the directly addressed variables should be assigned
without any gaps and not mixed up, in so far as this is possible.
Creating separate groups
Each OPC client graphics side should define its OPC variables in a separate
group. If the items are marked as inactive, they are only refreshed, when the
graphics side is "active". Use the cache for read commands and only activate the
groups when you wish to read the values.
Priority of the OPC process
Increase the priority of the process in the operating system. In the Windows NT
system, this is done in the Task Manager by right clicking on the process.
Grouping alarms
All binary alarms should be grouped in a double word and requested when not
equal to ZERO. This reduces the number of items to be transmitted.
Omitting user-defined data types
User-defined data types, which are to be transmitted as OPC items (array of byte),
reduce performance.
Tip 8: Fast item update after an Ethernet connection is aborted
Under Windows NT, the connect and receive timeouts are set by default to 30 s if
an Ethernet connection is aborted. This results in long delays. No OPC items can
be updated during the abort time. A possible solution is to reduce the value to 3 s.
These parameters can be set in the registry under:
Registry | Local_Machine | Software | PhoenixContact | IBSETH | Parameters | x

Tip 9: No communication with the CSV variables
If CSV variables are used, PC WORX and the OPC server must not be used
together. For communication with CSV variables the compiled PC WORX project
must be present on the PC.
282
OPC and INTERBUS
Tip 10: Switching INTERBUS configuration to inactive

In the OPC configuration file (*.clr), "Active = TRUE/FALSE" under the
[CONTROLLER HEADER] entry specifies whether the INTERBUS controller board
and its items are included in the OPC configuration or not.
Tip 11: State of the OPC item on Stop and Reset of the INTERBUS controller
board
If the Phoenix Contact controller board enters the Stop state all the PD and CSV
variables have the value QUALITY_BAD and the OPC_QUALITY_LAST_KNOWN
flag set. The directly addressed variables are excluded.
If the controller board is reset, the corresponding MPM variable is set to zero.
However, the corresponding item in the OPC server cache is not updated and it
therefore set to OPC_QUALITY_BAD. Once the controller board is started up, the
connection is reestablished and the items are updated.
7.10 Questions for the "OPC Communication" Section

1. Why was the OPC interface developed and which tasks can it be used to carry
out?
2. Which operating systems support OPC communication?
3. Can INTERBUS field devices such as controllers, frequency inverters, and I/O
terminals be operated directly as INTERBUS OPC servers?
4. Can the configuration file (*.clr) created using the INTERBUS OPC configurator
also be used with other servers (not from Phoenix Contact)?
5. Can several OPC clients access an INTERBUS OPC server at the same time?
6. How can the performance of the OPC item be improved?
7. How can the validity of the OPC item be determined (e.g., when reading an
OPC item)?
The answers to the questions for the "OPC Communication" Section

can be found on the accompanying CD-ROM.
Ethernet and INTERBUS
283
8 Ethernet and INTERBUS

The exchange of information within a distributed automation system, for instance
from an INTERBUS controller board to a visualization (via OPC), to a higher-level
control system (distributed installation) or between distributed intelligent
components (DI) is now usually achieved via the Ethernet transmission medium.
In order to use these Ethernet components it is necessary to be familiar with the
general structure, network topologies, transmission media, and protocols. This is
the only way to determine which transmission system (fieldbus or Ethernet) and
which protocol (message-oriented or summation frame) are suitable for an
application, especially in industrial automation.
This section focuses primarily on users, who use INTERBUS with Ethernet in the
field. It explains why Ethernet is used for automation purposes and what the
current configuration options are for automation. In order to understand the basics
of Ethernet or TCP/IP, please refer to the standard literature in the source material.
The practical section describes methods, which are used to diagnose and optimize
Ethernet connections, along with INTERBUS configurations using the Ethernet
transmission medium.
- The purpose of an Ethernet connection to industrial components
- Ethernet communication via TCP/IP
- Features and restrictions of Ethernet media
- Factory Line and other Ethernet components manufactured by Phoenix Contact
- Practical Ethernet diagnostic procedures
Why is the TCP/IP protocol used in industrial Ethernet?

What needs to be taken into account for installations in
industrial systems?
How to install and diagnose TCP/IP under Windows
How to locate errors in the Ethernet network
Diagnostic commands, which can be executed from the DOS
Command line
What are the advantages of Ethernet Diagnostic Management?
How to prevent errors from occurring in the Ethernet network
Configuring a redundant Ethernet configuration
Page 284
Page 286
Page 291
Page 295
Page 298
Page 300
Page 303
Page 307
284
8.1 Ethernet Connection to INTERBUS

Within the framework of industrial changes due to PC technology, pressure on
prices, and worldwide networking (e.g., remote monitoring, remote diagnostics), the
control concepts in automation have also changed. This means that control
systems are now being designed for industrial automation, where the installation of
components is spatially distributed. In the future, control concepts will include
intelligent components (Distributed Intelligence, DI). The demands placed on the
transmission system will consequently be greater. All such components in control
systems should communicate with each other and with higher-level control systems
and should exchange data with visualizations or management PCs.
How this is achieved and which transmission system is used to establish
communication between the distributed components, depends on the system
features of the media. The automation market is therefore in a position to offer a
wide range of different solutions, whereby the Ethernet transmission technology
with
a
transmission
rate
of
10
Mbps
and
100 Mbps and with TCP/IP is able to demonstrate great advantages.
8.2 Why use TCP/IP and Ethernet?

Over the last few years, TCP/IP and the Ethernet data transport medium have
proven to be a winning team, not only in the office world. In particular, industrial PC
users found themselves using both components more and more frequently. In
addition to the TCP and IP protocols, there is also a whole range of other protocols,
which also use the Ethernet medium as the transport path.
Appendix A.4 provides a detailed overview of all protocols, which use

the Ethernet medium. The representation refers to the seven layers of
the ISO/OSI model.
Why TCP/IP and Ethernet have established themselves today as a standard in

automation technology, becomes evident from the properties of the components.
In the hierarchy of the ISO/OSI model, TCP/IP is above Ethernet Layers 1 and 2
and below Layers 5 to 7 of the socket interface. The IP (Internet Protocol) is a
protocol, which is used to connect devices, which are located in different networks.
TCP (Transport Control Protocol) is based on IP and ensures that the devices are
connected during data transmission. It ensures the data and the sequence of the
data packets is correct. The TCP/IP layers are assigned to layers of the ISO/OSI
model in the Figure 8.1.
285
ISO/OSI
model
Layer 7: Application
Layer 6: Presentation
Socket interface:
Protocols for applications such as
TFTP, SNMP, HTTP
Socket interface:
Protocols for applications such
as FTP, SNTP, Telnet
UDP (User Datagram Protocol):

Connectionless data transmission
TCP (Transport Communication

Protocol): Connection-related
data transmission
Layer 5: Session
Layer 4: Transport
TCP/IP
Layer 3: Network
IP (Internet Protocol):
Addressing, searches for and uses paths and packets
Layer 2: Data Link
Error-free transmission of data blocks (packet driver)
Layer 1: Physical
Physical connection (Network Interface Card, transmission medium,

connector, and transmission parameters and rates)
Ethernet
Figure 8.1: Incorporating TCP/IP into the ISO/OSI layer model

The characteristics of the individual layers have produced the following
advantages, but also some disadvantages when using Ethernet with TCP/IP.
Advantages of TCP/IP:
-
TCP/IP provides virtually error-free and reliable data transmission.
Using TCP/IP with Ethernet enables the simultaneous transport of data in both
directions (full duplex).
TCP(/IP) continuously checks the connection.
TCP/IP connects several subnetworks with one another easily and effectively.
TCP/IP is independent of operating systems and hardware.
TCP/IP has standardized functions and protocols, and offers virtually unlimited
possibilities in the network.
Advantages of Ethernet:
-
Scalable speed and medium (TP, coaxial, fiber optics, etc.).
Has already been integrated into the office world, since the Ethernet medium
has already been established there. Has been successful as a transmission
medium.
Able to transmit large data packets.
Ethernet can use different transmission media, such as cable, radio, fiber
optics.
Ethernet is widely used with a large number of manufacturers.
The multi-master capability of Ethernet configurations is extremely useful.
286
Disadvantages of TCP/IP with Ethernet:

-
The diagnostics and troubleshooting of Ethernet configurations can be a

complicated process.
"Realtime transmission" is not always assured with TCP/IP via Ethernet.
Ethernet components, which are suitable for use in the industrial sector, are
highly priced with an expensive infrastructure.
Connectors and cables, etc., do not always meet industrial requirements.
For local and worldwide Ethernet networks, the TCP/IP protocol is a de facto
standard, which is therefore supported by all operating system platforms. It
therefore has a full routing capability, i.e., remote networks can be connected with
one another via WAN (Wide Area Network).
Table 8.1 and Table 8.2 provide an overview of the technical data of the 10 Mbps
Ethernet and a comparison of Ethernet and INTERBUS in relation to the data
throughput.
Table 8.1: Technical data of 10 Mbps Ethernet
Standard
Ethernet according to IEEE 802.3
Access method
CSMA/CD (collision detection)
Maximum data length
1500 bytes
Transmission medium
Coaxial cable, twisted pair cable, fiber optic cable
Transmission speed
10 Mbps
Maximum devices
Medium dependant
Network expansion
1500 m (4921.26 ft.) for electrical cabling
4300 m (14107.61 ft.) for optical cabling
Topologies
Line, tree, star, ring, redundant ring
Table 8.2: Comparison of the INTERBUS and Ethernet[12] data throughput
INTERBUS
Ethernet
Useful data
32 x 8 = 256
32 x 8 = 256
Frame data
16+32+38 x 5 = 238
25664 x 8 x 32 x 2 = 32786
Efficiency
256/(256+238) = 52%
256/(256+32768) = 0.77%
Data throughput/
260 kbps at 500 kbps
77 kbps at 10 Mbps
baud rate
1040 kbps at 2 Mbps
770 kbps at 100 Mbps
7700 kbps at 1000 Mbps
8.3 Installing Ethernet in an Industrial Environment

When the Ethernet transmission medium is installed in an industrial environment,
special notes should be observed. Adverse interference is to be expected from the
industrial environment which can be caused by electrical and magnetic
interferences, incorrect grounding, voltage peaks or even strain, temperature, and
motion. The following points are therefore important:
-
Potential fluctuations, which are generated by distributed supplied voltage,

must not trigger transmission faults.

-
287
Surge voltage protection and electrical isolation must protect the user when the
transmission media come into contact with power cables.
Distributed control systems must be protected against downtimes by an
effective redundancy concept.
In potentially explosive areas, the installation should be adapted accordingly.
The extreme and harsh industrial conditions should also be taken into account
when using Ethernet components. Connectors, cables, connections, etc. are
subjected to increased strain and wear which is caused by mechanical and
chemical influences.
When planning Ethernet configurations via TCP/IP for an I/O system in
automation, the realtime capability of the I/O data should be taken into
account. A rule of thumb would be, that I/O systems, which require an
update or cycle time of < 50 ms, ARE NOT suitable for Ethernet with
TCP/IP.

Not all RJ-45 connectors are suitable for use in harsh industrial
environments. Select the appropriate RJ-45 connector for the desired
environment carefully.
The use of twisted pair cables in industrial working environments is, like with the
RJ-45 connector, to be selected depending on the strain and possible
interferences. Shielded cables (STP, Shielded Twisted Pair) which are close to
sources of interference such as spot welding controllers, motor starters, contactors,
drives, induction welding systems, devices with high-frequency radiation,
electrostatic system parts, and high-current devices are compulsory.
8.4 Ethernet Components From Phoenix Contact

8.4.1 Factory Line and INTERBUS Ethernet Controller
In addition to Ethernet infrastructure components (Factory Line), Phoenix Contact
also offers components, which connect INTERBUS to Ethernet, as shown in
Figure 8.2. This enables the deterministic INTERBUS system to be integrated into
the message-oriented Ethernet system. This is important when, for example, OPC
visualizations are connected via the interface or when higher-level control systems
are to be connected to INTERBUS.
Phoenix Contact has a range of INTERBUS controller boards with an Ethernet
connection and Ethernet infrastructure components. The following Table 8.3
provides an overview of the capabilities.
A detailed overview of the outputs on the 7-segment display for all

components of the Factory Line series can be found on the
288
Figure 8.2: Ethernet components from Phoenix Contact
IBS 24 RFC/486DX/ETH-T
RFC ETH 450-IB

RFC ETH 430-IB
IBS S7 400 ETH- DSC/I-T
IBS 24 DSC ETH/I-T
FL Hub Agent
FL IL 24 BK
FL IL 24 BK-B
FL Switch TX/TX (copper

version) and
FL Switch FX/FX
(fiber optic version)
FL Switch 5 TX
(copper version)
FL Hub 10BASE-T
FL IBS SC/I-T
FL MC 10Base-T/FO POF
Application
SNMPCompatible
Only Ethernet
Components
INTERBUS
Master With
Ethernet
Connection
Components
Table 8.3: Components suitable for Ethernet from Phoenix Contact (as at March 2002)
PC WORX INTERBUS controller board with

10Base-T or AUI interface
PC WORX INTERBUS controller board with
10/100Base-T interface
S7 INTERBUS controller board with 10Base-T
interface
INTERBUS controller board, which can be
programmed in high-level language, with 10BaseT or AUI interface
Industrial switch with 2*100 Mbps uplink, 5*10/100
Mbps downlink, redundancy, SNMP, web-based
management, TFTP, BootP, multicasting, full
duplex, store & forwarding
Industrial switch with 1*uplink / 4*downlink 10/100
Mbps, full duplex, store & forwarding, autocross.
Star coupler for 10Base-T networks
Star coupler for 10Base-T networks with
management via SNMP and web-based
management
Inline Ethernet bus coupler with OPC connection
Inline Ethernet bus coupler with restricted
functionality
INTERBUS controller board, which can be
programmed in high-level language, with Ethernet
connection
Media converter from 10Base-T to fiber optics 660
nm
289
8.4.2 Network Management Software: Factory Manager 2.0

Factory Manager 2.0, as described in Figure 8.3, is a network management
software package (Windows 95/98/NT/2000/XP), which is extremely helpful
during startup. Factory Manager enables quick startup, maintenance, detailed
troubleshooting, and long-term network monitoring of all Ethernet components (not
only Phoenix Contact components). A static IP address specification is integrated
with a BootP server, a TFTP server for local or remote firmware update, detailed
Ethernet traffic and error statistics and proactive device diagnostics for critical
supply voltages. The optional PC WORX and DIAG+ software enables you to
program and diagnose the lower-level INTERBUS systems.
Figure 8.3: Configuration and diagnostics software: Factory Manager 2.0
The Factory Manager 2.0 software can be found as a demo version on

the accompanying CD-ROM. The restrictions of the demo version
mean that only 3 devices can be managed at the same time, there is
no integrated network spy, and it is not possible to save or load
configurations.
Using its own automatically created Factory Manager files (*.ncf), the Factory
Manager can create a database that other software tools can use. This provides
additional stand-alone software tools such as the "FL IO configurator" and "SNMPOPC configurator", which can import and use these Factory Manager files (*.ncf).
290
Figure 8.4 shows the different ways the Factory Manager can access an OPC
client. This makes communication via a configuration file (*.clr) and an SNMP-OPC
gateway possible.
8.4.3 OPC Configuration Software: FL IO Configurator

The FL IO configurator consists of the FL IO browser and the FL OPC configurator.
The FL IO browser creates a configuration file (*.icf) for the FL OPC configurator.
This then generates a configuration file (*.clr), which the INTERBUS OPC server
can read.
*.ncf
Factory
Manager
INTERBUS
*.clr OPC server
*.icf
FL IO
browser
FL OPC
configurator
OPC
OPC
*.ncf
SNMP OPC
gateway
OPC client
Figure 8.4: Factory Manager access to an OPC client
8.4.4 SNMP-OPC Software: FL SNMP-OPC Gateway

The FL SNMP-OPC gateway consists of the FL SNMP-OPC server and the
FL OPC-SNMP agents. The FL SNMP-OPC server is used to establish a
communication link, which transmits SNMP information to a visualization (HMI,
SCADA) via the OPC client/server connection. The FL OPC-SNMP agents are also
used to transmit OPC information to a management station via SNMP. To do so, it
is essential that the Ethernet components are SNMP-compatible.
8.4.5 Web-Based Management

Web-based management provides the user with an interface to specific Ethernet
components (FL switch, FL hub agent, FL IBS/I-T, and the FL IL 24 BK), which can
be addressed using Microsoft Internet Explorer. A single Ethernet device can be
directly called and parameterized from Internet Explorer. In this way, it is possible
to disconnect ports, to update firmware, and to set static IP addresses as well as
use other functions.
To access the web-based management, you need an Internet browser

(MS Internet Explorer with Java runtime for FL switch TX/FX) and a
password, a community-string. The read-password is: public; the
read/write password is: private.
291
8.4.6 Trap Receiver

Using Factory Manager it is possible to set SNMP traps in the trap receiver. This
means that for all SNMP-compatible Factory Line components such as FL switch,
FL hub agent, FL IBS/I-T, and FL IL 24 BK diagnostics information (e.g., threshold
values from RMON exceeded or fallen below) can be sent to a defined target IP
address. This SNMP functionality is not linked to Phoenix Contact components.
8.5 Diagnostics in the Ethernet Network

8.5.1 TCP/IP on a Windows Operating System
In order to be able to work with TCP/IP in the Ethernet network, the TCP/IP
protocol must be set up on your Windows 2000, NT, 98 or 95 (Version C or later)
PC. From the Control Panel | Network, you can add these network components
and configure them under properties.
8.5.2 Setting the IP Address and Subnet Mask

For Ethernet communication purposes via TCP/IP it is essential that each Ethernet
device is parameterized with a MAC, IP address, and the subnet mask. The MAC
address is a "device designation" which has already been incorporated into the
device by the manufacturer. The three left bytes of the six-byte long MAC address
contain the manufacturer code: 00:A0:45 represents the manufacturer: Phoenix
Contact. In some cases, a router or gateway address is also required, for example,
in order to exit the company network. On a Windows NT PC the TCP/IP address
settings can be found in the properties of the TCP/IP protocol, under Control Panel
| Network | Protocols, as shown in Figure 8.5.
For Ethernet structure components of the Factory Line series, the IP address
setting can be parameterized either via the BOOTP server, web-based
management or a V.24 connection using the terminal program (only for FL switch
TX/FX). Upon request, an IP address is assigned statically (BOOTP) or
dynamically from a free pool of IP addresses (DHCP) and then allocated to the
requesting Ethernet device. If a DHCP server is present, it is also possible to
assign an IP address.
Do not randomly assign IP addresses in a company network. This may
result in the failure of other Ethernet components. The network
administrator has an overview of all free IP addresses and can assign
them accordingly.
Table 8.4 lists the network classes A to E with all possible IP address areas and
the number of networks and hosts.
292
Figure 8.5: TCP/IP address setting using Windows NT

Table 8.4: Possible IP addresses in the network classes
Class
Lowest IP Address Highest
IP Number of
Address
Networks
A
000.001.000.000
126.000.000.000
126
B
128.000.000.000
191.255.000.000
16384
C
192.000.001.000
223.255.255.000
2097152
D
224.000.000.000
239.255.255.255
E
240.000.000.000
247.255.255.255
-
Number of Hosts
16777214
65534
254
-
8.5.3 Testing Ethernet Communication

If the parameters of the subnet mask and IP address are set in the TCP/IP settings
on the Ethernet device, the Ethernet adapter must be integrated with an Ethernet
cable into an (existing) Ethernet network. When the cable is connected (twisted
pair, FO) correctly, the LINK LED will light up if the other end of the Ethernet cable
has also already been correctly connected.
To test whether a hardware connection is correct, use the ICMP command
(Internet Control Message Packet): Echo request, also known as ping, and the IP
target address from the MS-DOS Prompt. ICMP enables error messages and
control messages to be exchanged on IP level. Like IP data packets, ICMP
commands are also unreliable. They are however the only means of informing
hosts and gateways of the network status (e.g., a timeout).
In the Windows "MS-DOS Prompt" enter the echo request with the IP target
address (C:\>ping <ip address>). The IP address 127.0.0.1 enables you to "ping"
your own PC. If an Ethernet device is "pinged" by an echo request, i.e., it checks
293
whether there is a device on the hardware level, then it responds using the echo
reply, also referred to as "Pong". If the echo request is not successful, you will
receive one of the following ICMP messages listed in Table 8.5.
Table 8.5: ICMP messages
Type Message
0
Echo Reply
3
Destination
Unreachable
4
Source Quench
5
Redirect
8
Echo Request
11
Time exceeded
12
Parameter Problem
13
Timestamp
14
Timestamp Reply
15
Information Request
16
Information Reply
Description
Replies to a ping
Destination PC cannot be
reached
Data packet too big
Bad router
Ping is sent
TTL (time-to-live) has expired
Incorrect parameter in header
Request for timestamp
Reply with timestamp
Request for network number
Reply with network number
In Figure 8.6, the echo request with a 32-byte data packet has successfully
reached destination 127.0.0.1, in other words the PC has been answered in less
than 10 ms.
Figure 8.6: If the "ping" is successful, a "Pong" is returned
Figure 8.7: Ethernet devices, whose specified IP address does not exist
294
Figure 8.7 shows a negative ICMP reply type 3 (see Table 8.5), for when the
Ethernet device with the specified IP address does not exist or if it does not
correspond to the specified subnet mask.
If the echo reply returned is negative, then this may be due to: If there is a
"Timeout" or if "Request time has been exceeded", the specified IP address of the
target device matches the subnet mask, but cannot be found. Possible causes are
as follows:
-
IP address of the target device is incorrect or has been assigned twice.
IP address of the target device does not match the subnet mask or the IP
address of the PC.
Set subnet mask or IP address within the limits of the subnet mask.
No TCP/IP protocols have been installed in the PC network.

Under Control Panel | Network, install the TCP/IP protocol.
Your PC Ethernet adapter (127.0.0.1) cannot be "pinged" with its own IP

address.
Ethernet TCP/IP configuration has been installed incorrectly or your PC
Ethernet hardware is not present/faulty.
Your PC "pings" itself but the LINK LED of the Ethernet adapter does not light
up.
Ethernet cable has not been configured correctly. The cable may not fit, as
the wires of the cable are not properly connected.
Under Windows 95/98, in the Device Manager (under Start | Settings | Control
Panel | System | Network Cards | Properties), the device is not ready to operate.
Under Windows NT/2000/XP, check the ready status under Start | Programs |
Administration | Event Display. Where the network drive fails to start, a red entry
with explanations is given.
Unable to start the driver. Check driver settings and hardware.
The target device can be "pinged" using the IP address, but not using a name.
The DNS server entry probably does not match, and the name is therefore
not resolved in the corresponding IP address.
If the reply from the echo request is still negative, the "netstat -rn" command should
be used to check the TCP/IP connections when the echo request is being
executed. The connection list, or routing table, shows the connections row by row.
Before an echo request is sent, this table is scanned. The "route add address"
command is used to add new IP address connections.
If echo requests are answered positively, then the hardware

connection is operating correctly. No information is provided about the
quality of the connection or the transmission rate. The benchmark
program NETIO for DOS, Windows, Linux, and OS/2 is used to check
the transmission rate. The program can be found on the accompanying
CD-ROM or downloaded from the Internet:
ftp://ftp.leo.org/pub/comp/os2/leo/systools/
295
8.5.4 Typical Network Errors

For LAN or Ethernet troubleshooting, a specific procedure should be followed,
which is still reliable and functional when new or unknown error descriptions occur.
It therefore has to be determined which protocols or network functions are
suspected to be the likely cause of the error. It is also necessary to find out which
machines or network components have been affected by the error or are likely to
cause such errors. In other words, troubleshooting should identify error(s) [5]
-
in the transmission system (i.e., physical error)
in the Internet working layer (i.e., network error or routing error)
in the data flow control layer (usually the transport layer)
in the name and address resolution (ARP, DNS, WINS, etc.)
in the application
in the operating system (for client or server)
During Ethernet troubleshooting, the following rule of thumb [5] is

established: "The further down the layers of the ISO/OSI model the
error has to be located, the harder it is to find it". This means that in
Layers 1 and 2, the network error is easier to locate than in the higher
layers.
Coaxial cables in particular are very likely to produce errors and are responsible for
a large number of network errors in the lower Layers 1 and 2. The use of twisted
pair cables laid in star formation and RJ-45 connectors has considerably reduced
the error frequency. Should an error however occur, it only affects one network
component and not the whole branch, as is the case with coaxial cabling. By using
twisted pair cables, Ethernet errors are less likely to occur in Layers above 1 and 2,
but are usually found in Layers 3 to 7, and are therefore harder to find.
The Ethernet error hit list [10] states which error sources occur frequently in the
network:
-
Data distributor not grounded
Ground loops between data distributors and termination devices
Installation of data cables lengthways to conductive cables
Data paths too long
Data cable not shielded or shielding has been incorrectly fitted
Wire pairs not twisted during installation work
Distances of connection terminals exceeded when laying the data cable
Mix up due to non-adherence to color code
Use of single components according to Cat.5 without entire system according

to Cat.5
296
8.5.5 Ethernet Troubleshooting

For a quick Ethernet check, the load on the network should be no greater than
40%. In an industrial Ethernet, we recommend that the load is less than 20%.
Otherwise network expansions such as switches have to be used for segmentation
purposes. The average rate of collision should also be less than five percent. In the
event of a collision, data traffic is increased by repeated packets, which produces
further collisions. In the worst case, the whole network data traffic can be delayed
for so long that the communication links between the Ethernet devices are
removed and certain Ethernet components (e.g., server) have to be restarted.
Collisions in the network can be caused by the load on the network, packet length,
number of communicating stations, length and frequency of accessible stations,
line length, coupling elements, and the jitter compatibility of the Ethernet adapter.
To avoid collisions, it is advisable to distribute the network segments into collision
domains (switches with store and forward features) and to auto-partition ports
(disconnecting ports after 32 - 64 consecutive collisions).
Error messages in FCS (collisions, cable errors), alignment frames (collisions,
cable errors), long frames, also referred to as Jabbers (collisions, faulty hardware),
short frames (collisions, cable errors, faulty hardware), phantom collisions (frequent
collisions, EMI), and late collisions (segments too long) must not or should not
occur. As Ethernet troubleshooting has such a complex error description, the
following three troubleshooting steps [5] are very useful:
Step 1: Step 1 of the error analysis involves finding out:
-
Which users are affected by the error and who detected the error
How, where, and when the error was detected
Whether the error can be assigned to a specific location or application
Whether the application or device has ever run smoothly and without errors
Whether the error can be reproduced and adjusted
Whether changes have been made in the system or network
Whether any attempts have been made to locate the error, and if so what has
been done
Whether complete documentation for the network is available
The initial troubleshooting tools provided are component-specific information

(diagnostic LEDs, SNMP, RMON), multi-meters (voltage measurements), cable
testers (copper cables), and optical attenuation measuring devices (fiber optic
cables). These are used to check cables, connectors (connections), terminal
resistors, wiring, transmission attenuation, crosstalk attenuation, ACR attenuation,
and cable lengths.
Error sources with copper cables may be due to an incorrect cable wave
impedance, incorrectly fitted wire pairs, FDX/HDX connections or incorrectly set
transmit and receive paths (MDI).
297
Errors may occur on optical Ethernet components as a result of incorrect

transmitting and receiving powers, mixed up connections for transmitters and
receivers, faulty cables or connectors, or problems with full duplex or half duplex
connections. Figure 8.8 shows a flowchart, which describes how to proceed in the
event of an error.
Is there a network connection?
No
Yes
Establish network
connection
Faulty network connection?
No
Proceed with
troubleshooting
No
No problems
Yes
Sofware application runs

with errors?
Yes
Internal computer
problems (memory)
Software error
Support from software

manufacturer
Figure 8.8: Troubleshooting flowchart
An effective troubleshooting method has proven to be the systematic

exchange of the individual Ethernet components, as per the trial &
error method. Even when it becomes apparent, that a certain Ethernet
component is faulty, this does not mean that the Ethernet error has
now been resolved. Ethernet problems are often a result of interlinked
individual errors.
Step 2: The second step involves using analyzer software, e.g., Ipswitch What's up
Gold 6.0, to set filters to broadcasts and multicasts, and to run for at least 60+1
seconds. All active components such as the router, spanning trees, etc, emit a
signal once every minute, thus allowing them to be detected. The analyzer
software is also used to detect collisions, faulty data packets, CRC (FCS) errors,
and other interference signals such as spikes as part of the error statistics.
The demo version of "Ipswitch What's up Gold 6.0" analyzer software

can be easily downloaded from the Internet at http://www.ipswitch.de.
298
Step 3: In order to track down the Ethernet error, it is often useful to apply the logic
method when isolating the error. To do so, it is necessary to observe several
Ethernet components at the same time and to record the data flow (frames, bytes,
errors) in both directions. It then becomes evident how many frames produce a
specific number of errors during transmission between two Ethernet components
and how many data bytes are involved. It is extremely helpful to use more than one
measuring device/software package for distributed troubleshooting. The "Ethernet
and INTERBUS" workshop explains the practical methods.
Figure 8.9 shows how measuring devices are assigned to the different layers in
the ISO/OSI model.
ISO/OSI
model
Layer 7
Layer 6
Layer 5
Layer 4
Protocol analyzer
(e.g., Ipswitch what's up Gold 6.0,
FLUKE protocol analyzer)
Layer 3
Layer 2
Layer 1
LAN analyzer
(e.g., FLUKE LAN meter)
Cable tester/optical measuring devices
(e.g., FLUKE DSP 4100)
Figure 8.9: Which measuring device should be used for which ISO/OSI layer?
Sporadic errors only occur temporarily and are difficult to locate. Such
errors are usually dependent on the network load, interference signals,
voltage fluctuations, temperature, compatibility, assembly of cables
and connectors of components.
In order to choose the right Ethernet troubleshooting method, the

information and comments provided by the user should be considered
important and taken into account.
8.5.6 Important Commands Used for Network Analysis

Useful commands for command lines and possible parameters for network analysis
are
detailed
in
the

Table 8.6.
299
300
Table 8.6: Commands for command line

arp
Displays the ARP table
-d <ip address>
-s <ip address>
finger
Shows the assignment of network addresses with the

physical address on the local PC
Deletes the ARP entry
Creates a new ARP entry
Displays the user
-1 <ip address>
hostname
ipconfig
Shows all active users on the remote PC

Displays the name of the PC
Displays the TCP/IP configuration of the PC
/all
/renew
/release
net
All information is displayed

IP address is renewed (DHCP)
IP address is released (DHCP)
Displays the configuration of the local PC
config
diag
diag /status
time
ver
view
netstat
Shows current settings

Starts the MS network diagnostic program
Shows the NetBIOS diagnostic statistics
Synchronizes the time
Shows the version of the redirector
Shows the PC with the resources and releases
Displays statistics for Ethernet, TCP, IP, and UDP
-a
-e
-n
-s
-p
-r
nslookup
Shows all connections and UDP/TCP sockets

Shows all Ethernet statistics
Shows all connections in numeric form
Shows all protocols with statistics
Shows all protocols
Shows the routing table
Shows DNS name
<hostname>
ping
Shows all data of the DNS name server

Checks the hardware connection to the device with an
ICMP packet (Internet Control Message Packet).
-a <ip address>
In the output, it uses the PC name instead of the IP

address
Ping runs continuously until stopped by CTRL C
Indicates how many pings should be sent (in this case 20)
Indicates the length of the ICMP packet
Sets the dont fragment bit (DF)
The IP packets receive a TTL value (time-to-live)
Triggers an IP-ToS (Time of Serve)
Activates the option: Time stamp (1<quantity<4)
Activates the option: Record route (1<quantity<9)
Moves the "ping" via the router from the
host list file
Moves the "ping" only via the router from the host list file
Allocates a timeout value (ms) to the ping
Sends pings to each device on a list
-a
-t <ip address>
-n 20 <ip address>
-l package length <ip addr.>
-f <ip address>
-t 128 <ip address>
-v ToS <ip address>
-s amount <ip address>
-r amount <ip address>
-j hostlist <ip address>
-k hostlist <ip address>
-w time value <ip address>
-liste
301
route
Changes and shows the routing table
without parameters
-f
-print
-add
-delete
-change
tcpdump
Shows the routing table

Deletes the routing table
Shows the static routing table
Creates a static routing table
Deletes a static routing table
Changes an existing routing table
Uses the Ethernet packet filters to view all packets on the
network
Shows the IP path and the TTL (time-to-live) for the data
packets from the source to the destination point. This
shows you where the packets are being delayed and
where there might be a faulty router.
tracert <ip address>

also traceroute
also findroute
-d
-h
-j
-w
Indication, without DNS resolutions of the IP addresses

Specifies the maximum TTL value of the IP data packets
Shows a list of crossing routers (file)
Indicates a timeout time for pong replies
The "WinNTcfg.exe" program gives the hardware address of the

Ethernet adapter, the IP address (dynamic or static), the subnet mask,
and all other network settings on your PC. WinNTcfg.exe can be found
on the accompanying CD-ROM (winipcfg.exe for MS under WIN 95).
8.5.7 SNMP (Simple Network Management Protocol)

The SNMP is the current protocol standard for diagnostics and management in
Ethernet networks. The SNMP compatibility of Ethernet components is part of the
features, which differentiate cost-effective office components from highperformance industrial components. The SNMP protocol enables the system user
to diagnose and parameterize Ethernet components, and forecast possible
bottlenecks in the bandwidth.
The SNMP protocol is based on communication between the SNMP manager and
SNMP agents. The SNMP manager is the work platform of the administrator and
communicates with the SNMP agents located in SNMP-compatible Ethernet
components. The SNMP manager therefore has direct access to SNMP objects in
the Ethernet components. These SNMP objects are found in Phoenix Contact
components such as the FL switch, FL IL 24 BK, FL IBS SC/I-T or in the FL hub
agent.
The SNMP manager requests the SNMP objects via the SNMP protocol and
evaluates the received information. SNMP objects are defined in standardized
databases, known as the MIBs (Management Information Base). These MIB
contain all hardware-specific information required for access purposes. These
SNMP objects can be accessed by using an SNMP browser for example. The
following section 8.5.8 RMON (Remote Network Monitoring) lists all MIBs that are
used.
302

A demo version of the SNMP browser "MG Soft MIB Browser" can be
found on the accompanying CD-ROM. To run the SNMP browser on
your Windows PC, install and start the "SNMP Service" (under
Windows NT 4.0: Control Panel | Network Settings | Services).
Installations carried out at a later date will require the CD for the
operating system.
As the term Simple from SNMP implies, the SNMP manager can easily access the
values of SNMP objects by using simple commands ("get" used for reading, "set"
used for writing). To protect Ethernet components from unauthorized access, a
password or community-string also has to be transmitted to the get and set
commands. There are two community strings: "read only", which only permits read
access and "read/write", which also enables you to configure SNMP objects. New
Ethernet components use the default communities "read-only: public" and
"read/write: private", which should however be changed immediately by the
administrator.
There are currently three versions of the SNMP protocol: SNMPv1, SNMPv2, and
SNMPv3. SNMPv1 is the original SNMP protocol, which offers poor control of
SNMP access. The community string is therefore added to the get and set
commands without any encoding in plain text. This means that the community
string can then be easily read using a protocol analyzer.
SNMP protocols SNMPv2 and SNMPv3 are used to transmit security-related data
using an encoding method. The latest SNMP protocols are not used extensively yet
in industrial and administrative environments. Another disadvantage is the
increased work and management time required during installation in comparison to
the SNMPv1 protocol.
Many Ethernet components run an SNMP agent, without the system

user knowing anything about the SNMP capability. A port scanner such
as
the
program:
SuperScan
(http://members.home.com/rkeir/software.html) can be used to search
for addresses on open UDP and TCP ports 161 and 162.
8.5.8 RMON (Remote Network Monitoring)

Like SNMP, RMON is a manufacturer-independent standard, which operates in a
distributed Ethernet architecture, consisting of agents and managers. It differs from
SNMP by also providing network statistics (RMON-I) and network analysis (RMONII). These RMON components issue statistics (remote statistic group) on network
load, collisions, packet sizes, and termination devices to a central management
station. Only RMON-II can be used for the analysis of packets and capturing
operations. This enables you to identify what and how much data is being
transported by Ethernet between the transmitter and receiver.
SNMP and RMON can access the following MIBs for Factory Line components
given in Table 8.7 :
Table 8.7: MIBs from the Factory Line series

FL IBS SC/I-T
FL IL 24 BK
FL Hub Agent
FL Switch
303
RFC 1213 MIB (MIB-2)

PxC-PRIV MIB (supports device-relevant groups: 2
(pxcGlobal)+11(pxcFactoryLine))
PxC-PRIV MIB (supports device-relevant groups: 2
(pxcGlobal)+11(pxcFactoryLine))
RFC 1516 (REPEATER-MIB)
PXC-PRIV MIB (supports device-relevant groups)
Firmware 2.00:
RFC 2239 (MAU-MGMT-MIB)
PXC-PRIV-MIB (FL switch MIB 20, supports device-relevant groups)
Firmware 3.00:
RFC 2239 (MAU-MGMT-MIB)
PXC-PRIV-MIB (FL switch MIB 30, supports device-relevant groups)
RFC 1493 (BRIDGE MIB)
RFC 1757 (RMON MIB, groups 1, 2, 3, 9)
RMON is structured into groups and provides the above mentioned statistical
information. RMON II provides historical statistics and represents them on a graph.
Since the information in the database is stored for a long period of time, the
behavior of Ethernet can be compiled over days, weeks, and months. Errors such
as duplicated network addresses or overloaded network segments can therefore
be easily identified.
RMON in both groups is supported for all Factory Line switches FX/TX as of
firmware Version 3.0 or later and is very useful for preliminary checks in the event
of Ethernet errors. For more complex errors, RMON tends to be less reliable. The
time lost due to individual requests for information does not benefit RMON as a
troubleshooting tool. On the other hand, for random checks and continuous
monitoring purposes, RMON is the perfect tool to be using.
304
8.6 Prevention of Ethernet Problems

The following checklist [5] should be used for the prevention of Ethernet problems:
Network documentation: Record the schematic structure and wiring of the network
using the MS graphics tool MS Visio, giving details of the hardware and software
that has been installed.
Gather information: Record all contact addresses, telephone numbers, and other
important addresses, which can be used to find specific help or information (such
as the manufacturer and supplier hotline).
Check infrastructure for Layer 1: Determine cable lengths, record number of stations
and segments, evaluate network and error statistics, use a traffic generator to stress
the network and analyze a collision.
Check the state of Layer 2: Activate the network statistics or the capacity, monitor
the broadcast messages, determine and evaluate TOPS (top transmitter, top
receiver), place configuration filter over critical stations, monitor the error statistics.
8.7 Ethernet Cable Types

Table 8.8 summarizes all relevant cable types for networks according to their basic
specifications.
30
10Base-T
UTP
100 Mbps
3 - 7 Mbytes/s
10 Mbps
700 kbytes/s
10Base-T
STP
10Base-F
10Base2
10Base5
Null modem
0.5, minimum
30
D-SUB-T
2.5, minimum
100 20
9-pos.
D-SUB
RJ-45
9-pos.
D-SUB
RJ-45
100
Various
cables
RG 58/U
RG 58C/U
RG 58A/U
RG 62
RG 8A/U
UTP3 and >
no shield
100
STP 3 and >

with shield
Fiber
2000
Fiber optic
185
Various
(D-SUB)
Various
(D-SUB)
BNC-T
500
100
10 Mbps
700 kbytes/s
100
10 Mbps
2000
Cable Type
(e.g., UTP 5 = Cat.5)
30
Distance Between
Two Stations (m)
Minimum Bending
Radius (cm)
Connector
Maximum Segment
Length (m)
Data Line
115 kbps
10 kbytes/s
14 kbps
90 kbytes/s
10 Mbps
700 kbytes/s
Maximum Number of
Stations
Serial
cable
Parallel cable
Maximum Transmission
Theoretical/
Practical
Type
Table 8.8: Cable types suitable for networks
100 Mbps
3 - 7 Mbytes/s
100
100Base FX
UTP
100 Mbps
3 - 7 Mbytes/s
400
1000Base-T
UTP
1000 Mbps
25 100
1000Base-LX
1000 Mbps
3000/
single
550/
multi
optic
connector
9-pos.
D-SUB
RJ-45
9-pos.
D-SUB
RJ-45
UTP5 and >
400 without
repeater;
305 m, 1 rep.
210 m, 2 rep.
25 - 100
UTP5 and >
9-pos.
D-SUB
RJ-45
Fiber
optic
connector
UTP5 and >
3000/550
Fiber optic
1300 nm
Cable Type
(e.g., UTP 5 = Cat.5)
100
Distance Between
Two Stations (m)
Minimum Bending
Radius (cm)
100Base-TX
UTP
Maximum Number of
Stations
700 kbytes/s
Connector
Maximum Segment
Length (m)
305
Data Line
Type
Maximum Transmission
Theoretical/
Practical
Table 8.9 shows the relationship between the category classification and the link
classes according to EN 50173. The link classes (A to F) are the transmission
speeds (bandwidth), Cat.X indicates the physical properties (requirements of
cables, sockets, and connectors). The Cat.7 or Class F cable is considered to be
the "fastest" twister pair cable available on the market today.
Cat.1 cabling can be used for alarms, analog speech transmission, Cat.2 cabling
for speech, RS-232 interface, Cat.3 cabling for data transmission up to 16 MHz,
Cat.4 cabling for data transmission up to 20 MHz, and Cat.5 cabling for data
transmission up to 100 MHz. UTP cables (unshielded twisted pair) really belong to
Cat.3 as they have no use in the industrial environment. Today, S/FTP cables
(screened/foil shielded twisted pair) are state-of-the-art cables for installing UTP
sockets. ITP (industrial twisted pair) is the industrial version of S/STP
(screened/shield twisted pair), which is limited to two wire pairs.
Details of the assignment of wire pairs for twisted pair cables and other
important wires can be found on the accompanying CD-ROM.
Table 8.9: Cat. cable types

Bandwidth (class)
Class A (< 100 kHz)
Class B (< 1 MHz)
Class C (< 16 MHz)
Class D (< 100 MHz)
Class E (< 300 MHz)
Class F (< 600 MHz)
Application
ISDN based
ISDN multiplex
10Base-T, token ring
100 Mbps Ethernet, CDDI
155 Mbps ATM
Gigabit Ethernet
Cat. 3
2 km (124 mi.)
500m (1640.42ft.)
100m (328.08ft.)
-
Cat. 4
3 km (1.86 mi.)
600 m (1968.50 ft.)
150 m (492.13 ft.)
-
Cat. 5
3 km (1.86 mi.)
700 m (2296.59 ft.)
160 m (524.93 ft.)
90m (295.28ft.)
-
306

The exception to the cable assignment of twisted pairs is, for example, the
connection between two PCs. The PCs are connected using a cross link
cable. The Tx+/Tx- and Rx+/Rx- wires are crossed over for this type of
cable. You can also use this type of crossover cable if you want to connect
specific Ethernet components with one another.
8.8 Ethernet Configuration Using INTERBUS

Figure 8.10 shows a commonly found Ethernet configuration. INTERBUS
controller boards, visualization and programming PCs, and other devices are able
to communicate with one another via Ethernet.
Remote data
transmission
connection
Remote maintenance
Remote diagnostics
Service
Router with
ISDN connection
FL switch
Firewall
Visualization computer
(e.g., OPC client)
INTERBUS
controller boards with
Ethernet connection
Planning and management computer
Flexible programming computer in the field

Ethernet
INTERBUS
Fixed programming computer

(e.g., OPC server)
INTERBUS components
No realtime requirements
With realtime requirements
Figure 8.10: Structure of an Ethernet configuration with INTERBUS connection

Figure 8.11 shows an INTERBUS Ethernet configuration, which has an
INTERBUS Ethernet gateway. The gateway includes a W&T component
(Wiesemann&Theis GmbH, Wuppertal in Germany). It is integrated into INTERBUS
as a normal INTERBUS device. The INTERBUS controller board provides input
and output words, which can be retrieved from or written to Ethernet via
TCP/UDP/IP with 10 Mbps or 100 Mbps.
The paired use of the gateways means that two different INTERBUS systems can
be coupled via Ethernet. It is also possible to establish direct communication with a
host PC on the network using a suitable client or server application.
307
FL switch
Visualization computer
INTERBUS
master with
Ethernet connection
Company
network
Programming computer
Gateway: W&T GmbH

1x INTERBUS IN,
1x INTERBUS OUT,
2x 9-pos. D-SUB,
10x IN and OUT words
Ethernet
INTERBUS
gateway
Ethernet
INTERBUS
gateway
INTERBUS
INTERBUS
INTERBUS components
Figure 8.11: Structure of an Ethernet configuration with INTERBUS connection

Table 8.10 shows the difference between the transmission speed of INTERBUS for
500 KB, 2 MB and Ethernet using the 100 Mbps version. For the comparison it is
assumed that 256 devices are each connected with 8-bit I/O data.
Table 8.10: Comparison of INTERBUS and Ethernet
Medium
Transmission time
INTERBUS 500 kbaud
9.6 ms
INTERBUS 2 Mbaud
2.0 ms
Ethernet 100 Mbps
770 ms
INTERBUS controller
FL switch
FL SNMP OPC
gateway
INTERBUS
Ethernet interruption
Sends an
SNMP trap
Genesis 32
visualization
Sends an
OPC event
Sends a text
message
INTERBUS station
Figure 8.12: Ethernet configuration with SNMP traps and SMS messages
Figure 8.12 shows the practical use of SNMP-compatible Ethernet components in
association with the FL SNMP-OPC gateway and Genesis 32 from Iconics Inc. In
308
the event of an Ethernet error, a text message (SMS) is sent to the administrator's
cell phone.
8.9 Redundant Ethernet With FL Switch

The redundancy manager of the FL switch makes it possible for distributed control
systems to protect Ethernet components from long downtimes. An effective
redundancy concept is to structure Ethernet as a ring, with the closing line of the
ring only being activated by the redundancy manager switch, should a transmission
path fail. Once an Ethernet path has been interrupted, the redundancy manager
closes the fall-back circuit after only 500 ms and the Ethernet system continues to
be operational. The redundant Ethernet configuration with an INTERBUS
connection can be seen in Figure 8.13.
WAN
Visualization
computer (OPC)
Programming and startup notebook
Failure
With FL switch 3, the redundancy
manager is switched to active
The redundancy line (broken line) is only
active if a standard connection fails
FL switch 1
FL switch 2
INTERBUS
system 1
FL switch 3
INTERBUS
system 2
INTERBUS
system 3
Figure 8.13: Structure of a redundant Ethernet configuration

Each FL switch can be set as a redundancy manager switch, via a DIP switch.
However, only one of the FL switches can be set as the redundancy manager. To
determine whether a transmission error has occurred, the redundancy manager
switch sends diagnostic data packets to itself every 10 ms (each FL switch has two
MAC addresses). When an error occurs, the "inoperative" redundancy line is
closed and special data packets are sent to all other Ethernet devices so that they
can read their routing table again (table detailing internal connection data).
309
8.10 "Ethernet and INTERBUS" Workshop

1.) A protocol analyzer is used to record the following measurements from Table
8.11 to
Table 8.14 with the Ethernet problems [22] which are detailed below. Which
device(s) could be the source of the error?
1.1) An industrial system reports faulty data throughput of an existing Ethernet
connection. Once the data flow was recorded by the frames and bytes, Table 8.1 is
produced.
Table 8.11: Task 1.1
Station Station
A
B
NIC 1
NT server 1
NIC 1
Router 1
NIC 1
Switch 1
NIC 1
NIC 2
NIC 1
NT server 2
Frames
AB
7226
754
349607
1049
390
Frames
BA
19234
2539
776332
1544
690
Bytes
AB
582362
60526
178366013
4822
39002
Bytes
BA
7022173
341559
970363645
49672
63948
Errors
AB
326
45
17628
56
92
Errors
BA
0
0
0
0
0
1.2) The second system, same as the first system (task 1.1), reports complaints
about faulty data throughputs between two Ethernet devices, which then creates
Table 8.12.
Station Station
A
B
NIC 1
Switch 1
NIC 1
Router 1
NIC 1
NIC 4
NIC 2
NIC 4
NIC 3
NIC 4
Frames
AB
7226
754
349607
1049
390
Frames
BA
19234
2539
776332
1544
690
Bytes
AB
582362
60526
178366013
4822
39002
Bytes
BA
7022173
341559
970363645
49672
63948
Errors
AB
0
0
17628
56
92
Errors
BA
0
0
12563
34
234
1.3) Once the Ethernet cable has been repaired in the second system (task 1.2),
reports continue to be sent about transmission problems. A second measurement
produces Table 8.13.
Station Station
A
B
NIC 1
Switch 1
NIC 1
Router 1
NIC 1
NIC 4
NIC 2
NIC 4
NIC 3
NIC 4
Frames
AB
9726
1554
349607
78049
43390
Frames
BA
21934
12339
776332
10544
65690
Bytes
AB
158362
16026
178366013
1141822
2139002
Bytes
BA
1702173
134159
970363645
1112672
6543948
Errors
AB
0
0
17628
3456
592
Errors
BA
0
0
12563
2134
1234
310
1.4) In the fourth task, it is impossible to establish a communication link between

NIC 1 and NIC 3. A second measurement produces
Table 8.14.
Station
A
NIC 1
NIC 1
NIC 1
NIC 1
NIC 2
Station
B
Switch 1
Router 1
NIC 3
Broadcasts
NIC 3
Frames
AB
7226
754
0
1049
390
Frames
BA
19234
2539
0
0
690
Bytes
AB
582362
60526
0
4822
39002
Bytes
BA
7022173
341559
0
0
63948
Errors
AB
0
0
0
0
0
Errors
BA
0
0
0
0
0
The answers to the "Ethernet and INTERBUS" workshop can be found

on the accompanying CD-ROM.
8.11 Practical Tips

Tip 1: Configure Windows NT as the router
If a Windows NT PC has two network cards, which are configured on different
networks, data packets can be transmitted between the two networks. And by
using Service pack 3 or later, the Windows NT PC can also be used as a router
with an ISDN card.
Tip 2: Gateway address entry in Windows network settings
When the network is configured in Windows operating systems, it is essential to
enter a gateway address. This entry relates to a router that may be included in the
network.
Tip 3: Forgotten community string (password) for FL switch
To reset the customized password of a Factory Line switch back to the default
password (private or public), the Default Values menu item must be selected for
each V.24 and monitor program (e.g., hyper terminal) in system configuration 1 of
the FL switch. The default password is then reactivated.
Tip 4: Project documentation: create two wiring plans
Create two wiring plans. One plan that shows the arrangement of the Ethernet
components in rooms or installation locations (to locate the cables which are
installed). A second wiring plan that shows the logic distribution of components with
design features, software, etc. For both plans, you can, for example, use plotting
programs with symbol files such as: MS VISIO.
Tip 5: The network connection has been established but data transmission is too
slow
Special network tools such as AnySpeed or NETIO test the data throughput to
predefined IP addresses. It is possible to determine from the waveform of the
measurement, whether the data throughput has really fallen or is falling. If this is
311
not the case, then it is extremely likely that data packets are being lost. The loss of
packets can be detected through repeated packets (retransmissions). Using a
protocol analyzer (e.g., LANDecoder32) you can analyze the TCP data flow to the
TCP sequence number. If a smaller TCP sequence number packet is sent again,
even though a higher TCP sequence number packet has already been sent, then
the return to a previous point of the data flow either means that the data has not
been received by the receiver or that it has not been acknowledged by the
receiver.
Tip 6: Faulty Ethernet data communication even though the ping request has had
a positive reply
Even though the device being "pinged" with a ping request is replying successfully,
it may consider the data packets to be too big because of a fragmentation setting,
e.g., for routers. The Whats Up Gold software package from Ipswitch can be used
to easily locate such errors.
Tip 7: Change SNMP community strings (password) as soon as possible
The SNMP community strings: "public" read and "private" read/write, which are
provided by the manufacturer, must be replaced by customized passwords.
"Hackers" are familiar with these passwords and can easily gain access and cause
extensive damage.
8.12 Questions for the "Ethernet" Section

1. Why is standard Ethernet not suitable for realtime applications?
2. Why is the TCP/IP protocol more suitable for industrial automation?
3. What are the tasks of Factory Manager network management software and
what other tools are useful for network monitoring?
4. What is auto negotiation?
5. What does Store & Forward mean?
6. What do the terms multi-address, aging, and learning mean?
7. What is connection mirroring?
8. What are community strings?
The answers to the questions for the "Ethernet" Section can be found
on the accompanying CD-ROM.
312
Appendix
A Appendix
A.1 Error Codes
The error codes for G4 controller boards can be found on the

A.2 Error Codes for INTERBUS Drivers

Code (hex)
0000
0085
0086
Error Message
ERR_OK
ERR_INVLD_NODE_HD
ERR_INVLD_NODE_STATE
0087
0088
0089
008A
008C
ERR_NODE_NOT_READY
ERR_WRONG_DEV_TYP
ERR_DEV_NOT_READY
ERR_INVLD_PERM
ERR_INVLD_CMD
008D
0090
0091
0092
0096
0097
009A
ERR_INVLD_PARAM
ERR_NODE_NOT_PRES
ERR_INVLD_DEV_NAME
ERR_NO_MORE_HNDL
ERR_AREA_EXCDED
ERR_INVLD_DATA_CONS
ERR_MSG_TO_LONG
009B
009C
009D
009E
009F
00EB
0100
ERR_NO_MSG
ERR_NO_MORE_MAILBOX
ERR_SVR_IN_USE
ERR_SVR_TIMEOUT
ERR_AVR_TIMEOUT
ERR_DTI_IN_USE
ERR_STATE_CONFLICT
0101
0102
ERR_INVLD_CONN_TYPE
ERR_ACTIVATE_PD_CHK
0103
0200
0201
1001
ERR_DATA_SIZE
ERR_OPT_INVLD_CMD
ERR_OPT_INVLD_PARAM
ERR_ETH_RCV_TIMEOUT
1010
1013
1014
1016
ERR_IBSETH_OPEN
ERR_IBSETH_READ
ERR_IBSETH_NAME
ERR_IBSETH_INTERNET
Cause
The function was executed successfully
Invalid node handle specified
Node handle of a data channel that is already
closed specified
Desired node not ready
Incorrect node handle
INTERBUS master not ready yet
Access type not enabled for channel
Utility function is not supported by driver
Version 0.9
Command contains invalid parameter
Node not present
Unknown device name used
Device driver resources used up
Access exceeds limit of selected data area
Specified data consistency is not permitted
Message or command contains too many
parameters
No message present
No further mailboxes of the required size free
Send vector register in use
Invalid node called
Invalid node called
Access to coupling memory not possible
This service is not permitted in the selected
operating mode of the controller
Service called via an invalid connection
Process IN data monitoring could not be
activated
The data volume is too large
Unknown command
Invalid parameter
Time limit exceeded when receiving the data
telegram
The IBSETHA file cannot be opened
The IBSETHA file cannot be read
The device name cannot be found in the file
The system cannot read the computer
name/host address
Appendix
313
A.3 Error Codes for the INTERBUS OPC Server

Code (hex)
E000 0000
8000 0000
4000 0000
0001 0000
0002 0000
E001 0000
E000 0010
Error Message
ERR_SEV_ERR
ERR_SEV_WARN
ERR_SEV_INFO
ERR_FAC_INIFILE
ERR_ETH
ERR_BASE_API
ERR_INVALID_ITEM_INDEX
E000 0011
E000 0020
E000 0021
E000 0022
ERR_NO_IB_CONNECTED
ERR_NEG_CNF
ERR_TIMEOUT
ERR_ALLOC_MEM
E000 0030
E000 0031
ERR_NO_SYS_ITEM
ERR_WRONG_DIRECTION
E000 0032
E000 0033
E000 0034
ERR_ITEM_NOT_FOUND
ERR_INVALID_RANGES
ERR_NO_MPM_AREA_DEFINED
E000 0040
E000 0041
ERR_OPEN_FILE
ERR_NO_CONTROLLER_SECTION
E000 0042
E000 0043
E000 0044
ERR_INVALID_CONTROLLER_NO
ERR_EMPTY_MXI_STRING
ERR_SVC_SYNTAX
E000 0045
ERR_SVC_SERVICE_FAILED
E000 0046
ERR_NO_HOST_ADAPTION
E000 0050
ERR_XDTA_UNDEFINED
E000 0051
ERR_DATAAREA_TOO_LONG
0000 0001
ERR_NO_MORE_CTRL
0000 0002
ERR_INVALID_
0000 0003
0000 0004
0000 0005
E000 0052
E000 0053
ERR_READ_INI_FILE
ERR_OPEN_INI_FILE
ERR_NO_CFG_UTIL_PTR
ERR_MXI_HD_UNDEFINED
ERR_DTI_HD_UNDEFINED
Cause
Error base for DDI and API errors
The OCS toolkit requested the
parameters of an invalid item
INTERBUS not connected, no items
Negative confirmation received
Timeout elapsed
Memory allocation failed,
all items may not be available
The specified item is not a system item
The read or write operation, respectively
is not permitted for this item (-> access
rights)
The requested item could not be found
The address is out of range
The MPM start address is greater than
the end address, read/write action not
performed
Server cannot open file
The server cannot read the cfg file
correctly, check syntax, especially the
sections [BEGIN_CONTROLLER_
SECTION], etc.
The controller number is out of range
MXI string not found
Syntax error in svc file, execution
aborted
Service
returned
with
negative
confirmation, timeout or SendMsg
request failed
The controller type name is not
recognized by the server
The controller does not know whether
ISA or ETH is the target (for XDTA
access)
The requested data array is too long, INI
file errors
No more controller sections found in the
ini file
One or more entries in the current
controller section are invalid
A line cannot be read correctly
File cannot be opened
314
Appendix
OCI Errors
E000 0060
E000 0061
ERR_OCI_NOT_INIT
ERR_INIT_FAILED
E000 0062
E000 0063
E000 0064
E000 0065
E000 0066
ERR_EXEC_FAILED
ERR_UNKNOWN_DATATYPE
ERR_PLC_STOP
ERR_RESOURCE_STATE_INIT
ERR_CONVERT_VALUE
E000 0067
E000 0068
E0000069
E000 006A
E000 006B
ERR_OCI_WRITE
ERR_OCI_READ
ERR_DOWNLOAD
ERR_OCI_TIMEOUT
ERR_CONTROLLER_RESET
0000 0001
0000 0002
0000 0003
0000 0004
ERR_NO_SOCKET
ERR_NON_BLOCKING
ERR_SEND_DATAGRAM
ERR_ECHO_RECEIVE_TIMEOUT
The OCI access class is not instantiated

OCI OpenCOM failed or library not
loaded
OCI execution failed
Returned IEC data type is unknown
Set all values to bad quality
The OCI access class is not instantiated
The value cannot be converted into the
appropriate variant
Write process was unsuccessful
Read process was unsuccessful
Switched from PLC_ON to PLC_RUN
Timeout error from OCI execute
The reset counter of the controller board
has changed
Error opening socket for UDP
Error setting non-blocking mode
Error sending data telegram
No message received within timeout
Figure A. 1: Protocols in the ISO/OSI layer model [11]
Physical
DataLink
Network
Transport
Session
Presentation
ISO/OSI Layer
7
Application
Domain
File
Electronic Terminal
Usenet
Diagnostic
name
transfer
mail
emulation
news
applications
service
Domain SimpleNetwork
Simple
Usenet
File
Management
Mail
Telnet
News
Name
Transfer
Service
Protocol
Transfer
Protocol
Transfer
Protocol
Pro tocol
(Telnet)
Protocol
(DNS)
(SNMP)
(FTP)
(UNTP)
RFC
RFC1098,
(SMTP)
RFC854
RFC959
RFC977
1034
1157,1212
RFC821
Transmission ControlProtocol
User Datagram Protocol
(TCP)RFC793
(UDP) RFC768
Internet
Address
Control
Resolution
Message
Internet Protocol
Protocol
(IP) RFC791
Protocol
(ARP) RFC903
(ICMP)
RFC792
Token
Ethernet
DQDB
FDDI
ATM
Ring
Twisted
FO
Coaxialcable
Radio
Laser
Pair
Protocols
Network access
Local
network
Internet
Host-to-host
communication
Application
Type of
communication
DOD Layer
Appendix
315
A.4 Protocols in Relation to the ISO/OSI Layer Model
316
Appendix
A.5 Motorola and Intel Address Format

INTERBUS controller boards are fitted with a Motorola processor on the master
side. Controller boards with a coprocessor expansion are fitted with an Intel
processor on the COP side. However, intelligent INTERBUS devices can also be
equipped with an Intel processor. When accessing data or storing data in the MPM
address areas, the different address formats of Motorola and Intel processors
come into conflict. The numbering of the individual bits within the bytes is the same
for both processors. Access to bytes is also the same. However, if a 16-bit or 32-bit
value is accessed, the bytes are the other way around. Figure A. 2: illustrates the
different addressing methods of Motorola and Intel for WORD (16-bit) and DWORD
(32-bit).
WORD access for Motorola
Byte
14
15
12
13
10
11
8
9
6
7
4
5
2
3
0
1
WORD address
DWORD access for Motorola

Byte
12
13
14
15
8
9
10
11
4
5
6
7
0
1
2
3
DWORD address
7
6
5
4
3
2
1
0
3
2
1
0
WORD access for Intel

Byte
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
DWORD access for Intel
Byte
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
Figure A. 2:: Representation of different addressing methods

Table A. 1 below lists G4 INTERBUS controller boards with a coprocessor from
Phoenix Contact, for which a BYTE and WORD rotation may be required.
Table A. 1: INTERBUS controller boards with coprocessor
IBS 24 RFC/486DX/ETH-T
IBS ISA FC 486DX/I-T
RFC ETH 450-IB
IBS ISA SC 486DX/I-T
RFC ETH 430-IB
Appendix
317
A.6 Glossary
This is the ABC guide to INTERBUS [24] and Ethernet networks [23].
1, 2, 3, and 4-wire termination
1, 2, 3, and 4-wire terminations are connection methods for analog IN and OUT
signals of sensors and actuators. Ensure the correct wire termination is used.
100Base-T4
10 Mbps (4 twisted pairs)
The 100Base-T specification has a physical star structure with a hub as the center
point. A Category 3 cable with an impedance of 100 , RJ-45 connectors, and a
maximum length of 100 m (328.08 ft.) is used. The aim is to achieve 10 times the
transmission speed of
100 Mbps, while at the same time maintaining the Category 3 bandwidth of 25 MHz
by using all four wire pairs. In 100Base-T4, three pairs are always used
simultaneously for each data direction.
100Base-TX
100 Mbps (2 twisted pairs)
100Base-TX uses a Category 5 cable with two wire pairs for 100 Mbps
transmission. Cables, RJ-45 wall boxes, patch panels, etc. must be designed
according to this category for a minimum transmission frequency of 100 MHz.
10Base2
10 Mbps (coaxial cable)
Ethernet transmission paths with a transmission rate of 10 Mbps based on coaxial
cables. 10Base2 is also referred to as Cheapernet or Thin Ethernet. The thin and
flexible 10Base2 coaxial cables have an impedance of 50 . The start and end of a
segment (185 m [606.96 ft.], maximum) must be terminated with 50 terminal
resistors. The attenuation of the coaxial cable and the possible number of connectors
(BNC T pieces) limit a 10Base2 segment to 185 m (606.96 ft.) maximum, with a
maximum of 30 connections. A maximum of four repeaters is permitted between two
stations.
The disadvantage of 10Base2 results if the cable is broken, e.g., by removing a
connector, as this causes a downtime of the entire network segment.
10Base5
10 Mbps (coaxial cable)
10Base5 is based on a coaxial bus cable with an impedance of 50 and a
maximum permissible length of 500 m (1640.42 ft.) (yellow cable). Vampir-Krallen
are used to tap the signals directly from the bus cable, without it being interrupted
by a connector or similar. The send, receive, and collision information is received
separately by a transceiver and is made available at a 15-pos. D-SUB connector.
The termination device is connected to this transceiver via an 8-wire TP cable
(50 m [164.04 ft.], maximum). A maximum of four repeaters is permitted between
any two stations and when implementing networks with a tree structure any
number of repeaters can be used. The advantages of 10Base5 are the long
318
Appendix
segment lengths and the high number of possible connections per segment
(maximum of 100). The disadvantages include the use of external transceivers and
the inflexible yellow cable.
10Base-T
10 Mbps (twisted pair)
The 10Base-T cable is designed in a star formation and starts at a hub or switch, the
central components within the network. The cable (Category 3) has at least two
twisted pair wires with an impedance of 100 , whereby the data is transmitted
separately in the transmit and receive direction. 8-pos. RJ-45 connectors are used
with the pairs connected to pins 1/2 and 3/6. The maximum length of a segment
(connection from hub to termination device) is 100 m (328.08 ft.). Cable breaks or
removed connectors, which result in the downtime of the entire segment in all
physical bus architectures, are limited in 10Base-T to just the connection between
the hub and termination device.
7-segment display
The 7-segment display is an indication element and is used for diagnostic purposes.
The
7-segment display is used, for example, on the IBS DCB/I-T controller board.
ActiveX
A software interface technology based on OLE developed by Microsoft. The
disadvantage is that it can only be run on Windows platforms and only enables
access up to the operating system level. ActiveX components from Phoenix
Contact include, for example, DIAG+, which can be integrated into an existing
visualization as ActiveX.
Addressing
In INTERBUS addressing, a distinction is made between physical (automatic) and
logical (user-defined) addressing. Physical addressing is the assignment of
process data to addresses, according to the physical location of the devices in the
INTERBUS system. Logical addressing is the assignment of process data to
memory areas within the INTERBUS controller board by the programmer.
Administrator
The administrator is the system manager or service engineer with unrestricted
access rights in the network/PC. He/she is responsible for network management
and upkeep.
API (Application Program Interface)
API is an interface for programs or applications. It is specific to the programming
language and operating system.
Application program
The application program or application, has been programmed for users and is
used to exchange IN and OUT process data with the controller board via specified
interfaces.
Appendix
319
ARP (Address Resolution Protocol)

ARP (Internet standard RFC-826) is used to determine the Ethernet address of a
network device that belongs to an IP address. The determined assignments are
managed on each individual PC in the ARP table. In Windows operating systems,
you can influence the ARP table using the ARP command.
Attenuation
The attenuation defines the reduction in amplitude of a pulse at the end of a cable.
The attenuation depends on the cable length and the pulse frequency. The
attenuation becomes greater with increasing frequency and increasing cable
length. The attenuation of a cable is defined as follows, attenuation = 20 x log x U
input pulse : U output pulse (decibels, dB).
AUI (Attachment Unit Interface)
The AUI is used to connect an external Ethernet transceiver. The transceiver splits
send, receive, and collision information and provides the data at a 15-pos. D-SUB
connector. It is connected to a termination device via an 8-wire TP cable with a
maximum length of 50 m (164.04 ft.). In the past, the AUI was mainly used to
connect termination devices to 10Base5 transceivers. The AUI can be found on the
PC WORX INTERBUS controller (IBS RFC 486DX ETH).
Autosensing hubs
In addition to standard Ethernet components for 10Base-T (10 Mbps) and
100Base-TX (100 Mbps), there are also autosensing components, which
automatically detect whether the connected termination device is operating with 10
or 100 Mbps. Autosensing hubs are used to integrate older 10Base-T devices into
new 100Base-T networks without any problems.
Autostart/autorestart
Autostart or autorestart refers to the process of automatic INTERBUS startup after
an INTERBUS stop.
Baud
Unit of measurement for data transmission. One baud corresponds to one
character per second. The baud rate is the speed of data transmission (bps).
Bit
The bit is the smallest digital binary data unit, which can only represent two states
(0, 1).
BNC (Bayonet Neill Concelmann)
The BNC connector has a bayonet joint (quarter-turn fastener) and is used to
connect two coaxial cables. BNC connectors are used in 10Base2 networks for the
mechanical connection of the RG-58 cable (Cheapernet).
320
Appendix
Branch
The INTERBUS branch is a subring system that branches off from the remote bus.
A branch is connected using a bus terminal module. The bus terminal module
provides the means for disconnecting the branch.
Broadcast
A broadcast is sent to all (Ethernet) devices. A typical broadcast application is the
ARP request. Other protocols, such as RIP, use broadcast messages. Broadcast
messages are not sent via routers or jumpers.
Bus error
The INTERBUS bus error is a message from the controller board reporting that
INTERBUS has been stopped, because a data cycle could not run without any
errors.
Bus quality
The INTERBUS bus quality is indicated by the bus quality bit in the diagnostic
status register and describes the ratio of error-free and faulty INTERBUS data
cycles.
Bus segment
An INTERBUS bus segment consists of a remote bus device and connected local
bus devices. The incoming INTERBUS remote bus cable is also part of a segment.
Bus segment number
The INTERBUS segment number is assigned during logical addressing and
describes the address position of the segment within the summation frame
protocol.
Bus system
In the bus system, several termination devices share one data line (bus line).
Access methods are used to control the access rights.
Bus terminal module
An INTERBUS bus terminal module is a device, which is connected to the remote
bus and provides a branch to a remote bus or local bus. The bus terminal module
regenerates the data signals using a repeater and isolates the potential of the bus
segments.
Bus timeout
The bus timeout is a time that can be set in the INTERBUS system. If a data cycle
cannot run without any errors within the bus timeout, INTERBUS is stopped.
Bus topology
The bus topology describes the structure of a bus system. The INTERBUS
topology is a ring structure.
Bus warning time
Like the bus timeout, the INTERBUS warning time is a time that can be set in the
Appendix
321
system. If error-free data transmission cannot be ensured within the bus warning
time, the warning bit is set in the diagnostic status register on the controller board.
Byte
The byte is a digital unit, which consists of 8 bits. In total, 256 different states can
be represented in one byte.
Cheapernet
Another name for Ethernet based on 10Base2.
Client
The client is an application, which establishes a connection to a server, to use the
services that are available there. A client is, e.g., the web browser, which connects
to a web server. All services such as mail, FTP, Telnet, OPC, etc. work according
to the client/server principle. The client is the "requester" and the server the
"provider".
Client/server structure
A client/server structure describes a system with "decentral intelligence", whereby
the client requests services or data from the server and the server provides them.
Coincidence factor
The definition of the coincidence factor for an output module is the ratio of the
permissible total current (total output current) to the sum of all maximum rated
currents of a multi-channel output module, which operates in the most unfavorable
combination of permitted operating conditions.
Com server
Com servers are termination devices in TCP/IP Ethernet networks, which provide
interfaces for serial devices and digital I/O points via the network. Com servers can
be used as both servers and clients.
Communication reference (CR)
In the INTERBUS system, the CR or communication reference is used during PCP
communication. The communication reference is a unique number, which is
assigned to each PCP device. It is used during communication between the
INTERBUS controller board and the PCP device. In total, there are 64 possible
communication references, whereby communication reference 1 is assigned to the
controller board itself.
The INTERBUS communication register is an input and output address area where
the control system is mapped. It is an interface for driver blocks and management
services, which is used to transmit process data. The communication register is a
two-word address area within the INTERBUS control system.
Communication relationship list (CRL)
The communication relationship list contains all the connection parameters
322
Appendix
required for PCP communication. The communication relationship list is stored on

the controller board.
Communications power
The INTERBUS communications power supplies the module electronics of the
INTERBUS device and should always be supplied separately from the I/O voltage.
Configuration frame
The INTERBUS configuration frame defines the bus architecture including the
device-specific parameters, such as ID code and length code or the logical device
number and group number, and is stored in the memory area of the controller
board. The configuration frame can be specified by the user or read from the
existing INTERBUS system by the controller board.
Controller board
The INTERBUS controller board, also referred to as master or controller, is used to
operate the INTERBUS system.
Controller error (CRTL)
The controller error is a message from the INTERBUS controller board indicating
that very high-priority errors are present on the controller board or controller.
CR
See Communication reference
CRL
See Communication relationship list
Cycle time calculation
As the INTERBUS cycle time is predictable, the interval that the INTERBUS
system requires can be calculated in advance. This depends on the amount of user
data transmitted, as the proportion of user data in relation to protocol data is 60%.
Cycle time
The cycle time is the amount of time the INTERBUS system requires to read all
data from the INTERBUS devices and to write data to all the devices. Therefore,
during the cycle time all data is transmitted from the field devices to the controller
boards and vice versa. As a guide, the cycle time is usually an interval of 1 to 10
ms. The cycle time increases linearly with the number of I/O points.
The CRC tests the data integrity of INTERBUS for data transmission with the
summation frame protocol and ensures error-free transmission of INTERBUS data.
A CRC error is a data transmission error that was detected with the CR check.
Data consistency
In the INTERBUS system, data consistency is the consistent transmission of a
defined data width that can be read from or written to a memory area without
Appendix
323
interruption. In the INTERBUS system, data consistency can be set using firmware
commands.
Data transmission integrity
Data transmission integrity ensures the integrity of the INTERBUS system through
use of the loop-back word and the CR check.
DDE (Dynamic Data Exchange)
A DDE is a relatively old system for exchanging data between two Windows
programs. There is a DDE server, e.g., from Wonderware, which is used to access
INTERBUS input and output data. DDE is no longer considered modern and
communication exchange is too slow. DDE was replaced by interfaces such as
OPC or CALL interfaces. DDE was used until about 1997.
Determinism
Determinism is the behavior of INTERBUS in relation to INTERBUS cycles, which
are predictable in terms of time. The length of each INTERBUS cycle is consistent
and can be calculated.
Device code
The INTERBUS device code is a data word consisting of a length code and ID
code and indicates the properties of the INTERBUS device.
Device name
Name of the INTERBUS device to which a data channel is to be opened. The
name defines the INTERBUS controller board (board numbers 1 to 8) and the
MPM accessor (host or INTERBUS master).
DHCP (Dynamic Host Configuration Protocol)
The DHCP is the dynamic, time-limited assignment of IP addresses from an
address pool. It is used to automatically configure PCs centrally and therefore
uniformly in a TCP/IP network, i.e., without manual access. The system
administrator specifies how IP addresses are to be assigned and how long they are
assigned. The result of this method is that each network device receives another IP
address upon every new connection.
The diagnostic parameter register contains information about an INTERBUS fault
or an INTERBUS error. The corresponding error location or error code is given in
the diagnostic parameter register.
Diagnostic register
The diagnostic register consists of the diagnostic status register and the diagnostic
parameter register. Both 16-bit words contain information about the INTERBUS
state.
The diagnostic status register contains general information about the state, the
diagnostic parameter register, the error location or error source in the event of an
error.
324
Appendix
Direct link data

INTERBUS direct link data is an optional setting in, e.g., CMD and PC WORX
software, so that input data can be directly transmitted to output data without any
influence by the application program.
DLL (Dynamic Link Library)
The DLL is a software library, which contains functions and procedures that are
accessed by a running application program. Dynamic means that this library is
dynamically integrated into the program, whereby several programs are available
and can thus also be used simultaneously.
DNS (Domain Name Service)
Ethernet are addressed using numeric IP addresses (149.208.17.57). As names
are a better indicator than numbers, a DNS is used. If the user specifies a domain
name for addressing, the TCP/IP stack requests the appropriate IP address at the
next DNS server. The DNS server contains a list of the IP addresses of a network
or the domains, which are assigned to the corresponding host names.
DNS server
DNS servers establish domain name connections with IP addresses.
DRIVECOM
DRIVECOM is a user group, which was founded by leading drive manufacturers
and uses the INTERBUS system to network its devices. The device profile contains
the required definitions.
EMC (electromagnetic compatibility)
EMC is the capability of an electrical device or system to operate without faults in
an electromagnetic environment without affecting this environment in an
unacceptable manner. Source: EN 50178: 1997.
EPROM
The EPROM is a programmable memory, which can be erased by UV light and
reprogrammed.
Ethernet
Ethernet is the most frequently used transmission technology in local networks.
Ethernet address (MAC)
The fixed physical address of a network component in Ethernet.
Extended installation remote bus
The extended INTERBUS installation remote bus is an installation remote bus with
a current carrying capacity of 16 A instead of the normal 4.5 A.
Fast Ethernet
Fast Ethernet is the upgrade of 10Base-T topologies from 10 Mbps to 100 Mbps.
Appendix
325
Fieldbus
The fieldbus is a digital communication network used to connect process devices
and control systems.
Firewall
A firewall is an Ethernet network component, which couples an internal network
(e.g., the Intranet) to a public network (e.g., the Internet). Access to the other
network can be limited or completely blocked depending on the access rights, the
service used, and the authentication and identification of the network device.
Another feature is that the data can be encoded, if, for example, the public network
is only used as a transition between two physically separated parts of an Intranet.
Firmware
Firmware is software that is run on INTERBUS controller boards in which hardware
functions are defined.
Frame switching
Frame switching involves store and forward, multi-addressing, address evaluation,
prioritization, and tagging. The Factory Line switch operates in this mode and
saves, learns, and evaluates source and target addresses to achieve an effective
network capacity.
FTP (File Transfer Protocol)
FTP (RFC 959) is a TCP/IP protocol, which transmits files between two network
devices. The FTP operates according to the client/server principle. The FTP
command <IP address of the FTP server> establishes a connection to the FTP
server, the user name and password are then requested. If the connection is
established, the FTP server can be accessed by entering additional commands
and parameters.
Function block
The function block in an application program, such as Step 5 or 7 and PC WORX,
is always used to process constantly recurring functions. Parameters are
transferred and often instantiated in these function blocks.
Function parameter register
The INTERBUS function parameter register is a register that transfers parameters
to the functions.
Function start register
The INTERBUS function start register is a register via which the functions defined
by the user can be started.
Function status register
The INTERBUS function status register is a register that displays the status of
executed functions.
Gateway
Gateways connect various networks with one another and are used to translate
326
Appendix
different communication protocols. An INTERBUS gateway is an INTERBUS

remote bus device that is used to connect an INTERBUS system with a data
network with the same or different properties.
Group
INTERBUS devices can be combined into groups. These groups can be switched
on or off by the application program. If the INTERBUS device within a group is a
local bus device, the entire local bus is switched off where this local bus device is
located.
HCS cable
The HCS cable is a fiber optic cable that consists of a glass fiber core and plastic
sheathing. In the INTERBUS system, the HCS cable can be used as a remote bus
cable and is 300 to 500 meters long (984.25 to 1640.42 ft.).
HHOP
HHOP is the hand-held operator panel or operator interface.
High-level language
A high-level language is a programming language in which the language
statements are no longer directly related to the machine commands (machine
language). Examples of high-level languages include C, C++, Delphi , and Visual
Basic.
HLI
The HLI is a software interface, which offers application programmers an easy
solution when developing control applications in high-level language.
HMI (Human Machine Interface)
HMI are operating and display units, which can also be used, e.g., to control
machines.
Host
The host is the name for the control or computer system into which the INTERBUS
controller board is integrated.
Appendix
327
Hub
A hub (star coupler) enables several network devices to be actively connected with
one another in a star formation. Data packets that are received at one port are
output at all the other ports at the same time.
Hybrid transmission method
The hybrid transmission method enables process data and parameter data to be
transmitted simultaneously.
I/O voltage
The INTERBUS I/O voltage is supplied directly and separately from the
communications power in the INTERBUS module and is used to supply the I/O
devices.
ICMP (Internet Control Message Protocol)
The ICMP (RFC-792) is used to transmit status information and error messages
between
IP network nodes. ICMP makes it possible to request an echo (ping). In this way, it
is possible to determine whether a destination can be reached.
ID code
Each INTERBUS device has an ID code. This identifies each INTERBUS device by
its type, whether it be, for example, an analog or digital local bus module, a remote
bus device, or even a PCP device.
ID cycle
The connected INTERBUS configuration is transmitted to the controller board using
the ID cycle. For example, the ID code and the process data length are transmitted
to the controller board.
IEC 61131
IEC 61131 is an international standard, which describes the structure and
programming of control systems and the communication between them in five parts
and several supplementary papers.
INA
The subindex of volatile parameters in PCP communication. Has no function.
Index
The index is an INTERBUS parameter in PCP communication and is used to
address a PCP object.
Input/output modules (I/O modules)
INTERBUS I/O modules are INTERBUS local bus devices, which can be installed
as digital or analog sensors and actuators.
328
Appendix
Installation local bus

The installation local bus (INTERBUS Loop, INTERBUS Loop 2, INTERBUS SLine) connects installation local bus devices. The installation local bus is used to
network sensors and actuators that are centrally distributed on machines or in
systems. The installation local bus is connected to the remote bus using a bus
terminal module. The bus terminal module converts the remote bus signals to
installation local bus signals, and provides the supply voltage. The installation local
bus is a ring, the first device of which is connected to the bus terminal module.
There is a cable back to the bus terminal module from the last installation local bus
device.
Installation remote bus
The INTERBUS installation remote bus is a variant of the remote bus, which as
well as the wires for data transmission, also carries the supply voltage for the
connected I/O modules. The voltage is supplied via the bus terminal module.
INTERBUS
INTERBUS is a fieldbus system standardized according to EN 50254 and IEC
61158 for the serial transmission of data from the sensor/actuator area.
INTERBUS Club
The INTERBUS Club Deutschland e. V. is a group of manufacturers who offer
products with INTERBUS interfaces. There are INTERBUS clubs throughout the
world.
INTERBUS operating state
The INTERBUS operating states are READY, ACTIVE, and RUN. READY - the
controller board is ready to operate, ACTIVE - the configuration frame has been
activated, and RUN - INTERBUS is running data cycles.
Internet
The Internet is the largest network system in the world, which offers connected
network devices an almost unlimited communication infrastructure. The use of
TCP/IP enables network devices to use Internet services such as e-mail, FTP,
browser services like
HTTP, etc., independent of the platform.
Intranet
A self-contained network (only within a company), within the limits of which network
devices can use standard Internet services such as e-mail, FTP, browser services
like
HTTP, etc. Often in the Intranet there is also a connection enabling access to the
Internet via routers or firewalls.
IP (Internet Protocol)
The IP is a protocol that enables the connection of devices that are located in
different networks.
Appendix
329
IP address
The IP address is a 32-bit number, which uniquely identifies every network device
in the Internet or Intranet (e.g., 149.208.16.1). It consists of a network part (net ID)
and a user part (host ID).
ISDN router
ISDN routers enable two networks to be connected with each other via the ISDN
network of a telephone network provider. In addition to the normal functions of a
router,
ISDN routers also handle the ISDN connection.
Jumper
Jumpers connect Ethernet subnetworks with one another and use the Ethernet
address to determine which packets the jumper will or will not allow. The
information required for this is taken from tables, which must be specified by the
administrator according to the model or dynamically created by the jumper itself. A
jumper does not differ from a switch in this respect.
LAN (Local Area Network)
A LAN is a local network within a restricted area, which uses a transmission
medium.
LBST
The LBST is a jumper in the connector for the outgoing interface, which indicates
that another local bus device follows.
Length code
The INTERBUS length code indicates the number and representation format of the
process data of INTERBUS devices.
Local bus (LB)
The INTERBUS local bus connects local bus devices to a remote bus terminal
module. The local bus is available in several versions, e.g., the ST local bus,
installation local bus,
Inline local bus, fiber optic local bus or local bus formerly known as peripheral bus.
The communications power is carried from the bus terminal module to the local bus
devices via the local bus.
MAC ID (Media Access Control)
The MAC ID is the fixed, physical address of a network component.
Master/slave procedure
The master/slave procedure is the access method for INTERBUS data exchange.
The INTERBUS controller board operates according to the master/slave principle
and defines the hierarchy in INTERBUS, i.e., each transmission is initiated by the
master. Each communication from the INTERBUS devices passes via the master.
The master defines the cycles and controls the entire data transmission in the
INTERBUS system. With the master/slave principle, data transmission conflicts do
not occur like in message-oriented transmission.
330
Appendix
MIB (Management Information Base)

The MIB is a group of variables in a tree structure, which represent the different
values of SNMP-compatible devices, such as Factory Line components.
MPM (Multi-Port Memory)
The MPM is a memory on the INTERBUS controller board, which several
components can access and thus exchange data.
NAT (Network Address Translation)
The growth of the Internet has meant that free IP addresses have become scarce.
NAT is used where company networks are connected to the Internet. The company
network is connected to the Internet via a NAT-compatible router, however,
internally it operates with a separate IP address area that is independent of the
Internet. The network can only be addressed externally via a single or small
number of IP addresses. Using the port number in the received TCP/IP packet it is
rerouted to a specific internal network device.
Nibble
The nibble is a 4-bit object, which was introduced for hexadecimal notation.
Node handle
A node handle identifies a data channel open to a node.
Node
An INTERBUS MPM accessor with an associated Device Driver is known as a
node.
Object
An object is a data block, which is used in INTERBUS PCP communication and
describes attributes (data type access rights) in more detail.
OCI (Open Communication Interface)
OCI is an older interface for 16-bit visualizations, which was used up until 1999.
Today, the OCI is only used "invisibly" within the OPC server.
OLE (Object Linking and Embedding)
OLE is a Microsoft-developed extension of DDE technology for integrating
Microsoft applications into other Microsoft applications. OLE is the prerequisite for
OPC.
OPC (OLE for Process Control)
OPC is a powerful and modern connection between automation components with
control hardware and field devices. In addition, it enables the integration of Office
products and information systems. OPC is based on the Microsoft Distributed
Component Object Model (DCOM) and therefore can also be used in distributed
PC networks.
Appendix
331
OPC server
The OPC server is, e.g., the link between an INTERBUS controller board and an
OPC client visualization. The INTERBUS OPC server is a non-window-based
software package, which establishes communication links between OPC clients
and INTERBUS controller boards.
Operating mode
The INTERBUS operating modes are synchronous (bus and programsynchronous), asynchronous, and asynchronous with synchronization pulse. These
operating modes define the time when the application program accesses the
INTERBUS controller board.
Outgoing interface
The outgoing INTERBUS interface (OUT 1) is the INTERBUS interface to an
outgoing remote bus device on the same INTERBUS level.
Parameter data
In INTERBUS, parameter data is transmitted via the parameter channel (PCP).
Data records are transmitted to intelligent devices, such as external frequency
inverters or controllers, which, for example, are required in the startup phase of
machines. Parameter data and process data is transmitted at the same time.
However, this is done over several INTERBUS cycles, which means they are
divided into small units. The parameter data is divided by the INTERBUS controller
board.
PCP (Peripherals Communication Protocol)
The PCP belongs to the INTERBUS protocol and controls the transmission of
parameter data. The parameter blocks are transmitted to the process data
simultaneously, but are split for a parameter window in the summation frame
protocol. The INTERBUS system transmits parameter data one INTERBUS cycle
at a time, until it has arrived at the device or controller board. A part of the
parameter record is transmitted in each INTERBUS cycle via PCP. PCP does not
adversely affect the transmission of process data.
Peripheral fault (PF)
The peripheral fault is not an error, but a message indicating that the INTERBUS
device, e.g., the I/O voltage is not present or a short circuit has occurred at its
outputs. The INTERBUS cycle is not interrupted. The INTERBUS system remains
operational.
Ping (Packet Internet Groper)
Ping is used for diagnostics in TCP/IP networks. This function is used to check
whether a specific device exists in the network and whether it can be addressed.
Ping works with the ICMP protocol, which is based on the IP protocol. If a network
device transmits an ICMP request by issuing the ping command, the addressed
station returns an ICMP reply to the sender. The PING <IP address> command
called in the DOS box requests a reply from the network device specified with the
IP address.
332
Appendix
PPP (Point to Point Protocol)

PPP is an extended successor to SLIP and has improved error correction. Just like
SLIP, PPP enables TCP/IP devices, which do not have a LAN connection, to be
integrated into TCP/IP networks via serial interfaces.
Preprocessing
INTERBUS preprocessing is a program that is processed on the controller board
between two INTERBUS cycles. It can be generated in CMD or PC WORX and is
used to preprocess time-critical data, as this data is processed quicker than the
actual application program on the PLC or the host system.
Process data
Process data is input and output information sent to and from INTERBUS devices,
which is updated with each INTERBUS cycle. This information is transmitted at
regular intervals in the process data channel. OUT process data is transmitted from
the controller board to the INTERBUS devices and in the same cycle, IN process
data is read from the INTERBUS devices to the controller board.
Profile
A profile, e.g., the DRIVECOM profile, defines the specification for a particular
device group. These definitions standardize the important parameters of the
devices and all devices can be addressed in the same way. The profile number is
required for the designation of a device profile, e.g., 21 for the DRIVECOM profile.
Protocol efficiency
Protocol efficiency is the efficiency of the transmission protocol, i.e., the percentage
of data that is user data. The INTERBUS system has a very high protocol
efficiency, which is determined by the summation frame method.
RBST
The RBST is a jumper in the INTERBUS remote bus connector of the outgoing
interface and indicates that another remote bus device follows.
Realtime
In terms of INTERBUS, realtime means that the processing time of INTERBUS
data is short compared to the response times of the process or the application
program and can therefore be ignored.
Reconfiguration button
Occasionally INTERBUS modules have a reconfiguration button, which can be
pressed for a reconfiguration. When the reconfiguration button is pressed a
peripheral fault is sent to the controller board and can trigger a specific action
(switch devices).
Remote bus
The INTERBUS remote bus connects remote bus devices to the controller board.
The remote bus is installed with a remote bus cable between two remote bus
devices. The remote bus is available in several versions, such as copper, fiber
optic, and infrared.
Appendix
333
Remote bus (RB)

see Remote bus
Remote bus branch
The INTERBUS remote bus branch is the branch of a remote bus terminal module.
This branch is an additional interface in which a local bus or remote bus is opened.
In total, 16 INTERBUS levels or INTERBUS branches can be opened.
Remote bus device
An INTERBUS remote bus device is an INTERBUS device with a remote bus
interface. It can be a bus terminal module, remote bus device with I/O or an
intelligent INTERBUS device.
Repeater
In local networks, a repeater is used to connect two (Ethernet) segments to expand
the network by a single segment. Repeaters forward data packets from one
network segment to another, whereby they "regenerate" the electrical signals, but
leave the contents of the data packet unchanged. Each INTERBUS bus terminal
module has a repeater function.
RIP (Routing Information Protocol)
Routing protocols (RFC-1058) such as the RIP are used to send modifications of
routes between two networked systems to the relevant systems and to thus enable
a dynamic modification to be made to the routing tables.
Router
Routers connect two different networks, whereby in contrast to jumpers, the IP
address is used instead of the Ethernet address to determine which data packets
are to be sent.
Sensor
An element, which converts a physical quantity into an electrical one. The sensor
determines the process variables.
Server
Servers are applications, which accept connections from clients and provide the
corresponding services. The most widely known server is the web server, which
accepts connections from a web browser. Almost all Internet services such as mail,
FTP, Telnet, socket, etc. work according to the client/server principle. See also
Client.
Single error
An INTERBUS single error is often a data transmission error (CRC error), which
does not cause the INTERBUS system to stop and does not generate further error
messages.
SLIP (Serial Line Internet Protocol)
SLIP (C 1055) is an easy method of transmitting TCP/IP data packets via serial
334
Appendix
point-to-point connections. This enables termination devices, which do not have a

LAN connection, to also be integrated into the network via the serial interface. SLIP
uses a very simple algorithm, which does not have a method for data integrity.
SLIP router
A SLIP router makes the hardware and functions available, to integrate serial
termination devices that are available via a TCP/IP stack into a network.
SNMP (Simple Network Management Protocol)
SNMP (RFC 1441) is a protocol that the majority of network device manufacturers
have agreed on. SNMP is based on IP and uses the UDP protocol for data
transmission. The SNMP protocol makes it possible to read values from devices or
to determine the values in devices.
STP (Shielded Twisted Pair)
Shielded data cable with two cable wires that are twisted together.
Subnet mask
The subnet mask is a 32-bit value that determines which part of the IP address the
network addresses and which part the network device addresses.
Summation frame (protocol, method)
The INTERBUS system uses the summation frame as a transmission protocol. The
advantages of the summation frame include efficient data transmission due to the
relatively low protocol overhead. The summation frame is a transmission protocol
in which all physical INTERBUS devices are treated as if they were one logical
device. All process data is transmitted simultaneously to all devices during a cycle.
On the basis of the location of the information in the summation frame, each device
can accept the data that is determined for it.
Switch
Like a hub, a switch can be used to connect several network devices with one
another in star formation. Switches combine the functions of a hub with those of a
jumper: a switch "learns" the Ethernet address of the network device connected to
a port and only forwards those data packets, which are addressed to this network
device. An exception to this rule are broadcast messages, which are forwarded to
all ports.
System coupler
A system coupler links INTERBUS systems hierarchically with each other. Each
system coupler has a master part and a slave part. The master part opens a new
lower-level INTERBUS system, the slave is a device in the lower-level INTERBUS
system.
TCP (Transmission Control Protocol)
TCP is based on IP and is used to connect devices during data transmission. It
makes sure the data is correct and that data packets are in the right order.
Appendix
335
TCP/IP stack
The TCP/IP stack is a part of the operating system or a driver installed in the
operating system, which provides all the functions and drivers required to support
the IP protocol.
Telnet (Terminal over Network)
Telnet (RFC 854) is used, e.g., for remote access to the network on a UNIX server.
Any computer in the network can gain remote access to another computer (Telnet
server) using a Telnet application (Telnet client). Today, Telnet is also used to
configure network components such as IBS RFC IB-450. Telnet is addressed
under TCP/IP as the port no. 23. Other port numbers can be used for special
applications. Telnet uses TCP/IP as its transmission and data link protocol. In the
Windows environment, the addressing parameters for Telnet connections are
specified in the Connect system menu. In the input window, the IP address of the
Telnet server is entered under Hostname and the desired port no. under
Connection. The predefined Telnet entry is port 23.
Terminal resistor
For 10Base5 or 10Base2 (coaxial cable), each network branch must be terminated
at the start and end by a terminal resistor or terminator. The value of the terminal
resistor must correspond to the cable impedance. For 10Base5 or 10Base2 the
terminal resistor has a value of 50 .
TFTP (Trivial File Transfer Protocol)
In addition to FTP, Trivial File Transfer Protocol (RFC 783) is a protocol used to
transmit entire files. TFTP offers only minimum commands, does not support any
complex security measures, and uses UDP as the transmission protocol. As UDP
is an unprotected protocol, the minimum security measures have been
implemented in TFTP.
Topology
The topology is the way in which a network is structured, e.g., ring, tree or star
topology. The INTERBUS system has a ring topology, i.e., a ring structure, which
also acts as a tree structure, because the forward and return lines are in the same
cable.
TP (Twisted Pair)
TP is a data cable with two cable wires that are twisted together. Twisting individual
double wires in pairs greatly reduces the crosstalk ratio between the double wires
in a cable. A distinction is made between twisted pair cables that are UTP cables
(Unshielded Twisted Pair) and STP cables (Shielded Twisted Pair). TP cables are
mainly used in network technology and are categorized according to their
maximum transmission frequencies.
Transceiver
A transceiver is the combination of a transmitter and receiver and implements the
physical network access of a station to Ethernet, and is integrated in the network
card for 10Base2 and 10Base-T. For 10Base5 (AUI), the transceiver is an external
component directly connected on the network cable.
336
Appendix
Transmit buffer
The transmit buffer is used in INTERBUS PCP communication and is a memory,
which temporarily stores data that is to be transmitted sequentially.
UART
UART is a block for data that is to be transmitted asynchronously. In the transmitter
it converts the signals from parallel to serial and in the receiver it converts the
signals from serial to parallel.
UDP (User Datagram Protocol)
UDP is a protocol, which like TCP is based on IP, however in contrast it is
connectionless and does not use any security measures. The advantage of UDP
compared to TCP is the higher transmission speed.
UTP (Unshielded Twisted Pair)
Unshielded data cable with two cable wires that are twisted together.
Watchdog
The watchdog is a monitoring circuit, which can be implemented once on the
hardware or software side. Once activated, the watchdog must be addressed at
regular intervals, otherwise it generates an error message.
WLAN (Wireless Local Area Network)
Network in a restricted area, which uses a wireless transmission medium.
Appendix
337
A.7 List of Useful Information

A.7.1 Phoenix Contact
Phoenix Contact GmbH & Co.
KG
Flachsmarktstrasse 8 - 28
32825 Blomberg, Germany
Service and Support Center
(INTERBUS Hotline)
Support Center
(INTERBUS Implementations)
Factory Line Support
IBS OPC Server Support
Data sheets for all INTERBUS

components from Phoenix
Contact
Phone +49 - 52 35 - 30 0
Fax
+49 - 52 35 - 34 12 00
E-mail info@phoenixcontact.com
www.phoenixcontact.com
Phone +49 - 52 35 - 34 18 88
Fax
+49 - 52 35 - 34 14 54
E-mail interbusservice@phoenixcontact.com
Phone +49 - 52 35 - 34
Fax
+49 - 52 35 - 34
E-mail info@phoenixcontact.com
Phone +49 - 52 35 - 34 18 88
Fax
+49 - 52 35 - 34 14 54
E-mail automation@phoenixcontact.com
Phone +49 - 52 35 - 34 18 88
Fax
+49 - 52 35 - 34 14 54
E-mail interbussupport@phoenixcontact.com
www.phoenixcontact.com
www.factoryline.de
Data sheets for all Factory Line
components
A list of all the international contact addresses for Phoenix Contact

including direct local contacts is provided on the accompanying CD-ROM.
A.7.2 INTERBUS Club e.V.

(User group for INTERBUS
device manufacturers)
Postfach 402
76 483 Baden-Baden, Germany
Phone: +49 - 72 21 - 55 90 9
Fax:
+49 - 72 21 - 55 69 0
E-mail: info@interbusclub.com
www.interbusclub.com
A.7.3 IDA Group

P.O. Box 1321
32819 Blomberg, Germany
E-mail: info@ida-group.org
www.ida-group.org
338
Appendix
A.7.4 IAONA Europe e.V.

Sandtorstrasse 22
39106 Magdeburg, Germany
Phone: +49 - 39 14 - 09 06 55
Fax:
+49 - 39 14 - 09 06 36
E-mail: info@iaona-eu.com
www.iaona-eu.com
A.7.5 OPC Foundation

16101 N. 82nd Street
Suite 3B
Scottsdale, AZ 85260-1830
USA
Phone :(1) 480 483-6644

Fax:
:(1) 480 483-7202
E-mail:
mj.bryant@mindspring.com
www.opc-foundation.org
A.7.6 Useful OPC Websites

OPC Foundation homepage for European users
www.opceurope.org
Toolkit suppliers used to develop the INTERBUS OPC server and which can be
used to easily develop the OPC client. First OPC toolkit for Linux
www.technosoftware.ch
Free OPC servers and clients, and links to other OPC sites
www.opc.dial.pipex.com/freestuff.html
Wintech toolkit descriptions
http://www.win-tech.com/html/opc.htm
Products and overview
http://www.t-h.de/OPC/OPCCorner-d.htm
Toolkits and server
http://www.softing.de/
How does OPC work?
http://www.controleng.com/archives/1998/ctl0501.98/05g506.htm
Source code kit
http://www.win-tech.com/html/opc.htm
OPC specification
http://lhcb.cern.ch/computing/controls/OPCEvaluation/htmlspef/index.html
Appendix
339
A.7.7 Table of Contents for the Accompanying CD-ROM

PC WORX 2.02
(demo)
CMD 4.50
(demo)
DIAG+
Factory Manager 2.0

(demo)
SNMP/OPC gateway
(demo)
OPC server 2.01
(demo)
OPC clients
Ipswitch What's up Gold

6.0 (demo)
DIAG 40
AUTODIAG 40
IEC 61131-6 programming environment for

INTERBUS controller boards from Phoenix Contact;
for
Windows NT, 2000 16-bit version
Project planning and configuration tool for
INTERBUS controller boards from Phoenix Contact;
for
Windows 95, 98, NT, 2000 16-bit version
User-friendly diagnostic and maintenance software
for INTERBUS controller boards from Phoenix
Contact
Diagnostic and configuration tool for Ethernet
products (Factory Line) from Phoenix Contact; for
Windows NT, 2000, XP
Transmits SNMP information to a visualization via an
OPC connection
OPC server for INTERBUS controller boards from
Phoenix Contact; for Windows NT, 2000, XP
OPC example 1 with INTERBUS OPC server 2.0
OPC example 2 with INTERBUS OPC server 1.0
PowerPoint file for setting the network and DCOM in
a distributed OPC client/server configuration step-bystep
Protocol analysis software for Ethernet protocols
MG Soft MIB browser

(demo)
Comprehensive INTERBUS diagnostic tools under

MS-DOS for INTERBUS controller boards from
Phoenix Contact (located in the Bin directory of IBS
CMD or
PC WORX 2.02)
INTERBUS configuration and startup tool for all
Microsoft operating systems
The MPM descriptor specifies the division of the
mailbox area (MXA) and the software register
IEC 1131-6 examples
High-level language examples
Step5/Step7 examples
SNMP browser for SNMP-compatible Ethernet
components
SNMPView
(freeware)
SNMP browser for SNMP-compatible Ethernet

components
DHCP/BOOTP server
DHCP/BOOTP server for Windows 9x/Me/NT/2000
IB loader
MPM descriptor,
EXE, and source code
INTERBUS program
examples
340
Appendix
1.6.11(shareware)
TFTP 1.0 server
(shareware)
TFTP 1.0 server for Windows 9x/Me/NT/2000
NETIO
Benchmark program for Ethernet connections for

DOS, Windows, Linux, and OS/2
Windows (error) messages as program
(shareware)
MSWINERR
Serial Sniffer 1.10 COM

(demo)
Basics section
V.24 interface monitor

(shareware)
PCP transmission times in Excel
INTERBUS cycle times in Excel
Example equation for the CR check
Answers to questions for the "Basics" section
"Basics" workshop
Configuration section
Assignment of connectors, adapters, and cables
Network types of power supply companies in
Germany
INTERBUS product designations
Fiber optic measured value protocol
INTERBUS acceptance report
Configuration table in Excel
IP code protection table
Fiber optic cable short designations
Fiber optics
Answers to questions for the "Configuration" section
"Configuration" workshop
INTERBUS diagnostics
G4 error list
section
DIAG40 description
Description of the DIAG+ interface as ActiveX
INTERBUS cable test report
Answers to questions for the "Diagnostics" section
INTERBUS
Various example programs for INTERBUS
programming section
programming
ASCII table
Answers to questions for the "Programming" section
"Programming" workshop
Distributed control
PC WORX examples for distributed communication
concept section
Answers to questions for the "Distributed Control
Concept" section
INTERBUS specialist
IB loader: INTERBUS startup and configuration tool
knowledge
for all Microsoft operating systems
Ethernet and INTERBUS Assignment of connectors, adapters, and cables
section
Error codes for Factory Line components
Answers to questions for the "Ethernet" section
OPC and INTERBUS
Description of the DCOM configuration
Appendix
section
341
Answers to questions for the "OPC Communication"
section
A.7.8 Source Material and Bibliography

[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
The Sensor/Actuator Bus, Theory and Practice of INTERBUS, published by

Verlag Moderne Industrie, 1993
OLE for Process Control, Basics, Implementation, and Application, published
by Hthig Verlag, 2000
OPC Specification Version 2.04, OPC Foundation
Ethernet TCP/IP for Industrial Automation, Frank J. Furrer, published by
Hthig-Verlag, 1998
Networker's Guide, Frank R. Walther, published by Markt & Technik Verlag,
2000
Correct Measurement in Measuring and Control Technology and Computer
Technology, Dietmar Benda, published by Franzis Verlag, 1997
EMC of Buildings, Systems, and Devices, published by VDE-Verlag, 1998,
Anto Kohling
Sensor/Actuator Fieldbus Technology Basics, published by Vogel-Verlag,
1997
INTERBUS Basics and Practice, Alfred Baginski, Martin Mller, published by
Hthig, 2nd Edition, 1998
LANline Special Cabling, 1997
Jrgen Plate, Computer Network Basics
IEE45 yr. 2000 No. 12, Jrg F. Wollert "Realtime With Ethernet"
"Peripherals Communication Protocol (PCP)" User Manual,
IBS SYS PCP G4 UM E
"Firmware Services and Error Messages" User Manual,
IBS SYS FW G4 UM E
"INTERBUS Assembly and Installation" User Manual, IBS SYS INST UM E
"Configuring INTERBUS" User Manual, IBS SYS PRO UM E
"User Interface Version 2.x for High-Level Language Programming of the
Generation 4 INTERBUS Standard Controller" User Manual,
IBS PC SC HLI UM E
"Driver Reference Manual for PC Controller Boards", IBS SC SWD UM E
"Microcontroller Protocol IPMS-3" User Manual, IBS IPMS3 UM E
"INTERBUS Slave Implementation Guide" User Manual, IBS Loop UM E
"IBS SUPI 3 INTERBUS Protocol Chip" User Manual, IBS SUPI 3 UM E
N&C PRAXIS 1/99, Ethernet Debugging Workshop, Page 88/89
TCP/IP Ethernet and Web I/O, Wiesemann & Theis, August, 2001,
www.wut.de
"INTERBUS Terms and Definitions" Reference Manual, IBS TERM RG UM E
Diagnostics Quick Start Guide, IBS SYS DIAG DSC UM E
IBS S7 300 DSC-T Quick Start Guide, IBS S7 300 DSC QS UM E
IBS S7 400 DSC/I-T Quick Start Guide, IBS S7 400 DSC QS UM E
"Driver Software for Controller Boards for Siemens SIMATIC S7-300
Controllers" User Manual, IBS S7 300 DSC SWD UM E
"Driver Software for Controller Boards for Siemens SIMATIC S7-400
Controllers" User Manual, IBS S7 400 DSC SWD UM E
342
Appendix
[30] P. Neumann/E. Grtsch/C. Lubkoll/R. Simon: PLC Standard IEC 1131,

published by Oldenbourg-Verlag, Munich, Germany, 1995
[31] S. Horn/M. Becker/T. Wolf: Process Data Channel Operating Modes, Phoenix
Contact, 1997
[32] Swoboda: Codes for Error Correction and Detection, published by Oldenbourg
Verlag, 1973
[33] M. Kster: INTERBUS System Description, Phoenix Contact, 2001
[34] O. Krumrey: IBS MA Firmware V4.4x ProConOS Interface for PDD, Phoenix
Contact, 2000
[35] J. Schmidt: Bus Error Manager (BEM), Phoenix Contact, 1999
[36] W. Pollmann: Specification MPM 4 TN, Phoenix Contact, 1995
[37] IBS PCI DDK UM E User Manual, Phoenix Contact, 2001
[38] Iwanitz, F., Lange, J.: OPC Basics, Implementation, and Application, published
by Hthig, 2nd Edition, 2002
[39] Kriesel, W., Heimbold, T., Telschow, D.: Bus Technologies for Automation,
published by Hthig, 2nd Edition, 2000
[40] Reinert, D., Schfer, M.: Safe Bus Systems for Automation, published by
Hthig, 2001
[41] Aspern, J.: PLC Software Development With IEC 61131, published by Hthig,
2000
[42] Schraft, R., Bender, K., Brandenburg, G. (ed.): PLC/IPC/DRIVES 2001,
published by Hthig, 2002
Appendix
343
A.8 Index
@utomationXplorer 228
A
Acceptance reports 73
Access method 20
Actuators 9
Addressing
Absolute 193
Logical 109
Physical 109
Symbolic 193
Application timeout time 59
ASCII 338
AUTODEBUG 73, 149
AUTODIAG 132, 151
Automation 9
B
Bus error 121
Bus timeout 59
Bus warning time 59
C
CALL 262
Cable
Cross sections 88
Type 88
Checking IN/OUT signals 73
Checklists (troubleshooting) 175
Checksum status telegram 24
Client/server structure 262
COM/DCOM 266
Communication hierarchy model 10
Communication reference 34, 256
Communications power
Compact PCP 35
Complicated error descriptions 155
Configuration
Acceptance 73
Excel spreadsheet 73
Planning 73
Configuration frame 47, 73, 132
Control program 73, 163
Controller error 121
Coprocessor 169
Coupling areas 218
Coupling memory 48
Coupling of contaminated
CR check 24
CR line monitoring 28
CR signal 23
Crossover cable 303
Cycle time 68

Checksum 25
Example equation 25
Efficiency 28
Error 24
Generator 24
Generator polynomial 25
Register 24
D
Data cycle 23
Data integrity 24
Data Interface (DTI) 54, 178
Data transmission error (CRC) 24
DCOM platform 266
DEBUG 73, 149
Default cycle time 59
Default index 239
Determinism 20
Device Driver Development Kit (DDK)
182
Device Driver Interface (DDI) 172
Device error 121
Device error 121
Device number
Logical 109
Physical 109
DIAG40 132, 151
Diagnostic display 115
Diagnostic status register 61, 113
Diagnostic tools 151
Diagnostics and report manager 41
Differential signal 98, 20
Distributed control system 236
DPM 48
DRIVECOM 28, 67
Driver block 215
Driver error codes 311
Driver 167, 171
Dual-Port Memory (DPM) 48, 169
E
EMC measures 91
Emergency stop concept 90
Error codes 311
Error correction 19
Ethernet
Cable 73, 303
Community string 300, 309
Configurations 305
Diagnostics 291
General 283
344
-
Appendix
Installation 286
Problem prevention 303
Redundancy 307
Troubleshooting 308
Ethernet controller board 170

Event error 121
F
Factory Line
General 287
I/O configurator 290
Components 287
SNMP-OPC gateway 290
Factory Manager 289
FC diagnostic status register 118
FC error 121
Fiber optics
Properties 17
Technologies 17, 73
Test report 73
Firmware
Command 28, 47, 110, 132
Differences 47
Error 178
G3/G4 firmware 46
Messages 46
Startup behavior 46
Flowcharts
INTERBUS diagnostics 164
INTERBUS startup 164
PCP structure 164
Troubleshooting 305
Frame Check Sequence (FCS) 22, 24
Full duplex 21
G
G4 error codes 311
Grounding
Star concept 98
H
Hamming distance 12, 28
Handle 178, 248
Higher-level control system 236
High-Level Language Interface (HLI) 172
HLI export filter 182
Hybrid data transmission 33
I
I/O address 73
I/O mode 218
IAONA 337
IB loader 229, 278
IBS CMD G4 151

IBS DIAG+ 154
IBS PC WORX 151, 186
ICMP 292
ID
Register 28
Standard register 28
ID code 28
IDA 336
Identification cycle 23, 28
IEC 61131-3 186

Instantiation 197
Intel 314
INTERBUS
Addressing
Advantages 9
Assembly 73
Cable 73, 160
Club e.V. 336
Combined systems 68, 139
Components 67
Connector pin assignment 73
Controller board167, 170
Cycle 22, 33, 36
Cycle time 68
Data throughput 38
Data transmission 20
Designations 109
Device 12
Diagnostic options 139, 157
Diagnostics 108
Driver 169
Efficiency 28, 38
Error 121
Error types 130
Fiber optics 18
Flowcharts 164
Installation 73
Installation remote bus 16
Local bus15
Local bus diagnostics 132
Loop (installation local bus) 17
Maintenance 73
Parameterization 73
Planning 73
Programming 167, 186, 211
Protocol 38, 21
Remote bus 14
Reset behavior 120
Response time 68
Ring 21
Slaves 39
Standard 28, 9, 101
Startup 73,164
INTERBUS Practical Manual

Status telegram 20
System description 12
System specifications 13
Telegram 20
Test 73
Transmission speed 38
Troubleshooting 121
User data efficiency 38
Warm restart 164
IP addresses 291
IP code protection table 73
ISO/OSI reference model 19
K
Keywords 196
L
LCD 115, 148
LED
BA 144
RC 144
ACTIVE 144
RUN 144
E 144
Length codes 28
Local bus (LB) 15
Local bus error 121
Loop-back word (LBW)
Loop-back word time monitoring 24
M
Mailbox Interface (MXI) 54, 178
Mailbox syntax 247
Management bits 28
Master protocol chip 40
Master/slave access method 20
MAU warning 43
Microprocessor interface 40, 41
Microprocessor watchdog error 41, 136
Motorola 314
MPM
Access 169
Address 56, 112
Communication options 53
Coupling 49
Descriptor 56
Device48
Interfaces 49
Memory management 50
Serial data channel 53
Static RAM 51
Status and control registers 52
Structure 49
Timeout 48
345
N
Network analysis 298
Network class 291
Network error 295
Network types of power supply
companies 96
Node 178
Node handle 178
O
On-chip diagnostics 41
OPC
Access 264
Alternative 278
Architecture 262
Automation interface 274
Client 264, 273
Client/server components 265
Configuration file 269
Configurations 276
Configurator 269
Data consistency 279
Data types 268
Diagnostics 273
Diagnostic client 273
Error codes 312
Error log file 270
Foundation 337
General 262
Performance 279
Project file 272
Read items 260
Server 266, 279
Suppliers 275
Operating modes
Asynchronous 61
Asynchronous with signal protocol
63
Asynchronous with
synchronization pulse 64
Bus-synchronous 65
General 57
Program-synchronous 65
Operating systems 168, 170
Optical path diagnostics 43
Oscilloscope 94, 157, 158
Output driver 158
Overswings 101
P
Parameter
Blocks 33
346
Data 33
Data channel 33
Transmission 33
PC WORX
Array 202
Capacity 207, 208
Constants 208
Data types 202
Hardware model 199
Matrixes 202
ST programming language 206
Structures 202
System tick 200
Task 200
PCP communication 34, 239
PCP cycle time 68
Peripheral fault 121
Peripherals Communication Protocol 33
Phoenix Contact 336
PNM7 255
Potential
Electrical isolation 98
Equipotential bonding 98
POU 191
Power cables 73, 91
Power supplies
Linear regulated 84
Non-regulated 87
Parallel connection
on the secondary side 101
Primary switched 86
Selection 89
Series connection
on the secondary side 101
Selective protection 88
Preprocessing
General 233
Parallel 234
Sequential 234
Process data
Channel 33
Length 34
Monitor 73
Parallel and sequential transmission
60
Preprocessing 233
ProConOS 189
ProConOS variable 252
Product descriptions 73
Programming cable
Programming interfaces 168, 170
Programming languages
C, C++, VB, Delphi 178, 181, 186
IEC 1131 197
Appendix
Examples 181
Protocol
Analyzer 161
Efficiency
Header
IPMS 40
Protocol chip
Comparison of properties 45
IBS LPC 1 45
IBS LPC 2 45
IBS SUPI 2 45
IBS SUPI 3 41
IBS SUPI 3 OPC 43
Read 68
Slave protocol chips 41
-
Q
Quality bit 142
R
RBST 160
RC combination 98
Read/write with name 247
Reconfiguration request 28
Redundancy
Power supplies 101
Register
Addresses 112
Diagnostic parameter register 114
Diagnostic status register 113
Extended diagnostic
parameter register 114
Standard function start register 116
Standard function status register 116
Remote bus (RB) 13
Remote bus check (RC) 121
Remote bus error 121
Remote procedure call (RPC) 172
Reset timeout check 28
RMON 301
S
S7 300 211
S7 400 216
S7 standard blocks 223
Safety measures
ESD 96
Lightning 96
Network disturbances 94
Surge voltage 94
Transients 98
Safety regulations 73
Select Line (SL)
Monitoring 28
INTERBUS Practical Manual

Signal 23
Sensors 9, 67
Serial register expansion (SRE) 46
Shielding 98
Shift register 21
Signal interface 54
Slave diagnostic status register 118
SNMP 290, 300
Standard control register 32
Standard functions
Register 110, 117
Start register 61
Status register 61
Standard identification register 28
Strain relief 73
Subnet masks 291
Summation frame protocol 22, 33
Surge voltage 104
Surge voltage protection concepts 73
SVC file 229
Synchronization request
Synchronous data scanning 20
SysFail request 54
System coupler 237
System description 12
T
TCP/IP 284
Test reports 160
Time equidistance
Deterministic 21
Hybrid 21
Timeout error 121
Tools for INTERBUS
diagnostics 144, 148, 151, 155, 157
Topology 12
Transients 98
Transmission
Parallel 60
Sequential 60
Transmission protocol 12, 20
Transmission quality 142
Transmission standard 20
Trap receiver 291
Troubleshooting 155, 295
TT, TN-C, TN-S, TN-C-S networks 96
V
Variables 194
VDE 101
Visualization
Voltage
Dips 94
Drop 94
347
Peaks 94
Ripple 94
Triggering 94
Voltages 94
W
Watchdog 178
Web-based management 290
X
XDTA
Access 68, 182
Basic specifications 54
Programming 68, 182
348
Appendix

Interbus Practical Guide PDF

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Interbus Practical Guide PDF

Încărcat de

Drepturi de autor:

Formate disponibile

2

Alexander Bsing Holger Meyer

Interbus Practical Guide

Interbus Practical Guide

INTERBUS Basics ....................................................................... 9

Interbus Practical Guide

1.7.9 SysFail Request............................................................. 54

Interbus Practical Guide

Interbus Practical Guide

Interbus Practical Guide

Distributed Control Concept..................................................... 236

Interbus Practical Guide

Installing Ethernet in an Industrial Environment............... 286

Ethernet Components From Phoenix Contact ................. 287

8.4.1 Factory Line and INTERBUS Ethernet Controller ........ 287

Diagnostics in the Ethernet Network................................ 291

8.5.1 TCP/IP on a Windows Operating System.................. 291

Prevention of Ethernet Problems..................................... 303

Ethernet Cable Types...................................................... 303

Ethernet Configuration Using INTERBUS ....................... 305

Redundant Ethernet With FL Switch................................ 307

"Ethernet and INTERBUS" Workshop ............................. 308

Practical Tips ................................................................... 309

Questions for the "Ethernet" Section ............................... 310

General system description of the INTERBUS system

Important cross references:

Dieses Dokument gehrt

What are the basic specifications for the INTERBUS system?

1.1 Areas of Application of the INTERBUS System

Data input and

Figure 1.1: INTERBUS in the communication hierarchy

As one of the leading fieldbuses in (factory) automation, the INTERBUS fieldbus

Low installation costs

Reduced planning costs

Flexible bus topology

Very fast and effective data transmission

Manufacturer-independent hardware and software

Open communication protocol

Simple, easy to understand error diagnostics

Very large number of device manufacturers

Very reliable data transmission

Option of creating a redundant version

A detailed description of popular sensor and actuator fieldbus

In addition to INTERBUS, there are other fieldbuses, such as PROFIBUS, Bitbus,

1.2 INTERBUS System Specifications

LOOP local bus, 200 m (656.17 ft.)

Remote bus at level 0

Interface converter to fiber optics

Remote bus at level 1

Remote bus, 12.8 km (7.95 mi.) maximum

Figure 1.2: INTERBUS topology with system specifications

Table 1.1: Basic INTERBUS system specifications

1.2.2 INTERBUS Remote Bus

Table 1.2: Basic INTERBUS remote bus specifications

2-wire, often implemented using a 9-pos. D-SUB

400 m (1312.34 ft.)

between two bus terminal

The remote bus can be electrically segmented at any time.

Remote bus branch

The remote bus branch offers the option of branching the

1.2.3 INTERBUS Local Bus

INTERBUS controller board