RoboCAN is a Roboteq proprietary meshed networking scheme allowing multiple Roboteq motor controllers to operate together as a single system. This protocol is extremely simple and lean, yet practically limitless in its abilities. It is the preferred protocol to use by user who just wish to make multiple controllers work together with the minimal effort.
In RoboCAN, every controller can send commands to, and can read operational data from, any other node on the network. One or more controller can act as a USB to CAN or Serial to CAN gateway, allowing several controllers to be thus managed from a single PC or microcomputer.
Using a small set of dedicated Microbasic function, scripts can be written to exchange data between controllers in order to create automation systems without the need for a PLC or external computer.
In addition, RoboCAN includes support for processing raw can data as defined in the RawCAN specification, in order to incorporate CAN compatible 3rd party devices in the network.

Network Operation
The simplified model of a motor is a resistor in series with an inductor and a voltage generator. The resistor and inductor are simply the resistance and inductance of the electromagnets inside the motor. The voltage generator represents the voltage that is created by the motor while it is turning and isreferred as Back EMF, or BEMF. The BEMF voltage is a fixed ratio of Volts per RPM.
RoboCAN via Serial & USB
Important notice: On many controller models, CAN and USB cannot be operated at the same time. Please see product datasheet to verify if this is the case on the model used. In case USB is not available, this section only applies to RS232 connections.
RoboCAN commands and queries can be sent from a USB or serial port using a modified syntax of the normal serial protocol: By simply adding the @ character followed by the node as a 2 digint hex address, a command or query is sent to the desired node. This scheme works with every Command (! Character), Query (?), Configuration setting (^), Configuration read (~), and most Maintenance commands (%)
Runtime Commands
Below is an Command example:
!G 1 500
This is the normal command for giving a 50% power level command to motor 1 of the controller that is attached to the computer.
@04G 1 500
This will send the same 50% command to motor 1 of the controller at node address 4.
The reply to a local command is normally a + or - sign when a command is acknowledged or rejected in normal serial mode.
When a command is sent to a remote node, the reply is also a + or – sign. However, in addition, the reply can be a * sign to indicate that the destination node does not exist or is not alive. Note that the + sign only indicates that the command syntax is valid and that the destination node is alive.
Broadcast Command
Node address 00 is used to broadcast a command simultaneously to all the nodes in the network. For example
@00!G 1 500
Will apply 50% power to all motor 1 at all nodes, including the local node
Realtime Queries
Queries are handled the same way but the reply to a query includes the responding node’s address. Below is a Query example:
?V 2
This is the normal query for reading the battery voltage of the local controller. The controller will reply V=123
@04?V 2
This will send the same query to node address 4
The reply of the remote node is @04 V=123
Replies to remote nodes queries are identical to these to a local controller with the exception of an added latency. Since the reply must be retrieved from the remote node depending on the selected bit rate, the reply may come up to 10ms after the query was sent.
Remote Queries restrictions
Remote queries can only return a single value whereas local queries can be used to read an array of values. For example
?AI
Is a local query that will return the values of all analog capture channels in a single string as
AI=123:234:345:567
@04?AI
Is a remote query and it will return only the first analog capture channel as
@04 AI=123
Remote queries are not being added in the Query history.
Broadcasted remote queries are not supported. For example @00?V 1 will not be executed.
Queries that return strings, such as ?FID or ?TRN are not supported. They will return the value 0
See the Roboteq User Manual for the complete list and description of available queries
Configurations Read/Writes
Configuration settings, like Amp Limit or Operating Modes can be read and changed on a remote node via the CAN bus. For example
@04^ALIM 1 250 will set the current limit of channel 1 of node 4 at 25.0A
@04~OVL will read the Overvoltage limit of node 4.
Note that changing a configuration via CAN only makes that change temporary until the remote controller is powered down. The %EESAV maintenance command must be send to the remote node to make the configuration change permanent.
A configuration write can be broadcast to all nodes simultaneously by using the node Id 00. For example
@00^OVL 250
Will set the overvoltage limit of all nodes at 25.0 Volts
Configuration reads cannot be broadcasted.
See Roboteq User Manual for the complete list and description of available configuration
Remote Configurations Read restrictions
Remote Configuraion Reads can only return a single value whereas local Configuration Reads can be used to read an array of paramers. For example
~AMOD
Will return the operating mode of all analog capture channels in a single string as
AI=01:01:00:01:02
@04~AMOD
Will return only the mode first analog capture channel as
@04 AI=01
Configuration reads cannot be broadcasted.
Self Addressed Commands and Queries
For sake of consistency commands sent to the local node number are executed the same way as they would be on a remote node. However the no CAN frame is sent to the network. For example if node 04 receive the command
@04!G 1 500
No data will be sent on the network and it will be interpreted and executed the same way as
!G 1 500
RoboCAN via MicroBasic Scripting
A set of functions have been added to the MicroBasic language in order to easily send commands to, and read data from any other node on the network. Functions are also available to read and write configurations at a remote node. Maintenance commands are not supported.
Sending Commands and Configuration
Sending commands or configuration values is done using the functions
SetCANCommand(id, cc, ch, vv)SetCANConfig(id, cc, ch, vv)
Where:
id is the remote Node Id in decimal
cc is the Command code, eg _G
cc is the channel number. Put 1 for commands that do not normally require a channel number
vv is the value
Example:
SetCANCommand(04, _G, 1, 500)
Will apply 50% powe to motor 1 of node 4
SetCANConfig(0, _OVL, 1, 250)
Will set the overvoltage limit of all nodes to 25.0V. Note that even though the Overvoltage is set for the controller and does not normally require that a Channel, the value 1 must be put in order for the instruction to compile.
Script execution is not paused when one of these function is used. The frame is sent on the CAN network within one millisecond of the function call.
Reading Operating values Configurations
When reading an operating value such as Current Counter or Amps, or a configurations such as Overvoltage Limit from another node, since the data must be fetched from the network, and in order to avoid forcing a pausin the script execution, data is accessed in the following manner:
- Send a request to fetch the node data
- Wait for data to be received
- Read the data
The wait step can be done using one of the 3 following ways
- Pause script execution for a few miliseconds using a wait() instruction in line.
- Perform other functions and read the results a number of loop cycles later
- Monitor a data ready flag
The following functions are available in microbasic for requesting operating values and configurations from a remote node.
FetchCANValue(id, cc, ch)
FetchCANConfig(id, cc, ch)
Where:
id is the remote Node Id in decimal
cc is the Command code, eg _G
cc is the channel number. Put 1 for commands that do not normally require a channel number
The following functions can be used to wait for the data to be ready for reading:
IsCANValueReady()
IsCANConfigReady()
These functions return a Boolean true/false value. They take no argument and apply to the last issued FetchCANValue or FetchCANConfig function
The retrived value can then be read using the following functions:
ReadCANValue()
ReadCANConfig()
These functions return an integer value. They take no argument and apply to the last issued FetchCANValue or FetchCANConfig function
Below is a sample script that continuously reads and print the counter value of node 4
top: FetchCANValue(4, _C, 1) ' request data from remote node while(IsCANValueReady() = false) ' wait until data is received end while Counter = ReadCANValue() ' read value print (Counter, "\r") ' print value followed by new line goto top ' repeat forever
Continuous Scan
In many applications, it is necessary to monitor the value of an operating parameter on a remote node. A typical example would be reading continuously the value of a counter. In order to improve efficiency and reduce overhead, a technique is implemented to automatically scan a desired parameter from a given node, and make the value available for reading without the need to send a Fetch command.
A function is provided to initiate the automatic sending of a value from the remote node, at a specific periodic rate, and to be stored to user selected location in a receive buffer.
The remote node will then send the data continuously without further commands.
A function is then provided to detect the arrival of a new value in that buffer location, and another to read the value from that location.
Since the scan rate is known, the execution of the script can be timed so that it is not necessary to check the arrival of a new value.

