CAN Newsletter December 2003
| Semiconductor | The CANopen Safety Chip 16-bit and 32-bit micro-controller CAN transceiver 8-bit DeviceNet micro-controller |
|---|---|
| Specification | Real-time performance of CAN and TTCAN Improving the data rate in CAN Clock synchronization in CAN networks |
| Application | Aeroengine line uses CANaerospace Robotic safety via SafetyBus p Fault-management scheme for CAN-based controller |
| Device | CAN in climate control CANopen multi-turn encoders DeviceNet encoder Diagnostic tool set Crash test DAQ CANopen efficiency I/O modules and HMI Decentralized control based on CANopen CANopen/DeviceNet IPC OEM controllers SBCs HMIs DeviceNet drive Servo amplifier CNC controller CANopen actuator Drive and logger CANopen frequency converters PCI interface Connecting serial devices to CANopen Programmable interface CAN/RS-232 interface CAN piggyback DeviceNet interface adapter I/O modules Gateway DeviceNet soft starter Servo press CANopen ident system |
| Software | CAN AWD system Data logger Software tool CAN APIs Linux driver Windows driver CAN IP cores CANopen for RT QNX and RT Linux |
| Tool | Configuration of CANopen devices Controlling and monitoring CAN via web interface |
The CANopen Safety Chip
The use of bus systems in safety-relevant systems is steadily increasing. The IEC 61508 international standard defines measures and methods for developing and evaluating processor-based safety systems, thus establishing an internationally recognized basis for modern control systems in the safety technology field. The CSC (CANopen Safety Chip), which was commissioned by the CSC Consortium under the leadership of CAN in Automation (CiA) and implemented by Sys Tec electronic, provides manufacturers of safety-relevant devices with a certified chip. It enables the development of safety-relevant sensors and actuators, which are networked over a standardized network, with considerable savings in development time and cost. The CSC can be integrated as a partially pre-programmed chip in various safety-relevant devices. Such systems could include safety sensors (e.g. emergency stop button, safety light curtains, safety mat, two-hand controls etc.) and actuators (safety relay, drives etc.). The CiA DSP 304 "CANopen Framework for Safety-relevant Communication", which defines the CANopen protocol expansions for the integration of safety-relevant devices in CANopen networks, is used as a network protocol. The protocol enables safety-relevant devices to operate along with non-safety-relevant devices in a CANopen network. The safety functions are realized via special communication objects, SRDOs (Safety-Relevant Data Object)...
headquarters(at)can-cia.org
Would you like to read more? Please subscribe to the CAN Newsletter. It's free!
Tool-based configuration of CANopen devices
There is more than one way to configure CANopen devices or networks. The first method is based on a CANopen master library that uses client SDOs (Service Data Objects) to write down a specific configuration to each of the devices in a CANopen network. Depending on the CANopen knowledge of the system integrator they can access all CANopen options in this way. However, as CANopen gets more and more popular, the demand for easier means to configure a network rises. Graphical interfaces and additional tools help the user to work with CANopen at a higher level of abstraction. With the help of configuration tools, configuration becomes more comfortable. They also minimize the risk of mistakes and keep the configuration of a system consistent. Even system integrators with little CANopen knowledge welcome this way of dealing with network aspects.
There are several ways to configure a network based on this trend for configuration tools: One method is using the CANopen capability of the configuration manager, which is specified in CiA DSP 302. In this case a database is used inside the NMT (Network Management) master module that contains the configuration for any device inside the network. The content of this database is transferred to the specific CANopen modules by means of client SDOs. As a result the system integrator is just responsible for the definition of the configuration. The configuration manager provides all the other mechanisms such as parameter download and verification of the device's configuration. Another method of configuring a network is based on a tool, which is directly connected to the CANopen master device. Such tools are available as stand-alone software, just to do the configuration, or combined, for example, with an IEC 61131-3 programming environment. A combined tool allows programming the main controller as well as configuring single devices. The exchange of variable names between the configuration module of the tool and the programming module is quite easy as both modules are based on the same software. Stand-alone configuration tool do not require programmable devices inside the network. All configuration is done by accessing Object Dictionary entries and assigning suitable values to each parameter. All configured devices require the capability to store their configuration if no configuration manager is available....
headquarters(at)can-cia.org
Would you like to read more? Please subscribe to the CAN Newsletter. It's free!
