ask question about motor controllers

Technology

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 (See XREF), in order to incorporate simple CAN compatible 3rd party devices in the network.

robocan-network

 

Network Operation

RoboCAN requires only that a controller has a unique node number (other than 0) assigned and that the RoboCAN mode is selected and enabled. All nodes must be configured to operate at the same bit rate. Each enabled node will emit a special heartbeat at a set and unchangeable rate of 128ms so that each node can create and maintain a map of all nodes alive in the network.


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.
@04!G 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.

Remote Maintenance Commands

Remote Maintenance Commands can be sent to an individual node, or broadcasted to all nodes, using the same syntax. For example:
@04%EESAV  will save the configuration to Flash.
Complex maintenance commands such as firmware update or script uploading are not supported.

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:

  1. Send a request to fetch the node data
  2. Wait for data to be received
  3. Read the data

The wait step can be done using one of the 3 following ways

  1. Pause script execution for a few miliseconds using a wait() instruction in line.
  2. Perform other functions and read the results a number of loop cycles later
  3. 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.

 robocan-scanning

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.


Introduction

The Roboteqâ Modbus Implementation User manual contains information about how Roboteq implemented Modbus protocol in controllers.

What is Modbus

Modbus is a serial communication protocol developed by Modicon published by Modiconâ in 1979 for use with its programmable logic controllers (PLCs). In simple terms, it is a method used for transmitting information over serial lines between electronic devices. The device requesting the information is called the Modbus Master and the devices supplying information are Modbus Slaves. In a standard Modbus network, there is one Master and up to 247 Slaves, each with a unique Slave Address from 1 to 247. The Master can also write information to the Slaves.
The official Modbus specification can be found at www.modbus.org/specs.php.

Modbus object types

The following is a table of object types provided by a Modbus slave device to a Modbus master device:


Object type

Access

Size

Coil

Read/Write

1 bit

Discrete Input

Read Only

1 bit

Input Register

Read Only

16 bits

Holding Register

Read/Write

16 bits

Protocol versions

Versions of the Modbus protocol exist for serial port and for Ethernet and other protocols that support the Internet protocol suite. There are many variants of Modbus protocols:

  • Modbus RTU: This is used in serial communication and makes use of a compact, binary representation of the data for protocol communication. The RTU format follows the commands/data with a cyclic redundancy check checksum as an error check mechanism to ensure the reliability of data. Modbus RTU is the most common implementation available for Modbus. A Modbus RTU message must be transmitted continuously without inter-character hesitations. Modbus messages are framed (separated) by idle (silent) periods.
  • Modbus ASCII: This is used in serial communication and makes use of ASCII characters for protocol communication. The ASCII format uses a longitudinal redundancy check checksum. Modbus ASCII messages are framed by leading colon (":") and trailing newline (CR/LF).
  • Modbus TCP/IP or Modbus TCP: This is a Modbus variant used for communications over TCP/IP networks, connecting over port 502. It does not require a checksum calculation, as lower layers already provide checksum protection.
  • Modbus over TCP/IP or Modbus over TCP or Modbus RTU/IP: This is a Modbus variant that differs from Modbus TCP in that a checksum is included in the payload as with Modbus RTU.

Data model and function calls are identical for the previous 4 variants of protocols; only the encapsulation is different.

Communication and devices

Each device intended to communicate using Modbus is given a unique address. On Ethernet, any device can send out a Modbus command, although usually only one master device does so. A Modbus command contains the Modbus address of the device it is intended for (1 to 247). Only the intended device will act on the command, even though other devices might receive it (an exception is specific broadcastable commands sent to node 0, which are acted on but not acknowledged). All Modbus commands contain checksum information, to allow the recipient to detect transmission errors. The basic Modbus commands can instruct an RTU to change the value in one of its registers, control or read an I/O port, and command the device to send back one or more values contained in its registers.
There are many modems and gateways that support Modbus, as it is a very simple protocol and often copied. Some of them were specifically designed for this protocol. Different implementations use wireline, wireless communication, such as in the ISM band, and even Short Message Service (SMS) or General Packet Radio Service (GPRS). One of the more common designs of wireless networks makes use of mesh networking. Typical problems that designers have to overcome include high latency and timing issues.

