IXXAT Cataloge 2007 08

Your Partner for Communication
IXXAT GmbH
Headquarter
Products and Services 2007 | 2008

IXXAT Inc.
Distributors
Products and Services
Further information about our distributors
can be found on our website www.ixxat.de for Industry and Automobile
CAN, FlexRay, LIN
CANopen, DeviceNet
SAE J1939
Distributed by
Gestaltung: Andrea Schnitzer, D-Ravensburg
ETHERNET Powerlink
EtherNet/IP
PROFINET
IEEE 1588
2007 | 2008
IXXAT . Leibnizstr. 15 . D-88250 Weingarten IXXAT Inc. . 120 Bedford Center Road . Bedford, NH 03110 IXXAT . Leibnizstr. 15 . D-88250 Weingarten IXXAT Inc. . 120 Bedford Center Road . Bedford, NH 03110
Tel.: +49-(0)751/5 6146 -0 . Fax: +49-(0)751/5 6146 -29 Phone: +1 / 603 / 471- 0800 . Fax: +1 / 603 / 471- 0880 Tel.: +49-(0)751/5 6146 -0 . Fax: +49-(0)751/5 6146 -29 Phone: +1 / 603 / 471- 0800 . Fax: +1 / 603 / 471- 0880
Internet: www.ixxat.de · e-mail: info@ixxat.de Internet: www.ixxat.com · e-mail: sales@ixxat.com Internet: www.ixxat.de · e-mail: info@ixxat.de Internet: www.ixxat.com · e-mail: sales@ixxat.com
Automotive Industrial
IXXAT – SERVICES 07
CAN INTERFACES 10
REPEATER 29
CAN GATEWAYS/BRIDGES 33
CANANALYSER 40
CAN DIAGNOSTIC TOOLS 49
CANOPEN 54
DEVICENET 76
ETHERNET POWERLINK 81
ETHERNET/IP 95
IEEE 1588 100
PROFINET 102
TCP/IP 105
SAE J1939 107
LIN 110
FLEXRAY 113
ACCESSORIES 118
SEMINARS 121
LITERATURE 122
Contents
New Products 6 CAN DIAGNOSTIC TOOLS
IXXAT – SERVICES CANcorder MMC 49

CANcheck 51
IXXAT – Partnering with our customers in the CAN-Bus-Tester (CBT) 52
development of innovative solutions 7
Services 8 CANOPEN
Quality Management ISO 9001 certified 9
CANopen Introduction 54
Product Overview CANopen 56
CAN INTERFACES CANopen Protocol Software 57
CANopen Manager Software 60
Overview PC/CAN Interfaces 10 CANopen RealTime Software 62
CAN Driver for Windows (VCI) 14 CANopen Maritime Software 64
Version 2 of the VCI driver 15 CANopen Master API 66
CAN Driver for Linux and VxWorks 16 CANopen Manager API 67
CAN Layer 2 OPC-Server 17 CANopen ConfigurationStudio 69
PC-I 04/PCI 18 CANopen Configuration Framework 72
PC-I 04/104 18 CANopen Device Manager 73
iPC-I 320/PCI II 19 CANopen EDS Editor 75
iPC-I 320/104 20
iPC-I XC16/PCI 21 DEVICENET
iPC-I XC16/PCIe 22
iPC-I XC16/PMC 22 DeviceNet Introduction 76
iPC-I 165 23 Produkt Overview DeviceNet Software and Tools 77
tinCAN161 24 DeviceNet Slave Protocol Software 78
USB-to-CAN compact 25 DeviceNet Master & I/O Scanner Toolkit 79
USB-to-CAN II 26 ODVA DeviceNet Conformance Test Driver 80
CAN@net II/VCI 27 DeviceNet Client API 80
CANblue/VCI 28
REPEATER ETHERNET POWERLINK
Repeater Introduction 29 ETHERNET Powerlink Introduction 81

CAN-Repeater 30 Product Overview ETHERNET Powerlink 82
CAN-CR200 31 ETHERNET Powerlink CN Protocol Software 83
CAN-CR220 31 ETHERNET Powerlink MN/CN Protocol Software 85
FO-Repeater 32 ETHERNET Powerlink Safety Introduction 87
ETHERNET Powerlink Safety Protocol Software 88
ETHERNET Powerlink PCI & cPCI Interface 90
CAN GATEWAYS AND BRIDGES ETHERNET Powerlink/CANopen-Gateway 91
ETHERNET Powerlink Module 92
CAN Gateway Introduction 33 ETHERNET Powerlink Configuration Framework 93
CANbridge 34
CANmodem/CANopen 35
CAN@net II/Generic 36 ETHERNET/IP
CANlink II 37
LIN2CAN 38 EtherNet/IP Introduction 95
CANblue/Generic 39 EtherNet/IP Scanner Software 96
EtherNet/IP Scanner Developers Kit (ESDK) 96
CANANALYSER EtherNet/IP Scanner Communication Driver (EIPS) 96
EtherNet/IP Adapter Software 97
canAnalyser 40 EtherNet/IP Adapter Developers Kit (EADK) 97
canAnalyser-lite 45 EtherNet/IP Adapter Communication Driver (EIPA) 97
CANopen Module 46 EtherNet/IP Scanner Simulation Test Tool (EIPScan) 98
DeviceNet Module 47 EtherNet/IP Adapter Module 99
J1939 Module 48
4
IEEE 1588 PTP
IEEE 1588 PTP Introduction 100

IEEE 1588 PTP Protocol Software 101
PROFINET
PROFINET Introduction 102

PROFINET IO-Developer’s Kit 103
PROFINET IO-Device Module 104
TCP/IP
NicheStack IPv4 & NicheLite TCP/IP 105

NicheStack IPv6 & NicheStack Dual IPv4v6 106
Add-ons 106
SAE J1939
SAE J1939 Introduction 107

SAE J1939 Protocol Software 108
LIN
LIN Introduction 110

LIN2CAN 111
USB-to-CAN II Automotive 112
FLEXRAY
FlexRay Introduction 113

Multibus Analyser for FlexRay 114
FlexRay CCM 116
Analyse & rest bus simulation of FlexRay networks 117
ACCESSORIES
CAN Accessories 118

FlexRay Accessories 120
SEMINARS
Standard Seminars and -Workshops 121

In-House Seminars 121
LITERATURE
Literature 122
All labels and product names noticed in the catalog are protected registered trade marks of their
individual owners. Specifications subject to change without notice. Errors and misprints excepted.
5
New Products
CANcheck CANopen Device Manager
The new CANcheck allows a simple test of CAN networks during The CANopen Device Manager is a versatile and upgradeable tool
start-up, troubleshooting and maintenance. The battery-operated aimed at device test, diagnostics and field service tasks. Build
hand-held device is connected to the CAN network to be tested and around a central component that manages the CANopen services
operated via a cursor keys and a graphic LCD display. The scope of and also serves as the primary entry point for network definition,
supply includes all tests that are important for testing and com- the CANopen Device Manager covers functionality like NMT node
missioning CAN systems, such as a wiring test when the network is and error control, SDO client, PDO producer and consumer, SYNC
switched off and an operational test when the network is in ope- and time stamp producer, concise DCF download and firmware
ration, a test of the resistances between all pins of the CAN connector, download according to CiA 302 and LSS master according to CiA 305.
a terminal resistance test and measurement of the signal level. In
addition, the cable length, the baud rate and the bus load of a
system can be determined. All identifiers transmitted in a system
can be scanned and displayed. It is also possible to display the error
frames received per time unit.
Industrial Ethernet Module for ETHERNET

Powerlink, EtherNet/IP and PROFINET
iPC-I XC16/PCIe
The "Industrial Ethernet Module" from IXXAT enables fast, low-cost
Intelligent CAN interface for PCI express bus systems connection of devices to ETHERNET Powerlink, EtherNet/IP and
PROFINET. The module is based on an Altera-FPGA and contains the
The iPC-I XC16/PCIe represents a very powerful and economic CPU (NIOS II), an Ethernet Controller and an integrated 2-port hub,
solution for an active CAN board with two CAN channels, covering which is routed out via an RJ45 connector. Depending on the ver-
a wide range of industrial and automotive CAN applications. In sion, the relevant protocol software for the implementation of an
combination with the CAN driver (VCI, part of delivery) the iPC-I ETHERNET Powerlink controlled node, a PROFINET device or an
XC16/PCIe allows an easy integration of PC supported CAN appli- EtherNet/IP adapters is already implemented on the module.
cations. In addition the iPC-I XC16/PCIe is well suited for use with
the IXXAT analysis and configuration tools.
PROFINET Protocol Software

With the PROFINET Development Kit IXXAT enables simple implemen-
tation of PROFINET IO devices according to the PROFINET standard in-
cluding real-time (RT) operation support. PROFINET RT uses the
possibility of prioritization and optimization of the protocol stack to
enable high-performance data transmission with standard compo-
nents of automation technology. On request, IXXAT also offers imple-
mentation of PROFINET in customer-specific devices.
6
IXXAT – Partnering with our customers in the
development of innovative solutions
IXXAT is one of the leading suppliers of communication solutions for
automation and automotive technology.
We want to achieve our main objective – establishing long-term

partnerships with our customers – by providing them with innova-
tive products and by maintaining the highest possible standards for
the quality of our services and products. To this end, we continually
invest in the research and development of new technologies and
products.
For many years, quality management has been a hallmark of both

our ongoing work and projects in development. We provide con-
stant training to our employees to insure their familiarity with the
latest technological advancements. And we complement this trai-
ning with a singular commitment to project management to further
promote the success of our customer relationships.
Employees
60
60 Company building IXXAT
55
50 51
45 In our core competence – the development of hardware compo-

40 42 nents, software and systems for communication – our range of ser-
38
34
vices includes the development and manufacture of micro-
30
30 controller-based hardware components as well as the development
28
of real-time and PC-based software (Windows, Linux). On request,
20
20
22 we will also handle long-term maintenance and management of
15 16
the hardware and software we’ve developed for customer-specific
10 11 11 solutions.
7
5
3 The expansion of our technological expertise is also reflected by the
0
88 89 90 91 92 93 94 95 96 97 98 99 00 01 02 03 04 05
continual growth of our product range. In the current catalog and
Our increase in employees reflects our corporate growth on our webpage, you will find a series of new products which will
enable us in the months ahead to further expand our already im-
pressive range of PC-interfaces, topology components, analysis tools
Our success is based on almost two decades of successful project and protocol stacks.
development for customers both at home and abroad. As a pioneer
of CAN technology, we have made major contributions to the suc-
cessful growth of the CAN protocol in a large number of applicati-
ons and fields, and, have been actively involved in the development
of important elements of CAN technology (e.g. the development of
the CANopen standard). Today, complete system solutions from
IXXAT are used by many companies in a variety of industries around
the world.
For our automotive customers, we have implemented a variety of

different protocols and have successfully performed a large number
of development projects involving tools and devices for CAN, LIN
and FlexRay.
Our primary applications in the field of industrial communication Prof. Dr.-Ing. Konrad Etschberger Dipl.-Ing. Christian Schlegel
systems involve solutions based on CAN (CANopen, DeviceNet) and
Ethernet (ETHERNET Powerlink, EtherNet/IP), as well as TCP/IP with Founder of the IXXAT Managing Director of the
the associated Internet protocols. Automation GmbH IXXAT Automation GmbH
7
Services
OVERVIEW OUR SERVICES
In addition to our exceptional products, Ixxat also offers develop- Consulting, system design and training
ment services for automation, automotive technology, transporta- We offer you advice on all technical matters concerning our primary
tion, and medical technology. technologies. On request, we will draw up concepts and solutions,
or develop system specifications in close cooperation with you. For
We develop hardware and software as well as embedded systems’ your employees, we also offer tailor-made in-house training courses.
solutions based on our core technologies in the following areas:
Hardware development
Hardware components and embedded systems solutions We are familiar with all of the major microcontroller families, PC
Communication protocols (industrial, automotive) interface standards and communication interfaces, – this enables us
Configuration and service tools to either develop customer specific hardware components and de-
Software for vehicle control units vices or to modify our products according to customer require-
Gateway solutions ments. On request, we will also handle serial production.
Test and inspection equipment
Software development for embedded systems
We strive to create long-term partnerships with our customers. We For many years, we have been developing powerful, reliable soft-
typically supervise the products and projects of our customers ware solutions for microcontrollers with different capabilities. This
throughout their entire life cycle. This enables our customers to be- experience provides us with the applied expertise needed to properly
nefit from the extensive investments we make in new technologies. address the special requirements of embedded systems, real-time-
This also includes the benefits generated from our participation in and memory-critical system solutions, and, the use of real-time
the development of communication standards that result directly operating systems.
from our membership in various associations and our participation
on industry committees. Software development for PC/Windows
We are experts in the development of PC-based software solutions
One of our primary objectives at IXXAT is to provide our customers for user and visualization interfaces as well as for service, testing
with a competitive advantage by offering them the support requi- and control systems. This also includes the connection to databank
red to enable them to launch their products quickly. For this reason, systems as well as to Intranet or Internet.
we continually strive to achieve high quality development results
within the given time and cost frame. This results from efficient, Development of testing and diagnosis devices
actively-practiced quality management with ISO 9001:2000 certi- In addition to the dedicated development of hardware or software
fied development and production processes complemented by ex- components, we also develop complete testing and diagnosis devi-
ceptionally attentive project management. ces for remote maintenance, data recording and analysis, etc.
Customers using our development services include BMW, Airbus,

Siemens, Schneider Electric, ThyssenKrupp, WAGO, Bosch and Daimler-
Chrysler.
TECHNOLOGIES & KNOW-HOW
Basic Software Embedded Devices Test & Service Safety PC Software

Driver Interface Boards Test/ Analyzing Tools SW Development Measurement
Solutions Board-Support-SW Gateways Test Systems according to Visualization
Protocol Software CPU-Boards Service Tools IEC/EN61508 Configuration
User Interfaces Remote Maintenance
PC-based OS Embedded OS
Operating Systems Windows NT / 2000/ XP, Linux VxWorks, Linux, Windows CE and others
Industrial Automotive Wireless Ethernet / Internet

CAN CAN / J1939 / CCP Bluetooth TCP/IP
Data Communication CANopen / DeviceNet ISO15765 / KWP2000 GSM / GPRS IEEE1588
ETHERNET Powerlink K-Line, LIN WLAN Webserver, E-Mail
EtherNet/IP, PROFINET FlexRay XML
PC Interface Technology Microcontroller FPGA Technology

Hardware PCI, PCI express, cPCI, ARM, Infineon, Freescale, Atmel, Altera
PMC, USB, PC card, PC/104 Renessas, Intel, STMicroelectronics (VHDL, IP-Cores)
8
Quality Management ISO 9001 certified
IXXAT's ISO 9001 certification confirms our successful aspiration to

an active and qualified usage of our quality management system
and the advantages for our customers resulting from it.
9
Overview PC/CAN Interfaces
The IXXAT PC/CAN interfaces enable PC applications to access CAN in the industrial sector that values the longevity of its products.
networks with a singular variety of different PC interface standards. Today, function-compatible alternatives still exist, even for boards
The customer can select an optimum PC/CAN interface according already developed in 1990. Almost all boards are available from
to the application, performance requirement or required unit costs. stock and can be supplied within a short time frame.
More than 10 different PC interface standards are supported, and
for many of which, we offer several different CAN boards. The com- Despite the wide variety of PC/CAN interfaces, all IXXAT interfaces
plete IXXAT PC/CAN interface product range was developed, and can be operated with the hardware-independent, common VCI
will continue to be developed exclusively by IXXAT, so that we can driver (Virtual CAN Interface). Therefore, it is very easy to switch
maintain complete control over production, product maintenance between CAN boards. Even future technologies are already being
and product life cycle. This criterion is an important one, especially "integrated" today.
OVERVIEW PC/CAN INTERFACES
Cardname Technic PC-access Microcontrollersystem CAN Controller Bus interface Certification

Passive CAN Interfaces
PC-I 04/PCI PCI Memory mapped passiv up to High-Speed CE, CSA/UL
2 x SJA 1000
PC-I 04/104 PC/104 Memory mapped passiv up to High-Speed CE, CSA/UL
2 x SJA 1000
Aktive CAN Interfaces
iPC-I 320/PCI II PCI DPRAM memory 8 Bit up to High-Speed CE, CSA/UL,
mapped 2 x SJA 1000 FCC
iPC-I 320/104 PC/104 DPRAM memory 8 Bit 1 x SJA 1000 High-Speed CE, CSA/UL
mapped
iPC-I XC16/PCI PCI (3,3 V DPRAM memory 16 Bit 1 x TwinCAN High-Speed CE, CSA/UL,
and 5 V) mapped (2 x CAN) and optional FCC
Low-Speed
(switchable via
software)
iPC-I XC16/PCIe PCI express DPRAM memory 16 Bit 1 x TwinCAN High-Speed CE, FCC
mapped (2 x CAN)
iPC-I XC16/PMC PMC DPRAM memory 16 Bit 1 x TwinCAN Switchable CE, FCC
mapped (2 x CAN) High/Low
speed interface
iPC-I 165 ISA DPRAM memory 16 Bit up to High-Speed CE, CSA/UL
mapped 2 x SJA 1000
CAN@net II/VCI Ethernet 10/100 MBit/s 32 Bit 1 x SJA 1000 High-Speed CE, FCC, CSA/UL
Ethernet
10
Cardname Technic PC-access Microcontrollersystem CAN Controller Bus interface Certification
Mobile CAN Interfaces
tinCAN 161 PCMCIA DPRAM memory 16 Bit 2 x SJA 1000 High-Speed CE
mapped and Low-Speed
USB-to-CAN II USB V2.0 USB 16 Bit 2 x SJA 1000 High-Speed CE, CSA/UL,
(full speed) and Low-Speed FCC
USB-to-CAN USB V2.0 USB 16 Bit 1 x SJA 1000 High-Speed CE, CSA/UL,
compact (full speed) FCC
CANblue/VCI Bluetooth Bluetooth 16 Bit 1 x SJA 1000 High-Speed CE
For custom applications requiring fully integrated PC/CAN inter- RoHS

faces, we also offer hardware and software licensing of our inter- Since July 1, 2006, IXXAT has delivered all products in accordance
face technologies. with the RoHS directive. Products for which conversion was not
possible have been discontinued. Whenever possible, IXXAT has pro-
vided replacement products for all discontinued products, making
QUALITY OF OUR HARDWARE the transition as seamless as possible.
IXXAT is certified according to ISO 9001:2000. Our goal is to gua- ElektroG (WEEE)
rantee the high quality of the products that we provide to our cus- According to the EU law, IXXAT is registered at the EAR foundation
tomers. Therefore, all IXXAT CAN boards are tested 100 %, i.e., every in Fürth. Because of this, all IXXAT components which are distributed
single board is checked "with a fine-tooth comb" before it leaves exclusively in the B2B area were registered.
our company.
Our registration number at EAR: 29724241
CE CERTIFICATION AND CSA APPROVAL

SUPPORTED PHYSICAL CAN BUS STANDARDS
The IXXAT PC/CAN interface boards fulfill the currently valid EMC di-
rective 89/336/EEC and are CE-certified in accordance with the fol- High Speed bus connection according to ISO 11898-2
lowing standards (these can vary according to the interface used, All CAN boards are available as standard with an on-board CAN bus
see manual): interface according to ISO 11898-2 (high-speed). The Philips 82C251
or the Texas Instruments SN65HVD251 chip is used as the transcei-
EN 61000-6-2 (immunity, industrial interference immunity) ver. Connection to the CAN network is generally made via a Sub-D-9
EN 61000-4-2 (air discharge 8kV, contact discharge 4kV) plug-in connector according to CiA-DS102. Versions with alternative
EN 61000-4-3 (electromagnetic field compatibility 80MHz- plug-in connectors (e.g. RJ45) can be supplied on request.
1GHz, 10V/m)
EN 61000-4-4 (transient distortion factor, burst, bus line1kV) Selected CAN boards can be equipped with alternative CAN bus inter-
EN 61000-4-6 (HF current compatibility 150kHz-80MHz, 10V) faces in the form of a piggyback board or as a separate assembly
EN 55022 (class B, interference emission, trade and small option for each CAN channel.
industrial sector)
Other available bus connections are:
In addition, almost all IXXAT PC/CAN interface boards have CSA ap-
proval for USA and Canada (equivalent to UL approval). Low-speed bus connection (fault-tolerant) according to
ISO 11898-3
For some CAN boards, a CAN low-speed bus connection based on
ROHS AND WEEE the CAN transceiver TJA 1054 is available either as an option or is
integrated and activated by software.
On 27th January 2003, binding European directives were agreed
upon for the restriction of hazardous substances – these took effect
permanently on July 1, 2006. GALVANIC ISOLATION
The main aim of the directive is to restrict substances that are harm-
ful to both the environment and to one’s health. This regulation di- The CAN bus connection is available as an option with galvanic iso-
rectly affects the following materials: lead, cadmium, hexavalent lation. Galvanic isolation is achieved by means of opto couplers or
chrome, mercury, PBB (polybrominated biphenyls), PBDE (polybro- magnet couplers and DC/DC converters on the board, and therefore,
minated diphenyl ethers). does not require an external power supply.
11
ACTIVE AND PASSIVE CAN INTERFACES If, on the other hand, the PC is only to be used for the configuration
of CAN components, for example, which is generally carried out via
CAN boards can basically be divided into two groups: a small number of CAN messages, the performance of a passive
board is completely sufficient.
Passive CAN boards
These boards require direct access of the PC driver to the CAN con- The active CAN boards from IXXAT are available with various micro-
troller of the board. The PC must configure and operate the CAN controllers. The standard CAN boards are equipped with the 8-bit
controller. MC DALLAS DS80C320. This microcontroller belongs to the 8051
family but has three times faster command processing and is clocked
Active ("intelligent") CAN boards with 22 MHz. For most applications with low to medium average
These boards have an independent microcontroller system. In addi- message rates such as applications based on the VCI-CAN driver,
tion to configuration of the CAN controller, the microcontroller can these CAN boards are also sufficient.
also perform time-critical tasks such as the transmission, reception
and filtering of CAN messages, can provide received messages with For applications with higher requirements on the communication
time-stamps, and, can process higher protocols such as CANopen or process, IXXAT supplies active CAN boards with 16-bit microcontrol-
DeviceNet. lers of the Infineon C16x or XC family. Due to the larger memory
and higher execution speed, even two CAN networks with high baud-
Today PCs are at least 100 times faster than the microcontrollers rate and high bus load can be operated and monitored. These boards
used on the CAN boards. Nevertheless, the use of CAN boards with can also perform the function of a CANopen master, even for net-
their own microcontrollers makes sense because of the following works with many nodes.
two consideration:
CAN controllers have only very limited buffering capacities for SOFTWARESUPPORT
received messages. In the worst case, a CAN message is received
approx. every 50 µs. Depending on the CAN controller used, only IXXAT supports its CAN boards with a wide variety of powerful soft-
a few or only one message can be buffered. This results in a high ware packages. In addition to the standard CAN driver software,
real-time requirement of the host PC for the reaction of the CAN these also include development, analysis and configuration tools, as
interrupt which must always be guaranteed in order to prevent well as program libraries for higher layer protocols.
a loss of messages.
CAN drivers for Windows
The very short processing time for reading out and passing on a The delivery specification of every IXXAT CAN board includes the
CAN message (copying of approx. 12 bytes) is a contrast to the universal CAN driver "Virtual CAN Interface" (VCI) for Windows
slow context switch of the PC operating system which is triggered 2000/XP. This powerful CAN driver package supports all CAN boards
by a CAN interrupt. Despite its excellent processing power, this (also passive boards), regardless of their PC interface, with a uniform
quickly results in a very high load for the PC. programming interface (API). This means that applications based on
VCI-API can be used with all IXXAT CAN boards without modifying
Especially for non-deterministic operating systems such as Micro- the application program.
soft Windows, these aspects can cause a problem with high trans- The VCI CAN driver also contains a simple CAN bus monitor which
mission rates and/or high levels of data traffic. By using powerful enables transmission and reception of CAN objects in a CAN system.
active CAN boards, the load on the PC can be relieved or the time-
critical requirements can be reduced. For applications with higher As is typical with Windows, the IXXAT CAN boards are installed con-
requirements in terms of data traffic and deterministic processing veniently and safely via the Windows device manager.
of the CAN messages, the use of active boards is always recommen-
ded, since variable factors such as the performance of the PC, the VxWorks and Linux
number and type of additionally installed boards and drivers and For the VxWorks and Linux operating systems, IXXAT provides the
the number of executed programs (e.g. hard disk accesses) do not BCI driver (Basic CAN Interface). The BCI supports the active and
guarantee a deterministic access to CAN networks. passive (only Linux) ISA and PCI boards.
Active CAN boards also offer the following additional advantages: CAN-OPC-Server
The CAN-OPC server enables simple connection of OPC clients
By pre-filtering CAN messages already on the CAN board, only (SCADA programs) to CAN systems. As the CAN-OPC server works
relevant messages are forwarded to the PC. Since messages are on CAN layer 2, it can be used with various CAN-based protocols in
no longer filtered by the PC program, the interrupt load of the the automotive and automation sectors.
PC decreases.
With the VCI, independent cyclic transmission of CAN messages

by the microcontroller is supported. CAN messages can be trans-
mitted on CAN networks under real-time conditions indepen-
dent of the PC.
12
LabView and LabWindows CANopen
For the standard visualization interfaces LabView and LabWindows, The CANopen Master API enables PC access to CANopen systems via
IXXAT provides free, fully functional integration examples based on the active CAN boards from IXXAT (PCI, USB, PC104, ISA, PCMCIA).
the VCI CAN driver. Here, all important functions for transmitting Based on this software package, powerful Windows based control,
and receiving CAN messages are fully supported. The IXXAT CAN in- test and service programs can be developed quickly and easily.
terface boards can be operated directly under LabView and Lab-
Windows with minimal adaptation work. If required, the integration
examples can be quickly adapted to specific customer requirements.
SOFTWARESUPPORT
BCI for Linux and VxWorks
VCI Driver for Windows
Labview / Lab-Windows
32 Bit Driver for ODVA

Conformance Test SW
Interface board
IXXAT Tools
OPC-Server
CANopen
Passive CAN Interfaces

PC-I 04/PCI 2000, XP x/– x – x/x x –
PC-I 04/104 in preparation x/– x – in preparation x –
Active CAN Interfaces
iPC-I 320/PCI II 2000, XP x/x x x x/x x x
iPC-I 320/104 in preparation x/x x x in preparation x –
iPC-I XC16/PCI 2000, XP x/– x x x/x x –
iPC-I XC16/PCIe 2000, XP –/– x – x/x x –
iPC-I XC16/PMC 2000, XP x/– x x x/x x –
iPC-I 165 – x/x x x x/x x x
CAN@net II – via Generic x in preparation in preparation x –
Version (*1)
Mobile CAN Interfaces
tinCAN 161 2000, XP – x x x/x x –
USB-to-CAN II 2000, XP – x x x/x x –
USB-to-CAN 2000, XP – x x x/x x x
compact
CANblue – via Generic x – in preparation x –
Version (*2)
*1) The Linux- and VxWorks connection is made by a TCP/IP soket interface,
which provides all necessary CAN functions.
*2) The connection is made by using Bluetooth SPP communication, which

has to be supported by the operating system. The serial ASCII protocol pro-
vides all necessary CAN functions.
13
CAN Driver for Windows
DeviceNet Module
J1939 Module
CANopen Module
(VCI)
Powerful driver software with generic programming VCI
interface for all IXXAT PC-CAN interface cards Application
miniMon
canAnalyser
OVERVIEW VCI V3 Application Programming Interface

User Mode
With the VCI, IXXAT presents the third generation of its proven CAN Kernel Mode
driver based on the successful VCI concept. The driver provides a VCI V3 System Service
uniform programming interface that is independent of both the
card type and the PC interface technology, and thus allows for the Device Driver Device Driver Device Driver
tinCAN161 USB-to-CAN II iPC-I XC16/PCI
use of all IXXAT CAN cards without having to adapt the application
software.
The VCI is designed as a system server and allows simultaneous

