Controller modes determine in what way and how much power flows from the motor to the wheels. Roboteq offers various options for both motion and command modes.  

Multiple Motion Modes

For each channel, the Roboteq controllers supports multiple motion control modes:

Open Loop Speed mode

In this mode, the controller delivers an amount of power proportional to the command information. The actual motor speed is not measured.


Closed Loop Speed modes

Closed Loop Speed - For a Closed Loop Speed mode, an optical encoder or analog tachometer is used to measure the actual motor speed. In brushless motor controllers, the motor's hall sensor can be used to measure speed. If the speed changes because of changes in load, the controller automatically compensates the power output. This mode is preferred in precision motor control.

Closed Loop Speed Position - This mode is unique in that the controller computes the position at which the motor must be at every 1ms. Then a PID compares that expected position with the current position and applies the necessary power level in order for the motor to reach that position. This mode is especially effective for accurate control at very slow speeds.


mode position 
Closed Loop Position modes

In this mode, the motor is coupled to a potentiometer or encoder that is used to compare the angular position of the axle versus a desired position. Roboteq controllers support 3 different position modes:

Position Relative - This mode uses analog, encoder, hall sensors or pulse feedback sensor with a scalled range of -1000 to +1000 and the motor will move from the current position to the destination using a controlled acceleration, velocity and deceleration.

Count Position - This mode is similar to Position Relative but the full counts of the encoders or the hall sensors for position feedback. The motor can be made to go to any count position value using a controlled acceleration and velocity profile.

Position Tracking - This mode is similar to the Positon Relative but with just a PID. The motor will try to go to the desires destination as fast as possible.


Torque mode

In Torque mode, controller will adjust the output in order to reach and maintain a set current value.



Mixed Motor Command Modes

Dual Channel controllers may be connected to two motors which will react to commands received on two input channels. Using these two channel inputs, the motors can be commanded independently or in a combined fashion to accommodate the most common drive and steering methods in robotic vehicles.

Independent Speed Command

In this mode, each of the two motors is commanded independently of the other. This operating mode is best suited for generic motor control applications.


Mixed Speed/Steering Command

This precise, hybrid mode allows the motors to work in combination to move and turn a vehicle by combining the forward/reverse command information and the left/right steering information. This mode of operation provides a cost effective method for moving and steering tank-style robots and underwater vehicles.



In many applications, Roboteq controllers drive high powered motors that move parts and equipment at high speed and/or with very high force. If a malfunction occurs, potentially enormous forces can be applied at the wrong time or in the wrong place. An error or malfunction can potentially cause serious damage to property and harm to operators and bystanders. While Roboteq controllers operate very reliably and failures are very rare, as with any other electronic equipment, an unforeseen failure is a possibility. If there is any danger that a loss of motor control can cause damage or injury, you must plan for that possibility in order to minimize the potential consequences, Roboteq certainly has. This article outlines some of the many precautions designed into our products to ensure the safety of our customers. Please read the below sections carefully so that you fully understand the potential risks in order best protect yourself, your equipment and bystanders.


 up down 1

Over/Under Limits Protections

Users should always keep in mind is that even a battery-operated system has a large amount of energy running through it. This is why Roboteq controllers always run below the maximum allowed current limit. This allows for a safe cushion for error without pushing design limits. Robteq controllers actively monitor the motor's current consumption and automatically reduce the power output to keep the current within allowed limits.  This keeps the motor and the wiring safe. Further, controllers automatically disconnect a motor from its power source if the voltage rises above the maximum threshold or dips below minimum threshold. Roboteq controllers also closely monitor their own heat output. Once a controller’s temperature rises above 70oC, power to the motor is scaled back. If the temperature exceeds 75oC, power to the motor is completely cut off.


watchdog icon 

Command Watchdogs

