Knowledgebase

applicomIO®
Knowledge Base
a product of Woodhead Software & Electronics

Copyright © Woodhead Software & Electronics
Table of Contents
1. Installation and Cabling ............................................................................ 1
Coexistence of applicom® / applicomIO® Products .................................... 1
PC104-CANIO Board .................................................................................. 2
PC104-DPIO Board ..................................................................................... 3
PC104-DPIO Board ver B ........................................................................... 4
PC104-DVNIO Board .................................................................................. 5
PCI-CANIO Board....................................................................................... 6
PCU-CANIO Board ver E ........................................................................... 7
PCIE-CANIO Board (EETH068) ................................................................ 8
PCI-DPIO Board ver A ................................................................................ 9
PCI-DPIO Board ver B .............................................................................. 10
PCU-DPIO Board ver E ............................................................................. 11
PCIE-DPIO Board (EETH068).................................................................. 12
CPCI-DPIO Board ..................................................................................... 13
PCI-DVNIO Board .................................................................................... 14
PCU-DVNIO Board ver E ......................................................................... 15
PCIE-DVNIO Board (EETH068) .............................................................. 16
PCI/PCU-ETHIO Board ............................................................................ 17
PCIE-ETHIO Board (EETH068) ............................................................... 18
Discrete Input/Output................................................................................. 20
For PCI Boards ........................................................................................ 20
For PC/104 Boards ................................................................................. 20
Use of Discrete I/O .................................................................................. 21
Installing the Ferrite ................................................................................ 21
CANopen Channel on PC104-CANIO ...................................................... 22
Profibus Channel on PC104-DPIO ............................................................ 24
DeviceNet channel on PC104-DVNIO ...................................................... 26
CANopen Channel on PCI-CANIO ........................................................... 29
Profibus Channel on PCI-DPIO and CPCI-DPIO ..................................... 31
DeviceNet channel on PCI-DVNIO/PCU-DVNIO ................................... 33
Configuration by RS232 Serial Link for PC/104 Boards .......................... 35
Configuration by RS232 Serial Link for PCI Boards ................................ 37
Configuration by Ethernet Link for PCU Boards ...................................... 37
Configuration by RS232 Serial Link for CompactPCI Boards .................. 38
In Case of Conflict ..................................................................................... 39
Mixing PCI and PC/104-type Boards ........................................................ 40
Environment and Operating Conditions .................................................... 41
Operating conditions: Limits ..................................................................... 41
Certificate of Compliance.......................................................................... 42
2. Implementation ........................................................................................ 43
Error Messages during Initialization.......................................................... 43
Start-up Synchronization for an Application using applicomIO® ............. 45
Simulation mode ........................................................................................ 46
applicomIO® Knowledge base Implementation <Table of Contents  i

Configuration .......................................................................................... 46
Initialization ............................................................................................ 50
Use of the Simulation Software ................................................................. 51
Testing Tools .......................................................................................... 52
Remote use via a TCP/IP connection......................................................... 54
Remote Use via a Serial link ...................................................................... 55
Configuration .......................................................................................... 55
Initialization ............................................................................................ 59
Use ........................................................................................................ 59
Communication Problems ......................................................................... 60
Remote Use via an Ethernet link ............................................................... 61
« Woodhead Remote Ethernet » protocol installation ................................... 61
Configuration .......................................................................................... 64
Existing configuration to Remote Ethernet configuration. .............................. 69
Initialization ............................................................................................ 70
Use ........................................................................................................ 70
Saving and Replaying an Initialization Sequence ...................................... 71
Concept ................................................................................................. 71
Saving an Initialization Sequence or a Flash Memory Download Sequence ...... 72
Generation of an Initialization File or a Flash Memory Download File ............. 73
Replaying the Initialization File or the Flash Memory Download File................ 74
3. CANopen ................................................................................................... 75
Description of a CANopen EDS file .......................................................... 75
ApplicomIO generic CANopen EDS file .................................................. 80
CANopen equipment detection method ..................................................... 81
Solving CANopen network problems ........................................................ 82
CANopen on line action............................................................................. 84
Description of a PDO ................................................................................. 88
Initialization principle of the applicomIO® CANopen master and the
network ...................................................................................................... 89
Analysis and use of the 'SDO abort codes' messages ................................ 90
Automatic generation of an EDS file ......................................................... 92
Functionalities accessible by AuWriteReadMsg_io. ................................. 94
Reading an SDO object with the function AuWriteReadMsg_io. ...................... 95
Writing an SDO object with the function AuWriteReadMsg_io. ....................... 96
Sending an NMT command with the function AuWriteReadMsg_io. ................. 97
Transmission/Reception of a CAN frame with the function AuWriteReadMsg_io.98
Management of "Emergency" (EMCY) events with the function
AuWriteReadMsg_io. ................................................................................ 99
Reading the PDO FIFO with the function AuWriteReadMsg_io. ..................... 101
Writing SDO object which size is greater than 255 bytes with the function
AuWriteReadMsg_io. .............................................................................. 104
Reading current state of a CANopen equipment bytes with the
AuWriteReadMsg_io function. .................................................................. 107
Example of using the function AuWriteReadMsg_io. ................................... 108
Management of IO commands ................................................................. 110
Description of the Master command and master status byte........................ 111
Description of the RTR TPDO command area ............................................. 112
Example of using IO commands in language C .......................................... 113
Setting up a discussion between two devices in the network without the
intervention of the CANopen master ....................................................... 115
Emergency messages: EMCY.................................................................. 116
Description of expert mode in the configurator ....................................... 117
Expert mode for general configuration of the CANopen master. ................... 117
Expert mode for device configuration. ...................................................... 118
Expert mode for configuration of PDOs. .................................................... 119
4. DeviceNet ................................................................................................ 121

Description of a DeviceNet EDS File ..................................................... 121
ii  <Table of Contents applicomIO® Knowledge base Implementation

Using the EDS File ................................................................................. 121
Error Messages during EDS File Analysis .................................................. 122
Generating a DeviceNet EDS File ........................................................... 123
Equipment Detection Method .................................................................. 124
Solving DeviceNet Network Problems .................................................... 126
Checking your Hardware Installation........................................................ 126
Troubleshooting .................................................................................... 128
On-line Actions for the DeviceNet Network ........................................... 129
"Network" Tab ...................................................................................... 129
"Explicit Message" Tab ........................................................................... 131
'Node Commissioning' Tab ...................................................................... 133
DeviceNet Connection Types .................................................................. 135
'Strobe'-type Connection ........................................................................ 135
'Polling'-type Connection ........................................................................ 136
'Cyclic'-type Connection ......................................................................... 137
'Change Of State'-type Connection .......................................................... 138
DeviceNet Master Cycle .......................................................................... 139
Input/Output Organization of DeviceNet Equipment .............................. 140
Checking the Identity of a DeviceNet Device ......................................... 142
DeviceNet Objects ................................................................................... 143
'Flex I/O' Configuration for the DeviceNet Network............................... 147
Flex I/O Device ..................................................................................... 147
Configuration of the Flex I/O Device ........................................................ 149
Input Sharing Functionality with Another DeviceNet Master ................. 152
Characteristics of a Device Sharing its Input with Several DeviceNet Masters 152
Use of Explicit Messaging ....................................................................... 153
5. EtherNet/IP ............................................................................................. 156

EtherNet/IP Compliance .......................................................................... 156
Identity Object, Class 0x01 .................................................................... 156
Message Router Object, Class 0x02 ......................................................... 157
Assembly Object, Class 0x04 .................................................................. 158
Connection Manager Object, Class 0x06 ................................................... 159
TCP/IP Interface Object, Class 0xF5 ........................................................ 160
EtherNet Link Object, Class 0xF6............................................................. 161
On-line actions on the EtherNet/IP network ............................................ 162
'Explicit Message' Tab ............................................................................ 162
„Port configuration‟ tab ........................................................................... 164
Organization of inputs/outputs to EtherNet/IP devices ........................... 165
EtherNet/IP Device ................................................................................ 165
Connections: “Rack Optimization” ........................................................... 166
Local slave ........................................................................................... 167
CIP objects ............................................................................................... 168
Using explicit messaging in EtherNet/IP ................................................. 172
DHCP, BOOTP, DNS .............................................................................. 174
Introduction to DHCP and BOOTP Client service on an applicomIO® solution 174
Introduction to the DNS Client service on an ApplicomIO® solution ............. 179
6. Modbus on Ethernet .............................................................................. 182

TCP/IP appendix ...................................................................................... 182
IP address ............................................................................................ 182
Subnetwork mask ................................................................................. 183
Gateway .............................................................................................. 184
TCP Time-out........................................................................................ 185
Connection maintenance ........................................................................ 185
Extended statuses (TCP/IP) .................................................................... 186
Configuring the master ............................................................................ 187
Maximum number of requests in progress ................................................ 187
Exchange block ........................................................................................ 188
Purpose of an Exchange block ................................................................. 188
applicomIO® Knowledge base Implementation <Table of Contents  iii

Configuring the period of an Exchange block ............................................. 188
Modbus on Ethernet device inputs / outputs ............................................ 190
Organization of Modbus on Ethernet device inputs / outputs ....................... 190
Online action on the Modbus on Ethernet network ................................. 191
Description ........................................................................................... 191
Use ...................................................................................................... 193
Transmission / reception of a Modbus frame .......................................... 194
Description ........................................................................................... 194
Use with the function AuWriteReadMsg_io of the DLL applicomio.dll ............. 194
7. Profibus DP............................................................................................. 197

General points .......................................................................................... 197
Profibus DP step by step .......................................................................... 198
Solving Profibus DP network problems ..................................................... 198
Checking the stations on the Profibus network .......................................... 198
Checking the Profibus cabling.................................................................. 199
Connection of equipment detected with its GSD file ................................... 201
Connection of equipment detected with a number of GSD files .................... 203
Connection of equipment detected without a GSD file ................................ 204
Profibus DP services ................................................................................ 205
Description ........................................................................................... 205
Use of the AuWriteReadMsg_io Function ................................................... 205
Diagnos................................................................................................ 207
Read IO configuration ............................................................................ 209
Read input data..................................................................................... 211
Read output data................................................................................... 213
Send configuratio data ........................................................................... 215
Send Global Control ............................................................................... 217
Send Global Group Control ..................................................................... 219
Read data blocks Classe1 DPV1 ............................................................... 221
Write data blocks Classe1 DPV1 .............................................................. 223
Read data block Classe2 DPV1 ................................................................ 225
Write data block Classe2 DPV1 ................................................................ 227
Abort communication Classe2 DPV1 ......................................................... 229
Set slave address .................................................................................. 231
Sample ................................................................................................ 233
8. PROFINET ............................................................................................. 234

PROFINET Service ................................................................................. 234
Description ........................................................................................... 234
Use of the AuWriteReadMsg_io Function ................................................... 234
Managment (dwMsgParam = 10) ............................................................ 236
Management – IO-Device management .................................................... 236
9. OPC Server ............................................................................................. 237

General introduction to OPC ................................................................... 237
The OPC concept ................................................................................... 237
What is OPC? ........................................................................................ 237
Characteristics of the applicomIO® OPC server ......................................... 237
Data type returned by the OPCIO server ................................................. 238
Enabling and disabling the Diagnostic mode........................................... 240
Using generic syntaxes for accessing input/output data .......................... 241
Display format modification suffixes ...................................................... 242
Use of "Emergency messages" in CANIO ............................................... 243
Introduction to DCOM with an OPC Server............................................ 244
Introduction to DCOM ............................................................................ 244
Installation ........................................................................................... 244
Windows Firewall ................................................................................... 245
Configuring the firewall .......................................................................... 246
DCOM Enhancements ............................................................................. 250
Configuring DCOM ................................................................................. 251
Configuring the general DCOM properties on the server and client machines . 252
iv  <Table of Contents applicomIO® Knowledge base Implementation

OPC Client in the Form of a Service ......................................................... 270
applicomIO® Knowledge base Implementation <Table of Contents  v

1. Installation and Cabling
Coexistence of applicom® / applicomIO® Products

® ®
Products of the applicom family for industrial networks and the applicomIO family for fieldbuses
can co-exist on the same machine.
However, care should be taken to ensure compatibility of the following software versions:
applicomIO® 1.1 applicomIO® 1.2

or lower or higher
applicom® 3.2 or
no no
lower
applicom® 3.3 or
no yes
higher
®
If applicom /applicomIO® products are installed on the same machine, the number attributed
to the boards is independent for each family. This means that there will be 2 boards
configured with number 1.
applicomIO® Knowledge base Implementation Installation and Cabling  1

PC104-CANIO Board
1 : Male 10-pin HE13 connector for connection to the CANOPEN network

2 : CANopen channel transmission indicator lamps
®
3 : Connector providing access to a discrete input and output through the applicomIO functions
IO_SetWatchDog and IO_GetDigitalInput
4 : Male 10-point HE13-type connector (pins) for configuration by RS232 serial link.
5 : Micro-switches to select interruption, base memory address and the applicom/applicomIO®
board number.
Characteristics:
Size of the PC104-CANIO board: 95 x 90
Power consumption: 5.5 W (5V)
Operating temperatures: 0 to +65 °C
(for extended temperatures, consult us)
Storage temperatures: -40 to +85 °C
Dielectric strength (galvanic insulation) : 500 Volts
MTBF: 100,000 hours
2  <Table of Contents applicomIO® Knowledge base Implementation

PC104-DPIO Board
1 : Male 10-pin HE13 connector for connection to the Profibus network

Maximum current on the 5V: 150mA
2 : Profibus channel transmission indicator lights
®
3 : Connector providing access to discrete input and output through the applicomIO functions
IO_SetWatchDog and IO_GetDigitalInput.
4 : Male 10-point low-profile HE13-type connector (pins) for an additional module enabling
configuration by RS232 serial link.
board number.
Characteristics:
Size of the PC104-DPIO board: 95 x 90
Power consumption: 4W (5V)
Dielectric strength (Profibus channel galvanic insulation) 500 Volts
MTBF: 100,000 hours

PC104-DPIO Board ver B
1 : HE13 male 10-pin straight connector for connection to the Profibus network
Maximum current on the 5V : 150mA
2 : Profibus channel transmission indicator lamps
®
4 : Male 10-pin HE13 type connector for configuration by RS232 serial link
5 : Microswitches used to select the interrupt, the base memory address and the applicomIO®
board number
Miscellaneous characteristics:
Size of the PC104-DPIO board ver B: 95 x 90
Consumption: 5 W (5 V)
Storage temperature: -40 to +85 °C
Dielectric strength (galvanic isolation Profibus channel): 500 Volts
MTBF: 100 000 hours

PC104-DVNIO Board
1 : Male 10-pin HE13 connector for connection to the DeviceNet network

2 : DeviceNet channel transmission indicator lights
®
IO_SetWatchDog and IO_GetDigitalInput
4 : Male 10-point HE13-type connector (pins) for configuration by RS232 serial link.
board number.
Characteristics:
Size of the PC104-DVNIO board: 95 x 90
Power consumption: 5.5 W (5V)
MTBF: 100,000 hours

PCI-CANIO Board
1 : Male 9-pin subD connector for connection to the CANopen network

2 : CANopen transmission indicator lights
3 : Male 9-point subD connector for configuration by RS232 serial link.
®
5 : Board number configuration jumpers (1 to 8).
Default configuration: board 1.
6 : PCI bus configuration PROM.
7 : PCI configuration jumper (reserved for applicom international use).
Default setting for applicomIO boards:
Characteristics:
Size of the PCI-CANIO board: 174 x 106 (not including connectors and rear)
MTBF: 100,000 hours

PCU-CANIO Board ver E
1 : RJ45 connector for connection to the Ethernet network (support for Ethernet Remote
configuration).
2 : Ethernet transmission indicator lamps
3 : Female Dsub 9-pin connector for CANopen network.
4 : DeviceNet transmission indicator lamps
®
Default position for the applicomIO boards:
8 : socket for required MCAN056 module for CANopen network.
Size of the PCU-CANIO ver E board: 167 x 106 (excluding connectors and rear panel)
Consumption: 5.5 W (5 V)
Operating temperature: 0 to +65 °C
Dielectric strength (galvanic isolation): 500 Volts
MTBF: 100 000 hours

PCIE-CANIO Board (EETH068)
configuration).
®
7 : PCI configuration jumper (reserved for applicomIO® use).
8 : socket for required MCAN056 module for CANopen network.
Size of the PCIE-CANIO (EETH068) board: 167 x 106 (excluding connectors and rear panel)
MTBF: 100 000 hours

PCI-DPIO Board ver A
1 : Female Sub D 9-pin connector for connection to the Profibus network.

Maximum current on the 5V: 150mA
2 : Profibus channel transmission indicator lights
®
Characteristics:
Size of the PCI-DPIO board ver A: 174 x 106 (not including connectors and rear)
MTBF: 100,000 hours

PCI-DPIO Board ver B
1: Female Sub D 9-pin connector for connection to the Profibus network.

®
4 : Male subD 9-pin connector for configuration by RS232 serial link.
5 : Configuration RS232 port transmission indicator lamps
8 : 5RS232 module support required if the configuration port is used
Size of the PCI-DPIO board ver B: 174 x 106 (excluding connectors and rear panel)
MTBF: 100 000 hours

PCU-DPIO Board ver E
configuration).
3 : Female Dsub 9-pin connector for Profibus network.
4 : Profibus transmission indicator lamps
®
8 : socket for required MPFB053 module for Profibus network.
Size of the PCU-DPIO ver E board: 167 x 106 (excluding connectors and rear panel)
MTBF: 100 000 hours

PCIE-DPIO Board (EETH068)
configuration).
®
8 : socket for required MPFB053 module for Profibus network.
Size of the PCIE-DPIO (EETH068) board: 167 x 106 (excluding connectors and rear panel)
MTBF: 100 000 hours

CPCI-DPIO Board
1: Female Sub D 9-pin connector for connection to the Profibus network.

®
5 : CompactPCI connector
7 : Male subD 9-pin connector for configuration by RS232 serial link.
Size of the PCI-DPIO board ver B: 174 x 100 (excluding connectors and rear panel)
MTBF: 100 000 hours

PCI-DVNIO Board
1 : 5-point connector for connection to the DeviceNet network

2 : DeviceNet transmission indicator lights
3 : Male 9-point subD connector for configuration by RS232 serial link.
®
Characteristics:
Size of the PCI-DVNIO board: 174 x 106 (not including connectors and rear)
Storage temperatures : -40 to +85 °C
MTBF: 100,000 hours

PCU-DVNIO Board ver E
configuration).
3 : 5-point connector for connection to the DeviceNet network.
®
8 : socket for required MCAN056 module for DeviceNet network.
Size of the PCU-DVNIO ver E board: 167 x 106 (excluding connectors and rear panel)
MTBF: 100 000 hours

PCIE-DVNIO Board (EETH068)
configuration).
3 : 5-point connector for connection to the DeviceNet network.
®
8 : socket for required MCAN056 module for DeviceNet network.
MTBF: 100 000 hours

PCI/PCU-ETHIO Board
1 : RJ45 connector for connection to the Ethernet network.

3 : Male (PCI-ETHIO ver C or ver D) or Female (PCI-ETHIO ver E) Dsub 9-pin connector for
configuration by RS232 serial link.
®
8 : socket for required 5RS232 module if the configuration port is used
Size of the PCI-ETHIO ver C and D board: 174 x 106 (excluding connectors and rear panel)
Size of the PCU-ETHIO ver E board: 167 x 106 (excluding connectors and rear panel)
MTBF: 100 000 hours

PCIE-ETHIO Board (EETH068)
configuration).
3 : Female Dsub 9-pin connector for configuration by RS232 serial link
®
8 : socket for required 5RS232 module if the configuration port is used.
MTBF: 100 000 hours

Discrete Input/Output
For PCI Boards
Rear of the board
For PC/104 Boards

Use of Discrete I/O
Terminals 1 and 2:
“ Watchdog ” contact output, potential free contact (24V DC, 0.25 A), which can be controlled by the
®
applicomIO IO_SetWatchDog function
Terminals 3 and 4:
Opto-coupled discrete input. Power supply voltage:
 Direct 10 to 30V.
 Alternating 24V 10 (50 to 60 Hz).
This input can be managed by the applicomIO® function IO_GetDigitalInput.
Installing the Ferrite

For PCI-type interfaces, a ferrite must be installed on the discrete I/O cable.
The ferrite must be fitted on the discrete input/output cable making a loop with it. It must be fitted as
close as possible to the board.
For PC/104-type interfaces, it may also be necessary to place a ferrite on the discrete I/O cable in
order to comply with the standard.
This ferrite is available upon request.

CANopen Channel on PC104-CANIO
Description of the CANopen interface of the PC104-CANIO board (the numbering below
corresponds to connectors of the male 10-pin HE13 type).
The pinout of the board's male HE13 connector is as follows:
Note that 24V and 0V signals are optional. Similarly, the 24V signal is an input and it is not supplied
by the board.
This line interface is galvanically insulated (insulation voltage: 500V).
You can easily connect a CANOpen standard 9-point subD to this connector by means of a 9-wire
ribbon cable. With the ribbon cable, connect pin no. 1 of a female HE13 connector to pin no. 1 of a
male subD. Pin no. 10 of the HE13 connector remains unconnected.
The wiring must be made according to the following diagram :

The cable must have a characteristic impedance of approximately 120 ohms and terminal resistors
a value of 121 ohms.
Cable length and transmission rate:
Transmission Rate Maximum Length of the Bus

1 Mbit/s 25 m
800 kbit/s 50 m
500 kbit/s 100 m
250 kbit/s 250 m
125 kbit/s 500 m
100 kbit/s 620 m
50 kbit/s 1 km
20 kbit/s 2.5 km
10 kbit/s 5 km

Profibus Channel on PC104-DPIO
Description of the Profibus interface of the PC104-DPIO board (the numbering below corresponds
to connectors of the male HE13 type).

You can easily connect a Profibus standard 9-point subD to this connector by means of a 9-wire
ribbon cable. With the ribbon cable, connect pin no. 1 of a female HE13 connector to pin no. 1 of a
male subD . Pin no. 10 of the HE13 connector remains unconnected.
The PC104-DPIO interface is connected on the Profibus network via a compulsory bus connector in
order to comply with the standard (EN50170).

This connector includes the necessary line adaptation if the board is installed at the end of the line:
The adaptation is supplied in Profibus standard connectors.
Remark:
To go up to maximum cable lengths, a twisted pair screened cable is required, with the following
characteristics :
- Characteristic Impedance : app. 135-160  (f = 3-20 MHz)
- Loop resistance :  115 /km
- Service capacity : 30 nf/km
- Attenuation : 0.9 dB/100m ( f = 200 kHz)
- Admissible section of conductors : 0.3 mm2 to 1.5mm2
- Admissible diameter of cable : 4 mm to 9 mm
Cable references :
BELDEN® Ref.: 3079A
Siemens Ref.: 6XV1 830-0AH10
Baud Rate in kbits/s Distance in m

9,6 - 19,2 - 93,75 1200
187,5 1000
500 400
1500 200
3000 to 12000 100
Note:
- Creating several Profibus buses with a multicore cable is only possible if the conductors are
screened in pairs.
- A Profibus bus cable must not run alongside telephone cables.

DeviceNet channel on PC104-DVNIO
Description of the DeviceNet interface of the PC104-DVNIO board (the numbering below
corresponds to connectors of the male HE13 type).
Note that the 24V signal is an input and that it serves to detect the presence of a 24V power supply
for the network.
A DeviceNet standard male connector (e.g. Phoenix Contact DFK-MSTB 2,5/5-G-5,08 or DFK-
MSTB 2,5/5-GF-5,08) can be connected to this board. The pinout of this connector is shown below:
1 : 0V (electrical ground - black)

2 : Can_L (low CAN signal – blue)
3 : Shielding
4 : Can_H (high CAN signal – white)
5 : 24V (24V detection - red)

Note that the cable must have a characteristic impedance of approximately 120 ohms and the
terminal resistors a value of 121 ohms.
Drop lines of 6 m maximum are allowed.

The maximum distance of the network depends on Baud Rate and cable type:
 Thick cable: Cable consisted of two twisted and shielded pairs with a wire at the center,
covered by a shielding braid. It is normally used for the main trunk. Supports up to 8A.
Ref.: BELDEN® 3082A (PVC) – 3083A (CPE)
 Thin cable: Thinner and more flexible than the thick cable. It is normally used for the drop
lines. Supports up to 3A.
Baud Rate Total Length of Total Length (Main Trunk and Drop lines)
Drop lines
100 % thick cable 100 % thin cable
125 kbit/s 156 m LThick + 5 x LThin = 500 500 m 100 m
250 kbit/s 78 m LThick +2.5 x LThin = 250 250 m 100 m
500 kbit/s 39 m LThick + LThin = 100 100 m 100 m
Where:
LThick: Length of thick cable
LThin:
Length of thin cable
The twisted supply pair must be connected to an outside power source at +24V.

CANopen Channel on PCI-CANIO
Description of the CANopen interface of the PCI-CANIO board.
Note that 24V and 0V signals are optional. Similarly, the 24V signal is an input and it is not supplied
by the board.

Transmission Rate Maximum Length of the Bus

1 Mbit/s 25 m
800 kbit/s 50 m
500 kbit/s 100 m
250 kbit/s 250 m
125 kbit/s 500 m
100 kbit/s 620 m
50 kbit/s 1 km
20 kbit/s 2.5 km
10 kbit/s 5 km
If the transmission rate is too high with respect to the topology, frame collisions can result, leading
to"Bus Off" status for all devices.

