The low-level Modbus API is the preferred option when your application needs a high level of control over the sequencing and timing of Modbus requests. The low-level API is typically also the preferred choice where flexibility is paramount. In contrast, the flexibility and power offered by the LabVIEW Modbus API also means that your application code must be more complex to correctly manage the API. To help you understand this complexity, LabVIEW provides two examples.
Modbus Introductory Example
The first example, Modbus Library.lvproj, provides a basic overview of the API’s functionality. It also demonstrates the differences between an implementation on a PC and a real-time target. Figure 3 shows the code involved in the Real-Time Modbus Master example.
Figure 3. Master on RT Target.vi
This example demonstrates the core requirements of a Modbus application using the LabVIEW API. First, a Modbus instance is created. In this case, a TCP master. However, you can switch this example to a serial master by changing the polymorphic instance selector.
Figure 4. Changing the Type of Modbus Master
When the instance is created, you can begin polling the slave device for data. The example shows the use of the function code Read Input Registers. All Modbus function codes supported by the API are shown on the appropriate palette. Because of implementation of the protocol, the slave API has additional functions that the master cannot implement. For example, a slave can write to the input register range, while a master may only read from that range. Figure 5 shows the function codes.
Figure 5. Modbus Master and Slave Palettes Showing the Function Codes
Finally, the Modbus instance is closed, de-allocating the memory associated with the instance. This also closes any references, including the TCP connection or NI-VISA serial references used by the instance.
Only the master example has been discussed thus far; however, every example follows the same basic pattern familiar to most LabVIEW users: open, read/write, and close.
Finally, although the API does look the same, it is important to understand the key difference. If your device is a master, it must send a request across the network to the appropriate slave to acquire data. The slave, on the other hand, has its own local data storage and can access it quickly.
Redundant Master Example
The basic example may suffice for some applications; however, it may not be enough for complicated applications where the goal is to talk to a sensor or gateway. To help bridge this gap, a sample application shows how to use two masters to communicate with a given slave. If one of the masters fails and loses connection with either the slave or human machine interface (HMI), the other master takes over.
Figure 6. Design of the Redundant Master Example
If this design meets the needs of your application, or if you are interested in a more complex example of Modbus communication, view Redundant Modbus Masters.lvproj in the Example Finder.