Skip to content

Variants for Modbus

Almost all IoTize products support this protocol, but there are a few possible variations to consider.

Which equipment?

Modbus is an example of a wired protocol that is natively handled by Duetware.

Modbus is an industrial protocol, but its digital definition can also be used to link a microcontroller to others because its concepts are simple enough to be effective in a large number of configurations. Thus, this protocol can be used to connect a TapNLink module to any microcontroller with a serial port (UART, low voltage). In this case, implementation is simplified by automatically generating files (by Studio) defining register tables, and the client code provided for the target microcontroller is easy to integrate in the existing application. But in the majority of cases, Modbus will be used more on Iotize's gateway products: Tapioca, TapNPass but also TapBus. In the following sections, we assume that we are in this case.

With which gateways?

There are mainly two variants of the Modbus protocol:

Modbus RTU

Modbus RTU is an implementation of the serial link protocol. In general, it is based on an RS485 electrical link, but is also used in various variants: RS232 or serial USB. TapNPass boxes but also some Tapioca modules use these modes.

Modbus TCP

Modbus-TCP can be used over a TCP-IP link, either ethernet (Tapioca or TapBus) or Wi-Fi. In the following, we will assume that Modbus-RTU is used over an RS-485 link, which is still the most frequent case.

Master or slave ?

The Modbus architecture assumes a master (or client) and one or more slaves (or server). Iotize products support both modes. For example, in the case of a TapNLink module, it is usually the TapNLInk module that takes the initiative to read or write data to registers located in one or more target microcontrollers. But you can also choose the reverse mode in which a target microcontroller will read or write registers in the TapNLink module. Of course, the same goes for gateways.

Mode master (client)

This is the most common vas: the list of slave registers must be defined and Duetware can (in target variables) provide images of these registers to a mobile application or the Cloud. We can then consider that Duetware is a relay between the target and the mobile App.

Slave mode (server)

In this case, the registers will be 'InTap' variables that the master (or client) will have to read or write so that the mobile application (or the Cloud) has access to their values. We can then consider that these are variables shared between the target and the mobile app.  

Modbus direct, or through Duetware variables

Duetware offers two different accesses to Modbus devices:

  • Either a direct access based on the registry's reference information: slave number, registry address, variable type,....
  • Or through a variable whose identification number has no link with the above information. The conversion 'variable id' to 'registry reference' is done internally by Duetware.

The first method has the advantage of simplifying the configuration of Duetware. The second offers the advantages linked to Duetware's functionalities: the notions of 'groups of variables' and those of 'access rights' will then make it possible to optimize communications and better manage access control.

Back to top