Profibus Channel on PCI-DPIO and CPCI-DPIO
Description of the Profibus interface of the PCI-DPIO and the CPCI-DPIO boards (the numbering
below corresponds to connectors of the female 9-pin subD type).
The PCI-DPIO interfaces are connected on the Profibus network via a compulsory bus connector in
order to comply with the standard (EN50170).
This connector includes the necessary line adaptation if the board is installed at the end of the line:
The adaptation is supplied in Profibus standard connectors.

Remark:
To go up to maximum cable lengths, a twisted pair screened cable is required, with the following
characteristics :
- Characteristic Impedance : app. 135-160  (f = 3-20 MHz)
- Loop resistance :  115 /km
- Service capacity : 30 nf/km
- Attenuation : 0.9 dB/100m ( f = 200 kHz)
- Admissible section of conductors : 0.3 mm2 to 1.5mm2
- Admissible diameter of cable : 4 mm to 9 mm
Cable references :
BELDEN® Ref.: 3079A
Siemens Ref.: 6XV1 830-0AH10
Baud Rate in kbits/s Distance in m

9,6 - 19,2 - 93,75 1200
187,5 1000
500 400
1500 200
3000 to 12000 100
Note:
- Creating several Profibus buses with a multicore cable is only possible if the conductors are
screened in pairs.
- A Profibus bus cable must not run alongside telephone cables.

DeviceNet channel on PCI-DVNIO/PCU-DVNIO
Description of the DeviceNet interface of the PCI-DVNIO board:
Note that the 24V signal is an input and that it serves to detect the presence of a 24V power supply
for the network.


 Thick cable: Cable consisted of two twisted and shielded pairs with a wire at the center,
covered by a shielding braid. It is normally used for the main trunk. Supports up to 8A.
 Thin cable: Thinner and more flexible than the thick cable. It is normally used for the drop
lines. Supports up to 3A.
Baud Rate Total Length of Total Length (Main Trunk and Drop lines)
Drop lines
125 kbit/s 156 m LThick + 5 x LThin = 500 500 m 100m
Where:
LThick: Length of thick cable
LThin: Length of thin cable
The twisted supply pair must be connected to an outside power source at +24V.

Configuration by RS232 Serial Link for PC/104 Boards
®
All applicomIO boards in PC/104 format have a RS232 connector for configuration by serial link,
except PC104-DPIO.
However, this board may be equipped with a module, optionally installed, in order to have access to
this functionality.
The RS232 serial link is accessible with a male HE13 connector (pins) with a pinout as shown
below:
With a 9-wire ribbon cable, this HE13 connector can be connected to an RS232 standard 9-pin
SubD connector. A cable with a 10-pin female HE13 connector and a 9-pin male SubD connector
must be used:

This cable is used to connect the RS232 standard for PCs to a 9-pin male SubD:
This serial link complies with the RS232C standard and enables baud rates of up to 115 kbps.

Configuration by RS232 Serial Link for PCI Boards
®
The applicomIO PCI-CANIO, PCI-DVNIO, PCI-DPIO ver B and PCI-ETHIO boards are fitted with
an RS232 connector so that they can be configured by serial link.
The PCI-DPIO ver B and PCI-ETHIO boards must be equipped in this case with a 5RS232 module
(fitted in the factory).
This connector is a male 9 pins Dsub following the PC RS232 PC or a female 9 pins Dsub (PCI-
ETHIO ver E) on which a gender changer allows to follow this standard.
Configuration by Ethernet Link for PCU Boards

®
The applicomIO PCU-CANIO, PCU-DVNIO, PCU-DPIO ver E and PCU-ETHIO boards are fitted
with an RJ45 connector so that they can be configured by Ethernet link. To be able to use this
feature, the bios version of them must be 4.6 or upper.

Configuration by RS232 Serial Link for CompactPCI Boards
®
The applicomIO CPCI-DPIO boards are fitted with an RS232 connector so that they can be
configured by serial link.

In Case of Conflict
 For the PC/104 boards, a conflict is only possible if the memory range and/or the interrupt
configured are not available. Check your configuration, especially the following points :
 reservation of these resources in the machine SETUP
 setting the various configuration jumpers
 similarity of resource choices with the software configuration (applicomIO console)
 non-use of these resources by other system components
 For the PCI boards, the memory range and the interrupt are allocated automatically by the
BIOS. No hardware conflict is theoretically possible. However, since the interrupt can be
shared with other PCI boards, it is essential that the corresponding drivers can share the
®
interrupt. The applicomIO driver authorizes this sharing. If a problem of sharing with
another driver occurs, you must allocate different interrupts to the PCI slots supporting the
boards in conflict, in the machine setup.
Notes :
 If you install an Plug&Play Microsoft Operating system whereas applicom® PCI interfaces
are physically present in the machine, Windows will not require the access path to the inf
file and will classify the interfaces applicom® in the heading Other peripherals. In this
case, install the applicom® software , remove these peripherals through the system icon of
the control panel (Device Manager) and reboot the machine.
 Under Plug&Play Microsoft Operating system, if you wish to remove an applicom® PCI
board from your machine, you must remove it through the system icon of the control panel
(Device Manager) before to stop your PC.

Mixing PCI and PC/104-type Boards
Mixing of PCI and PC/104 boards is possible for up to 8 boards. The numbers allocated to each
board with the board number selection jumpers must be successive, regardless of the board mix
used.
Example:
Use of two PC/104 boards and two PCI boards.
®
This example includes four applicomIO boards: the first is a PC/104-type board, the second PCI,
the third PC/104 and the fourth PCI.
In this case, for the PC/104 boards, choose the base address (e.g. D4000) and the IRQ (e.g. 5) in
the applicomIO® console.
Configure the micro-switches for the PC/104 boards, as indicated under the heading "Configuration
of PC/104 Boards", such that both are set to IRQ 5. Configure the micro-switches, in compliance
with the table under this same heading, in order to select the numbers for each board. In our
example: board 1 for one and board 3 for the other one.
For the PCI boards, configure their board numbers, as indicated under the heading "Configuration
of PCI Boards", i.e. board 2 and board 4.
The addresses and interrupts of the PCI boards are automatically configured by the PC.
Thus, to mix PCI- and PC/104-type applicomIO® boards, you just have to configure successive
board numbers, without needing to take into account the bus type of each board.

Environment and Operating Conditions
Operating conditions: Limits
About the standard:
®
applicomIO Boards
PCI-DPIO, PCU-DPIO, PCI-DVNIO,PCU-DVNIO, PCI-CANIO,PCU-CANIO, PC104-CANIO,
PC104-DVNIO, PC104-DPIO, PCI-ETHIO and CPCI-DPIO comply with the directive 89/336/CEE
and are thus labeled .
For this compliance to be respected, however, a ferrite (provided by Woodhead upon request)
must be fitted on the cable, if the discrete input/output of these boards is used.
Also, all cables on the communication channels must be screened (with screening connected to the
metal case of the connector).
All the applicomIO® boards comply with the the office and the industrial standard except the
PC104-DPIO ver A board which complies with the industrial standard only.
When the PC104-DPIO ver A board is integrated in a host system, take all necessary precautions
to ensure compliance.
Characteristics:
- Operating temperature: 0 to +65 °C
(for extended temperatures on PC104 boards, consult us)
- Storage temperature: -40 to +85 °C
- Dielectric strength (galvanic insulation): 500 Volts
- MTBF : 100,000 hours
PCI bus Characteristics:

The applicomIO® PCI boards are designed to be plugged in a 5V signaling environment. They can‟t
be used in a 3,3V signaling environment.
Power consumption of boards:

PCI-DPIO ver A, PC104-DPIO ver A : 4W
PCI-DVNIO, PCI-CANIO : 7W
PC104-CANIO, PC104-DVNIO, PC104-DPIO ver B
PCI-DPIO ver B, PCU-DPIO ver E, PCI-ETHIO,
PCU-ETHIO ver E, PCU-DVNIO,
PCU-CANIO, CPCI-DPIO : 5.5W

Certificate of Compliance
Declaration of Compliance
We, Woodhead
41, rue Mazagran
76320 Caudebec-lès-Elbeuf
France
Declare that the products:

PCI-DPIO, PC104-CANIO, PC104-DVNIO, PC104-DPIO, PCI-CANIO, PCI-DVNIO, PCI-ETHIO,
PCU-ETHIO, PCU-DPIO, PCU-CANIO, PCU-DVNIO and CPCI-DPIO.
are in conformity with the requirements of the council directive:

No. 89/336/CEE dated 3 May 1989.
Year of application of marking: 1999, 2000, 2002, 2003, 2004, 2005, 2006
Caudebec-lès-Elbeuf, 25/09/2004
Damien LETERRIER, Electronics Development Manager

2. Implementation
Error Messages during Initialization

This article lists the main error messages that you may encounter during the initialization phase,
and it includes some possible troubeshooting options.
Hardware-Related Problems:
 Board x fault number XXXXXXXX

Physical defect on the board. Please contact the applicom international Technical Support
Team.
 Board x not installed or configuration error or No signature for board x
®
 Check that the applicomIO board is inserted in the bus of your PC
 For PC104-type boards, check that the jumper is correctly positioned and that the
memory zone for the board is not already in use.
This message may also appear for a configuration-related problem (see below).
 ERREUR - INITAP – the dongle is not installed on one of the configured boards.
Dongle-related problem. Please contact the applicom international Technical Support
Team.
 Board x prom test OK, but version Vy.z is not compatible
or
ERROR - INITAP – minimum required prom version is X.X. Here, prom version Y.Y is
installed
The prom version of the board is not sufficient for this version of the software. Please
contact the applicom international Technical Support Team.
applicomIO® Knowledge base Implementation Implementation  43

Configuration-Related Problems:
 Board x not installed or error in your configuration. Check your configuration.

 Check that boards are declared in the console. For PC104-type boards, check in
particular that the declared memory implantation address in the console coincides
with the physically validated address on the applicomIO® board.
 It may be necessary to reboot the machine if you have declared new boards.
 Try to resave your configuration and start a new initialization.
 ERROR - PCLOAD - file confapli.ap(x) not found

Configuration file problem. Try to resave your configuration and start a new initialization.
Other Possible Problems:

 Cannot initialize the board(s) since applications are using the DLL!
Close all application using the applicomIO® product.
 Messages containing status = 93
or
ERROR - INITAP - driver not loaded
If possible, reboot the machine, resave your configuration and try a new initialization.
 ERROR - APLOAD - file <file name > not found
One of the files of the applicomIO® product is missing. Restart the set-up and choose
Modify mode. Ensure that all protocols that you are using have been selected:
 If this is not the case, select the protocol and continue with the installation process.
 If this is case, a file of the applicomIO® product has probably been destroyed.
Then go back to choose Repair mode and continue the installation process.

Start-up Synchronization for an Application using applicomIO®
It can be useful to automate the start-up of an application during start-up of a computer. However, if
®
this application uses applicomIO , the boards must be previously initialized. It is therefore useful to
synchronize the end of the initialization with the start-up of the client application.
This is not an issue if you are using the Download to Flash Memory method. In this case, a few
seconds after the board is powered on, it is initialized, even before the end of the start-up for the
operating system.
For standard initialization or automatic initialization, this function is performed by means of a
command file in text format APPUSR.INI located in the sub-directory of the active configuration
(configIO/Configuration name/appuser.ini). The commands in this file are used during the
initialization process. To synchronize the start-up of one or more applications with the end of
initialization, edit this file and insert the following lines one or more times:
a. In standard mode:
 WINEXEC application path\name
b. In automatic mode:
 The command: STARTSERVICE «service name»
In this case, service name is the name of the service as it appears in the Service
Manager.
 The command: STARTSERVICE service name
In this case, service name is the name of the key in the registry base containing
information related to this service. (HKLM\SYSTEM\CurrentControlSet\Services\
service name)
Remarks:
An empty line in the appuser.ini file is considered to indicate the end of the file. The commands
after an empty line will therefore not be executed.
In case of problems, the error is assigned to the text file applicom.log located in the subdirectory
containing the active configuration (configIO/ "Configuration name"/applicom.log)

Simulation mode
Concept
®
Simulation mode enables use of the product without an applicomIO board. In this mode, the
presence of boards is emulated by simulation software (simulation of 1-8 applicomIO® boards).
This enables you to do the following:
 Modify the values of input data for applications using the applicomIO product.
 Simulate communications defects with a specific device.
Simulation mode is particularly useful during the development and testing of an application on a
computer that has no applicomIO® communications boards.
Implementation
The implementation of applicomIO® in simulation mode involves no special difficulties. The

implementation philosophy is virtually identical to that for normal use with applicomIO® boards. This
User Manual reviews the various steps of implementation and highlights some specific features that
differ from normal use.
Configuration
®
Configuration is normally done via the applicomIO console. This console enables you to set the
parameters for your industrial architecture and to define the devices to be used.

To work in simulation mode, just define a simulation-type configuration. To do this, start the
Configuration Manager (File/Configuration Manager menu).
In the configuration properties window, you can change the location of the applicomIO® boards. To
conduct a simulation, select Simulation Mode.
After you have selected the new configuration type, you have to restart the applicomIO® console in
order to work with this new configuration. It will therefore close automatically. Attention: the console
cannot be restarted until all applications using the previous configuration have been closed.

Once the configuration console has been restarted, the user mode of the applicomIO® solution can
be detected by means of the icon of the „Board Configuration‟ node in the tree for the present
configuration.
Normal configuration:
Configuration in simulation mode:

The addition of a new board in simulation mode is done with the same commands as in the normal
operating mode. Of course, automatic detection of boards is not possible. The user must therefore
manually declare the boards being used. The configuration of the EPROM version of the simulated
board is useful only if you must use the „Save Initialization‟ function (see Saving and Replaying an
Initialization Sequence).
Once the boards have been declared, the configuration procedure for simulation mode is strictly
identical to that for a normal configuration. Obviously, however, the automatic detection of network
devices is not possible in simulation mode.
Remark: It is also possible to perform the configuration on a computer in a field network (thus
benefiting from detection mechanisms for network devices) and then to convert this configuration
into simulation mode. This configuration can then be transferred to a simulation machine with the
Restore and Archive commands in the Configuration Manager.

The flow chart below summarizes the main steps in a user configuration.
When all the steps have been completed, you will have to initialize applicomIO® with your new
configuration.
Initialization
Just as normal use requires the configuration to be transferred to the board, simulation mode
requires the configuration to be downloaded into the simulation software so that the present
configuration parameters can be taken into account.
Configuration in simulation mode must first of all be carried out, and then stored using the
®
applicomIO console.
The configuration must then be transferred to the simulator by means of the Board Initialization
command. This command runs the simulation software and transfers the parameters.
Once the software has been activated, any application using the applicomIO® product can be run.
Caution !
To download a new configuration into the simulation software, you must first close the simulation
software before reopening the initialization command.

Use of the Simulation Software
The simulation software opens automatically once the Board Initialization command has been
completed. In this mode, the presence of boards is emulated by simulation software (simulation of
®
1-8 applicomIO boards). This enables you to do the following:
 Modify the values of input data for applications using the applicomIO product.
 Simulate communications defects with a specific device.
 Modify the data format type (Intel or Motorola) for each device. For format changes to take
effect, all application using the applicomIO® solution must be closed.
Remarks:
When the simulation software is open, the input change interface for the “devices” is not visible.
This interface appears when you click on the Details button.
The Cycle Time variable enables simulation of a network cycle time. The higher this value is, the
longer it will take for data changes to be taken into account.

Testing Tools
®
As for a normal configuration, you can use the diagnostic tool that comes with the applicomIO
product. This tool offers valuable assistance in validating the correct operation of your simulation
mode. The tool functions like an application using the applicomIO® product.
It allows you to do the following:
 View input to the selected device (which can be changed by the simulation software).
 Modify output from the selected device.
 View the communication status of the selected device (which can be changed by the
simulation software).
Example:
The simulation software:
 simulates a communications defect on device 12.
 sets value 77 in the first input byte of device 11.

The diagnostic tool (which symbolizes each application using the applicomIO® product) then
indicates that device 12 has a communications defect and that value 77 is set in the first input byte
of device 11.

Remote use via a TCP/IP connection
The applicom solution (hardware or software) is also available under a number of environments,
other than the traditional operating systems in the Windows family. You can therefore benefit from
all the features and performance of the applicom product under environments such as VxWorks,
QNX, Windows CE, etc.
When using applicom product in these environments, however, no configuration tools are available
which run directly under these platforms. To carry out the configuration therefore, the entire series
of configuration and debugging tools can be used remotely, via the TCP/IP socket.
So, in the configuration manager when creating a new configuration you can choose remote use,
then specify the address of the target machine. This means you can use the implementation tools
just as though the configuration was being carried out locally.
You can also save and reload a configuration on the target machine. Consequently, it is easy to
reload a configuration made previously to make modifications, from any machine (Desktop,
portable, etc.)
Full detailed explanations concerning remote use via a TCP/IP connection are included in the
documentation supplied with the product dedicated to your environment.
To use this functionality under Windows, refer to the next article.

Remote Use via a Serial link
Concept
The remote mode via „serial link‟ enables the user to access a remote board from a user station on
®
which the applicomIO product is installed. This mode is of particular interest when the board must
be installed on a machine for which local installation of the applicomIO® product is not possible,
e.g. for non-Windows operating systems.
Implementation
The implementation of applicomIO® in remote mode via serial link involves no special difficulties.
The implementation philosophy is virtually identical to that for normal use with applicomIO® boards.
This User Manual reviews the various steps of implementation and highlights some specific
features that differ from normal use.
Configuration
®

To work in remote mode via serial link, just define a remote machine (serial link) configuration. To
do this, start the Configuration Manager (File/Configuration Manager menu).
access a board via serial link, select Remote Machine (Serial link).

Once the configuration console has been restarted, the user mode of the applicomIO® solution can
be detected by means of the „Board Configuration‟ node in the tree for the present configuration.
Normal configuration:
Remote configuration via serial link:

The configuration of boards in remote mode via serial link is done with the same commands as in
normal mode. However, the remote board is declared by means of a specific dialog box for the
remote configuration:
The user can declare the board being used:

 either manually by using the Manual Selection button,
 or by Automatic Detection, if the board is already accessible. In the latter case, detection
begins with the serial link, and the detection result is displayed in the Automatic Detection
dialog box:
 The user then presses the Accept button to include the detected board in the
configuration.
The Number of the Board in Local Use gives the number attributed to the board by the
applications using the board locally. Caution: this parameter must correspond exactly to the
hardware configuration (using jumpers) attributed to the board for use on the remote machine. If
this is not the case:
 A configuration downloaded into flash memory will not be taken into account when the
board is restarted. This will continue until the hardware configuration has been corrected.
 A configuration transmitted by standard initialization will not enable the local driver to
access the board.

Paramaters for access to the board are configured in the Board Properties windows:
 The COM Port used on the PC for connection.
 Speed of communication.
 Time-out for communication.
Caution: The last parameter specifies a waiting time for response from the board following a
request from a utility using the remote mode via serial link. It is not the Time-out used for
management of byte transmission over the cable.
Once the board has been declared and its access parameters have been set, the method for
configuration in remote mode via serial link is strictly identical to a normal configuration, with the
following exceptions:
 Only one board can be configured at a time.
 Since exchanges with the boards are longer, network feedback will take much longer than
in normal mode.
Initialization
®
In remote mode via serial link, the initialization process for the applicomIO interface is similar to
that for local mode. The loading time will obviously be longer. Once the COM port of your machine
is connected to the board, you can start:
 An initialization of boards via serial link.
 A download into flash memory of the board.
Caution:
During start-up, these initialization processes do not detect whether the board is in use or not.
Therefore, before starting an initialization, ensure that your board is not being used.
Remarks:
 Errors specifically related to the use of the serial link can occur during initialization. Consult
the chapter „More Information on Problems in Use‟.
 During a download to flash memory, only the files that are not present and that have been
modified since the last download are transmitted to the board. This enables considerable
time savings during download. In case of problems, you can always use the Clear Flash
Memory command.
Use
Once all the applications have been closed, after selection of Remote Machine mode in the
console, all restarted applications will use the serial link to communicate with the remote board. The
first time, a warning message will systematically appear to alert you to possible disturbances in the
functioning of the remote board, if the board is being used locally.
To ensure that you have properly established the connection between your computer and the
board, see chapter „Cabling and Indicator‟.
Caution:
Only one application at a time can communicate with the board via the serial link. If an application is
already using the connection, the other applications will return an error message (usually status 51)
when they are opened.

Communications Indicator
An icon will appear in the task bar whenever an application is operating in serial link mode. This
icons indicates the current communications status between the PC and the remote board:
: An application using the serial link has been started.
: An application is connection to the COM port of the PC. (from this moment on, no other application
using applicomIO® can use the connection)
: The dialog is occurring properly over the serial link. In this status, the green light blinks as a
function of the transmission and reception of data over the cable.
: A one-time communications problem has been detected. This icon appears only when the
transmission re-try mechanisms have been activated. Once this icon appears, communication may
either be interrupted completely (red light) or it may restart (green light). If this icon appears
regularly, check your serial connection.
: A communications error has been encountered. The communications status (generally status 63)
has been returned to the application using the serial link. In general, the functioning of the
application is interrupted.
Remark: By moving the mouse cursor over the icon, you can display information in a bubble, in
particular the connection transfer rate, the COM port being used, etc.
Communication Problems
In general, if an application encounters communication problems with the board (status 63 is
returned or the application is blocked), first check that:
 The connection has been properly established between the selected COM port of the PC
®
and the configuration port of the applicomIO board. Check the required cabling in the
“Cabling and Indicator” manual.
 The BIOS of the board is version 4.0 or higher.
If such is the case, close all applications and restart. If the problem continues, first try to modify the
configured speed. As a last resort, reboot the board as well as the computer using the COM port.

Error Statuses for Serial link:
 Status 63 indicates that a communication error has been encountered. In general:
 Either the serial connection has been lost during transfer of a request or response.
 Or a disturbance has caused erroneous values to be exchanged over the line.
 Status 49 indicates that a complete request has reached the board, but that:
 The board could not respond within the console‟s time-out time.
 The serial connection was lost after the arrival of this request, thus preventing the
board from sending its response within the configured time-out.
Remote Use via an Ethernet link

Concept
The remote mode via „Ethernet link‟ enables users to access to remote board from a user station on
®
which the applicomIO product is installed. This mode is of particular interest when the board must
be installed on a machine for which local installation of the applicomIO® product is not possible,
e.g. for non-Windows operating systems.
Limitations
1 – This version of propriotary remote Ethernet protocol does not support WIFI media.
2 – The diagniostic tool is allowed only if the applicom IO board is number one (PCI jumper set
at one).
Implementation
The implementation of applicomIO® in remote mode via Ethernet link involves no special
difficulties. The implementation philosophy is virtually identical to that for normal use with
applicomIO® boards. This User Manual reviews the various steps of implementation and highlights
some specific features that differ from normal use.
« Woodhead Remote Ethernet » protocol installation

The installation of the « Woodhead Remote Ethernet » protocol is slightly different according to the
installed operating system.
With Windows XP: click on “start” button, select “Parameters” and select “panel configuration”.
Open “Network connection”. Select one of network connection and use “properties” from “Files”
menu.
With Windows Vista: click on “start” button, select “Control panel”. Open the “Network and
sharing center”. Then click on “Manage network connections” link in the left panel. Select one of
network connection and use “properties” from “Organize” menu.
With Windows 7: click on “start” button, select “panel configuration”. Open the “View network
status and tasks”. Then click on “Change adapter settings” link in the left panel. Select one of
network connection and use “properties” from Organize menu.

Click on « install »
In the component list, choose « Protocol » and click on “Add”

Select “have a disk”. Select « wsereth.inf » in the folder [applicomIO 2.3 Insall
directory]\Drivers\WSE Remote Ethernet.
Click on « open ».

Click on « OK ».
Restart the computer to enable the protocol
Configuration
®

To work in remote mode via Ethernet link, just define a remote board (Ethernet link) configuration.
To do this, start the Configuration Manager (File/Configuration Manager menu).
access a board via Ethernet link, select Remote Board (Ethernet link).


The configuration of boards in remote mode via Ethernet link is done with the same commands as
in normal mode. However, the remote board is declared by means of a specific dialog box for the
remote configuration:
The User has to choice it Local Network Adapters connected on the same Ethernet media as the
applicomIO board. The Status will indicate the current state of the selected adapter.
The user can declare the board being used:

 either manually by using the Manual tab,
 or by automatic detection, if the board is already accessible by using Automatic tab.
Once the board has been declared and its access parameters have been set, the method for
configuration in remote mode via Ethernet link is strictly identical to a normal configuration, with the
following exceptions:
Manual board configuration.

The user have to know the board number and the serial number of the applciomIO board target.

After to choose one board, click on « >> » to add it on the current configuration.
The field « board number » and « serial number » shall be filed.
The Board Number gives the number attributed to the board by the applications using the board
locally. Caution: this parameter must correspond exactly to the hardware configuration (using
jumpers) attributed to the board for use on the remote machine. If this is not the case:
 A configuration downloaded into flash memory will not be taken into account when the
board is restarted. This will continue until the hardware configuration has been corrected.
 A configuration transmitted by standard initialization will not enable the local driver to
access the board.

Automatic configurattion
To be able to do an automatic detection, the applicomIO board shall be connected on the same
ethernet network than the local network adapter selected.
To start the detection, click on « detect ».

After detection, a « blink » button allows to start a blink sequence on selected board.
Different information in the detected board list:
1. Icone:
- This board could be add in the configuration.
- this board is used by another client.
2. Board number (jumper configuration)
3. serial Number.
4. Host mac adress.
Existing configuration to Remote Ethernet configuration.
It is allowed to change the configuration type to Remote Ethernet configuration type. To do this, the
user has to choose “Remote Ethernet” form the configuration manager (FILE/configuration
manager).
Limitation :

