Labview not communicating with devices through STRIDE Modbus Gateway

[Dhouston]

Hello all. We have a STRIDE Modbus Gateway that we are trying to use with LabVIEW. Our issue is that we can not get any data from our instruments that we connect to the Gateway. We have set up a VISA connection for the Gateway in MAX, and the connection validates successfully. When we connect our instrument to the Gateway, we are seeing flashing LEDs on the gateway which indicate the gateway is receiving data from the instrument. However, our LabVIEW program does not show any data, and actually errors out. We have seen various errors (eg. Error 54, 56, 66, and 538139) when it errors out. We are using the NI Modbus Library, which has successfully worked in other applications, but it is not working for this one. We set the Gateway to RTU Master. We know we are at least communicating with the gateway since we can change settings using the gateway web interface, we can ping the gateway successfully, and the fact that MAX successfully makes connection. Why can we not get any data? Our instruments are a Digi DC782 scale and a Watlow EZ Zone temperature controller.

Now, if we connect our PC directly to these instruments, we can use other non-Modbus LabVIEW programs to interface with these instruments, and these work successfully.  We don't understand what we are doing wrong with the gateway.

Here is one extremely frustrating issue.  Our VISA setup we have in MAX always errors when we do a VISA Test Panel.  We try to do the IDN command and we get either a Timeout, or worse, an I/O error.  What could be causing this?

[alexweefs · Accepted solution]

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.

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.

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.

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.

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.

[Dhouston]

Thank you for the response.  We greatly appreciate your detailed explanation of the Modbus API.  We went with using a Digi gateway for our project, which worked much better, and allowed our use of Modbus without all the issues the Stride gateway gave us.  

Your explanation furthers our understanding of Modbus more, and we thank you for that.