Design World

  • Home
  • Technologies
    • ELECTRONICS • ELECTRICAL
    • Fastening • joining
    • FLUID POWER
    • LINEAR MOTION
    • MOTION CONTROL
    • SENSORS
    • TEST & MEASUREMENT
    • Factory automation
    • Warehouse automation
    • DIGITAL TRANSFORMATION
  • Learn
    • Tech Toolboxes
    • Learning center
    • eBooks • Tech Tips
    • Podcasts
    • Videos
    • Webinars • general engineering
    • Webinars • Automated warehousing
    • Voices
  • LEAP Awards
  • 2025 Leadership
    • 2024 Winners
    • 2023 Winners
    • 2022 Winners
    • 2021 Winners
  • Design Guides
  • Resources
    • Subscribe
    • 3D Cad Models
      • PARTsolutions
      • TraceParts
    • Digital Issues
      • Design World
      • EE World
    • Engineering diversity
    • Trends
  • Supplier Listings
  • Advertise
  • Subscribe

Free programs with the look of LabVIEW

By Lee Teschler | June 11, 2018

Free programs that seem to behave like LabVIEW engineering software have become available. Here’s what’s behind the user interface.

Leland Teschler, Executive Editor

Since 1986, engineers working in test instrumentation have been able to use a program called LabVIEW developed by National Instruments Inc. LabVIEW is well-known for its graphical user interface which lets users program instrument functions by routing wires between blocks rather than by writing computer code. The procedures written in LabVIEW can be quite sophisticated. They can include, for example, closed-loop feedback and function nodes for controlling devices such as cameras and voltmeters.

The concept of being able to construct relatively complicated test procedures without writing a traditional text-based program is alluring. However, no open-source equivalents to LabVIEW have been developed. That may be because National Instruments has patented many of the concepts underlying LabVIEW.

Nevertheless, one open source program called MyOpenLab has some of the look and feel of LabVIEW. MyOpenLab seems to have been a home project for a programmer in Germany who first released it in 2006. It is now maintained by a programmer in Columbia. It’s following has grown thanks partly to a college professor in Spain who has posted tutorial videos and a number of short online courses that employ the program. (Another open-source program called Pylab-works has a similar look-and-feel but apparently has been abandoned.)

MyOpenLab screen shot

A simple MyOpenLab circuit written to execute on an Arduino. The resemblance of the graphic elements to those in the LabVIEW program are evident. And as in LabVIEW, the user runs wires between elements using the mouse. The wires appear as continuous or dotted to denote different properties.

In particular, MyOpenLab seems to be widely used to develop control programs that can run on Raspberry Pi and Arduino boards. (There is also a LabVIEW compiler available to run programs on the Raspberry Pi. LabVIEW can’t run on Arduino though it can run on a PC and tell an Arduino to perform certain operations.)

The resemblance between LabVIEW and MyOpenLab has led to questions on online forums about how the two programs really differ. The appeal of MyOpenLab is easy to understand. A basic license for a seat of LabVIEW starts at about $400 annually and goes up from there. There is a hobbyist version available called LabVIEW Home Bundle for a one-time fee of $50. But it is clearly labeled as being for “noncommercial, nonindustrial, and non-academic purposes.”

Though MyOpenLab may behave a bit like LabVIEW, it is based on Java and has an internal structure that is completely different. It is worth investigating the internal architecture of the two programs to see how they compare.

Difference between LabVIEW and MyOpenLab

LabVIEW is built using a concept called data flow programming. The formal explanation of data flow programming is that its applications consist of numerous processes that exchange data through a series of connections. An operation runs as soon as all its inputs become valid. Moreover, the processes can be reconnected to form different applications without undergoing any changes internally.

A simpler explanation is to recall the workings of the most widely used flow-based programming application: the spreadsheet. Each spreadsheet cell is a process. Connections between cells take the form of the equations and cell references within them. To reconnect the cells in a different way, the user writes different equations with different cell references.

LabVIEW can be visualized as operating in a similar way. Instead of spreadsheet cells, it uses rectangles to represent processes. Connections between processes take the form of wires. (Another widely used analogy is to view LabVIEW as working like a flow chart, again with wires forming the connections.)