It‟s not allowed to select “Remote Ethernet” if the current configuration has more than on configured
board.
Initialization
®
In remote mode via Ethernet link, the initialization process for the applicomIO interface is similar
to that for local mode. You can start:
 An initialization of boards via Ethernet link.
 A download into flash memory of the board.
Caution:
During start-up, these initialization processes do not detect whether the board is in use or not.
Therefore, before starting an initialization, ensure that your board is not being used.
Remarks:
 During a download to flash memory, only the files that are not present and that have been
modified since the last download are transmitted to the board. This enables considerable
time savings during download. In case of problems, you can always use the Clear Flash
Memory command.
Use
Once all the applications have been closed, after selection of Remote Board (Ethernet link) mode
in the console, all restarted applications will use the Ethernet link to communicate with the remote
board. The first time, a warning message will systematically appear to alert you to possible
disturbances in the functioning of the remote board, if the board is being used locally.
To ensure that you have properly established the connection between your computer and the
board, see chapter „Cabling and Indicator‟.
Caution:
In the same time, only one host is allowed to communicate with applicomIO board.

Saving and Replaying an Initialization Sequence
Concept
®
The applicomIO product is a fully integrated Windows product that comes with a configuration
console and board initialization software. The applicomIO® product therefore enables you to use
applicomIO® boards installed locally on the MS-Windows machine. In some special contexts,
applicomIO® boards can also be used :
 In MS-Windows-type environments designed for the embedded computing market.
 In various other environments (DOS, Linux, VxWorks, QNX, etc.).
In the above two cases, configuration and initialization tools cannot be used on the target machine.
To remedy this, the applicomIO® product proposes three options enabling the user to configure and
initialize the boards in any environment:
 Initialization (or download into flash memory) of applicomIO® boards by serial link.
Initialization is done by means of a serial link between the COM port of the machine on
which the configuration console is installed and the serial port of the applicomIO® board
installed on the remote machine. This function is described in a separate chapter:
“Initialization via the serial port”.
 Initialization (or download into flash memory) of applicomIO® boards by Ethernet link.
Initialization is done by means of an Ethernet link between the local network board of the
machine on which the configuration console is installed and the Ethernet port of the
applicomIO® board installed on the remote machine. This function is described in a
separate chapter: “Initialization via the Ethernet Link”.
 Initialization (or download into flash memory) of applicomIO® boards by replaying an

initialization file previously generated on a Windows platform. In this case, the initialization
can be replayed as many times as you wish, using a simple utility for which the source (in C
ANSI and thus easily recompiled in the target platform) is available upon request. This
solution is preferable if your applicomIO® boards do not have a serial port (e.g. PCI-DPIO
boards) or if initialization by serial link is impossible (remote problem, etc.).
Remark: The serial and Ethernet port solution have the advantage of enabling automatic detection
of network devices.

Saving an Initialization Sequence or a Flash Memory Download Sequence
The file enabling initialization (or download into flash memory) must be generated on a machine
equipped with the following:
 MS-Windows (XP, 2003, Vista, 2008, 7)
®
 An applicomIO solution
This process is normally done with an applicomIO® console, and it involves no special difficulties.
The device configuration philosophy is virtually unchanged. Some special features are outlined
below.
To generate an initialization file (or download into flash memory ), define a simulation-type
configuration. To do this, open the Configuration Manager (File/Configuration Manager menu).

conduct a simulation, select Simulation Mode. Then, to validate the generation of an initialization
file, tick the box Save the Initialization to Disk.
order to work with this new configuration.
Once the configuration console has been restarted, the configuration is carried out like a
configuration in simulation mode.
Remark: By default, the “Save the Initialization to Disk” option is available only for a simulation-
type configuration. However, it is possible to use this process on a local-type configuration (normal
use). To do this, you must start the console in Expert mode (accessible from the File/Preferences
menu). Attention: In this case, the boards must be installed on the machine being configured.
Generation of an Initialization File or a Flash Memory Download File

®
File generation is done using the normal commands of the applicomIO console :
Board Initialization
This command generates an initialization file “applicomIO.ply” in the configIO\XXXX sub-directory
(where XXXX is the name of your configuration in simulation mode). Once the initialization phase
has been completed, the file can be used to initialize applicomIO® boards installed on a remote
machine (the installed boards must obviously conform with the declared boards in the applicomIO®
console).
Downloading into Flash Memory
This command generates an initialization file “applicomIOflash.ply” in the configIO\XXXX sub-
directory (where XXXX is the name of your configuration in simulation mode). Once the
downloading phase has been completed, the file can be used to download into flash memory
applicomIO® boards installed on a remote machine (the installed boards must obviously conform
with the declared boards in the applicomIO® console).

Replaying the Initialization File or the Flash Memory Download File
®
Initialization (or downloading into flash memory) of applicomIO boards is done by replaying an
initialization file previously generated on a Windows platform. This initialization can be replayed as
many times as you want in any environment by simple porting and recompilation of a utility whose
source (in the form of a Windows console application) is available upon request.
As an example, this utility software, known as playerIO.exe comes with the applicomIO® solution
package. To start the initialization process from a file, open the playerIO utility without entering an
argument. The utility then enables you to enter the name of the initialization file.
To obtain the list of arguments accepted by this utility, open it by means of the /? option. .
Once the initialization file has been run, the applicomIO® boards will :
 either be initialized in a volatile manner, if the file was generated via a simple initialization
command,
 or be initialized in a persistent manner (by updating of their flash memory and restarting of
the boards upon completion of the download into flash memory), if the file was generated
from a command to download into flash memory.

3. CANopen
Description of a CANopen EDS file

Structure of an EDS file
These files are standardized by the CiA, in document "Electronic Data Sheet Specification for
CANopen", appendix of DS 301.
An EDS file contains all the information you need to configure your equipment.
It is presented in text format and can therefore be opened with a simple text editor like Windows
NotePad, or any other ASCII file editor. The file structure is very similar to that of Windows ".INI"
initialization files. As in these files, there are sections.
A section can be recognized by a text between square brackets such as [FILEINFO] or [1602sub1],
followed by values assigned to keys.
The format used when assigning a value to a key must always be as follows: KEY_NAME=VALUE
The section and key names are standardized and invariant whatever the language used in the file.
Information sections of an EDS file

Section [FileInfo]
This section is purely informative. It may be useful for management of versions, updates, or the
various sources. The main keys of this section are:
Key Description Value

Description Name of the device it is linked to alphanumeric
FileName File name alphanumeric
FileVersion File version alphanumeric
FileRevision File revision alphanumeric
CreationDate Creation date date
CreationTime Creation time time
ModificationDate Modification date date
ModificationTime Modification time time
CreatedBy Created by alphanumeric
ModifiedBy Modified by alphanumeric
This section can be consulted directly in the console using the main menu command
"Library/Property/.. EDS Information tab .../FILEINFO".
Section [DeviceInfo]
This section is purely informative. It describes the device characteristics, e.g.:
VendorNumber Vendor number alphanumeric
ProductNumber Product reference number alphanumeric
ProductVersion Product version alphanumeric
ProductRevision Product revision alphanumeric
applicomIO® Knowledge base Implementation CANopen  75

OrderCode Order code alphanumeric
BaudRate_XXXX Baud rate supported NO = 0
YES = 1
VendorName Vendor name alphanumeric
ProductName Product name alphanumeric
This section can be consulted directly in the console using the main menu command
"Library/Property/.. EDS Information tab .../DEVICEINFO".
Sections of the object dictionary of an EDS file

Object dictionary tree structure
These sections correspond to the objects of your device.
The storage structure has the following format:

If the "SubNumber" key contained in the main section of an object is zero, then the information can
be stored in two ways:
st
 1 case: The value is stored directly in the main section
This is the most common case.
Object:1000
Object value: 0x00030191
[1000]
SubNumber=0
ParameterName=device type
ObjectType=0x07
DataType=0x0007
AccessType=ro
LowLimit=
HighLimit=
DefaultValue=0x00030191
PDOMapping=0
nd
 2 case: The value is stored in subsection 0
Object: 1A00
Object value: 0x60000108
[1a00]
ParameterName=TransmitPDO1 Mapping
ObjectType=0x8
DataType=0x21
AccessType=rw
PDOMapping=0
SubNumber=0
[1a00sub0]
ParameterName=1.MappedObject
ObjectType=0x7
DataType=0x7
AccessType=RO
DefaultValue=0x60000108
PDOMapping=0
If the "SubNumber" key is greater than zero however, the storage structure must have the
following format:
[6000]
ParameterName=ReadState8InputLines
ObjectType=0x8
DataType=0x5
AccessType=ro
PDOMapping=0
SubNumber=0x3
[6000sub0]
ParameterName=NumberOfElements
ObjectType=0x7
DataType=0x5
AccessType=RO
DefaultValue=2
PDOMapping=0
[6000sub1]

ParameterName=ReadState8InputLines_1H_8H
ObjectType=0x7
DataType=0x5
AccessType=RO
PDOMapping=1
[6000sub2]
ParameterName=ReadState8InputLines_9H_10H
ObjectType=0x7
DataType=0x5
AccessType=RO
PDOMapping=1
The main keys used:
ParameterName Parameter name or function alphanumeric
ObjectType Contains the object code Numeric
DataType Index in the standardized data Numeric
types
DefaultValue Object default value Depends on the type of data
AccessType Data access type Read only = ro
Write only = wo
Read and write = rw
LowLimit Minimum value Numeric
HighLimit Maximum value Numeric
PDOMapping Mappable data No = 0
Yes = 1
SubNumber Number of subobjects From 0 to 255
Mandatory sections of the object dictionary

a. [1000]
This section indicates the device profile. It is a very important section since the
function of objects [6000] to [9FFF] depends on it.
This section is displayed in the console via the various branches of the
resource area.
b. [1001]
This section is used, if the device supports it, to map the error register, in the
input/output frames.

Sections used to build the PDOs
The following sections are used to create and adjust the PDO data transport frames.
They can be divided into two groups:
1-Frame properties:
 From [1400] to [15FF]: PDO in reception (from PDO1 to PDO512)
 From [1800] to [19FF]: PDO in transmission (from PDO1 to PDO512)
They contain the following subgroups:
SubObject Description Value
XXXXsub1 COB-ID of the PDO From 0x181 to 0x57F
XXXXsub2 Transmission type From 0 to 240 and from 252 to 255
XXXXsub3 Inhibit Time From 0 to 65535
2-Frame mapping:
 From [1600] to [17FF]: PDO in reception (from PDO1 to PDO512)
 From [1A00] to [1BFF]: PDO in transmission (from PDO1 to PDO512)
The mapping of the first RPDO consists of the content of objects [1600sub1] to [1600sub8]; that
of the second, objects [1601sub1] to [1601sub8], …
Sections describing the input/output objects

applicomIO® only supports objects of 8, 16, 24, 32, 40, 48, 56 and 64 bits, any other object will
be ignored.
Standardized objects, defined by the profile:
 from [6000] to [9FFF]
These sections describe the input/output objects defined by the equipment profile
Manufacturer objects:
 from [2000] to [5FFF]
These sections describe the input/output objects specific to the manufacturer

ApplicomIO generic CANopen EDS file
Description
You are given the file "generic.eds" so you can configure a device for which you do not yet have a
file EDS.s
This file contains the standard CANopen objects (CIA DS301) and the specific objects of profile
401.
Caution: this file contains no relevant information about your device.
Use
This file allows you to use the basic functionalities of a device with I/O profile.
It will be proposed automatically during network detection if no valid EDS file corresponding to your
device is detected.
It contains the following objects:
- 0x1000 : Device Type
- 0x1001 : Error Register
- 0x1002 : Manufacturer Status Register
- 0x1003 : Pre-defined Error Field
- 0x1005 : COB-ID SYNC
- 0x1006 : Communication Cycle Period
- 0x1007 : Synchronous Window Length
- 0x1008 : Manufacturer Device Name
- 0x1009 : Manufacturer Hardware Version
- 0x100A : Manufacturer Software Version
- 0x100C : Guard Time
- 0x100D : Life Time Factor
- 0x1010 : Store Parameters
- 0x1011 : Restore default Parameters
- 0x1200 : Server SDO Parameter
st
- 0x1400 : 1 Receive PDO Parameter
nd
rd
th
st
- 0x1600 : 1 Receive PDO Mapping
nd
rd
th
st
- 0x1800 : 1 Transmit PDO Parameter
nd
rd
th
st
- 0x1A00 : 1 Transmit PDO Mapping
nd
rd
th
- 0x6000 : Read Input 8-Bit
- 0x6200 : Write Output 8-Bit
- 0x6401 : Read Analogue 16-Bit
- 0x6411 : Write Analogue 16-Bit.

CANopen equipment detection method
Description
Detection of CANopen equipment is carried out by reading the following objects in the equipment
dictionary:
c. Object Index 1000h: Device Type. Mandatory object must be present for detection.
d. Object Index 1008h: Manufacturer Device Name. Optional object, if this object is missing
the device name will be "Unknown device".
e. Object Index 1018h Subindex 02h: Product Code of Identity Object. Optional object which
only exists as of CANopen version 4.0.
f. Objects 1400h, 1600h (communication parameters and mapping parameters) for the 4
possible RPDOs.
g. Objects 1800h, 1A00h (communication parameters and mapping parameter) for the 4
possible TPDOs.
®
applicomIO must then make the link with an EDS file. The file must have criterion 1 and one of
the following 3 criteria 2, 3, or 4:
1 – Identical profile mandatory condition: Input [1000]-DefaultValue of the EDS identical to the
Device Type object read (first 16 bits)
2 – Identical product numbers: Input [DeviceInfo]-ProductNumber of the EDS identical to the

Product Code of Identity Object object read.
3 – Product number in the device name: Input [DeviceInfo]-ProductNumber of the EDS contained in
the Manufacturer Device Name object read.
4 – Product name in the device name: Input [DeviceInfo]-ProductName of the EDS contained in the
Manufacturer Device Name object read.
If several files correspond to the criteria only one must be selected. If none of these criteria is
respected, applicomIO® suggests using file "generic.eds".

Solving CANopen network problems
Checking your hardware installation
The CAN bus

It forms the ISO layers 1 and 2 of CANopen, enables in-depth self-inspection of the integrity of the
transported data. All errors detected on it by one of the elements is reflected onto the others by an
error frame mechanism and more or less severe penalties, extending up to exclusion of the
deficient device: Bus Off.
During the implementation of your network, these very powerful mechanisms can block it
completely after just a few milliseconds operation, making detection of hardware problems very
difficult.
To ensure efficient implementation and maintenance, cables fully adapted to carrying CAN signals
(line impedance, specific capacitance), network geometry as linear as possible (even though other
topologies are still possible in theory) and good quality connectors are essential.
Standardization of the CAN bus does not define the network medium, however the CANopen
standard recommends the use of a differential pair. Since it provides excellent immunity against
electromagnetic interference, this solution can be used in industrial environment. Nevertheless, use
of differential mode makes finalizing the wiring slightly more difficult than simple mode single wire.
Detail of CAN bus in differential mode:
Note that a differential pair has a "polarity", identified by the "CAN high" and "CAN low" lines,
which must not be crossed under any circumstances.
Note also that there is an impedance adapter resistor at each end, which avoids signal rebounds on
the line. The value of these resistors mainly depends on the impedance of the cable used, the line
geometry and the transmission speed. Standard ISO 11898 defining a line with a transmission
speed of 1Mbit/s, recommends the use of cable with impedance 124 ohms and therefore RT values
between 118 and 130 ohms.
For further details consult the document "CIA Draft Recommendation DR-303".

Remember that the maximum transmission speed and final size of your network are closely linked:
Transmission speed Maximum bus length

1 Mbit/s 25 m
800 kbit/s 50 m
500 kbit/s 100 m
250 kbit/s 250 m
125 kbit/s 500 m
100 kbit/s 620 m
50 kbit/s 1 km
20 kbit/s 2,5 km
10 kbit/s 5 km
If the transmission speed is too high compared with the topology, frame collisions may occur and all
devices will therefore be set to "Bus Off" status.
The CANopen network

The CANopen master initializes the various devices configured and manages the network.
The diagnostic tool can be used to display the various events which could generate device start-up
1
problems .
During network detection, problems may also be observed on the bus: stations are polled very
quickly, no stations are detected, stations are partially detected, etc. In this case, it is best to use
the on line actions to locate the problem before initializing the board.
See also:
 In the knowledge base:
®
 Initialization principle of the applicomIO CANopen master and the network.
 In the documentation:
 Hardware Installation : Wiring and indicator lamps on PCI-CANIO

CANopen on line action
The CANopen protocol can be used to send SDO frames and NMT commands, used respectively
to configure, initialize and check it.
®
The applicomIO CANopen console groups these actions and displays them in two screens:
- CANopen on line action: "Network" tab
- CANopen on line action: "Station" tab
CANopen on line action: 'Network' tab
» CAN Bus
Status of the CAN bus:
: the CAN controller status is Bus Off: no communication is possible.
: No communication problem on the CAN bus.
» Network/Station
Status of the Network Manager:
: Communication problem with at least one of the devices configured (device missing,
configuration error, problem on the device, etc.).
: No communication problem, all configured devices are present and running.
» Bus Load
Minimum, current and maximum network load.
» Rx
Total number of bytes received.
» Tx
Total number of bytes sent.
» Rx Frames/s
Number of frames received per second.

» Tx Frames/s
Number of frames transmitted per second.
» OverRun
Reception buffer overrun counter. It displays the minimum number of frames lost.
» Errors
CAN transmission or reception error counter (error flag of the CAN2.0B protocol). It displays the
number of times when at least one of the transmission or reception error counters of the CAN
controller has reached or exceeded the threshold of 96.
» Bus Off
CAN controller Bus Off status counter. It displays the number of times that the transmission error
counter has reached the value 255.
» Reset Counters
Resets counters to zero: Rx and Tx, Rx Frames/s and Tx Frames/s counters, OverRun counter,
Error counter, BusOff counter and network load.
» Transmission Speed
Transmission speed as configured in the CANopen master.
» Reset Node
Transmits the NMT "Reset Node" command to all devices in the network.
» Reset Communication
Transmits the NMT "Reset Communication" command to all devices in the network.
» "Operational" Status
Transmits the NMT "Set Operational" command to all devices in the network. Used to start the
devices.
» "Pre-Operational" Status
Transmits the NMT "Set Pre-Operational" command to all devices in the network. Used to configure
the devices.
» "Stopped" Status
Transmits the NMT "Set Stopped" command to all devices in the network. Used to stop the devices.

CANopen on line action: 'Station' tab
» Station Number
Used to input the number of the station to be interrogated (1-127).
» Station Name
Displays the device name read on the network in the object 0x1008.
» Save Parameters
Save the parameters in the device's memory.
The saved parameters correspond to the last configuration sent to the board.
Use of the CANopen 0x1010 object under index 0x01: “Store parameters to all parameters that can
be saved” with the value “save” (0x73 0x61 0x76 0x65).
» Default Parameters
Resets device parameters to default values (manufacturer's parameters).
Use of the CANopen 0x1011 object under index 0x01: “Restore default parameters to all
parameters that can be restored” with the value “load” (0x6C 0x6F 0x61 0x64).
» Generating the EDS File
Performs a full read/write of the objects in the stations and generates a corresponding EDS file.
» Index
Enter the index of the object to be read or written in the equipment dictionary.
» Sub-Index
Enter the sub-index of the object to be read or written in the device dictionary.
» Read
Reads from the device dictionary the object referenced by the index and sub-index.
» Write
Writes in the device dictionary the object referenced by the index and sub-index.
» Read Area
Displays the bytes read in hexadecimal and in ASCII.

» Write Area
Used to enter in hexadecimal or ASCII the bytes which must be written.
» Read/Write Results
Displays a report of the SDO command executed:
ACCESS OK TO THE OBJECT DICTIONARY:

No error. The result is in the read or write area.
STATION IN "TIME-OUT"
The device does not answer: the device does not exist, wiring, power supply or speed
problem, etc.
ERROR ACCESSING THE OBJECT DICTIONARY

The object does not exist: check the index and/or the sub-index.
On a write, the object is in read only (RO attribute).
» Reset Node
Transmits the NMT command "Reset Node" to the device.
» Reset Communication
Transmits the NMT command "Reset Communication" to the device.
» "Operational" Status
Transmits the NMT command "Set Operational" to the device. Used to start the equipment.
» "Pre-Operational" status
Transmits the NMT "Set Pre-Operational" command to the device. Used to configure the device.
» "Stopped" Status
Transmits the NMT command "Set Stopped" to the device. Used to stop the device.

Description of a PDO
Real time data transfer in the CANopen network is carried out using specialized frames: the PDOs.
They are based on the standard data frames of the CAN 2.0A protocol
The transfer type is "Producer / Consumer". In other words the data sent onto the network may be
intended for one or more recipients (or none!), the producer not checking the reception. This is
possible due to the high level of security on the CAN network (layer ISO 2).
The quantity of data carried by a PDO is limited to 64 bits, with granularity of 8 bits.
There are two types of PDO:
- “Transmit PDO” or TPDO
- “Receive PDO” or RPDO
TPDOs travel from the master to the device. They correspond to the device output modules (e.g.:
actuators, commands, etc.).
RPDOs travel from the device to the master. They correspond to the device input modules (e.g.:
temperature sensor, position sensor, etc.).

Initialization principle of the applicomIO® CANopen master and the network
Description
®
The applicomIO CANopen master is used to group all the inputs/outputs of the devices in a
DPRam memory area. To do this, each device is configured by sending SDO messages in order to
initialize its communication and input/output mapping parameters.
The master also manages the device monitoring by "Node Guarding" and automatic device restart.
Start-up phases
1 – Transmission of a "Reset Node" broadcast to all devices.
2 – Transmission of the SDO messages referenced in "Device properties/Object dictionary" for
each device.
3 – Start-up of "Node Guarding" if it is valid (Guard Time and Time Life Factor not 0) for each
device.
4 – Individual start-up of each device if all SDO messages could be sent.
Potential problems
Device missing, bad speed or bad station number
The device does not start: the diagnostic tool indicates "Error SDO: Timeout"
Error in an SDO message (cannot access the object)
The device does not start: the diagnostic tool indicates "Error SDO: Abort Transmit".
Wiring problem, incorrect load resistance or interference on the line
The device starts with difficulty after quite a long time: the diagnostic tool indicates "Error SDO:
Timeout" and "Error NMT: Guarding Fail".
Other CANopen master on the line
The device restarts regularly, access to inputs/outputs is random.
'Emergency' messages
The device operates correctly but the diagnostic tool generates "Emergency" messages, e.g.: short
circuit on an output (emergency current error), power supply fault of outputs (emergency voltage
error), protocol error (emergency protocol error), etc.
The list of possible errors consists of the standard emergency messages (CIA DS301) and the
specific manufacturer emergency messages described in the device documentation.

Analysis and use of the 'SDO abort codes' messages
Description
The "SDO abort codes" are displayed with the diagnostic tool in the "Events" tab:
Each event is stored in chronological order of arrival. The event characteristics can be consulted by
double clicking on the 1st column of the corresponding line or with the "Property" button.

The events "Error SDO: Abort Transmit" contain the following characteristics:
This information corresponds to the "Abort Sdo Transfer Protocol" in document CIA DS301.
Case of "Abort SDO":
 Object declared as "rw" in the EDS and only as "ro" in the device, check the manufacturer's
EDS file.
 Object size in the EDS inconsistent with that in the device, check the manufacturer's EDS
file.
 Objects 1400Sub1 to 15FFSub1, 1800Sub1 to 19FFSub1: PDO not available, delete it from
the configuration in "Device property/ PDO message and I/O mapping".
 Objects 1400Sub2 to 15FFSub2, 1800Sub2 to 19FFSub2: Requested transmission mode
impossible for this PDO, check the manufacturer's documentation and set a transmission
mode supported for the PDO in "Device property/PDO message and I/O mapping".
 Objects 1600 to 17FF, 1A00 to 1BFF: too many objects in the mapping or objects not
mappable, check the configuration in "Device property/PDO message and I/O mapping".
 Other type of error specific to the manufacturer, refer to the device documentation.

Automatic generation of an EDS file
Description
The "Generate EDS file" functionality in the “Network detection tab/On line action
button/Station tab” is used to generate an EDS file with the information contained in the station
connected on the bus, using read/write objects via SDO messages.
The "Start" button is used to start file generation by polling the station. First choose the destination
file:
®
By default, the file DetectAuto.eds in the directory "CanOpen_eds" of the applicomIO work
directory is proposed. Accept the file name to start generation with the "Save" button or cancel with
the "Cancel" button.

Reading of the objects in the dictionary then starts:
Detection ends with the "Stop" button or by waiting until the EDS file has been 100% generated.
Validate with the "OK" button (or cancel with "Cancel"):
You can add the file generated to the device library so that it can be integrated in the configuration.
Procedure
Detection/generation of the EDS file takes place by reading and/or writing all the objects of indices
0x1000 to 0x9FFF of the device on line. These reads/writes are made using SDO messages and
are therefore very time consuming, depending on the bus transmission speed. Objects are built in
the EDS as follows:
- Index 0x1000 to 0x1FFF: "Communication objects", the name, size and access of the parameters
are set in standard DS301.
- Index 0x2000 to 0x5FFF: "Manufacturer objects", the name is generic of type "Entry XXXXSUBYY
no parameter name" where XXXX = index in hexadecimal and YY=sub-index in hexadecimal, the
size is determined according to the number of bytes in the reply to the read, the access type is
determined by making a write after the read.
- Index 0x6000 to 0x9FFF: "Standardized objects", the name, size and access depend on the
profile used, they are not currently referenced in the automatic generation. The same rule is
therefore used as for the "Manufacturer objects".

Functionalities accessible by AuWriteReadMsg_io.
Description
These functionalities are used to:
1. read or write an object in the object dictionary of a configured device,
2. send a NMT command to a configured device,
3. send a CAN frame and receive a reply to this transmission,
4. manage the "emergency" (EMCY) events.
5. read a FIFO containing all the PDOs consumed by the applicomIO CANopen master.
6. write a large SDO object (maximum size 65535 bytes)
7. read the state of a CANopen node
All these functionalities can be accessed with the function AuWriteReadMsg_io in the messaging
mode library.

Reading an SDO object with the function AuWriteReadMsg_io.
The functionality used to read an SDO object is accessible in the messaging mode library.
Use with the function AuWriteReadMsg_io of the DLL applicomio.dll

Function prototype:
C: AuWriteReadMsg_io (wChan, wEquip, dwMsgParam, wNbTx, &byBufTx, &wNbRx, &byBufRx,
&dwStatus);
Definition of function parameters:

- wChan: 16-bit word indicating the targeted applicomIO® channel; it is determined with the
CARD2CHAN macro, which transforms a board number into a channel number (channel =
(board-1)*4 ).
- wEquip : number of the targeted applicomIO® device (1 to 127).
- dwMsgParam : 32-bit word containing the SDO parameters to be read
bit 31
bit 0
byte 3 byte 2 byte 1 byte 0
not used Sub-index Most significant end of Least significant end of
the index the index
- wNbTx: number of bytes to transmit = 1.

- lpbyBufTx: pointer to the transmission buffer whose 1st byte contains the command 0x01.
- pwNbRx : pointer to the number of bytes received:
* On calling: indicates the maximum size of the reception buffer.
* In return: indicates the number of bytes received if dwStatus=0.
- lpbyBufRx: pointer to the reception buffer.
- pdwStatus: pointer to an applicomIO® error status 32-bit word 1

Writing an SDO object with the function AuWriteReadMsg_io.
The functionality used to write an SDO object is accessible in the messaging mode library.

Function prototype:
&dwStatus);
- wChan : 16-bit word indicating the targeted applicomIO® channel; it is determined with the
(board-1)*4 ).
- dwMsgParam : 32-bit word containing the SDO parameters to be written:
bit 31
bit 0
the index the index
- wNbTx: number of bytes to transmit = 1 + size of the value to be written in the object.
- lpbyBufTx : pointer to the transmission buffer whose 1st byte contains the command 0x02 and
the next ones contain the bytes forming the value to be written.
* On calling: indicates the maximum size of the reception buffer (meaningless for
the SDO write).
* In return: indicates the number of bytes received if dwStatus=0 (meaningless for
the SDO write).
- lpbyBufRx: pointer to the reception buffer: meaningless for the write.
- pdwStatus : pointer to an error status 32-bit word 1