Frame format

A Modbus frame is composed of an Application Data Unit (ADU), which encloses a Protocol Data Unit (PDU):

  • ADU = Address + PDU + Error check,
  • PDU = Function code + Data.

Note:
The byte order for values in Modbus data frames is big-endian (MSB, most significant byte of a value received first).
All Modbus variants choose one of the following frame formats:

Modbus RTU frame format

Name

Length (bytes)

Description

Address

1

Node address

Function

1

Function code

Data

n

n is the number of data bytes, it depends on function

CRC

2

Cyclic redundancy check (CRC-16-IBM)

Example of frame in hexadecimal: 01 04 02 FF FF B8 80 (CRC-16-ANSI calculation from 01 to FF gives 80B8, which is transmitted least significant byte first).

Modbus ASCII frame format

Name

Length (bytes)

Description

Start

1

Starts with colon : (ASCII hex value is 3A)

Address

2

Node address in hex

Function

2

Function code in hex

Data

n x 2

n is the number of data bytes, it depends on function

LRC

2

Checksum (Longitudinal redundancy check)

End

2

CR/LF

Address, function, data, and LRC are all capital hexadecimal readable pairs of characters representing 8-bit values (0–255). For example, 122 (7 × 16 + 10) will be represented as 7A.

Modbus TCP frame

Name

Length (bytes)

Description

Transaction ID

2

For synchronization between messages of server and client

Protocol ID

2

0 for Modbus/TCP

Length

2

Number of remaining bytes in this frame

Unit ID

1

Node address

Function

1

Function code

Data

n

n is the number of data bytes, it depends on function

Unit identifier is used with Modbus/TCP devices that are composites of several Modbus devices, e.g. on Modbus/TCP to Modbus RTU gateways. In such case, the unit identifier tells the Slave Address of the device behind the gateway. Natively Modbus/TCP-capable devices usually ignore the Unit Identifier.

Function Codes

Modbus protocol defines several function codes for accessing Modbus registers. There are four different data blocks defined by Modbus, and the addresses or register numbers in each of those overlap. Therefore, a complete definition of where to find a piece of data requires both the address (or register number) and function code (or register type).
The function codes most commonly recognized by Modbus devices are indicated in the table below. This is only a subset of the codes available - several of the codes have special applications that most often do not apply.


Function Code

Register Type

1

Read Coil

2

Read Discrete Input

3

Read Holding Registers

4

Read Input Registers

5

Write Single Coil

6

Write Single Holding Register

15

Write Multiple Coils

16

Write Multiple Holding Registers

Roboteq Implementation

Roboteq’s implementation of Modbus doesn’t contain all supported functions and modes but contains only subset of it. I this section we are introducing the supported modes and functions implemented in Roboteq’s micro controllers.

Supported Functions

Controllers only supports two functions:

Read Input Registers (0x04)

This function is implemented to read exactly 4 bytes (2 registers). Issuing any messages to read other than 2 registers will return no response.
For queries that returns values less than 4 bytes, the result will be in the least significant bytes of the returned response.
For example, to read Motor Amps for second channel, you need to read 2 registers from address 0x2002 so you need to send the following RTU message:
01 04 20 02 00 02 DB CB


Name

Description

01

Node address

04

Function code (Read Input Registers)

20 02

Register address for reading motor amps for second channel.

00 02

Length of registers to be read (must be 2)

DB CB

Cyclic redundancy check (CRC-16-IBM)

The response for this message will be as following:
01 04 04 00 00 FF FF FA 34


Name

Description

01

Node address

04

Function code (Read Input Registers)

04

Total bytes read (always 4 bytes)

00 00 FF FF

Value in big Indian notation (MSB first).
As the amps query is 16 bits, so we will take last 16 bits from the given value which is FFFF.
Also the amps query returns signed value, so we should deal with 0xFFFF as signed 16 bits integer which is -1 in decimal.

FA 34

Cyclic redundancy check (CRC-16-IBM)

Write Multiple Holding Registers (0x10)