The terminology for the LabVIEW programming model is more complicated than that of a spreadsheet. Whereas a spreadsheet program has individual worksheets, the roughly analogous structure in LabVIEW is a virtual instrument (VI). Each VI consists of a block diagram, a front panel and a connector panel. A VI that calls or makes use of another VI does so via the connector panel. The front panel is built using what are called controls that supply information to the VI and indicators that display results based on the inputs given to, and the internal processes of, the VI.

The block diagram contains structures and functions which perform operations on controls and supply data to indicators. Collectively controls, indicators, structures, and functions are referred to as nodes. Nodes connect to one another using wires. Thus, in a spreadsheet, a cell can be defined to display the addition of two other cells; in LabVIEW, two controls and an indicator can be wired to an addition function so the indicator displays the sum of the two controls.

The spreadsheet analogy with LabVIEW breaks down with regard to virtual instruments because a VI can not only run as a program, but it can also be dropped as a node onto a block diagram of another VI. One advantage of this approach is that each VI can be tested in a modular fashion before being embedded into a larger structure.

The simplicity of building programs by dragging and dropping VIs has benefits. But when the functions to be implemented are complex, the construction of LabVIEW programs may require an extensive knowledge of LabVIEW syntax and memory management topology.

Once the hierarchy of VIs is complete, the resulting LabVIEW code gets compiled into executable machine code.

MyOpenLab screen and connections

A front panel created in MyOpenLab and the corresponding connections on the worksheet. Elements for the worksheet get selected from the library area located in the upper left of the screen.

MyOpenLab has an architecture that is not oriented around flow programming; it is what’s called event driven. In event-driven programs, events determine the flow of the program. Typical events include mouse clicks, key presses, and messages from other programs. Perhaps for obvious reasons, graphical user interfaces typically are built around event-driven architectures.

The typical approach to implementing a program that responds to events is to build in a main loop that listens for events in a way that is analogous to that of industrial programmable controllers. When the program senses an event, it runs an event handler routine. In the case of event-driven programs for GUIs, the event handlers typically look for mouse clicks and keystrokes. In the case of MyOpenLab, we might surmise event handlers look for wires pulled between blocks, inputs to block functions, and so forth.

Though MyOpenLab is built around an event-driven architecture, LabVIEW can also implement event-driven actions. It does so via an “Event” structure. Here, the structure term refers to graphical entities that control how and when code runs. In this sense, LabVIEW can be viewed as a hybrid between a data flow program and one that’s event driven.

Readers might note that the looping and event handlers in an event-driven program sound a bit like the role played by routines in flow-based programs that look for changes in inputs. The analogous function in a flow-based program is called a scheduler. The scheduler decides whether to do something with the list of connections between the blocks. An important difference between an event-based program and a data-flow program is that the scheduler in a data-flow program doesn’t do any looping. It only runs when there is data to work on and somewhere to put the output. Generally speaking, this structure lets flow-based programs consume less run time than event-based programs.

To be clear, the “looping” in this discussion takes place internally within the software. Both LabVIEW and MyOpenLab can be used to create multiple information loops, stacked sequences, and so forth. But these loops are constructed by the program user.

MyOpenLab is written in Java. Java is a compiled language. Java applications are typically compiled into bytecode that then runs via another program called a Java runtime environment. It, and another component called a Java virtual machine, typically come as part of a Java development kit. The point to note about all these Java components is that they are free, like MyOpenLab itself.

Simple vs. sublime

One reason for comparisons between LabVIEW and MyOpenLab is that the two programs have analogous functions in their user interfaces. In MyOpenLab, the drawing area is called a circuit panel. The program also has a front panel. Where LabVIEW has virtual instruments, MyOpenLab has visual models. In MyOpenLab, the user presses button icons for actions such as starting and stopping the simulation, stepping through sequences, showing data tables, adjusting simulation time, and so forth. To make connections between component blocks, the user marks the output with a click of the left button and then marks the corresponding entry of the selected component block.

Because MyOpenLab is in Java, it’s possible to modify the Java code of a component. It is not clear from its documentation whether MyOpenLab can accept or work with routines written in languages other than Java. In contrast, LabVIEW can call and execute code from several languages as well as DLLs.

The means of running code written outside the main application illustrate the differences between LabVIEW and MyOpenLab. LabVIEW is a more complete and mature program. One indication: The manual detailing just how to use external code in LabVIEW runs 302 pages. Documentation for MyOpenLab consists mainly of 10 user guides each on the order of 60 pages long and written in Spanish. (Google translate seems to do a decent job of translating these into understandable English.)