Sending an NMT command with the function AuWriteReadMsg_io.
The functionality used to send an NMT command is accessible in the messaging mode library.

Function prototype:
&dwStatus);
- wChan : 16-bit word indicating the targeted applicomIO® channel; it is determined with the
(board-1)*4 ).
- dwMsgParam : 32-bit word, meaningless for the NMT commands
- wNbTx : number of bytes to transmit = 1.
- lpbyBufTx : pointer to the transmission buffer whose 1st byte contains the NMT command:
 0x03 : "NMT Reset module" :
 0x04 : "NMT Reset communication module"
 0x05 : "NMT Set module pre-operational"
 0x06 : "NMT Set module operational"
 0x07 : "NMT Set module prepared (stopped)"
the NMT commands).
the NMT commands).
- lpbyBufRx: pointer to the reception buffer: meaningless for the NMT commands.
- pdwStatus: pointer to an error status 32-bit word 1

Transmission/Reception of a CAN frame with the function AuWriteReadMsg_io.
The functionality used to for transmission and reception of a CAN frame is accessible in the messaging mode
library.

Function prototype:
&dwStatus);
(board-1)*4 ).
- wEquip: number of the targeted applicomIO® device = 128.
- dwMsgParam: 32-bit word indicating the CAN message transmission COB-ID.
bit 31
bit 0
Byte 3 byte 2 byte 1 byte 0
not used not used Most significant end of Least significant end of
the transmission COB-ID the transmission COB-ID
If transmission COB-ID = 0x0000 then the transmission is not made.

- wNbTx: number of bytes to transmit = 3+ Number of data bytes in the CAN frame (1 to 8).
- lpbyBufTx: pointer to the transmission buffer whose first 3 bytes contain the following values:
 lpbyBufTx[0] : 0x08.
 lpbyBufTx[1] : Least significant end of the reception COB-ID
 lpbyBufTx[2] : Most significant end of the reception COB-ID
If reception COB-ID = 0x0000 then the reception is not made.
The reception is blocking with a 10 s time-out.
- pwNbRx: pointer to the number of bytes received:
* On calling: indicates the maximum size of the number of data items in the CAN
frame to be received.
- lpbyBufRx: pointer to the reception buffer (data of the CAN frame received).
Caution: reception of a CAN message is only valid if the reception COB-ID is not used by the
board, for example the reception IDs of the SDOs, device TPDOs, EMCYs etc. cannot operate.

Management of "Emergency" (EMCY) events with the function
AuWriteReadMsg_io.
The functionality used to manage "Emergency" events is accessible in the messaging mode library.

Function prototype:
&dwStatus);
(board-1)*4 ).
- dwMsgParam: 32-bit word, meaningless for management of EMCYs
- lpbyBufTx: pointer to the transmission buffer whose 1st byte contains the EMCY management
command:
 0x09 : Clear EMCY event list.
 0x0A : Read one EMCY event.
* On calling: indicates the maximum size of the reception buffer = 26 bytes.
- lpbyBufRx: pointer to the reception buffer: containing the EMCY event during the: "Read one
EMCY event".
Format of the data received during a "Read one EMCY event":
lpbyBufRx[0] = Least significant end of the number of events read.
lpbyBufRx[1] = Most significant end of the number of events read.
lpbyBufRx[2] = Least significant end of the number of events still to be read.
lpbyBufRx[3] = Most significant end of the number of events still to be read.
If number of events read > 0, the following data is received:
lpbyBufRx[4] = Least significant end of the number of bytes of the event =0x16.
lpbyBufRx[5] = Most significant end of the number of bytes of the event =0x00.
lpbyBufRx[6] = Least significant end of the event type = 0x00.
lpbyBufRx[7] = Most significant end of the event type = 0x02.
lpbyBufRx[8] = Least significant end user word (meaningless).
lpbyBufRx[9] = Most significant end user word (meaningless).

lpbyBufRx[10 .15] = Timestamping 6 bytes (48 bits) describing a format
Year/Month/Day/Hours/Minutes/Seconds/Milliseconds:
bit 48 40 36 32 27 24 22 16 10 8
bit 0
Byte 6 Byte 5 Byte 4 Byte 3 byte 2 byte 1
Year Month Day Time Min Sec Millisec

12 bits 4 bits 5 bits 5 bits 6 bits 6 bits 10 bits
lpbyBufRx[16] = Least significant end of the applicomIO® device number concerned.

lpbyBufRx[17] = Most significant end of the applicomIO® device number concerned.
lpbyBufRx[18] = Least significant end EMCY "error code".
lpbyBufRx[19] = Most significant end EMCY "error code".
lpbyBufRx[20] = EMCY "error register".
lpbyBufRx[21] = Byte 1 Manufacturer “error field”.

Reading the PDO FIFO with the function AuWriteReadMsg_io.
The functionality used to read the FIFO containing the PDOs used by the ApplicomIO CANopen master is
accessible in the messaging mode library.
This FIFO must be validated in the configurator for each device configured. It operates according to the First In First
Out principle, each time an event is read it is automatically deleted from the FIFO. A special command is used to
clear all FIFO events.

Function prototype:
&dwStatus);
(board-1)*4 ).
- dwMsgParam: 32-bit word, meaningless for management of PDOs
- lpbyBufTx: pointer to the transmission buffer whose 1st byte contains the PDO management command:
 0x0B: Clear PDO event list.

 0x0C: Read PDO event.
 * On calling: indicates the maximum size of the reception buffer = 29 bytes.

 * In return: indicates the number of bytes received if dwStatus=0.
- lpbyBufRx: pointer to the reception buffer: containing the PDO event during the: "Read PDO event" .
Format of the data received during a "Read PDO event":
Data format for a PDO event:
lpbyBufRx[0] = Least significant end of the number of events read.
lpbyBufRx[1] = Most significant end of the number of events read.
lpbyBufRx[2] = Least significant end of the number of events still to be read.

lpbyBufRx[3] = Most significant end of the number of events still to be read.
If number of events read > 0, the following data is received:
lpbyBufRx[4] = Least significant end of the number of bytes of the event =0x16.
lpbyBufRx[5] = Most significant end of the number of bytes of the event =0x00.
lpbyBufRx[6] = Least significant end of the event type = 0x00.
lpbyBufRx[7] = Most significant end of the event type = 0x02.
lpbyBufRx[8] = Least significant end user word (meaningless).
lpbyBufRx[9] = Most significant end user word (meaningless).
lpbyBufRx[10 .15] = Timestamping 6 bytes (48 bits) describing a format

Year/Month/Day/Hours/Minutes/Seconds/Milliseconds:
bit 48 40 36 32 27 24 22 16 10 8
bit 0
Byte 6 Byte 5 Byte 4 Byte 3 byte 2 byte 1
Year Month Day Time Min Sec Millisec

12 bits 4 bits 5 bits 5 bits 6 bits 6 bits 10 bits
lpbyBufRx[16] = Least significant end of the applicomIO® device number concerned.
lpbyBufRx[17] = Most significant end of the applicomIO® device number concerned.
lpbyBufRx[18] = Least significant end COB-ID.
lpbyBufRx[19] = Most significant end COB-ID.
lpbyBufRx[20] = Number of bytes of the PDO
lpbyBufRx[21] = Byte 1 PDO.


Writing SDO object which size is greater than 255 bytes with the function
AuWriteReadMsg_io.
The functionality, used to write a SDO which size is greater than 255 bytes, is accessible in the messaging mode
library.
The maximum size of a SDO object is 65535 bytes (0xFFFF).
To use this feature, proceed to the following 3 steps:
 Send initialization parameters (Index, Sub-index, object size).

 Send data to transmit (fragmented in packets of 255 bytes max).
 Write SDO object to the device.
These 3 steps are available with AuWriteReadMsg_io function. To jump from one step to another, you need to fill
the code mentioned in the first byte of the transmit buffer of the AuWriteReadMsg_io function.
Step Code Description

1 0x0E Initialization of parameters (Index, sub-index, object size).
2 0x0F Writing data buffer in the card (1).
3 0x10 Sending of the SDO object.
0x11 Cancel the data written in card buffer.
(1) : The data buffer must include the complete number of data defined in the first step (parameters
initialization). To write the data you could use multiple packets with a 255 bytes maximum size each. For
example, to write 5000 bytes in total, you have to write 19 packet of 255 bytes and one of 155 bytes
(19*255)+155=5000.
The size of the SDO object to write is controlled by the card.
In case of a bad request (bad initialization, not enough memory…), the function returns a status 4 error code.
Warning : if you want to use packet greater than 255 byte, you have to use the
AuSetApplicationMaxSize_io (1586, &dwStatus), which increase the maximum up to 1500 bytes.

Function prototype:
&dwStatus);

Initialization of parameters for writing SDO object
(board-1)*4 ).
- dwMsgParam : 32-bit word containing the SDO parameters to be written:
bit 31
bit 0
the index the index

- lpbyBufTx: pointer to the transmission buffer whose 1st byte contains the command
lpbyBufTx [0] = 0x0E Initialization parameters command to send SDO object.
lpbyBufTx [1..2] Size of the object to send.
the SDO write).
the SDO write).
Writing datas to transmit

(board-1)*4 ).
- dwMsgParam : 32-bit word meaningless for the write:
- wNbTx: number of bytes to transmit = 1 + size of packet (255 max).
lpbyBufTx [0] = 0x0F command to write datas in the card buffer.
lpbyBufTx [1..X] Data to write in SDO object.
- pwNbRx : pointer to the number of bytes received: meaningless for the write.

Transmit SDO object
(board-1)*4 ).
- wNbTx: number of bytes to transmit =1.
lpbyBufTx [0] = 0x10 command to transmit the SDO object.
Cancel datas written in card buffer

(board-1)*4 ).
- wNbTx: number of bytes to transmit =1.
lpbyBufTx [0] = 0x11 command to transmit the SDO object.
A sample explains the used of the AuWriteReadMsg_io function to write SDO object greater
than 255 bytes see directory « Development\MSVC\Sample LibApplicomIO\CANopen » in
applicomIO® installation directory.
This sample is based only on one C file : CANopenWideSdo.c

Reading current state of a CANopen equipment bytes with the AuWriteReadMsg_io
function.
The functionality used to read the current state of a CANopen equipment in the applicomIO® scanner is available in
the messaging mode library.

Function prototype:
&dwStatus);
(board-1)*4 ).
- dwMsgParam : 32-bit word meaningless for this use.
lpbyBufTx [0] = 0x0D Command to read the current stat of an equipment.
- pwNbRx : pointer to the number of bytes received: meaningless for this use
- lpbyBufRx: pointer to the reception buffer.
The possible values are :
5: OPERATIONAL.
4: PREPARED
127 : PREOPERATIONAL

