The European Community developed the CAN Open standard as a publicly funded project and is now an accepted international standard. The standard is controlled by the non-profit trade association “Can In Automation” (CiA). CiA supports the protocol and provides CAN Open technical and marketing information through its web site, trade shows, fairs and exhibitions.
CAN Open is found in applications as simple as coffee makers and as complex as critical medical and transportation systems. It is also strong in industrial applications.
NetBurner CANopen Product Summary:
All NetBurner products that have a CAN port and support the standard NetBurner development software support CANopen. Contact Real Time Automation for CANopen Embedded Gateway and Master and Slave Source File solutions.
CAN Open refers to a CAN frame as a Communications Object (COB). COB’s normally use the eleven bit CAN identifier but also support the 29 bit identifier. A specific identifier in CAN Open is called the COB-Id. The COB-Id defines the Node address and a function code. The COB-Id specifies if the COB is a Process Data Object (PDO) or a Service Data Object (SDO). PDO’s and SDO’s are types of communication objects which transfer application data between nodes.
Using multiple CAN frames SDO’s move more than eight bytes of data. SDO’s are used for high volume, low priority asynchronous messages. SDO are transferred between a client and a server using three types of transmission methods.
- Expedited transfers – used to send small bursts of data
- Segmented Transfers – sends more then four but less then 128 bytes of data
- Block transfers – used to send blocks of data with almost no size restraint
Expedited transfers require no pre-initialization. Although data is limited to four bytes, initialization and data are sent in the same CAN frame. The first half of the CAN Data field (Byte 0 – Byte 3) is used for message information such as where to store the data and how many bytes in the Data field is NOT data. The second half contains the data. All CAN Open nodes must support Expedited Transfers.
Segmented Transfers use a COB almost identical to the Expedited Transfer to initialization the Server node. This first COB prepares the Server node and expects the Server node to reply to the client whether or not the intended dialog can be preformed. The area of the Expedited CAN Data field normally used for data is used to define the number of bytes to be transferred. Following the initialization frame data is transfer in segments (CAN frames) where one byte (Byte 0) is used to state what segment the CAN frame is and the remaining seven bytes are data. The receiver of the data acknowledges each segment of data by sending a reply. Support of Segmented Transfers is optional.
Block Transfers are much like Segmented Transfers in that they both use similar initialization frames and they both send segments of data. Where they differ is Block Transfers send blocks of segmented messages and the receiving node only acknowledges the last segment of each block.
Process data objects are used for small data transfers (eight bytes or less). PDO’s have the advantage of passing higher priority data. Messages can even be synchronous. PDO’s must be predefined at both the Client and Server using a PDO mapping. The PDO mapping defines whether a PDO is consuming or producing data. A PDO that is mapped to an indicator light is a consuming object. A PDO mapped to a switch is a producing object.
Because PDO mapping defines everything about the data, only the COB-Id is used for message data management. The entire eight bytes of the CAN Data frame is used for data.
Contact Real Time Automation for CANopen Embedded Gateway and Master and Slave Source File solutions.