access of several applications to one or more CAN controllers of one CAN-Bus
or more PC interfaces. Moving all important functions to the kernel
optimizes the real-time-compatibility of the VCI driver.
The user interface is designed as a "C" Port that offers all necessary
functions for CAN-based applications. In addition to the "C" Port, SUPPORT OF LABVIEW
the VCI offers a .net API and therefore, can be used with all Wind-
ows .net languages and scripts (e.g. C#). The use of IXXAT CAN interface cards in connection with the test
and programming system Labview® from National Instruments is
Communication with the CAN interface card occurs via message supported by a VI library.
channels. A message channel consists of one transmit and one re-
ceive FIFO. Message channels can be created exclusively or coope-
ratively. If message channels are created cooperatively for a certain FURTHER FUNCTIONS OF THE VCI-CAN DRIVER
CAN controller, the data of that CAN controller is distributed equally
to the various message channels. The receive FIFO of a message Convenient card installation via the Windows device manager
channel supports the access methods "event-controlled" and "pol- Prepared dialog for selection of the installed cards simplifying
ling" where a FIFO fill level mark can be defined to trigger an event. integration into the users' applications
In addition, specific message filtering can be carried out for each Management functions for start-up and testing of the PC/CAN
CAN controller. The CAN messages are read out from the receive interface card
FIFO with status and time stamp of the time of reception. Automatic download of the firmware with active cards directly
from the driver, thus making simple firmware updates possible
In addition to the standard transmit method, intelligent cards (cards Standard (11-bit identifier, CAN 2.0A) and extended protocol
with their own microcontroller system) support extended transmit (29-bit identifier, CAN 2.0B)
functions such as the transmission of messages with a time delay, Detection and display of error frames on the bus
with which the message flow can be controlled via a transmit inhi- Measurement and display of the bus load (only with active
bit time, or cyclic on-board transmission, with which high bus loads CAN cards)
and exact cycle times of messages can be generated. Also available Reception of self-transmitted messages (self-reception),
are incrementing functions which can alter the transmit data. possible operation in "Listen only mode"
Cyclic transmission of CAN messages (only with active cards)
The VCI supports a plug & play notification system by which both
the insertion and the removal of CAN interfaces is automatically
detected and processed. This makes it possible to remove devices
while a VCI application is running.
14
SIMPLE INSTALLATION OF THE CAN CARDS Version 2 of the VCI driver
The CAN cards are installed in accordance with the Windows stan-
dard. During installation, the data of the installed CAN card is en- In addition to the VCI V3 driver, IXXAT continues to offer its proven
tered in the registry. VCI V2 driver which supports all interfaces listed in the catalog,
including those with older operating systems (such as Windows
NT/98/Me).
AVAILABLE VERSIONS
The VCI driver version 3 is available for Windows 2000/XP. Older

Windows operating systems will be supported by the version 2 of
the VCI driver.
It is also possible for CAN cards and CAN modules of other vendors
to be supported by the VCI CAN driver. Please ask us if you are in-
terested in this capability.
FREE CAN MONITOR „MINIMON“
For both simple testing purposes and for start-up of the PC inter-
faces, a free CAN monitor (miniMon) is installed with the VCI. This
monitor can be used to display CAN messages with time stamp,
message identifiers and data. A logging function enables the data
received to be recorded directly to hard disk. CAN messages are
transmitted via a list in which CAN messages are entered. Installed
interfaces are displayed with the available CAN controllers, the cur-
rent bus load and the controller status.
CONTENT OF DELIVERY
VCI
CAN monitor "miniMon"
Demo programs in C, C#
Installation and programming manual
15
CAN Driver for Linux SUPPORTED PC/CAN CARDS
and VxWorks Card Linux VxWorks

iPC-I 320/PCI x x
iPC-I 320/104 x x
CAN Driver for IXXAT ISA, PCI and PC104 CAN
iPC-I 165 (ISA) x x
boards
iPC-I XC16/PCI x –
PC-I 04/PCI x –
OVERVIEW PC-I 04/104 x –
With the BCI (Basic CAN Interface), selected active and passive ISA,
PCI, PC/104 CAN boards from IXXAT are supported under the Linux
and VxWorks operating systems. The driver simultaneously supports SUPPORTED OPERATING SYSTEMS
two CAN channels per CAN board and up to four (also different)
CAN boards in one PC. The BCI features a simplified user interface, Linux kernel version 2.4 or higher
but, nevertheless, provides all necessary mechanisms for convenient VxWorks
operation of the CAN boards.
CONTENTS OF DELIVERY
Messages are transmitted and received via queues, with a separate
transmit and receive queue available for each CAN channel. The Availability of the product on request
messages received can be processed either via interrupts or by pol- Driver for Linux or VxWorks as source code
ling. For interrupt processing, two different operating modes are Sample program in C
available: the "latency" mode enables short reaction times to recei- Programming manual
ved messages, while the "throughput" mode guarantees maximum
data throughput. If active boards are used, the messages received
are already provided with a time-stamp and can be pre-filtered by SUPPORT OF OTHER OPERATING SYSTEMS
the CAN interface via programmable software and firmware filters.
The software structure of the CAN driver is designed for simple
The Linux version of the CAN driver is implemented as a loadable adaptation to other operating systems. All OS-specific functions
kernel module. and interfaces are combined centrally in one module, so that the
remaining code is OS-independent.
FUNCTIONS OF THE CAN DRIVER
Transmission and reception of CAN messages via queues

"Polling" or "interrupt" modes optimized to "latency" or
"throughput" for receive queues
Programmable firmware filters for message reception
(only on the active boards)
Programmable software filters in the BCI driver for message
reception
Standard (11-bit identifier, CAN 2.0A) and extended protocol
(29-bit identifier, CAN 2.0B)
Automatic download of firmware directly from the BCI library,
simple software updates are thus possible (active boards only)
Baud rates up to 1 Mbaud
Support of up to 4 CAN boards with 1 or 2 CAN controllers
(Philips SJA1000)
16
CAN Layer 2 The IXXAT CAN layer 2 OPC server fulfills the OPC specification Data
Access Version 2.0, although OPC clients are also supported accor-
OPC-Server ding to specification V1.0 or V1.0a.
The delivery specification also includes a simple OPC client which

Standardized Interface for SCADA Programs displays received CAN data and thus allows for simple testing of
the OPC server after installation and first steps with the OPC tech-
nology.
OVERVIEW
By using specific hardware interfaces in PC applications (e.g. visua- SYSTEM REQUIREMENTS

lization or control programs), relevant drivers often had to be ad-
apted or created again. The open interface standard OPC represents PC with operating system Windows 98, Me, NT(SP5), 2000, XP
a data communication interface and considerably simplifies this in- IXXAT CAN interface board with Philips SJA1000
tegration step. OPC stands for "OLE for Process Control" and is based VCI version 2
on the Microsoft Windows OLE/COM technology. Many applications,
including all common visualization programs (SCADA programs),
support the OPC interface. CONTENTS OF DELIVERY
OPC-Server software with single-user license

OPC Client OPC Client Editor for project database
(Visualisation) (Office Application)
Simple OPC client for functional tests
User manual
CAN Layer 2 OPC-Server

ORDER NUMBER
VCI V2 Project
Database 1.02.0170.00000 CAN Layer-2 OPC-Server
Device Driver Device Driver Device Driver

CAN
The OPC server from IXXAT is based on VCI and connects all IXXAT
PC/CAN interface cards to SCADA programs. As the OPC server
works directly on CAN layer 2, it is not restricted to a certain higher
CAN protocol (such as CANopen or DeviceNet) and can be used, in
principle, with every standardized or user-specific CAN protocol of
the automation and automotive sectors. The data is transmitted
between the OPC server and the OPC client on the level of single
layer 2 CAN messages.
DESCRIPTION OF THE FUNCTIONS
The data interface of the OPC server is described via a project da-
tabase, in which the interpretation instructions for the CAN mes-
sages are entered with the aid of an editor (also supplied).
The OPC server can also be extended by further filters for data im-
port, allowing for the generation of a project database for a system
from existing system descriptions. An import filter for CANopen DCF
files is supplied, from which the required additional elements for
transmission and reception of CANopen PDOs can be automatically
generated. The OPC name space is formed automatically by reading
a project database.
17
PC-I 04/PCI PC-I 04/104
Passive CAN interface for PCI bus systems Passive CAN interface for PC/104 bus systems
This is a passive CAN board (no microprocessor on board) for the

PC/104 bus with up to two CAN channels. It represents a very eco-
This is a passive board (no microprocessor on board) for the PCI bus nomic solution for connecting a PC to a CAN network in applicati-
with up to two CAN channels. It represents a very economic solution ons where there are low performance requirements.
for connecting a PC to a CAN network in applications where there
are low performance requirements. TECHNICAL DATA
TECHNICAL DATA PC bus interface PC/104 bus, 8 Bit

PC address range C000h-FFC0h (memory mapped), adjustable
PC bus interface PCI Bus (specification 2.1), 32 Bit, 33MHz, 5V in 1 kB steps
PC address range Plug & Play, 1024 bytes memory mapped and Interrupts IRQ 3, 4, 5, 6, 7, 9, 10, 11, 12, 14, 15 separated for
128 bytes I/O area each CAN controller, shared interrupt, edge/level
Interrupts INT A, Plug & Play mode
Microcontroller None Microcontroller None
CAN controller Up to two Philips SJA 1000 CAN controller Up to two Philips SJA 1000
CAN bus interface ISO/IS 11898-2, Sub D9 connector according to CAN bus interface ISO/IS 11898-2, bent 2 x 5 pin connectors accor-
DS 102, optional galvanic decoupled ding to DS 102, optional galvanic decoupling
Power supply 5 V DC, 300 mA typ., provided by PC Power supply 5 V DC, 150 mA typ., provided by PC
Temperatur range -20 ºC to +70 ºC Temperatur range -20 ºC to +70 ºC
Certification CE, CSA/UL Certification CE, CSA/UL
Size Approx. 95 x 125 mm Size Approx. 90 x 96 mm
ORDER OPTIONS ORDER OPTIONS
Galvanic decoupling Galvanic decoupling
CONTENTS OF DELIVERY CONTENTS OF DELIVERY
PC/CAN interface card, manual PC/CAN interface card and manual

CAN driver VCI for Windows 2000, XP CAN driver VCI for Windows 2000, XP
Simple CAN monitor "miniMon" Simple CAN monitor "miniMon"
ORDER NUMBER ORDER NUMBER
1.01.0057.10100 PC-I 04/PCI, 1 x SJA1000 CAN controller, 1.01.0070.10100 PC-I 04/104, 1 x SJA1000 CAN controller,
1 x CAN interface 1 x CAN interface
1 x CAN interface, 1 x galvanic decoupled 1 x CAN interface, 1 x galvanic decoupled
2 x CAN interface 2 x CAN interface
2 x CAN interface, 2 x galvanic decoupled 2 x CAN interface, 2 x galvanic decoupled
18
iPC-I 320/PCI II ORDER OPTIONS
Intelligent PC/CAN interface for PCI bus systems Galvanic decoupling
PC/CAN interface card and manual

CAN driver VCI for Windows 2000, XP
Simple CAN monitor "miniMon"
ORDER NUMBER
1.01.0039.10100 iPC-I 320/PCI II, 1 x SJA1000 CAN controller,

1 x CAN interface
1 x CAN interface, 1 x galvanic decoupled
2 x CAN interface
This is an active CAN board with one or two CAN channels that is
appropriate for use in a wide variety of CAN applications. The inter-
face is cutting-edge because of its support of the PCI bus which al-
lows an installation via Plug & Play. Filtering, preprocessing, and
transmission and time stamped storage of the CAN messages are
just some of the features offered by the on-board microcontroller.
In combination with the universal CAN driver (VCI, part of delivery),
the iPC-I 320/PCI II allows an easy integration of PC supported CAN
applications. Offering an exceptional combination of functionality
and value, it is perfectly suited for high-volume productions. In ad-
dition, the iPC-I 320/PCI II is also well-suited for use with the IXXAT
analysis and configuration tools.
TECHNICAL DATA
PC bus interface PCI bus (2.1), 32 Bit, 33 MHz, 5 Volt

PC address range Plug & Play, 8 kB memory mapped and 128 Bytes
I/O-area
Interrupts INT A, Plug & Play
Microcontroller Dallas DS80C320, 22.1184 MHz
Memory extension 128 kByte SRAM, 128 kByte Flash, 4 kByte DPRAM
CAN controller Up to two Philips SJA 1000
CAN bus interface ISO/IS 11898-2, Sub D9 connector according
to DS 102, optional galvanic decoupling
Power supply 5 V DC, 300 mA typ., provided by PC
Temperature range 0 ºC to +70 ºC
Certification CE, FCC, CSA/UL
Size Approx. 124 x 97.5 mm
19
iPC-I 320/104 ORDER OPTIONS
Galvanic decoupled
Intelligent CAN interface for PC/104 bus systems

ORDER NUMBER
1.01.0043.10100 iPC-I 320/104, 1 x SJA1000 CAN controller,

1 x CAN interface
1.01.0043.10200 iPC-I 320/104, 1 x SJA1000 CAN controller,
This is an active CAN board with one CAN channel that is appro-
priate for a wide variety of CAN applications. Filtering, preproces-
sing, transmission and time-stamped storage of the CAN messages
are just some of the features offered by the on-board microcon-
troller. In combination with the universal CAN driver (VCI, part of
delivery) the iPC-I 320/104 allows for the easy integration of PC-
supported CAN applications. Offering exceptional functionality and
value, it is perfectly suited for high-volume productions.
TECHNICAL DATA
PC bus interface PC/104 bus, 8 bit

PC address range C000h-FE00h (memory mapped), adjustable
in 8 kB steps
Interrupts IRQ 3, 4, 5, 6, 7, 9, 10, 11, 12, 14, 15
Microcontroller Dallas DS80C320, 22,1184 MHz
Memory extension 2 x 64 kByte SRAM, 2 x 64 kByte Flash,
4 kByte DPRAM
CAN controller 1 x Philips SJA 1000
CAN bus interface ISO/IS 11898-2, bent 2 x 5 pin connector accor-
ding to DS 102, optional galvanic decoupling
Temperature range -40 ºC to +85 ºC
Certification CE, CSA/UL
Size Approx. 90 x 96 mm
20
iPC-I XC16/PCI ORDER OPTIONS
Galvanic decoupling
Intelligent CAN interface for 5 V and 3.3 V PCI bus High-/Low-speed interface, switchable via software
systems with optional Low Speed bus interface

CAN driver VCI for Windows 2000/XP
ORDER NUMBER
1.01.0047.33110 iPC-I XC16/PCI, 2 x internal CAN,

2 x CAN interface High-Speed
1.01.0047.33220 iPC-I XC16/PCI, 2 x internal CAN,
2 x CAN interface High-Speed, galvanic decoupled
1.01.0047.33260 iPC-I XC16/PCI, 2 x internal CAN, 2 x CAN interface
High/Low-Speed, galvanic decoupled
Covering a wide range of industrial and automotive CAN applica-

tions, this is a powerful and economic solution for an active CAN
board with two CAN channels. The interface is state-of-the-art,
supports PCI, and can be easily installed by Plug & Play. Some of
the features offered by the on-board microcontroller include filte-
ring, preprocessing, transmission and time stamped storage of the
CAN messages.
Due to the powerful microcontroller, both CAN controllers can ope-
rate simultaneously without losing any data, even in systems with
a high bus load. In combination with the CAN driver (VCI, part of de-
livery), the iPC-I XC16/PCI allows for the seamless integration of
PC- supported CAN applications. In addition, the iPC-I XC16/PCI is
well-suited for use with the IXXAT analysis and configuration tools
and as a CANopen network controller.
TECHNICAL DATA
PC bus interface PCI-Bus (2.2), 32 Bit / 33 MHz, 5 Volt or 3.3 Volt

PC address range Plug & Play, 16 kB memory mapped and
128 bytes I/O area
Interrupts INT A, Plug & Play
Microcontroller Infineon XC161, 40 MHz
Memory extension 512 kByte SRAM, 128 kByte FLASH, 8 kByte
DPRAM
CAN controller Internal TwinCAN module (two CAN channels)
CAN bus interface ISO/IS 11898-2 according to DS 102, Sub D9 con-
nector, optional galvanic decoupling and high-/
low-speed bus interface (ISO/IS 11898-3) switchable
via software
Power supply 5 V DC, 100 mA typ.; 3.3 V DC, 120 mA typ.
21
iPC-I XC16/PCIe iPC-I XC16/PMC
Intelligent CAN interface for PCI express bus systems Intelligent CAN interface for 5 V and 3.3 V PMC
bus systems with Low Speed bus interface
Covering a wide range of industrial and automotive CAN applicati-

This is a powerful and economic solution for an active CAN board ons, this is a powerful and economic solution for an active CAN
with two CAN channels. The interface is state-of-the-art, supports board with one or two CAN channels. The interface is state-of-the-
PCI express, and can be easily installed by Plug & Play. Some of the art, supports PMC and can be easily installed by Plug & Play. Some
features offered by the on-board microcontroller include filtering, of the features offered by the on-board microcontroller include fil-
pre-processing, transmission and time-stamped storage of the CAN tering, pre-processing, transmission and time-stamped storage of
messages. Due to the powerful microcontroller, both CAN control- the CAN messages. Due to the powerful microcontroller, both CAN
lers can operate simultaneously without losing any data even in sy- controllers can operate simultaneously without losing any data
stems with a high bus load. In combination with the CAN driver even in systems with a high bus load. In combination with the CAN
(VCI, part of delivery), the iPC-I XC16/PCIe allows for the seamless driver (VCI, part of delivery), the iPC-I XC16/PMC allows for the se-
integration of PC- supported CAN applications. In addition, the iPC- amless integration of PC-supported CAN applications.
I XC16/PCIe is well-suited for use with the IXXAT analysis and con-
figuration tools, and, for use as a CANopen network controller. TECHNICAL DATA
TECHNICAL DATA PC bus interface PMC Bus (2.2), 32 Bit / 33 MHz, 5 Volt or 3.3 Volt
Memory range Plug & Play, 16 kB memory mapped and
PC bus interface PCIe (r1.0a), x1 link (2,5 Gbps per direction) 128 bytes I/O area
PC address range Plug & Play, 16 kB memory mapped and Interrupts INT A, Plug & Play
128 bytes I/O area Microcontroller Infineon XC161, 40 MHz
Interrupts INT A, Plug & Play On board memory 512 kByte SRAM, 128 kByte FLASH, 8 kByte DPRAM
Microcontroller Infineon XC161, 40 MHz CAN controller Internal TwinCAN module (two CAN channels)
Memory extension 512 kByte SRAM, 128 kByte FLASH, 8 kByte CAN bus interface ISO/IS 11898-2 and ISO/IS 11898-3, Sub D9 con-
DPRAM nector according to DS 102, galvanic decoupled
CAN controller Internal TwinCAN module (two CAN channels) and high-/low-speed bus interface switchable
CAN bus interface ISO/IS 11898-2 high-speed, Sub D9 connector via software
according to DS 102, Galvanic decoupled Power supply 5 V DC, 100 mA typ.; 3.3 V DC, 120 mA typ.
Power supply 12 V DC, 60 mA typ.; 3.3 V DC, 200 mA typ. Temperature range -20 ºC to +70 ºC
Temperature range 0 ºC to +70 ºC Certification CE, FCC
Certification CE, FCC Size Approx. 74 x 149 mm single CMC
PC/CAN interface card and manual CAN driver VCI for Windows 2000/XP
CAN driver VCI for Windows 2000/XP Simple CAN monitor "miniMon"
ORDER NUMBER
ORDER NUMBER
1.01.0049.33660 iPC-I XC16/PMC, 2 x internal CAN controller,
1.01.0053.33220 iPC-I XC16/PCIe, 2 x internal CAN, 2 x CAN 2 x High/Low-speed bus interface,
interface High-Speed, 2 x galvanic decoupled 2 x galvanic decoupled
22
iPC-I 165 ORDER OPTIONS
Galvanic decoupled
Intelligent CAN interface for ISA bus systems

ORDER NUMBER
1.01.0045.10200 iPC-I 165, 1 x SJA1000 CAN controller,

2 x CAN interface
This is a powerful and economic solution covering a wide range of

CAN applications requiring an active CAN board with one or two
CAN channels. Some of the features offered by the on-board micro-
controller include filtering, preprocessing, transmission and time
stamped storage of the CAN messages. Due to the powerful micro-
controller, both CAN controllers can operate simultaneously without
losing any data, even in systems with a high bus load.
In combination with the CAN driver (VCI, part of delivery), the iPC-
I 165 allows an easy integration of PC supported CAN applications.
In addition, the iPC-I 165 is well-suited for use both with the IXXAT
analysis and configuration tools and as a CANopen network con-
troller.
TECHNICAL DATA
PC bus interface ISA-Bus, 16 Bit

PC address range C000h-FE00h (memory mapped), adjustable
in 16 kB steps
Interrupts IRQ 3, 4, 5, 7, 9, 10, 11, 12, 14, 15
Microcontroller Infineon SAB C165, 20 MHz
Memory extension 512 kByte SRAM, 512 kByte Flash, 8 kByte DPRAM
CAN controller Up to two Philips SJA 1000
CAN bus interface ISO/IS 11898-2, Sub D9 connector according to
DS 102, optional galvanic decoupling
Temperatur range 0 ºC to +50 ºC
Certification CE, CSA/UL
23
tinCAN161 CONTENTS OF DELIVERY

Intelligent CAN Board for PC-Card Bus Systems CAN driver VCI for Windows 2000/XP
(PCMCIA) Simple CAN monitor "miniMon"
ORDER NUMBER
1.01.0026.00020 tinCAN161 – with one High-Speed and one High-/

Low-Speed bus interface, 2 x galvanic decoupled
This powerful active CAN board comes with two CAN channels in a
PC-card format.
It has a high-speed and a high-/low-speed bus interface switchable
via software and therefore, is ideal for use in the industrial and auto-
motive sector.
The 16-bit microcontroller system of tinCAN161 enables filtering,
pre-processing and saving of received CAN messages with time-
stamp, even under high bus loads.
With the universal CAN driver VCI also included in the delivery,
tinCAN161 also allows simple integration of PC-supported appli-
cations in CAN systems. In conjunction with the canAnalyser, it is
the ideal solution for a powerful mobile tool for analysis, start-up
and configuration of CAN systems.
TECHNICAL DATA
PC bus interface PC card version 4 (PCMCIA), 16-bit board

PC address range Plug & Play
Interrupts Plug & Play
Microcontroller Infineon SAB C161, clocked with 25 MHz
Memory extension 1 MByte SRAM, 512 kByte Flash, 8 kByte DPRAM
CAN controller 2 x Philips SJA 1000
CAN bus interface 1 x ISO/IS 11898-2, 1 x 11898-2 / 11898-3
switchable, 2 x Sub D9 connectors according to
DS 102, galvanically decoupled
Power supply 5 V DC, typically 400 mA, provided by PC
Certification CE
Size PC card type II, bus connection in external
housing, 54 x 86 x 5.5 mm
24
USB-to-CAN compact ORDER OPTIONS
Galvanic decoupled
Intelligent low-cost CAN interface
for the USB-Port
VERSIONS
With Sub D9 plug according to DS102

With RJ45 plug according to DS102
CAN interface, user’s manual

ORDER NUMBER
1.01.0087.10100 USB-to-CAN compact (with SUB-D9 plug)

The USB-to-CAN compact is a low-cost, active CAN module for 1.01.0087.10200 USB-to-CAN compact, with galvanic isolation
connection to the USB bus. The 16-bit microcontroller system en- (with SUB-D9 plug)
ables reliable, loss-free transmission and reception of messages in 1.01.0088.10100 USB-to-CAN compact (with RJ45 plug)
CAN networks with both a high transmission rate and a high bus 1.01.0088.10200 USB-to-CAN compact, with galvanic isolation
load. In addition, messages are provided with a time-stamp and can (with RJ45 plug)
be filtered and buffered directly in the USB-to-CAN compact. The
module can also be used as a master assembly, e.g. for CANopen
systems. Together with the universal CAN driver VCI supplied with
the delivery, the USB-to-CAN compact allows the simple integration
of PC-supported applications into CAN systems.
Combining an extremely attractive price with compact construc-

tion, the USB-to-CAN compact is ideal for use in series products
and in conjunction with the canAnalyser for development, service
and maintenance work.
TECHNICAL DATA
PC bus interface USB, Version 2.0 (full speed)

Microcontroller Infineon C161U, 24 MHz
Memory extension 128 kByte RAM, 512 kByte Flash
CAN controller Philips SJA 1000, 10 kBit/s to 1 MBit/s
CAN bus interface ISO/IS 11898-2, Sub D9 connector or RJ45 con-
nector according to DS 102, galvanically decou-
pled as an option
Power supply Provided by USB port, 250 mA typ
Size Approx. 80 x 45 x 20 mm
25
USB-to-CAN II ORDER OPTIONS
Automotive/Industrial Version
Intelligent CAN/LIN Interface for the USB Port Galvanic decoupling
CAN module, user’s manual

ORDER NUMBER
1.01.0062.11110 USB-to-CAN II – Industrial Version

1.01.0062.11220 USB-to-CAN II – Industrial Version
with galvanic isolation
1.01.0066.11220 USB-to-CAN II – Automotive Version
This active interface offers two CAN channels and one LIN channel
(automotive version) for connection to the USB bus.
With its powerful 16-bit microcontroller system, the interface allows

filtering, pre-processing and saving of received messages. Transmis-
sion and reception processes can be controlled loss-free even with
a high transmission rate and bus load.
Together with the universal CAN driver VCI also supplied with the
delivery, the USB-to-CAN II module allows for the simple integra-
tion of PC-supported applications into CAN systems. In conjunction
with the canAnalyser from IXXAT, USB-to-CAN II is a convenient,
mobile analysis and development tool. The interface can also be
used as a master assembly, e.g., for CANopen systems with many
subscribers.
TECHNICAL DATA
PC bus interface USB, version 2.0 (full speed)

Microcontroller Infineon 161u, 36 MHz
CAN controller Two Philips SJA 1000
CAN bus interface 2 x RJ45 connector with RJ45 on Sub-D9 adapter
line (10 cm), galvanically decoupled as an option
Industrial version: 2 x ISO/IS 11898-2
Automotive version: 1 x ISO/IS 11898-2,
1 x ISO/IS 11898-2 and 11898-3 switchable via
software, 1 x LIN master/slave switchable via
software (VCI V3)
Power supply 5 V, 400 mA max. via USB
Size 98 x 55 x 20 mm
26
CAN@net II/VCI CONTENTS OF DELIVERY
CAN@net II/VCI, user’s manual

Intelligent CAN Adapter with Ethernet Interface CAN driver VCI for Windows 2000, XP
ORDER NUMBER
1.01.0086.10200 CAN@net II/VCI – Intelligent CAN module

with Ethernet interface
The CAN@net II allows simple, flexible access from a PC to CAN

systems via Ethernet. Because of its ability to support the TCP/IP
protocol, the CAN@net II allows for worldwide direct connection
to a PC, implementation in an LAN, or, communication with the
gateway via the Internet. The main area of application of the
CAN@net II is to provide remote access to CAN systems requiring
both service and remote maintenance.
With the VCI CAN driver included in the delivery, the CAN@net II
can be operated in the same way as all IXXAT CAN PC interface boards.
Therefore, all VCI-based CAN-programs and tools can be run with
the CAN@net II. The VCI CAN driver is also capable of communica-
ting via a PC with up to 128 CAN@net II devices simultaneously.
In addition to the CAN@net II/VCI, IXXAT also offers the CAN@net II/
Generic interface, which is addressed via a standard TCP/IP socket
interface. This makes it possible to connect CAN@net II to any pro-
cessor and operating system platforms (see also CAN@net II/Generic
interface in the section "CAN gateways").
TECHNICAL DATA
Ethernet-Interface 10/100 Mbit/s Ethernet (10-Base T/100-base T),

Autodetect, Connector RJ45, Auto crossover
IP address allocation DHCP, via PC tool
Microcontroller Freescale MCF5235, 150 MHz
Memory extension 8 MByte DRAM, 4 MByte Flash
CAN controller 1 x SJA1000
CAN bus interface ISO/IS 11898-2, Sub D9 connector according to
DS102, galvanically decoupled
Power supply 9-32 V DC, 3 W
Size 22.5 x 100 x 115 mm
Housing Plastic housing for top hat rail mounting
Certification CE, FCC, CSA
27
CANblue/VCI CONTENTS OF DELIVERY
CANblue module and user’s manual

Intelligent CAN Module with Bluetooth Interface CAN driver VCI for Windows 2000, XP
Simple CAN tool "miniMon"
ORDER NUMBER
1.01.0125.00000 CANblue/VCI
The CANblue/VCI is a CAN module that is connected to the PC

wirelessly via Bluetooth. It is ideal for servicing and accessing CAN
systems that are otherwise difficult to access.
Depending on the space limitations, the maximum distance bet-

ween the CANblue and the PC/notebook can be up to 100 m.
Because it is supported by the VCI CAN driver, the CANblue/VCI can

be operated with all IXXAT tools and with customer-specified pro-
grams. In addition, wireless access to CAN systems via Bluetooth
can also be easily achieved with existing VCI-based application pro-
grams and tools.
TECHNICAL DATA
Bluetooth interface Bluetooth specification V2.0, Class 1 / +16,9 dBm

(49 mW), 100m
Microcontroller Infineon C161U, 36 MHz
Memory extension 256k Flash, 128k RAM
CAN bus interface ISO/IS 11898-2 (High Speed) and ISO/IS11898-3
(Low-Speed), switchable, Sub D9 plug according
to DS102, galvanic decoupled
Power supply 9-30 V DC, 2.5 W
Housing Stable metal housing
Certification CE
28
Introduction Repeater
10m 10m
Repeaters are used to establish a physical coupling of two or more
segments of a CAN bus system. They can be used to implement tree
or star topologies as well as for long drop lines. In addition, network
segments can be electrically decoupled using a galvanically isolated
repeater. 3 4 7
The lines coupled by the repeater are independent electric segments
that can be optimally terminated in terms of signals. In this way 50m 50m 50m
topologies can be implemented that are not possible with a pure
line of the bus due to electrical reflections. 2 5 8
According to the transceiver output capacities, the division of a CAN
system into several subsystems, connected via CAN repeaters, in-
creases the maximum number of bus nodes.
As signaling is not directed in CAN, the repeater logic has to trans-

1 6 9
late the signals of the segment received into the other and has to
ensure that the input signals are not back-coupled. In terms of si- Conventional bus structure
gnals, the repeater corresponds to a line with relevant delay time. The distance between the two nodes
Therefore, it cannot be used to extend a CAN system. furthest apart (1/9) is 220 meters
Using repeaters does not influence the real-time behavior of a sy- 10m 10m
stem because in terms of transmission behavior it corresponds to a
network that consists only of lines.
Repeater
Another application of repeaters is the coupling of different physical 40m
CAN layers by means of high/low-speed repeaters, optical repeaters,
or optical star couplers.
The repeaters offered by IXXAT have an additional monitoring 3 4 7

function. Connected network segments that are disturbed by per-
manent dominant levels are detected and automatically disconnec-
50m 50m 50m
ted, thus allowing the remaining network to continue functioning
normally. After the fault has been eliminated, the operation of a
disconnected segment is detected and the segment is automatically 2 5 8
reconnected to the network.
IXXAT also offers the repeater technology for licensed integration

into customer hardware.
1 6 9
Extended structure with drop line

The distance between the two nodes
furthest apart (1/6 or 6/9) is 150 meters
29
CAN-Repeater CONTENS OF DELIVERY
CAN-Repeater, Quick reference

ISO/IS 11898-2 CAN Repeater
(with Low-Speed Option)
OPTIONAL
1x ISO/IS 11898-3 Low-Speed Businterface

Further options on request
ORDER NUMBER
1.01.0064.44000 CAN-Repeater (2 x ISO/IS 11898-2)

1.01.0064.46000 CAN-Repeater (ISO/IS 11898-2 to ISO/IS 11898-3)
The CAN Repeater is used for the galvanic isolation of two segments
of a CAN network and for creating star or tree topologies. One special
feature of the Repeater is that it can separate a defective segment
from the rest of the network so that the remaining network can
continue working. After elimination of the defect, the segment is
switched into the network again.
As an option, the Repeater can also be equipped with a low-speed

bus interface in accordance with ISO/IS 11898-3, allowing operation
of the Repeater as a high/low-speed converter. Its galvanic isolation
isolates both CAN segments from each other as well as from the
power supply.
TECHNICAL DATA
Display Transmit (2 green LEDs), defective segment

(2 red LEDs)
CAN bus interface ISO/IS 11898-2 with CAN choke. Terminals (CAN-
High, CAN-Low, CAN-GND). CAN 1, CAN 2 and
power supply are galvanic isolated against each
other. CAN termination resistors are integrated
(can be disabled).
Baudrate Up to 888 kbps
Delay 200 ns (corresponds ~40 m (~120ft.) bus length)
Power supply 9-35 V DC, 1.5 W typ., through terminals
Housing, size Plastic enclosure, 110 x 75 x 22 mm
30
CAN-CR200 CAN-CR220
Modular ISO/IS 11898-2 CAN Repeater ISO/IS 11898-2 CAN Repeater with 4 kV
Galvanic Isolation
The CAN-CR200 is used for the galvanic isolation of two segments The CAN-CR220 is used for the galvanic isolation of two segments
of a CAN network and for creating star or tree topologies. Several of a CAN network and offers a very high galvanic isolation of 4 kV,
CAN-CR200 can be connected to a CAN-hub via the integrated allowing it be utilized in medical applications. One special feature of
backbone bus. One special feature of the Repeater is the automatic the Repeater is the automatic recognition and separation of a de-
recognition and separation of a defective segment from the rest of fective segment from the rest of the network so that the remaining
the network so that the remaining network can continue working. network can continue working. After elimination of the defect, the
After elimination of the defect, the segment is switched into the segment is switched into the network again.
network again. The galvanic isolation isolates the CAN segments from each other
as well as from the power supply.
The galvanic isolation isolates the CAN segments from each other
as well as from the power supply. The CAN-CR220 is tested according DIN/EN 50178 (DIN VDE 0160:
1988-05 and DIN VDE 0160/A1: 1989-04).
TECHNICAL DATA
TECHNICAL DATA
Display Transmit and defective segment (three duo LEDs),
Power (one LED) Display Transmit and defective segment (two duo LEDs),
CAN bus interface ISO/IS 11898-2 with CAN choke. Two Sub-D9 Power (one LED)
connectors and one backbone bus. CAN 1, CAN 2, CAN bus interface ISO/IS 11898-2 with CAN choke. Two Sub-D9 con-
backbone bus and power supply are galvanic iso- nectors. CAN 1, CAN 2 and power supply are
lated against each other. CAN termination resistors galvanic isolated against each other. Galvanic iso-
are integrated (can be disabled). lation 4 kV/1 second, 2.5 kV/60 seconds. CAN ter-
Baudrate Up to 888 kbps mination resistors are integrated (can be disabled).
Delay 200 ns (corresponds ~40 m (~120ft.) bus length) Baudrate Up to 888 kbps
Power supply 9-32 V DC, 1.5 W typ., through terminals Delay 200 ns (corresponds ~40 m (~120ft.) bus length)
Temperature range -20 °C to +70 °C Power supply 9-32 V DC, 1.5 W typ., through terminals
Housing, size Plastic enclosure, 22.5 x 100 x 115 mm Temperature range -20 ºC to +70 ºC
Housing, size Plastic enclosure, 22.5 x 100 x 115 mm
CAN-CR200, Quick reference
CAN-CR220, Quick reference
ORDER NUMBER
ORDER NUMBER
1.01.0067.44010 CAN-CR200
1.01.0067.44400 CAN-CR220
31
FO-Repeater CONTENS OF DELIVERY
FO-Repeater, Quick reference

Converter from ISO/IS 11898 to fiber optic cable
OPTIONAL
Extended galvanic isolation of both CAN lines from the supply

voltage
FOC connection with ST plug
Additional options are available upon request
ORDER NUMBER
1.01.0063.01010 CAN Fiber Optic Repeater – Glas fiber version

with F-SMA connector
1.01.0063.01020 CAN Fiber Optic Repeater - Glas fiber version
with ST connector
The FO Repeater is used for the conversion of the CAN-signal from

copper wire (ISO/IS 11898-2) to fiber optic cables. This allows com-
plete isolation and protection against EM-influences to be achieved.
One special feature of the Repeater is that it can separate a defec-

tive segment from the rest of the network so that the remaining
network can continue working. After elimination of the defect, the
segment is switched into the network again
TECHNICAL DATA
Display Sending (2 green LEDs), defective segment

2 red LEDs)
CAN bus interface ISO/IS 11898-2, Terminals (CAN-High, CAN-Low,
CAN-GND). CAN termination resistors are integra-
ted (can be disabled).
FOC connection 2 x F-SMA or ST terminals for duplex line
(Glass 50/125 µm duplex)
Baudrate Up to 888 kbps
Delay ~300 ns (translates into ~60 m (~90ft.) bus length)
between the wire connection of a FO Repeater
through the fiber optic cable to the wire connec-
tion of a second FO Repeater (not including the
signal delay time of the fiber optics between the
two repeaters, which is ~5ns/m)
Power supply 9-35 V DC, 3 W typ., through terminals
Temperature range 0 °C to +60 °C
Housing, size Plastic enclosure, 110 x 75 x 22 mm
(without FO connector)
32
CAN Gateway Introduction
CAN bridges and CAN gateways are infrastructure components with
which complex network structures can be implemented.
CAN bridges can connect CAN networks of different bit rates or pro-
tocols with each other. They are based on the store-(modify)-forward Sub-network 1:
principle where CAN messages are received by a sub-network and 1 Mbit, short line lengths
then transmitted to the other sub-network.
Translation and filter rules can also be used, allowing a protocol ad-
aptation to be carried out between the sub-networks. A bridge can
also provide simple gateway functions.
1 2 3
Unlike the CAN repeater, the CANbridge enables the enlargement of
the maximum network size so that the sub-systems are fully self-
sufficient with regard to bus arbitration. Independent of each other
in terms of their real-time behavior, CAN sub-networks connected by
bridges are to be regarded as independent networks. Translation, filter, etc. B
CAN-bridges are appropriate for creating hierarchical networks by
transferring only the information to the connected sub-networks
via bridges which are relevant to the sub-network. The bridge
function can also be executed with the aid of other transmission sy-
stems. For example, the CAN-Ethernet-CAN bridge is connected via
two Ethernet-TCP/IP gateways which enable connection to remote 5 6
CAN networks.
As an extension to the CAN bridges, CAN gateways allow for access

to CAN networks via other communication systems. In each case, Sub-network 2: 250 kbit, long line lengths
the protocols of the connected bus systems are mapped to the other
communication model. Connection of CAN networks with the CANbridge
This allows devices with only one serial port to be connected to

CAN/CANopen networks via CAN/CANopen-RS232 gateways. Gate-
ways can also provide remote accesses to CAN networks. The CAN-
TCP/IP gateway, for example, enables worldwide access to the CAN
network for both diagnosistic and service purposes.
33
CANbridge TECHNICAL DATA
Microcontroller Fujitsu MB90F543

Configurable CAN/CAN Gateway Memory extension 128 k Flash on-chip, 6 k RAM on-chip
(optional 256 k external SRAM), 256 Bytes
I2C EEPROM
CAN controller 2 x CAN on-chip, CAN 2.0A, 2.0B
CAN bus interface 2x ISO 11898-2 (High Speed), as an option
galvanic isolated or 1x ISO 11898-2 and
1x ISO 11898-3 (low-speed)
Serial interface RS232 for device configuration
Voltage supply 9-36 V (Industrial Version), 7-16 V
(Automotive Version), 1.5 W
Certification CE
Housing Robust metal housing approx. 100 x 85 x 32 mm
or plastic DIN rail housing approx.
110 x 75 x 22 mm
CONTENS OF DELIVERY
CANbridge
Configuration software for Windows 9x/Me/NT/2000/XP
OVERVIEW Operation Instruction
The CANbridge allows the coupling of two CAN networks, including

networks with different bit rates. Unlike a CAN-Repeater, which only ORDER OPTIONS
translates the electric signals, the CAN messages are received com-
pletely by the CANbridge and then sent to the other CAN network Industrial Version: Housing option, electrical isolation
in line with existing filter and conversion rules (Store-Forward prin- Automotive Version: second CAN-bus interface according to
ciple). With the aid of conversion rules (gateway tables), CAN mes- ISO 11898-2 (high-speed) or ISO 11898-3 (low-speed)
sages can be filtered or forwarded under another identifier. With
these mechanisms, the bus load can be reduced in the individual
networks by only sending messages which are of interest to the ORDER NUMBER
other network.
1.01.0121.11020 CANbridge – DIN Rail, 2 x High-Speed
The CANbridge has a powerful 16-bit microcontroller that can pro- Bus Interface, Industrial Version
cess bursts at higher data rates without message loss. LEDs signal 1.01.0121.22020 CANbridge – DIN Rail, 2 x High-Speed Bus Inter-
the current status of the coupled networks. face (galvanic isolated), Industrial Version
1.01.0120.22010 CANbridge – Aluminium, 2 x High-Speed Bus
The CANbridge is configured via a configuration file which is Interface (galvanic isolated), Automotive Version
downloaded to the device by a loader program. 1.01.0120.23010 CANbridge – Aluminium, 1 x High-Speed Bus
Interface (galvanic isolated) + 1 x Low-Speed Bus
The CANbridge is available in three different versions: as an indu- Interface, Automotive Version
strial version in either a DIN rail housing or in a robust metal hou- 1.01.0120.22020 CANbridge – Aluminium, 2 x High-Speed Bus
sing, and as an automotive version in a robust metal housing. Interface (galvanic isolated), Industrial Version
34
CANmodem /CANopen The CANmodem can be connected to a conventional, external AT-
compatible modem either via the full-duplex RS232 interface or
directly to the PC. Communication occurs through a serial protocol
For remote access to CANopen systems based on the HDLC standard. For modem adaptation, a configurable
via telephone line init string can be saved in the object directory.
Connection between the PC and the CANmodem is made by means