Example of using the function AuWriteReadMsg_io.
The following example shows how to read an object using SDO, write an object using SDO and send an
®
NMT command to device number 6, from board number 1 of the applicomIO interface.
Remark: When including the "applicomio.h" file in a C++ project, you must put the include in extern "C"
(extern "C" { #include "applicomio.h" } )
example in ANSI Language C
#include "Applicomio.h" /* Prototype declaration file */

unsigned short wCard = 1; /* Board number */
unsigned short wEquip = 6; /* Device number */
unsigned short wNbTx ; /* Number of variables in transmission */
unsigned short wNbRx; /* Number of variables in reception */
unsigned long dwStatus; /* Status */
unsigned long dwMsgParam = 0; /* Parameters */
unsigned char byBufTx[10]; /* Transmission buffer */
unsigned char byBufRx[10]; /* Reception buffer */
unsigned short wIndex; /* Object index */
unsigned char bySubIndex; /* Object sub-index */
/* initialize applicomIO.dll library by "AuInitBus_io" */
/* Read object Index 0x1000 sub-index 0x00 (Device Type) using

SDO*/
wIndex=0x1000 ;
bySubIndex=0x00 ;
dwMsgParam = (bySubIndex << 16) | wIndex; /* Index and sub-index */
wNbTx=1; /* Nr command bytes */
byBufTx[0]=0x01; /* SDO read command */
wNbRx=10; /* Max. size of the reception buffer */
if (TRUE==AuWriteReadMsg_io(CARD2CHAN(wCard), wEquip, dwMsgParam ,
wNbTx, byBufTx, &wNbRx, byBufRx, &dwStatus ))
{
/*valid data wNbRx = number of bytes received, data in
byBufRx */
}
else
{
/* process error contained in dwStatus*/
}
/* Write object Index 0x100C sub-index 0x00

(GuardTime=0x1234=4600) using SDO*/
wIndex=0x100C ;
bySubIndex=0x00 ;
dwMsgParam = (bySubIndex << 16) | wIndex; /* Index and sub-index */
wNbTx=3; /* Nr command bytes + 2
bytes of guard time */
byBufTx[0]=0x02; /* SDO write command */
byBufTx[1]=0x34; /* Least significant of value
of guard time */
byBufTx[2]=0x12; /* Most significant of value
of guard time */

{
/* data written correctly */
}
else
{
}
/* Send an NMT command: « set operational mode » */

wNbTx=1; /* Nr command bytes */
byBufTx[0]=0x06; /* NMT command Set operational */
{
/* NMT command sent correctly */
}
else
{
}
/* execute the function "AuExitBus_io" before exiting */

A complete example is available in the "Development\MSVC\Sample LibApplicomIO\CANopen" directory
from the directory where applicomIO® was installed.
It includes:
- a C file CANopenAuWriteReadMsg.c,
- the H include file applicomIO.h,
- the lib file applicomIO.lib of the functions of the DLL applicomIO.dll,
- an executable file CANopenAuWriteReadMsg.exe, generated by a compiler from the previous files.
This example is used for reading and writing an object by SDO message, transmission of an NMT
command, transmission reception of a CAN frame, use of transmission/reception with the LMT service
and management of EMCY events.
The C file must be included in a work project or can be compiled on line, it requires access to the file
applicomIO.h and link editing with applicomIO.lib.

Management of IO commands
The management of IO commands creates a virtual device "0" with a size of 65 input bytes and 65
output bytes. These inputs outputs are refreshed by the functions IO_RefreshInput and
IO_RefreshOutput of the data access library.
For management of IO commands, you must be in expert mode and check the field "IO
1
Command" in the CANopen master properties ( ).
Representation of the input output area.
- 65 Output bytes: Command area
Byte 0 Byte 1 . . . . . Byte 64

Mast Cd Dev 1 RTR Dev 64 RTR
Byte 0: Master commands

Byte 1-64: TPDO commands in RTR mode of devices 1 to 64 (7bits RTR + 1 toggle bit).
The outputs will be refreshed by the data access library (function IO_RefreshOutput()).
The area of 65 output bytes represents the command area, it is divided into two parts:
 1 master command byte (MASTER CD).
Bits in the master command byte are set to control the following functions:
 Bit 0: transmission of a SYNC and RTR TPDOs set (if the SYNC period is zero).
 Bit 1: Transmission of a SYNC only (if the SYNC period is zero).
 Bit 2: Stop/resume nodeguarding.
 Bit 3: Reset RTR TPDO toggle bits.
 64 "RTR TPDO" command bytes of devices 1 to 64. A byte is allocated to each device.
This byte is used to control 7 RTR bits for TPDO1,TPDO2,….,TPDO7 defined in the
2
device configuration( ) and a toggle bit (switching alternately from 0 to 1).
- 65 Input bytes: Status area
Byte 0 Byte 1 . . . . . Byte 64

Mast Stat Dev 1 RTR Stat Dev 64 RTR Stat
Byte 0: Master status

Byte 1-64: TPDO status in RTR mode of devices 1 to 64 (7bits RTR + 1 toggle bit).
The inputs will be refreshed by the data access library (function IO_RefreshInput()).

The area of 65 input bytes represents the status area, it is divided into two parts:
 1 master status byte (MASTER STAT).
The value of the master status byte corresponds to the value of the master command byte
when processing is finished. This byte gives a request execution report.
Example: 0x02 is written in the master command byte, the board transmits a SYNC object
on the network. Once the SYNC object is transmitted, the board puts the report in the
master status byte 0x02.
 64 bytes of the status area give the transmission report of the RTR TPDO commands for
each device.
See also:
- in the knowledge base:
 (1) Expert mode for general configuration of the CANopen master.
 (2) Expert mode for configuration of PDOs.
Description of the Master command and master status byte
The master command byte is the first byte (byte 0) of the outputs from device 0.
The master status byte is the first byte (byte 0) of the inputs from device 0.
The MASTER COMMAND bits will be used as toggle bits (alternately 0 and 1) to trigger the
commands.
The MASTER STATUS will correspond to the value passed in the MASTER COMMAND after
acknowledgement of the command.
Commands available:
Bit 0: Transmission of a SYNC and RTR TPDOs set (if the SYNC period is zero).
Bit 1: Transmission of a SYNC only (if the SYNC period is zero).
Bit 2: Stop/resume nodeguarding.
Bit 3: Reset RTR TPDO toggle bits.
7 6 5 4 3 2 1 0
- - - - Reset Tg NdGrd SYNC SYNC+ RTR
Remark: The outputs and inputs of device 0 are accessible via the data access library.

Description of the RTR TPDO command area
A 64 byte area is dedicated to operation of the RTR TPDOs.

A byte represents a device i.e. a maximum of 64 devices and can be used to manage 7 TPDOs
plus 1 "toggle bit".
The "toggle bit" is used to validate the transmission of a new command. It must change status
each time a command is sent.
Between each command transmission, you must wait for the report in the Master STATUS area,
organized in the same way.
Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0

Toggle bit TPDO7 TPDO6 TPDO5 TPDO4 TPDO3 TPDO2 TPDO1
The toggle bit must be set alternately to „0‟ and ‟1‟ in order for the RTRs to be transmitted.
Example for device 1, transmission of TPDO2:
1. In the second output byte of device 0: write 0x82.

2. Wait until the second input byte of device 0 changes to 0x82 (report).
3. then write 0x02 in the output byte.
4. wait for 0x02 in the inputs.
9. ……….
Each time the toggle bit changes status, the RTR will be sent.
The RTR STATUS area seen in the application as INPUTs will be reset in the board as soon as
the RTR COMMAND byte is written and refreshed as the RTR PDO data arrives.
The application can read the device data when the toggle bit and the RTR bits in the inputs are
equal to the toggle bit and to the RTR bits written in the COMMAND.
Remark: The outputs and inputs of device 0 are accessible via the data access library.

Example of using IO commands in language C
The following example shows how to use the Command IO area with the data
access library.
Access this area on device 0.
Network configuration:
o A device 1 with a TPDO1 configured.
o A device 3 with a TPDO2 configured.
o Set the SYNC transmission period to 0 to disable it.
Example in ansi language C
unsigned char byBufferOut[65];

unsigned char byStatusRtr[65];
unsigned char byBufferIn[65];
unsigned char byToggleBit=0x80;
.
. Init
.
memset( byBufferOut, 0, 65);
byToggleBit ^= 0x80;
//Transmission of a SYNC
byBufferOut[0] = 0x02 ;
// Write RTR commands for device 1 TPDO1

byBufferOut[1]= byToggleBit | 0x01;
// Write RTR commands for device 3 TPDO2
byBufferOut[3]= byToggleBit | 0x02;
®
// Refresh data on the applicomIO board device 0
Equip = 0; Offset = 0; Nb = 4;
IO_WriteQByte (wCard, Equip,Offset, nb, byBufferOut, &Status );
IO_RefreshOutput (wCard, &Status );
.
.
. Processing
.

// Read RTR STATUSES
do
{
// Read data
IO_RefreshInput (wCard, &Status );
IO_ReadQByte (wCard, Equip, Offset, nb, byStatusRtr, &Status );
Ret = memcmp(byStatusRtr, byBufferOut,4)
}while(Ret != 0); /*while the arrays are different*/
// Read DATA devices 1 and 3

IO_ReadQByte (wCard, Equip,Offset, nb, &byBufferIn[0], &Status );
IO_ReadQByte (wCard, Equip,Offset, nb, &byBufferIn[1], &Status );
.
. Exit

Setting up a discussion between two devices in the network without the
intervention of the CANopen master
Description
CANopen allows several devices to share the same communication CAN ID.
®
By default however, the applicomIO CANopen master does not allow the same COB-ID to be
reused for several PDOs, in order to simplify the network implementation.
This functionality can be deactivated by authorizing the duplication of COB-Ids in the protocol
menu. This allows the same ID to be allocated to several PDOs and the transfer of data from device
to another.
Step by step implementation

 1 – Give the command "Protocol/Allow PDO ID duplication".
 2 - For the first device create a PDO to be shared (TPDO or RPDO).
 3 – Access the PDO properties by double clicking on the frame.
 4 – In the PDO COB-ID resource choose the number to be shared and select it by
double clicking on it.
 5 – Repeat the process for the other device(s), choosing the same PDO COB-ID.
Remark:
If you want read access for the PDO in the DPM of the applicomIO® CANopen master, check the
option "Map the data in the master" on a TPDO.
If you want write access for the PDO in the DPM of the applicomIO® CANopen master, check the
option "Map the data in the master" on an RPDO. In this case this PDO will be transmitted on the
network by the applicomIO® CANopen master.
If the option "Map the data in the master" is never checked on a PDO, this PDO will not be
available in the DPM of the applicomIO® CANopen master.

Emergency messages: EMCY
1
The EMCY messages are alarm frames generated by the devices in case of internal error, e.g. a
current or voltage fault (short circuit in input or output).
.
The complete description of EMCY messages is defined in standard "CiA DS 301"
The applicom master consumes the EMCYs generated by the devices and puts them in an EMCY
queue. This queue can be read by:
2
 Sending a messaging command => AuWriteReadMsg_io .
3
 Reading an OPC item .
See also:
 In the knowledge base:
 2 : Reading / writing objects with SDO messaging and sending NMT commands
 3 : Use of CANopen Emergency Messages under OPC

Description of expert mode in the configurator
This chapter documents all accessible parameters only if expert mode is validated.
To validate expert mode in the configurator, select in the menu
 File/Preferences/Expert Mode
Expert mode for general configuration of the CANopen master.
 Time-out for the SDOs:

Used to set a time in ms to manage the time-out between transmission and reception of SDOs,
(device response time).
The default value is 200 ms.
 Wait time on start-up:
Used to set a wait time (10 ms steps) after a general RESET on all devices in the CANopen
network.
 IO command
Used to simulate the device "0" IO command to:
- Send a SYNC and RTR TPDOs.

- Send a SYNC only.
- Stop/resume nodeguarding.
- Reset the RTR TPDO toggle bits.
- Send RTR TPDOs.
Also used to access the RTR transmission types in the TPDO properties:
 Asynchronous Remote (Async RTR).
 Synchronous Remote (Sync RTR).

Expert mode for device configuration.
 PDO V4.01 Compatibility

According to specification DS-301 version 4.01 or greater
- Used to manage bit 31(PDO exists or does not exist) of the PDO COB-ID in the
communication parameters of the object dictionary.
- Used to manage the reset of the number of object mapped before to write values.
 Respect the EDS for object accesses
Used to take account of the access rights (read only, read write) on the objects in the object
dictionary which are specified in the device EDS.
 Atomic SDO writing.
Used to respect SDO writing order.

Expert mode for configuration of PDOs.
 Synchronous Remote (Sync RTR):

Used to set synchronous RTR transmission mode for a TPDO.
The device will only produce its PDO after receiving an "RTR" frame.
The data will only be updated on reception of the SYNC object.
SYNC can be transmitted cyclically or manually 1.
 Asynchronous Remote (Async RTR):

Used to set asynchronous RTR transmission mode for a TPDO.
The device will only produce its PDO and update the data after receiving an "RTR" frame.
 Save in FIFO:
2
This option is used to save in a FIFO all TPDOs consumed.
Remark: So that the Synchronous Remote and Asynchronous Remote transmission types are
"
accessible the "IO Command option must be checked in the general configuration of the CANopen
master.
See also:
- in the knowledge base:
 (1) Management of IO commands

 (2) Reading the PDO FIFO with the function AuWriteReadMsg_io.

4. DeviceNet
Description of a DeviceNet EDS File

Using the EDS File
An "EDS" file is supplied with the device by the manufacturer. It is a necessary configuration
®
support for the applicomIO console. It characterizes the device by defining the types of
connections to be managed as well as the size of associated input/output and the list of possible
parameters specific to the DeviceNet.
It is recommended that you obtain a recent version of the EDS file, either directly from the
manufacturer of the DeviceNet equipment or from the ODVA http://www.odva.org .
When the device is supplied without the EDS file, the applicomIO® console can, upon user request,
generate a minimum file from information originating from the device installed on the network. This
EDS file will then be automatically inserted in the equipment library.
The EDS files contained in the equipment library are analyzed during selection of the DeviceNet
protocol in the console. When available, the various sections of the file are used as follows:
[File] : designates the characteristics of the EDS file in the "EDS Information" tab.
[Device] : contains the device-specific characteristics in the "EDS Information" tab.
[IO_Info] : designates the types of connections available in the "Connection Configuration" tab.
[Params] : defines the available parameters in the "Parameters" and "On-line Parameters" tabs.
[EnumPar] : defines the lists of values for certain parameters.
[Groups] : groups the parameters by family in the "Parameters" and "On-line Parameters" tabs.
When the file cannot be properly analyzed, an error message is displayed in the "message
window". In such a case, the file cannot be used.
applicomIO® Knowledge base Implementation DeviceNet  121

Error Messages during EDS File Analysis
 ERROR: "StrobeInfo" absent
The "StrobeInfo" input is missing or the "Default" value is incorrect.
 ERROR: "PollInfo" absent
The "PollInfo" input is missing or the "Default" value is incorrect.
 ERROR: "CyclicInfo" absent
The "CyclicInfo" input is missing or the "Default" value is incorrect.
 ERROR: "COSInfo" absent
The "COSInfo" input is missing or the "Default" value is incorrect.
 ERROR: "InputX" absent
The "InputX" input referenced by "StrobeInfo, PollInfo, CyclicInfo or COSInfo" is missing.
 ERROR: "OutputX" absent
The "OutputX" input referenced by "StrobeInfo, PollInfo, CyclicInfo or COSInfo" is missing.
 ERROR: ParamX appears twice in the EDS file
Each ParamX in the file must be unique.
 ERROR: ParamX: The data type (=27) must be in the range [1..26]
The "DataType" input must be between 1 and 26.
 ERROR: ParamX: The default value (=4) is not between the Min value (=5) and the
Max value (=10).
The "Default Value" must be between the "Min Value" and the "Max Value".
 ERROR: Parameter21: The Min value (=30) is greater than the Max value (=29).
The "Default Value" must be between the "Min Value" and the "Max Value".
 CAUTION: The [ParamX] instance referenced in [GroupX] cannot be found
From GroupX, test for the presence of referenced ParamX values in the list for each group.
 CAUTION: MaxInst=X is less than number of parameters (Y)
The number of ParamX values found in the EDS is compared with the value in "MaxInst".
 CAUTION: ParamX, "LinkPath Size" does not correspond to the length of "LinkPath"
The "LinkPathSize" value for each ParamX is compared with the number of characters in
the "LinkPath" string.
 CAUTION: ParamX Type is not supported : "DataType Dec" ("DataType Hex")
The ParamX parameter use a type (DataType) that is not supported by the console.
Transmission and reception on the DeviceNet network are not supported. String types
(STRING, STRING2, STRINGN and SHORT_STRING) are only displayed.

Generating a DeviceNet EDS File
After network detection and upon insertion of the device in the configuration, if no other EDS file
corresponding to the device is found in the EDS library, the applicomIO console can generate an
EDS file for the device.
Click on the button "Create new EDS file".
A file name and a description of the device will be proposed automatically.

In the generated EDS file, all the sections ([FILE], [DEVICE], [IO_Info], [Params], [EnumPar] and
[Groups]) are filled in with information for the device.
The [Params] section is generated by interrogating the "Parameters" object of the device.
Depending on the attributes of this object (Full or Stub), this section will be more or less complete.

Equipment Detection Method
Equipment detection is done on all possible MAC IDs by interrogating the following attributes with
the 0x0E service (Get_Attribute_Single) :
Object Instance Attribute

1 : Identity 1 1 : Vendor ID Manufacturer identification
1 : Identity 1 2 : Device Type Device profile identification
1 : Identity 1 3 : Product Code Product identification
1 : Identity 1 4 : Revision Version of device
1 : Identity 1 5 : Status Device status
1 : Identity 1 6 : Serial Number Serial number of the device
1 : Identity 1 7 : Name Device name
5 : Connection 2 : Polling 7 : Produced connection Input size for "Polling"-type connection
Size
5 : Connection 2 : Polling 8 : Consumed Output size for "Polling"-type connection
connection Size
5 : Connection 3 : Strobe 7 : Produced connection Input size for "Strobe"-type connection
Size
5 : Connection 4 : COS 7 : Produced connection Input size for "Polling"-type connection
Size
5 : Connection 5 : Cyclic 7 : Produced connection Input size for "Polling"-type connection
Size
Note: For COS and Cyclic connections, output sizes are determined by the output size for the
"Polling" connection.
The result of these requests can be viewed in "Equipment Information" in equipment properties of
the "Network Detection" tab.

This information can be used to find the EDS file for the device in the equipment library or to
generate a file.

Solving DeviceNet Network Problems
Checking your Hardware Installation
CAN Bus
The CAN bus constitutes ISO layers 1 and 2 of DeviceNet and enables a very high level of auto-
verification of the integrity of transported data. All errors detected by one of the items are sent to the
others by error frame and penalty mechanisms of varying degrees of severity, up to and including
the exclusion of the defective device (Bus Off).
These high-performance mechanisms can, during implementation of your network, completely
crash the network after only a few milliseconds of operation, making it very difficult to detect
hardware defects.
The use of specially adapted cables for the transport of CAN signals (line impedance, specific
capacitance), the most linear network architecture possible (even though other topologies are
theoretically still possible) and good-quality connectors ensure effective implementation and
maintenance.
The CAN network consists of a differential pair, which has a "polarity", as shown by the "CAN high"
and "CAN low" lines; under no circumstances should these be crossed.

Topology
DeviceNet is based on a "bus"-type topology. An impedance adaptation resistor (RT) must be

placed at each end of the trunk line. RT = 121 ohm, ¼ Watt
 Cable
 Thick cable: Cable consisted of two twisted and shielded pairs with a wire at the center,
covered by a shielding braid. It is normally used for the trunk line. Supports up to 8A.
Ref.: BELDEN® 3082A (PVC) - 3083A (CPE)
 Thin cable: Thinner and more flexible than the thick cable. It is normally used for the
drop lines. Supports up to 3A.
 Baud Rate
 125 kbit/s
 250 kbit/s
 500 kbit/s

Baud Rate Total Length of Total Length (Trunk Line + Drop Lines)
Drop Lines
125 kbit/s 156 m LThick + 5 x LThin = 500 500 m 100 m
where LThick: 100 % thick cable
LThin : Length of thin cable
The twisted power supply pair must be connected to an external power source at +24V.
Troubleshooting
Synchronization Error with the Bus:
 No healthy devices are present on the network!
®
 The applicomIO board is not connected to the DeviceNet network or there is no +24V on
the network (the "Power Error" counter in the "Network" tab is incrementing).
 The applicomIO® master does not have the same Baud Rate as the other devices in the
network (the "Error" or "Bus Off" counter is not equal to zero, or the "WARNING LEVEL"
is reached).
 The DeviceNet network is not properly cabled (the "Error" or "Bus Off" counter is not equal
to zero, or the "WARNING LEVEL" is reached).
MAC ID Duplication Detected:

 The DeviceNet master is configured with a MAC ID already being used by another network
device (Network-Module LED is red, status 70). Reinitialize the applicomIO® board with a
different MAC ID.
Profile Incompatible:
 The device does not correspond to the configuration. The identity check has failed. Check
your configuration ("applicomIO® Description" tab).
 The device does not correspond to the configuration. The connection sizes are different.
Check your configuration ("Connection Configuration" tab).

On-line Actions for the DeviceNet Network
®
On-line actions (explicit message transmission, counter reading) are gathered in the applicomIO
DeviceNet console on two screens:
- DeviceNet on-line action: "Network" tab
- DeviceNet on-line action: "Explicit Message" tab
"Network" Tab
®
This tab indicates the connection status of the applicomIO board on the DeviceNet network.
LED
» Module/NetWork LED
LED indicating the channel status.
: OK.
: Scanner not active
: The channel is not "on line": MAC ID duplication check in progress or No power supply.
: Channel error: Bus Off. or MAC ID duplication detected.
®
: Network error. See applicomIO Status.

» Network/Station
Status of the Network Manager:
: Communication problem with at least one of the devices configured (device missing,
configuration error, problem on the device, etc.).
: No communication problem, all configured devices are present and running.
CAN
» Rx
Total number of bytes received.
» Tx
Total number of bytes sent.
» Rx Frames/s
Number of frames received per second.
» Tx Frames/s
Number of frames transmitted per second.
» OverRun
Reception buffer overrun counter. It displays the minimum number of frames lost.
» Errors
CAN error counter for transmission or reception. It displays the number of times when at least one
of the transmission or reception error counters of the CAN controller has reached or exceeded the
threshold of 96.
» Bus Off
CAN controller Bus Off status counter. It displays the number of times that the transmission error
counter has reached the value 255.
» Baud Rate
Transmission speed configured in the DeviceNet master.
» Reset Counters
Resets counters to zero: Rx and Tx, Rx Frames/s and Tx Frames/s counters, OverRun counter,
Error counter, BusOff counter and network load.
DeviceNet
» MAC ID
Address configured in the DeviceNet master.
» Status
DeviceNet Master status (See applicomIO® Status).
» Power Error
Counter detecting +24V power errors on the DeviceNet master channel.
» Reset counter
Resets the Power Error counter.

"Explicit Message" Tab
This tab enables the transmission of "Explicit Messages" on the DeviceNet network.
Address
» MAC ID
Address of the targeted device on the network. The address values range from 0 to 63.
» Class
DeviceNet object identifier. The address values range from 0 to 65535.
» Instance
DeviceNet object instance. The address values range from 0 to 65535.
» Attribute
Attribute of the DeviceNet object instance. If the attribute must be included in the message, the
value must range from 0 to 255. Otherwise, leave this field empty.

Service
» Number
Service identifier. A service name is associated with each number. To enter a customized service
number, select "Customer Service".
» Name
Explicit name of the service. A service number is associated with each name. Use "Customer
Service" to enter a customized service number.
Data
» Data
Used to enter data to be sent to the device. The "..." button is used to set the various test
parameters. It enables the user to format the data.
Reception
» Reception
Displays the data returned by the device in response to a request.
Command
» Send to Device
Transmits the explicit message defined by the service, the address and the data.
Communication Report
Displays the report of a read or write parameters operation:
: The operation took place correctly.
: Messaging error. Communication with the device took place correctly but the device
returned an error message.
: Communication error. Impossible to communicate with the device.

'Node Commissioning' Tab
This tab enables you to modify, via the DeviceNet network, the Baud Rate and the MAC ID of the
devices supporting this functionality.
New Values
» MAC ID
New MAC ID to be applied to the device.
» Baud Rate
New Baud Rate to be applied to the device.
Receive
: Messaging error. Communication with the device took place correctly but the device
: Communication error. Impossible to communicate with the device.

Remarks:
The "Apply MAC ID" command sends the following "explicit message" to the DeviceNet device:
 Object: 3 – "DeviceNet"
 Instance: 1
 Attribute: 1 – "MAC ID"
 Service: 10hex - Set_Attribute_Single
 Data: 0-63 [New MAC ID]
The "Apply Baud Rate" command sends the following "explicit message" to the DeviceNet
device:
 Object: 3 – "DeviceNet"
 Instance: 1
 Attribute: 2 – "Baud Rate"
 Service: 10hex - Set_Attribute_Single
 Data: 0 [125 kBit/s], 1 [250 kBit/s], 2 [500 kBit/s].

DeviceNet Connection Types
Four connection types enable input/output data exchange between the DeviceNet master and the
devices:
 Strobe
 Polling
 Change Of State
 Cyclic
The connection types can be used with a device as a function of the device's characteristics. For
example, if a device supports only a "Strobe" connection, it will refuse a "Polling" or "Cyclic"
connection.
'Strobe'-type Connection
"Strobe"-type messages enable rapid exchange of small quantities of input/output data between the
DeviceNet master and the devices.
In a single frame, the master transmits an output bit for each device configured with a "Strobe"-type
connection. The bit intended for the device is located in the frame at the position of the device's
MAC ID value.
The device receiving this bit can do one of the following:

 ignore it.
 consider it to be an output value.
 consider it to be a "trigger".
The device can respond to the DeviceNet master with up to 8 bytes of input and/or status
information data.

'Polling'-type Connection
"Polling"-type messages enable exchange of any amount of input/output data between the
DeviceNet master and the devices.
For each device configured with a 'Polling'-type connection, the master sends a frame containing
the output data.
The device responds with a frame containing the input and/or status information.
The sizes of these frames depend on the configured values in the "Polling"-type connection.

'Cyclic'-type Connection
"Cyclic"-type messages enable exchange of input/output data at a set period. This period is defined
by the "Send Rate" value.
The acknowledgement frames can be deleted by unticking the "Ack" box in the "Expert Mode"
dialog box.

'Change Of State'-type Connection
"Change of State"-type messages (or "COS") optimize the network load by reducing the number of
input/output data exchanges. These data are transmitted only upon change of state. However, to
ensure proper device operation, an exchange is made after each Heartbeat interval.
Some types of devices (such as analog devices) require input transmission to be slowed down. To
do this, increase the "Inhibit Timer" value in the "Expert Mode" dialog box.
The acknowledgement frames can be deleted by unticking the "Ack" box in the "Expert Mode"
dialog box.
The sizes of these frames depend on the configured values in the "Change of State"-type
connection.

DeviceNet Master Cycle
A DeviceNet master cycle consists of three phases.
 Phase 1 at the start of the cycle: Transmission of the Strobe message and reception of
device feedback.
 Phase 2: For each "polling"-type connection, transmission and reception of "Polling"-type
messages.
 Phase 3: Management of "Change of State" and "Cyclic"-type messages.
For all phases to be executed, all connection types must be configured.
The time between two DeviceNet master cycles is called: "Interscan Delay". Explicit messages can
be sent during this period. By default, this value is set at 2 ms. The "General Configuration of the
DeviceNet Master" tab can be used to modify it.
The granularity of the time is 2 ms.
In this example, the cycle time is 4 ms with an "Interscan Delay" configured at 2 ms.

Input/Output Organization of DeviceNet Equipment
®
applicomIO automatically organizes its DP Ram, device input/output and the local slave as a
function of the configured connections.
Thus, the variables of a device in applicomIO® are composed successively of variables for
"Strobe", "Polling" and "Change of State/Cyclic" connections.
The granularity of the variables is one byte; therefore, the size of the output variables of the
"Strobe" connection ("Strobe" bit) will be one byte.
This organization can be viewed with the "Input/Output Summary" tab in the DeviceNet master
properties.
Example:
For this device, "Strobe", "Polling" and "Cyclic"-type connections are configured as below:

The sizes and positions of the input/output data can be viewed in the "Input/Output Summary"
tab:
The output bit of the "Strobe" message is the first bit of the first byte of the output variables of the
device in applicomIO.

Checking the Identity of a DeviceNet Device
Checking the identity ensures that the master is properly connected to the expected device. The
®
criteria selected are verified during the connection phases to the applicomIO master.
The master interrogates the device for its identity via explicit messaging. The following attributes of
the "Identity" object are thus verified by the 0x0E service (Get_Attribute_Single):
Attribute ID Name
1 Vendor ID
2 Device Type
3 Product Code
4 Revision
If one of these attributes do not corresponds, a 79 status is attributed to the device.

DeviceNet Objects
General Presentation
DeviceNet is based on object modeling. Objects describe the characteristics of a device and the
manner in which it manages communication.
Object Function
Connection Manages input/output connections and explicit messages.
Message Router Routes explicit messages to the target objects.
Identity Provides general information on the identity of the device.
DeviceNet Manages the configuration and status of the physical connection to the
DeviceNet network.
Assembly Groups together the attributes of several objects in a single data block, which
can be sent and received via a single connection.
Parameter Manages the configuration parameters of the device.
Application Device Manufacturer-specific objects.

Addressing an Object
An object is addressed with the following parameters:

a. MAC ID: the address of the Participant.
b. Class: class identification for the object.
c. Instance: instance identification for the object.
d. Attribute: attribute identification.
e. Service: service code identification.

Remark: The instance 0 enables direct addressing of the object class.
Example: Reading the device name of MAC ID 10:

 MAC ID: 10
 Class: 1 (Object Identity)
 Instance: 1
 Attribute: 7 (Product Name)
 Service: 14 (Get Attributes Single)
Sending an Explicit Message

With the DLL (applicomIO.dll):
Use the AuWriteReadMsg function.
®
With the applicomIO console:
Explicit messages are sent via the "Explicit Message" tab in "On-line Actions". To access
this tab, select a node in the "Network Detection" tree; the "On-line Actions" can then be
accessed with the button or with the "Network/On-line Actions..." command in the main
menu.

'Flex I/O' Configuration for the DeviceNet Network
Flex I/O Device
The Flex I/O device consists of a station head (reference 1794-ADN) and 1 to 8 modules.
This device is configured by means of the "Module Configuration" tab in device properties
(Configuration area):
This tab describes the composition of the Flex I/O device.

» Module Configuration List
List of "Flex I/O" modules.
 "Module" column: Position of the module with respect to the "Flex I/O" branch interface.
 "Reference" column: Catalogue number of the module.
 "Name" column: Module name.
 "Inputs" column: Size of the module inputs in Bytes.
 "Outputs" column: Size of the module outputs in Bytes.
Module 0 is the "branch interface" of the "Flex I/O".
Double click on a module to configure it.

» Total Size
Indicates the size of the "Flex I/O" inputs/outputs with these configured modules.
» Communication Report
Messaging error. Communication with the device took place correctly but the device
Communication error. Impossible to communicate with the device.

Commands
» Add
Used to add a module at the current position in the "Module configuration" list.
» Delete
Deletes the module selected in the "Module configuration" list.
» Up
Moves the selected module one rank towards the branch interface.
» Down
Moves the selected module one rank away from the branch interface.
» Read in the Flex I/O
Used to read all parameters of the "Flex I/O" and replace them in the module configuration.
» Write in the Flex I/O
Used to write the configuration of all modules in the "Flex I/O".
®
When you exit this tab, the applicomIO console proposes to replace the input/output sizes for the
connections with those for the modules.

Configuration of the Flex I/O Device
®
If the applicomIO console is in "initialized" mode and the device is on the DeviceNet network, an
"on-line" configuration is possible.
"On-line" Configuration
 Use the "Reading in the Flex I/O" command to read its composition from the device as
well as the parameter values of the modules. Refer to the chapters that follow for
parameter configuration.
Note: The Flex I/O saves its configuration to memory. During a change in module, it is
preferable to reinitialize the headend by means of the "Memory Clean-up" command,
which will force the device to detect its modules.
 Use the "Writing to the Flex I/O" command to write the parameter values in the device.
Caution: When it is exchanging input/output with a master, the Flex I/O device does not
authorize modification of its configuration. The following message will appear:
In this case, deactivate the Flex I/O device of the configuration and then reinitialize the
applicomIO® board with the PcInitIO command. Reactivate the Flex I/O device in your
configuration. You can now write in the Flex I/O device.
"Off-line" Configuration
Add your modules one by one with the "Add" command.
Select the module to add (double click on the module to view its parameters).
Caution: Any modifications will be taken into account by device only after the "Writing in the Flex
I/O" command has been used.

Configuration of the Headend
Double click on the row representing the headend of the Flex I/O device (Module 0) in the "Module
Configuration" tab.
This tab enables you to configure the transition states of the headend. Double click on a parameter
to modify its value.
For more information, refer to the Allen-Bradley documentation.
®
If the applicomIO console is in "initialized" mode, the following mode is available.
» Memory Clean-up
This command forces the Flex I/O device to reinitialize with its default values.

Module Configuration
Double click on the line representing a module of the Flex I/O device in the "Module
Configuration" tab.
This tab describes the input/output sizes and the configuration of module parameters.
» Configuring the Input/Output Sizes of a "Flex I/O" Module
Gives the sizes in words (16 bits) of the module inputs/outputs.
When the module is present in the "Flex I/O" configuration, you can modify the sizes by double
clicking or by pressing the space bar.
» Sizes for I/O Only
Resets "Input Size" and "Output Size" to their default values. They are then optimized for the
inputs / outputs.
Note: The "Input Size" and "Output Size" directly affect access to the parameters (Read Only or
Read-Write). If a parameter is " ", a symbol representing a key will appear next to it.
Double click on a parameter to modify its value.
For more information about the module parameters, refer to the Allen-Bradley documentation.

Input Sharing Functionality with Another DeviceNet Master
Characteristics of a Device Sharing its Input with Several DeviceNet Masters
®
In expert mode, the applicomIO console can be used to configure a device as not being directly
managed by the DeviceNet master. When configured in this way, the device only allows the master
to consult its input values. Thus, output writing is forbidden, since the device is managed by another
master. For this reason, the output sizes in the "Connection Configuration" tab cannot be
modified, as shown below:
To do this, tick the "Device managed by another master" box in the "General Configuration" tab
(accessible in expert mode only).
When a device shares its inputs with another master, it is symbolized by the icon: if the device
is active, and by the icon: if the device is deactivated.
Communication is assured via the other master, which is in direct communication with this device.
This operation is transparent for the user.

Use of Explicit Messaging
Description
The functionality enabling explicit messaging with a configured device is accessible via the
functions library of the DLL.
Use with the AuWriteReadMsg_io Function of applicomio.dll

The "AuWriteReadMsg_io" function enables use of explicit messaging specific to DeviceNet. It
requires 8 parameters:
Explicit Messaging
(board-1)*4 ).
- wEquip: 16-bit word indicating the number of the targeted applicomIO® device (0 to 127).
- dwMsgParam: ignored.
- wNbTx: Number of bytes to transmit to the lpbyBufTx buffer.
- lpbyBufTx: pointer on the transmission buffer. The bytes are distributed as follows:
[0] : DeviceNet Service .
[1] : Object class. (Least significant byte)
[2] : Object class. (Most significant byte)
[3] : Object instance. (Least significant byte)
[4] : Object instance. (Most significant byte)
[5] : Object attribute. (optional)
[6]-[…] : Data of the message to be sent. (optional)
Up to 256 bytes of data can be placed in the buffer for the message to be sent.
- pwNbRx: pointer on the number of bytes received: indicates the number of bytes
received if the variable pointed by pdwStatus is not zero.
* Call up: indicates the maximum size of the reception buffer.

* Return: indicates the number of bytes received if dwStatus=0.
- lpbyBufRx: pointer on the reception buffer. The bytes are distributed as follows:
[0] : DeviceNet Service + 0x80. If the return message is an error, this byte
contains 0x94.
[1]-[…] : Data returned.
Up to 256 bytes of data can be placed in the buffer for the message to be
received.
- pdwStatus: pointer on the 32-bit applicomIO® error status.1

Example in ANSI Language C
Reading of Class 1 (Identity), Instance 1, Attribute 1 (VendorID) of applicom device no. 5 from board 1 of
the applicomIO® interface.
Remark: When including the "applicomio.h" file in a C++ project, you must include it in extern "C"
(extern "C" { #include « applicomio.h » } )
#include "applicomio.h" /* Prototype declaration file */
unsigned short wCardNumber = 1; /* Board number */

unsigned short wNes = 5; /* applicom number for the device */
unsigned long dwMsgParam; /* Ignored */
unsigned short wClass = 0x01; /* Object Identity */
unsigned short wInstance = 0x01; /* Instance 1 */
unsigned char byAttribut = 0x01; /* Attribute 1 (VendorID) */
unsigned long dwStatus; /* Return code of AuWriteReadMsg_io() */
unsigned char byTxBuf[256]; /* Data to transmit to the
device */
unsigned char byRxBuf[256]; /* Data received by the device
*/
unsigned short wNbTx = 0; /* Number of bytes to transmit to the device
*/
/* Max. size of reception buffer */
unsigned short wNbRx = sizeof(byRxBuf);
/* Creation of message to transmit to the device */

byTxBuf[wNbTx++] = 0x0E; /* Service : Get_Attribute_Single */
memcpy(&byTxBuf[wNbTx++], &wClass, 2); /* Object Identity */
wNbTx++;
memcpy(&byTxBuf[wNbTx++], &wInstance, 2); /* Instance 1 */
wNbTx++;
byTxBuf[wNbTx++] = byAttribut; /* Attribute 1 (VendorID) */
memcpy(&byTxBuf[wNbTx], 0, wNbTx); /* No data to send here */
/* initialize applicomIO.dll library by "AuInitBus_io" */
/* Transmission of the DeviceNet message */
AuWriteReadMsg_io(CARD2CHAN(wCardNumber), /* Channel number */

wNes, /* applicom number */
dwMsgParam, /* Ignored */
wNbTx, /* Number of bytes to transmit */
byTxBuf, /* Buffer to transmit */
&wNbRx, /* Number of bytes received */
byRxBuf, /* Received buffer */
&dwStatus); /* Communication result */
if (dwStatus == 0)
{
if (byRxBuf[0] == (byTxBuf[0] | 0x80))
{
/* No error message */
/* Response of device to the request */
}
else
{
/* Error message returned by device */
/* byRxBuf[0] == contains 0x94 */
}
}
else

{
/* Error returned by applicom */
}
/* execute the function "AuExitBus_io" before exiting */
A complete example is available in the "Development\MSVC\Sample LibApplicomIO\DeviceNet" sub-

directory within the directory in which applicomIO® was installed.
It includes:
 a C file AuWriteReadMsgDNet.c
 an executable file AuWriteReadMsgDNet.exe
This example transmits explicit messages to a configured device.
This file can be integrated into a work project or it can be compiled on line; it requires access to the
applicomIO.h file and an edition of links with applicomIO.lib.
See also:
In the documentation :
i. Status applicomIO

5. EtherNet/IP
EtherNet/IP Compliance
Identity Object, Class 0x01
The following attribute and service requirements for the Identity Object are supported. There is only
one instance of this object.
Class Attributes
Id Description Get Set Limits

01h Revision   1
02h Max Instance   1
 Supported  Not supported
Class Services
Id Service Param. Options

01h Get_Attributes_All
0Eh Get_Attribute_Single
Instance Attributes

01h Vendor Id   0x243
02h Device Type   0x0C
03h Product Code   0x02
04h Revision   0x0202 (*)
05h Status  
06h Serial Number  
07h Product Name   applicomIO EtherNet/IP Scanner
(*) in relation with the current firmware version.
Instance Services

05h Reset

Message Router Object, Class 0x02
The following attribute and service requirements for the Message Router Object are supported.
There is only one instance of this object. No attributes and services are supported.
Class Attributes

1 Revision  
4 Optional Attribute List  
5 Optional Service List  
6 Max ID of class attributes  
7 Max ID of instance attributes  
 Supported  Not Supported
Class Services
Service Param. Options

Get_Attributes_All 
Get_Attribute_Single 
Instance Attributes

1 Object List  
2 Maximum connections supported  
3 Number of active connections  
4 Active connections list  
Instance Services

Get_Attributes_All 
applicomIO® Knowledge base Implementation EtherNet/IP  157

Assembly Object, Class 0x04
The following attribute and service requirements for the Assembly Object are supported.
The instance corresponding to the assembly number of the Local Slave configured into the
applicomIO console.
Class Attributes

1 Revision  
Class Services

Instance Attributes

03h Data  
Instance Services

10h Set_Attribute_Single

Connection Manager Object, Class 0x06
The following attribute and service requirements for the Connection Manager Object are supported.
Class Attributes

01h Revision   1
02h Max Instance   1
Class Services

Instance Attributes

01h Open Requests  
02h Open Format Rejects  
03h Open Resource Rejects  
04h Open Other Rejects  
05h Close Requests  
06h Close Format Requests  
07h Close Other Requests  
08h Connection Timeouts  
09h Connection Entry List   00 00 00 00 00 00
0Bh CPU Utilization   00 00
0Ch Max Buffer Size   00 00 00 00
0Dh Buffer Size Remaining   00 00 00 00

TCP/IP Interface Object, Class 0xF5
The following attribute and service requirements for the TCP/IP Object are supported. There is only
one instance of this object.
Class Attributes

Class Services

Instance Attributes

01h Status  
02h Configuration Capability  
03h Configuration Control  
04h Physical Link   20h F6h 24h 01h
05h Interface Configuration  
06h Host Name  
Instance Services


EtherNet Link Object, Class 0xF6
The following attribute and service requirements for the EtherNet Link Object are supported.
Class Attributes

Class Services

Instance Attributes

01h Interface Speed  
02h Interface Flags  
03h Physical Address  
04h Interface Counters  
05h Media Counters  
06h Interface Control  
Instance Services


On-line actions on the EtherNet/IP network
'Explicit Message' Tab
This tab is used to send "Explicit Messages" on the EtherNet/IP network.

Address
IP address
IP address of the target device on the network.
Class
CIP object identifier. This value must be between 0 and 65535.
Instance
Instance of CIP object. This value must be between 0 and 65535.
Attribute
Attribute of the CIP object instance. If the attribute must be placed in the message, the value must
be between 0 and 255. Otherwise leave this field blank.
Service
Number
Service identifier. A service name is associated with each number. To enter a personalized service
number, select the service name: "Customer Service".
Name
Explicit name of the service. A service number is associated with each name. The service name
"Customer service" is used to enter a personalized service number.
Data
Data
The data to be sent to the device.
The "…" button is used to set various control parameters. It allows data to be put into the desired
format.
Reception
Reception
Displays the data sent back by the device in response to a query.
The "…" button is used to set various control parameters. It allows data to be put into the desired
format.
Messaging
Connected
Unconnected

„Port configuration‟ tab
This tab is used to read and write device port parameters. To be active, a device shall
be selected.
These buttons can only be used if the board has been initialized.
 Read the values from the device
Reads the values from the adapter.
 Write values to the device
Writes values to the adapter.
In particular, you can change the adapter's IP address. To do this, the Link the
parameters checkbox must be unchecked to be able to enter the IP address in the
New IP address parameter.

Organization of inputs/outputs to EtherNet/IP devices
®
applicomIO organizes the inputs/outputs to devices and the local slave automatically in its DP
Ram depending on the connections configured.
EtherNet/IP Device
® st
Device variables in a device in applicomIO are made up in succession of variables for its 1
nd
connection then variables for its 2 connection if configured.
Default Items:
If the inputs/outputs datas are described in the EDS file, the console creates default items in
accordance with information from the EDS.
This items are available in OPC server.

Connections: “Rack Optimization”
In the case of modules using « Rack Optimization » connections, datas are grouped together on the
remote bus branch so all digital data are exchanged through a single connection.
1734-AENT PointIO
input:
Byte Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Byte 8 Byte 9 …
0
Status bits Data Data Data Data Data Data ….
Slot 1 Slot 2 Slot 3 Slot 4 Slot 4 Slot 5
 Status bit
Each bit status corresponds to slot in rack optimization.
Ex Bit 0 = Slot 1, Bit 1 = Slot 2,…
Bit value:
1 = Bad value.
0 = value OK.
 Data Slot n:
The byte 4 contains the data of the slot 1, if this slot is in Rack Optimization.
…
Output:
0
8 bytes reserved Data Data ….
Slot 1 Slot 2
 8 bytes reserved:
 Data Slot n:
…

1794-AENT FLEX I/O
Input:
0
Status bits Data Slot 1 Data Slot 2 Data Slot 3 ….
 Status bit
Each bit status corresponds to slot in rack optimization.
Ex Bit 0 = Slot 1, Bit 1 = Slot 2,…
Bit value:
1 = Bad value.
0 = value OK.
 Data Slot n:
The byte 4 and 5 contains the data of the slot 1, if this slot is in Rack Optimization.
The byte 6 and 7 contains the data of the slot 2, if this slot is in Rack Optimization.
Output:
Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 …

Data Slot 1 Data Slot 2 Data Slot 3 ….
 Data Slot n:
The byte 0 et 1 contains the data of the slot 1, if this slot is in Rack Optimization.
The byte 2 et 3 contains the data of the slot 2, if this slot is in Rack Optimization.
…
Local slave
®
The input variables to the local slave in applicomIO are made up in succession of configuration
data from the connection then its input data.

CIP objects
General introduction
CIP is based on object modeling. The objects describe the characteristics of a device and the way it
manages communication.
Object Function
Connection Manages input/output and explicit message connections.
Message Router Routes explicit messages to target objects.
Identity Provides general information on the identity of the device.
DeviceNet Manages the configuration and status of the physical connection to the
DeviceNet network.
Assembly Groups the attributes of several objects in one data block which can be sent and
received via a single connection.
Parameter Manages the configuration parameters for the device.
Application Objects specific to the manufacturer of the device.

Object addressing
An object is addressed with the following parameters:

a. MAC ID: the address of the Participant for the DeviceNet network or the IP address for
the EtherNet/IP.
b. Class: Object class identifier.
c. Instance: Object instance identifier.
d. Attribute: Attribute identifier.
e. Service: Service code identifier.
Note: Instance 0 enables the object class to be addresses directly.

Example: Reading the name of the device at address 128.127.56.161:
 IP address: 128.127.56.161
 Class: 1 (Identity Object)
 Instance: 1
 Attribute: 7 (Product Name)
 Service: 14 (Get Attributes Single)
Send explicit message

 With the DLL (applicomIO.dll):
By using function AuWriteReadMsg.
®
 With the applicomIO console:
Explicit messages are sent using the "Explicit Message" tab from "On-line actions". To
access this, select a node from the "network detection" tree. The "On-line actions" are then
accessible using the button or the "Network/On-line action" command from the main
menu.

Using explicit messaging in EtherNet/IP
Description
The functions required to use explicit messaging with a configured device are held in the DLL
function library.
Use with the function AuWriteReadMsg_io from the applicomio.dll DLL

The function "AuWriteReadMsg_io" enables the explicit messaging specific to EtherNet/IP to
be used. It takes 8 parameters:
Explicit messaging
- wChan: 16-bit word giving the target applicomIO® channel. It is calculated using macro
CARD2CHAN which converts a board number to channel number (channel = (board-1)*4).
- wEquip: 16-bit word giving the number of the applicomIO® target device (0 to 127).
- dwMsgParam:
Unconnected: value 0x00000100UL.
Connected: value 0x00000101UL.
- wNbTx: number of bytes to send in the lpbyBufTx buffer.
- lpbyBufTx: pointer to the send buffer. The bytes are arranged as follows:
[0] : CIP Service.
[1] : Size of path in words (1 to 128).
[2]-[…] : Path
[2+PathSize]: Message data to be sent.
- pwNbRx: pointer to number of bytes received: indicates the number of bytes received if
the variable pointed to by pdwStatus is non-null.
* On call: indicates the maximum size of the receive buffer.

* On return: indicates the number of bytes received if dwStatus=0.
- lpbyBufRx: pointer to receive buffer. The bytes are arranged as follows:
[0] : CIP Service. + 0x80. If the answering message is an error, this byte
contains 0x94.
[1]-[…] : Data returned on reply.
- pdwStatus: pointer to an applicomIO® 32-bit error status1 word.
See also:
 in the documentation
 applicomIO status
 sample

 Installed into the subdirectory
“Development\MSVC\Sample LibApplicomIO\EthernetIP” of your installation
directory

DHCP, BOOTP, DNS
Introduction to DHCP and BOOTP Client service on an applicomIO® solution
General
®
The DHCP and BOOTP client services provided with the applicomIO solution automatically obtain
an IP address and the various options required:
List of the different options:
1. IP address:
IP address of the Ethernet channel of the applicomIO® solution obtained by the
BOOTP or DHCP server.
2. Sub-network mask:
Sub-network mask of the Ethernet channel of the applicomIO® solution obtained
by the BOOTP or DHCP server.
3. Gateway address.
Address of the gateway configured on the Ethernet channel of the applicomIO®
solution.
4. Address of the primary DNS server
Address of the primary DNS required for DNS resolution.
To invalidate this service, the IP address should be set to 0.0.0.0
5. Address of the secondary DNS server
Address of the secondary DNS required for DNS resolution.
To invalidate this service, the IP address should be set to 0.0.0.0
6. Bail time:
IP address attribution lifetime, only in DHCP.
Possible values: 0 No bail management
-1 Unlimited bail
From 1 to 4294967295 Bail time in seconds
7. Domain name (DomainName).
Name of native domain for the applicomIO® solution. The applicomIO® solution will
use this domain for any IP address resolution.
For resolving an IP address on another domain, a domain name must be specified
after that of the name to be resolved. E.g.: Device1.Production1 in this case, the
name "Device1" will be associated with the domain "Production1".
8. Host name (HostName).
Name with which the applicomIO® may be resolved after registration on the DNS
server.
You can also refer to the chapter : “Automatic registration of the applicomIO®
board on the DNS server”

Startup flowchart for the applicomIO® solution in DHCP or BOOTP configuration
This startup flowchart represents the different stages possible during initialization (presence of
server, non-presence of server, etc.)
Each time a new IP address is obtained by a DHCP or BOOTP server, this is saved in "flash
memory".
Any static IP configuration will also be saved in "flash memory".

Factory IP address
®
During initialization of the applicomIO Ethernet solution in DHCP or BOOTP configuration, if the
DHCP or BOOTP server does not respond to the request for an IP address, the applicomIO®
solution initializes itself with the parameters saved in "flash memory" (obtained previously).
Assume no initialization has been carried out on the board previously. A factory IP address will then
be assigned to the applicomIO® board. This IP address is 192.168.0.1, the sub-network mask
being 255.255.255.0.
If the applicomIO® board is initialized with the factory IP address, an information message
is displayed in the applicomIO® diagnostic tool.

Flash memory
®
Each time the applicomIO board is initialized, all the IP addresses required for the applicomIO®
solution will be saved in flash memory.
If no IP address is obtained from a BOOTP or DHCP server, the applicomIO® board initializes itself
with the last values saved.
If the applicomIO® board is initialized with parameters from the flash memory, an
information message is displayed in the applicomIO® diagnostic tool.

Waiting for a response from the DHCP or BOOTP server.
®
Until the applicomIO board receives a response from the BOOTP or DHCP server, status 58 is
returned to any query issued on this board.
In the diagnostic tool, a "NOT READY" message is displayed.
Bail management by the applicomIO® solution in DHCP configuration.

During attribution of an IP address by the DHCP server, a bail is opened for a specific time (refer to
the configuration of the DHCP server used), during which the DHCP server will not redistribute this
address to any other station on the network.
®
The applicomIO solution will automatically send a renewal request for this bail (before it expires)
to the DHCP server.
Bail management is active in DHCP mode if it is not null or unlimited.
Distributing dynamic IP addresses with a bail could become a problem in industrial use
(loss of station due to change of IP address, end of bail, etc.)
To guard against this problem, reserve an IP address relative to a MAC address and set unlimited
bail.
If the Ethernet/IP local slave of the applicomIO® solution is used and no reservation is made, the IP
address of the board could be changed each time it is used. This makes communication with the
EtherNet/IP local slave difficult.
IMPORTANT: Each time the applicomIO® board is initialized, the current IP address will be
suggested to the DHCP server for it to attribute.

Introduction to the DNS Client service on an ApplicomIO® solution
General
DNS resolution resolves the names or IP addresses for a primary DNS server, then the secondary
if the primary server does not respond (TIMEOUT).
®
As the applicomIO solution is initialized with a default domain name, all resolutions will be made
on this domain.
If no IP address is defined for the primary and secondary servers (0.0.0.0), a status value of 2 will
be returned for every resolution request.
To resolve a host name on another domain, the name of the host followed by the name of the
domain must be specified (Device2.Production2) when resolving
Example :
The applicomIO® solution is initialized with the domain name "Production1".

On the DNS server, "Device10" is recorded with address 128.127.56.12 for domain "Production1".
"Device10" will be resolved implicitly on domain "Production1", the response received being
128.127.56.12.
Assume, on another domain "PROD_GAZ_1", a device "Local_1" is accessible. To resolve this IP
address outside our domain name ("Production1") it is necessary to specify the domain name
during the resolution request.
In our example, an IP address request for "Local1" on "PROD_GAZ_1" will be done as follows:
"Local_1.PROD_GAZ_1".

Operating principle of the primary and secondary server
One-off resolution (from the diagnostic tool):
During an attempt at DNS resolution on the primary server, if it does not respond (TIME OUT), the
same request will be sent to the secondary server.
Automatic resolution (resolution of the configuration device):

®
During initialization of the applicomIO solution, all the host names of equipment defined in the
configuration will be resolved automatically:
All these requests will be sent to the primary DNS server. If this does not respond to the request
(TIME OUT), all requests will then be sent to the secondary server. If this does not respond, all
requests will be sent to the primary server and so on until all the names are resolved. During this
phase, the device has status 131.
For each device configured with a name, requests will be reiterated until a response is obtained
from a server (positive response (0), or negative (132)).
Automatic registration of the applicomIO® board on the DNS server

®
The applicomIO solution offers the possibility of auto registration on the DNS server in order to be
able to be resolved by another station.
To use this feature, select File\Preferences\Expert mode from the applicomIO® console
This options displays the expert parameters in the various configuration windows of the
applicomIO® console. Warning: Changing these parameters can change how the applicomIO®
solution operates.
In the "TCP/IP protocol configuration" panel, "General" tab.
Select "True" in the "Dynamic update of the DNS" line. This causes the board to register
automatically on the DNS server at each initialization.
Registration is only done on the primary server. It is done using the name of the host and the name
of the domain configured in static mode or obtained by the server in DHCP or BOOTP mode.
By default, this option is not enabled.

Time Out.
A default time out is fixed for the DHCP, BOOTP and DNS services. It is set to 3 seconds.
In Expert mode, it is possible to change this parameter (from 1 second to 30 seconds).
®
To do this, select File\Preferences\Expert mode from the applicomIO console
Any changes made to this parameter can stop one of the three services working properly.

6. Modbus on Ethernet
TCP/IP appendix
IP address
Each interface on a TCP/IP network or subnetwork requires a unique IP address.
This address is determined according to the type of network:
 open type network (e.g.: connected to the world wide web), the address or set of
addresses must be issued by a qualified organisation in the country where the network is
installed.
 closed type network (intranet), the addresses are issued by the network administrator.
An IP address is represented on 4 bytes (or 32 bits) and consists of:

 a network identifier.
 a machine identifier.
Using these two identifiers, the IP addresses can be divided into 5 classes:

Which gives us in notation with decimal point:
The choice of an internal address, will therefore depend on the number of stations on this network,
generally a class C address is sufficient.
Special case: "loopback" destination address 127.0.0.1 , this address is used to test the TCP/IP
layer. A packet with a destination address of 127.0.0.1 will not leave on the network, the packet
drops to the IP layer then rises immediately to TCP.
Subnetwork mask
The class A and B addresses include many machines which are represented respectively on 24
and 16 bits. It is therefore recommended to divide the machine identifier into subnetwork identifier
and machine identifier.
For example, for a class B address:
This breakdown provides 254 subnetworks, with 254 machines per subnetwork. The subnetwork
mask is used to specify the bits used to create the subnetwork mask. This mask is a 32 bit word
containing bits set to 1 for the network and subnetwork identifiers, and bits set to 0 for the machine
identifier.
Example for a subnetwork mask of a class B address:
i.e. a subnetwork mask of 255.255.255.0
Using its IP address and the subnetwork mask, a machine can determine whether a packet is
intended for:
 a machine on its own subnetwork.
 a machine on another subnetwork (use of the IP address of the gateway).
 a machine on a different network (use of the IP address of the gateway).
Example:
®
The applicom card has IP address 140.152.3.25 with a subnetwork mask at 255.255.255.0.
The address is therefore class B with a network id at 140.152, a subnetwork id at 3, and a machine
id at 25.The following devices must be queried:
 Device 1 with address 140.152.7.10: identical network id (140.152), different subnetwork id
(7) => use of gateway.
 Device 2 with address 140.152.3.20: identical network id (140.152), identical subnetwork id
(3), different machine id (20) => send direct to device.
applicomIO® Knowledge base Implementation Modbus on Ethernet  183

 Device 3 of address 194.204.26.43: different network id (class C) => use of gateway.
Gateway
The TCP/IP IP layer (layer 3) can be used to change network or subnetwork via a dedicated
machine called a gateway or router. This machine requires at least two links on two different
networks. When the destination address is on a different network, IP uses the IP address of the
gateway to send the packet, this gateway is responsible for taking this packet completely and
sending it to the destination network.
Example: switch to an internal subnetwork:
Figure 1 : IP Gateway
The request intended for device 2 of address 140.152.7.10, is sent to the gateway 140.152.3.1
(switch from network 140.152.3 to 140.152.7). The gateway sends the request to device 2 , which
replies using the gateway 140.152.7.1.

TCP Time-out
The TCP/IP protocol provides a reliable transport layer, i.e. it manages time-out and retry
procedures to acknowledge packets.
The maximum number of retries is 12 and the time-out between each retry is variable. This time is
calculated initially from an estimation of the "return trip" time of a packet on the connection then
increased exponentially as the tests proceed with a limit of 64 seconds, which most often gives:
Figure 2 : TCP Time-Out
We can quickly see that the wait time to find out whether a packet has not been acknowledged can
®
be very long: 542.5 seconds, or over 9 minutes. The applicom interface allows you to configure:
 the number of retries.
 the maximum interval between two retries.
To simplify the time-out calculation, it is easier to set the maximum interval between two retries at 1
®
second and then "juggle" with the number of retries, by default the applicom interface uses 2
retries, which gives you a time-out of about 3 seconds.
On very disturbed or very saturated networks (load greater than 30 %), it is best to put 4 retries.
Connection maintenance
The TCP connections can be maintained with the "connection maintenance" function in the TCP/IP
"Advanced parameters" (commonly called "keep alive"). This maintenance keeps the connection
alive even though there is no data circulating; also, if the partner device no longer responds to this
maintenance, the connection is automatically deleted.
®
The applicom interface can be used to validate or not this type of operating mode, whose
characteristics (not modifiable) are as follows:
 maintenance frequency: 30 seconds

 retry frequency: 20 seconds
 number of retries if no response: 8

Extended statuses (TCP/IP)
The extended statuses for TCP/IP are used to refine the statuses related to the protocol and are
accessed via the "TCP-IP & ISO Diagnostics" utility by selecting "Expert Mode".

Configuring the master
Maximum number of requests in progress
Accessible via the Ethernet node, General tab, in expert mode only.
Sets the maximum number of requests in progress. Above this value, the requests are put on a
queue until a request in progress is released.
The number of requests being processed indicates a number of requests sent simultaneously onto
the network. Theses requests increase the network load.
Adjust the maximum number of requests being processed to regulate the this load.
Value from 1 to 32; 6 by default.

Exchange block
Purpose of an Exchange block
An exchange block is used to read or write a fixed number of data items of the specified type at a
precise address in a device on the network.
You must define a new exchange block for each new memory area of a device.
 For the input variables, operation is purely cyclic, i.e. the input values will be read at
regular intervals defined by the period of the exchange block.
 For the output variables there are two possible operating modes:
 Cyclic mode only.
In this case operation is the same as for the inputs.
 "Cyclic and on change of value" mode.
In addition to operation in cyclic mode, the output data of the device is also
refreshed if their values change.
Writing outputs in "Cyclic and on value change" mode
Configuring the period of an Exchange block

To ensure that the input/output data will be read and written at the specified intervals, you must
accurately determine the periods of the exchange blocks.
The correctly choose the period of each exchange block, the number of devices and the
response time of each one must be taken into account.
The following curves give as an indication the minimum period values of each exchange block
below which the values will not be refreshed at the requested periods.

For each of these curves, the network configuration is as follows: one exchange block in input and
one exchange block in output for each device.
 Configuration of an exchange block in input
 Period: variable
 Number of words exchanged: 1
In a given configuration, all the periods of all exchange blocks in input are identical
irrespective of the device.
 Configuration of an exchange block in output

 Mode: "cyclic and on status change"
 Period: 500 ms
 Number of words exchanged: 1
Each curve corresponds to the response time of each device (2.5, 5, 7.5 and 10 ms).
These curves show that, as far as possible, you must avoid choosing period values which are too
small, which would penalize all the exchanges blocks in their respective refresh times.
Important:
These measurements correspond to a special configuration case: one exchange block of one word
in input, one exchange block of one word in output and identical device response time.
If several exchange blocks are configured in input (or in output), it is recommended to adapt their
periods according to the priority of the corresponding data. For example, the period for process
data (device Inputs or Outputs), which have high priority, must be less than that of information data
(e.g.: device status word), low-priority data.

Modbus on Ethernet device inputs / outputs
Organization of Modbus on Ethernet device inputs / outputs
®
The device inputs and outputs are organized automatically in the DP RAM of the applicomIO
interface according to the exchange blocks configured.
Consequently, device inputs and outputs in applicomIO® will be composed successively of
exchange block data.
Example:
The configuration of this device is as follows:
 Input:
1. 1 exchange block for 1 bit
2. 1 exchange block for 2 words

 Output:
1. 1 exchange block for 1 word
2. 1 exchange block for 12 bits
Corresponding organization of the DP RAM:
Online action on the Modbus on Ethernet network

Description
Online actions (read and write in registers in devices which have not been configured) are grouped
®
in the applicomIO console in a screen:

 Online action, "Read/Write" tab
This feature is called in the "Network detection" tab, by pressing the "Online action" button
 Destination
 IP address: Address of target device
 Transport protocol:Type of transport protocol used to access the device
Values: TCP or UDP; by default TCP.
 Destination port: Port used to connect to the target device

 Read
 Base register: Address of the register to read
 Number: Number of words to read
 Read: Press this button to read the specified register once
 Continuous: Continuous read of the specified register
 Stop on error: Stop reading as soon as an error is encountered
 Number of reads: Total number of reads made
 Write
 Base register: Address of the register to write
 Number: Number of words to write
 Write: Press this button to write the specified register once
 Continuous: Continuous write of the specified register
 Stop on error: Stop writing as soon as an error is encountered
 Number of writes: Total number of writes made
Use
 Determination of the target device address
 If you have carried out network detection beforehand and you select one of the
devices detected, the IP address of the device chosen will be automatically taken.
 If no device is selected (you have not carried out network detection or if the "Network"
node is selected), a default IP address will be automatically calculated from the board
address with a station number = 0. You must specify the correct station number of the
target device.
 Enter the protocol used (TCP/IP or UDP)
 Enter the destination port (by default 502)
Read
Enter the value of the base register and the number of words to read.
Press the "Read" button to execute the command.
"Continuous" checkbox for a cyclic read of the register.
The "Stop on error" checkbox will stop the cyclic read if an error occurs.
The result of the read is displayed as well as the communication status.
Write
Enter the value of the base register and the number of words to write.
Press the "Write" button to execute the command.
"Continuous" checkbox for a cyclic write of the register.
The "Stop on error" checkbox will stop the cyclic write if an error occurs.
The result of the write is displayed as well as the communication status.

Transmission / reception of a Modbus frame
Description
Access the functionality for transmission and reception of a Modbus frame with a configured device
via the DLL function library.

The function "AuWriteReadMsg_io" is used to transmit and receive frames in the Modbus on
Ethernet devices.
It requires 8 parameters:
®
- wChan: 16-bit word indicating the targeted applicomIO channel; it is determined with the
CARD2CHAN macro, which transforms a board number into a channel number (channel = (board-
1)*4 ).
- wNes: 16-bit word indicating the number of the targeted applicomIO® device (0 to 127).
- dwMsgParam: 0.
- wNbTx: Number of bytes to transmit to the lpbyBufTx buffer.
- lpbyBufTx: pointer to the transmission buffer.
The bytes are distributed as follows:
[0] : Modbus function code.
[1]-[…] : Data of the Modbus function to be sent.
You can place up to 256 bytes of data in the transmission buffer.

- lpbyBufRx: pointeur to the reception buffer. The bytes are distributed as follows:
[0] : Modbus function code. If the response message is an error, this byte contains the
Modbus function code + 0x80.
[1]-[…] : Data returned in response.
You can place up to 256 bytes of the message to be received in the buffer.
1
- pdwStatus: pointer to an applicomIO®. error status 32 bit word

example in ANSI Language C
Read an input register at address 0, on a device applicom number 5, of board number 1.

Remark: When including the "applicomio.h" file in a C++ project, you must include the file in
extern "C" (extern "C" { #include "applicomio.h" } )
#include "applicomio.h" /* Prototype declaration

file */
unsigned short wCardNumber = 1; /* Board number */

unsigned short wNes = 5; /* Applicom device
number */
unsigned long dwMsgParam = 0; /* Must be 0 */
unsigned short wRef = 0x0000; /* Address */
unsigned short wWdCount = 0x0001; /* Number of
words */
unsigned long dwStatus; /* Return code */
unsigned char byTxBuf[256]={0}; /* Data to
be transmitted */
unsigned char byRxBuf[256]={0}; /* Data
received from the device */
unsigned short wNbTx = 0; /* Number of bytes to be
transmitted */
/* Max. size of the reception buffer */
unsigned short wNbRx = sizeof(byRxBuf);
/* Production of the message to be sent to the

device */
byTxBuf[wNbTx++] = 0x04; /* Function code */
memcpy(&byTxBuf[wNbTx++], & wRef, 2); /* Address
*/
wNbTx++;
memcpy(&byTxBuf[wNbTx++], & wWdCount, 2); /*
Number of words */
wNbTx++;
/* initialize applicomIO.dll library by

"AuInitBus_io" */
/* Send the Modbus on Ethernet message */

AuWriteReadMsg_io(CARD2CHAN(wCardNumber), /*
Channel number */
wNes, /* applicom number */
dwMsgParam, /* Must be 0 */
wNbTx, /* Number of bytes to
transmit*/

byTxBuf, /* Buffer to
transmit */
&wNbRx, /* Number of bytes
received */
byRxBuf, /* Reception
buffer */
&dwStatus); /* Result of the
exchange */
if (dwStatus == 0)
{
if (byRxBuf[0] == (byTxBuf[0] + 0x80))
{
/* Error message returned by the device */
}
else
{
/* No error message */
/* Response by the device to the request
*/
}
}
else
{
/* Error returned by applicom */
}
/* execute the function "AuExitBus_io" before

exiting */
A complete example is available in the "Development\MSVC\Sample LibApplicomIO\ModbusEthernet"

directory from the directory where applicomIO® was installed.
It includes:
 a "C" file: MbIOAuWriteReadMsg.c
 an executable file MbIOAuWriteReadMsg.exe
This example can be used to send all types of command to a configured device.
This file must be included in a work project or can be compiled on line, it requires access to the file
"applicomIO.h" and link editing with applicomIO.lib.
See also:
In the documentation:
i. applicomIO Status

7. Profibus DP
General points
Profibus DP is a fieldbus optimized for high-speed cyclic data exchange. Its characteristics,
described in European standard EN 50170 volume 2, allow exchanges of up to 244 bytes of useful
data at speeds from 9.6 kbit/s to 12 Mbit/s.
A text file is used to identify a master or slave Profibus DP device. The format of this file defined by
the standard allows the use of configuration tools independent of the device manufacturer. Each
device must have this identification file, generally designated by the extension “.GSD”. This file is
provided by the device manufacturer.
Each device is marked with an individual identification number (Ident Number). During the network
initialization phase, the master compares the identification number of each device with the one
defined at configuration time. This makes it possible to provide protection against configuration
faults.
applicomIO® Knowledge base Implementation Profibus DP  197

Profibus DP step by step
Solving Profibus DP network problems
Implementation of a Profibus DP network can present certain difficulties. For correcting elementary
problems, you will find a list of checks in this chapter, to be carried out according to the problem
noted:
Problem Cause
No equipment present after a network detection. Address conflict.
Break in cabling.
The network detection indicates a network problem. Address conflict.
Short circuit on the cable.
Checking the stations on the Profibus network

The aim of this chapter is to present certain problems connected with the configuration of Profibus
stations. A Profibus network is composed of at least one bus segment and two stations. The
stations are divided into two families: active stations (Masters) and passive stations (Slaves): a
Profibus network always has at least one master station.
Profibus allows the use of physical addresses 0 to 126 for distinguishing each station on the
network. By definition, the active stations initiate the communication; however, in order to regulate
access to the bus, an access authorization (token) is passed from one master station to another
master station in increasing order of address. Only the station with the highest address transfers
the token to the station with the lowest address to close the token‟s logical loop.
The correct operation of a Profibus network requires observance of the following points:
 Each station has a unique physical address.
 All stations are set to the same transmission speed or are capable of automatically
detecting the speed used.
 The address of the highest station (HSA) of each master station is greater than or equal to
the address of the highest master station.
 The exchange cycle control time in each slave station (Control Watchdog) is sufficient to
allow initialization and the data exchanges.
 The receive wait time (TSL) of each master station is matched to the network architecture.
The value of this parameter increases for networks having several master stations or a
long cable length, or one using repeaters.

Checking the Profibus cabling
The aim of this chapter is to present certain problems connected with the use of a Profibus cable
with copper conductors, assuming compliance with the regulations and directives contained in the
standards concerned (standard EN50170, CEM regulations, etc.). It is essential that dedicated
Profibus connectors are used (9-way male D-sub connectors).
The integration of bus terminations in the connection equipments often leads to network start-up
difficulties:
 Either through faulty configuration of the terminations.
 Or through reversing the cable in the connector.
A Profibus cable with copper conductors must have two bus terminations at the ends of each
network segment, as shown in the figure below :
Activation of a termination is accessible on each connector. A Profibus connector generally includes

a switch, either visible directly, or connected to a tongue as shown in the figure below:
A station which has an activated termination must always be powered.

A network operating correctly at 9.6 kbit with no terminations may exhibit significant malfunctions at
1.5 Mbit since the risks of interference are greater at high speeds.
Profibus connectors are equipped with terminals allowing two cables to be connected. The position
of the cable in the connector is important given that the connection of the outside cable to the
terminations is broken.

Connection of equipment detected with its GSD file
Automatic detection of the configuration from the network makes it possible to ascertain, for each
equipment, the individual identification number and the configuration string of all the modules. To
supplement this information, a search for the files compatible with each equipment detected is
carried out in the list of available equipments contained in the “Equipment library”. From the result
of this search, three cases are possible for each equipment detected:
 A single GSD file: this is then automatically used.
 A number of GSD files are compatible: a dialog box offers a choice of one of these files.
 Lack of any GSD file: a dialog box offers the use of the “Generic device” file. In this case,
to benefit from all the information for the equipment, you must insert its GSD file in the
“Equipment library” and re-initiate network detection.
From the information present in the GSD file and the values read over the network, a configuration
is generated. Manual corrections of this configuration may be necessary in the following cases:
 A module detected in the equipment is unknown in the list of available modules in the GSD
file. An unknown module is shown as follows:
 Several combinations in the module list can be implemented.

 The module configuration can be programmed in the equipment.
After validating the message, it is possible to manually complete the module information in the
properties of the “Undetermined Module”, “Parameters” tab in “Expert” mode only

Connection of equipment detected with a number of GSD files
The presence of several files for the same equipment type is shown by the following dialog box:
A double click on the left mouse button or pressing the “Space” key allows viewing of the properties
of each GSD file compatible with the equipment detected on the network. After selecting the file,
validate with the “OK” button.

Connection of equipment detected without a GSD file
The lack of a GSD file for a network equipment is shown by the following dialog box:
For a better integration of the equipments with the card configuration, it is recommended that the
GSD files for your equipments are added to the “Equipment library”. These files are generally
provided by the device manufacturer. For equipments which don‟t have a description file, the
configuration interface offers a virtual file “Generic device” which allows manual input of the
information necessary for integrating this equipment into the configuration. Use of the “Generic
device” is detailed in the chapter “Using the generic device”.

Profibus DP services
Description
The functionality enabling use of Profibus DP services can be accessed from the DLL functions
library: "applicomIO.DLL".
Use of the AuWriteReadMsg_io Function

The "AuWriteReadMsg_io" function enables use of Profibus DP-specific services:
 Get configuration from the device (Get Config = SAP_59).
 Read input from the device (Read Input = SAP_56).
 Read output from the device (Read_Output = SAP_57).
 Read diagnostic function from the device (Slave Diag = SAP_60).
 Write a command in the device (Global Control = SAP_58)
 …
This function requires the following 8 parameters:
 wChan: 16-bit word indicating the targeted applicomIO® channel; it is determined
with the CARD2CHAN macro, which transforms a board number into a channel
number (channel = (board-1)*4 ).
 wEquip: 16-bit word indicating the number of the targeted applicomIO® device.
 dwMsgParam: 32-bit word indicating the service.
Service Fonction
56 Read Input
57 Read_Output
58 Global Control
59 Get Config
60 Slave Diag
61 Set Global Control Group
62 Get Slave Parameter
63 Set Slave Parameter
67 Read Data Bloc C1
68 Write Data Block C1
69 Read Data Block C2
70 Write Data Block C2 -
72 Abort Data Block Comm C2
0x10037 Set Slave Adr
 wNbTx: Number of bytes to transmit to the lpbyBufTx buffer.

 lpbyBufTx: Near pointer to the transmission buffer. Up to 244 bytes of data can be
placed in the transmission message.
 pwNbRx: Near pointer to the number of bytes received. The return value indicates the
number of bytes received, if the variable indicated by pdwStatus is equal to zero.
 lpbyBufRx: Near pointer to the reception buffer. Up to 244 bytes of data can be placed in
the reception message.
 pdwStatus: Near pointer to the 32-bit applicomIO® error status.1

Diagnos
The function « AuWriteReadMsg_io » allow to read diagnos information inside the device.
This function needs 8 parameters:
Parameter Type
wchan 16-bit integer. Number of the targeted communication
channel . One goes from a board number to a channel
number by using the CARD2CHAN macro.
wEquip 16-bit integer. Number of the targeted device.
dwMsgParam= 60 32-bit integer. Parameter associated with the messaging
command.
wNbTx 16-bit integer. Number of bytes sent.
byBufTx Table of bytes. Messaging command to be sent.
wNbRx 16-bit integer. Caution, this parameter is an input and output
parameter:
During call-up, maximum size of the returned table of bytes.
As feedback, number of bytes received.
byBufRx Table of bytes. Feedback from the device following the
command.
dwStatus 32-bit integer. Exchange status.
#include "applicomio.h" /* Fichier des déclarations*/
void ReadSlaveDiagnostic(WORD wChan)

{
DWORD dwMsgParam = 60; /* SAP for Read Slave Diagnostic */
WORD wEquip; /* applicom number */
WORD wNbTx = 0; /* Number of bytes to send */
BYTE byTxBuf[MAX_BUFFER_SIZE]; /* send buffer */
BYTE byRxBuf[MAX_BUFFER_SIZE]; /* receive buffer */
WORD wNbRx = sizeof(byRxBuf); /* number of bytes received */
DWORD dwStatus; /* return code */
printf("Read Slave Diagnostic\r\n");
wEquip = (WORD)PrintAndScan("applicom Equipment Number :","%u"); /* Get

applicom equipment number */
AuWriteReadMsg_io (wChan, /* Channel number */

wEquip, /* applicom number */
dwMsgParam, /* service */
wNbTx, /* Number of bytes to send */
byTxBuf, /* send buffer */
&wNbRx, /* number of bytes received */
byRxBuf, /* receive buffer */
&dwStatus ); /* return code */
if (dwStatus == 0) /* get return status */

{ /* if no error */
printf("Response Len: %u Data: %s \r\n",wNbRx,DumpData(byRxBuf,wNbRx));
}
else

{/* Error code analysis */
printf("Error : \r\n%s \r\n",GetStatusDefinition(dwStatus));
}
}

Read IO configuration
The function « AuWriteReadMsg_io » allow to read configuration buffer of the device.
Parameter Type
dwMsgParam = 59 32-bit integer. Parameter associated with the messaging
command.
parameter:
command.
void ReadSlaveConfiguration(WORD wChan)

{
DWORD dwMsgParam = 59; /* SAP for Read Configuration */
printf("Read Slave Configuration\r\n");



{ /* if no error */
}
else

}
}

Read input data
The function « AuWriteReadMsg_io » allow to read input data of the device.

Parameter Type
command.
parameter:
command.
void ReadSlaveInput(WORD wChan)

{
DWORD dwMsgParam = 56; /* SAP for Read Input */
printf("Read Slave Input\r\n");



{ /* if no error */
}
else
}}

Read output data
The function « AuWriteReadMsg_io » allow to read output data of the device.
Parameter Type
command.
parameter:
command.
void ReadSlaveOutput(WORD wChan)

{
DWORD dwMsgParam = 57; /* SAP for Read Output */
printf("Read Slave Output\r\n");



{ /* if no error */
}
else

}
}

Send configuratio data
The function « AuWriteReadMsg_io » allow to send configuration data to the device.
Parameter Type
command.
parameter:
command.
void SetParameterData(WORD wChan)

{
DWORD dwMsgParam = 63; /* Get service parameter data */
WORD wEquip ; /* applicom equipment number */
WORD wLen;
printf("Set Parameter Data\r\n");
/* Get applicom equipment number */

wEquip = (WORD)PrintAndScan("applicom Equipment Number :","%u");
/* Get slave data length */;

wLen = (WORD)PrintAndScan("Slave Parameter Data len [7..244] :","%u");
if (wLen)
{
if ( (wLen <= 244) && (wLen >= 7) )
{ /* Get slave data */;
GetData(&byTxBuf[wNbTx],wLen);
wNbTx += wLen;
}
else
{ /* length error */
printf("Error : \r\n%s \r\n",GetStatusDefinition(21));

return;
}
}

wEquip , /* Station address */

{ /* if no error */
}
else
}
}

Send Global Control
The function « AuWriteReadMsg_io » allow to send Global Control to the device.
Parameter Type
command.
parameter:
command.
void SetGlobalctrl(WORD wChan)

{
DWORD dwMsgParam = 58; /* Set Global ctrl service */
printf("Set Global Ctrl\r\n");

byTxBuf[wNbTx++] = (BYTE)PrintAndScan("New Global ctrl value :","%u");


{ /* if no error */
}

else
}
}

