Sharing a particular device among multiple processes or computers [LJM User's Guide]

Sometimes it's beneficial to access a particular device from multiple processes or computers.

The most lightweight way to share a device is using UDP reads. The leader strategy is the most robust option.

Device considerations

Connection types

USB: T-series devices support a single USB connection.

Ethernet: Either TCP or UDP can be used for typical Modbus communications. See the Ethernet section of the T-series datasheet to find the number of TCP socket connections supported on your device. UDP is technically connectionless, so there is no limit to the number of UDP based device connections.

WiFi: T7-Pros support a single WiFi TCP connection. They also support WiFi UDP connections, but Ethernet UDP should be preferred.

Modbus

The Modbus module in firmware is single-threaded and synchronous. This means that only one Modbus operation may be serviced at a time. To estimate whether a single device will be able to be shared according to your requirements, see T-series data rates for information about how much communication overhead and sampling time is required. For example, reading the AIN of a T7 using the highest resolution index takes 159 milliseconds. No other processes are able to perform Modbus operations for that duration.

Lua

The on-board Lua scripting engine interfaces with the Modbus module, similar to how external connections do. While this means that Lua scripting has full functionality, it also means Lua scripts can be another source of contention.

Lua can also be used to gather data and put results into user RAM. This is useful for long-running operations, such as AIN reads with high resolution.

Strategy: UDP - For network communication

Using UDP to communicate with the device is simple to implement. It's generally the recommended way to share a device among multiple processes.

UDP is technically connectionless, which means that sharing a device on the network using UDP doesn't consume any of the T-series devices' connections. The result is that your loop doesn't have to worry about opening or closing. With UDP, you can open a device handle using UDP as the Connection type, then your loop only needs to read. Collisions are less likely because opening incurs an overhead.

Strategy: Open-read-close - For USB or network communication

The open-read-close strategy is when each process that needs to access the device opens a connection, reads from the device (or writes), then immediately closes the device connection. This strategy is:

• Simple to implement
• A good alternative to UDP when using USB
• Sufficient for slower sampling frequencies, depending on how many processes access the device

Pseudocode for doing open-read-close might look loosely like the following:

while (reading) {
    device = OpenDevice(openParameters)
    result = ReadFromDevice(device, readParameters)
    CloseDevice(device)
    ProcessResult(result)
    Sleep()
}

One downside of open-read-close compared to UDP reads is that opening incurs overhead in two forms: the TCP SYN/FIN commands incur very slight overhead (a couple of packets) and LJM reads from the device every time it opens a device (less than 10 round-trip packets).

One downside of open-read-close compared to the leader strategy is that clock drift between different computers can increase the likeliness that multiple computers will try to open the device at the same time.

With LJM, you may want to experiment with the open timeouts and send timeouts to give each process a better chance at re-trying to opens and Modbus operations. For example, you might want to set the open timeout (for whatever connection type you're using) to 200 ms, so that there are 5 attempts to read from the device within 1 second.

Strategy: Use a Leader Process - For USB or network communication

The leader strategy is when one process acts as the leader. The leader is the only process that reads from the device. Other processes then read from the leader. This works for USB or network connections. This strategy:

• Requires the most custom work
• Is the most robust strategy
• Can have the least amount of sampling jitter
• Is compatible with stream mode
• Scales to allow the most processes reading from the device

For network connections, the leader process may be on a separate computer from the others and it exposes network connections to the other 3 hosts that let them get readings.

Regardless of whether the connection is via USB or the network, the leader responsibilities include:

• Leader must know what the other processes need to sample and at what interval.
• Leader must expose an interface for the other processes to read from.
• Files, named pipes, shared memory, remote procedure calls, and REST endpoints are a couple of ways for the leader to expose such an interface.
  • Recommended proof-of-concept for USB: The leader can write a timestamp and the current value to a file for each non-leader process. For example, if the leader knows that Process B needs to read AIN2, it could write the current Epoch time comma-separated with the current value of AIN2 to a file—the file could be named proc_b_ain2.csv and the leader could write 1556211610, 3.2 to indicate that AIN2's current value at that time is 3.2. Process B could then read that file. Every time the timestamp changes, Process B knows that a new value has been written.

This is the approach that is likely have the least amount of sampling jitter because the leader process can regularly schedule readings (the LJM timing functions are helpful for this). Clock drift between multiple computers does not affect the sampling time because only one computer's clock is triggering the sample collections.

For hardware-timed sampling using stream mode, this is the only possible type of device sharing strategy because T-series devices may only perform one stream at a time.  Also, stream mode takes over the entire analog input system such that analog inputs are not available to any command-response reads.

Since communication with the device can be a performance bottleneck, the leader strategy is the most scalable because it can incur the least amount of communication overhead with the device.