This function is implemented to write exactly 4 bytes (2 registers). Issuing any messages to write other than 2 registers will have no effect.
For commands that takes values less than 4 bytes, the values for the command will be obtained from the least significant bytes of the message.
For example, to set the motor command on the second channel to value 500 which is 0x1F4, you need to write 2 registers to address 0x0002 so you need to send the following RTU message:
01 10 00 02 00 02 04 00 00 01 F4 72 61


Name

Description

01

Node address

10

Function code (Write Multiple Holding Registers)

00 02

Register address for writing motor command on channel 2.

00 02

Number of registers to write (must be 2)

04

Number of bytes to be written (must be 4)

00 00 01 F4

Value to be written in big Indian notation (MSB first)

72 61

Cyclic redundancy check (CRC-16-IBM)

The response for this message will be as following:
01 10 00 02 00 02 E0 08


Name

Description

01

Node address

10

Function code (Write Multiple Holding Registers)

00 02

Address of written register (motor command on channel 2).

00 02

Number of registers written.

E0 08

Cyclic redundancy check (CRC-16-IBM)

Exception responses

Following a request, there are 4 possible outcomes from the slave:

  • The request is successfully processed by the slave and a valid response is sent.
  • The request is not received by the slave therefore no response is sent.
  • The request is received by the slave with a parity, CRC or LRC error (The slave ignores the request and sends no response).
  • The request is received without an error, but cannot be processed by the slave for another reason.  The slave replies with an exception response.

Here is an example of an exception response:
0A 81 02 B053
0A 81 02 B053


Name

Description

0A

Node address

81

Function code with the highest bit set.

02

The exception code.

B0 53

Cyclic redundancy check (CRC-16-IBM)

The exception codes as explained in the Modbus specification are:


Code

Name

Meaning

0x01

Illegal
Function

The function code received in the query is not an allowable action for the slave.  This may be because the function code is only applicable to newer devices, and was not implemented in the unit selected.  It could also indicate that the slave is in the wrong state to process a request of this type, for example because it is unconfigured and is being asked to return register values. If a Poll Program Complete command was issued, this code indicates that no program function preceded it.

0x02

Illegal Data Address

The data address received in the query is not an allowable address for the slave. More specifically, the combination of reference number and transfer length is invalid. For a controller with 100 registers, a request with offset 96 and length 4 would succeed, a request with offset 96 and length 5 will generate exception 02.

0x03

Illegal Data Value

A value contained in the query data field is not an allowable value for the slave.  This indicates a fault in the structure of remainder of a complex request, such as that the implied length is incorrect. It specifically does NOT mean that a data item submitted for storage in a register has a value outside the expectation of the application program, since the MODBUS protocol is unaware of the significance of any particular value of any particular register.

0x04

Slave Device Failure

An unrecoverable error occurred while the slave was attempting to perform the requested action.

0x05

Acknowledge

Specialized use in conjunction with programming commands.
The slave has accepted the request and is processing it, but a long duration of time will be required to do so.  This response is returned to prevent a timeout error from occurring in the master. The master can next issue a Poll Program Complete message to determine if processing is completed.

0x06

Slave Device Busy

Specialized use in conjunction with programming commands.
The slave is engaged in processing a long-duration program command.  The master should retransmit the message later when the slave is free..

0x07

Negative Acknowledge

The slave cannot perform the program function received in the query. This code is returned for an unsuccessful programming request using function code 13 or 14 decimal. The master should request diagnostic or error information from the slave.

0x08

Memory Parity Error

Specialized use in conjunction with function codes 20 and 21 and reference type 6, to indicate that the extended file area failed to pass a consistency check. 
The slave attempted to read extended memory or record file, but detected a parity error in memory. The master can retry the request, but service may be required on the slave device.

0x0A

Gateway Path Unavailable

Specialized use in conjunction with gateways, indicates that the gateway was unable to allocate an internal communication path from the input port to the output port for processing the request. Usually means the gateway is misconfigured or overloaded.

0x0B

Gateway Target Device Failed to Respond

Specialized use in conjunction with gateways, indicates that no response was obtained from the target device. Usually means that the device is not present on the network.