Send Global Group Control
The function « AuWriteReadMsg_io » allow to send Global Group Control to the device.
Parameter Type
command.
parameter:
command.

void SetGlobalctrlGroup(WORD wChan)
{
DWORD dwMsgParam = 61; /* Set Global ctrl service */
printf("Set Global Ctrl Group\r\n");
wEquip = 127; // Broadcast Equipment

byTxBuf[wNbTx++] = (BYTE)PrintAndScan("New Global ctrl value :","%u");
byTxBuf[wNbTx++] = (BYTE)PrintAndScan("Select a Global ctrl group [0..255]
:","%u");


{ /* if no error */

}
else
}
}

Read data blocks Classe1 DPV1
Parameter Type
command.
parameter:
command.

void ReadDataAsyncC1 (WORD wChan)
{
DWORD dwMsgParam = 67; /* Read data block C1 service */
printf("Read Data Async\r\n");

byTxBuf[wNbTx++] = (BYTE)PrintAndScan("Slot Number :","%u");
byTxBuf[wNbTx++] = (BYTE)PrintAndScan("Index Number :","%u");
byTxBuf[wNbTx++] = (BYTE)PrintAndScan("Lenght Data :","%u");


{ /* if no error */

}
else
}
}

Write data blocks Classe1 DPV1
Parameter Type
command.
parameter:
command.
void WriteDataAsyncC1 (WORD wChan)

