Menu

CAN networking roboteq motor controllersCANbus connectivity is now available on selected controller models. Roboteq supports three implementations: two using simplified protocols, plus a CANopen standard compliant version.

Controller Area Network, or CAN bus connectivity is available on a growing number 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.

CAN connectivity

 

Supported CAN Modes

Three CAN operating modes are available on the CAN-enabled Roboteq controllers:

1 - RawCAN
2 - MiniCAN
3 - CANopen

 

Raw CAN

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 pdf NextGen Controllers User Manual (6.18 MB) .

 

MiniCAN

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 pdf NextGen Controllers User Manual (6.18 MB) .

TPDOs and RPDOs are standard CAN frames identified by their 11-bit header as follows:

TPDO1: 0x180 + NodeID
TPDO2: 0x280 + NodeID
TPDO3: 0x380 + NodeID
TPDO4: 0x480 + NodeID

RPDO1: 0x200 + NodeID
RPDO2: 0x300 + NodeID
RPDO3: 0x400 + NodeID
RPDO4: 0x500 + NodeID

For example, the following simple script uses VAR1 that is transported in RPDO1 as the incoming motor command and stores the value of the Motor Amp into VAR9 so that it is sent in TPDO1. Note that this script does not check for loss of communication on the CAN bus. It is provided for information only.

top:
speed = getvalue(_VAR, 1) ' Read  first 32bit integer carried in RPDO1
setcommand(_G, 1, speed) ' Use it to command speed of motor 1
motor_amp = getvalue(_A, 1) ' Fetch motor 1 Amps in controller
setcommand(_VAR, 9, motor_amps) ' Place is first 32bit integer in TPDO1 frame
wait(10)
goto top: ' Loop forever every 10ms

Complete details on the MiniCAN operation can be found in the CAN section of the Roboteq controller's pdf NextGen Controllers User Manual (6.18 MB) .

CANopen

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:

  • Standardized in EN50325-4
  • Widely supported and vendor independent
  • Highly extensible
  • Offers flexible structure (can be used in a wide variety of application areas)
  • Suitable for decentralized architectures
  • Wide support of CANopen monitoring tools and solutions

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 Objects, or SDO messages to read/write parameter values
  • Process Data Objects, or PDO mapped messages to automatically transmit parameters and/or accept commands at runtime
  • Network Management, or NMT as defined in the CANopen specification

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 Interfacesection of the Roboteq controller's pdf NextGen Controllers User Manual (6.18 MB) .

Go to top