Skip to main content
Skip table of contents

Appendix A - Diagrams

This app note was written when the T7 was the only T-series device. Most mentions of T7 can be assumed to apply to any T-series device with Ethernet.

The following figures demonstrate typical methods to monitor and control a LabJack device through the internet.  The "recommended path" as seen in the parent app-note LabJack via Internet, is shown in figure 2 below.

On-site client with IoT service

Figure 1. User software interacts with IoT service

Write application software on any on-site computer, then add a simple TCP communication code to the software that will communicate with the IoT service, and relay the instructions to the LabJack device. Simple implementations of this IoT option are demonstrated in the DAQConnect App Note, and the Monitor with GoogleDrive App Note.

Pros

  • Use any IoT service

  • Compatible with all LabJack devices

  • Use LJM or UD high-level libraries (C, C++, LabVIEW, Python, MATLAB, VB6, .Net, Java...)

  • Does not require port forwarding (good security)

  • User software does not have to include a web server, and the IoT service is robust enough to handle any number of off-site platforms performing simultaneous access

  • Internet communication can be encrypted

Cons

  • User must learn the API of the IoT service, typically a REST API

  • User software must parse/convert the IoT TCP communication into LabJack device communication, and vice versa

On-site server

Figure 2. User software as web server

Write application software on any on-site computer, then create a web interface for that software.  We don't have any examples of this option, but it is a good idea to start by reading about Tomcat, or Apache etc.

Pros

  • Do not have to learn the API of an IoT service

  • Compatible with all LabJack devices

  • Use LJM or UD high-level libraries (C, C++, LabVIEW, Python, MATLAB, VB6, .Net, Java...)

  • Flexible, powerful, extensible

  • On-site interface resembles off-site interface, which makes it easier to maintain, develop, or expand.

  • It's relatively easy to create a web interface using newer programming packages that are meant to be viewed in a browser.

  • Internet communication can be encrypted

Cons

  • User software must include a web server and web interface

  • User software must convert browser input to LabJack device input, and vice versa

  • Requires port forwarding (less secure)

  • Must type public IP address:port into browser unless registered with a domain name

IoT service with Modbus TCP client capability

Figure 4. IoT service with Modbus TCP client capability

At the time of this writing, it is unclear if there exists a pre-made IoT service that can act as a web server, and also a Modbus TCP client. If such an IoT service can not be found, it's possible to write the software, and load it onto a server. Create software as shown in figure 2, and then move the software from the on-site computer to any other net-based server.

Pros

  • The on-site deployment is minimal because it only requires the LabJack device and port forwarding

Cons

  • Requires port forwarding (less secure)

  • Custom application must reside in the IoT service.

  • For extensive custom operation, must create your own IoT service.

  • T-series only

  • Device-to-internet communication cannot be encrypted

  • Must type public IP address:port into browser unless registered with a domain name

Remote Desktop

Figure 6. Remote Desktop

Write application software on any on-site computer, then configure that computer for remote desktop. Individual users can monitor and control the LabJack device from anywhere, with no extra user code, and very little added complexity.

Pros

  • Do not have to learn the API of an IoT service

  • There are apps that will allow cell phones and tablets to perform remote desktop

  • Compatible with all LabJack devices

  • Use LJM or UD high-level libraries (C, C++, LabVIEW, Python, MATLAB, VB6, .Net, Java...)

  • Does not require port forwarding (good security)

  • User software does not need to include a web server

  • Internet communication is encrypted

Cons

  • Typically only one off-site platform can connect at a time

  • Android, iOS are less convenient

  • Remote control must essentially be done manually rather than programmatically

Off-site host with port forwarding

Figure 7. User software (host) on off-site platform

Use an existing app to monitor and control the LabJack device, or write a custom app. The app or custom software is then configured to connect to a port-forwarded IP address. For an example of this off-site host platform option, see the ScadaMobile App Note, or this pre-made code example.

Pros

  • Do not have to learn the API of an IoT service

  • Windows, Mac, Linux can use LJM or UD high-level libraries (C, C++, LabVIEW, Python, MATLAB, VB6, .Net, Java...)

  • Android, iOS etc must use lower-level direct Modbus TCP example code. See this pre-made example in Java

Cons

  • Only 2-3 hosts (sockets) can operate simultaneously depending on the complexity and frequency of requests made by each host

  • Requires port forwarding (less secure)

  • Must type public IP address:port into browser unless registered with a domain name

  • Device-to-internet communication cannot be encrypted

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.