A scan is initiated with the function:
ScanCANValue(id, cc, ch, tt, bb)
Where:
id is the remote Node Id in decimal
cc is the Query code, eg _V
ch is the channel number. Put 1 for queries that do not normally require a channel number
tt is the scan rate in ms
bb is the buffer location
The scan rate can be up to 255ms. Setting a scan rate of 0 stops the automatic sending from this node.
Unless otherwise specified, the buffer can store up to 32 values.
The arrival of a new value is checked with the function
IsScannedCANReady(aa)
Where
aa is the location in the scan buffer.
The function returns a Boolean true/false value
The new value is then read with the function
ReadScannedCANValue(aa)
Where
aa is the location in the scan buffer.
The function returns an integer value. If no new value was received since the previous read, the old value will be read.
The following example shows the use of the Scan functions
' initiate scan of counter every 10ms from node 4 and store to buffer location 0 ScanCANValue(4, _C, 1, 10, 0) ' initiate scan of voltage every 100ms from node 4 and store to buffer location 1 ScanCANValue(5, _V, 1, 100, 1) top: wait(10) ' Executer loop every 10 ms ' check if scanned volts arrived if(IsScannedCANReady(1)) ' read and print volts Volts = ReadScannedCANValue(1) print (Volts,"\r") end if ' No need to check if counter is ready since scan rate = loop cycle Counter = ReadScannedCANValue(1) print (Counter,"\r") goto top ' Loop continuously
Checking the presence of a Node
No error is reported in MicroBasic if an exchange is initiated with a node that does not exist. A command or configuration sent to a non-existent node will simply not be executed. A query sent to a non existing or dead node will return the value 0. A function is therefore provided for verifying the presence of a live node. A live node is one that sends the distinct RoboCAN heartbeat frame every 128ms. The function syntax is:
IsCANNodeAlive(id)
Where:
id is the remote Node Id in decimal
The function returns a Boolean true/false value.
Self Addressed Commands and Queries
Functions addressed to the local node have no effect. The following function will not work if executed on node 4
SetCANCommand(04, _G, 1, 500)
The regular function must be used instead
SetCommand(_G, 1, 500)
Broadcast Command
Node address 00 is used to broadcast a command, or a configuration write simultaneously to all the nodes in the network.
The local node, however, will not be reached by the broadcasted command.