of a safe callback procedure. For this, the caller gives the CANmodem
his callback number, which is then checked by the CANmodem
against a prespecified white list. If the relevant number is entered
in the white list, the modem calls the caller back and starts an
authorization phase based on the CHAP protocol. After successful
authorization, the PC application can run all functions on the CAN-
modem.
TECHNICAL DATA

Memory 128 kB FLASH, 256 kB RAM
CAN controller Fujitsu on-chip CAN controller
CAN bus interface High-Speed ISO/IS 11898-2, galvanically isolated
Baudrate Up to 1 MBit/s
Serial interface Full-duplex RS232 interface
Voltage supply 9 - 36 V DC, 1.5 W
Size 100 x 75 x 20 mm
Certification CE
OVERVIEW Housing Plastic housing for DIN rail assembly
CANmodem is an intelligent gateway that allows remote access to

CANopen systems via a conventional AT compatible modem. CONTENS OF DELIVERY
The programming interface for Windows 2000/XP (API) provides CANmodem/CANopen

functions for transmitting and receiving SDO messages as well as Windows programming interface (API-DLL)
for configuration of the CANmodem. PC-based service and moni- CANmodem manual, CANmodem API manual
toring programs can simply access the CANmodem by means of the
API via a telephone dial-up connection.
ORDER NUMBER
The CANmodem is a full CANopen node and has an object directory,
two server SDOs and 127 client SDOs. Data of any length can be 1.01.0122.20000 CANmodem/CANopen
read and written via the client SDOs (segment size via Modem is
231 bytes). The module can act as a heartbeat producer and as a he- 1.04.0130.00000 External Modem
artbeat consumer, can monitor up to 16 devices, and can transmit
corresponding events in the CANopen network such as NMT events
or heartbeat events. In addition, transmission and reception of any
layer 2 messages is possible. This function can be used for trans-
mitting and receiving any PDOs or for using the CANmodem with
any CAN protocol.
In the event of service, many SDO accesses to the individual devices

occur. The API not only allows SDO accesses to be initiated indivi-
dually, but it also allows an entire list of SDO accesses to be initiated
and transmitted to the CANmodem. This list is then processed lo-
cally by the CANmodem and the results are then returned. With
many SDO accesses, the propagation time via the telephone line
plays a minor role.
35
CAN@net II/Generic CAN-ETHERNET-CAN BRIDGE
Using 2 CAN@net II/Generic, a CAN-Ethernet-CAN bridge can be

CAN-Ethernet Gateway and implemented. This bridge allows for the exchange of CAN messages
CAN-Ethernet-CAN Bridge between two CAN systems via TCP/IP where filter tables can be de-
fined.
Ethernet Intranet Ethernet

Internet
CAN@net CAN@net
Socket I/F Socket I/F
(Client) (Server)
CAN CAN
Bridge configuration
CONFIGURATION & FIRMWARE UPDATE
The configuration of the TCP/IP parameters can be performed using

an easy to handle PC tool with automatic device detection. The con-
figuration of the bridge functionality and the CAN communication
is supported by an implemented webserver.
TECHNICAL DATA
CAN-ETHERNET GATEWAY
PC bus interface 10/100 Mbit/s Ethernet (10-Base T/100-base T),
In the gateway mode the CAN@net II/Generic is connected to a PC Autodetect, RJ45 connector
or to a controller platform via TCP/IP. The application program on IP address allocation DHCP, via PC tool
the host communicates via a standard TCP/IP socket and uses a sim- Microcontroller Freescale MCF5235, 150 MHz
ple ASCII protocol. The CAN@net II/Generic offers simple, flexible Memory extension 8 Mbyte DRAM, 4 Mbyte Flash
access to CAN systems via a LAN or via the Internet. CAN controller 1 x Philips SJA1000
CAN bus interface ISO/IS 11898-2, Sub D9 galvanically decoupled
(500V)
Current supply 9-32 V DC, 3 W
PC or
User platform Temperature range -20 ºC to +70 ºC
Socket Certification CE, FCC, CSA
Housing Plastic housing for top hat rail mounting
Ethernet Intranet Ethernet Size approx. 22,5 x 100 x 115 mm
Internet
CAN@net
Socket I/F
(Server)
CAN@net II/Generic
CAN User manual
Sample programs
Gateway configuration
ORDER NUMBER
1.01.0086.10201 CAN@net II/Generic
36
CANlink II TECHNICAL DATA

RS232-CAN Converter Memory extension 128 k Flash on-chip, 6 k RAM on-chip (optional:
256 k externel SRAM), 256 Bytes I2C EEPROM
CAN controller 1 x CAN on-chip, CAN 2.0A, 2.0B
CAN bus interface 1x ISO 11898-2 (High Speed), optional:
galvanically isolated
Serial port RS232 (600, 1200, 2400, 4800, 9600,19200,
38400, 57600, 115200 bits/s)
Power supply 9-36 V, 1.5 W
Certification CE
Housing Plastic top hat rail housing
approx. 110 x 75 x 22 mm
CANlink II
Configuration software for Windows 9x/Me/NT/2000/XP
User’s manual
ORDER OPTIONS
OVERVIEW Galvanic isolation
With the CANlink II, devices with a serial port can be connected to
the CAN bus with two modes being available for use in CAN and ORDER NUMBER
CANopen networks.
1.01.0033.10000 CANlink II – DIN Rail
In the CAN mode (layer 2), the received CAN data is transmitted 1.01.0033.20000 CANlink II – DIN Rail, with Galvanic Isolation
transparently to the RS232 interface. Data sent by means of RS232
is packed in CAN telegrams and transmitted. One configurable iden-
tifier is available for each transmission and reception.
In the CANopen mode the CANlink works as a CANopen subscriber,

where the serial data is saved as a bytestream object in the manu-
facturer-specific object dictionary range.
SUPPORTED CANOPEN FEATURES
1 server SDO expedited, non-expedited, no CRC check

1TX PDO static mapping
1 RX PDO static mapping
Emergency message
Heartbeat producer
NMT slave
The communication interfaces and modes are configured with a

configuration file which is saved on the device with an upload pro-
gram.
37
LIN2CAN TECHNICAL DATA

Powerful LIN-CAN-Gateway Interfaces 1x CAN ISO 11898-2 High-Speed,
1x CAN ISO 11898-3 Low-Speed,
1x LIN, 1x RS232
Memory extension 6 kByte RAM data memory, 128 kByte Flash,
512 kByte external SRAM
Extras Configurable Sleep mode with Wake up via CAN,
LIN or RS232
Power supply 7 V to 16 V DC, 1.5 W
Certification CE
LIN2CAN
Configuration software for Windows 2000/XP
User’s manual
OVERVIEW
ORDER NUMBER
The LIN-CAN gateway is a universal device for both the analysis of
LIN networks via the CAN bus and for the emulation of LIN slave or 1.01.0130.00000 LIN2CAN
master modules. In addition, the device can be used as a LIN-PC in-
terface for PC-based configuration and monitoring software or for
PC-supported LIN device development.
OPERATION MODES
The LIN-CAN Gateway supports four operating modes:
LIN-CAN Gateway as LIN Master or LIN Slave

LIN-Slave Emulation
LIN-Master-Slave Emulation
LIN-PC Interface
The various modes can be configured and activated via PC. The con-
figuration is saved as "non-volatile" in the device so that the con-
figured mode can be started automatically after power-on.
38
CANblue/Generic TECHNICAL DATA
Bluetooth Bluetooth specification V2.0,

CAN-Bluetooth-CAN Bridge and CAN-Bluetooth interface Class 1 / +16,9 dBm (49 mW), 100m
Module with ASCII Protocol Microcontroller Infineon C161U, 36 MHz
Memory 256 k Flash, 128 k RAM
CAN bus interface ISO/IS 11898-2 (High Speed) and ISO/IS11898-3
(Low-Speed), switchable, Sub D9 plug according
to DS102, galvanic decoupled
Voltage supply 9 - 30 V DC, 2.5 W
Certification CE, FCC
Housing stable metal housing
CANblue/Generic, manual
ORDER NUMBER
1.01.0125.00001 CANblue/Generic
BRIDGE MODE
The bridge mode allows the user to set-up a CAN-Bluetooth-CAN

bridge by using two CANblue/Generic devices. Message exchange
occurs on layer 2 and is transparent. The CANblue/Generic can also
be used in systems that work with CANopen, DeviceNet or customer-
specific protocols. Filters for CAN identifiers can be stored in the
devices for data exchange via Bluetooth. By using more than two
CANblue/Generic devices the coupling of the devices can be made
dynamically. Depending upon the existing environmental conditions,
the maximum distance between the CANblue/Generic devices is up
to 100m.
ASCII PROTOCOL MODE
In ASCII protocol mode, functions for transmitting and receiving

CAN messages and for configuring the CANblue/Generic are avai-
lable to the user based on simple ASCII commands. The CANblue/-
Generic is ideal for "non-Windows" systems or embedded platforms
that will be connected wirelessly to CAN.
39
canAnalyser In the standard version the canAnalyser offers powerful functions
covering many areas of application:
The powerful CAN Tool for Development, Online monitoring of bus traffic
Testing and Service Transmission of one-off or cyclic messages and entire message
sequences
Parallel monitoring of several CAN buses
Recording of CAN messages with various trigger conditions
Static evaluation of the message traffic
Recording and display of bus load
Graphic display of message contents over the time axis
Creation of command controlled message sequences
An integral part of the canAnalyser is the processing of message

databases. With this, each CAN identifier can be allocated a message
name and the signals transmitted in the data field can be interpre-
ted and displayed as physical parameters in different ways. The can-
Analyser also processes the widely used CANdb format. In all
modules the relevant message name from the database is displayed
in addition to the CAN identifier.
Additional functions are provided by optional modules, such as the

protocol specific display of messages of CANopen, DeviceNet or
J1939 based systems.
Control Panel
OVERVIEW HIGHLIGHTS
With the canAnalyser, IXXAT offers a powerful, versatile tool for the Multilingual 32-bit software for Windows2000/XP
development, testing and servicing of CAN-based networks. The Support of all CAN interfaces supplied by IXXAT
canAnalyser is already used extensively, especially in the area of in- Support of 11- and 29-bit identifiers (CAN 2.0A/2.0B)
dustrial automation, and, is also being used more and more in the Timestamp for receive objects with a resolution of 500 µsec
automotive industry. Using current Windows technologies, the (depending on the used hardware)
complete new developed canAnalyser V2, with further improved Passive mode (no transmission of Ack bit and error frames,
flexibility and reliability, is a modern allround analysis tool for all thus no interference of the CAN system by the canAnalyser)
CAN application areas. Detection and display of error frames
Integrated support of project databases
The software package is based on a modular concept which com- Online trace on hard disk with various trigger conditions
bines exceptional openness with virtually unlimited versatility. Cus- Support of all CAN controllers available on the interface board
tomer specific functions can be easily integrated via an open .NET (multi-line mode)
programming interface in the form of individual modules. By using Display of the CAN controller status and bus load
a powerful CAN interface from IXXAT, the canAnalyser achieves the Documented .NET programming interface for extension by
reception of CAN messages and time oriented buffering even when user-specific modules
dealing with very high bus loads and baudrates. Execution of Scripts
40
FUNCTIONS
Configuration and Operation
The control panel of the canAnalyser is the central element for con-
figuration. Supported by a Wizard, the required CAN interface is
selected and the CAN controller on the board is configured. It also
defines which function modules are assigned to the CAN controllers.
The configuration is clearly displayed in the form of a tree and the
module assignment occurs intuitively by means of drag and drop.
Each CAN bus can be assigned a database. Using the control panel,
the individual modules are started and terminated and the module
windows are arranged, minimized and restored.
Scripting Host
Programmability
Due to the open programming interface, the canAnalyser can be For further monitoring of certain message groups, the receive
extended by the user's own modules or user interfaces. With com- module can be started multiple times, where each instance can
mon Windows development systems (e.g. Visual Studio.NET), new, display one section of the CAN data flow. For this, an individual
independent modules can be developed and added to the canAnalyser. message filter is set up in each case, so that an accurate overview
It is possible for users to create interfaces for their systems or for of the CAN system is insured. Filter configurations can be defined
certain devices or tools with system specific analysis functions. and assigned symbolic names, working in the same manner as the
format templates in Microsoft Word.
Scripting Host
The Scripting Host provides the canAnalyser user a powerful inter-

face that combines the advantages of graphic Windows programs
with the flexibility of scripts. By using the Scripting Host the can-
Analyser can be quickly and easily adapted to specific measuring
and analysis tasks. This allows the user to simulate devices and pro-
tocols or to test existing devices in the simulated restbus and to
put them into operation. Specific test environments can be easily
created using any Windows interface components. The Scripting Receive Module
Host supports the standard script languages C# and Visual Basic

.NET. The incorporation of DLLs also enables the integration of furt-
her modules. The Scripting Host can be used to manage an unlimi-
ted number of scripts which are started either manually or
automatically.
Receiving and displaying CAN messages (Receive Module)
The CAN messages transmitted on the CAN bus can be displayed

online in different ways. Either all messages or only certain ones,
selected via an adjustable filter, are displayed. Messages can be
displayed in two ways. In scroll mode, the messages are displayed
together with the time of reception one after the other in a list.
This form of display is particularly suitable for monitoring message
sequences. On the other hand, in the overwrite mode the messages
received are listed according to the identifier and permanently over-
written with the incoming data. Each message is assigned a counter,
which displays the commonness of its transmission. Here the altered
byte is highlighted in color. With cycle time monitoring, the regu-
larity of reception is observed and an icon indicates whether or not
the message was updated within the expected time. Therefore, this
form of display is suitable for determining the current value of
certain messages.
41
Transmission of CAN-messages (Transmit Module)
Messages to be transmitted can be arranged by the user in a mes-

sage table. Individual entries from this table can be transmitted
once or cyclically. The table contains both the definition of the mes-
sage (identifier, data bytes, RTR bit) and a description of the mes-
sage. The data entry can be either decimal or hexadecimal. For
messages to be transmitted cyclically, cycle times of 250 us (depen-
ding on the used hardware) to 100 s can be specified. In cyclic trans-
mission mode, identifiers or data contents can be incremented
automatically.
Sequencer Module
Graphic display of data (Graphic Module)
Data contents of CAN messages are displayed in the graphic

module in a window over the time axis. The information to be
displayed, such as name and unit is automatically taken from the
database allocated to a CAN bus. The data is displayed in real time,
where a maximum of 16 signals per graphic window are distributed
Transmit Module over up to 4 time axes. In addition, the current value of a signal is
displayed numerically. With the aid of a metering bar, specific values
can be determined and evaluations carried out.
Recording CAN messages (Trace Module)
With the trace module all received messages and error frames are
recorded directly onto the hard disk. The recording can be started
and stopped via the trace control. In addition, trigger conditions
for starting and stopping as well as filters for the CAN messages to
be recorded can be defined for each bus. A trace can be viewed at
any time and can be reloaded into a system offline for analysis by
specifically configured analysis modules, or, online with the aid of
the sequence module (limited number of messages).
Transmitting message sequences (Sequencer Module)
During the development of CAN devices, functions, protocols and

complete systems situations can be tested by transmitting message
sequences. Unavailable devices can also be simulated. The message
sequences are created with a few easy to learn commands (such as
transmitting a message, waiting for a message, pause with specified
duration, repeat, user input) via an integrated editor and then exe-
cuted at the push of a button.
Graphic Module
42
Statistic analysis of network variables (Statistic Module)
With the statistic module, important variables of a CAN network

can be both statistically recorded and displayed graphically. The
module determines the current bus load of the system and dis-
plays this over the time. In addition to general data such as the
number of error frames or the total number of transmitted CAN
messages, the frequency of the individual CAN messages is dis-
played as a histogram.
Signal Module
Editor for the project databases
The basis for the interpretation and symbolic display of the data
transmitted in the CAN message is the project database. In this,
a CAN message is first assigned a name according to its identifier.
The message can contain up to 64 individual data (signals). The
file format used is XML. In addition, there exists an import filter
for the CANdb format.
Each signal can be interpreted as an analog, digital or string value.
The structure of the project database is displayed in a two part

Statistic Module
window as a hierarchical tree with signal type dependent icons,
with separate, clear input masks existing for each area.
Symbolic interpretation and display of transmitted
process variables (Signal Module)
Beyond the display of the receive module, not only is the identi-
fier of a CAN message with a symbolic name displayed, but the
complete contents of the message are also extracted and dis-
played as signals (physical values) based on the interpretation
rules stored in the database. Therefore, this module is particularly
suitable for installation, testing and servicing of CAN systems as
it allows the service technician to handle measuring and setting
variables in the usual way.
Whether in scroll mode or in overwrite mode, the signals contained

in a CAN message can be displayed with the signal module. In
scroll mode, the messages are displayed along with the time of re-
ception one after the other in a list where a separate line is used
for each signal. On the other hand, in overwrite mode, selected
signals are permanently overwritten by the incoming values. Mes-
sages and signals can be activated and deactivated individually,
i.e., excluded from interpretation.
Database Editor
43
HARDWARE REQUIREMENTS
PC with Windows 2000 / XP

IXXAT CAN interface with SJA1000 CAN controller
and CAN driver VCI
Software as single user license, consisting of control panel,

receive module, transmit module, trace module, sequencer
module, graphic module, statistic module, signal module
Database editor
Sample programs for using the programming interface
User's manual
USB license key
ADDITIONALLY AVAILABLE SOFTWARE
LIN analysis: With the LIN2CAN device it is possible to monitor

and transmit LIN messages with the canAnalyser. The LIN2CAN is
configured as a gateway and converts the LIN messages into CAN
messages and vice versa.
ORDER NUMBER
1.02.0133.00000 canAnalyser
44
canAnalyser-lite HARDWARE REQUIREMENTS
PC with Windows 2000/XP