{
DWORD dwMsgParam = 68; /* Write data block C1 service */
WORD wLen;
printf("Write Data Async\r\n");


wLen = byTxBuf[wNbTx++] = (BYTE)PrintAndScan("Lenght Data :","%u");
if (wLen)
{
if ( (wLen <= (244 -3)) )
wNbTx += wLen;
}
else

return;
}
}


{ /* if no error */
}
else
}
}

Read data block Classe2 DPV1
Parameter Type
command.
parameter:
command.

void ReadDataAsyncC2 (WORD wChan)
{
DWORD dwMsgParam = 69; /* Read data bloc C2 service */
printf("Read Data Async\r\n");

byTxBuf[wNbTx++] = (BYTE)PrintAndScan("Lenght Data :","%u");


{ /* if no error */

}
else
}
}

Write data block Classe2 DPV1
Parameter Type
command.
parameter:
command.

void WriteDataAsyncC2 (WORD wChan)
{
DWORD dwMsgParam = 70; /* Write data bloc C2 service */
WORD wLen;
printf("Write Data Async\r\n");


wLen = byTxBuf[wNbTx++] = (BYTE)PrintAndScan("Lenght Data :","%u");
if (wLen)
{
if ( (wLen <= (244 -3)) )
wNbTx += wLen;
}
else

return;
}
}
{ /* if no error */
}
else
}
}

Abort communication Classe2 DPV1
Parameter Type
command.
parameter:
command.

void AbortDataAsyncC2 (WORD wChan)
{
DWORD dwMsgParam = 72; /* Write data bloc C2 service */
WORD wLen;
printf("Abort Data Async\r\n");



{ /* if no error */
}

else
}
}

Set slave address
Parameter Type
dwMsgParam = 32-bit integer. Parameter associated with the messaging
0x00010037 command.
parameter:
command.

void SetSlaveAddress(WORD wChan)
{
DWORD dwMsgParam = 0x00010037; /* SAP to Set Slave Address */
WORD wTs; /* Station address */
WORD wIdentNumber;
WORD wLen;
printf("Set Slave Address\r\n");
/* Get station address */

wTs = (WORD)PrintAndScan("Current station address [0..126]:","%u");
/* Get New Station Address*/

byTxBuf[wNbTx++] = (BYTE)PrintAndScan("New Station Address [0..125]
:","%u");
/* Get Ident Number */

wIdentNumber = (WORD)PrintAndScan("Ident Number :","%u");
byTxBuf[wNbTx++] = wIdentNumber >> 8; /* Get Ident high */
byTxBuf[wNbTx++] = (BYTE)wIdentNumber; /* Get Ident low */
/* Get flag no address change*/

if (0 == PrintAndScan("No Address change [0..1] :","%u"))
byTxBuf[wNbTx++] = 0;

else
byTxBuf[wNbTx++] = 0xFF;

wLen = (WORD)PrintAndScan("Slave Data len [0..237] :","%u");
if (wLen)
{
if (wLen <= 237)
wNbTx += wLen;
}
else
return;
}
}

wTs, /* Station address */

{ /* if no error */
}
else
}
}

Sample
A complete sample is available in the folder « Development\MSVC\Sample LibApplicomIO\Profibus » from

®
applicomIO installed directory.
It includes C ANSI source code : Wchan_ProfibusDPAuWriteReadMsgIO.c, and an executable file:
ProfibusAuWriteReadMsgIO.exe.
This file should be included in a Microsoft visual studio 6.0 project. It needs to access to : applicomIO.h
and applicomIO.lib.
Notes :
applicomIO.h file shall be included like this in c++ project:
extern "C"
{
#include "applicomio.h"
}
Before using aplicomIO functions, a first call to "AuInitBus_io" should be made.

After using aplicomIO functions, a call to "AuExitBus_io" should be made.

8. PROFINET
PROFINET Service
Description
The functionality enabling use of PROFINET services can be accessed from the DLL functions
library: "applicomIO.DLL".
A Sample in C is installed into the subdirectory:

[Répertoire d‟installation]\ Development\MSVC\Sample LibApplicomIO\Profinet
Use of the AuWriteReadMsg_io Function

The "AuWriteReadMsg_io" function enables use of PROFINET specific services:
 IO-Device detection on the network (DCP Identify)
 Set name to one IO-Device (DCP Set name)
 Get name from one IO-Device (DCP Get name)
 Set IP to one IO-Device (DCP Set IP)
 Get IP to one IO-Device (DCP Get IP)
 IO-Device signal (DCP Blink)
 Reset one IO-Device (DCP Reset factory)
 Set DHCP configuration to one IO-Device
 Get DHCP configuration from one IO-Device
 Read record data (Record read)
 Write record data (Record Write)
 Channel Managment (OFFLINE/ONLINE/RUN)
 IO-Device Managment (User/automatic – Connect Release)
 Alarm managment (Card configured in IO-Device) :
o Send
o Response
 Alarm managment (Card configured in IO-Controller) :
o Indication
o Acquittement (Acknoledge)

This function requires the following 8 parameters:
 wChan: 16-bit word indicating the targeted applicomIO® channel; it is determined
with the CARD2CHAN macro, which transforms a board number into a channel
number (channel = (board-1)*4 ).
 wEquip: 16-bit word indicating the number of the targeted applicomIO® device.
 dwMsgParam: 32-bit word indicating the service.
Number Service Code operation (lpbyBufTx [0])

1 Service DCP 01 - C_IDENTIFY
02 - C_SET_NAME
03 - C_SET_IP
04 - C_GET_NAME
05 - C_GET_IP
06 - C_BLINK
07 - C_CLEAR
08 - C_RESET_FACTORY
09 - C_SET_DHCP
10 - C_GET_DHCP
2 Service READ 01- C_INIT
02- C_DATA
03- C_END
3 Service WRITE 01- C_INIT
02- C_DATA
03- C_END
6 Service Alarme 01- C_ALARM_SEND
02- C_ALARM_ACK_RSP
03- C_ALARM_IND
04 - C_ALARM_ACK_IND
10 Service Management 0 - C_TO_RELEASE
Avec numéro d‟équipement (wEquip ) 1 - C_TO_CONNECT
de 0 à 126 2 - C_GOTO_LIST_AUTO
3 - C_GOTO_LIST_MAN
4 - C_C_SET_ALARM_MODE
134 - D_GET_MANAGEMENT_MODE
égale à 127 002 - C_GOTO_LIST_AUTO
003 - C_GOTO_LIST_MAN
004 - C_OFFLINE
005 - C_ONLINE
006 - C_RUN
135 - D_GET_NETWORK_MODE
 wNbTx: Number of bytes to transmit to the lpbyBufTx buffer.

 lpbyBufTx: Near pointer to the transmission buffer. Up to 244 bytes of data can be
placed in the transmission message.
 pwNbRx: Near pointer to the number of bytes received. The return value indicates the
number of bytes received, if the variable indicated by pdwStatus is equal to zero.
 lpbyBufRx: Near pointer to the reception buffer. Up to 244 bytes of data can be placed in
the reception message.
 pdwStatus: Near pointer to the 32-bit applicomIO® error status.1
applicomIO® Knowledge base Implementation PROFINET  235

Managment (dwMsgParam = 10)
Equipment Number = 1 to 126
When you use the function « AuWriteReadMsg_io » with wEquip = 1 to 126, the action
of the code operation will be done only to the specified IO-Device.
Equipment number = 127
Numéro Service Code operation (lpbyBufTx [0])

