In the field of test and measurement we do tons of work with NI hardware and software. Clients often lean on DMC engineers as experts of the NI stack to help them figure out what’s going wrong and how to make things right with their test systems.
Hardware experts don't always have hours of time to invest in staying updated on the latest in LabVIEW like we do at DMC. Understandably, this can result in code that doesn’t follow standard architecture or best practices.
We've seen every kind of graphical code structure under the sun. It takes time to follow the hundreds of wires and many parallel loops to figure out what makes a program behave the way that it does.
Me analyzing LabVIEW code for the first time
Using OpenAI and LabVIEW
Text-based languages have benefitted from recent advancements in tools used to analyze and write code like Python with tools like GitHub Copilot. NI has been hard at work too, as evidenced by their recent demo of Nigel, but they haven’t yet released it.
In the meantime, I thought I could try something rudimentary to achieve a similar outcome using the GPT API from OpenAI with a few tricks to make it work on VI files (files for LabVIEW written in their G language). I wanted to see if I could use GPT to describe LabVIEW code.
Here are the steps:
- Convert the LabVIEW graphical code to text-based code.
- Pass the text-based code to GPT and ask it to analyze the code.
Converting Graphical Code to Text-Based Code
Step 1 basically describes a transpiler which is a compiler that takes code in one language and produces equivalent code in a target language, though as we’ll see that’s easier said than done. For my purposes, I decided to target Python-like code since it isn’t strictly typed and would let me get away with leaving out a lot of information about data types. It’s also likely that GPT is trained on tons of Python code and trying to use a language more equivalent to LabVIEW code would mean implementing more programming constructs in the transpiler or creating a proprietary intermediary language as NI has been doing with Nigel.
The first major hurdle is the fact that LabVIEW code isn’t written as a series of sequential statements. Instead, it is a data-flow language which uses “wires” to transfer information from block to block. This makes it especially great for simple-looking implementations of multi-threaded applications but annoying for our purposes. Luckily, this construct maps well onto the concept of computational graphs and we can try to move from code to a more abstract graph to make our life simpler. We can think of LabVIEW code as a “directed acyclic graph” with a set of start nodes (controls) and end nodes (indicators) connected by edges (wires).
But how do we convert LabVIEW code to a computational graph? Using VI Scripting of course! NI has a library of tools that lets you find all instances of a specified type of LabVIEW programming construct and if we look for all wires and note what pair of objects each one joins, we can build our graph.
We then take the graph and use a custom scheduler algorithm to create a sequence of operations for each of the code blocks and finally use the metadata of each wire’s two terminals to provide some additional data in the transpiled code.
Ask GPT to Analyze the Code
Add in some logic to avoid accidentally using the variable names in multiple places using UIDs and we’re basically done! All we do now is ask GPT to describe the code in terms of what it represents and not the actual variables themselves and we have a crude AI-powered VI analysis tool.
Except that it doesn’t work for:
- For loops
- While loops
- Broken code
- Cases where there are orphaned blocks
- Feedback loops
- Analyzing sub-VIs
- Etc.
You get the idea. Perhaps with a more structured approach to VI scripting and fine-tuning with example code, it might be possible to get more out of this idea, but I think this serves as a useful demo to see what might one day possible!
Learn more about DMC's LabVIEW programming expertise and contact us for your next project.