Besides the standard services, extensions for additional communication profiles such as redundant communication (CiA 302), safety relevant communication (CiA 304) as well as device profile implementations like Generic I/O Modules (CiA 401) are available.
A flexible user interface provides functions to evaluate the received data and to use the CANopen services in the network.
To connect the CANopen Slave Stack to multiple CAN controllers and CPU types, a well-defined driver interface is used. Using this driver interface the CANopen stack can also easily be adapted to new CAN controllers or CPU types. Also it is possible to substitute hardware platforms with only little effort. The CANopen Slave Stack can be used with various Realtime Operating Systems such as ThreadX, FreeRTOS, Keil RTX oder TI-RTOS ,and as well with Linux (SocketCAN, can4linux) or QNX and also with Real time extensions for Windows.
Besides the function API there is also an Mailbox API available for an easy use with multiple tasks resp. threads. Messages between application modules and CANopen stack are send via mailboxes instead of function calls. This secures a non-blocking communication. An application may consist of several tasks that use the CANopen Stack in parallel.
To save resources the CANopen Slave Stack is widely configurable and scalable. The settings for these features are supported by the graphical configuration tool, CANopen DeviceDesigner, which also allows the creation of the object directory and EDS file using a built-in database. As a consequence, changes can be realized fast and easy. Using the unique CANopen DeviceDesigner valuable development time is saved.
Many ready-to-run examples are provided to make the start with the CANopen stack as easy as possible. Additionally a user manual, which describes principles and use cases and a reference manual, which describes each API function in detail belongs to the scope of delivery. The stack is constantly tested with the CANopen Conformance Test for compliance with the specification.
System requirementsANSI-C compiler
Scope of delivery/Licensing model• CANopen protocol sourcecode (ANSI-C compatible)
• Ready to run example application
• User manual and reference manual
• Site license
• Incl. 6 months support ba e-mail or telephone
• Optional maintenance agreement available
• Optional integration support
• 1 license of CANopen DeviceDesigner included
Services Basic Slave Master/Slave Manager SDO Server 2 128 128 SDO Client 128 128 SDO expedited/ segmented/block ●/●/- ●/●/○ ●/●/○ PDO Producer 32 512 512 PDO Consumer 32 512 512 PDO Mapping static static/dynamic static/dynamic MPDO Dest Mode ○ ○ MPDO Src. Mode ○ ○ SYNC Producer ● ● SYNC Consumer ● ● ● Time Producer ● ● Time Consumer ● ● Emergency Producer ● ● ● Emergency Consumer 127 127 Guarding Master ● Guarding Slave ● ● ● Bootup Handling ● ● Heartbeat Producer ● ● ● Heartbeat Consumer 127 127 NMT Master function ● ● NMT Slave ● ● ● LED CiA-303 ● ● ● LSS CiA-305 ● ● ● SDO Requester (SRD) CiA-302-5 ○ ○ CANopen Router CiA-302-7 ○ ○ Master Bootup CiA 302 ● Configuration Manager ● Flying Master ○ ○ Redundancy ○ ○ Safety ○ ○ ○ Multiline ○ ○ C#-API-Wrapper for Windows ○ ○ ○ Delphi-API-Wrapper for Windows ○ ○ ○
CANopen Profiles CiA 401 (U8/INT16) ○ ○ ○ CiA 402 ○ ○ ○ CiA 404 ○ ○ ○ CiA 406 ○ ○ ○ CiA 413 ○ ○ ○ CiA 418 ○ ○ ○ CiA 419 ○ ○ ○ CiA 437 ○ ○ ○ CiA 443 ○ ○ ○ CiA 447 ○ ○ ○ CiA 454 ○ ○ ○
● – included
○ – optionally available
- Caratteristiche e Benefici
CANopen Profile SupportCANopen defines a large number of device or application profiles that specify the interface and behavior of certain devices. We offer extensions to support the functionalities of these profiles and to provide the data and events to the application in a preprocessed way. Currently extensions for the following profiles are available:
• CiA 401 – device profile for IO modules
• CiA 402 – device profile for drives
• CiA 404 – device profile for measurement devices and closed-loop controllers
• CiA 406 – device profile for encoder
• CiA 413 – interface profile for truck gateways
• CiA 418 – device profile for batteries
• CiA 419 – device profile for chargers
• CiA 437 – application profile for grid-based photovoltaic components
• CiA 443 – Device profile for sub sea instruments (SIIS Level-2)
• CiA 447 – application profile for add-on devices for passenger cars (taxi, police, …)
• CiA 454 – application profile for Energy Management Systems e.g. in LEVs (EnergyBus)
• Additionally, the CANopen Slave Stack can be used to develop any CANopen application even for other profiles as mentioned before.
Highlights• ANSI-C compatible CANopen source code stack
• Supports all CANopen services of CiA 301
• Layer Setting Service (LSS) CiA305 included
• Extensions for further standards available
• Available for many CAN controller and CPU types
• Comfortable user interface
• Widely configurable and scalable
The following chip manufacturers and their families are supported at the moment by the emtas CANopen and J1939 stacks:
AMD x86 Architecture ATMEL ATmega64C, AT90CAN64, AT90CAN128, SAM C21 BOSCH C_CAN, M_CAN Freescale (NXP) Kinetis, msCAN12 (e.g. HCS08, HCS12), i.MX, MPC560x Cypress (Spansion/Fujitsu) FM3 (ARM Cortex-M3) Infineon XMC4000 (ARM Cortex-M4, MultiCAN), XMC1400 (Cortex-M0), XE166 Intel x86 Architecture Microchip dsPIC33, PIC24H, PIC32 NXP LPC17xx, LPC40xx, LPC546xx NuvoTon NUC130, NUC140 Renesas R-IN32M3, RX62, V850E2, RH850/F1L, Synergy S1,S3,S5,S7 ST Microelectronics STM32 (ARM Cortex-M0, Cortex-M3, Cortex-M4, Cortex-M7, bxCAN, M_CAN) Texas Instruments TMS320, C2000 (DSP), ARM, Stellaris LM4F, TMS570 (Hercules), Tiva TM4C129 LINUX systems can4linux, SocketCAN, ECI
The table only lists the families. All providers offer within each family a large number of “family members”
that differ in periphery, maximum clock rate or size of housing. In consequence the number of pins and pin
assignment also differ.
The CANopen stack can be used with the following compilers or IDEs:• gcc
• Atmel Studio
• Atollic True Studio
• Mikro C
- Numeri ordine
on request - Emtas CANopen Slave Stack