Multiple safe guards are designed into the firmware Roboteq’s controllers to help ensure the highest possible level of safety. If pulse commands are not repeated regularly or if no new command is received via the Serial, USB or CAN bus within a preset amount of time, the controller will cut-off all power to the motor. Additionally, when using analog commands, a motor using a Roboteq controller and a joystick will not start if the joystick is not centered. Should the command voltage rise above or fall below the safety thresholds, the motor will automatically stop.


stopsign icon

Motor Stops if Unsafe Conditions are Detected

Users can also set their own current thresholds. If the current should rise above user-defined threshold for too long, the controller will cut power to the motor. Power to the motor is also cut if limit switches are reached. To allow Roboteq users as many safety options as possible, any digital input can be used as a safety stop (controlled ramp stop) or emergency stop (motor disconnect). If a loop error condition error continues, for instance if the motor cannot reach a programmed speed or position for a sustained period of time, power to the motor is cut off. Roboteq’s stall detection disengages the motor if power is applied to the motor but no motion is detected. Further, if you have fitted your motor with an electromechanical break, Roboteq controllers will engage it, automatically.

 Safe Torque Off (STO) on selected Roboteq Controller models, coming later in 2018!


fault icon

Hardware Fault Protections

In the unlikely event that the firmware operating the motor controller’s microcomputer unit (MCU) should fail, Roboteq controllers feature the ability to automatically detect and recovery the MCU. An optional, separate power supply keeps the controller responding if power levels in the main battery pack become too low. Roboteq controllers feature a digital output for driving external contactors. By measuring for abnormal battery current draw while the motor is off, Roboteq controllers can detect transistor shorts in the power stage.


sheild 2

Additional Safety Functions Thanks to MicroBasic Scripting

Roboteq’s MicroBasic scripting allows the user to write programs that are permanently saved into, and run from the controller’s Flash Memory. This powerful ability also allows users to set application-specific fault conditions that can be detected and acted upon thanks to Roboteq’s MicroBasic scripting. One example of this would be activating an external alarm buzzer when motor speed is outside its low or high range. The MicroBasic scripting feature gives users the capability to fully customize the functionality of their Roboteq controller and program safety features based on their unique requirements.



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.



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
Is a local query that will return the values of all analog capture channels in a single string as
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
Will return the operating mode of all analog capture channels in a single string as
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)

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

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)

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:


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:
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

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)
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
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
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)

wait(10) ' Executer loop every 10 ms
' check if scanned volts arrived
' 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:


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.

 sto certificate  

STO Documentation

STO Certificate

STO User Manual

Safety is a critical concern in Mobile Robots. Serious injury to person and/or expensive material damage can occur if the robot and its load run out of control. Laser range finders, remote controls and other systems can be used to tell the robot to stop. The challenge is to make the robot always respond to the stop command. This is where Safe Torque Off – or STO – comes in.

STO is a safety mechanism for motor drives that reliably brings the motor to a no-torque state. STO is typically used for the prevention of an unexpected startup (EN 1037) of machinery or for an emergency stop, fulfilling stop category 0 (EN 60204-1).




STO has the immediate effect that the drive cannot supply any torque-generating energy. STO can be used wherever the drive will be brought to a standstill in a sufficiently short time by the load torque or friction or where coasting down of the drive is not relevant to safety. In a Mobile Robot application, STO will stop motion in case of emergency, and prevent restart until it is safe to do so.

From this simple description, one can assume that STO is as simple as disconnecting power to the drive and motors. And indeed, STO can be achieved using a contactor that will cut the power to the motor controller, for example. However, using a contactor adds cost and components that can also eventually go wrong.

STO must operate according to Safety Category 3 Performance Definition. To achieve Safety Category 3, according to EN ISO 13849-1, the controller must meet a list of several requirements. Of this list, the most challenging is that the STO must function even in the case of a single fault in any part of the system.

So, in the case of our earlier example, a single contactor cannot be use. At a minimum, two contactors are needed in series, so that energy can be cut from the motor in case one of the two contactors gets stuck.


Embedding STO in a Controller

