. Modbus is a serial communications protocol originally published by Modicon(now Schneider Electric) in 1979 for. Modbus in LabVIEW 3 ways to use Modbus in LabVIEW:.Use a high-level OPC Server. LabVIEW Example LabVIEW App #1 (Slave) LabVIEW App #2 (Master) LabVIEW. Oct 10, 2019 The MODBUS library is a free, downloadable set of Virtual Instruments (VIs) that provide Modbus communication from any standard Ethernet or serial port. The LabVIEW library implements the Modbus protocol in software and offers both master and slave functionality. Oct 21, 2019 Open the Labview Modbus library and run 'MB Serial Master Example.vi' Now it should be possible to read/write values into the simulator using the example program. The Block Diagram of example program can be analyzed to find out how data is being transferred behind the scenes on Modbus protocol. Kshitiz Sharma Kshitiz Sharma.
Serial Parameters are parameters that modify the way the MODBUS frame is structured. Refer to the MODBUS specification for more information about the MODBUS Frame. The Serial Parameters in LabVIEW is a cluster containing an enum (Mode) and an integer (Slave Address).
Help ContentsIntroduction
The Modbus Protocol was originally developed by Modicon (now part of Schneider Electric). Modbus was developed as a communication protocol for Modicon PLC Devices. The original Modbus Protocol specification, published in 1979, describes Serial Communications where data is transmitted one bit at a time. A later update to the standard, called Modbus TCP, describes how to use Modbus in TCP/IP networks.
The rest of this article describes the Modbus protocol is more detail:
- Modbus Data Types.
- Modbus Message Structure.
- Modbus PDU.
- Modbus Exception Codes.
Modbus Data Types
The Modbus Protocol supports these data types:
Data Type | Access | Description |
---|---|---|
Coil | Read-write | Single bit outputs. |
Discrete Input | Read-only | Single bit inputs. |
Input Register | Read-only | 16-bit input registers. |
Holding Register | Read-write | 16-bit output registers. |
Modbus Message Structure
Modbus is a request-response protocol where:
- The client sends a request to a Modbus device.
- The Modbus device sends a response.
The structure of a modbus message is the same for both requests and responses:
Unit Address | Modbus PDU | Error Check |
The exact format of the message depends on the variant of Modbus protocol used:
- Modbus ASCII - A serial protocol using a subset of ASCII characters.
- Modbus RTU - A serial protocol using 8-bit binary.
- Modbus TCP - A TCP/IP protocol.
- Modbus RTU over TCP - A TCP/IP protocol with an additional CRC check.
Modbus ASCII
Modbus ASCII uses a subset of the ASCII character set to send modbus messages over Serial Communications.
Modbus ASCII messages start with the colon (:) character (ASCII 58). Modbus ASCII messages end with carriage return (ASCII 13) and line feed (ASCII 10) characters. Between the start and end characters only hexadecimal characters 0 to 9 and A to F are allowed.
The structure of a Modbus ASCII message is:
Start | Unit Address | Message | LRC | End |
ASCII 58 | 2 characters | N characters | 2 characters | ASCII 13 + ASCII 10 |
Where:
- The Unit Address field is the PLC Address encoded as 2 hexadecimal characters.
- The Message field is a Modbus PDU where each byte is encoded as 2 hexadecimal characters.
- The LRC field is the Longitudinal Redundancy Check of the Address and Message fields.
Modbus RTU
Modbus RTU uses 8-bit Serial Communications to send Modbus messages.
The structure of a Modbus RTU message is:
Unit Address | Message | CRC |
1 Byte | N Bytes | 2 Bytes |
Where:
- The Unit Address field is the PLC Address encoded as single byte.
- The Message field is a Modbus PDU.
- The CRC field is the Cyclic Redundancy Check of the Address and Message fields.
Modbus TCP
Modbus TCP uses a TCP/IP link to send and receive Modbus messages.
The structure of a Modbus TCP message is:
Transaction Id | Protocol | Length | Unit Address | Message |
2 Bytes | 2 Bytes | 2 Bytes | 1 Byte | N Bytes |
Where:
- The Transaction Id field identifies the transaction.
- The Protocol field is zero to indicate Modbus protocol.
- The Length field is the number of following bytes.
- The Unit Address field is the PLC Address encoded as single byte.
- The Message field is a Modbus PDU.
Unit Address
Note: Real Modbus TCP devices use the Unit Address field in different ways:
- Some Modbus TCP devices ignore Unit Address.
- Some Modbus TCP devices require a fixed value for Unit Address, for example 0 or 255.
- Some Modbus TCP devices are a gateway to multiple PLC where the Unit Address selects which PLC to communicate with.
Modbus RTU over TCP
Modbus RTU over TCP is a non-standard variant of Modbus TCP that includes the CRC from the Modbus RTU message.
The structure of a Modbus RTU over TCP message is:
Transaction Id | Protocol | Length | Unit Address | Message | CRC |
2 Bytes | 2 Bytes | 2 Bytes | 1 Byte | N Bytes | 2 Bytes |
Where:
- The Transaction Id field identifies the transaction.
- The Protocol field is zero to indicate Modbus protocol.
- The Length field is the number of following bytes.
- The Unit Address field is the PLC Address encoded as single byte.
- The Message field is a Modbus PDU.
- The CRC field is the Cyclic Redundancy Check of the Address and Message fields.
Modbus PDU
The Modbus Protocol supports these PDU:
- Modbus Read Coils (01).
- Modbus Read Discrete Inputs (02).
- Modbus Read Holding Registers (03).
- Modbus Read Input Registers (04).
- Modbus Write Single Coil (05).
- Modbus Write Single Register (06).
- Modbus Write Multiple Registers (16).
Modbus Read Coils (01)
Modbus Read Coils, function code 01, reads between 1 and 2000 output coils (bits) from the PLC.
The request PDU consists of 5 bytes:
Offset | Length | Description | Values |
---|---|---|---|
0 | Byte | Function Code | 01 |
2 | Word | First coil address | 0000h - FFFFh |
4 | Word | Coil count | 0001 - 07D0h |
The normal response varies in length from 3 bytes up to 252 bytes depending on the number of coils requested:
Offset | Length | Description | Values |
---|---|---|---|
0 | Byte | Function Code | 01 |
1 | Byte | Byte Count | (CoilCount + 7) / 8 |
2 | N Bytes | Coil data | ... |
Note: The total number of bytes returned is 2 + (CoilCount + 7) / 8, where CoilCount is the number of coils requested. For example a request for 1 coil, will return 3 bytes. A request for 8 coils will also return 3 bytes. A request for 9 coils will return 4 bytes. The largest request possible is for 2000 coils, which will return 252 bytes.
If the PLC detects an error in the request, for example an address that is not available, an error response will be sent:
Offset | Length | Description | Values |
---|---|---|---|
0 | Byte | Function Code | 81h |
1 | Byte | Exception Code | See Exception Codes |
Example: Read 12 coils starting at 00033 from a PLC at address 2. Response with coils 00040 and 00042 set and all others clear :
Request | Response | |
---|---|---|
Modbus ASCII | 3A 30 32 30 31 30 30 32 30 30 30 30 43 44 31 0D 0A | 3A 30 32 30 31 30 32 38 30 30 32 37 39 0D 0A |
Modbus RTU | 02 01 00 20 00 0C 3D F6 | 02 01 02 80 02 1D FD |
Modbus TCP | 00 05 00 00 00 06 02 01 00 20 00 0C | 00 05 00 00 00 05 02 01 02 80 02 |
Note: The PDU part of each request and response is shown in Blue.
Modbus Read Discrete Inputs (02)
Modbus Read Discrete Inputs, function code 02, reads between 1 and 2000 inputs from the PLC.
The request PDU consists of 5 bytes:
Offset | Length | Description | Values |
---|---|---|---|
0 | Byte | Function Code | 02 |
2 | Word | First input address | 0000h - FFFFh |
4 | Word | Input count | 0001 - 07D0h |
The normal response varies in length from 3 bytes up to 252 bytes depending on the number of inputs requested:
Offset | Length | Description | Values |
---|---|---|---|
0 | Byte | Function Code | 02 |
1 | Byte | Byte Count | (InputCount + 7) / 8 |
2 | N Bytes | Input data | ... |
Note: The total number of bytes returned is 2 + (InputCount + 7) / 8. InputCount is the number of inputs requested. For example a request for 1 input, will return 3 bytes. A request for 8 inputs will also return 3 bytes. A request for 9 inputs will return 4 bytes. The largest request possible is for 2000 inputs, which will return 252 bytes.
If the PLC detects an error in the request, for example an address that is not available, an error response will be sent:
Offset | Length | Description | Values |
---|---|---|---|
0 | Byte | Function Code | 82h |
1 | Byte | Exception Code | See Exception Codes |
Example: Read 16 inputs starting at 10501 from a PLC at address 1. Response with inputs 10501 and 10503 set and all others clear :
Request | Response | |
---|---|---|
Modbus ASCII | 3A 30 31 30 32 30 31 46 34 30 30 32 30 45 38 0D 0A | 3A 30 31 30 32 30 32 30 35 30 30 46 36 0D 0A |
Modbus RTU | 01 02 01 F4 00 20 39 DC | 01 02 02 05 00 BA E8 |
Modbus TCP | 00 0A 00 00 00 06 01 02 01 F4 00 20 | 00 0A 00 00 00 05 01 02 02 05 00 |
Note: The PDU part of each request and response is shown in Blue.
Modbus Read Holding Registers (03)
Modbus Read Holding Registers, function code 03, reads between 1 and 125 holding registers from the PLC.
The request PDU consists of 5 bytes:
Offset | Length | Description | Values |
---|---|---|---|
0 | Byte | Function Code | 03 |
2 | Word | First input address | 0000h - FFFFh |
4 | Word | Register count | 0001 - 007Dh |
The normal response varies in length from 4 bytes up to 252 bytes depending on the number of holding registers requested:
Offset | Length | Description | Values |
---|---|---|---|
0 | Byte | Function Code | 03 |
1 | Byte | Byte Count | RegisterCount * 2 |
2 | N Bytes | Register data | ... |
Note: The total number of bytes returned is 2 + 2 * RegisterCount, where RegisterCount is the number of holding registers requested. For example a request for 1 holding register, will return 4 bytes. A request for 2 holding registers will return 6 bytes. A request for 125 holding registers will return 252 bytes.
If the PLC detects an error in the request, for example an address that is not available, an error response will be sent:
Offset | Length | Description | Values |
---|---|---|---|
0 | Byte | Function Code | 83h |
1 | Byte | Exception Code | See Exception Codes |
Example: Read 2 holding registers starting at address 40601 from a PLC at address 1. Response returns register 40601 value 1000, and register 40602 value 5000:
Request | Response | |
---|---|---|
Modbus ASCII | 3A 30 31 30 33 30 32 35 38 30 30 30 32 41 30 0D 0A | 3A 30 31 30 33 30 34 30 33 45 38 31 33 38 38 37 32 0D 0A |
Modbus RTU | 01 03 02 58 00 02 44 60 | 01 03 04 03 E8 13 88 77 15 |
Modbus TCP | 00 0F 00 00 00 06 01 03 02 58 00 02 | 00 0F 00 00 00 07 01 03 04 03 E8 13 88 |
Note: The PDU part of each request and response is shown in Blue.
Modbus Read Input Registers (04)
Modbus Read Input Registers, function code 04, reads between 1 and 125 input registers from the PLC.
The request PDU consists of 5 bytes:
Offset | Length | Description | Values |
---|---|---|---|
0 | Byte | Function Code | 04 |
2 | Word | First input address | 0000h - FFFFh |
4 | Word | Register count | 0001 - 007Dh |
The normal response varies in length from 4 bytes up to 252 bytes depending on the number of input registers requested:
Offset | Length | Description | Values |
---|---|---|---|
0 | Byte | Function Code | 04 |
1 | Byte | Byte Count | RegisterCount * 2 |
2 | N Bytes | Register data | ... |
Note: The total number of bytes returned is 2 + 2 * RegisterCount, where RegisterCount is the number of input registers requested. For example a request for 1 input register, will return 4 bytes. A request for 2 input registers will return 6 bytes. A request for 125 input registers will return 252 bytes.
If the PLC detects an error in the request, for example an address that is not available, an error response will be sent:
Offset | Length | Description | Values |
---|---|---|---|
0 | Byte | Function Code | 84h |
1 | Byte | Exception Code | See Exception Codes |
Example: Read 2 input registers starting at address 30201 from a PLC at address 1. Response returns register 30201 value 10000, and register 30202 value 50000:
Request | Response | |
---|---|---|
Modbus ASCII | 3A 30 31 30 34 30 30 43 38 30 30 30 32 33 31 0D 0A | 3A 30 31 30 34 30 34 32 37 31 30 43 33 35 30 41 44 0D 0A |
Modbus RTU | 01 04 00 C8 00 02 F0 35 | 01 04 04 27 10 C3 50 A0 39 |
Modbus TCP | 00 14 00 00 00 06 01 04 00 C8 00 02 | 00 14 00 00 00 07 01 04 04 27 10 C3 50 |
Note: The PDU part of each request and response is shown in Blue.
Modbus Write Single Coil (05)
Modbus Write Single Coil, function code 05, writes a single coil to the PLC.
The request PDU consists of 5 bytes:
Offset | Length | Description | Values |
---|---|---|---|
0 | Byte | Function Code | 05 |
2 | Word | First coil address | 0000h - FFFFh |
4 | Word | Coil value | 0x0000 or 0xFF00 |
The normal response is the request reflected back:
Offset | Length | Description | Values |
---|---|---|---|
0 | Byte | Function Code | 05 |
2 | Word | First coil address | 0000h - FFFFh |
4 | Word | Coil value | 0x0000 or 0xFF00 |
If the PLC detects an error, for example an address that is not available, an error response will be sent:
Offset | Length | Description | Values |
---|---|---|---|
0 | Byte | Function Code | 85h |
1 | Byte | Exception Code | See Exception Codes |
Example: Set coil 00101 in device with address 1 to 1.
Request | Response | |
---|---|---|
Modbus ASCII | 3A 30 31 30 35 30 30 36 34 46 46 30 30 39 37 0D 0A | 3A 30 31 30 35 30 30 36 34 46 46 30 30 39 37 0D 0A |
Modbus RTU | 01 05 00 64 FF 00 CD E5 | 01 05 00 64 FF 00 CD E5 |
Modbus TCP | 00 19 00 00 00 06 01 05 00 64 FF 00 | 00 19 00 00 00 06 01 05 00 64 FF 00 |
Note: The PDU part of each request and response is shown in Blue.
Modbus Write Single Register (06)
Modbus Write Single Register, function code 06, writes a single register to the PLC.
The request PDU consists of 5 bytes:
Offset | Length | Description | Values |
---|---|---|---|
0 | Byte | Function Code | 06 |
2 | Word | First register address | 0000h - FFFFh |
4 | Word | Register value | 0000h - FFFFh |
The normal response is the request reflected back:
Offset | Length | Description | Values |
---|---|---|---|
0 | Byte | Function Code | 06 |
2 | Word | First register address | 0000h - FFFFh |
4 | Word | Register value | 0000h - FFFFh |
If the PLC detects an error in the request, for example an address that is not available, an error response will be sent:
Offset | Length | Description | Values |
---|---|---|---|
0 | Byte | Function Code | 86h |
1 | Byte | Exception Code | See Exception Codes |
Example: Set Holding Register 40101 in device with address 1 to 15000.
Request | Response | |
---|---|---|
Modbus ASCII | 3A 30 31 30 36 30 30 36 34 33 41 39 38 43 33 0D 0A | 3A 30 31 30 36 30 30 36 34 33 41 39 38 43 33 0D 0A |
Modbus RTU | 01 06 00 64 3A 98 98 DB | 01 06 00 64 3A 98 98 DB |
Modbus TCP | 00 1E 00 00 00 06 01 06 00 64 3A 98 | 00 1E 00 00 00 06 01 06 00 64 3A 98 |
Note: The PDU part of each request and response is shown in Blue.
Modbus Write Multiple Registers (16)
Modbus Write Multiple Registers, function code 16, writes between 1 and 123 registers to the PLC.
The request PDU consists of between 8 and 252 bytes:
Offset | Length | Description | Values |
---|---|---|---|
0 | Byte | Function Code | 10h |
2 | Word | First register address | 0000h - FFFFh |
4 | Word | Register Count | 0000h - 007Bh |
5 | Byte | Byte Count | 0000h - 007Bh |
6 | N Words | Register values | ... |
The normal response consists of 5 bytes:
Offset | Length | Description | Values |
---|---|---|---|
0 | Byte | Function Code | 10h |
2 | Word | First register address | 0000h - FFFFh |
4 | Word | Register Count | 0000h - 007Bh |
If the PLC detects an error in the request, for example an address that is not available, an error response will be sent:
Offset | Length | Description | Values |
---|---|---|---|
0 | Byte | Function Code | 90h |
1 | Byte | Exception Code | See Exception Codes |
Example: In the PLC at address 28, set register 40101 to 1000 and register 40102 to 2000.
Request | Response | |
---|---|---|
Modbus ASCII | 3A 31 43 31 30 30 30 36 34 30 30 30 32 30 34 30 33 45 38 30 37 44 38 41 30 0D 0A | 3A 31 43 31 30 30 30 36 34 30 30 30 32 36 45 0D 0A |
Modbus RTU | 1C 10 00 64 00 02 04 03 E8 07 D8 19 02 | 1C 10 00 64 00 02 03 9A |
Modbus TCP | 00 23 00 00 00 0B 1C 10 00 64 00 02 04 03 E8 07 D8 | 00 23 00 00 00 06 1C 10 00 64 00 02 |
Note: The PDU part of each request and response is shown in Blue.
Modbus Exception Codes
An exception code is a single byte providing an explanation of an error:
Modbus Programming Examples
Code | Description |
---|---|
01h | Illegal function |
02h | Illegal data address |
03h | Illegal data value |
04h | Slave device failure |
Further Information
To learn how modbus data addresses are presented in human readable form.
To learn about Modbus Register Block Tags.
For an overview of the Modbus Driver.
For the meaning of terms used in Fernhill SCADA.
Fernhill SCADA Version 3.62. Copyright © 2012-2020 Fernhill Software Ltd: All rights reserved.
Labview Modbus Serial Example Reference
While exchanging with our customers on the best ways to interface industrial controllers, we noticed that nowadays the small secrets enabling you to use an RS485 interface were sometimes unknown from engineers implementing computer or internet based automation. So here is a quick remedial course...
What is RS485?
RS485 is a serial transmission standard, a little bit like RS232, but using other electric signals. An important advantage of RS485 is that you can put several RS485 devices on the same bus. Therefore, you don't have to multiply RS485 interfaces on the host to question several devices. However, there is a small trick to do so: at each end of the bus, you must put a bus terminator. Sometimes this means that you must screw a small resistance on a terminal, or simply move a switch in the adequate position.
An RS485 bus is often made of just two wires and a resistor at the extremities...
RS485 and RS232 are not directly compatible: you must use the correct type of interface, or the signals won't go through. There are indeed RS232 to RS485 gateways, but they are not interesting nowadays: it's as easy to use an RS485 to USB, to Ethernet, or to GSM directly. It's cheaper and it's one less component in the system.
The main particularity when using RS485 is in the format of the exchanged data. While with RS232 many devices simply use text (ASCII) protocols, with RS485 most devices use the MODBUS protocol. You must therefore know a minimum of MODBUS to interface an RS485 device.
What is MODBUS?
MODBUS is a protocol between a host (master) and devices (slaves) to access the configuration of the devices and to read the measures. MODBUS messages correspond to relatively simple operations to read and write 16 bit words and binary registers (often called 'coils'). The host systematically initiates the exchange and the 'slave' device answers. The slave doesn't sent any message before the host requests it.
As there can be several devices connected in parallel on the RS485 bus, each slave device must use a unique MODBUS Slave ID on the bus. Each MODBUS request starts with the Slave ID of the intended device, each answer starts with Slave ID of the slave sending it. So, in order for the MODBUS communication to work, you must check in the device configuration its Slave ID and change it if necessary. On the way, check also communication speed and parity (same principle as RS232).
You cannot easily craft MODBUS messages 'by hand', as you would have done with ASCII protocols used on RS232: each MODBUS message ends with a checksum code, computed from the full content of the message. To exchange MODBUS messages, you must therefore use:
- either a specific program provided by the device vendor, with a compatible interface;
- or a simple RS485 interface with a programming library which encodes and decodes MODBUS messages;
- or a smart RS485 interface able to encode and decode by itself the MODBUS messages, such as the Yocto-RS485.
Labview Modbus Serial Example Software
Note as well that there are two variants of the MODBUS protocol: the MODBUS ASCII mode, where messages are exchanged as lines of hexadecimal codes, and the MODBUS RTU mode, where messages are exchanged directly as binary frames. To talk with a MODBUS device, you must imperatively use the same mode as configured in the device. All the devices which truly follow the standard support the MODBUS RTU mode. In real life, its always this latter mode which is used: MODBUS ASCII has no advantage as all the messages are in any case difficult to code by hand.
A small temperature controller with built-in PID, fuzzy logic, ... and a MODBUS interface on RS485
Accessing MODBUS registers
When you have theoretically understood how to exchange information, you still must know which register to request to obtain measures, and which registers to change to configure the device. At this level, register addresses change from one device to another, but there are MODBUS conventions useful to know to understand technical user guides, which are often not as clear as one could hope.
There are 4 types of MODBUS registers:
- The coils, corresponding to on/off binary outputs, such as relays.
- The input bits, corresponding to binary inputs (read only).
- The input registers, corresponding to analog inputs (read only).
- The holding registers, corresponding to analog parameters which can be changed.
The technical user guide of a MODBUS device usually contains a list of all the available registers, listed by type. For each type of register corresponds a range of register numbers, following this convention:
- The coils are numbered from 00001 onward
- The input bits are numbered from 10001 onward
- The input registers are numbered from 30001 onward
- The holding registers are numbered from 40001 onward
Note that when one uses this convention, the first register of each category always ends by digit 1 (zero is not used).
Sometimes, rather than indicating the unique register number, the vendor indicates the type of register with the identifier of the MODBUS function which allows you to read them:
- 01h for the coils
- 02h for the input bits
- 04h for the input registers
- 03h for the holding registers
In this case, it's often the relative position of the register in its group which is indicated, with the 0 position for the first element. Thus, register 0 of the 04h function corresponds to the first input register, which you can also call register 30001. Take care not to be confused by the incoherence between register ranges which do not correspond to the MODBUS function identifiers, and the incoherence of relative positions starting at 0 while absolute positions start at 1...
When you know which register to access, you must still know how to interpret it. As analog registers are coded using 16 bits, there are usually two conventions. The first one consists in using a value range defined in the device configuration, and to make an linear mapping of the 0-65535 register value to this value range. The second consists in storing directly the value in decimal fixed point, in engineering unit: for example, 2345 represents 23.45 degrees Celsius. Some vendors provide simultaneously the values in the two formats: for example, register 30001 for the version proportional to the defined range and register 31001 for the decimal version.
Labview Modbus Example
A concrete example
Let's see concretely how you can access the temperature measurement and the setpoint value of a Schneider Electric Zelio REG48 temperature controller. Here is an extract of the technical user guide:
Extract of the register table of the Zelio REG48 controller
If you have paid attention, you have understood that this table describes input registers. The base register use the proportional format, and the one at offset +1000 is in decimal form (engineering unit). If you use a Yocto-RS485 you can thus access it with the modbusReadRegisters() function. Beware, as indicated in the documentation, this function uses the relative position of the register (indexed from zero):
Modbus Tcp Labview
// Retrieve our RS485 interface
var serial =YSerialPort.FindSerialPort('RS485-REG48');
// Read first two registers, in 'engineering unit'
var slaveID =1;
var firstRegs = serial.modbusReadInputRegisters(slaveID,1000,2);
// Decode fixed point decimal number
var processVal = firstRegs[0]/10;
var setpointVal = firstRegs[1]/10;
var serial =YSerialPort.FindSerialPort('RS485-REG48');
// Read first two registers, in 'engineering unit'
var slaveID =1;
var firstRegs = serial.modbusReadInputRegisters(slaveID,1000,2);
// Decode fixed point decimal number
var processVal = firstRegs[0]/10;
var setpointVal = firstRegs[1]/10;
Another possibility of use with the Yocto-RS485: you can configure it with the web interface so that it automatically reads those registers, without needing you to interact with a computer to trigger the measures.
Labview Modbus Serial Example Java
A job to periodically read a register
Thanks to this, the Yocto-RS485 can serve as a data logger to store the measures received by RS485 on its flash memory (up to 500'000 measures).
You can go even farther: if you connect the Yocto-RS485 on a YoctoHub-Ethernet and if you load on it a small web page with some JavaScript, you can transform this simple RS485 temperature controller based on technology from the 70's into a connected product in the fashion of the Internet of Things. Any browser running on a tablet can then connect to the interface and interact with the temperature controller:
Labview Modbus Serial Example Diagram
Neat, isn't it?