That said, LabVIEW programs can grow to become quite complex if the task at hand is complicated. And the creation of sophisticated LabVIEW programs seems to require as much expertise on the part of the programmer as any other advanced language.

Consider, for example, comments on the LabVIEW Wikipedia talk page where Wikipedians discuss edits to the article at hand. The talk page for LabVIEW has a lengthy section on criticisms of LabVIEW and whether specific criticisms should be included in the LabVIEW Wikipedia article. Many of the criticisms take the form of, “You can’t do X in LabVIEW,” and are written by practitioners who have a substantial history with the program. As often as not, other practitioners chime in pointing out that LabVIEW can indeed do X. But the how-to explanation is either buried in the rather extensive LabVIEW documentation or is laid out in terms that aren’t exactly clear.

Of course, MyOpenLab doesn’t incorporate any of the advanced programming features about which some Wikipedians griping on the LabVIEW talk page seem unaware. Thus the clearest delineation between where each of the two programs fit is in the difficulty of the application. LabVIEW will continue to make sense for handling knotty instrumentation and control tasks. MyOpenLab could be a candidate for simpler uses. DW

References

We are indebted to Rich Brueggman, Certified LabVIEW expert and founder/CEO of Data Science Automation in Pittsburgh, Pa., for his suggestions and sanity checks during the writing of this piece. www.dsautomation.com, 724-942-6330.

You Might Also Like


Filed Under: Data acquisition + DAQ modules, Software • simulation, MOTION CONTROL, Motion control • motor controls, Mechatronics, TEST & MEASUREMENT
Tagged With: nationalinstruments
 

LEARNING CENTER

Design World Learning Center
“dw
EXPAND YOUR KNOWLEDGE AND STAY CONNECTED
Get the latest info on technologies, tools and strategies for Design Engineering Professionals.
Motor University

Design World Digital Edition

cover

Browse the most current issue of Design World and back issues in an easy to use high quality format. Clip, share and download with the leading design engineering magazine today.

EDABoard the Forum for Electronics

Top global problem solving EE forum covering Microcontrollers, DSP, Networking, Analog and Digital Design, RF, Power Electronics, PCB Routing and much more

EDABoard: Forum for electronics

Sponsored Content

  • Sustainability, Innovation and Safety, Central to Our Approach
  • Why off-highway is the sweet spot for AC electrification technology
  • Looking to 2025: Past Success Guides Future Achievements
  • North American Companies Seek Stronger Ties with Italian OEMs
  • Adapt and Evolve
  • Sustainable Practices for a Sustainable World
View More >>
Engineering Exchange

The Engineering Exchange is a global educational networking community for engineers.

Connect, share, and learn today »

Design World
  • About us
  • Contact
  • Manage your Design World Subscription
  • Subscribe
  • Design World Digital Network
  • Control Engineering
  • Consulting-Specifying Engineer
  • Plant Engineering
  • Engineering White Papers
  • Leap Awards

Copyright © 2025 WTWH Media LLC. All Rights Reserved. The material on this site may not be reproduced, distributed, transmitted, cached or otherwise used, except with the prior written permission of WTWH Media
Privacy Policy | Advertising | About Us

Search Design World

  • Home
  • Technologies
    • ELECTRONICS • ELECTRICAL
    • Fastening • joining
    • FLUID POWER
    • LINEAR MOTION
    • MOTION CONTROL
    • SENSORS
    • TEST & MEASUREMENT
    • Factory automation
    • Warehouse automation
    • DIGITAL TRANSFORMATION
  • Learn
    • Tech Toolboxes
    • Learning center
    • eBooks • Tech Tips
    • Podcasts
    • Videos
    • Webinars • general engineering
    • Webinars • Automated warehousing
    • Voices
  • LEAP Awards
  • 2025 Leadership
    • 2024 Winners
    • 2023 Winners
    • 2022 Winners
    • 2021 Winners
  • Design Guides
  • Resources
    • Subscribe
    • 3D Cad Models
      • PARTsolutions
      • TraceParts
    • Digital Issues
      • Design World
      • EE World
    • Engineering diversity
    • Trends
  • Supplier Listings
  • Advertise
  • Subscribe
We use cookies to personalize content and ads, to provide social media features, and to analyze our traffic. We share information about your use of our site with our social media, advertising, and analytics partners who may combine it with other information you’ve provided to them or that they’ve collected from your use of their services. You consent to our cookies if you continue to use this website.OkNoRead more