The low-cost introduction to IXXAT CAN interface with SJA1000 CAN controller and
professional CAN analysis CAN driver VCI V2
OVERVIEW
Software as single user license, consisting of control panel,
As the "little brother" of the canAnalyser, the canAnalyser-lite pro- receive module, transmit module, trace module, sequencer
vides the most important functions required for CAN analysis in a module, statistic module
compact form. Database editor
User's manual
Offering functions for online monitoring of bus traffic, for single- USB license key
shot or cyclic transmission of messages and complete message
sequences, for recording bus traffic with various trigger conditions FURTHER INFORMATION
and for statistical evaluation of bus traffic, it possesses the main
functions for the analysis of CAN systems while providing a low- A free demo version is available on our homepage. The product
cost introduction. homepage, with tutorial, tips and support can be found at
www.cananalyser.com.
Since the configuration files and the project databases of both ver-
sions are compatible, it can be easily upgraded to the full version, OPTIONAL AVAILABLE MODULES
if required.
CANopen Module
SCOPE OF FUNCTIONS DeviceNet Module
SAE J1939 Module
Like the canAnalyser, the canAnalyser-lite is based on the reliable
modular concept. The lite version contains the following modules: ADDITIONAL APPLICATION
Receive module for receiving and displaying CAN messages LIN analysis: With the LIN2CAN device it is possible to monitor
Transmit module for transmitting messages and transmit LIN messages with the canAnalyser. The LIN2CAN
Trace module for recording messages with filter and trigger is configured as a gateway and converts the LIN messages into
functionality CAN messages and vice versa.
Sequencer module for transmitting message sequences
Statistic module for displaying parameters and message Comparison of functions of the canAnalyser
frequencies and the canAnalyser-lite
These modules correspond to those of the full version and are canAnalyser canAnalyser-lite
managed by means of the control panel that is also supplied. Receive Module x x
Transmit Module x x
In contrast to the canAnalyser, the canAnalyser-lite does not allow Trace Module x x
multiple instances of a module, has no open programming inter- Sequencer Module x x
face, and, can only be operated with one CAN bus. Graphic Module x –
Statistic Module x x
Signal Module x –
HIGHLIGHTS CANopen Module o o
DeviceNet Module o o
Multilingual 32-bit software for Windows 2000/XP SAE J1939 Module o o
Support of all CAN interfaces supplied by IXXAT Two channel capability x –
Support of 11- and 29-bit identifiers (CAN 2.0A/2.0B) Open programming x –
Timestamp for receive objects with a resolution of up to interface
500 µsec (depending on the used hardware) Scripting Host x –
Passive mode (no transmission of Ack bit and error frames, Multiple Module
x –
thus no interference of the CAN system by the canAnalyser instances
Detection and display of error frames
Online trace on hard disk with various trigger conditions x included in delivery specification o optional – not support
Display of the CAN controller status and the bus load
ORDER NUMBER
1.02.0166.00000 canAnalyser-lite
45
CANopen Module The basis for the interpretation of the received data is the so-called
configuration set. This either allocates an EDS/DCF file to the 127
possible network subscribers or defines its device profile. The con-
CANopen Interpreter for canAnalyser figuration set can be loaded, edited and saved. In addition, it is pos-
sible to add, delete and modify the CAN objects used by each node
and their CAN identifiers. The profiles used for interpretation are
OVERVIEW integrated via external ASCII files, allowing the CANopen Module
to be easily extended by new profiles. Due to its flexible structure,
As an addition to the canAnalyser, the CANopen Module allows for the CANopen Module can be used universally in all CANopen systems.
the interpretation of CAN messages according to the CANopen
standards. Here, the message types defined by CANopen together
with their parameters, are displayed in color in plaintext. The module SYSTEM REQUIREMENTS
is suitable for the analysis of CANopen nodes and networks.
canAnalyser or canAnalyser-lite (Version 2.0 or newer)
Software as single-user license

User manual
ORDER NUMBER
1.02.0145.00000 CANopen Module for canAnalyser/canAnalyser-lite
CANopen Module
DESCRIPTION OF FUNCTIONS
The CANopen Module interprets all received CAN messages accor-

ding to the CANopen specifications DS-301, DS-302 (incl. Flying
Master) and DS-305 (LSS). The messages are recognized as SDOs,
PDOs (also multiplexed), NMT, Emergency, Sync and Timestamp
objects and interpreted accordingly. Here, it is possible to filter the
messages received according to both their node number and their
message type. An SDO transfer is displayed with index and subindex
and the symbolic name of the addressed object dictionary entry.
Any abort code which may occur is correctly displayed with the SDO
data transferred up to that point. The display is color coded accor-
ding to the message type. In addition, the SDO display can be swit-
ched between the display of the individual subsequences and an
overall display of the byte stream transferred. For each message
type, the original raw CAN message can be displayed in order to
detect additional or also incorrect protocol data.
46
DeviceNet Module In addition, filtering of the received messages according to both
MAC-ID and message type can be set and saved during operation.
For further processing of the interpreted data in other applications,
DeviceNet Interpreter for canAnalyser the content of the analysis window can be exported to a text file
(CSV format). Because of its flexible filter configuration and the
comprehensive interpretation basis, the DeviceNet module is suit-
OVERVIEW able for all DeviceNet systems.
This extension module for the canAnalyser enables the interpreta-

tion of received CAN messages in accordance with the ODVA Device- SYSTEM REQUIREMENTS
Net standard. Received messages are analyzed according to the type
of message and displayed as plain text. By means of powerful filters, canAnalyser or canAnalyser-lite (Version 2.0 or newer)
the data to be displayed can be specifically selected. Therefore, the
module is suitable for both developers of DeviceNet devices and for
troubleshooting and analysis of DeviceNet networks and systems. CONTENTS OF DELIVERY

User manual
ORDER NUMBER
1.02.0148.00000 DeviceNet Module for canAnalyser/

canAnalyser-lite
DeviceNet Module
The DeviceNet module interprets all received CAN messages accor-

ding to their DeviceNet significance and displays the received
parameters according to Message Group, MAC ID and Message ID.
The incoming information is divided into Unconnected Message,
Explicit Message, I/O Message, Duplicate MAC-ID Check Message,
Device Heartbeat Message, Device Shutdown Message, Offline Con-
nection Set as well as reserved and invalid DeviceNet messages and
their content decoded, depending on type:
Explicit Messages: All specified common services and class

names are displayed. The error responses are also represented.
Furthermore the fragmentation protocol is analyzed and moni-
tored. The interpretation of Explicit Messages is based on the
connection table which contains the used message format.
The connection table is filled automatically by detection of the
connection set-up and can be configured manually.
I/O Messages: Support of both Predefined Master/Slave

Connection Set (Poll, Bit-Strobe, COS/Cyclic, Multicast Poll) and
dynamic messages from groups 1 and 3. Fragmented I/O Mes-
sages can be configured by the user; for these messages, the
fragmentation protocol is analyzed and monitored.
Unconnected: Unconnected Message Manager Port (UCMM)

and Unconnected Port of the Predefined Master Slave Connec-
tion Set are supported.
47
J1939 Module SYSTEM REQUIREMENTS
canAnalyser or canAnalyser-lite (Version 2.0 or newer)

J1939 Interpreter for canAnalyser
OVERVIEW
As an addition to the canAnalyser, the J1939 Module enables the User manual
display of received messages according to the SAE J1939 notation.
Received messages are analyzed according to the type of message
and displayed as plain text. By means of powerful filters, the data ORDER NUMBER
to be displayed can be specifically selected. The module is therefore
suitable for both developers of J1939 devices and for troubleshoo- 1.02.0149.00000 J1939 Module for canAnalyser/canAnalyser-lite
ting and analysis of J1939 networks and systems.
J1939 Module
The J1939 Module provides the display of received messages accor-

ding to the SAE J1939 notation. This includes the interpretation of
received messages and the extraction of Parameter Group Number,
Source Address and transmitted Suspect Parameters with name,
value and unit. Furthermore the Messages Priority, Data Page, Proto-
col Data Unit Format and Protocol Data Unit Specific Fields are dis-
played. The J1939 module allows the processing and interpretation
of the transport protocol as well as the interpretation of diagnostic
messages. Proprietary application messages can be interpreted if a
user defined database with Parameter Group and Suspect Parameter
definitions is provided. The J1939 module also provides for the pro-
cessing and interpretation of the transport protocol as well as for
the interpretation of diagnostic messages. To clearly arrange dis-
played messages, it is possible to set filters for Parameter Group
Numbers and Source Addresses. Received messages can be saved
into a CSV file. Furthermore, the filter and module configuration
can be stored, imported and exported.
48
CANcorder MMC to 128 different trace records. The recorded data is transfered to the
memory card as soon as a trace record becomes completely taken.
Because of this, the recording capacity is only limited by the size of
A versatile Data Logger for the Diagnosis of CAN the memory card.
Networks and the Recording of Process Data
The CANcorder MMC is configured with the aid of a convenient
Windows configuration tool. This also allows trace data to be
downloaded from the device to the PC and saved to the hard disk
for further analysis. The CANcorder MMC does not have to be con-
nected to the PC for this, as the configuration data and the logs
can be transferred using the memory card.
Besides the manual configuration, the CANdb import functionality

allows for a simpler configuration of trigger events by using the
signal names and values which are defined in the CANdb database.
To do this, these are entered via Drag&Drop into the CANcorder
trigger/filter controls of the configuration tool.
OVERVIEW
IXXAT's CAN data logger "CANcorder MMC" is a powerful, cost-

effective tool for archival logging of data traffic in CAN systems. Its
intelligent trigger functions allow logging and saving of CAN mes-
sages before and after a freely-definable trigger event. These trigger
events can be error frames, time delays, keys of the remote control,
the digital input or a received CAN bit pattern. This bit pattern is
described in program text similar to C-syntax and enables all ele-
ments of a CAN message to be linked to logical operators and values.
Due to the CANdB file import, a signal based trigger configuration
is supported. In the multi-stage trigger, up to three consecutive trig-
ger events can be analyzed, leading to the implementation of com-
plex trigger conditions. As a result, sporadic errors can be specifically
logged and downloaded to the PC for further analysis.
Besides recording CAN messages, the CANcorder MMC can be used

for the transmission of up to four cyclic messages. Cycle times bet-
ween 62 days and 10 ms can be defined for each message, and, the
offset between the four messages can be set.
The CANcorder MMC is available with two CAN channels (11 bit or
29 bit identifier) and allows data to be recorded in single or dual
mode. Due to the large buffered data memory of 4 MB, up to
230,000 messages can be recorded. The memory can be used for up
49
Due to the Sleep-Mode (automatic power-down after a specified TECHNICAL DATA
time with no bus traffic) and the optionally available remote con-
nection via GSM module/cell phone (option TeleControl), the CAN- CAN bus interface2 x High-Speed ISO/IS 11898-2, optional Low-
corder is particularly appropriate for mobile applications in Speed ISO/IS 11898-3, Sub-D9 connector according
passenger cars and commercial vehicles. The TeleControl option al- to DS 102, as an option electrically decoupled
lows events to be signaled by SMS, the up-loading of Trace Baudrate Up to 1 MBits/s
records via GSM-module/cell phone, and, remote configuration. Microcontroller Infineon C165; 22,118 MHz
CAN controller 2 x Philips SJA1000; 16 MHz
As a result of its easy handling and configuration, the CANcorder is Memory extension 4 MB data memory for recording of up to 230,000
also an indispensable tool for both the long-term monitoring of indu- messages, battery-buffered; Memory card slot,
strial machines and systems, and, the recording of operation data. max 1024 MB memory card (SD or MMC)
Power supply 7 - 50 V DC
Size Approx. 165 x 85 x 32 mm
CANcorder MMC
Memory card with 256 MB
Windows application for configuration and for data upload
for Windows 9x/Me/NT/2000/XP
Serial cable for configuration and data upload (RS232)
Power supply cable
Manual
OPTIONS
FEATURES
CANcorder-RC: Cable remote control with start/stop key and
Easy configuration without knowledge of programming with one free configurable key (trigger, set a marker in the data
a dialog-based Windows program stream)
Two CAN channels (single or simultaneous recording) TeleControl: Remote inquiry, remote configuration and SMS
Bus interfaces for low and high speed applications transmission via modem/GSM module or cell phone
(ISO/IS 11898-2 and ISO/IS 11898-3)
Recording of messages using standard (CAN 2.0A, 11 bit) or Device rental service
extended CAN format (CAN 2.0B, 29 bit) The CANcorder MMC can also be rented on a temporary basis. The
Recording of data, error and remote frames with time stamp minimum rental time is 2 weeks, but it can be extended on a weekly
Conversion of the binary traces for further processing to ASCII, basis. At the conclusion of the rental period, should the user wish
canAnalyser/32, CANalyzer, CSV format to purchase the device, all previously paid rental fees will be credited
Configurable message filter for recording specific data towards the purchase price.
CANdb import functionality for the easy configuration of
trigger events
Cyclic transmission of up to four pre-defined messages ORDER NUMBER
4 Mbytes data memory battery buffered for up to 230,000
messages, variable memory usage for 1 to 128 separate traces CANcorder MMC
Continuous long-time recording 1.01.0095.11010 with 2 high-speed bus interfaces
Configurable sleep mode with wake-up on CAN, RS 232 or 1.01.0095.15010 with 1 high-speed and 1 low-speed bus interface
trigger input 1.01.0095.22010 with 2 high-speed bus interfaces, galvanic isolated
Trigger input (TTL, 5 V) and trigger output (TTL, 5 V) 1.01.0095.55010 with 2 low-speed bus interfaces
Configuration and upload of traces via RS232 (max. 115.2
Kbauds) or memory card (card reader required for PC) CANcorder MMC TeleControl
Support of remote inquiry / remote configuration via 1.01.0096.11010 with 2 high-speed bus interfaces
modem/GSM (option TeleControl) 1.01.0096.15010 with 1 high-speed and 1 low-speed bus interface
Freely definable SMS-transmission for status-/event 1.01.0096.22010 with 2 high-speed bus interfaces, galvanic isolated
signaling via GSM/cell phone (option TeleControl)
Solid metal case 1.01.0081.00000 Remote Control Unit for the CANcorder
Manual cable remote control: CANcorder RC (option)
Firmware update via memory card
Command line script control (configuration up-/download,
trace upload, clock setting, erase of memory card or on-board
memory)
50
CANcheck The CANcheck is operated by means of a simple menu control via
cursor keys and LCD display. Test results can be output via the LCD
display or a connected PC.
Installation tester for CAN networks For display of the results on a PC, the CANcheck is connected to the
PC via a USB port. Results are displayed on the PC via a terminal
program. The logging function of the terminal program enables the
test results to be either archived in a file or printed out.
TECHNICAL DATA
Display 128 x 64 pixels; background light can be

switched on or off
Keypad Touch-sensitive keypad with 6 keys
Switch on/off Switch on by pressing any key; switches off
automatically after 10 mins.
USB port USB 2.0 (full speed)
CAN interface ISO/IS 11898 High-Speed CAN
Power supply 4 x 1.5 V Mignon Battery (AA) or USB
Operating time approximately 24 hrs. with a battery capacity
of 2850 mAh
Housing and Sturdy aluminum housing
dimensions 116 x 160 x 34 mm (W/H/D)
OVERVIEW
CONTENT OF DELIVERY
CANcheck allows users to analyze CAN networks during commisio-
ning, maintenance and helps searching faults. This battery-opera- CANcheck installation tester
ted, hand-held device connects to the CAN network to be tested CAN "Y" cable with Sub-D9 plug (2 m)
and operates using a clearly-structured menu. 1-to-1 CAN/Trigger cable
USB line
Manual
FUNCTIONS
Cable test with network switched off and operational test with ORDER NUMBER
network switched on
Wiring test: test of the resistances between all pins of the 1.01.0097.00000 CANcheck – Installation tester for CAN networks
CAN-connector (assignment in accordance with CiA), providing
assessment based on pre-defined threshold values
Terminal resistance test: measurement of the resistance between
CAN_H and CAN_L
Cable length: measurement of cable length via pulse-time
delay, cable impedance
Measurement of the signal level: absolute and differential
signal level listed according to identifier
Baud rate detection: detection of baud rate of the tested CAN
system
Identifier scan: determination of all identifiers transmitted and
display of reception frequency
CANopen mode: Signal level and reception frequency listed
according to node-ID
Bus load: measurement of the current bus load of the CAN
system
Error frames: number of error frames per time unit
User’s guide: test instructions before the test, OK or error
message after the test, continuation after acknowledgement
Multilingual: test instructions in German or English
51
CAN-Bus-Tester (CBT)
A Powerful Tool for CAN-Protocol Analysis
and Testing of Bus Physics
HIGHLIGHTS
Analysis of the physical level of all messages

Physical analysis of signal-to-noise ratio and edge quality
of selectable messages
OVERVIEW Comprehensive trigger conditions for fault detection
Logger function for long-term analysis
Many faults found in CAN bus systems have physical causes. With Automatic baud rate detection
the CAN-Bus-Tester, it is possible to detect and analyze these faults. Simple connection to CAN-system
In addition, the most important logical analysis functions are also Simple operation via Windows program
integrated into the Tester (otherwise found only in protocol analyzers).
The Tester can be used with all bus systems with 11- or 29-bit iden-
tifiers according to ISO 11898-2. Particular emphasis was placed on TECHNICAL DATA
simple operation. A USB-interface makes hot-plug&play possible
between PC and Bus-Tester. Automatic baud rate detection and the Use CAN according to ISO 11898-2 (High-Speed) with
self-connecting BusScan enable easy monitoring of the physical 11-bit or 29-bit identifier (CAN 2.0A and 2.0B)
signal-to-noise ratio of the bus, sorted according to CAN-identifiers Baudrate 5 k, 10 k, 20 k, 50 k, 62,5 k, 100 k, 125 k, 250 k,
received. Generally, devices which transmit messages with low 500 k, 800 k, 1000 kBit/s
signal-to-noise ratio are highly susceptible to failures. Depending on Baudrate detection All baudrates
the test strategy, various methods of identifying faults can be used, Signal-to-noise 0,9 V - 5,0 V
including setting various trigger events (identifier, physical and/or voltage range display
logical faults and error-frames). In the case of a fault, the pre- and Resolution for signal- 0.1 V
post-history of up to 128 messages can be viewed. All faults are to-noise voltage range
defined up to the individual bit position and are displayed with a Bit sampling 32 times
time stamp. A trigger signal available via the external trigger output Bus load Permanent display in %
can be used for triggering an oscilloscope. A certain (faulty) CAN- Cycle time Minimum 300 µs, resolution 10 µs
message can thus be shown selectively on the oscilloscope. measurement
Trigger on ID, physical failures (flank quality), logic errors
Temporary faults on the bus or a slowly deteriorating signal quality, (CRC, ACK, form-faults), active/passive error-flags
which can lead to the failure of the communication system, can be Trigger output BNC-socket, electrically isolated
registered with an intuitive logger function. Since the Tester collects Logger function Signal-to-noise voltage ratio for all IDs
its data while the plant is running, costly downtime of machines Connection to CAN bus Passive, 2 x 9-pole SUB-D connector
and plants is avoided, and, all data can be protocolled. PC connection Via USB, electrically isolated
Supply voltage 11 - 36 V DC, DIN 45323 low-voltage socket;
0.1 - 0.3A
Dimensions and wight H = 35 mm, W = 109 mm, L = 143 mm, 320 g
Safety/protection EN 60950 / IP 20 according to EN 60529
EMC EN50081-1, EN50082-2
Temperatur range Operation: +5 °C to +40 °C; storage:
-20 °C to +60 °C
52
CONTENT OF DELIVERY
CAN-Bus-Tester CBT
CAN adapter cable, 30 cm long, 4-pole with conduit-thread
connector
USB cable, 3 m
Adapter circuit board, for easy connection of an oscilloscope
Power unit 100 V - 240 V / 50 Hz; 24 V, 500 mA
Power cable, 1.8 m
Manual including CD (German/English)
Case
SYSTEM REQUIREMENTS
PC: > 400 MHz, USB interface, CD-ROM drive

Operating system Windows 98/Me/2000
Device rental service

The CAN-Bus-Tester can also be rented on a temporary basis. The
minimum rental time is 2 weeks, but it can be extended on a weekly
basis. At the conclusion of the rental period, should the user wish to
purchase the device, all previously paid rental fees will be credited
towards the purchase price.
ORDER NUMBER
1.04.0004.00000 CAN-Bus-Tester, German, Power supply for Europe

1.04.0004.00001 CAN-Bus-Tester, English, Power supply for Europe
1.04.0004.00031 CAN-Bus-Tester, englisch, Power supply for Australia
1.04.0004.00021 CAN-Bus-Tester, englisch, Power supply for the UK
1.04.0004.00011 CAN-Bus-Tester, englisch, Power supply for USA/Japan
53
CANopen Introduction
The profile family CANopen defines a protocol for distributed indu-
strial automation systems based on CAN. CANopen was developed
Communication Object Application
within the CAN-in-Automation (CiA) users' and manufacturers' interface dictionary process
group and is now standardized as CENELEC EN 50325-4. Soon after
its release, CANopen found a broad acceptance, especially in Europe
where it can be considered the leading standard for CAN based in- Server SDOs
I/O-Signals
dustrial and embedded system solutions.
Client SDOs Logical addres-
The CANopen profile family is based on a "Communication Profile", sing scheme for
CAN-Bus
accessing the Device

which specifies the basic communication mechanisms and a number Rx PDOs
communication functionality
of different Device or Application Profiles which describe the most
Process
and device para-
important device types such as digital and analog I/O modules, Tx PDOs meters as well as
drives, programmable controllers and encoders. In these device pro- data
files functionality, parameters and the access to process data of and functions
standard devices of the corresponding types are specified. Based on NMT, SYNC,
these standardized profiles devices of different manufacturers can Emergency,
Time Stamp
be accessed in exactly the same manner, which again results in
messages
manufacturer independence to a large extent.
The key element of the CANopen standard is the description of the

device functionality through an object dictionary.
Similar to other well-known field bus systems CANopen distinguishes
Each entry in the object dictionary is identified via a 16 bit index two basic data transfer mechanisms: The high-speed exchange of
and an 8 bit sub-index. The individual entries in the object dictio- small process data portions through so called "Process Data Objects"
nary provide a basis for a standardized network access to "Applica- (PDO), and, the access to entries in the object dictionary through so
tion Objects" of a device such as input and output signals, device called "Service Data Objects (SDO)". Process data objects are event
parameters, device functions or network variables, as well as to triggered, cyclic or requested as broadcast objects without additio-
"Communication Objects" which describe the communication nal protocol overhead. A PDO can be used for the transmission of
functionality of the device. at most 8 bytes of data. In connection with a synchronization mes-
sage, the transmission and the acceptance of PDOs can be synchro-
nized through the entire network ("Synchronous PDOs"). The
assignment of application objects to a PDO (Transmission Object) is
adjustable through data structures ("PDO Mapping") within the
object dictionary.
54
The transmission of SDOs is performed as a confirmed service with
two CAN objects in the form of a logical peer-to-peer connection
between two network devices. The addressing of the corresponding
object dictionary entries is accomplished by specifying index and
sub-index of the entry in the data field of the involved CAN frames.
Transmitted data can be of unlimited length. The transmission of
SDO messages involves an additional protocol overhead.
Standardized event-triggered "Emergency Messages" of high prio-

rity are reserved to report device malfunctions. A common system
time can be provided through a central timing message.
Management functionality like controlling and monitoring the

communication status of the nodes is achieved through a network
management protocol (NMT), which is organized according to a
logical master-slave relationship. Two alternative mechanisms
("Node-Guarding" and "Heartbeat") are available to implement node
monitoring functionality.
IXXAT has been involved in the specification and development of

higher layer CAN based protocols for more than 10 years. Among
other activities, IXXAT has provided essential contributions to the
specification of the CANopen standard. First implementations of
the IXXAT CANopen software were available by 1995. Its member-
ship in the CiA in combination with active cooperation with all im-
portant workgroups as well as the applied expertise gained through
many projects qualifies IXXAT as one of the most competent part-
ners available for the development of CANopen products and
system solutions.
55
Product Overview CANopen
IXXAT CANopen software and tools are used by different companies TOOLS
worldwide in applications such as machine control, elevator tech-
nology, marine automation, commercial vehicles, military and CANopen EDS Editor
medical technology. In order to meet the requirements of these The CANopen EDS Editor enables convenient processing of EDS files.
application areas and the corresponding development phases, IXXAT Its simple user interface offers device manufacturers and system
offers the following software solutions and services: integrators all the functions required to create or maintain existing
EDS files.
PROTOCOL SOFTWARE CANopen Device Manager

The CANopen Device Manager is a small, but extremely versatile
CANopen Protocol Software tool targeted at all tasks requiring direct CANopen device access.
The CANopen Protocol Software includes all necessary functions to These include device development and test, service and diagnostics
implement slave or simple master devices according to the CAN- tasks, as well as device configuration. CANopen Device Manager
open specification CiA 301. Support for LSS services according to fully supports SDO, PDO, and LSS master services, as well as the
CiA 305 is included by default. download of configuration data and firmware update according to
CiA 302. CANopen Device Manager particularly stands out with its
CANopen Manager Software flexible plug-in interface allowing the user to extend the basic
The CANopen Manager Software is a very powerful software package functionality with optional add-on modules including a powerful
that is optimally tailored at the implementation of complex CAN- scripting engine.
open manager devices. In particular, the software package is suited
for the implementation of CANopen PLC devices and is based on CANopen ConfigurationStudio
the specifications CiA 301, CiA 302 and CiA 405. The CANopen Configuration Studio is a convenient, powerful tool
for the design and configuration of CANopen devices and networks.
CANopenRT (Real-Time) Software Highlights of the tool are its modularity and extendibility, and its
The CANopenRT Software is an optimized version of the CANopen concise representation of process data and network topology.
Protocol Software featuring enhanced interfaces which permit a
highly efficient integration with either real-time or mainstream
operating systems. The software is particularly well-suited for multi- SERVICES
threaded applications requiring CANopen connectivity.
Code introduction
CANopen Maritime Software One-day or two-day detailed introduction to the source code of the
The CANopen Maritime Software implements the CANopen frame- CANopen Protocol solutions. Interfaces, processes and data flows
work for maritime electronics, CiA 307, and is specially designed for in the CANopen software are discussed.
the increased safety standards required by maritime automation.
It offers a single-point-of-failure tolerance due to redundant com- Technical support and development services
munication and support of the flying master concept. Support in the specification of a CANopen device or the system to
be implemented. The customer benefits from our comprehensive
CANopen Master API CANopen know-how resulting in an accelerated development pro-
The CANopen Master API is a software package that allows the easy cess. IXXAT may also handle adaptation, implementation and testing
development of CANopen master applications such as control, service of the CANopen software to your hardware or application.
and test programs under Windows. The CANopen Master API is par-
ticularly wellsuited for applications that do not require flexible con- Support for the conformance test
figuration over the CANopen network. A preliminary CANopen protocol conformance test is carried out at
IXXAT with the official CiA software. Faults that occur can be detec-
CANopen Manager API ted as well as possible corrections can be proposed before the con-
The CANopen Manager API is a powerful and flexible software formance test at CiA.
solution that – in combination with a iPC-I XC16/PCI CAN interface
– allows the user to implement generic CANopen control applica- Seminars
tions. It can also be integrated with IEC 61131-3 run-time environ- IXXAT offers a two day CANopen seminar which is performed at a
ments on Microsoft Windows based platforms. It is based on the fixed schedule at the IXXAT offices in Weingarten. The seminar is
CANopen Manager Software, and thus fully supports the standardized also held as an in-house seminar at the customer site on request.
CANopen boot-up procedure. The CANopen Manager API conforms
to the specifications CiA 301, CiA 302, and CiA 405.
56
CANopen resources more effectively. This enables extreme resource-saving
implementations. The core functionality of the CANopen software
Protocol Software is implemented independent of the architecture of the individual
CAN controller. The CAN driver itself is fully encapsulated in a sepa-
rate software module. Adaptation to the micro controller or pro-
Software package for the development of CANopen cessor type used (e.g. interrupts, timer) in performed centrally in a
slave or simple CANopen master devices separate header file.
HIGHLIGHTS MULTI-CHANNEL SUPPORT
Comprehensive range of functions based on the current Upon request, the IXXAT CANopen Protocol Software is available as
CANopen specification CiA 301 a multi-channel version.
Support of status displays according to CiA 303-3 CANopen This version allows the user to implement multiple, independent
indicator specification CANopen devices within one field device. NMT master or slave
Support for Layer Setting Services according to CiA 305 functionality can be configured independently on each of the chan-
Enables quick and easy development of CANopen devices nels with fully independent object dictionaries. It also supports the
(slave or master) parallel operation of different CAN controllers on each of the channels.
Modular software structure with comprehensive configuration
and scaling possibilities
High efficiency with minimum resource requirements "Zero OBJECT DICTIONARY & PROGRAMMING INTERFACE
copy" implementation
Clearly structured, simple programming interface for connection The object dictionary represents the interface between the application
of the application program and the communication interface. Each object dictionary entry can
Easy portability to alternative micro controllers be directly allocated a reference to a variable with application data.
Uniform interface between protocol stack and CAN driver, PDOs and SDOs directly access these application variables. There-
independent of the architecture of the CAN controller used fore, no changes to an existing application are required in order to
Multi-channel support integrate a CANopen protocol stack. User-specific call-back functions
can be connected to each application object and enable event-con-
* Optional Add-on Modules trolled signaling to the application when these objects are accessed.
This mechanism allows direct, application-specific reaction to
Application Programming Interface changes in the application data triggered on the bus-side. In addi-
tion, the possibility of saving and restoring configured data is also
LSS Flying SDO Local Object
supported.
Master/Slave Master* Manager SRD* Dictionary
NMT NMT SYNC EMCY Client SDO Server SDO PDO PROCESS- (PDO) AND SERVICE DATA OBJECTS (SDO)
Master Slave Handler Handler Handler Handler Handler
The CANopen Protocol Software supports asynchronous (with or
without event timer), synchronous (cyclic and acyclic) and on re-
CAN Driver/CAN Message Handler
quest (RTR) PDO transfer types. PDO-mapping may be implemented
CANopen Master/Slave Software statically or dynamically, depending on available resources and the
required reaction times. In addition, the protocol software supports
multiplex PDOs including scanner and dispatcher lists. Dummy map-
CANopen ping as well as variable inhibit times are also possible. Objects can
be mapped into several PDOs simultaneously. With SDOs, the trans-
fer types expedited, non-expedited (segmented) and block transfer
OVERVIEW OF FUNCTIONS are supported. The SDO response can be delayed at application level
for both read and write access. The application can check the data
The CANopen Protocol Software contains all functions required for written by SDOs for consistency before the target variables are over-
the implementation of simple CANopen master or CANopen slave written. The SDO transfer can be aborted if necessary.
devices according to the CANopen specification CiA 301.
NETWORK MANAGEMENT
SCALABILITY & HARDWARE-SPECIFIC ADAPTION
The CANopen software supports the boot-up defined in CiA 301
To insure a high degree of scalability and adaptability, the software with all network services including node guarding with or without
package is configured via central files. One configuration file allows life guarding (master monitoring), and, the heartbeat mechanism
to optimally adapt the CANopen functionality provided by the pro- with producer monitoring.
tocol stack to the given application, thus using the available
57
IDENTIFIER ALLOCATION Function Slave Master/Slave
Max. number server-SDO 127 127
By default, identifiers are allocated according to the predefined I/O Max. number client-SDO – 127
connection set, but, they can also be assigned by altering the rele- Max. number PDOs (Tx/Rx) 512 512
vant object dictionary entries. Dynamic PDO mapping x x
SYNC object C P/C
EMERGENCY object P P/C
MASTER FUNCTIONALITY TIME STAMP object C P/C
NMT functionality S M/S
Smaller CANopen systems frequently require only a simple master Node guarding, heartbeat x x
device to start the system, instead of a full CANopen manager. There- ID configuration according to x x
fore this CANopen software package enables the implementation of Predefined Connection Set
such a simple CANopen master with its own object dictionary. ID configuration via SDOs x x
A CANopen device implemented on this basis can work in a system NMT Start-up object (1F80h) x x
either as a slave or as a master and can be configured via the object Slave assignment list (1F81h) – x
dictionary with the aid of configuration tools. However, the soft- Status display according to x x
ware package only provides the basic functions for the NMT ser- CiA 303-3
vices. Functions such as the control of the system boot-up, checking Flying Master according to S M/S
CiA 302 optional optional
whether the correct devices are available, automatic download of LSS services according to CiA 305 S M/S
configuration data or also specific reactions to node failures are not
included and must be implemented by the user. C = Consumer; P = Producer; S = Slave; M = Master
The software package "CANopen Manager Software" is the appro-
priate basis for the implementation of full or more complex CAN-
open manager devices, and, for the development of programmable SUPPORTED PROCESSORS & CAN CONTROLLERS
devices and controls (PLC).
The CANopen Protocol Software is independent of hardware and
can be used on a large number of micro controllers and CAN con-
OPTIONAL FUNCTIONALITY trollers. For processors of the following manufacturers (valid at time
of printing of this catalog), IXXAT supplies reference implementati-
To supplement the CANopen standard software, the following ons including project files for the development environments used
optional functions are available on request: which can be run directly on the corresponding development plat-
forms:
Flying master, startup-capable device or NMT-master-capable
device according to CiA 302 Atmel
SDO manager (SDM), SDO requesting device (SRD) according Freescale
to CiA 302 Fujitsu
Infineon
IMPLEMENTATION WORK Microchip
Philips
The CANopen Protocol Software is delivered as hardware-indepen- Renesas
dent C-source code and is always tested with the latest CANopen STMicroelectronics
conformance test software from the CiA. Texas Instruments
The documentation and example programs supplied with the soft- x86 Architecture
ware enable a quick start with the CANopen software. Project files
are supplied with the example programs that allow direct integra- A complete overview of all available versions can be found on the
tion in the corresponding development environments of the com- web page under the following link:
piler manufacturers. All example programs can be run directly on a www.ixxat.de/canopen_stack_available_versions_en.html
reference platform (evaluation board of the CPU manufacturer or
IXXAT interface board). Adaptation to the target hardware can nor- Adaptation of the CANopen software to processors that are not
mally be carried out in a few days. The sample programs facilitate directly supported can be carried out in a few days provided a CAN
implementation of a user's application. driver is readily available, on the basis of a universal ANSI C version.
IXXAT will be pleased to make the relevant adaptations of the CAN-
AVAILABLE VERSIONS open software for you.
The CANopen Protocol Software is available in two different packa-

ges with different scopes of functions: Slave and Master/Slave. The
Master/Slave package supports the complete functionality and can
be used for the development of both slave devices and simple ma-
ster devices. The range of functions of each package is described in
the following table:
58
Source code
Company license (restricted to company site and business field)
Detailed documentation
Example programs
Technical support
SUPPLEMENTARY SERVICES
(not included with the scope of delivery)
Maintenance agreement
IXXAT offers a maintenance agreement to supplement the software
package. The maintenance agreement consists of the following
services for the duration of the agreement:
Free updates
Technical support, including general questions concerning
CANopen
ORDER NUMBERS
Single channel version
1.02.0122.TTDDC CANopen Slave Protocol Software

(Versions on request)
1.02.0124.TTDDC CANopen Master/Slave Protocol Software
Multi channel version
1.02.0222.TTDDC CANopen Slave Protocol Software

1.02.0224.TTDDC CANopen Master/Slave Protocol Software
59
CANopen OVERVIEW OF FUNCTIONS
Manager Software The CANopen Manager Software is a powerful software package

which enables the implementation of CANopen master or CANopen
manager devices. Devices implemented in this way can be operated
Software package for the development as master- and as pure slave devices. The software package is based
of CANopen master devices on the following CANopen standards:
CiA 301 – CANopen application layer and communication profile

HIGHLIGHTS CiA 302 – CANopen additional application layer functions
CiA 405 – CANopen interface and device profile for IEC61131-3
Suitable for the implementation of CANopen devices with programmable devices
master and/or slave functionality
Comprehensive functionality based on the CANopen The application interface consists of process data image, command
specification CiA 301 interface, and a comprehensive diagnostics interface that allows for
Complete CANopen master functionality with standardized a straightforward integration of application programs and PLC run-
boot-up procedure based on CiA 302 (can be switched off time systems. Since all necessary interfaces and functions are inclu-
during run-time) ded in the software package, the user no longer has to take care of
Supports CANopen slave devices according to CiA 301 Versions the time consuming development and testing of CANopen specific
3 and 4 functions (such as control of the system boot-up, testing whether
Support for hot-swapping of CANopen devices in the running the correct devices are present, automatic download of configuration
system data or specific reaction to device failures), as it would be the case
Simple integration of application program via the data inter- when using other CANopen software packages.
face providing process data image according to CiA 302
Comprehensive diagnostics interface
IEC61131-3 support based on CiA 302 and CiA 405 DATA INTERFACE AND PROCESS IMAGE
Local Object Dictionary with integrated management of net-
work variables according to CiA 302 and CiA 405 The exchange of process data with the application program occurs
All functions can be parameterized via Object Dictionary via a data interface. This provides a complete decoupling of appli-
Automatic configuration of devices with system start-up cation and communication software, and enables the implementa-
(plug&play) by integrated Configuration Manager tion of either single processor or multi processor based systems. The
Easy integration with IEC61131-3 run-time systems (with and application programming interface consists of the following areas:
without operating systems)
Process data image: The I/O data exchanged between the applica-
tion and CANopen manager are passed via a process data image
which is managed according to CiA 302 and CiA 405 via network
variables.
Command Diagnostic/Error
Process Image
Interface Interface Command interface: The command interface provides the applica-
Application Programming Interface
tion with all necessary functions for the control of the CANopen
manager. This includes commands for initialization, checking the
device and system status, and, for the implementation of function
Process Image modules according to CiA 405.
Local Network Manager/Scanner
Control/ Manager Configu-
CMD ration Client SDO interface: This interface enables the execution of SDO
Boot-up
Handler Procedure & Manager requests by the application.
Error Control Local Object
Dictionary
Event interface: This interface notifies the CANopen manager appli-
cation of important events in both the device and in the system.
SYNC EMCY NMT NMT Client SDO Server SDO PDO
Handler Handler Master Slave Handler Handler Handler
Diagnostics interface: The diagnostics interface allows the appli-
cation to obtain information on all system devices at any time.
CAN Driver/CAN Message Handler
Standard CANopen Master/Slave Software
CANopen
Master/Manager Software
CANopen
60
NMT MASTER, STANDARDIZED BOOT-UP PROCEDURE SUPPORT OF IEC611631-3 RUN-TIME SYSTEMS
The NMT master is able to control and monitor up to 126 slave de- Both the data interface and the program structure allows for the
vices. It controls the system start-up according to the standardized simple integration of the CANopen Manager Software with PLC run-
boot-up procedure defined in CiA 302. This boots a CANopen system time systems such as ProConOS from KW-Software.
according to a specified sequence with a variety of options such as
a system consistency check (check of all devices present in the system
for device parameters like manufacturer, device type, revision num- SCALABILITY & HARDWARE SPECIFIC ADAPTATION
ber, serial number), automatic download of configuration data (by
configuration manager), re-boot of a device or the system after a Adaptation of the CANopen Manager Software to the hardware is
failure, differentiation between mandatory and optional devices, done in a central file. The resource requirements can also be controlled
hot-swapping of devices, etc. The software supports devices accor- and adjusted via a configuration file, for example by adapting the
ding to CANopen versions 3 and 4. In addition, the NMT master also size of the process image, the number of available TPDOs, RPDOs,
has an automatic boot-up procedure. The current system configu- network variables and of client or server SDOs to the applications
ration is independently determined and both process data image requirements. Furthermore, the configuration file determines which
and the network variables are automatically created. Node monito- function units of the CANopen Manager Software should be present
ring is carried out either by node guarding or heartbeat. The NMT in the executable that will be installed on the target hardware.
master can be completely configured via object entries according to
CiA 302. The master function can be switched off at run-time,
allowing the device to also work as a CANopen slave. IMPLEMENTATION
The CANopen Manager Software is delivered as C source code. The

PROCESS- (PDO) AND SERVICE DATA OBJECTS (SDO) documentation and the example program included in the delivery
enable a quick start with the software package.
The PDOs support the transmission modes asynchronous (as an
option with event timer), synchronous (cyclically and acyclically)
and on request (RTR Only). For the PDO Mapping, byte-granularity SUPPORTED PROZESSORS, CAN-CONTROLLER & COMPILER
is the standard. Dummy mapping is also available, as well as variable
inhibit times. Objects can be entered in several PDOs simultaneously. The software package is supplied as standard C code and can there-
SDOs are available both as Client- and as Server-SDOs and support fore be run on a wide range of processors.
the transfer types expedited, non-expedited (segmented). The num- An overview of the supported micro controllers is on our website.
ber of SDOs and PDOs which can be used is limited only by the
resources available.
SCOPE OF DELIVERY
LOCAL OBJECT DICTIONARY Source code

Software license
The CANopen Manager Software implements its own object dictio- Detailed manual
nary. This contains object entries specified in CiA 301 and the Example programs
management of network variables according to CiA 302 and CiA Technical support
405. In addition, entries according to CiA 302 are available for the
configuration of the NMT master. This enables the complete confi-
guration of the CANopen manager via the network. The application SUPPLEMENTARY SERVICES
program can also access the local object dictionary via the client (not included with the scope of delivery)
SDO interface. In this way a configuration can be implemented via
local user interfaces (e.g. display or serial interface). Maintenance agreement
CONFIGURATION MANAGER services for the duration of the agreement:
The configuration manager is a central functionality for the auto- Free updates
matic configuration of CANopen slave devices within the system. Technical support, including general questions concerning
According to CiA 302, the configuration manager stores the confi- CANopen
guration data of slave devices. When starting slave devices, these
can be parameterized automatically. This enables both the easy ser- ORDER NUMBER
vicing and simple replacement of defective devices in a system. (Versions on request)
Non-volatile memory is required for storing the configuration data.
1.02.0175.TTDDC CANopen Manager Software – Product license
61
CANopen PROGRAMMING INTERFACE & OBJECT DICTIONARY
RealTime Software The CANopen Real-Time Interface (CRT) is the programming inter-
face between the application tasks and the CANopen protocol stack.
The CRT implementation is based on mailboxes, allowing for a non-
CANopenRT – Real-time-capable CANopen Soft- blocking internal communication. An application may consist of
ware for the Development of CANopen Devices several tasks which can use the CRT independently of each another.
Data is exchanged between application and CANopen software via
the object dictionary. Each object dictionary entry can be directly
HIGHLIGHTS allocated a variable reference with application data. In a similar
fashion, each application object can also be allocated a user-specific
Comprehensive range of functions based on the CANopen call-back function. This allows for fast, event-controlled reaction of
specification CiA 301 the application when these objects are accessed. Simultaneous ac-
Enables quick and easy development of CANopen devices cess to the data of the object dictionary by the application and CAN-
(slave and master) open software is controlled by semaphores.
and scaling possibilities
Integration in the operating system of the target system with PROZESS-(PDO) & SERVICE-DATA-OBJECTS (SDO)
universal interface
Easy portability to alternative micro controllers and CAN The CANopenRT software supports the PDO transfer types asyn-
controllers chronous, synchronous and on request. PDO-mapping can be reali-
Multi-channel support zed either statically or dynamically. In addition multiplex-PDO,
High efficiency dummy mapping and variable inhibit time are available. Objects
may be mapped into several PDOs simultaneously. For SDOs, the
transfer types expedited, non-expedited (segmented) and block
Application
transfer are supported.
MASTERFUNCTIONALITY & NETWORK MANAGEMENT

Object
GOE* CRT (CAN Real-time Interface)
Dictionary
The CANopenRT software supports the boot-up message introduced
NMT NMT SYNC EMCY SDO PDO with version 4 of the CANopen specification. It provides supports for
Master Slave Handler Handler Handler Handler all network services including node guarding with or without life
guarding (master monitoring), and heartbeat with producer moni-
CAN DLL* (Operating System Driver Interface) toring as defined in CiA 301. Functionality, such as control of the sys-
tem boot-up, automatic download of configuration data and
CANopenRT Software specific reaction to node failures is not included but can be imple-
mented by the user based on the available NMT services.
Operating System CAN Driver
GOE: Generic Operation Environment

CANopen * Operating System dependant
OPERATING SYSTEM SUPPORT
All operating system services are encapsulated in virtual OS calls,

which are contained in a central module (Generic Operating Environ-
FUNCTIONAL OVERVIEW & SOFTWARE ARCHITECTURE ment, GOE). The CANopenRT software can be easily adapted to
alternative operating systems. Only the support for semaphores and
The CANopenRT software contains all functions necessary for im- mailboxes, or message queues, is required.
plementing slave or simple master devices according to the CAN-
open specification CiA 301.
In the CANopenRT software package, a central CANopen task is SCALABILITY & HARDWARE SPECIFIC ADAPTATION
responsible for processing all protocol related functions and
services. This task is triggered as soon as there are pending tasks, The CANopenRT software package provides services and mecha-
and, processes only these tasks. nisms defined in the specification CiA 301. To maximize scalability
and resources’ conservation, and, to optimize adaptation to the
given application, the software package is configured in central files.
62
IMPLEMENTATION WORK
The CANopenRT protocol software is delivered as a hardware-inde-

pendent, standard C-source code. The documentation and example
programs supplied with the software allow for a quick start with
the CANopen software. If the operating system used has its own
CAN driver, a wrapper for this driver is required to adapt the native
driver interface of the operating system to the driver interface ex-
pected by the CANopenRT software package.
AVAILABLE VERSIONS
The CANopenRT Protocol Software is available in slave master/slave

versions. The master/slave package has the complete range of
functions and can be used for the development of both pure slave
devices and simple master devices. The CANopen functionality avail-
able with the CANopenRT software fully corresponds to that avail-
able with the CANopen Protocol Software.
SUPPORTED OPERATING SYSTEMS
IXXAT directly supports the CANopenRT software package on a

number of different operating systems. In addition optimized ver-
sions for other operating systems are available directly from the
manufacturer of those systems. Please consult the IXXAT home page
for an up-to-date list of supported target operating systems.
SCOPE OF DELIVERY
Source code
Software license
Detailed manual
Sample programs
Technical support
OTHER SERVICES
(not included with the scope of delivery)
Maintenance agreement
services for the duration of the agreement:
Free updates
Technical support, including general questions concerning
CANopen
ORDER NUMBERS
(includes both single and multi-channel versions)
1.02.0212.xxxxx CANopenRT Slave Software

1.02.0214.xxxxx CANopenRT Master/Slave Software
63
CANopen REDUNDANT COMMUNICATION
Maritime Software The redundancy necessary for single point of failure tolerance requires
that CANopen devices for maritime applications are connected to
physically independent bus lines via two CAN controllers. In fault-
CANopen Maritime - Software for the development free operation, transmission occurs on both CAN lines. The IXXAT
of CANopen devices for maritime applications and CANopen Maritime Software provides complete support of the red-
areas of application which require redundant com- undancy mechanism according to CiA 307, including transmit-side
munication mechanisms according to CiA 302. delay time monitoring.
Process data is always transmitted on both transmission lines. In
the event of a failure of one line, the system continues working
HIGHLIGHTS without interruption and data loss. Due to interferences or con-
junction on the CAN bus, transmissions may occur at different times
Comprehensive range of functions based on the CiA 307 CAN- on both lines despite simultaneous transmit requests. The integrated
open framework for maritime electronics, CiA 301 CANopen delay time monitoring prevents a more recent message from being
application layer and communication profile, and CiA 302 overwritten by an older message.
CANopen additional application layer functions
Enables quick development of CANopen Maritime slave or
master devices NETWORK MANAGEMENT AND FUNCTIONALITY
and scaling capabilities The CANopen Maritime Software implements independent NMT
Clearly structured, simple programming interface for integration state machines for both CAN lines according to CiA 307. Flying ma-
in application programs ster and startup-capable-device functionality according to CiA 302
Easy portability to alternative micro controllers and CAN as well as the heartbeat mechanism are supported by default.
controllers
PROGRAMMING INTERFACE AND OBJECT DICTIONARY

OVERVIEW OF FUNCTIONS
Based on the implementation of the CANopen Protocol Software,
Building on many years of experience with CANopen based commu- the CANopen Maritime Software supports all object dictionary
nication systems, IXXAT has developed a specification for CANopen entries available with the CANopen Protocol Software. It also sup-
applications in the maritime sector and the CANopen Maritime ports object dictionary entries for the extended heartbeat mecha-
Software in cooperation with leading manufacturers of maritime nisms, the redundancy configuration parameters, and the flying
automation systems. master timing parameters according to CiA 302 and CiA 307.
The software package implements the CANopen framework for
maritime electronics, CiA 307, and is specially designed for the in-
creased safety requirements in maritime automation. The require- SCALABILITY & HARDWARE SPECIFIC ADAPTATION
ments of maritime classification organizations demand a single
point of failure tolerance of the communication system. This is sup- Since the CANopen Maritime Software package already provides all
ported via the redundant communication on two independent CAN services and mechanisms defined in the CANopen framework for
lines and by the flying master concept. maritime electronics, the developer can concentrate fully on the
creation of the actual application. To insure a high degree of scala-
bility and adaptability, the software package is configured centrally.
The protocol stack can be adapted to the given application in central
configuration files, thus allowing for efficient use of available
Host Controller resources.
TIME REQUIRED FOR IMPLEMENTATION

CAN CAN
Controller 1 Controller 2
The CANopen Maritime Software is supplied as a hardware-inde-
pendent C source code. The supplied documentation and sample
Bus Driver Bus Driver programs allow for a start with the CANopen Maritime Software.
Project files are supplied with the example programs. Adaptation to
the target hardware can typically be carried out within a few days.
DCL (Default CAN Lines) Implementation of the user application is facilitated with the example
programs.
RCL (Redundant CAN Lines)
64
AVAILABLE VERSIONS ORDER NUMBERS
The CANopen Maritime Software is available as slave or master/- 1.02.0280.00000 CANopen Maritime Software Slave product line
slave version. The master/slave package contains the complete license (Maintenance contract required)
scope of functions and can be used for both the development of 1.02.0281.00000 CANopen Maritime Software Master/Slave product
pure slave devices and for simple master devices. line license (Maintenance contract required)
Function Slave Master

Max. number of server SDOs 127 127
Max. number of client SDOs – 127
Max. number of PDOs (Tx/Rx) 255 255
Dynamic PDO mapping x x
Maritime multiplexed PDOs x x
SYNC objekt C P/C
EMERGENCY objekt P P/C
TIME STAMP objekt C P/C
NMT functions S M/S
Heartbeat P/C P/C
NMT Start-up-Object according to
x x
(Object 1F80h) CiA 302
Slave assignment list
– x
(Object 1F81h) according to CiA 302
Redundant communication, active
x x
CAN line mechanism according to CiA 307
Independent NMT state machines
x x
according to CiA 307
NMT master monitoring x x
Startup-Capable-Device (S) and
Flying-Master (M/S) according to x x
CiA 302 and CiA 307
C = Consumer; P = Producer; S = Slave; M = Master
SUPPORTED PROCESSORS AND CAN CONTROLLERS
The CANopen Maritime Software is hardware-independent and can

be used on a large number of micro controllers and CAN controllers.
For a number of processors, IXXAT supplies reference implementa-
tions including project files for the development environments used.
Please consult the IXXAT home page for an up-to-date list of ready
to run target systems. Other targets can be made available upon
request.
SCOPE OF DELIVERY
Source code
Software license
Detailed manual
Sample programs
Technical support
65
CANopen Master API An application program based on the CANopen Master API can be
used without modifications on various active IXXAT CAN interfaces.
The CANopen Master API supports multiple CAN boards in parallel,
Software package for the development of CANopen and depending on the hardware, up to two independent CAN channels
service and test applications under Windows per card.
Currently the following IXXAT CAN interface modules are supported

FUNCTION OVERVIEW under Windows 2000/XP:
The CANopen Master API is a software package which allows easy iPC-I 165 (ISA)
development of CANopen master applications on a PC using Windows. iPC-I 320/PCI
iPC-I XC16/PCI
The software package consists of two components: The CANopen tinCAN161
master software (firmware) for an active IXXAT CAN interface, and, USB-to-CAN II
a programming interface in the form of a Windows DLL. The firm- USB-to-CAN compact
ware implements a complete CANopen master and manages the
CANopen communication processes (transmitting and receiving For information on availability of discontinued IXXAT hardware or
SDOs with timeout monitoring, transmitting and receiving PDOs, under other operating systems, please contact the IXXAT sales staff.
SYNC generation, emergency handling, network management and
cyclic node guarding, heartbeat monitoring) completely indepen-
dently, leaving the PC available for the application program. CONTENTS OF DELIVERY
The application accesses data of remote CANopen devices via a CANopen Master API software
function interface which supports both SDO and PDO services. Run-time license for one installation
Compared to an intermediate data storage in form of a local object Manual, demo applications
dictionary, the advantage of this approach is that the data is imme- Technical support
diately available to the application and can be directly processed
without introducing any further latencies.
ORDER NUMBER
The application thus has full control of all CANopen services which
allows the user to also implement complex control algorithms. There- 1.02.0132.00000 CANopen Master API
fore, the CANopen Master API is suitable for both the development
of control programs and for the implementation of service and test
programs.
FUNCTIONALITY
Transmitting and receiving of client SDOs with unlimited data

length (expedited, non-expedited, block transfer)
Transmitting and receiving PDOs (synchronous and asynchro-
nous)
Receiving emergency messages
Transmitting sync messages
Transmitting the time stamp message
NMT master functions for control of boot-up and node guarding
or heartbeat
66
CANopen Manager API FUNCTION OVERVIEW
The IXXAT CANopen Manager API provides a comprehensive appli-

Software and hardware package for the implemen- cation programming interface for a CANopen manager which is
tation of complex PC-based CANopen control running locally on the micro controller of the supported IXXAT CAN
solutions interface. Every effort has been made to provide the full scope of
functionality offered by the CANopen manager to a PC application
under Microsoft Windows. Thus, the PC application has full control
Combined with the iPC-I XC16/PCI CAN interface card, the CAN- over the process of network initialization and the slave boot-up
open Manager API represents an ideal basis for the implementation process.
of complex PC-based CANopen control solutions. This package is
also suitable for integration with IEC 61131-3 runtime environments The programming interface implemented by CANopen Manager API
based on Microsoft Windows PC-platforms. Since the CANopen pro- is divided into function categories. Each cover a clearly defined sec-
tocol mechanisms are processed on the CAN interface card's micro tion of the overall functionality provided:
controller, the full PC processing capacity is available to the appli-
cation. Basic functions for initialization, software or hardware
configuration
Functions for network management
HIGHLIGHTS Functions for management of the local object dictionary
and for running SDO services
Comprehensive range of functions based on the current Functions for data exchange by means of process data image
CANopen specifications Functions for state monitoring and diagnostics
Full CANopen master functionality including support of the
standardized boot-up procedure
Automatic configuration of devices on system start-up DATA INTERFACE AND PROCESS MAP
(plug & play) thanks to integrated configuration manager
Local object dictionary with integrated management of net- The exchange of process data with the application program is carried
work variables including the option to create application out via a data interface. This allows a complete decoupling of ap-
specific objects plication and communication software. The data interface consists
Support of CANopen slave devices in accordance with DS301 of the following areas:
versions 3 and 4
Support for hot-swap of CANopen devices in a running system Process data image: I/O data and other process parameters received
Simple integration of the application program via a Microsoft and to be transmitted via PDOs are transferred from the application
Windows DLL with C function interface to the CANopen manager and vice versa via the process data image.
Communication between PC application and firmware via process The organization of the process data image is in accordance with
data image, command interface and diagnostics interface CiA 302 and CiA 405 by means of network variables.
All functions can parameterized locally via the object dictionary
Command interface: The command interface provides the appli-
cation with all necessary functions for the control of the CANopen
manager. These include commands for initialization and checking of
Client Application the device and system state.
CANopen Manager API DLL Client-SDO interface: This interface allows access to remote slave
devices from the user application.
Cmd Cmd CSDO CSDO Diag PI input PI output Event interface: The CANopen manager is informed of important
Req Res Req Res
Queue Queue Queue Queue Buffer Buffer Buffer events in the device and the system via this interface.
Diagnostics interface: This interface allows the application to

obtain information at any time on the state of all devices in the
CANopen Manager Firmware on Microcontroller system.
67
NMT MASTER
The NMT master implemented in the CANopen manager is able to

control and monitor up to 126 slave devices. The system is started
according to the standardized boot-up procedure defined in CiA
302. This boots a CANopen system in a pre-defined sequence while
checking all devices in the system for vendor, device type, version
number and serial number. Automatic download of configuration
data (by the Configuration manager), restart of a device or of the
system in the event of a fault or after failure of the device, diffe-
rentiation between mandatory and optional devices as well as hot
swapping of devices is also available. The NMT master supports
CANopen devices according to both version 4 and version 3 of the
specification. In addition, the NMT master supports an automatic
configuration mode. This automatically determines the current
system configuration and automatically creates the process data
image and network variables. Device monitoring can either be car-
ried out via node-guarding or heartbeat. The NMT master can be
configured completely via object dictionary entries in accordance
with CiA 302.
IMPLEMENTED SPECIFICATIONS
CiA 301 – CANopen application layer and communication profile

CiA 302 – CANopen additional application layer functions
CiA 405 – CANopen interface and device profile for IEC61131-3
programmable devices
SUPPORTED TARGET HARDWARE & OPERATING SYSTEMS
Windows 2000/XP, iPC-I XC16/PCI interface board
SCOPE OF DELIVERY
CANopen Manager API software

Run-time license for one installation (basic license required)
Manual
Technical support
ORDER NUMBER
1.02.0135.00000 CANopen Manager API (Basic license)

1.02.0134.00000 CANopen Manager API (Following single license)
68
CANopen For entry-level users of CANopen devices and systems, the program
offers client modules, which allow network configuration directly on
ConfigurationStudio the application level and hide all CANopen configuration data, such
as PDO mapping, and the assignment of CAN identifiers. In this
scenario, the user is only responsible for connecting input and out-
Comfortable Project Management and Configura- put, or I/Os with network variables. The CANopen Configuration-
tion Tool for CANopen Devices and Systems Studio is also prepared for integration with programming
environments of CANopen PLCs.
OVERVIEW The modular design and the capability to integrate additional client
modules with specific configuration functionality and options, in-
The CANopen ConfigurationStudio is a powerful tool for project cluding those programmed by the user, allow for a quick and easy
management and configuration of CANopen devices and systems. way to meet specific customer requirements.
Special features of the tool include an ergonomical user interface,
modularity, expandability, and the underlying database concept. The basis of the ConfigurationStudio is a database-oriented manage-
Based on a client-server structure, the tool is extremely flexible and ment of all configuration and device data required by the user.
can be customized using various program modules (client modules). A very fast import function loads new device data from correspon-
ding EDS files into the database.
CANopen devices and systems are configured using various client

modules with different functionality. Access of the CAN bus is pos-
sible via an integrated CANopen client module, which also provides
NMT and LSS functionality.
HIGHLIGHTS
Automated PDO mapping and linking

Support for network variables according to CiA 302 and CiA 405
Configuration of CANopen manager devices according to
CiA 302
Structured and simple access to device data
Prepared for integration with IEC 61131-3 CANopen PLC pro-
gramming environments
Fast database-oriented management of all configuration and
device data from EDS and DCF files
User-expandable functionality (requires the developer kit)
FUNCTIONALITY
Project window
In the project window, the CANopen system is displayed in a concise
tree structure in which devices can be grouped according to their
respective functionalities. The project window also starts the corres-
ponding client modules for a selected device, device group, or net-
CANopen ConfigurationStudio work. Depending on the client module, the module can be started
any number of times, allowing for simultaneous display and modi-
The range of applications of the CANopen ConfigurationStudio fication of the object dictionaries of multiple devices. It is also
stretches from an easy to use device configuration tool which possible to work on any number of project windows simultaneously.
allows the user to comfortably manage and configure CANopen
devices to a complex network configuration tool with automated
PDO mapping and linking functions.
69
Network variables according to CiA 302 and CiA 405
Another feature of the object linker is the support for devices imple-
mented according to CiA 405. These devices constitute CANopen
PLCs with programming environments according to IEC61131-3. The
object linker allows any network variable definition according to the
dynamic channel descriptions contained in the EDS files. Network
variables provide the interface between the data contained in the
CANopen system and the actual program within the control. Net-
work variables can be created manually or by using the drag & drop
functionality. The defined network variables may be connected with
actual input and output data in the matrix. In this case, the object
linker is also responsible for calculating PDO mapping of the control.
CANopen Device Configurator
Editing individual device records

To manually edit the configuration data for a CANopen device, the
program provides two client modules, the object dictionary browser
and the device configurator.
The device configurator presents the communication area (1000h-

1FFFh) data in concise and easy to use input masks. The user no
longer has to know the index and sub index designations or data
formats of individual records. Instead, the desired values can be
entered directly via radio buttons, check boxes and sliders. PDO map-
ping is accomplished with a drag & drop feature.
The object dictionary browser displays the object dictionary of a

selected device in an easy to understand tree structure with index,
sub index and object names. When an object is selected, all associated
attributes are displayed, and the current value of the object can be
modified. The change is immediately stored in the database and is
available for future module configuration via a CAN download.
CANopen Visual Object Linker
Automatic PDO mapping and PDO linking

When dealing with larger systems, special knowledge is required for
manual PDO mapping and linking, and the careful selection of PDO Integration of PLC programming environments according to
connections becomes very time-consuming. The object linker of the IEC61131-3
CANopen ConfigurationStudio offers a measurable improvement by You can integrate PLC programming environments in one of two
supporting fully automated mapping/linking of PDOs in only a few ways: either by exchanging DCF and NVX files as defined in CiA 405,
steps. All devices used in the project are presented in a matrix, sorted or, by directly connecting the programming environment with the
according to input and output data. The desired connections bet- database server. The first approach is very simple, provided the PLC
ween input and output devices are presented in the matrix with programming environment supports the interpretation of DCF and
flags and are automatically calculated by the object linker. This NVX files. The second solution requires modification to the program-
eliminates time-consuming planning and optimization of PDO ming environment, but, it has the advantage that the programming
mapping and identifier assignment. tool can immediately read and write the necessary data to and from
the database. In addition, the tool can save its own data, such as
source code, binary code or project information, in the database.
As a result, all project data is available in a single folder.
70
Database and database server HARDWARE REQUIREMENTS
The core of the ConfigurationStudio is a fast, object-oriented data-
base, which contains all CANopen device and system data normally IXXAT CAN interface card and VCI V2 CAN driver
contained in separate EDS and DCF files. The key advantage of this
solution is the fact that all data is accessible immediately after pro-
gram startup, eliminating waiting to import EDS and DCF files. Client SCOPE OF DELIVERY
modules access the database via a database server that processes
and coordinates each access. It insures that all client modules Software for Windows 2000/XP
simultaneously processing information receive updated data values. Single-user license
Manual
The object-orientated database approach offers the advantage of
allowing customized client modules to save their proprietary data in
the database. ADDITIONAL INFORMATION
EDS, DCF import and export A free demo version of the of the ConfigurationStudio is available on
A very efficient import and export feature for EDS and DCF files, the IXXAT homepage.
allows the user to set-up new project devices inside the database.
It is also the default interface with other CANopen tools. EDS and ORDER NUMBER
DCF files can be processed quickly, even with large file sizes.
1.02.0162.00000 CANopen ConfigurationStudio
Bus access, NMT and LSS functionality
CANopen network access is used to download device and system
data. This client module establishes a connection between the Con-
figurationStudio and the CAN network via an IXXAT CAN interface
card. This enables you to load data that has been edited offline into
the CANopen devices on the CAN bus. You can also load the current
configuration of a device connected to the bus into the database, or
compare it with the configuration contained in the database.
Also available are functions for starting and stopping a system,

performing system scans to determine existing nodes, functions for
calling on the store, restore function of a device, functions to
start/stop/reset PLC programs, and LSS functions for parameteriza-
tion of bit rate and node number of a CANopen device are available.
Extension with customer specific features

The modular client/server architecture allows users to easily add
supplementary functions to the ConfigurationStudio. A developer
kit containing interface documentation, software modules required
for programming, and program examples is provided for this purpose.
71
CANopen Configuration DESCRIPTION OF FUNCTIONS
Framework Catalogue
A catalogue system enables device description files (EDS files) to be
imported and stored in a catalogue database. This is useful if CAN-
Component for integration of a projecting and open devices are used repeatedly in projects since a device can then
configuration function for CANopen systems be selected directly in the catalogue and added to a project and does
in OEM tools not have to be imported to an external device description file, saving
time. Therefore, it is also possible for an OEM to define which CAN-
open devices the customer can use in the OEM systems, thus preven-
OVERVIEW ting the customer from using unauthorized devices.
The CANopen Configuration Framework allows for the integration Project database
of a projecting and configuration function in OEM tools such as Projects are managed in the form of a database. This means that the
PLC programming environments or other system tools while main- data and descriptions of the individual devices are stored in binary
taining a uniform look and feel. form, making faster access to this data available when opening the
projects themselves or when opening projects with a large number
The framework provides all the necessary components and mecha- of devices. In addition, the project database insures consistency of
nisms required for the creation and management of configuration the data.
data of an CANopen project. The framework does not have its own
user interface. This is to be provided by the OEM tool. This offers Automatic PDO-mapping and PDO-linking
the following advantages: all system data is centrally accessible in With larger systems, the specialized know-how required for PDO-
the interface and can be centrally edited, the OEM tool has a uni- mapping/linking and the time-consuming, careful selection of the
form look and feel, and, CANopen-relevant configuration data can individual PDO links requires great effort. The CANopen Configuration
be displayed to the user at system level in abstracted form. This Framework supports the creation of PDO-mappings and correct
makes it considerably easier for the user to understand and work allocation of the PDOs to the devices (PDO-linking) by means of an
with the OEM tool. The Framework is integrated in the OEM tool via automatic system. For this, the user of the OEM tool must only
a COM-based interface provided by the framework. define how the input and output data of the individual devices are
to be linked with each other, or with PLC variables (network varia-
The CANopen Configuration Framework is based on fast, database- bles). This allows the user to create links without detailed knowledge
oriented management of all configuration and device data. Data of of CANopen.
new devices is either taken from a device catalogue or transferred
to the database from the CANopen device description files (EDS Network variables in accordance with CiA 302/CiA 405
files) via a fast import function and is then available in binary form. Another function provided by the CANopen Configuration Frame-
The advantage of this concept is the extremely fast availability of all work is the definition and management of network variables in
configuration data which is normally only stored in independent accordance with CiA 302 or CiA 405. Network variables are used by
device description files. This means that there are no long waiting devices that provide data of an application running on the device to
times when either starting the configuration tool or opening an the CANopen system in the form of a process data interface. This is
existing project. especially relevant with PLCs. With these network variables it is pos-
sible to link the data (variables) of the application program with data
The CANopen Configuration Framework runs on the operating of other devices. Based on these links, the CANopen Configuration
systems Windows 2000 and Windows XP. Framework can then also automatically calculate the PDO-mapping
and PDO-linking.
HIGHLIGHTS
EDS/XML
Imp/Exp
Automatic PDO-mapping and PDO-linking
Support of network variables in accordance with CiA 302/CiA 405
Catalog Device
Clear and simple access to the device data Database Catalogs
Fast, database-based management of all configuration and
device data from device description files (EDS and DCF files) Configuration Project Projects
Framework
Management of any number of device description files in one Interface
Datebase
catalogue
COM-based interface for simple integration in OEM tools PDO Linker
Config File
Config File
Generator
72
Import / export of device description files (EDS/DCF) CANopen Device
A powerful and especially fast import and export of device descrip-
tion files (EDS and DCF files) enables importing and exporting of Manager
devices to and from the catalogue and exporting of configuration
data of individual devices from a project (as a DCF file). At the same
time this is the standard interface to other CANopen tools. Even very Powerful service and diagnostics tool for service
large device description files are processed quickly and, the file size staff and developers
is not limited.
Generation of configuration data files OVERVIEW

After completion of projecting or configuration of a CANopen
system, the CANopen Configuration Framework creates a configu- The IXXAT CANopen Device Manager is a versatile and upgradeable
ration data file. This configuration data file is then normally sent to tool aimed at device test, diagnostics, and field service tasks. Built
the CANopen manager (master). This therefore configures itself and around a central component that manages the CANopen services
passes the embedded configuration data on to the individual devices while serving as the primary entry point for network definition, the
in the CANopen system during the system boot-up. The configura- CANopen Device Manager covers functionality like NMT node and
tion data file is created in the Concise DCF format. error control, SDO client (including block transfer with CRC), PDO pro-
ducer and consumer, SYNC and time stamp producer. It also offers
Programming interface concise DCF download and firmware download according to CiA 302,
The programming interface of the CANopen Configuration Frame- LSS master according to CiA 305, and, as an optional add-on, a
work is implemented as a COM interface. It provides various inter- Python-based scripting engine that allows the development of
faces for the management of the catalogue, of the projects and of powerful test applications.
the individual devices in a project. This enables simple integration of
the CANopen Configuration Framework in OEM tools.
CANopen Device Manager
HIGHLIGHTS
Comprehensive CANopen functionality including NMT node

and error control services, SDO client, PDO consumer and
producer
Support for SDO block transfer
LSS master functionality according to CiA 305
Configuration and firmware download according to CiA 302
Easy-to-use, intuitive user interface
Optional plug-in modules covering dedicated diagnostics or
service functionality that can be installed at run-time.
Customizable for specific service tasks
Python based scripting engine that allows the implementation
of even the most complex user applications
73
PLUG-IN MODULES SYSTEM REQUIREMENTS
The highlight of the IXXAT CANopen Device Manager is the support Microsoft Windows 2000/SP4, Windows XP/SP2
for plug-in modules that can be tailored to specific requirements of Microsoft .Net Framework 2.0
CANopen devices and systems. Plug-in modules can be dynamically IXXAT CAN interface card and VCI V3 CAN driver
installed at run time and can integrate seamlessly with CANopen
Device Manager. They may either implement a high-level abstraction
of functionality as described in the CiA device profile specifications, SCOPE OF DELIVERY
or, provide an entirely customized graphical user interface optimized
for the specific requirements of device commissioning or mainten- Software for Windows 2000/XP
ance tasks performed by a service staff. CodeMeter USB License key
User Manual
Single-user license
SDO SERVICES
Direct device access is supported by means of SDO (normal, expedi- ORDER NUMBER
ted, and block transfer). From the user point of view, SDO access to
the device is considerably simplified by an object dictionary browser 1.02.0157.00000 CANopen Device Manager
listing information contained in EDS files that can be assigned to 1.02.0158.00001 Python Script Engine for CANopen Device Manager
each device. Large data blocks can be directly written to or read from
a file, and can be optionally displayed in a separate dialog with both
ASCII and hexadecimal representation. To interrupt long transfer, an
SDO abort protocol can be specifically requested.
PDO SERVICES
The CANopen Device Manager supports PDO read and write services
as specified in CiA 301. During a device or a network scan, all pos-
sible PDOs of the detected devices are uploaded and both commu-
nication and mapping parameters are displayed in the form of a
summary list. PDO processing is performed by selecting any of the
configured PDO and requesting the corresponding PDO read or write
service. To allow for diagnostics and testing of synchronous PDO
transmission, the CANopen Device Manager supports single-shot or
periodic generation of SYNC message according to CiA 301, with
adjustable time periods of 1ms.
SCRIPT ENGINE
One of the most prominent features of CANopen Device Manager is

the availability of an optional script engine supporting IronPython.
IronPython is an implementation of the widely used Python language
that supports full integration with Microsoft’s .Net Framework. This
allows the user to implement complex, graphical user interface-
based test or service applications with support for advanced data
evaluation functionality.
74
CANopen EDS Editor CONTENTS OF DELIVERY
EDS-Editor for Windows 2000/XP

Tool for the easy creation and maintenance Single user license
of EDS files Manual
FUNCTIONALITY OVERVIEW ORDER NUMBER
The CANopen EDS Editor is a software tool that allows the comfor- 1.02.0165.00000 CANopen EDS Editor
table creation and maintenance of CANopen EDS files according to
CiA 306. An effective user interface provides device manufacturers
and system integrators with all the functions needed to create or to
edit existing EDS files. All inputs are evaluated for compliance with
the CANopen specifications to prevent generation of incorrect EDS
files.
CANopen EDS Editor
The program window is divided into two parts, showing the object
dictionary as a tree and the EDS sections with intuitive masks. For
each section a specialized mask is used to simply editing of the cor-
responding object data. Special masks are available for the file in-
formation, device information, dummy usage, and dynamic channel
sections. This allows easy and consistent set-up of EDS files.
The EDS editor also offers a powerful interface to read and write
EDS files, allowing the user to load large files in a very short time
while reducing the delay times during loading and writing.
The EDS editor is an indispensable software tool for all manufactu-

rers and users of CANopen systems who are involved in the creation
and maintenance of EDS files.
75
DeviceNet Introduction
DeviceNet is one of three open network standards (DeviceNetTM, DeviceNet is the implementation of CIP over CAN (Controller Area
ControlNetTM and EtherNet/IPTM), all of which use a common appli- Network).
cation layer, the "Common Industrial Protocol" (CIPTM). This common
application layer and open software and hardware interfaces allow The DeviceNet specification standardizes the physical connection
for a universal connection of automation components from the of DeviceNet nodes by defining Layer 4, Layer 3 (DeviceNet Trans-
fieldbus level over the control level to the enterprise level. port), Layer 2 (Usage of CAN), Layer 1 and Layer 0 (Physical Layer
The Family of CIP Networks is specified and published by ODVA and Transmission Media). Along with specifying connectors, cable
(Open DeviceNet Vendor Association – www.odva.org ) and CI (Con- types and cable lengths, communication-based displays, operating
trolNet International – www.controlnet.org ). elements and the corresponding housing labelling are also defined.
The Common Industrial Protocol presents communication and A DeviceNet network can run up to 64 nodes with baud rates of
application in the object model. Predefined objects facilitate the 125, 250 or 500 kBaud. The maximum length of a DeviceNet net-
data exchange between different devices and manufacturers. work can be up to 500 m (at 125 kBaud and usage of suitable
By creating various device profiles, additional standardization bene- cables). The devices can either be supplied via the DeviceNet net-
fiting the user was achieved. work (nominal 24 V) or have their own power supply.
CIP is a connection based protocol. It defines the exchange of I/O
data using I/O Messaging (or Implicit Messaging) as well as the ex-
change of general data for configuration, diagnostic and manage- Application Identity
ment via Explicit Messaging. CIP thus provides 4 essential functions Specific Object(s) Object
to the user:
Parameter Message Router Assembly
Common object model for application Object Object Object
Common communication model for data exchange

in the network DeviceNet
Object
Common configuration methods Explicit Messaging I/O Connections
Common device profiles UCMM
Connections
Connection Object
User Device
I/O Encoder Valves Drives SEMI Others CAN
Profiles
Network
CIP Application Layer
Application
Application Object Library
CIP Data Management Services

Presentation
Explicit Messages, I/O Messages The main field of application of DeviceNet is factory automation
with I/O-modules, valves, encoders, simple drives and controls (PLC).
Session CIP Message Routing, Connection Management Within the Family of CIP Networks DeviceNet covers the main part
of the applications where small to medium amount of data with
Encapsulation
Transport
DeviceNet ControlNet short to medium cycle times (1 ms to 500 ms) can be exchanged in
TCP UDP
Network
Transport Transport
IP
the network.
Classic Master/Slave applications are supported by the Predefined
CAN ControlNet Ethernet
DataLink
CSMA/NBA CTDMA CSMA/CD Master/Slave Connection Set.
The Unconnected Message Manager Port (UCMM) and the dynamic
DeviceNet ControlNet Ethernet
Physical
Physical Layer Physical Layer Physical Layer
creation of connections for Explicit Messages and I/O Messages
were specified for more complex slave devices and the support of
Peer-to-Peer networking.
76
Product Overview DeviceNet Software and Tools
IXXAT offers protocol software to develop DeviceNet devices as well Products that IXXAT sells as a partner
as tools and drivers for testing and analyzing DeviceNet devices and of Rockwell Automation:
networks.
DeviceNet Master & I/O Scanner Toolkit
With the DeviceNet Master & I/O Scanner Toolkit we provide the
DeviceNet Products from IXXAT customer with a powerful software package in order to implement
DeviceNet masters resp. I/O scanners and connect controls (PLC) to
DeviceNet Slave Protocol Software DeviceNet.
The DeviceNet Slave Protocol Software contains all important
functions required to implement a DeviceNet slave device in accor-
dance with the current DeviceNet specification from ODVA. Third Party Products that IXXAT recommends,
but does not sell:
DeviceNet Client API
The DeviceNet Client API is a software package that allows the simple ODVA DeviceNet Protocol Conformance Test Software
development of DeviceNet client applications, such as service and (www.odva.org)
test programs, under Microsoft Windows. The ODVA DeviceNet Protocol Conformance Test Software is recom-
mended for all companies that develop DeviceNet products them-
DeviceNet Module selves in preparation for certification by the ODVA. The software
The DeviceNet Module is an extension of the canAnalyser allowing can be operated on IXXAT PC/CAN interfaces in conjunction with
the user to record, interpret and analyse DeviceNet messages. the ODVA DeviceNet Conformance Test Driver.
ODVA DeviceNet Conformance Test Driver RSNetWorx for DeviceNet

This is a driver for the ODVA DeviceNet Protocol Conformance Test (www.software.rockwell.com/rsnetworx)
Software. RSNetWorx for DeviceNet is a powerful tool for both the configu-
ration and management of DeviceNet devices and networks.
DeviceNet Seminar
The basics of DeviceNet are taught in a 2-day seminar. The target
groups of the DeviceNet seminar are developers who implement
their own solutions based on DeviceNet and want a comprehensive
introduction to the technology.
77
DeviceNet DeviceNet Message Body Format
8/8 (8-bit Class ID and 8-bit Instance ID)
Slave Protocol Software
Fragmentation Protocol
Support of the Fragmentation Protocol for all Explicit
Software Package for the Development Messages and I/O Messages
of DeviceNet Slave Devices
Predefined Master/Slave Connection Set
Explicit Messages
FUNCTION OVERVIEW I/O Messages
- Poll
The DeviceNet Slave Protocol Software allows an easy and quick - Bit-Strobe
development of DeviceNet devices. All communication mechanisms - Change of State/Cyclic (unacknowledged/acknowledged)
defined in the DeviceNet Specification are supported, allowing the
developer to concentrate entirely on the actual application. Unconnected Message Manager Port (UCMM Server)
Dynamic Explicit Messages in Message Group 1 and 3
The modular structure of the protocol software allows an optimum
implementation into the target system. The software package can Peer to Peer I/O Messages
be adjusted to the application requirements through the use of a Dynamic I/O Messages in Message Group 1
configuration file. The available DeviceNet objects and functions
can be extended individually, new user-defined objects can be crea- Further Message Types
ted and specific device profiles can be developed. Device Heartbeat Message (Producer)
Device Shutdown Message (Producer)
A separate module contains all the CAN interface functions required Offline Connection Set
to access the CAN controller, allowing the user simple adaptation to
CAN controllers that are currently not supported by the software. User-specific Hardware Interfaces
The data transfer to and from the CAN controller is managed Switches for MAC ID and baud rate
through the use of queues in order to separate the interrupt level Module Status LED, Network Status LED or combined MN
from the program level. Status LED as well as I/O LED
The DeviceNet Slave Protocol software is delivered as C source code. The resources of the target hardware must include a timer inter-
Each version is tested for compliance by using the most current rupt for the protocol timing as well as a CAN controller interrupt.
ODVA DeviceNet Protocol Conformance Test Software.
The comprehensive documentation and sample program provided SUPPORTED TARGET SYSTEMS
allow users to quickly become comfortable utilizing the DeviceNet
software. The sample program will immediately run on a reference The DeviceNet slave protocol software is available for various micro-
platform (i.e. CPU manufacturer evaluation board or IXXAT PC/CAN controllers from Infineon, Intel, Philips, Atmel, Freescale and others.
interface). By referencing the sample program, any adjustment of
the code to meet the requirements of the target hardware can usually A list of the currently supported microcontrollers and development
be achieved within a few days. tool chains can be found under
www.ixxat.de/devicenet_stack_available_versions_en.html
FEATURES An adaptation of the DeviceNet software to other target systems

can be done by using the standard C code within a few days. This
The DeviceNet Slave Protocol Software supports the development adaptation can also be done by IXXAT.
of Group-2-Only Servers and Group-2 Servers according to the
ODVA DeviceNet Standard.
Classes
Identity Object Class Source Code
Message Router Object Class Company license (limited to company location or business
DeviceNet Object Class units)
Assembly Object Class Extensive manual
Connection Object Class Sample program
Acknowledge Handler Object Class Technical support
78
FURTHER INFORMATION DeviceNet
Please request our expanded "DeviceNet Software Description". Master & I/O Scanner Toolkit
ADDITIONAL SERVICES Software Package for the Development
(not part of the contents of delivery) of DeviceNet Master and I/O Scanner Devices
Service Contract
In addition to the software package IXXAT offers a service contract. FUNCTION OVERVIEW
During the contract period IXXAT provides the following services:
The DeviceNet Master & I/O Scanner Toolkit is a software package
Free updates and bug elimination offered by IXXAT as a Value Added Design Partner (VADP) of Allen-
Technical support via telephone, including answering all Bradley/Rockwell Automation.
questions regarding general DeviceNet issues The software facilitates the development of DeviceNet Master and
I/O Scanner devices used in industrial controls for DeviceNet. The
Code Introduction configuration of the scanner with RSNetWorx for DeviceNet is sup-
One or two days of detailed introduction to the code. Interfaces, ported.
flow charts and data exchange inside the DeviceNet software will The modular structure of the protocol software allows an optimum
be explained. In addition, any questions addressing possible adap- implementation into the target system. A separate module contains
tation issues will be answered and, if necessary, code will be modi- all CAN interface functions in order to access the CAN controller,
fied accordingly. thus providing the user easy adaptation to CAN controllers that are
currently not supported by the software.
Supporting the Conformance-Test The DeviceNet Master & I/O Scanner Toolkit is delivered as source
We will conduct preliminary DeviceNet Protocol Conformance Test code. The documentation allows a quick start using the software.
using the official ODVA software within IXXAT. Potential errors can
be detected and corrected prior to the official test at the ODVA test
labs. FUNCTIONALITY
Technical Consulting Master/Scanner-Functions

Support during the specification of the DeviceNet device or system Simultaneous Operation of Master and Slave
prior to the actual development. Our clients benefit from our Background Polling for low-priority nodes
applied expertise in regard to DeviceNet, helping them to avoid Flexible Bit-Mapping of I/O Data on up to 4 Memory Segments
errors and achieve superior solutions in a shorter period of time. Shared Inputs between several scanners allows shared access
to the input data of a node without additional I/O connections.
Implementation Support Supports multiple Identity Object Instances and Applications
IXXAT offers adaptation, implementation and testing of DeviceNet Objects on the host side
software to meet the requirements of both your hardware and
application. User-specific Hardware Interface
Prepared interface for various CAN controllers
Seminars
IXXAT offers a DeviceNet-Seminar. If requested, the seminar can Configuration and Diagnosis
also be held on-site. Supports Generic Scanners
Configuration with RSNetWorx for DeviceNet by means of EDS File
Access to internal data structures possible from both the host
ORDER NUMBER and network side
Firmware Upload and Download
1.02.0118.TTDDC DeviceNet Slave Protocol Software
(Variants on request)
Software package in source code

Original Allen-Bradley documentation
Company license
Technical support
ORDER NUMBER
1.04.9240.00001 DeviceNet Master & I/O Scanner Toolkit
79
ODVA DeviceNet DeviceNet Client API
Conformance Test Driver
The DeviceNet Client API is a software package which facilitates the
development of DeviceNet Client applications such as service and
Driver for ODVA DeviceNet Protocol Conformance test programs under Microsoft Windows.
Test Software
FUNCTION OVERVIEW
FUNCTION OVERVIEW
DeviceNet Client Functionality
The driver enables the use of the ODVA DeviceNet Protocol Confor- UCMM Client for up to 63 explicit connections in Message
mance Test Software on the IXXAT PC/CAN interfaces. It is supplied Group 3
as an add-on to the universal IXXAT CAN driver VCI (Virtual CAN Group 2 Client for up to 63 explicit connections in Message
Interface). A list of the supported IXXAT PC/CAN interfaces can be Group 2
located at Supports all 4 DeviceNet Message Body Formats 8/8, 8/16,
www.ixxat.de/overview_software_support_en.html 16/8 und 16/16
Device Heartbeat Message (Consumer)
Device Shutdown Message (Consumer)
SYSTEM REQUIREMENTS Offline Connection Set (Client)
Windows 98 SE, NT 4 (SP 6), 2000 (SP 2) or XP. The CANdy-lite and DeviceNet Server Functionality
the USB-to-CAN compact are not supported under Windows NT. UCMM Server for up to 2 explicit connections in Message
IXXAT VCI driver version 2.16 or higher Group 3
ODVA DeviceNet Protocol Conformance Test Software Supports DeviceNet Message Body Format 8/8
(available at the ODVA www.odva.org)
CIP Communications Adapter Profile with
Identity Object Class
CONTENTS OF DELIVERY Message Router Object Class
DeviceNet Object Class
Driver software on CD-ROM Connection Object Class
Additional Interfaces
ORDER NUMBER Functions for MAC ID and Baudrate
Functions for Module Status and Network Status
1.02.0260.00000 Driver for the ODVA DeviceNet Protocol
Conformance Test Software Platform Compatibility
DeviceNet Client API supports Microsoft Windows 2000/XP
using IXXAT CAN-Interfaces
DeviceNet Client include files, DLLs and Runtime components

for Microsoft Windows
Client demo application with source code for Microsoft Visual
Studio
User manual
EDS-File for configuration with Rockwell Automation RSNet-
Worx for DeviceNet
ORDER NUMBER
1.02.0320.00000 DeviceNet Client API
80
ETHERNET Powerlink Introduction
Version 1 of ETHERNET Powerlink was developed in November 2001 Any topologies can be implemented by using hubs. Due to the fact
by the Austrian control manufacturer Bernecker & Rainer Industrie- that only one device transmits at a time and that no collisions occur,
Elektronik and was made available to other companies. The EPSG the number of hubs is no longer restricted to two as it is with Fast
(ETHERNET Powerlink Standardization Group) was founded in Ethernet. It is a distinct advantage from a design standpoint if EPL
November 2002. In November 2003, the specification ETHERNET devices already have an integrated 2-port hub from which line
Powerlink V2 was adopted, which contains the most important structures can be easily implemented.
extension of V1, an application layer: a standardized application The application interface of ETHERNET Powerlink V2 is based on the
interface based on the mechanisms defined in CANopen. IXXAT was mechanisms defined in the CANopen communication profile DS301
heavily involved in the standardization work for this, particularly of CAN in Automation (or EN50325-4). This opens up a wide range
with regard to the CANopen mechanisms. of readily available and usable device and application profiles for
ETHERNET Powerlink, enables continuity of communication services
Start Period Cyclic Period Asynchronous Period Idle Period
between CANopen and EPL systems and facilitates migration from
SoC Manager
CANopen to ETHERNET Powerlink at software level.
S1 S2 S3 S4 acyclic Controller Device Profile
Device
DeviceProfile
Device Profile
DeviceProfile
Profile
EPL Layer 7
Cycle time
Object Dictionary HTTP
Application
FTP
Fig. 1: EPL cycle PDO SDO
Session/Pres.
NMT
To avoid collisions and to make maximum use of the bandwidth, UDP TCP Transport
data exchange between the devices is time-slot based. One device IP Network
in the EPL network takes on the function of the "Managing Node"

(MN), which controls the communication, defines the clock pulse EPL Lower Layer
for synchronization of all nodes, and assigns the right of transmis- SCNM Cycle Handler Data Link
sion to the individual devices. The "Controlled Nodes" (CN) only MAC
transmit when requested to by the manager. An EPL cycle is divided PHY Physical
into four time periods (Fig. 1):

Fig. 2: Reference model
Start Period: Here the manager transmits a "Start of Cyclic"
frame (SoC) as a broadcast message to all controllers. All devices The reference model in Figure 2 shows the communication mecha-
in the EPL network synchronize on the SoC. nisms and familiar elements from CANopen, such as PDO, SDO,
Cyclic Period: Cyclic isochronous data exchange takes place in object dictionary and network management. As is also illustrated,
this time period. According to a preset (configurable) schedule, the SDO protocol can also be implemented via UDP/IP and therefore
the manager transmits a "Poll Request" frame (PReq) sequentially using standard IP messages. This enables direct access to the object
to each controller. The addressed controller responds with a dictionaries of EPL devices by devices and applications outside the
"Poll Response" frame (PRes). All nodes interested in these data EPL system via special EPL routers.
can receive them, whereby a real producer/consumer commu As a result of its impressive features, ETHERNET Powerlink is suitable
nication between the stations is achieved similar to CAN. for implementing applications with hard real-time requirements in
Asnychronous Period: This time interval is available for the the range of µs. However, it is also equally suitable for implementing
asynchronous, non time-critical data exchange. For example, applications that must guarantee transmission of larger quantities
a controller is granted the right to transmit by the manager of data within a defined period of time and also require the known
and it can then transmit an IP-Frame. flexibility from CANopen. Ethernet Powerlink is a flexible commu-
Idle Period: Unused period until the new EPL cycle begins. nication protocol that can easily be conformed to the requirements
of the application.
81
ETHERNET Powerlink Product Overview
Real-Time Ethernet with ETHERNET Powerlink the host system is handled by DMA via the PCI bus. For the host side,
an EPL API is provided. The EPL PCI interface is also available as com-
In 2001, ETHERNET Powerlink (EPL) was the first available real-time pact PCI (cPCI) version.
Ethernet protocol. The EPL version V2, which has been available
since the end of 2003, extends the basic EPL communication
mechanism with a communication profile adopting the well proven Ethernet Powerlink/CANopen Gateway
CANopen concept and its mechanisms. Thus, EPL version V2 includes
essential new features like interoperability, flexibility and configu- Due to its high bandwidth and the very close relationship to CAN-
rability which are critical in combination with fast and reliable real- open, EPL offers the ideal possibility to extend or integrate existing
time communication. CANopen networks. With the aid of the EPL /CANopen Gateway, it
is very easy to exchange process and service data between EPL and
CANopen devices. This enables the use of EPL, for example, as a back-
ETHERNET Powerlink Protocol Stack bone network for networking several CANopen sub-segments.
IXXAT started with ETHERNET Powerlink (EPL) Version 2 in 2003 and

in mid-2004 offered the first complete EPL Protocol Stack according ETHERNET Powerlink Configuration Framework
to the EPL V2 specification for Controlled Nodes, Managing Nodes
and combined Managing / Controlled Node implementations. The The EPL Configuration Framework enables the integration of a pro-
software includes all mandatory functions of the EPL V2 specifica- jecting and configuration function in OEM tools such as SPS pro-
tion as well as various optional functions. gramming environments or other system tools whilst maintaining a
uniform look and feel.
The IXXAT EPL protocol stack is available in a generic version which
can easily be ported to various target platforms and operating The framework provides all necessary components and mechanisms
systems. The delivery content also includes code which allows the required for the creation and management of configuration data of
stack to run directly on a reference system, allowing for simple and an EPL project.
rapid development.
The EPL software stack has been developed in close cooperation ETHERNET Powerlink Safety Protocol Stack
with leading vendors of ETHERNET Powerlink-enabled devices like
Bernecker & Rainer, Lenze and Hirschmann. The ETHERNET Powerlink Safety protocol (EPLsafety) is independent
of the transmission media, but was developed by the EPSG with a
focus on EPL as transportation layer.
ETHERNET Powerlink Module EPLsafety provides a secure data transmission between nodes of a
safety domain, also during transmission via unsecured networks.
IXXAT offers an EPL module for the quick and cost-effective imple- With EPLsafety it is possible to achieve the Safety Integrity Level 3
mentation of controlled nodes, based on FPGA technology. This “single (SIL 3) which is defined in IEC 61508.
chip“ solution allows the module to be used as a communication By using the EPLsafety protocol software from IXXAT, it is possible do
controller in connection with a host CPU. For this purpose, the develop safety nodes as well as a safety configuration manager
module can be connected to the host system via a shared memory which is necessary for monitoring and updating the network con-
interface (DPRAM) or via a serial port. The EPL module supports Poll figuration.
Response latencies of less than 2 µs and cycle times of less than The protocol software is TÜV pre-certified which simplifies the cer-
500 µs. tification process of the final product.
A baseboard is available for the evaluation of the EPL module which

consists of a power supply and the necessary interface connections Further ETHERNET Powerlink Services and Products
to various host systems. Various processor modules of Phytec and
Spectrum Digital can also be plugged directly into the baseboard Code introduction and implementation support
as a host CPU. Consultation and training
Customized hardware and software development
EPL configuration tool (in preparation, please ask)
ETHERNET Powerlink PCI Interface Card EPL Node Manager (in preparation, please ask)
The EPL PCI interface card from IXXAT connects a PC-based host sys- On our website, you will find always the latest information about our
tem to an ETHERNET Powerlink system. The EPL PCI interface card ETHERNET Powerlink products.
has two independent Ethernet interfaces, which can work either as
a Managing Node or as a Controlled Node. The full EPL functionality
is completely processed on the interface card. Data exchange with
82
ETHERNET Powerlink and adaptability. A configuration tool delivered with the software
allows optimum adaptation of the EPL functionality provided by the
CN Protocol Software protocol stack to the given application, thus enabling effective use
of available resources, and guaranteeing an implementation that is
extremely resource-efficient.
Software package for the development
of controlled nodes (CN) Object dictionary and programming interface
The object dictionary is the interface between the application and
the EPL stack. Each object dictionary entry can be directly allocated
HIGHLIGHTS a reference to a variable with application data. PDOs and SDOs
access these application variables directly. Therefore, no modificati-
Scope of functions based on the current Ethernet Powerlink ons to an existing CANopen application are necessary to integrate
(EPL) V2 specification the EPL protocol software.
Operation speed optimized, modular software structure
Provides simple and rapid development of EPL devices User-specific call-back functions can be linked to every application
(Controlled Nodes) object and enable an event-controlled notification of the application
Comprehensive configuration and scaling possibilities in the event of accesses to these objects. This mechanism allows a
Clearly structured programming interface for connection direct, application-specific reaction on modifications to the applica-
to the application program tion data caused on the bus side. In addition, the saving and recovery
"C" source code can be used with any target system of configured data is also supported. The application is also able to
Capable of operating either with or without operating system build or modify parts of the Object Dictionary during operation.
Adaptable to various Ethernet controller architectures and hard-
ware architectures (e.g. 1-CPU, 2-CPU) via internal interfaces Process (PDO) and Service Data Objects (SDO)
Dynamic modification of the Object Dictionary during operation The EPL protocol software supports both dynamic and static PDO-
Multi-channel capability mapping and provides all possibilities of producer/consumer com-
munication.
Application In addition to PDO communication, the SDO protocol necessary for

configuration and diagnostics is also implemented in the EPL proto-
Object Dictionary (OBD)
col software. It allows safe transmission of non-real-time-critical
SDO data. The SDO protocol can be run via UDP/IP or via ASend (EPL
GOE SIS NVM
Error
PDO
frames).
Handling UDP TCP
NMT
IP
Multi-channel support
Powerlink Driver (PLD) The EPL-protocol software enables the implementation of several
independent EPL interfaces in one device. In this way, gateways can
EPL Stack Lower Layer Driver (LLD) be developed which, with two separated EPL channels and as Con-
trolled Node, are connected to an EPL network and allow data
Ethernet Controller
exchange between the networks.
Operating system support

OVERVIEW OF FUNCTIONS The EPL stack can be used with or without an operating system. The
software has an internal scheduler which ensures the optimal allo-
The EPL protocol software contains all the necessary functions for cation of the available process time resources. By using an operating
the implementation of controlled nodes in accordance with the EPL system, the EPL stack is executed as one task. Only basic operating
V2 specification. A UDP/IP stack, which is required for running the system functions like semaphores and tasks are required. These
SDO protocol via UDP, is also an available option. The integration of functions are encapsulated by an abstraction layer (GOE – Generic
a UDP/IP stack by the user is simplified by the internal interfaces of Operating Environment) and can, because of this be easily adapted
the EPL stack. to the operating system.
Encapsulation of hard real-time tasks and hardware specific Reference platform

adaptation The provided "C" source code can be used on any target system.
The lower layers of the EPL software are specifically designed to Besides the generic version, the delivered software package includes
guarantee fast response times to real-time events on the EPL bus. a reference implementation which work on Freescale Coldfire 523x
Therefore, the access and the handling of the Ethernet controller is based systems without the need of additional adaptation. Evaluation
encapsulated within a separate module – the lower layer driver boards with wiring diagrams (reference schematics) are also available.
(LLD). For an adaptation of the EPL software to a specific CPU or
hardware platform, this module needs to be modified. This abstrac-
tion between hardware-dependant routines and the higher layers
of the EPL software offers users a high degree of both scalability
83
"C" source code

Reference implementation for Coldfire 523x
Software license
Manual
Technical support
Service Contract
In addition to the software package IXXAT offers a software service
contract. During the term of the contract, IXXAT provides the following
services:
Free updates and bug fixing

Technical support via telephone including answering questions
regarding general ETHERNET Powerlink issues.
Code Introduction
IXXAT also offers comprehensive one- or two-day introductions to
the code. Interfaces, sequences and data flows within the EPL pro-
tocol software are explained. Questions concerning the adaptation
to be carried out will be answered, and, adaptations to the code can
be made.
Technical support
IXXAT also offers support in the specification of the EPL device or
system to be implemented. Here, the customer benefits from our
comprehensive EPL applied expertise allowing errors to be avoided
and better solutions to be developed within a shorter period of time.
Implementation support
IXXAT handles adaptation, implementation and testing of the EPL
software for your hardware or application.
Seminars
IXXAT offers a seminar on ETHERNET Powerlink. The seminar can also
be held in-house on request.
ORDER NUMBER
1.02.0290.00000 ETHERNET Powerlink Software for CN

(Product license)
1.02.0291.00000 ETHERNET Powerlink Software for CN
(Product line license)
84
ETHERNET Powerlink layers of the EPL software makes it possible to provide a high degree
of scalability and adaptability. A configuration tool delivered with
MN/CN Protocol Software the software allows optimum adaptation of the EPL functionality
provided by the protocol stack to the given application which gua-
rantees an extremely resource-efficient implementation. So it is pos-
Software package for the development of sible to develop a pure managing node or a pure controlled node by
managing nodes (MN) and controlled nodes (CN) using the managing node/controlled node protocol software.
Object dictionary and programming interface

HIGHLIGHTS The object dictionary is the interface between application and com-
munication. Each object dictionary entry can be directly allocated a
Scope of functions based on the current Ethernet Powerlink reference to a variable with application data. PDOs and SDOs access
(EPL) V2 specification these application variables directly. Therefore, no modifications to
Operation speed optimized, modular software structure an existing CANopen application are necessary to integrate the EPL
Allows for simple and rapid development of EPL devices protocol software.
(managing nodes and controlled nodes)
Comprehensive configuration and scaling possibilities User-specific call-back functions can be linked to every application
Clearly structured programming interface for connection of object and enable an event-controlled notification of the application
the application program in the event of accesses to these objects. This mechanism allows a
"C" source code can be used with any target system direct, application-specific reaction on modifications to the applica-
Capable of operating either with or without operating system tion data caused on the bus side. In addition, saving and recovery of
Adaptable to various Ethernet controller architectures and configured data is also supported. The application is also able to
hardware architectures (e.g. 1-CPU, 2-CPU) via internal inter- build or modify parts of the Object Dictionary during operation.
faces
Dynamic modification of the Object Dictionary during operation Process (PDO) and Service Data Objects (SDO)
Multi-channel capability The EPL protocol software supports both dynamic and static PDO-
mapping and allows a true producer /consumer communication.
Application In addition to PDO communication, the SDO protocol necessary for
configuration and diagnostics is also implemented in the EPL protocol
Object Dictionary (OBD)
software. It allows safe transmission of non-real-time-critical data.
SDO The SDO protocol can be run via UDP/IP or via ASend (EPL frames).
Error
GOE SIS NVM PDO UDP TCP
Handling
NMT Multi-channel support
IP
The EPL-protocol software enables the implementation of several
Powerlink Driver (PLD) independent EPL interfaces in one device. Managing node or con-
trolled nodes can be configured independently as well as with inde-
EPL Stack Lower Layer Driver (LLD) pendent object dictionaries in each case. In this way, gateways can be
developed that are connected to a higher order EPL network with
Ethernet Controller
one EPL channel as a controlled node, and, control an EPL sub-net-
work as a managing node with the second EPL channel.
OVERVIEW OF FUNCTIONS Network management

One important task of the managing node is network management,
The EPL protocol software contains all necessary functions to im- which includes start-up and monitoring of the network nodes. The
plement managing and controlled nodes in accordance with the EPL protocol software supports the complete boot-up process defi-
EPL V2 specification. A UDP/IP stack that is required to run the SDO ned in the EPL V2 specification for mandatory and optional control-
protocol via UDP can be supplied as an extra option. Integration of led nodes. Software updates of controlled nodes by the managing
a UDP/IP stack by the user is greatly simplified by the internal inter- node are also supported.
faces of the EPL protocol software. The EPL protocol software includes the configuration manager
which allows for device configurations to be checked and updated
Encapsulation of hard real-time tasks and hardware specific during the boot-up process. With the aid of the configuration ma-
adaptation nager it is easy to replace defective devices while a network is in
The lower layers of the EPL software are specifically designed to operation. In this case no special configuration of the replacement
guarantee fast response times of real-time events on the EPL bus as device is required before installation by the service technician.
well as the efficient processing of the EPL cycle on the managing
node. Therefore, the access to and the handling of the Ethernet
controller is encapsulated within a separate module, the lower layer
driver (LLD). For an adaptation of the EPL software to a specific CPU
or hardware platform, this module needs to be modified. This
abstraction between hardware-dependant routines and the higher
85
Operating system support ORDER NUMBER
The EPL stack can be used with or without an operating system. The
software has an internal scheduler which insures the optimal allo- 1.02.0293.00000 ETHERNET Powerlink Software for MN/CN
cation of the available process time resources. By using an operating (Product license)
system, the EPL stack is executed as one task. Only basic operating 1.02.0294.00000 ETHERNET Powerlink Software for MN/CN
system functions like semaphores and tasks are required. These (Product line license)
functions are encapsulated by an abstraction layer (GOE – Generic
Operating Environment) and can be easily adapted to the operating
system.
Reference platform
The provided "C" source code can be used on any target system.
Besides the generic version, the delivered software package includes
a reference implementation, which work on Freescale Coldfire 523x
based systems without the need of additional adaptation. Evaluation
boards with wiring diagrams (reference schematics) are also available.
"C" source code

Sample implementation for Coldfire 523x
Software license
Manual
Technical support
Service Contract
In addition to the software package IXXAT offers a software service
contract. During the term of the contract, IXXAT provides the follo-
wing services:
Free updates and bug fixing

Technical support via telephone including answering questions
regarding general ETHERNET Powerlink issues.
Code Introduction
IXXAT offers comprehensive one- or two-day detailed introductions
to the code. Interfaces, sequences and data flows within the EPL
software are explained. Questions are also answered concerning the
adaptation to be carried out, and, adaptations to the code can be
made.
Technical support
Support in the specification of the EPL device or system to be im-
plemented. Here the customer benefits from our comprehensive EPL
applied expertise, allowing errors to be avoided and better solutions
to be developed within a shorter period of time.
IXXAT handles adaptation, implementation and testing of the EPL
protocol software for your hardware or application.
Seminars
IXXAT offers a seminar on ETHERNET Powerlink. The seminar can also
be held in-house on request.
86
ETHERNET Powerlink Safety Introduction
The trend in data communication of safety-related devices conti- EPLsafety only uses the unsafe transmission layer to exchange the
nues to move away from discrete cabling of safety-critical functions safe EPLsafety frames whose content is not further interpreted by
towards the use of existing communication resources. In order to the transmission layer. The use of EPL as the transmission layer is of
follow this trend especially in the area of industrial Ethernet, new course preferred because there is a close relationship of the commu-
methods of resolution are required. The ETHERNET Powerlink Safety nication mechanisms between EPL and EPLsafety, which can there-
Protocol (EPLsafety) makes such a safety-related data exchange fore be used optimally.
possible. It was developed by the ETHERNET Powerlink Standardisa-
tion Group (EPSG) as an open safety protocol. It is suitable for com- An EPLsafety network can consist of up to 1023 EPLsafety domains
munication cycles in the µs range and allows to implement safe with up to 1023 devices in each domain. The EPLsafety domain may
systems up to SIL-3 (Safety Integrity Level) in accordance with extend over several (also inhomogeneous) networks. Communication
IEC61508. The EPLsafety specification is available as a released version between EPLsafety domains is possible via special EPLsafety domain
1.0 certified by the TÜV Rheinland. gateways.
EPLsafety uses different guarding mechanisms. Besides the guarding In addition to “Safety Nodes” (SN), each EPLsafety domain has a
of data content by using CRC codes, a time-based monitoring of “Safety Configuration Manager” (SCM), which is responsible for the
communication is carried out independently from the (unsafe) allocation of node addresses, storage of node-specific parameters
transmission protocol. EPLsafety thus enables safe transmission of and permanent monitoring of the SNs.
data over unsafe networks.
EPLsafety uses the basic communication mechanisms familiar from
Contrary to what the name ETHERNET Powerlink Safety may sug- EPL and CANopen, such as safe process data objects (SPDO), safe
gest, this protocol can be used not only together with ETHERNET service data objects (SSDO) and a safe object directory (SOD). IXXAT
Powerlink (EPL) as a transmission protocol. Moreover it is possible implemented the reference stack for ETHERNET Powerlink Safety in
to use other transmission protocols and media such as CAN together close cooperation with the TÜV Rheinland, which carried out deve-
with EPLsafety. lopment support, software type testing and certification.
Factory Floor Network and Company Network Firewall
EPL V2
Network A Network Any
Basic Security
(EPL V2) (Ethernet TCP/IP) Network
MN EPL Safety Domain 1

SN4
SCM SN1 SN2 SN3 SN5
SDgateway
EPL Safety Domain 2 IP Node

SN3 Network C (CAN)
SCM SN1 EPL Safety Domain n
SN2 SCM SN1
CN CN CAN-Node
Safety Domain
87
ETHERNET Powerlink SSC: Safety Stack Control: control of the EPLsafety software
such as stack initialisation
Safety Protocol Software SNMT: Safety Network Management: transmission, reception and
processing of network management commands as well as
distribution of the safety addresses
Software package for the development of safety SCM: Safety Configuration Manager: configuration, verification
nodes (SN) and Safety Configuration Manager and monitoring of safety nodes
(SCM) SPDO: Safety Process Data Objects: cyclic exchange of process
data and verification of time synchronization
HIGHLIGHTS SSDO: Safety Service Data Objects: server/client communication
to access the object directory via the network
Scope of functions based on the current ETHERNET Powerlink SOD: Safety Object Dictionary: access to the Safety Object
Safety specification Directory
Modular software structure for the implementation of SN SFS: Safety Frame Serialization: serialization and deserialization
and SCM of the safety frames
Pre-certified software component enables quick and easy SNS: Safety Node State: management of the operating states
development of EPLsafety devices of the safety nodes
Clearly structured programming interface for connection of SERR: Safety Error Handling: logging of stack-internal errors
the application program SCFM: Safety Control Flow Monitoring: monitoring of the correct
“C”-source code for use on any target platforms (hardware- program flow in accordance with SIL-3
independent)
Independent of operating system – can be run with and
without operating system HARDWARE CONCEPTS FOR EPL SAFETY
Simple connection to a non-safe transport protocol possible
via abstraction layer The Safety Integrity Level (SIL) that can be achieved with the
Any non-safe transport protocol can be used; not limited to EPLsafety software mainly depends on the hardware architecture
ETHERNET Powerlink used. The IXXAT EPLsafety software was created for use in SIL-3
Multi-instancibility allows simple creation of safety domain devices. To meet the requirements of SIL-1, it is sufficient for
gateways example to use one single Safety Controller (SC) that carries out
Reference portation for Intel Xscale (IXP420) and Atmel ARM7 the safe application and the EPLsafety stack. To achieve SIL-3, the
(AT91SAM7S64) for GNU C-Compilers Safety Controller must also be designed as redundant.
Designed for use in SIL-3 devices I/O
Free PC demo available
Safe Application
Application Safety
Controller
SSC
SOD
(Safety Communication
SERR SCM
SNS Object Contoller
Dictionary) (non safe)
SNMT SPDO SSDO
SCFM SIL-1/SIL-2 hardware architecture

I/O
EPLsafety Stack SFS (Safety Frame Serialization)
SHNF (Sichere Hardwarenahe Firmware) Safe Application
Safety Safety
Controller 1 Controller 2
Architecture of the EPLsafety software
Communication
Contoller
(non safe)
SIL-3 hardware architecture

88
With its function modules, the IXXAT EPLsafety software enables the
execution of all communication and back-up mechanisms necessary
for EPLsafety. This includes the provision of a Safe Object Directory
(SOD), Safe Process Data (SPDO) and Safe Service Data (SSDO) as
well as time and CRC monitoring of the data packages. Zipping and
unzipping of the EPLsafety frames in the transmission messages of
the non-safe transmission protocol is carried out by the functions
of the hardware-level firmware (SHNF) provided by the user. The
inputs and outputs of the EPLsafety device must also be controlled
by a special safety application. The SOD of the EPLsafety software is
used as the data interface to the safety application.
Safety Controller
Safe Application
Safe OS
EPL Safety Stack
(opt.)
SHNF
Communication Controller
SHNF
Non-Safe
Communication Stack
Integration of the EPLsafety software in the overall system
SCOPE OF SUPPLY
C-source code
Pre-certified reference implementation
Software license available for SN or SCM+SN
Manual
One-day code introduction
Technical support
Maintenance contract
As a supplement to the software package, IXXAT offers a mainten-
ance contract. For the period of the contract, the maintenance con-
tract consists of the following services:
Free updates and troubleshooting

Technical support by phone including answers to general
questions on ETHERNET Powerlink Safety
Technical support
Support for software certification. You benefit from our compre-
hensive EPLsafety know-how and expertise in the development of
safety-critical software.
ORDER NUMBER
On request ETHERNET Powerlink Safety Protocol Software
89
ETHERNET Powerlink FIELDS OF APPLICATION
PCI & cPCI Interface Host interface for PC based control applications (PLC)
PC interface for analysis, diagnostics and tests
Gateway for hierarchical EPL systems in connection with control
EPL interface board for PCI and cPCI bus systems application
CONTENT OF DELIVERY
EPL PCI or cPCI interface board

Driver and API for Windows 2000/XP
Manual
Programming example
FURTHER INFORMATION
The technical details and features of the EPL PCI or cPCI interface
board are subject to change. The latest information can be found on
the webpage.
ORDER NUMBER
1.01.0110.00000 ETHERNET Powerlink PCI Board - EPL-IB200/PCI

1.01.0111.00000 ETHERNET Powerlink cPCI Board - EPL-IB210/cPCI
The EPL interface board enables the connection of PC host systems to

EPL systems via the PCI or cPCI bus. The EPL functionality runs com-
pletely on the CPU system of the EPL interface board. Depending on
the performance required, the EPL interface board can work with one
or two EPL systems in each case independently as a managing node
(MN) and controlled node (CN). In the MN and in the CN mode, it has
rapid response times (< 2µs) and a very low SoC-jitter. Data is trans-
mitted between the host system and the EPL interface board by DMA
via the PCI or cPCI bus. Regarding process data, the EPL interface
board is also able to process large quantities of data from systems
with more than 100 CNs. The scope of supply includes a driver for
Windows 2000/XP and an API. Adaptation to other operating systems
(e.g. VxWorks) is possible and can be carried out by IXXAT.
TECHNICAL SPECIFICATIONS/FEATURES
2 Ethernet controllers with EPL acceleration

2-port hub with two RJ45 connectors per Ethernet controller
or 4-port hub when using only one Ethernet controller
Direct synchronization of several cards via separate SYNC-line
Response times as MN/CN less than 2µs
PCI bus interface in accordance with specification 2.2
(32 bit/33 MHz, 5 or 3.3 Volt)
Also available with cPCI bus interface (32 bit/33 MHz,
5 or 3.3 Volt)
90
ETHERNET Powerlink/ MN
(PLC) Ethernet Powerlink Segment
CANopen-Gateway
CN CN EPL/
(Antrieb) (Antrieb) CANopen
Gateway for the integration of CANopen networks Gateway CANopen
Segment
in ETHERNET Powerlink systems
Sensor I/O PLC
Picture: Coupling of EPL and CANopen segments
On the CANopen side, the EPL/CANopen-Gateway can be configured

either as a master or as a slave. Synchronization of the CANopen
network by the very precise EPL SoC message is also possible. If the
gateway is configured as a CANopen NMT master, start-up of the
CANopen network can be synchronized with the EPL network. It is
also possible to route CANopen emergency messages into the EPL
network to allow for error monitoring of the CANopen network via EPL.
TECHNICAL SPECIFICATIONS / FEATURES
EPL controlled node in accordance with EPL Version V2

CANopen master/slave function
OVERVIEW OF FUNCTIONS RJ45 Ethernet connector
CANopen-compliant Sub-D connector
With the ETHERNET Powerlink (EPL) Version V2, many CANopen EPL node ID adjustable via software
communication mechanisms which have already proven to be very Display of the CANopen and EPL network status via separate LEDs
useful in CAN systems have been adopted for Ethernet. EPL thus Plastic housing for hat rail assembly
combines short cycle times and the high bandwidth of the Ethernet
with the proven CANopen mechanisms such as the object model or
process and service data communication. Finally, the EPL can be FIELDS OF APPLICATION
regarded as a further development of the CANopen, to accommo-
date the increasing requirements of transmission bandwidth and Extension of the topology of the CANopen systems with EPL as a
network extension. backbone network
Integration of already automated CANopen sub-systems in higher
Because of the great similarity between CANopen and EPL, an order EPL network
extension or integration of CANopen systems with EPL is achievable. Central logging of large quantities of process data via EPL from
Existing CANopen systems can be extended by EPL in many ways CANopen sub-network
with the aid of special EPL/CANopen-Gateways. In this way, for
example, several CANopen segments can also be linked with each CONTENT OF DELIVERY
other over large distances. In addition, central data logging can be
carried out over several CANopen sub-segments due to the high EPL/CANopen-Gateway
bandwidth of the EPL network. Configuration software to set EPL node ID
Manual
With the aid of the EPL/CANopen-Gateway, it is also possible to
exchange service data between EPL and CANopen networks in ad- FURTHER INFORMATION
dition to the exchange of process data.
The technical details and features of the EPL/CANopen-Gateway may
The IXXAT EPL/CANopen-Gateway offers a simple way of combining change. Up-to-date information on our ETHERNET Powerlink pro-
CANopen and EPL networks. From the point of view of the EPL net- ducts is available on our website.
work, the gateway provides access to the input and output data of
the CANopen network. With the aid of the configuration of the
gateway, the process data that shall be exchanged between the CAN- ORDER NUMBER
open and the EPL network can be defined.
On request ETHERNET Powerlink/CANopen-Gateway
91
ETHERNET Powerlink A baseboard is available as a supplement to the EPL module. This
provides the power supply necessary for the evaluation of the EPL
Module module as well as various bus connections. With the baseboard it is
possible to connect processor modules of Phytec (phyCORE-XC161,
phyCORE-LPC2294) or Spectrum Digital (eZdsp F2812) to the EPL
FPGA-based solution for cost-effective ETHERNET module via the integrated plugboards.
Powerlink implementations
HIGHLIGHTS
Hardware-based ”single chip” solution for EPL Controlled Nodes

Reference design for Altera-FPGA with Ethernet Controller,
HUB and CPU (NIOS II)
Fast poll response times (<=2µs)
EPL protocol stack in accordance with the ETHERNET Powerlink
specification V2 runs completely on the EPL module
Simpler applications can be implemented directly on the EPL
module
Host connection via shared memory interface or serial port
Host API with demo application
Syncronization of the application CPU on EPL-SoC message via
separat interrupt line possible
Integrated 2-port hub with RJ45 connectors
Node-ID setting via DIP-switch or software
OVERVIEW OF FUNCTIONS CONTENT OF DELIVERY
The EPL module represents a powerful solution for the implemen- EPL module with integrated EPL protocol stack
tation of ETHERNET Powerlink in devices such as drives, I/O modules Host API in C-source code with programming example
or encoders. For connection to the application CPU, a serial port or Manual
a shared memory interface is available. The memory required for
the data exchange is already on the EPL module, so that the inter-
face of the application CPU only has to be connected to the EPL ADDITIONAL PRODUCTS
module.
Baseboard for the EPL module
Device vendors can integrate the hardware design instead of the
add-on module directly in their own circuit. For an easy integration
of the EPL module into an EPL network, the EPL module comes with FURTHER INFORMATION
an integrated, two port hub with two RJ45 sockets.
The technical details and features of the EPL module are subject to
A Host-API is supplied together with the EPL module, which allows change. The latest information can be found on the webpage.
the EPL module to be controlled via its interface (ANSI-C Code).
With the aid of the API, for example, new user objects can be ge-
nerated in the object directory, SDO accesses to other network ORDER NUMBER
nodes can be carried out, or, the local object directory can be con-
figured. It is also possible to store configuration data on the EPL 1.01.0112.00000 ETHERNET Powerlink FPGA Module
module via the functions of the API.
Process data is exchanged between application CPU and the EPL

module via separate storage areas for input and output data. The
application has 1.5 kBytes for process data in each direction.
92
ETHERNET Powerlink HIGHLIGHTS
Configuration Framework Automatic PDO-mapping and PDO-linking

Automatic calculation and configuration of the EPL network
timing parameters
Component for integration of a projecting and Support of network variables in accordance with CiA
configuration function for Powerlink systems DS302/DS405
in OEM tools Clear and simple access to the device data
Fast, database-based management of all configuration and
device data from device description files (EDS and DCF files)
OVERVIEW Management of any number of device description files in one
catalogue
The EPL Configuration Framework allows for the integration of a COM-based interface for simple integration in OEM tools
projecting and configuration function in OEM tools such as SPS
programming environments or other system tools whilst maintai-
ning a uniform look and feel. DESCRIPTION OF FUNCTIONS
The framework provides all the necessary components and mecha- Catalogue
nisms required for the creation and management of configuration A catalogue system enables device description files (EDS files) to be
data of an EPL project. The framework does not have its own user imported and stored in a catalogue database. This is useful if EPL
interface. This is to be provided by the OEM tool. This offers the devices are used repeatedly in projects since a device can then be se-
following advantages: all system data is centrally accessible in the lected directly in the catalogue and added to a project and does not
interface and can be centrally edited, the OEM tool has a uniform have to be imported from an external device description file, which
look and feel, and, Powerlink-relevant configuration data can be saves time. Therefore, it is also possible for an OEM to define which
displayed to the user at system level in abstracted form. This makes EPL devices the customer can use in the OEM systems, preventing
it measurably easier for the user to both understand and work with the customer from using unauthorized devices.
the OEM tool. The Framework is integrated in the OEM tool via a
COM-based interface provided by the framework. Project database
Projects are managed in the form of a database. This means that the
The EPL Configuration Framework is based on fast, database- data and descriptions of the individual devices are stored in binary
oriented management of all configuration and device data. Data of form, making faster access to this data possible when opening the
new devices is either taken from a device catalogue or transferred projects themselves or when opening projects with a large number
to the database from the EPL device description files (EDS files) via of devices. In addition, the project database insures consistency of
a fast import function and is then available in binary form. The the data.
advantage of this concept is the extremely fast availability of all
configuration data which is normally only stored in independent Automatic PDO-mapping and PDO-linking
device description files. This means that there are no long waiting With larger systems, the specialized applied expertise required for
times when either starting the configuration tool or opening an PDO-mapping/linking and the time-consuming, careful selection of
existing project. the individual PDO links requires great effort. The EPL Configuration
Framework supports the creation of PDO-mappings and the correct
The EPL Configuration Framework runs on the operating systems allocation of the PDOs to the devices (PDO-linking) by means of an
Windows 2000 and Windows XP. automatic system. For this, the user or the OEM tool must only
define how the input and output data of the individual devices are
to be linked with each other or with SPS variables (network varia-
EDS/XML
Imp/Exp
bles). This allows the user to create links without detailed knowledge
of ETHERNET Powerlink.
Catalog Device
Database Catalogs Network variables in accordance with CANopen CiA 302/405
Another function provided by the EPL Configuration Framework is
Configuration
Framework
Project Projects the definition and management of network variables in accordance
Datebase
Interface with the specifications DS302 or DS405 of CAN-in-Automation.
Network variables are used by devices that provide data of an appli-
PDO Linker cation running on the device to the Powerlink system in the form of
a process data interface. This is especially the case with SPSs. With
EPL Timing these network variables, it is possible to link the data (variables) of
Calculator
the application program with data of other devices. Based on these
Config File
links, the EPL Configuration Framework can then also automatically
MN Config File calculate the PDO-mapping and PDO-linking.
Generator
93
Automatic calculation of the Powerlink communication cycle
Depending on the timing data of the individual Powerlink devices
and the lengths of the individual PDOs, the timing must be calcula-
ted for the Powerlink communication cycle and the configuration
values defined for the individual timing parameters of both the
managing node (MN) and the controlled nodes (CNs). This function
is also automatically carried out by the EPL Configuration Framework.
Import/export of device description files (EDS/DCF)

A powerful and exceptionally fast import and export of device des-
cription files (EDS and DCF files) enables importing and exporting
of devices to and from the catalogue as well as the exporting of
configuration data of individual devices from a project (as a DCF
file). At the same time, this is the standard interface to other EPL
tools. Even very large device description files are processed quickly,
and, the file size is not limited.
Generation of configuration data files

After completion of projecting or configuration of a Powerlink sys-
tem, the EPL Configuration Framework creates a configuration data
file. This configuration data file is then normally sent to the mana-
ging node (MN). This configures the MN itself which passes the em-
bedded configuration data on to the individual devices in the
Powerlink system during the system boot-up. The configuration data
file is created in the Concise DCF format.
Programming interface
The programming interface of the EPL Configuration Framework is
implemented as a COM interface. It provides various interfaces for
the management of the catalogue, of the projects and of the indi-
vidual devices in a project. This enables simple integration of the EPL
Configuration Framework in OEM tools.
ORDER NUMBER
On request EPL Configuration Framework
94
EtherNet/IP Introduction
EtherNet/IP is one of three open network standards (DeviceNetTM, Application Identity
ControlNetTM and EtherNet/IPTM), which all use a common applica- Specific Object(s) Object
tion layer, the "Common Industrial Protocol" (CIPTM). This common
application layer and open software and hardware interfaces allow Parameter Message Router Assembly
Object Object Object
a universal connection of automation components from the field-
bus level over the control level to the enterprise level.
TCP/IP
Interface Object
The Family of CIP Networks is specified and published by ODVA Explicit Messages I/O Messages
(Open DeviceNet Vendor Association – www.odva.org) and CI (Con- UCMM Connection Manager
trolNet International – www.controlnet.org). Object
Ethernet Link
Object
The Common Industrial Protocol presents communication and TCP/IP Ethernet (IEEE802.3)
Network
application in the object model. Predefined objects facilitate the
data exchange of different devices and manufacturers. By creating
various device profiles, additional user benefits were achieved.
EtherNet/IP is the implementation of CIP over TCP/IP and Ethernet
CIP is a connection based protocol. It defines the exchange of I/O (IEEE 802.3).
data using I/O Messaging (or Implicit Messaging) as well as the
exchange of general data for configuration, diagnostic and ma- The EtherNet/IP specification defines Layer 4, Layer 3 (Encapsulation
nagement via Explicit Messaging. CIP thus provides 4 essential Protocol and usage of TCP/IP), Layer 2 (Usage of Ethernet IEEE
functions to the user: 802.3), Layer 1 and Layer 0 (Physical Layer and Transmission Media).
Common object model for application Connectors, cable types and cable lengths are specified as are com-
Common communication model for data exchange munication-based displays, operating elements and the correspon-
in the network ding labeling of the housing.
Common configuration methods
Common device profiles EtherNet/IP supports data rates of 10 Mbit/s and 100 Mbit/s. Nor-
mally, a star topology using suitable (managed) switches is built.
The number of devices connected in an EtherNet/IP network
User Device
Profiles
I/O Encoder Valves Drives SEMI Others depends only on the available IP-Address space.
Application
CIP Application Layer
Application Object Library
In contrast to DeviceNet, as of yet, the EtherNet/IP standard does
not specify a network power.
CIP Data Management Services
Presentation
Explicit Messages, I/O Messages
Besides factory automation with I/O-modules, valves, encoders,
Session CIP Message Routing, Connection Management drives and controls (PLC), the main field of application of
EtherNet/IP is the networking of both the control and the enterprise
Transport
Encapsulation level. Within the Family of CIP Networks, EtherNet/IP covers appli-
DeviceNet ControlNet
Network
Transport Transport
TCP UDP cations where medium to large amount of data with medium cycle
IP
times (10 ms to 500 ms and above) need to be exchanged in the
DataLink
CAN ControlNet Ethernet network.
CSMA/NBA CTDMA CSMA/CD
DeviceNet ControlNet Ethernet

Physical
Physical Layer Physical Layer Physical Layer
95
EtherNet/IP Scanner Software
The EtherNet/IP Scanner software enables developers of PC based Resource Utilization and Management
or embedded products to quickly add EtherNet/IP Scanner Class - All resources are initialized at startup
functionality to a product's feature set. - No dynamic memory or thread allocation
Applications for the EtherNet/IP Scanner Software are EtherNet/IP- - Only one thread utilized
capable controllers (PLC) as well as devices which must provide client
functionality in the network. Supported Objects according to CIP Standard
The EtherNet/IP Scanner Software provides I/O Server and I/O Client, - Identity Object
Message Server and Message Client capability as well as an Applica- - Message Router Object
tion Programming Interface (API) for the application. - Assembly Object
The EtherNet/IP Scanner Software is delivered as complete source - Connection Manager Object
code – EtherNet/IP Scanner Developers Kit (ESDK) or as DLL for - Connection Configuration Object
Microsoft Windows 2000/XP – EtherNet/IP Scanner Communi- - Port Object
cation Driver (EIPS). - TCP/IP Interface Object
The EtherNet/IP Scanner Software is distributed either as a royalty- - Ethernet Link Object
free site license limited to one location or as an enterprise license.
SUPPORTED TARGET SYSTEMS
GENERAL FUNCTIONS The EtherNet/IP Software is delivered for Microsoft Windows

2000/XP and Microsoft Visual Studio and is already running on this
Scanner Class Functionality system with the demo application. An adaptation to other systems
- UCMM (unconnected) Message Server and Client is possible using the EtherNet/IP Scanner Developer's Kit (ESDK)
- Class 3 (connected) Message Server and Client which is delivered completely in source code.
- Class 1 (connected) I/O Server and Client This adaptation can also be done by IXXAT.
A suitable operating system as well as TCP/IP protocol stack must
be already available for the target system, as they are not part of
the delivery content of the EtherNet/IP Scanner Software.
EtherNet/IP Scanner
Developers Kit (ESDK)
EtherNet/IP Scanner
SPECIFIC FUNCTIONS Communication Driver (EIPS)
Basic functionality of EtherNet/IP Scanner Software
Platform Compatibility and Portability SPECIFIC FUNCTIONS
- Direct Microsoft Windows XP/2000/NT/CE/WinSock
compatibility Basic functionality of EtherNet/IP Scanner Software
- Direct AIX UNIX, LINUX compatibility Platform Compatibility
- Platform-dependent utilities isolated in a separate module - Direct Microsoft Windows XP/2000/NT/CE/WinSock
for easier porting to other platforms compatibility
CONTENT OF DELIVERY CONTENT OF DELIVERY
EtherNet/IP Scanner Class source code, include files, DLLs EtherNet/IP Scanner Class include files, DLLs and Runtime
and Runtime components for Microsoft Windows components for Microsoft Windows
Scanner (Client) demo application with source code for Scanner (Client) demo application with source code for
Microsoft Visual Studio Microsoft Visual Studio
User manuals User manuals
STC-File for ODVA EtherNet/IP Protocol Conformance Test STC-File for ODVA EtherNet/IP Protocol Conformance Test
Software Software
EDS-File for configuration with Rockwell Automation EDS-File for configuration with Rockwell Automation
RSNet-Worx for EtherNet/IP RSNetWorx for EtherNet/IP
1.02.0230.00000 EtherNet/IP Scanner Developers Kit (ESDK) 1.04.0121.00000 EtherNet/IP Scanner Communication Driver (EIPS)
96
EtherNet/IP Adapter Software
The EtherNet/IP Adapter software enables developers of PC based Resource Utilization and Management
or embedded products to quickly add EtherNet/IP Adapter Class - All resources are initialized at startup
functionality to a product's feature set. - No dynamic memory or thread allocation
Applications for the EtherNet/IP Adapter Software involve Ether- - Only one thread utilized
Net/IP-capable devices like I/O-Modules, encoders, valves, simple
drives and other components used in factory automation. The Ether- Supported Objects according to CIP Standard
Net/IP Adapter Software provides I/O Server and Message Server ca- - Identity Object
pability as well as an Application Programming Interface (API) for - Message Router Object
the application. - Assembly Object
The EtherNet/IP Adapter Software is delivered as complete source - Connection Manager Object
code – EtherNet/IP Adapter Developers Kit (EADK) or as DLL for - Port Object
Microsoft Windows 2000/XP – EtherNet/IP Adapter Communica- - TCP/IP Interface Object
tion Driver (EIPA). - Ethernet Link Object
The EtherNet/IP Adapter Software is distributed either as royalty-
free site license limited to one location or as an enterprise license. SUPPORTED TARGET SYSTEMS
GENERAL FUNCTIONS The EtherNet/IP Software is delivered for Microsoft Windows

2000/XP and Microsoft Visual Studio and is already running on this
Adapter Class Functionality system with the demo application.
- UCMM (unconnected) Message Server An adaptation to other systems is possible using the EtherNet/IP
- Class 3 (connected) Message Server Adapter Developer's Kit (EADK) which is delivered completely in
- Class 1 (connected) I/O Server source code.
This adaptation can also be done by IXXAT.
Additional Functionality A suitable operating system as well as TCP/IP protocol stack must
- UCMM (unconnected) Message Client be already available for the target system, as they are not part of
the delivery content for the EtherNet/IP Adapter Software.
EtherNet/IP Adapter
Developers Kit (EADK)
EtherNet/IP Adapter
SPECIFIC FUNCTIONS Communication Driver (EIPA)
Basic functionality of EtherNet/IP Adapter Software
Platform Compatibility and Portability SPECIFIC FUNCTIONS
- Direct Microsoft Windows XP/2000/NT/CE/WinSock
compatibility Basic functionality of EtherNet/IP Adapter Software
- Direct AIX UNIX, LINUX compatibility Platform Compatibility
- Platform dependent utilities isolated in a separate module - Direct Microsoft Windows XP/2000/NT/CE/WinSock
for easier porting to other platforms compatibility
CONTENT OF DELIVERY CONTENT OF DELIVERY
EtherNet/IP Adapter Class source code, include files, DLLs and EtherNet/IP Adapter Class include files, DLLs and Runtime
Runtime components for Microsoft Windows components for Microsoft Windows
Adapter (Server) demo application with source code for Adapter (Server) demo application with source code for
Microsoft Visual Studio Microsoft Visual Studio
User manuals User manuals
STC-File for ODVA EtherNet/IP Protocol Conformance Test STC-File for ODVA EtherNet/IP Protocol Conformance Test
Software Software
EDS-File for configuration with Rockwell Automation EDS-File for configuration with Rockwell Automation
RSNetWorx for EtherNet/IP RSNetWorx for EtherNet/IP
1.04.0120.00000 EtherNet/IP Adapter Developers Kit (EADK) 1.04.0122.00000 EtherNet/IP Adapter Communication Driver (EIPA)
97
EtherNet/IP Scanner CONTENT OF DELIVERY
Simulation Test Tool (EIPScan) EtherNet/IP Scanner Class executable program for Microsoft
Windows
Manual
EtherNet/IP Scanner Simulation Test Tool (EIPScan) is a Microsoft EDS-File for configuration with Rockwell Automation
Windows-based tool that simulates a full EtherNet/IP Scanner to RSNetWorx for EtherNet/IP
allow vendors to test and debug their EtherNet/IP products under
development.
ORDER NUMBER
1.04.0123.00000 EtherNet/IP Scanner Simulation Test Tool (EIPScan)
EIPScan provides I/O Server and I/O Client, Message Server and Mes-
sage Client functionality. EIPScan is capable of configuring a variety
of I/O connections based on the connection configuration set by
the user.
EIPScan was developed with the EtherNet/IP Scanner Developers

Kit (ESDK). The tool is compatible with Rockwell Automation RSNet-
Worx for EtherNet/IP.
The EtherNet/IP Scanner Simulation Test Tool is distributed as single

node license.
FUNCTION OVERVIEW
Scanner Class Functionality

- UCMM (unconnected) Message Server und Client
- Class 3 (connected) Message Server und Client
- Class 1 (connected) I/O Server und Client
Scanner simulation
- View and modify I/O data
Platform Compatibility
- EIPScan supports Microsoft Windows 2000/XP
98
EtherNet/IP HIGHLIGHTS
Adapter Module Hardware-based single chip solution for EtherNet/IP Adapter

devices
Reference design for Altera-FPGA with Ethernet Controller
FPGA-based solution for cost-effective EtherNet/IP and CPU (NIOS II)
Adapter implementations I/O cycle time (RPI) > 10 ms
EtherNet/IP Adapter software runs entirely on the module
Smaller applications can be implemented directly on the
EtherNet/IP Adapter module
Host connection via shared memory interface or serial interface
CONTENT OF DELIVERY
EtherNet/IP Adapter module with integrated EtherNet/IP

Adapter software
Host API in ANSI-C source code with programming example
Manual
Technical support
ADDITIONAL PRODUCTS
Baseboard for the EtherNet/IP Adapter module

OVERVIEW
The EtherNet/IP Adapter module represents a powerful solution for FURTHER INFORMATION
the implementation of EtherNet/IP Adapter functionality in devices
such as drives, I/O modules or encoders. For connection to the The technical details and features of the EtherNet/IP Adapter
application CPU, a serial interface or a shared memory interface is module are subject to change. The latest information can be found
available. The memory required for the data exchange is already on on the webpage.
the EtherNet/IP Adapter module, so that the interface of the appli-
cation CPU only has to be connected to the module.
ORDER NUMBER
For simple applications it is possible to run the application together
with the EtherNet/IP Adapter software on the module. Device On request EtherNet/IP Adapter Module
vendors can also integrate the hardware design instead of the add-on
module directly in their own circuit.
A Host-API is supplied together with the EtherNet/IP Adapter

module, which allows the module to be controlled via its interface.
The access and the configuration to the local objects of the Ether-
Net/IP Adapter module is supported by the Host-API. It is also pos-
sible to save configurations on the EtherNet/IP Adapter module.
Process data are exchanged between application CPU and the

EtherNet/IP Adapter module via separate storage areas for input
and output data. The application can use 1.5 kBytes for process data
in each direction.
A baseboard is available as a supplement to the EtherNet/IP Adapter

module. This provides the power supply necessary for the evaluation
of the module as well as various bus connections. With the base-
board it is possible to implement a simple I/O device directly or to
connect processor modules of Phytec (phyCORE-XC161 and
phyCORE-LPC2294) or Spectrum Digital (eZdsp F2812) to the Ether-
Net/IP Adapter module via the integrated plugboards.
99
IEEE 1588 PTP Introduction
The IEEE 1588 standard is known as "Precision Clock Synchroniza- First, one node (master clock) transmits a "Sync" telegram, which
tion Protocol for Networked Measurement and Control Systems" or contains the estimated transmission time. The exact transmission
"PTP" for short. PTP defines a procedure allowing many spatially time is captured by a clock and transmitted in a second "Follow Up"
distributed real-time clocks to be synchronized through a "package- message. Based on the first and second telegram and by means of
compatible" network (normally Ethernet). The technology behind its own clock, the receiver can now calculate the time difference
the standard was originally developed by Agilent and was used for between its clock and the master clock. To achieve the best possible
distributed measuring and control tasks. The challenge was to syn- results, the time stamps should be generated in hardware or as close
chronize networked measuring devices with each other in terms of as possible to the hardware.
time so that they are able to record measured values and provide The telegram propagation time is determined cyclically in a second
them with a precise system time stamp. Based on this time stamp, transmission process between the slave and the master ("delay"
the measured values can then be correlated with each other. telegrams). The slave can then correct its clock and adapt it to the
current bus propagation time.
Synchronization principle
In Ethernet systems, unpredictable collisions due to the CSMA/CD Configuration
procedure may lead to time packages being delayed or disappearing A PTP network configures and segments itself automatically. For
completely. For this reason, IEEE 1588 defines a special "clock syn- this, each node uses the "best master clock" algorithm (BMC) in
chronization" procedure. order to determine the best clock in the segment. Every PTP clock
stores its features within a specified dataset. These features are
transmitted to other nodes within its "Sync" telegrams. Based on
this, other nodes are able to synchronize their datasets with the
features of the actual master and can adjust their clocks accordingly.
Due to the cyclic running of the BMC, nodes can also be connected
or removed during propagation time (hot plugging).
No distinction is made in the protocol between a software clock

and a hardware clock. However, to be able to work with synchronism
in the nanosecond range, hardware support is required. Generally,
the synchronization errors – caused by software jitter – cannot be
eliminated. With a pure software solution (e.g. Windows systems),
the error may actually be in the micro- or milli-second range.
100
IEEE 1588 PTP
Protocol Software
The IEEE 1588 protocol software enables simple, rapid development
of IEEE 1588 compliant devices. Developed by IXXAT, the IEEE 1588
protocol software has a modular structure, insuring fast integration
into the target system. For access to the UDP/IP socket, the inter-
faces to the target platform are compiled in a separate adaptation
layer (network interface), considerably simplifying porting to the
target system.
SAMPLE IMPLEMENTATION FOR LINUX

Application
The content of delivery also includes a sample implementation on a
IEEE 1588 target with IEEE 1588 hardware support. The target is a MPC8360
Control Engine from Freescale with PowerQUICC technology. The PowerQUICC
(Best Master Clock Algorithm)
MPC8360 has 2 eTSEC (Enhanced Triple Speed Ethernet Controller).
By capitalizing upon its hardware integrated time unit and system
Mngmt Slave Master clock, a nano-second time precision can be achieved with a CPU
SIS workload of less than one percent. Furthermore, the MPC 8360 has
Dispatcher input/output trigger ports and a PTP based timer, allowing each
application to use this precise time base on a nano-second level.
Network Interface Time Stamp Unit (TSU)
CONTENT OF DELIVERY
UDP/IP Clock Interface (CIF)
Source code
Ethernet Controller Clock Software license
Manual
Demo implementation for Windows 2000/XP
The software is completely independent of the operating system and Sample implementation for PowerQUICC MPC8360
therefore, can also be used in applications without an operating (with hardware support)
system (superloops). The only requirement is a multicast-compatible Windows demo program
UDP/IP stack. Technical support
FUNCTIONALITY ADDITIONAL SERVICES

(not included in the content of delivery)
The IEEE 1588 software package includes a full implementation of
the standard for Ethernet with the following functionality: Maintenance agreement
As a supplement to the software package, IXXAT offers a mainten-
Ordinary clock ance agreement that includes the provision of the following services
Boundary clock for the term of the agreement:
Best master clock algorithm
Configuration and scaling via central configuration file Free updates and troubleshooting
Management API Adaptation to the latest standard
Technical support
WINDOWS DEMO IMPLEMENTATION Code introduction

IXXAT also offers a one-day introduction to the code that focuses on
Included in the software package is a demo implementation of a interfaces, processes and data flows in the IEEE 1588 software. Spe-
software-only solution that can be run directly under Windows. The cific questions concerning the adaptation can also be answered
demo implementation provides the basis for the IEEE 1588 Windows while direct adaptations to the code can also be carried out.
demo, which can be downloaded for free from the IXXAT webpage.
System time, time delay and other relevant information are dis- Implementation support
played with the Windows demo program. As an additional program offering, IXXAT can also handle the adap-
tation, implementation and testing of the IEEE 1588 software on
your system.
101
PROFINET Introduction
PROFINET is the innovative, open standard for industrial Ethernet in The highest requirements come from the control of complex drive
automation technology. The PROFINET Standard is specified systems like packaging machines or robotics. With PROFINET IRT
and published by PI (PROFIBUS & PROFINET International – (Isochronous Real Time) applications with cycle time < 1 ms and
www.profibus.com). jitter < 1 µs are possible. This is accomplished by the usage of
specific hardware for the Ethernet interface.
PROFINET provides solutions for process automation, factory auto-
mation and motion control. PROFINET enables the integration of
existing fieldbus systems, like PROFIBUS, Interbus, DeviceNet and Internet
Process
Automation
Factory
Automation
Motion
Control
other technologies to an open Ethernet based network. NRT RT IRT
PROFINET uses Ethernet standard as well as TCP, UDP and IP as
protocols for communication, configuration and diagnosis in the
network.
100 ms 10 ms < 1 ms
IT TCP/IP
Device Profi- Process RealTime
I/O Encoder Robots Drives SEMI Others
les
Application Application
On the application side three different device types are defined: IO-
Presentation Application Interface
Controller – the classic PLC (Master), which establishes connections
to the devices, exchanges data and controls the system, IO-Device
Session PROFINET Kernel – the device (Slave) which is assigned to the controller to exchange
data, and IO-Supervisor – the interface for programming, commis-
DCOM
sioning and diagnosis in the network.
RPC
Transport PROFINET Real Time Channel
TCP UDP Beside communication and exchange of I/O data the PROFINET
Network IP standard also defines the topology and structure of the network.
DataLink Ethernet CSMA/CD Guidelines for the cabling, the selection of suitable connectors and
topology components facilitate the planning and the commissio-
Physical Link Ethernet Physical Layer ning of a PROFINET network. The user has the choice between a star
structure using (managed) switches which is common in IT business,
the classical line structure used in PROFIBUS systems and tree struc-
ture which combines both principles.
The PROFINET standard defines three different performance levels
which cover the various requirements from different applications. The migration of existing PROFIBUS systems to PROFINET systems
For non-realtime applications, PROFINET NRT (Non Real Time) is can easily be achieved by using Proxies (Gateways) which enable
defined. It uses standard protocols as UDP/IP. With cycle times > the communication and the data exchange between both networks.
100 ms PROFINET NRT targets for applications in process automation.
The device profiles already known from the PROFIBUS world can
For applications with higher requirements on cycle time like factory also be used for PROFINET. With PROFIdrive a powerful profile for
automation, PROFINET RT (Real Time) is the right choice. I/O data is the implementation of high-performance drive solutions is available.
exchanged directly using the Ethernet protocol, while diagnosis and
configuration uses standard UDP/IP. PROFINET RT enables applica- For safety-relevant applications, the PROFIsafe profile for PROFINET
tions with cycle times > 10 ms. and PROFIBUS DP systems is defined.
102
PROFINET
IO-Developer’s Kit
The PROFINET IO Developer’s Kit enables developers of embedded
products to add quickly PROFINET IO Device functionality to a
product’s feature set.
FUNCTION OVERVIEW
PROFINET IO Device functionality:

- Cyclic data exchange with a PROFINET IO-controller
- Sending and receiving of diagnostic and process alarms,
and plug and pull alarms
- Assignment of IP addresses and device names via Ethernet
SUPPORTED TARGET SYSTEMS
The PROFINET IO-Developer’s Kit is delivered for NetSilicon® NS9360

Development Kit and is instantly running on this system with the
demo application.
An adaptation to other systems is possible for the PROFINET IO-

Developer’s Kit. A suitable operating system as well as TCP/IP pro-
tocol stack must be already available for the target system, they are
not content of delivery of the PROFINET IO-Developer’s Kit.
This adaptation can also be done by IXXAT.
CONTENT OF DELIVERY
PROFINET IO Device source code and include files

Demo application for NetSilicon® NS9360 Development Kit
Manual
GSD-File for integration with Siemens STEP 7
ORDER NUMBER
On request PROFINET IO-Developer’s Kit
103
PROFINET HIGHLIGHTS
IO Device Module Hardware-based single chip solution for PROFINET IO Device

devices
Reference design for Altera-FPGA with Ethernet Controller
FPGA-based solution for cost-effective PROFINET and CPU (NIOS II)
IO Device implementations Real Time (RT) communication with cycle time > 10 ms
PROFINET IO Device software runs entirely on the module
Smaller applications can be implemented directly on the
PROFINET IO Device module
Host connection via shared memory interface or serial interface
CONTENT OF DELIVERY
PROFINET IO Device module with integrated PROFINET IO

Device software
Host API in ANSI-C source code with programming example
Manual
Technical support
ADDITIONAL PRODUCTS
OVERVIEW Baseboard for the PROFINET IO Device module
The PROFINET IO Device module represents a powerful solution for

the implementation of PROFINET IO Device functionality in devices FURTHER INFORMATION
such as drives, I/O modules or encoders. Supported is the perfor-
mance level Real Time (RT). For connection to the application CPU, The technical details and features of the PROFINET IO Device module
a serial interface or a shared memory interface is available. The me- are subject to change. The latest information can be found on the
mory required for the data exchange is already on the PROFINET IO webpage.
Device module, so that the interface of the application CPU only
has to be connected to the module. ORDER NUMBER
For simple applications it is possible to run the application together On request PROFINET IO Device Module
with the PROFINET IO Device software on the module. Device
vendors can also integrate the hardware design instead of the add-
on module directly in their own circuit.
A Host-API is supplied together with the PROFINET IO Device mo-

dule, which allows the module to be controlled via its interface. The
access and the configuration to the local data of the PROFINET IO
Device module is supported by the Host-API. It is also possible to
save configurations on the PROFINET IO Device module.
Process data are exchanged between application CPU and the PRO-
FINET IO Device module via separate storage areas for input and
output data. The application can use 1.5 kBytes for process data in
each direction.
A baseboard is available as a supplement to the PROFINET IO Device

module. This provides the power supply necessary for the evaluation
of the module as well as various bus connections. With the basebo-
ard it is possible to implement a simple I/O device directly or to connect
processor modules of Phytec (phyCORE-XC161 and phyCORE-
LPC2294) or Spectrum Digital (eZdsp F2812) to the PROFINET IO
Device module via the integrated plugboards.
104
NicheStack IPv4 & OVERVIEW PROTOCOLS/SERVICES
NicheLite TCP/IP NicheLite Mini-IP NicheStack

Code Size 4 kB 15 kB
Communication Protocols
UDP x x
NicheStack and NicheLite are both fully functional and easily por- IP x x
table TCP/IP stacks that contain all basic protocols for Internet-, Routing – x
Intranet- and LAN-connections. They are supplied as source code
ICMP x x
(ANSI-C) together with a socket API and comprehensive, detailed
documentation. ARP x x
Network 1 Interface Unlimited
Both stacks contain the following protocols and services: Multicast – x
Address Resolution Protocol (ARP)

Internet Protocol (IP) NicheLite Mini-TCP NicheStack
Internet Control Message Protocol (ICMP) Code Size 6 kB 31 kB
Dynamic Host Configuration Protocol Client (DHCP-Client) x x
TCP
Trivial File Transfer Protocol (TFTP)
Transport Control Protocol (TCP) Sockets Mini (BSD Subset) Full BSD
User Datagram Protocol (UDP)
NicheTask (on request)
Additionally, the NicheStack also includes: SPECIFIC FEATURES
File Transfer Protocol (FTP) Easy integration: NicheStack and NicheLite can be used in
TELNET connection with RTOS as well as being integrated in super-
IP Multicast loops. Special multitasking capabilities are not required.
Versatile, flexible memory management: memory is used
economically and available again immediately after use.
MEMORY REQUIREMENTS Memory is allocated via macros and can thus be easily adapted
to various compilers.
The two stacks differ in some functional features which results in RTOS-independent: both stacks provide an "Application
different codesize: NicheLite is extremely slim and requires only Process Interface" for major operating systems, simplifying
about 12 kByte of code. However, it supports only one interface integration into these operating systems.
(Ethernet-Controller, PPP, etc.), does not allow routing or multicasting, Network interfaces: both stacks support Ethernet, Token Ring,
and has only a mini-socket with BSD-subset. While NicheStack does SLIP and PPP.
not have these limitations, it does require substantially more Zero-Copy-Stack: for the exchange of data between various
memory. A standard application on a 32-bit processor with ARP, IP, protocol levels, a single memory buffer is used. The buffer is
ICMP, UDP, DHCP and TCP results in a code size of about 42 kBytes. passed by reference, not copied, from one protocol level to the
A socket-API increases the code requirement to approximately next, providing maximum performance with minimal memory
52 kBytes. requirement.
105
NicheStack IPv6 & NicheStack FTP
NicheStack Dual IPv4v6 The FTP-stack supplements the TCP/IP-protocol stacks by the client
and server functions of the File Transfer Protocol FTP. FTP offers the
Communication Protocols user a standardized file exchange between two systems and checks
the integrity of the data. The stack contains a FTP-Client as well as
The products NicheStack v6 and NicheStack Dual v4v6 are a logical a FTP-Server.
further development of the NicheStack for the new Internet stan-
dard IPv6. NicheStack v6 supports the new Internet standard IPv6. NicheStack POP3
NicheStack Dual v4v6 supports both IPv4 and IPv6. This is done at
package level, where it is possible to use both protocols (IPv4 and The POP3 module allows the implementation of the e-mail protocol
IPv6) in parallel on one network. POP3 on an embedded system, allowing e-mails to be picked up
from any POP3 e-mail server.
Protocols contained in NicheStack v4 and NicheStack Dual v4v6: see
NicheStack IPv4. NicheStack SMTP
SPECIFIC FEATURES NicheStack SMTP allows the implementation of e-mail notification
functions on an embedded system. Therefore, pre-defined e-mails
Specifically optimized for embedded applications (code size, can be sent to any e-mail address; for example, to specifically draw
memory requirement and performance) attention to faults or in order to transmit production data automa-
Easily portable via ANSI-C source code tically. It is also possible to send e-mails to several addresses.
Prepared for real-time operating systems (upcalls) or Superloop
(contained as a template in the source code) DHCP-Server
Stack works in blocking mode or non-blocking mode
Supports MIB-II statistics (number of packages transmitted/- This software package allows the implementation of a DHCP server
received, retransmits, collisions,...) for troubleshooting and on an embedded system. This enables the system to allocate tempo-
optimization rary or permanent IP-addresses to Clients. DHCP is the standard
method to allocate a temporary IP-address to devices which do not
have a permanent one.
Add-ons
NicheStack HTTP-Server
NicheStack IPSec/IKE
NicheStack HTTP Server enables a full Webserver to be implemented
IPSec/IKE allows encryption of all data contents of IP packages. The on an embedded system, making it possible to access this system by
keys can be replaced via the Internet (public/private key procedure). means of common browsers such as Netscape Navigator or Internet
Available encryption mechanisms: DES, Triple DES, AES (128, 192, Explorer in the same way as any other server in the network.
256 Bit), MDS, SHA-1, SHA-2 (256, 384, 512 Bit). All standard features of a web-server, like CGI, SSI, Server Push and
authorization of selected webpages are supported by NicheStack
NicheStack SSL HTTP Server. In addition, NicheStack HTTP Server includes a HTML
compiler which can integrate standard HTML files, pictures (gif, jpg)
SSL allows encryption of the complete TCP data traffic and is often or Java applets into the webserver project without needing to
considered to be the standard for encryption of Internet data (e.g. implement a file system.
online banking). Available encryption mechanisms: RC4 (128 bit key),
Triple DES, MD5, SHA-1 (160 bit). SNMP v1, v2c or v3 Agent
NicheStack TELNET-Server The Simple Network Management Protocol is the most commonly
used protocol for the configuration and maintenance of network
The TELNET-Server is an additional package for the TCP/IP-protocol components. An SNMP-agent can be implemented with each of the
stacks (already included in NicheStack IPv4) and allows remote three SNMP-modules.
access or remote control of the device via a network. It is completely
compatible with the standard TELNET-Clients contained, for example, NicheView
in operating systems such as Windows.
NicheView is a physically accommodating yet extremely efficient
NicheStack PPP WWW-browser for embedded systems.
This product provides an interface for all user inputs such as key-
The PPP protocol stack is an additional package for the TCP/IP pro- board inputs, mouse-clicks etc. and for outputs such as text or image
tocol stacks. It includes the protocols LCP, IPCP, PAP and CHAP and displays etc. With a code size of only 35 kByte, NicheView imple-
allows the TCP/IP stack communication via the serial interface. ments HTML 3.2, multiple fonts, plug-ins and JavaScript in one
Utilization of a telephone modem (analogue, ISDN, GSM) is suppor- device. It supports frames, animated GIFs, Color and JPEG, as well as
ted by the NicheStack PPP. tables and forms.
106
SAE J1939 Introduction
The SAE J1939 protocol was defined by the SAE for use in commercial SAE J1939 in the ISO/OSI layer model
vehicles, but it is also used in ships, rail-bound vehicles, agricultural SAE J1939 is divided into several layers according to the OSI layer
machinery and large generators. In addition, SAE J1939 serves as model, where each level is specified in a separate document. In a fa-
the basis for the international standards NMEA 2000 (marine) and shion similar to practically all fieldbus protocols, since layers 5 and
ISO 11783 (ISO bus for agricultural machinery), allowing the protocol 6 are not needed in SAE J1939, they are also not specified.
stack to also be used for these applications as well.
In the commercial vehicle sector, serial protocols standardized by 7 Application

SAE J1939/71
the SAE have been used for a long time, for communication bet- SAE J1939/73
ween the individual electronic control units and components of the 6 Presentation
SAE J1939/01
SAE J1939/81
drive train. The J1708/J1587 protocol based on the serial port 5 Session
normally available in microcontrollers can be considered the prede- 4 Transport SAE J1939/21
cessor. 3 Network SAE J1939/31
2 Data Link SAE J1939/21
Due to the required compatibility with the J1708/J1587 protocol, an 1 Physical SAE J1939/11
extension of the CAN message identifier from 11 to 29 bits (exten- SAE J1939/12
ded format) and the development of CAN modules or protocol im- Documents
plementations which support this message format was required for
J1939. The functionality of SAE J1939 is divided into layers as follows:
With the availability of the extended CAN identifier it is possible to Layer 1 (physical layer) describes, among other things,
map the principle of the definition of communication relationships the electric interface with the physical medium.
to CAN as used in J1708. For this, part of the identifier is used to Layer 2 (data link layer) describes the data communication
specify an 8-bit source and an 8-bit target address (node number). via CAN based on the specification CAN 2.0B.
Layer 3 (network layer) essentially describes the functionality
Therefore, via SAE J1939, it is possible to both transmit measure- of a bridge for the transmission of messages between two net-
ment values and control data and to configure components. In ad- work segments and is only relevant for the implementation of
dition, it is also possible to read or delete diagnosis data of a J1939 bridge.
individual components and to carry out a calibration of individual Layer 4 (transport layer) describes the various network services
controls. for message request mode, acknowledged transmission, and frag-
mented transmission of large data blocks.
To make this possible, all variables relevant for the commercial Layer 7 (application layer) describes the actual data (parame-
vehicle sector are defined with value ranges, resolution, identifica- ters or network variables with value range, resolution, physical
tion number etc. in SAE J1939. This was implemented on the basis unit and the type of transmission). Each message is unambi-
of the specification already available for J1587. guously referenced by a number (parameter group number).
Since the network management can be regarded as a separate
Thus, in the J1939 protocol, not only are the type of transmission, unit which reaches through to the hardware (layer 1), this
the structure of messages and their segmenting, flow checks etc. block in the layer model is shown as an independent function
specified but the content of the messages itself can also be precisely block on the right-hand side. The network management basi-
defined. cally consists of the automatic allocation or determination of
node addresses (plug & play principle). Node monitoring is not
defined in SAE J1939 and must be implemented via cyclic
messages at the application level.
107
SAE J1939 VARIANTS
Protocol Software The SAE J1939 software is available in two variants:
The Micro variant is optimized for use on 8-bit CPUs with very
Software Package for the Development limited RAM resources. Here the software is configured completely
of J1939 Devices statically by generated files via the configuration tool. As in this
case all configuration parameters can be placed in the Flash
The SAE J1939 protocol software enables a simple, fast development memory, the RAM requirement for the SAE-J1939 software is sub-
of SAE J1939 devices. All communication mechanisms defined in stantially reduced.
the SAE J1939 specification are available (except for the bridge
functionality), so that the developer can concentrate fully on his or The standard variant allows the dynamic configuration of the SAE
her application. J1939 software via the function interface and therefore during run-
time. This variant supports several software instances (CAN chan-
As the user interface is designed as a universal message-based nels) and is also prepared for use with a real-time operating system.
function interface, the protocol stack can be universally used and However, the software can also be used in an application without
is therefore also the basis for other protocols such as NMEA 2000 an operating system.
and ISO 11783 (ISOBUS). In addition, it is possible to adapt the stack
to the message defined in the standard 1939/71 and therefore to
work on variable/signal level via generatable mapping functions and SUPPORTED PROCESSORS/CAN CONTROLLERS
macros.
The SAE J1939 Software is independent of hardware and can be
This is made possible via a graphic configuration tool which, in used on a large number of micro controllers and CAN controllers. For
addition to generation of the mapping functions, permits the com- processors of the following manufacturers (valid at time of printing
plete configuration of the stack as well as the generation of a tem- of this catalog), IXXAT supplies reference implementations:
plate file for the application. In addition, a plausibility check of all
configuration parameters ensures that configuration errors of the Atmel
user are avoided. Freescale
Infineon
The modular structure of the protocol software based on the OSI Microchip
layer model allows an optimum adaptation to the individual target x86 Architecture
system. For example, access to the CAN controller is implemented
by an appropriate CAN interface whose functions are included in a A complete overview of all available versions can be found on the
separate module. The software can therefore easily be adapted to web page under the following link:
further CAN controllers if required. www.ixxat.com/j1939_stack_available_versions_en.html
The documentation and sample programs provided enable a fast Adaptation to SAE J1939 software on processors not directly sup-
start-up with the SAE J1939 software. All sample programs are ported can be carried out with the aid of the standard C code in a
directly executable on a reference platform (evaluation board of the few days. IXXAT will be pleased to carry out the adaptations of the
CPU vendor or IXXAT PC/CAN interface card). Normally, porting can SAE J1939 software for you.
be carried out on the target hardware within a few days.
FUNCTIONALITY
Source code
Transmission and reception of application-specific messages Configuration tool with graphic user interface
(acknowledged and unacknowledged). Company license (restricted to company location and business
Treatment of transport protocols for large data blocks field) detailed manual
(message- and subscriber-oriented). Detailed manual
Simultaneous communication to several subscribers Sample programs
Support of the "address claiming" process for the dynamic Technical support
definition of the node address
Support of cyclic transmission and reception of messages
with time-out supervision
The target hardware has to provide one free timer interrupt for time
monitoring of the protocol as well as an interrupt line of the CAN
controller.
108
FURTHER SERVICES
(not included in contents of delivery)
Maintenance contract
IXXAT offers a maintenance contract to supplement the software
package. The maintenance contract includes the following services
during the contractual period:
Free updates and troubleshooting

Technical support
Introduction to the code

One-day introduction to the code. Interfaces, processes and data
flows in the SAE J1939 software are explained. Direct questions con-
cerning the adaptation to be carried out can also be answered and
adaptations to the code can be made.
IXXAT handles adaptation, implementation and testing of the SAE
J1939 software to your hardware or application.
J1939 Module
The J1939 module is an extension for the IXXAT canAnalyser and
provides powerful functions for recording, interpretation and analysis
of J1939 messages.
ORDER NUMBER
1.02.0285.TTDDC SAE J1939 Protocol Software (Versions on request)
109
LIN Introduction
LIN (Local Interconnect Network) is a low-priced serial communica-
tion system that was specially developed for cross-linking simple
electronic assemblies in automobiles. LIN is particularly useful in
areas where simple sensors and actuators are to be networked but sync sync identifier 1-8 data bytes check
where the efficiency of CAN (Controller Area Network) is not required. break field LIN telegram sum
Generally the sub-systems connected with LIN (e.g. doors, seats,
steering wheel) are connected to higher order CAN-based networks
(body, chassis). This provides simple access for CAN-based diagnostic Event triggered frame
and service tools. The LIN specification 2.0 defines an event-triggered frame in addition
to the standard frame (unconditional frame). For this, several frame
Communication principle IDs are defined as event triggered within the network. If the master
The LIN technology is a serial single wire communication protocol device requests such a frame, the corresponding slave starts to
based on the standard SCI interface (UART). Access to the LIN bus transmit data. When this occurs, the slave also transmits a frame ID
is controlled by a master which guarantees a maximum latency time. of a standard frame within the first data byte which is assigned to
A special characteristic of LIN is the synchronization of the slave this information. If a collision occurs or if an event triggered frame
devices via the bus, where implementation is made possible by low- can not be identified correctly, the information will then be trans-
priced nodes with simple resonant circuits. Data communication mitted individually by using a standard frame.
takes place by means of a 12 V single wire line with a maximum
data transmission rate of 20 kBit/s. LIN products and services
Due to the small number of identifiers (64) as well as the relatively IXXAT offers products and services for LIN. Our powerful LIN-to-
low bit rate, a typical LIN system has up to 16 nodes. The clock syn- CAN gateway "LIN2CAN" allows the emulation of LIN slave and
chronization, simple UART communication, and the single wire master/slave devices and can also be used as a PC interface to
medium all contribute to the low cost of a LIN system. analyze LIN systems. Since the automotive version of our USB-to-
CAN II interface provides both a CAN interface and a LIN interface,
Message format it can also be used for the time synchronous analysis of LIN and
The transmission of a LIN telegram begins with a 13-bit long domi- CAN systems.
nant level (sync break) transmitted by the master which is used to Capitalizing upon its development experience and applied expertise,
identify the start of the frame. Then the master transmits a sync IXXAT also offers customized development of hardware and soft-
field (alternate 1-0 sequences). This can be used by the slave node ware for LIN and, the implementation of LIN interfaces and proto-
for clock synchronization. cols in customers' systems.
After the sync field, the identifier is transmitted by the master. This
consists of a 6-bit long message ID and a 2-bit long parity field. Further information about LIN
In addition to the ID, the message ID contains an optional message Further information about LIN can be found on the official LIN web-
length information (2, 4 or 8 data bytes). The slave, which is page (www.lin-subbus.org) or within our article "Successful testing
addressed by the message ID, now transmits its data bytes (1-8 data of LIN systems".
bytes) followed by a checksum. The protocol version 1.3 uses the
classic checksum whereas protocol version 2.0 uses the enhanced
checksum.
110
LIN2CAN LIN Slave Emulation
The LIN slave mode provides a stand-alone LIN slave emulation. The
Powerful LIN-CAN-Gateway device has a configurable transmission table. When a LIN header is
received, the stored data is transmitted. The table is configurable by
the PC and is stored in the flash memory of the device.
LIN Master Slave
As a LIN Master/Slave, the device works as a stand-alone LIN bus

arbiter with LIN-Slave function. Here a configurable schedule list is
available, which is processed cyclically. In addition to the bus arbiter
function, a transmit function is also available in this mode via a
configurable transmit list.
LIN PC Interface
In addition to the stand-alone modes, the LIN-CAN Gateway can

also be operated via the serial interface as a PC interface. Here, for
example, the device can be operated as a LIN-Slave where the LIN
objects on the PC are available for monitoring. The transmit table
can be modified interactively. In addition, the LIN-Master function
is available where the bus arbiter function can be triggered from
OVERVIEW the PC. With these functions, a PC-supported simulation of LIN-
Slave or -Master devices is possible.
The LIN-CAN gateway is a universal device for both the analysis of
LIN networks via the CAN bus and for the emulation of LIN slave or All modes can be configured via PC. The configuration values are
master modules. In addition, the device can be used as a LIN-PC stored in the FLASH Memory of the device and can be read out by
interface for PC-based configuration and monitoring software, or, the PC.
for PC-supported LIN device development.
TECHNICAL DATA
OPERATION MODES
The LIN-CAN Gateway supports four operating modes: Interfaces 1x CAN ISO 11898-2 High-Speed,
1x CAN ISO 11898-3 Low-Speed,
LIN-CAN Gateway as LIN Master or LIN Slave 1x LIN, 1x RS232
LIN-Slave Emulation Memory extension 6 kByte RAM data memory, 128 kByte Flash,
LIN-Master-Slave Emulation 512 kByte external SRAM
LIN-PC Interface Extras Configurable Sleep mode with Wake up via CAN,
LIN or RS232
The various modes can be configured and activated via PC. The Power supply 7 V - 16 V DC, 1.5 W
configuration is saved as "non-volatile" in the device so that the Temperature range -20 ºC to +70 ºC
configured mode can be started automatically after power-on. Certification CE
LIN CAN Gateway

The LIN-CAN Gateway mode allows the transparent transmission
of LIN messages to a CAN network. The device works as a LIN master LIN2CAN
or LIN slave. Received LIN messages are passed on to CAN and the Configuration software for Windows 2000/XP
LIN identifiers are translated into CAN identifiers. The LIN data is User's manual
passed on via the CAN object. The device also provides a transmit
function to LIN via CAN. For this, CAN identifiers are translated into
LIN identifiers and, when requested by a LIN master are transmitted ORDER NUMBER
once in the LIN network. The data of the CAN object is stored in a
buffer and then transmitted as LIN data. PC programmable trans- 1.01.0130.00000 LIN2CAN
lation tables, which are stored on the device, are available for the
translation of the messages.
111
USB-to-CAN II CONTENT OF DELIVERY
Automotive USB-to-CAN Automotive, 2 adapter lines on Sub D9,

user’s manual
Intelligent CAN/LIN interface for the USB port Simple CAN bus monitor "miniMon"
ORDER NUMBER
1.01.0066.11220 USB-to-CAN II – Automotive version,

galvanic decoupled
The USB-to-CAN II is an active interface with two CAN and one LIN
channel. It can be connected to the PC via USB with the VCI-V3
driver included in the scope of supply, and, an additional LIN add-
on driver.
The VCI driver enables time-synchronous layer 2 analysis of CAN
and LIN networks. LIN communication is supported on the USB-to-
CAN II either in LIN master or slave mode.
In LIN slave mode, the interface responds automatically to received
master requests.
The response data is updated by means of a buffer via the PC-API.
In LIN master mode, master requests are processes by the PC appli-
cation. All received LIN messages are passed on to the application
with time stamp, master request, response and status information.
TECHNICAL DATA
PC bus interface USB, Version 2.0 (full speed)

PC address space Plug & Play
Microcontroller Infineon 161u, 36 MHz
CAN controllers two Philips SJA 1000
CAN bus interface 2 x RJ45 connectors with RJ45 on Sub-D9 adapter
line (10 cm), galvanic decoupled, 1 x ISO/IS
11898-2, 1 x ISO/IS 11898-2 and 11898-3 switch-
able via software
LIN protocol V1.3 and V2.0
LIN bus interface 1 x LIN master/slave switchable via software
Power supply 5 V, 400 mA max. via USB
Dimensions 98 x 55 x 20 mm
112
FlexRay Introduction
FlexRay is a fast, deterministic and fault-tolerant bus system for A B C D E
automotive use, based on the experience of DaimlerChrysler with
the development of prototype applications and the byteflight com- Channel A
munication system developed by BMW. byteflight was developed Channel B
by BMW especially for use in passive safety systems (airbags).
In order to also fulfill the requirements of active safety systems, 1 2 3 4 5 6 7 8 11
A1 B1 C1 A3 E1 B2 B4 E2
byteflight was further developed by the FlexRay consortium in par- Channel A
ticular relation to time-determinism and fault tolerance. Today, the 1 2 3 4 5 6 7 9 t
carmakers BMW, DaimlerChrysler, General Motors, Volkswagen as A2 C1 D1 A4 E1 A4
Channel B
well as the companies Bosch, freescale and Philips Semiconductors t
are represented as core partners in the FlexRay consortium. Static Segment Dynamic Seg.
The data exchange between the numerous control devices, sensors Communication Cycle
and actuators in automobiles is nowadays mainly carried out via
CAN networks. However, the introduction of the new x-by-wire FlexRay communication cycle
systems results in increased requirements especially with regard to
error tolerance and time-determinism of message transmission.
FlexRay fulfils these increased requirements by message transmis- Data rate of FlexRay
sion in fixed time slots and by fault-tolerant and redundant mes-
sage transmission on two channels. FlexRay communicates via two physically separated lines with a data
rate of 10 Mbit/s each. The two lines are mainly used for redundant
and therefore fault-tolerant message transmission but can also
Access to the transmission medium transmit different messages, in which case the data throughput is
doubled.
FlexRay works according to the principle of TDMA (Time Division
Multiple Access), where the components or messages have allocated FlexRay can also be operated with lower data rates of 2.5 or 5
fixed time slots in which they have exclusive access to the bus. The MBit/s. Bus topologies, active and passive star topologies as well as
time slots are repeated in a fixed cycle. The time at which a message mixed topologies are defined for data transmission.
is on the bus can be exactly predicted and bus access is therefore
deterministic.
Synchronization of nodes
However, the fixed allocation of the bus bandwidth to the compo-
nents or messages by means of fixed time slots has the disadvan- In order to implement synchronous functions and optimize the
tage that the bandwidth is not fully exploited. For this reason bandwidth by means of small distances between two messages, the
FlexRay subdivides the cycle into a static and a dynamic segment. distributed components in the communication network require a
The fixed time slots are situated in the static segment at the begin- common time base (global time). For clock synchronization, specific
ning of a bus cycle. In the dynamic segment the time slots are messages tagged as synchronization messages are transmitted in
assigned dynamically. Exclusive bus access is only enabled for a the static segment of the cycle. With the aid of a special algorithm,
short time in each case (so-called "mini-slots"). The time slot is only the local clock-time of a component is corrected in such a way that
extended by the required time if a bus access occurs within a mini- all local clocks run synchronously to a global clock.
slot. Bandwidth is therefore only used up when it is actually needed.
113
Structure of a FlexRay network node Multibus Analyser
A FlexRay network node consists of a host processor, FlexRay comfor FlexRay
munication controller (CC), optional bus guardian (BG) and bus
driver (BD). The host processor supplies and processes the data,
which is transmitted via the FlexRay controller. Based on the experience made in analyzing automotive bus systems
in the CAN area, IXXAT developed its Multibus Analyser. The Multibus
The bus driver connects the communication controller to the bus, Analyser is operating together with the FlexRay CCM PC interface
the bus guardian monitors access to the bus. The host processor and provides functions for receiving, transmitting as well as tracing
informs the bus guardian which time slots the FlexRay controller and the interpretation of FlexRay and CAN messages.
has allocated. The bus guardian then allows the FlexRay controller
transmit access within these time slots. Data can be received at any
time.
Device 1 Device 2
Host Communication Host Communication
(µC) Controller (µC) Controller
BG BG
BD BD BD BD
Channel 1
Channel 2
FlexRay network node
FUNCTION OVERVIEW
Reception and display of messages (receive module)
The receive module of the Multibus Analyser provides the online

display of the FlexRay and CAN messages (raw data). The messages
can be displayed in scroll and overwrite mode. In scroll mode the
FlexRay messages are displayed with timestamp, ID, cycle and channel
number. In the overwrite mode the messages are displayed in the
order of either the identifier, the channel number or FlexRay cycle
at cycle reception and are always updated by the latest received
messages.
As a special feature, the receive module highlights the contents of
a message which has changed in order to make the changes ob-
vious.
The message status vector is also displayed and interpreted, static
and dynamic messages are tagged. The receive module provides
filter functions for selecting and displaying data with respect to
message, cycles, IDs, channel number or message status.
114
Transmitting of messages (transmit module)
Recording of messages (trace module)
The Multibus Analyser can also be operated as a network node pro-
The trace module allows the online logging of the entire communi- viding the transmission of pre-defined messages.
cation on hard disk. The received messages (with timestamp, cycle
number, ID and channel) as well as relevant errors are recorded for
offline evaluation.
The trace module has a manual start/stop function and a trigger/filter
mode. Recorded messages can be converted to various formats.
The multibus functionality of the analyser allows the user to analyze
FlexRay and CAN systems synchronously.
Scripting Host and .net Interface
The scripting host is a powerful interface which allows the user to

adapt the Multibus Analyser quickly and easily to specific simulation
and analyzation tasks. For test and device simulation the interface
provides functions for the transmission and reception of FlexRay
and CAN messages.
The scripting host supports the Windows scripting languages C#
and Visual-Basic-Spript as well as .NET visual components.
CAN modules
In addition to the FlexRay function modules the Multibus Analyser

provides various modules for CAN analyzing and stimulation from
the canAnalyser product (see canAnalyser).
Display and interpretation of physical signals
(signal module)
IMPORT/EXPORT FUNCTIONALITY
The signal module enables the interpretation of the signals transmitted
in a FlexRay or CAN message. Similar to the receive module, a scroll Data interpretation: CAN IXXAT XML, CANdB, Fibex
and an overwrite mode is available for displaying the interpreted FlexRay: IXXAT INI, Fibex
signals. The display can be completely customized in order to meet
the users requirements. Furthermore, the signal module provides a
cycle time monitor. The data interpretation rules are provided accor- ORDER NUMBER
ding to the ASAM Fibex data description standard. This allows the
visualisation of the network, whereby the received signals can be 1.02.0241.00000 Multibus Analyser FlexRay
assigned to the devices.
115
FlexRay CCM DUAL CHIP EXTENSION
With the dual chip extension, two FlexRay cold starters can be
PC interface for FlexRay and CAN implemented with one hardware platform. Thus the device can also
start FlexRay networks containing only integration nodes.
EMBEDDED PROGRAMMING EXTENSION
An extension package enables the implementation of own software

components on the Embedded FlexRay CCM hardware. Thus the im-
plementation of transport protocols, real-time simulations or gate-
way solutions is possible.
TECHNICAL DATA
FlexRay 2 x 10 Mbit/s
FlexRay protocol chips: freescale MFR4300 (2x MFR 4300
with dual chip extension)
Analysis of the FlexRay start-up behavior (asynchronous
analysis mode)
FlexRay interface: Philips TJA 1080
2 x CAN ISO/IS 11898-2 and ISO/IS 11898-3 switchable via
The FlexRay CCM is a powerful FlexRay/CAN platform for both PC- software
based and stand-alone applications. As an open PC interface, it is Connection to PC with Fast Ethernet 10/100 Mbit/s
measuring hardware for comprehensive analysis and simulation 4 trigger outputs, 2 trigger inputs
tasks for FlexRay and CAN networks. An exact local time enables MPC 866 microcontroller system with 130 MHz
synchronous logging of FlexRay and CAN messages. The FlexRay 4 Mbyte RAM, 32 Mbyte Flash
analysis is carried out both via the FlexRay protocol module and via Power supply with 6.5 to 50 V DC
an asynchronous bit stream analysis, so that both the start-up Temperature range -40 to +70 ºC
behavior and specific errors on the FlexRay bus can be detected.
The powerful micro-controller system (MPC 866, 130 MHz) allows CONTENT OF DELIVERY
real-time-critical tasks to be performed directly on the hardware in
the form of add-on software modules. In this way, real-time rest FlexRay CCM
bus simulations, protocol implementations or emulation functions Power cable
can be implemented. Ethernet cable
Driver CD
The FlexRay CCM can also be used as an autonomous device, which Manual
enables use as a FlexRay/CAN gateway, for example.
The interface communicates via Fast Ethernet TCP/IP (10/100Mbit/s)
and is designed for processing of 100 % bus load on all bus systems. ORDER NUMBER
The interface is connected to FlexRay via the current version of the 1.01.0100.00001 FlexRay CCM – PC interface
FlexRay chip (freescale MFR 4300). Upgrading to new chip genera- 1.01.0100.00004 FlexRay CCM – PC interface
tions is carried out with plug-in modules. (with MFR4300 dual chip option)
In addition to two 10 Mbit/s FlexRay interfaces, the interface has 1.01.0100.00006 FlexRay CCM-E – PC Interface
two CAN interfaces (ISO/IS 11898-2 high-speed CAN und ISO/IS 1.01.0100.00005 Dual chip extension for FlexRay CCM
11898-3 low-speed CAN).
To control external hardware components, the interface has four

trigger outputs, which can be controlled via FlexRay messages or
by the FlexRay cycle. In addition, two trigger inputs are available.
The scope of supply of the FlexRay interface includes a driver that

provides functions for configuration as well as receiving and trans-
mitting FlexRay and CAN messages. Own PC applications can be
easily developed on the basis of the driver.
116
Analysis and rest bus simulation
of FlexRay networks
With the analysis of FlexRay networks, requirements are made of FlexRay rest bus simulation
the measuring hardware that are fundamentally different from the
requirements for CAN networks, for example. The rest bus simulation provides a simulation environment for one
Whereas with a CAN analysis system, the use of a communication or more control devices, so that they can be tested independently of
controller is generally sufficient for bus analysis, in the case of Flex- other nodes. This includes the generation of message traffic that is
Ray additional measures must be taken to be able to analyze start- necessary for the device to be tested and reaction to messages. In
up processes and errors. A FlexRay communication controller, for addition, the FlexRay residual bus simulation ensures that at least
example, is not capable of receiving messages during the start-up two FlexRay cold starters are available so that the FlexRay network
phase required for establishing the deterministic communication can be started. With the dual chip extension of the FlexRay CCM,
and passing them on to an analysis system. In addition, not all errors one device can represent two cold starters and thus start a network
relevant for the FlexRay bus analysis can be reported by a FlexRay with FlexRay integration nodes.
communication controller. The generation of the FlexRay message traffic for the rest bus simu-
lation is frequently connected with real-time requirements. This
With its FlexRay/CAN-PC interface "FlexRay CCM", IXXAT pursues means that response data are expected within a specified time, usu-
the approach of the combined FlexRay analysis consisting of asyn- ally within a message cycle, by the control device to be tested and
chronous bit stream analysis and synchronous analysis with the aid the simulation of the Flexray message traffic must be provided in
of a FlexRay communication controller. The FlexRay bit stream is real time. The IXXAT FlexRay CCM supports real-time rest bus simu-
thus scanned by an independent system and the FlexRay commu- lation directly on the hardware via a Linux-based embedded pro-
nication controller is operated at the same time. The results from gramming environment. The code to be processed is dynamically
both sources are compared and results additionally obtained are loaded in kernel mode to the FlexRay CCM and processed. FlexRay
supplied to the analysis software. and CAN messages can be received and processed further and res-
ponse data can be sent in real time. A framework and C-interfaces
are available for this. A GNU compiler with a download tool that
runs on Windows translates and loads the program modules to the
FlexRay CCM, which are stored there on the flash file system. It is
also possible to control the embedded residual bus simulation via
the PC with data transfer, as is stand-alone operation (i.e. operation
of the FlexRay CCMs without a PC). For low real-time requirements
i.e. when response times of 10-20 ms are sufficient, the rest bus
simulation environment via the .net interface of the MultibusAnalyser
is available. Both simulation types can also be operated in parallel.
Timestamp
Timestamp –– Sync
Sync Apart from the rest bus simulation, the embedded programming en-
Comparator
Comparator
vironment of the FlexRay CCMs also offers the possibility to imple-
Msg Controller ment gateways, transport protocols or ECU emulations.
Stati The embedded programming package for the FlexRay CCM consists
Bitstream
Bitstream
Analysis
Analyse
of support of stand-alone operation, embedded frameworks for Flex-
Ray and CAN with the necessary development and download envi-
22 xx CAN
ronment.
CAN
CAN ORDER NUMBER
1.02.0243.00000 FlexRay residual bus simulation

Together with the IXXAT MultibusAnalyser, the FlexRay/CAN-PC
interface FlexRay CCM therefore provides a powerful analysis envi-
ronment for the synchronous analysis of FlexRay and CAN networks.
The FIBEX import provided by the MultibusAnalyser allows an analysis
both at message level and at signal level. FlexRay and CAN networks
can also be stimulated via transmit functions. The open .net inter-
face enables simple implementation of customized function modules,
displays as well as node and rest bus simulations. An additional code
generator also enables access to FlexRay and CAN messages via ap-
plication parameters (signals), which are already generated in the
form of .net assemblies (see MultibusAnalyser).
117
CAN Accessories
Sub-D9 Connector with CAN Termination CAN Termination (Socket)
120 Ohm for High-Speed CAN systems according to ISO/IS 11898-2; 120 Ohm for High-Speed CAN systems according to ISO/IS 11898-2;
SUB-D9 connector; Male to female; Pin assignment 1-to-1; Female; RT between pin 2 and 7
RT between pin 2 and 7
Order number
1.04.0075.03000 Sub-D9 Connector with CAN Termination
Order number
1.04.0075.01000 CAN Termination (Socket)
CAN Termination (Plug)
120 Ohm for High-Speed CAN systems according to ISO/IS 11898-2;
Male; RT between pin 2 and 7 CAN cable
All pins connected; Length 2.0 m; Sub-D9 plug (1 x F / 1 x M); Shield
Order number
1.04.0075.02000 CAN Termination (Plug)
Order number
1.04.0076.00180 CAN cable
118
Y CAN cable Glass fiber cable F-SMA
All pins connected; Length 22 cm; Sub D9 socket to sub D9 Duplex; For FO repeater and star coupler; With 2 plugs on each side;
socket/plug; Shield Wavelength 820 nm; Glas fiber 50/125 um; Attenuation 3 dB/km
Order number
1.04.0003.01012 Glass fiber cable F-SMA (2 meter)
1.04.0003.01015 Glass fiber cable F-SMA (5 meter)
Order number
1.04.0076.00001 Y CAN cable Glass fiber cable ST
Duplex; For FO repeater and star coupler; With 2 plugs on each side;
Nullmodem cable Wavelength 820 nm; Glas fiber 50/125 um; Attenuation 3 dB/km
Serial cable for CAN@net, CANbridge, LIN2CAN and K2CAN;

2 x Sub D9 socket; Length 2.0 m; Shield
Pin assignment
Socket 1 Socket 2 Order number
1 7+8
1.04.0003.01022 Glass fiber cable ST (2 meter)
2 3
3 2 1.04.0003.01025 Glass fiber cable ST (5 meter)
4 6
5 5
6 4
7 1
8 1
9 N.C.
S S
Order number
2.09.0000.00524 Nullmodem cable
Laplink cable
Serial cable for CANlink II and CANcorder; 2 x Sub D9 socket;
Length 3.0 m; Shield
Pin assignment
Socket 1 Socket 2
1 4
2 3
3 2
4 1
5 5
7 8
8 7
9 9
S S
Order number
2.09.0000.00168 Laplink cable
119
FlexRay Accessories
CAN 1:1 cable for FlexRay CCM Trigger cable for FlexRay CCM
Lemo plug (8 pins, type FGC.1B.308) to Sub-D9 plug; 1 meter Lemo plug (8 pins, type FGB.1B.308) to 4 BNC plugs; 2 meter length
length; Cable: Nexans, impedance 100 Ohm; Temp. range: -40 to
+85 ºC
Order number Order number

1.04.0093.00000 CAN 1:1 cable for FlexRay CCM 1.04.0094.00000 Trigger cable for FlexRay CCM
FlexRay 1:1 cable for FlexRay CCM Ethernet cross cable for FlexRay CCM
Cable with integrated 100 Ohm bus termination; Lemo plug (5 (content of delivery of the FlexRay CCM)
pins, type FGB.0B.305) to Sub-D9 socket; 2 meter length; Cable: Lemo plug (8 pins, type FGG.1B.308) to RJ45 plug; 3 meter length
Nexans, impedance 100 Ohm; Temp. range: -40 to +85 ºC Cable: Lappkabel UNITRONIC; Temp. range: flexible -5 to +40 ºC,
permanently mounted -40 to +70 ºC

1.04.0092.00000 FlexRay 1:1 cable for FlexRay CCM 1.04.0090.00000 Ethernet cross cable for FlexRay CCM
FlexRay Y-cable for FlexRay CCM Power cable for FlexRay CCM
Lemo plug (5 pins, type FGB.0B.305) to Sub-D9 socket and Sub- (content of delivery of the FlexRay CCM)
D9 plug; 2 meter length; Cable: Nexans, impedance 100 Ohm; Lemo socket (2 pins, type FGJ.1B.302) to two 4 mm banana plugs;
Temp. range: -40 to +85 ºC 2 meter length; Cable: Lappkabel SILFLEX-SIHF; Temp. range:
-40 to +85 ºC

1.04.0092.00001 FlexRay Y-cable for FlexRay CCM 1.04.0091.00000 Power cable for FlexRay CCM
120
Since 1992, the seminars offered under the guidance of Prof. Dr.- In-House Seminars
Ing. Konrad Etschberger have aimed to provide a foundational
knowledge of the communication technology.
Our lecturers are engineers with special knowledge of their specific In addition to our standard seminars, we also offer in-house semi-
training fields. We make every effort to keep the contents of our nars. The in-house seminars can be held as two-day seminars, with
seminars up to date with the latest developments in technology identical content to the standard seminars, or adapted to the cus-
and to continually improve both content and didactics. tomer's requirements and running for one day or more. In-house
seminars can be held in German or English.
Many of the over 800 companies whose engineers have attended
our seminars have been employing our know-how to train employees
in new communication technologies. TARGET GROUP
If you are interested in one of our seminars or in an in-house Our in-house seminars are of particular interest to customers who
seminar, we will be pleased to provide you our seminar brochure want to train several employees at the same time in a short time.
with detailed information or make you an individual offer. Here the contents can be specially adapted to the needs of different
groups of participants, such as developers, service technicians etc.
The seminar dates can be found in the seminar area of our web-
page www.ixxat.com or in our seminar brochure. The in-house seminars also allow special project-related subjects to
be dealt with. Working in small groups, this is the best way to answer
participants' individual questions.
Standard Seminars
and -Workshops
Currently the following seminars and workshops are offered:
CAN Seminar (2 days)

CANopen Seminar (2 days)
DeviceNet Seminar (2 days)
EtherNet/IP Seminar (2 days)
Powerlink Seminar (2 days)
FlexRay Workshop (1 day)
With the seminars, the participants receive a quick, efficient intro-

duction to the specific topics. The seminars are particularly intended
for developers and system designers who have to make their own
developments based on the specific technologies and want to
acquire foundational knowledge. A detailed description of the
seminar contents can be found in our seminar brochure.
121
Prof. Dr.-Ing. K. Etschberger (Publ.)
Controller Area Network (CAN)
Hanser-Verlag, 2002, ISBN: 3-446-21776-2, 3rd edition
bound, approx. 440 pages
The third updated and extended edition of our CAN-book provides

the basics needed for understanding the CAN-protocol and imple-
menting CAN-networks in a well-founded form, and places special
emphasis on the CAN-based higher protocols such as CANopen,
DeviceNet, SAE J1939 and Time-Triggered CAN.
As an introduction, the important basics for fieldbus-oriented data
communication and the most important fieldbus concepts are des-
cribed. This is followed by an introduction to the CAN data trans-
mission and physical layer.
For developers of CAN-based devices and systems, the different
kinds of CAN-protocol modules and transceivers are presented as
well as the most important components available on the market
today. Finally the book deals with different aspects for implemen-
ting CAN-networks and gives an overview of components for the
implementation of CAN-based automation solutions.
English edition
Prof. Dr.-Ing. K. Etschberger (Publ.)

Controller Area Network
IXXAT Automation, 2001, ISBN: 3-00-007376-0
bound, approx. 440 pages
Articles, basics and further information on industrial and auto-

motive communication topics can be found on our website
www.ixxat.com.
122
Your Partner for Communication
IXXAT GmbH
Headquarter
Products and Services 2007 | 2008

IXXAT Inc.
Distributors
Products and Services
Further information about our distributors
can be found on our website www.ixxat.de for Industry and Automobile
CAN, FlexRay, LIN
CANopen, DeviceNet
SAE J1939
Distributed by
Gestaltung: Andrea Schnitzer, D-Ravensburg
ETHERNET Powerlink
EtherNet/IP
PROFINET
IEEE 1588
2007 | 2008
IXXAT . Leibnizstr. 15 . D-88250 Weingarten IXXAT Inc. . 120 Bedford Center Road . Bedford, NH 03110 IXXAT . Leibnizstr. 15 . D-88250 Weingarten IXXAT Inc. . 120 Bedford Center Road . Bedford, NH 03110
Tel.: +49-(0)751/5 6146 -0 . Fax: +49-(0)751/5 6146 -29 Phone: +1 / 603 / 471- 0800 . Fax: +1 / 603 / 471- 0880 Tel.: +49-(0)751/5 6146 -0 . Fax: +49-(0)751/5 6146 -29 Phone: +1 / 603 / 471- 0800 . Fax: +1 / 603 / 471- 0880
Internet: www.ixxat.de · e-mail: info@ixxat.de Internet: www.ixxat.com · e-mail: sales@ixxat.com Internet: www.ixxat.de · e-mail: info@ixxat.de Internet: www.ixxat.com · e-mail: sales@ixxat.com

IXXAT Cataloge 2007 08

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

IXXAT Cataloge 2007 08

Hochgeladen von

Copyright:

Verfügbare Formate

Your Partner for Communication

Products and Services 2007 | 2008

CAN DIAGNOSTIC TOOLS 49

IEEE 1588 100

SAE J1939 107

IXXAT – SERVICES CANcorder MMC 49

REPEATER ETHERNET POWERLINK

Repeater Introduction 29 ETHERNET Powerlink Introduction 81

IEEE 1588 PTP Introduction 100

PROFINET Introduction 102

NicheStack IPv4 & NicheLite TCP/IP 105

SAE J1939 Introduction 107

LIN Introduction 110

FlexRay Introduction 113

CAN Accessories 118

Standard Seminars and -Workshops 121

Industrial Ethernet Module for ETHERNET

PROFINET Protocol Software

We want to achieve our main objective – establishing long-term

For many years, quality management has been a hallmark of both

45 In our core competence – the development of hardware compo-

For our automotive customers, we have implemented a variety of

Customers using our development services include BMW, Airbus,

TECHNOLOGIES & KNOW-HOW

Basic Software Embedded Devices Test & Service Safety PC Software

Industrial Automotive Wireless Ethernet / Internet

PC Interface Technology Microcontroller FPGA Technology

IXXAT's ISO 9001 certification confirms our successful aspiration to

OVERVIEW PC/CAN INTERFACES

Cardname Technic PC-access Microcontrollersystem CAN Controller Bus interface Certification

For custom applications requiring fully integrated PC/CAN inter- RoHS

CE CERTIFICATION AND CSA APPROVAL

With the VCI, independent cyclic transmission of CAN messages

32 Bit Driver for ODVA

Passive CAN Interfaces

*2) The connection is made by using Bluetooth SPP communication, which

