CANbus connectivity is now available on selected controller models. Roboteq supports three implementations: two using simplified protocols, plus a CANopen standard compliant version.
CAN Networking Now on Selected Motor Controllers
Controller Area Network, or CAN bus connectivity is now available on selected controller models. Roboteq supports three implementations: two using simplified protocols, plus a CANopen standard compliant version.
Thanks to their CAN interface, up to 127 controllers can work together on a single twisted pair network at speeds up to 1Mbit/s. Connection to a CAN bus is as simple as shown on the diagram below. Termination Resistors must be inserted at both ends of the bus cable. The standard supports several bit rates, allowing a network to stretch up to 1000m, or longer using repeaters, on a simple and low cost twisted pair cable. CAN is a mature and very robust networking standard that is very popular in industrial and automotive applications. CAN packets are essentially composed by a header and a data payload. The header is an 11 bit number that identifies the sender's address (bits 0 to 6) and a packet type (bits 7 to 10). Data payload can be 0 to 8 bytes long. A detailed description of CAN can be found on Wikipedia.
Supported CAN Modes
Three CAN operating modes are available on the CAN-enabled Roboteq controllers:
1 - RawCAN
RawCAN is a low-level operating mode giving read and write access to raw CAN frames. It is recommended for use in low data rate systems that do not obey to any specific standard. CAN frames are built and decoded using the MicroBasic scripting language.
When a packet arrives, the header, byte count, and data are stored in 10 variables that can be read using a specific query from a MicroBasic script. Reading a byte count different than 0 indicates the arrival of a new frame. The controller can be configured to capture all valid frames on a network, or to filter and capture only those frame with a specific NodeID.
Transmit RawCAN Frames simply requires that a frame content be loaded using a specific Microbasic function. This function can be used to enter the header, bytecount, and data, one element at a time. The frame is sent immediately after the bytecount is entered.
Complete details on the RawCAN operation can be found in the CAN section of the Roboteq controller's User’s Manual.
MiniCAN is greatly simplified subset of CANopen, allowing, within limits, the integration of the controller into an existing CANopen network. This mode also requires MicroBasic scripting to prepare and use the CAN data.
MiniCAN is greatly simplified subset of CANopen. It only supports Heartbeat, and fixed map Received Process Data Objects (RPDOs) and Transmit Process Data Objects (TPDOs). It does not support Service Data Objects (SDOs), Network Management (NMT), SYNC or other objects.
In MiniCAN mode, data to be transmitted is simply placed in one of the controller's available Integer or Boolean User Variables. Variables can be written from MicroBasic scripts and the value of these variables is then sent at a periodic rate inside four standard CANopen TPDO frames (TPDO1 to TPDO4). Each of the four TPDOs is sent in turn at the time period defined in the controller's SendRate configuration parameter.
Likewise, incoming frames headers are compared to the Listen Node ID number. If matched, and if the other 4 bits of the header identify the frame as a CANopen standard RPDO1 to RPDO4, then the data is parsed and stored in Integer or Boolean Variables. A MicroBasic script can then be used to fetch the data from these variables and assign them to an action.
Details of which variable is sent in each TPDO, and received in each RPDO frame can be found in the CAN section of the Roboteq User’s Manual.
TPDOs and RPDOs are standard CAN frames identified by their 11-bit header as follows:
TPDO1: 0x180 + NodeID
Complete details on the MiniCAN operation can be found in the CAN section of the Roboteq controller's User’s Manual.
CANopen is the full Standard from CAN in Automation (CIA), based on the DS302 specification. It is the mode to use if full compliance with the CANopen standard is a primary requisite.
The benefits of CANopen include:
Practically all of the controller’s configuration settings, real-time queries and real-time commands that can be accessed via Serial/USB communication can also be accessed via CANopen. All of the controller's supported commands are mapped in a table, or Object Dictionary that is compliant with the CANopen specification. The controller operating in the CANopen mode can accept the following types of messages:
Service Data Object (SDO) Read/Write messages provide generic access to Object Dictionary. They can be used for obtaining or writing parameter values on an irregular basis due to the excessive network traffic that is generated with each SDO request and response message.
Transmit Process Data Object (TPDO) messages are runtime operating parameters that are sent automatically on a periodic basis or upon a trigger event from the controller to one or multiple nodes. TPDOs do not alter object data; they only read internal operating values and transmit data to the CAN bus. TPDOs are identified on a CANopen network by the bit pattern in the 11-bit header of the CAN frame. The most common operating parameters such as Amps, Speed, and Counter values are mapped in the four available TPDO frames.
Receive Process Data Object (RPDO) messages are configured to capture runtime commands destined to the controller. RPDOs alter the controller operation immediately upon receipt. These include the most common commands, such as go to speed or go to position, or output activation.
Complete details on the CANopen operation and Object Dictionary can be found in the CANopen Interface section of the Roboteq controller's User’s Manual.