Supported Modes

Controllers are supporting the following modes:

Modbus RTU over TCP (2)

Simply put, this is a Modbus RTU message transmitted with a TCP/IP wrapper and sent over a network instead of serial lines.
For examples, to read VAR1, you need to read 2 registers from address 0x20C1 so you need to send the following RTU message:
01 04 20 C1 00 02 2B F7


Name

Description

01

Node address

04

Function code (Read Input Registers)

20 C1

Register address for reading VAR1

00 02

Length of registers to be read (must be 2)

2B F7

Cyclic redundancy check (CRC-16-IBM)

The response for this message will be as following:
01 04 04 00 00 12 34 F6 F3


Name

Description

01

Node address

04

Function code (Read Input Registers)

04

Total bytes read (always 4 bytes)

00 00 12 34

Value in big Indian notation (MSB first).

F6 F3

Cyclic redundancy check (CRC-16-IBM)

Modbus TCP (1)

Modbus TCP message is the same as RTU over TCP message by removing CRC and adding MBAP header (Modbus Application Header) is being added to the start of the message. Also, node address moved from into MBAP header and named Unit ID.

The MBAP header is consisting from the following:

Name

Description

Transaction ID

2 bytes set by the Client to uniquely identify each request. These bytes are echoed by the Server since its responses may not be received in the same order as the requests.

Protocol Identifier

2 bytes set by the Client, must be 0x0000.

Length

2 bytes identifying the number of bytes in the message to follow.

Unit Identifier

Node address.

For example, to read VAR1, you need to read 2 registers from address 0x20C1 so you need to send the following TCP message:
00 02 00 00 00 06 01 04 20 C1 00 02


Name

Description

00 02

Transaction ID.

00 00

Protocol Identifier (0x0000 for TCP).

00 06

Number of bytes in the record.

01

Node address

04

Function code (Read Input Registers)

20 C1

Register address for reading VAR1

00 02

Length of registers to be read (must be 2)

The response for this message will be as following:
00 02 00 00 00 0D 01 04 04 00 00 12 34


Name

Description

00 02

Transaction ID.

00 00

Protocol Identifier (0x0000 for TCP).

00 0D

Number of bytes in the record (13 bytes).

01

Node address

04

Function code (Read Input Registers)

04

Total bytes read (always 4 bytes)

00 00 12 34

Value in big Indian notation (MSB first).

Modbus RS232 ASCII

Modbus ASCII marks the start of each message with a colon character ":" (hex 3A). The end of each message is terminated with the carriage return and line feed characters (hex 0D and 0A).
In Modbus ASCII, each data byte is split into the two bytes representing the two ASCII characters in the Hexadecimal value.
Modbus ASCII is terminated with an error checking byte called an LRC or Longitudinal Redundancy Check (See appendix B).
For examples, to read VAR1, you need to read 2 registers from address 0x20C1 so you need to send the following ASCII message:
:010420C10002AE<CRLF>


Name

Description

':'

Start of message - 0x3A

'0' '1'

Node address – 0x01

'0' '4'

Function code (Read Input Registers) – 0x04

'2' '0' 'C' '1'

Register address for reading VAR1 – 0x20C1

'0' '0' '0' '2'

Length of registers to be read (must be 2) – 0x0002

'A' 'E'

LRC

<CRLF>

End of message, carriage return and line feed – 0x0D0A

The response for this message will be as following:
:01040400001234DE<CRLF>


Name

Description

':'

Start of message - 0x3A

'0' '1'

Node address – 0x01

'0' '4'

Function code (Read Input Registers) – 0x04

'0' '4'

Read data length (4 bytes) – 0x04

'0' '0' '0' '0' '1' '2' '3' '4'

Value read from VAR1 – 0x00001234

'D' 'E'

LRC

<CRLF>

End of message, carriage return and line feed – 0x0D0A

Register Address Calculation

With the help of Command Mapping table and Query Mapping table, you can calculate the register address by getting the Modbus ID value from the table then add to it the desired command/query index.
For example, the read user integer variable Modbus ID is 0x20C0, to get the first variable:

  • ModbusID = 0x20C0.
  • Add the index                                    à 0x20C0 + 0x01 = 0x20C1
  • Use 0x20C1 as the address.