OVERVIEW VCI V3 Application Programming Interface

The VCI is designed as a system server and allows simultaneous

The VCI driver version 3 is available for Windows 2000/XP. Older

FREE CAN MONITOR „MINIMON“

and VxWorks Card Linux VxWorks

FUNCTIONS OF THE CAN DRIVER

Transmission and reception of CAN messages via queues

The delivery specification also includes a simple OPC client which

By using specific hardware interfaces in PC applications (e.g. visua- SYSTEM REQUIREMENTS

OPC-Server software with single-user license

CAN Layer 2 OPC-Server

tinCAN161 USB-to-CAN II iPC-I XC16/PCI

DESCRIPTION OF THE FUNCTIONS

This is a passive CAN board (no microprocessor on board) for the

TECHNICAL DATA PC bus interface PC/104 bus, 8 Bit

ORDER OPTIONS ORDER OPTIONS

Galvanic decoupling Galvanic decoupling

CONTENTS OF DELIVERY CONTENTS OF DELIVERY

PC/CAN interface card, manual PC/CAN interface card and manual

ORDER NUMBER ORDER NUMBER

Intelligent PC/CAN interface for PCI bus systems Galvanic decoupling

PC/CAN interface card and manual

1.01.0039.10100 iPC-I 320/PCI II, 1 x SJA1000 CAN controller,

PC bus interface PCI bus (2.1), 32 Bit, 33 MHz, 5 Volt

PC/CAN interface card and manual

1.01.0043.10100 iPC-I 320/104, 1 x SJA1000 CAN controller,

PC bus interface PC/104 bus, 8 bit

PC/CAN interface card and manual