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