Command Mapping

Command

ModbusID

AC

0x00C0

AO

0x0320

ASW

0x03C0

AX

0x0240

B

0x02A0

C

0x0060

CB

0x0080

CG

0x0000

CSW

0x0380

D0

0x0140

D1

0x0120

DC

0x00E0

DS

0x0100

DX

0x0260

EES

0x02E0

EX

0x0180

G

0x0000

H

0x0160

MG

0x01A0

MS

0x01C0

P

0x0020

PR

0x01E0

PRX

0x0220

PSW

0x03A0

PX

0x0200

R

0x0300

RC

0x02C0

S

0x0040

SX

0x0280

TV

0x0360

TX

0x0340

VAR

0x00A0

Query Mapping

Query

ModbusID

A

0x2000

AI

0x8020

AIC

0x8040

ANG

0x2640

B

0x22A0

BA

0x2180

BCR

0x2120

BS

0x2140

BSR

0x2160

C

0x2080

CB

0x20A0

CIA

0x22E0

CIP

0x2300

CIS

0x22C0

CR

0x2100

D

0x21C0

DI

0x8000

DO

0x2260

DR

0x2360

E

0x2280

EO

0x24E0

F

0x2200

FC

0x26A0

FF

0x2240

FIN

0x26E0

FM

0x2440

FS

0x2220

GY

0x2620

HS

0x2460

ICL

0x2680

K

0x2340

LK

0x2480

M

0x2020

MA

0x2380

MGD

0x23A0

MGM

0x23E0

MGS

0x2400

MGT

0x23C0

MGY

0x2420

ML

0x2560

MRS

0x25A0

MZ

0x25C0

P

0x2040

PI

0x8060

PIC

0x8080

PK

0x25E0

QO

0x24C0

RF

0x2600

RMA

0x2500

RMG

0x2520

RMM

0x2540

S

0x2060

SCC

0x2660

SL

0x26C0

SR

0x20E0

T

0x21E0

TM

0x2320

TR

0x24A0

TS

0x2580

V

0x21A0

VAR

0x20C0

Controller Configuration

To configure controller to use Modbus, you will find new configuration section called Modbus under control board:

From the configuration you could set Modbus mode to (Off, TCP, RTU over TCP, or RS232 ASCII). You will be also able to set the Modbus Save ID.

You can use terminal to issue commands for changing mode and slave ID:


Command

Description

^DMOD 0

Set mode Off.

^DMOD 1

Set mode TCP.

^DMOD 2

Set mode RTU over TCP.

^DMOD 3

Set mode RS232 ASCII.

^MNOD 5

Set slave ID to 5.

~DMOD

Query mode.

~MNOD

Query slave ID.

technology

All Roboteq controllers are high performance, microcontroller-based motor controllers, loaded with numerous features and operating modes. Yet, for all their sophistication, the controllers are very simple to install and operate. Their many configuration options are programmed using PC utility with a convenient Graphical User Interface. Once programmed, the configuration data are stored permanently in the controllers' nonvolatile memory, eliminating the need for cumbersome and unreliable jumpers.

Read more: Technology & Innovation

Roboteq controllers can be interfaced in a uniquely flexible number of ways. Each of these command interface modes can be assigned a different priority. A switching mechanism will enable one command mode upon the loss of another. For example the loss of serial commands will automatically enable the analog joystick to allow manual override.

Read more: Data Connectivity

MicroBasic Language Reference

Download sample scripts

Download Notepad++ Microbasic dictionary

Do More with Scripting

One of Roboteq's controller’s most powerful and innovative features is the ability for the user to write programs that are permanently saved into, and run from the controller’s Flash Memory. This capability is the equivalent of combining the motor controller functionality and this of a PLC or Single Board Computer directly into the controller.

Read more: MicroBasic Overview

Motor Controller Finder

Motor Type

Max Voltage

Number of Channels

Max Amps per Channel

USB

CANbus

MicroBasic Scripting

Cooling

Total products: 80
Results: Show
Go to top