« Close

Datasheets and User Guides

App Notes

Software & Driver

 

Appendix A - Diagrams

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.

 


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
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

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.
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

Figure 3. T7 script interacts with IoT service

Develop a Lua script that opens a connection to a IoT service and then communicates with it.  This would require some special Lua functionality that we have not implemented at this time.  NOT SUPPORTED.

Pros

  • Use REST interface of any IoT service
  • Does not require port forwarding (good security)
  • T7 Lua script initiates/maintains a connection to the IoT service
  • The IoT service is robust enough to handle any number of off-site platforms performing simultaneous access
Cons
  • Custom application code must reside in the Lua script (limited code space)
  • User must learn the API of the IoT service
  • T7 only
  • Unable to use LJM or UD high-level libraries or other languages than Lua
  • User must learn the API of the IoT service, typically a REST API
  • Lua Script must parse/convert the IoT TCP communications into LabJack device communications, and vice versa (limited code space)

 

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. Easily purchase server space on Linode.com, or a similar provider.

Pros

  • T7 Lua script does not have to poll a REST API on the IoT service, which allows for faster command/response times, nor does the script have to parse/convert IoT communications into T7 instructions, this process is handled by software running on the IoT service.
Cons
  • Requires port forwarding (less secure)
  • Custom application must reside in the IoT service, or in the Lua script (limited code space/flexibility).
  • For extensive custom operation, must create your own IoT service.
  • T7 only
  • Requires port forwarding (less secure)
  • Must type public IP address:port into browser unless registered with a domain name

Figure 5. T7 as web server

Write application software in Lua on the T7, and upload a custom webpage to the T7 that displays the result of the Lua script. Very limited features/flexibility/extensibility, but extremely stand-alone.

Pros

  • Stand-alone operation, few parts
  • Do not have to learn the API of an IoT service, the T7 has it's own REST API.
Cons
  • Very basic operation only. e.g. view 4 analog voltages, control a few digital I/O on/off.
  • Must fit/store entire webpage on T7s memory (which is limited)
  • Custom application code must reside in the Lua Script (limited code space)
  • T7 only
  • Unable to use LJM or UD high-level libraries or other languages than Lua
  • Requires port forwarding (less secure)
  • Must type public IP address:port into browser unless registered with a domain name

 


 

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
Cons
  • Typically only one off-site platform can connect at a time
  • Android, iOS are less convenient

 


 

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

Simply 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