All drive manufacturers are free to invent any method they wish if it meets the safety requirements. The most common implementation – and the one used by Roboteq, is to add a circuit that will cut off the power to MOSFET drivers. Without power, the drivers are not able to turn on any of the MOSFET’s gate.

Two switches in series are necessary to ensure that the power does get cut even if one of the switches is permanently ON because of failure.
Each of the switches is driven by a separate input, commonly labeled STO1 and STO2. In this manner, too, if one external or internal circuit is damaged and the respective STO command is stuck at the “ON” level, the other can still safely disconnect the power to the drivers.


Asset 1


The MCU monitors the STO input lines and the voltage to the MOSFET drivers. It is important to notice, however, that the STO circuit works independently of the controller’s MCU. It is therefore totally immune to any hardware malfunction.

The Safety Standard also requires that the drive be able to detect a failure in the STO circuit, and this can be quite challenging. Consider the example below:

STO1 and STO2 are active and both switches are On. But switch 1 is damaged and will remain ON even if the STO1 command is off. The drive appears to be operating normally. However, it is no longer as safe because it would not turn off if STO1 only is deactivated. It will still stop because STO1 and STO2 will be off. But if there is another fault in the system and should the STO2 command wire be stuck to a high voltage, the controller will not stop.

To alleviate these sort of problems, the controller incorporates additional circuitry for detecting and reporting that the STO circuit is fully functional.

The controller design is such that MCU can force either of both STO inputs to the OFF state. The MCU will use this capability to briefly turn off the MOSFET driver supply and verify that the driver supply voltage does in fact drops. This check is performed every time the controller is powered ON, as well as at periodic intervals.

Note that the MCU is not physically capable to force the STO inputs to the ON state. If it was, this could cause the STO circuit to cease protecting, in case the MCU is accidentally setting the outputs to 1 due to software of hardware malfunction.

Being a safety critical function that absolutely has to work in all situations, STO must be certified by a regulatory organization such as TUV. There, the examiner simulates the failure of all critical components to verify that the drive can still safely be stopped.

STO is available now on Roboteq's FBL2360T controllers. STO will be progressively introduced to all our motor controller products.





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

Modbus object types

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

Object type





1 bit

Discrete Input

Read Only

1 bit

Input Register

Read Only

16 bits

Holding Register


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.

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


Length (bytes)




Node address



Function code



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



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


Length (bytes)




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



Node address in hex



Function code in hex


n x 2

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



Checksum (Longitudinal redundancy check)




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


Length (bytes)


Transaction ID


For synchronization between messages of server and client

Protocol ID


0 for Modbus/TCP



Number of remaining bytes in this frame

Unit ID


Node address



Function code



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


Read Coil


Read Discrete Input


Read Holding Registers


Read Input Registers


Write Single Coil


Write Single Holding Register


Write Multiple Coils


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




Node address


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)


Cyclic redundancy check (CRC-16-IBM)

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




Node address


Function code (Read Input Registers)


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




Node address


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)


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




Node address


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




Node address


Function code with the highest bit set.


The exception code.

B0 53

Cyclic redundancy check (CRC-16-IBM)

The exception codes as explained in the Modbus specification are:






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.


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.


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.


Slave Device Failure

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



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.


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..


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.


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.


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.


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




Node address


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




Node address


Function code (Read Input Registers)


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:



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.


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



00 02

Transaction ID.

00 00

Protocol Identifier (0x0000 for TCP).

00 06

Number of bytes in the record.


Node address


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



00 02

Transaction ID.

00 00

Protocol Identifier (0x0000 for TCP).

00 0D

Number of bytes in the record (13 bytes).


Node address


Function code (Read Input Registers)


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:




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'



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

The response for this message will be as following:




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'



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



































































Query Mapping





























































































































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:




Set mode Off.


Set mode TCP.


Set mode RTU over TCP.


Set mode RS232 ASCII.


Set slave ID to 5.


Query mode.


Query slave ID.

  •  Start 
  •  Prev 
  •  1  2 
  •  Next 
  •  End 

Page 1 of 2

Go to top