égale à 127 002 - C_GOTO_LIST_AUTO
003 - C_GOTO_LIST_MAN
004 - C_OFFLINE
005 - C_ONLINE
006 - C_RUN
135 - D_GET_NETWORK_MODE
When you use the function « AuWriteReadMsg_io » with wEquip = 127, the action of the
code operation will be done to all configured IO-Device.
 C_TO_RELEASE disconnect all IO-Device in User mode.

 C_TO_CONNECT connect all IO-Device in User mode.
 C_GOTO_LIST_AUTO set all IO-Device in automatic mode.
 C_GOTO_LIST_MAN set all IO-Device in user mode.
OFFLINE/ONLINE/RUN
The function « AuWriteReadMsg_io » allow to manage the channel state:

 OFFLINE The communication interface will not send any frame
down the wire apart from the Remote Ethernet configuration protocol
 ONLINE The communication interface is fully started). It responds to
pings, the identify PROFINET DCP etc. Connections to the IO-
Devices are not established however.
 RUN The interface is fully started and all connections to the IO-
Devices established
Management – IO-Device management
The function « AuWriteReadMsg_io » allow to manage the IO-Device state:

 Automatic mode: Connections/reconnections are entirely managed by
the IO-Controller.
 User mode: Connections/reconnections are controlled by
programming. In user mode, if an IO-Device disconnection occurs,
reconnection is by programming (free messaging).

9. OPC Server
General introduction to OPC

The OPC concept
OPC is a communication standard based on the OLE / COM technology. This technology
constitutes the new means of information exchange recommended by Microsoft between MS-
Windows applications. The COM model is intended to provide an interoperability between software
components developed independently by separate editors. This interoperability is independent of
the development languages used. COM can be considered as a “software bus” providing a “Plug
And Play” function between software modules.
COM is based on a Client/Server architecture, independent of the development language used, but
“C++ oriented”. In effect, it is a protocol based on function calls through interfaces exposed by
objects. An interface is in fact a grouping of logically interconnected functions.
What is OPC?
OPC is in fact only the specification of a standard. This standard describes the set of objects and
their interfaces which any “OPC server” must implement so as to provide greater interoperability
between checking/control/supervision applications, for industrial equipment (API, sensors,
actuators) and automated office management applications.
The OPC concept is based on the client / server architecture of the COM model. The same client
application can call upon a number of “OPC servers” simultaneously and the servers can be located
either on the local machine or on remote machines (through DCOM, that is, distributed COM).
Characteristics of the applicomIO® OPC server

®
The applicomIO OPC server is based on the version 2.05A specifications of the OPC foundation
(but supports the 1.0A specification). It supports accesses through the OPC Custom Interface. It
supports all the mandatory interfaces and also the optional interface.
IOPCBrowseServerAddressSpace allows a client to obtain interactively the syntaxes supported by
the server.
The applicomIO® OPC server is identified in the MS-Windows operating system by means of its
ProgID (program identifier):
ProgID “APPLICOMIO.OPCServer” ;
applicomIO® Knowledge base Implementation OPC Server  237

Data type returned by the OPCIO server
The OPCIO server returns the data to the clients in variant form. The following table shows the
different variant types returned by default when the type requested by the client (requested type of
the specification) is set to VT_EMPTY:
Data type Variant type Limits

Min Max
Bit VT_BOOL 0 1
Unsigned byte* VT_UI1 0 255
Signed byte VT_I1 -128 127
Unsigned word VT_UI2 0 65535
Signed word* VT_I2 -32768 32767
32
Unsigned double VT_UI4 0 2
word
31 31
Signed double word* VT_I4 -2 2
38 38
Float VT_R4 -3.402823466 3.402823466
String VT_BSTR
Array VT_ARRAY|**
*These data types can be sent by the server only after modification of the default formats of the
byte, word or double word type variables. This modification is made using the check boxes of the
®
Data format section of the Expert tab of the OPC server parameters of the applicomIO console.
** Can correspond to each of the usable unit types.
The following table shows the variant types returned when using predefined items:
Predefined item Variant type

INPUT VT_BOOL
STATE_WATCHDOG VT_I2
STATE_REPLY VT_I2
GLOBAL_STATUS VT_I2
GLOBAL_DIAG VT_I2
READ_ERROR VT_I2
ADVISE_FAILED VT_I2
STATUS VT_I2
DIAG VT_I2
NB_POINT VT_I4
NB_TOPIC VT_I4

The addition of a display format in the syntax modifies the data type. The following table shows the
variant types used according to the display format:
Format Unit type variant Array type variant

(VT_ARRAY|*)
Data type Type returned Type returned
_A VT_* VT_BSTR Not allowed
_H VT_* VT_BSTR Not allowed
_% VT_* Unchanged Unchanged
_B VT_* Unchanged Unchanged
_S VT_UI1 VT_I1 VT_I1
_S VT_I1, VT_I2, VT_I4 Unchanged Unchanged
_U VT_I1 VT_UI1 |VT_UI1
_U VT_I2 VT_UI2 VT_UI2
_U VT_I4 VT_UI4 VT_UI4
_U VT_U1, VT_U2, VT_U4 Unchanged Unchanged
* Can correspond to any of the usable unit types.
Note:
At the time of adding the item, the client application has the capability of asking for the data in the
type of its choice (by modifying the requested type field). Unit type variants can be modified
without any problem (provided that a conversion is possible). However, array type variants cannot
be modified. It is therefore recommended that the default requested type is left at VT_EMPTY.

Enabling and disabling the Diagnostic mode
When the OPCIO server is first installed, the diagnostic mode is not enabled. To allow access to
the diagnostic mode:
 Open the OPC server parameters configuration box (from the description area tree)
 Select the Parameters tab
 Enable the Allow the server diagnostic view check box.
When the server is next started up, a contextual menu linked to the icon present in the taskbar will
be accessible, and will allow access to the diagnostic mode.
In certain cases, it may be desirable to not display the icon for the OPCIO server in the taskbar. To
do this:
 Switch the console into Expert mode (menu File/Preferences/Expert mode)
 Select the Expert tab
 Disable the Enable OPC icon in taskbar check box.
Note:
It is also possible to force the start-up of the server directly with the diagnostic window. To do this,
the OPCIO server must be started with the /WINDOWS option.

Using generic syntaxes for accessing input/output data
As part of using the OPC server, it is necessary to designate a variable to be accessed through an
item name. The recommended designation method consists of the user declaring the items he is
going to use. This declaration is made simply and quickly from the console, from the item
definition area.
®
However, the applicomIO product also offers the capability of using generic syntaxes. In this
case, no configuration is required. However, it must be clearly understood that the generic syntaxes
include the position of the data item with respect to the memory representation of the complete
equipment (which may be composed of a number of data blocks). If the physical configuration
changes, the supervision application will then require amendment.
There are two generic syntax families:
 standard syntaxes similar to those of the applicom® product
 IEC syntaxes conforming to the IEC 1131 standard
Syntax
Type Access rights
Standard IEC
BI* %I* Input bit READ ONLY
BI* %IX* Input bit READ ONLY
OI* %IB* Input byte READ ONLY
WI* %IW* Input word READ ONLY
DI* %ID* Input double word READ ONLY
FI* %IF* Input floating word READ ONLY
BO* %Q* Output bit READ/WRITE
BO* %QX* Output bit READ/WRITE
OO* %QB* Output byte READ/WRITE
WO* %QW* Output word READ/WRITE
DO* %QD* Output double word READ/WRITE
FO* %QF* Output floating word READ/WRITE
* designates respectively, for discrete and numeric type variables, the position of the item as a bit
or as a byte with respect to the start of the memory representation of the equipment.
For using arrays, simply add a "_" to the syntax followed by the number of data items in the array.
Eg : WO3_5 is an array of 5 words. The first word is at address 3.
When navigating in the usable items (diagnostic mode, OPC type browser, etc.), by default the
generic syntaxes do not appear. To make them appear:
 Switch the console into Expert mode (menu File/Preferences/Expert mode)
 Select the Expert tab
 In the Using OPC server with section, you can then enable the IEC syntaxes or standard
syntaxes check box
Note: It is possible to add display format modification suffixes after a generic syntax (see
knowledge base Display format modification suffixes).

Display format modification suffixes
These suffixes modify the format of the data item returned to the client. All the formats are
exclusive. They are made up of a "_" followed by the sign for the format at the item name.
eg: TOPIC1.MOT0_H
The following table summarizes all the suffixes available:
Format name Meaning

_U Unsigned value
_S Signed value
_A The value will appear in character string format
_H The value will be converted into a hexadecimal character
string
_% The value will be expressed as a percentage between the
minimum and the maximum.
_B The value will be converted to BCD format. If the
conversion cannot be performed, the quality associated
with the data item will be bad.
The following table shows the default formats and the suffixes which can be used according to the
data type:
Format
Data type
Default Permitted
Byte (8 bits) _S All
Word (16 bits) _U All
Double word (32 bits) _S _H _B _% _A
Float (32 bits) _S _A _%
Note:
It is possible to modify the default formats of byte, word and double word type variables using the
check boxes in the Data format section of the Expert tab of the OPC server parameters of the
®
applicomIO console.

Use of "Emergency messages" in CANIO
The following items can be used to handle the information related to the emergency messages.
Item name Meaning

Error_Code WORD representing the error code
Error_Register Byte representing the error register
Error_Field_B1 Byte 1 of the error field
Remarks:
 To use these items, you must use event mode. When an item changes value, the
information is returned directly to the client by event mode.
 A synchronous/asynchronous read can only be carried out in the cache memory. It is
impossible to read in the device directly.
 The successive values of an item are saved in a list until the server transmits them to the
client. This mechanism enables the client to obtain all the values of the item, even if several
emergencies are generated within a very short time.
 By default, it is impossible to have a correct initial value for all these items. Consequently,
during initialization, the OPCIO server assigns an "uncertain" quality for each item, until an
emergency occurs. If this operation should cause a problem, however, you can force an
initial value for these items.
1. In the applicomIO installation directory, edit the file itemdll.ini and change the value of
the key "bEnableUncertainQuality" in section "EMCY_CAN", with value "FALSE".
2. Change the values of "bBitDefaultValue" and "nDefaultValue" in the same section.
The first key sets the initial value of the bit type data, and the second all the other data
types.

Introduction to DCOM with an OPC Server
Introduction to DCOM
What is DCOM?
Com objects, such as the OPC server, do not necessarily have to be on the same machine as the
client. With DCOM (distributed COM), a client can create and use COM objects both on its own
system as well as on other machines. This means that the components of an application can be
spread over the network.
The COM library

A client does not address an object directly to start it or to use it, but goes via the COM library. The
library is part of the operating system. The COM library manages the information in the registry
base for all known COM objects in the system.
Transparency
For the client, the use of a COM object via DCOM or via the local COM mechanisms is completely
transparent. The operating system, via the COM library, manages the object and determines
whether it must be instantiated according to the configuration associated with the object.
Installation
®
When implementing the applicomIO OPC solution you will have to carry out the following
operations:
 Set up a "server station" containing the solution applicomIO® that can be accessed,
either from a local OPC client (running on the machine), or from a remote OPC client (running
on another machine)
 Set up a "client station" and querying a remote station.
Setting up a "server station"

After installation, the applicomIO® OPC server can be accessed by any OPC client running on the
local machine. To check, try to connect to the OPC server from the applicomIO® OPC client utility.
Setting up a “Client station” can be describes by the following sequence:
Windows Firewall
Configuring DCOM
Configuring the applicom OPC Server on the server machine
Setting up a "client station"

The package of the "OPC server" includes a file AppOpcServer.reg allowing the server to be
registered in the client station in the registers database, thus allowing it to be configured in the utility
dcomcnfg.
To register the OPC server, include the file AppOpcServer.reg in the register database by double-
clicking the file.

Setting up a “Client station” can be describes by the following sequence:
Windows Firewall
Configuring DCOM
Windows Firewall
The Windows firewall allows traffic across the network interface when initiated locally, but
by default stops any incoming “unsolicited” traffic. However, this firewall is “exception
based, meaning that the administrator cans specify applications and ports that are
exceptions to the rule and can respond to unsolicited requests.
The firewall exception can be specified at two main levels, the application level and the
port and protocol level. The application level is where you specify which applications are
able to respond to unsolicited requests and the port and protocol level is where you can
specify the firewall to allow or disallow traffic on a specific port for either TCP or UPD
traffic. To make any OPC client/server application work via DCOM, changes need to be
made on both levels.

Configuring the firewall
1. By default the windows firewall is set to “On”. This setting is recommended by

Microsoft and by OPC to give your machine the highest possible protection. For trouble
shooting, you may which to temporarily turn off the firewall to prove or disprove that the
firewall configurations is the source of any communication failure.
Note: if may be appropriate to permanently turn off the firewall If the machine is
sufficiently protected behind a corporate firewall. When turn off, the individual firewall
settings outlined here need not to be performed to allow OPC communication.

2. Select the “Exceptions” tab and add all OPC Clients and Servers to the exceptions list.
Also add Microsoft Management Console (used by the DCOM configuration utility in the
next section) and the OPC utility OPCEnum.exe found in the Windows\System32
Directory.

In the Add a Program dialog, there is a listing of most of the applications on the machine,
but note that not all of them show up on this list. Use the “Browse” button to find other
executables installed on the computer.
Note: Only EXE files are added to the exceptions list. For in-process Clients (DLLs and
OCXs) you will need to add the EXE applications that call them to the list instead.

3. Add TCP port 135 as it is needed to initiate DCOM communications, and allow for
incoming echo requests. In the Exceptions tab of the windows Firewall, click on Add Port.
In the Add a Port Dialog, fill out the fields as follow:
Name: DCOM
Port number: 125

Choose the TCP radio button
DCOM Enhancements
“Service Pack 2 for Windows XP” and Vista has also made some security enhancements to
DCOM; two in particular need to be taken into consideration when using OPC on a
network: First, the default Launch and Access permissions dialogs have been modified to
allow the user to configure .limits on the permissions given to applications using DCOM.
Secondly, for each user now defined in the Launch and Access permissions, both local and
remote access can be explicitly defined.
A brief background on default Launch and Access permissions in DCOM: Launch

permissions define who can launch a COM based application (such as an OPC server) both
over the network or locally. Access permissions define who can access that application
once it has been launched. Applications can get their Launch and Access permissions from
one of three places: they can use explicitly defined setting for their application, they can
use the default permissions or they can set their own permissions programmatically.
Because an application could set its own permissions programmatically, the explicitly
defined or default settings, although set properly, may not be used and therefore the user is
not able to explicitly have control over these settings. To overcome this security flaw,
Microsoft has added “limits” to the DCOM security settings from Launch and Access to
limit the permissions that an application can use. This limit prevents the application from
using permissions beyond what is specified in the DCOM configuration settings. By default
the limits set by “XP Service Pack 2” and Vista will not allow for OPC communications
over the network.

In addition to the new permissions limits, one must now specify if the user or group
specified has permissions locally or remotely (or both). In order for OPC applications to
work over the network with DCOM, the permissions must be set such that remote users can
launch and/or access the OPC servers and clients on the machine.
Configuring DCOM
The program "DCOMCNFG"
Before a client can use a COM object on another machine, the properties of the COM object must
be configured on the client machine and on the remote machine. DCOM and the COM objects used
are configured by using the program supplied with the dcomcnfg system in the
Windows\System32 directory. After starting the program, for example by entering the command
dcomcnfg in the Run dialog box (Start menu), four tabs are available for the DCOM configuration.
Note:
If you reduce the security parameters, you will still have to restart the system so that they are taken
into account.
Caution:
 The screen dumps were made under Windows XP SP2, there may be some slight changes
between screen shoots done with earlier operating system.
Only the tabs which have to be modified are described.
The parameters specified in this documentation simply guarantee that the DCOM protocol can be
started. However, most Windows NT security parameters have been reduced. To obtain a higher
level of security, you must strictly respect a configuration in compliance with the DCOM principles.
For further information, refer to articles Q176799, Q158508 and Q169321 in the "Microsoft
Knowledge Base".

Configuring the general DCOM properties on the server and client machines
Under Windows XP, the utility dcomcnfg takes the following form:
To obtain the general properties configuration box, select the node „My Computer‟ in the tree
under \Console Root\Component Services\Computers\, then choose the Properties option in the
menu with a right click or in the Action menu.

“COM Security” tab
Do not use this tab. The OPC server rights will be set individually later on.
The following default rights can be set to use DCOM. These rights can be set individually for each
object and these default properties will then be ignored.
6. Edit the Limits for Access and Launch

a. Access Permissions. Edit Limits...
You need to check the Remote Access box for the user labeled ANONYMOUS LOGIN in this
dialog.
Note: This setting is necessary for OPCEnum.exe to function and for some OPC Servers and
Clients that set their DCOM 'Authentication Level' to 'None' in order to allow anonymous
connections. If you do not use OPCEnum you may not need to enable remote access to
anonymous users
Type of right Information

Access Permissions The Access Permissions are used to specify for all COM objects the user accounts which can access the
object, in other words, call its methods.
Launch and Activate The Default run rights are used to specify for all COM objects the user accounts which can create a
Permissions new instance of the object.

Launch and Activation Permissions. Edit Limits...
You need to check the remote boxes for the user labeled Everyone in this dialog.
Note: Since Everyone includes all authenticated users, it is often desirable to add these
permissions to a smaller subset of users. One suggested way to accomplish this is to create a
group named .OPC Users. and add all user accounts to this group that will execute any OPC
Server or Client. Then substitute OPC Users everywhere that Everyone appears in these
configuration dialogs.
Edit Default Permissions for Access and Launch

For each user (or group) that participates in OPC communication (e.g. .OPC Users.), make sure
that both the Local Allow and Remote Allow checkboxes are both checked.

Access Permissions per user:
Launch and Activation permissions per user:
“Default properties” tab

The Default properties tab is used to specify the basic DCOM properties.

To use DCOM with the OPC server:
 check Activate distributed COM on this computer
 set the parameters to:
Type of network controller Authentication level ID adoption level

Workgroup (no domain server available for the authentication) None Anonymous
Domain server Connection Identifier
“Default security” tab

The Default security tab is used to specify the rights for the DCOM operations. These parameters
certify that only the clients with the necessary rights can use the server.
Configuring DCOM for an individual OPC Server

Follow these steps to configure DCOM for a specific COM server for OPC communications using
Windows XP Service Pack2:
1. Go to Start -> Run and type DCOMCnfg and click on OK.
2. Click on Component Services under the Console Root to expand it.

3. Click on Computers under Component Services to expand it.
4. Right click on My Computer in the pane on the right and select Properties.
5. Double Click DCOM Config.

6. Select the applicom OPC Server, right click the selection and then click Properties
7. In the server property page select the “security tab”

8. Edit the server permissions settings. Select Customize and click the Edit button.
Now repeat the configuration for OpcEnum.

“Applications” tab
The Applications tab displays all the COM objects available from the machine.
Select the applicom OPC Server and click on the Properties … button to start the configuration of
the parameters specific to the OPC server.

Configuring the applicom OPC Server on the server machine
“General” tab
In the General tab you can change the authentication level of an object.
For the OPC server, leave this property set to default

“Position” tab
The Position tab is used to specify the machine on which the server is started.
On the server station, select Run the application on this computer.

“Identity” tab
The parameters of the Identity tab specify which accounts will be used to check the user's rights on
the object.
Several possibilities are available:
Type Action
Interactive user This is the recommended default choice for the applicom® OPC server.
The user account which opened the current session is used. If, however, no user is logged on the machine,
there is no interactive user and the COM object cannot be created. In this case, select This user.
The running user The user account which started the OPC client is used. This user must then have the necessary rights, and
therefore belong to the Security tab. This mode generally results in the starting of a server instance for
each user running. This option must not be used with the applicom® OPCserver.
This user The user account indicated is used. This user must then have the necessary rights, and therefore belong to
the Security tab. The user must have the default rights allocated to the Users group of the machine, in
other words, must belong to the Users group. This choice must be used for the servers where no user is
logged on.

“Security” tab
You can specify the access rights for the applicom® OPC server from the Security tab. For the
three security aspects used by DCOM, you can either:
use the default rights
In this case, the account configured in the Identity tab must have the necessary rights in the Default
security tab (default access rights, default run rights).
use customized rights for the selected object
If you do not want a particular user to be able to access all COM objects available, you must use
customized rights.
To work with the OPC server, only the access rights and the run rights have to be configured:

Choose Use customized access rights
Press Modify and set the following rights:
Then choose Use customized run rights

Note:
On the server machine as well as on the client machine, the accounts of the two persons logged on
must exist.
Example: The A user is logged on the machine hosting the server and the B user is logged on the
machine hosting the client. To use DCOM, a B account must exist on the server station (with the
same password as on the client machine) and an A account must exist on the client station (with
the same password).
If you work with a domain, you are recommended to use a group including the user accounts. The
rights are then managed from the domain server.

Configuring the applicom OPC Server on the client machine
For the client part, the following screen dumps propose a simple configuration to use the
®
applicom OPC server via DCOM
“General” tab

“Location” tab

“Identity” tab
In the Identity tab you can specify the user account which will be used for the client machine. It is
logical to specify Interactive user, in other words, the user logged on the machine.

“Security” tab

Access type: Allow access
Access type: Authorize start

OPC Client in the Form of a Service
This article proposes a configuration possible allowing access to the OPC server from an OPC
client running as Windows service.
The program “DCOMCNFG”
Start the DCOMCNFG program in “Windows\System32” directory, for example by typing the
“dcomcnfg” command in the Run box of the Start menu. Four tabs are available.
Remark
Under Windows XP, the DCOM configuration utility DCOMCNFG is slightly different from that
present on a Windows 2000 or NT4 workstation. Refer to paragraph “DCOM configuration”
The Applications tab

The Applications tab displays all the COM objects available on your system.
Select applicom OPC Server.

Press the Properties button. A new properties box then opens, in order to configure the OPC
server.

“Identity” tab
This tab is used to indicate the identity of the person whose rights will be tested by the system when
accessing the COM object.
Choose This user

Enter the name and password of a user with administration rights on the machine.

“Security” tab
This tab is used to define which users have the right to load the OPC server and access it.
Choose Use customized access rights

Then choose Use customized run rights

Caution:
The screen dumps were made on a French Windows 2000 station. They may be different on
another system.


Knowledgebase

Uploaded by

Copyright:

Available Formats

Knowledgebase

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Knowledgebase

Uploaded by

Copyright:

Available Formats

applicomIO®

a product of Woodhead Software & Electronics

applicomIO® Knowledge base Implementation <Table of Contents  i

4. DeviceNet ................................................................................................ 121

ii  <Table of Contents applicomIO® Knowledge base Implementation

5. EtherNet/IP ............................................................................................. 156

6. Modbus on Ethernet .............................................................................. 182

applicomIO® Knowledge base Implementation <Table of Contents  iii

7. Profibus DP............................................................................................. 197

8. PROFINET ............................................................................................. 234

9. OPC Server ............................................................................................. 237

iv  <Table of Contents applicomIO® Knowledge base Implementation

applicomIO® Knowledge base Implementation <Table of Contents  v

Coexistence of applicom® / applicomIO® Products

applicomIO® 1.1 applicomIO® 1.2

applicomIO® Knowledge base Implementation Installation and Cabling  1

1 : Male 10-pin HE13 connector for connection to the CANOPEN network

2  <Table of Contents applicomIO® Knowledge base Implementation

1 : Male 10-pin HE13 connector for connection to the Profibus network

applicomIO® Knowledge base Implementation Installation and Cabling  3

4  <Table of Contents applicomIO® Knowledge base Implementation

1 : Male 10-pin HE13 connector for connection to the DeviceNet network

applicomIO® Knowledge base Implementation Installation and Cabling  5

1 : Male 9-pin subD connector for connection to the CANopen network

6  <Table of Contents applicomIO® Knowledge base Implementation

applicomIO® Knowledge base Implementation Installation and Cabling  7

8  <Table of Contents applicomIO® Knowledge base Implementation

1 : Female Sub D 9-pin connector for connection to the Profibus network.

applicomIO® Knowledge base Implementation Installation and Cabling  9

1: Female Sub D 9-pin connector for connection to the Profibus network.

10  <Table of Contents applicomIO® Knowledge base Implementation

applicomIO® Knowledge base Implementation Installation and Cabling  11

12  <Table of Contents applicomIO® Knowledge base Implementation

1: Female Sub D 9-pin connector for connection to the Profibus network.

applicomIO® Knowledge base Implementation Installation and Cabling  13

1 : 5-point connector for connection to the DeviceNet network

14  <Table of Contents applicomIO® Knowledge base Implementation

applicomIO® Knowledge base Implementation Installation and Cabling  15

16  <Table of Contents applicomIO® Knowledge base Implementation

1 : RJ45 connector for connection to the Ethernet network.

applicomIO® Knowledge base Implementation Installation and Cabling  17

18  <Table of Contents applicomIO® Knowledge base Implementation

Rear of the board

For PC/104 Boards

20  <Table of Contents applicomIO® Knowledge base Implementation

Installing the Ferrite

applicomIO® Knowledge base Implementation Installation and Cabling  21

The pinout of the board's male HE13 connector is as follows:

The wiring must be made according to the following diagram :

22  <Table of Contents applicomIO® Knowledge base Implementation

Cable length and transmission rate:

Transmission Rate Maximum Length of the Bus

applicomIO® Knowledge base Implementation Installation and Cabling  23

This line interface is galvanically insulated (insulation voltage: 500V).

24  <Table of Contents applicomIO® Knowledge base Implementation

The adaptation is supplied in Profibus standard connectors.

Cable length and transmission rate:

Baud Rate in kbits/s Distance in m

applicomIO® Knowledge base Implementation Installation and Cabling  25

1 : 0V (electrical ground - black)