It’s a setup

Consistency is key, you’ll hear me say that a lot.

I have specialised in working with LabVIEW development teams over the past 18+ years and strongly believe that getting a process in place that encourages consistency is the key to improving quality and delivery performance. Forget banging your fist on the table or screaming at people. Most engineers I know don’t respond well to these “motivational” techniques. Instead, let’s focus on alignment of style, process and structure.

Recently I worked with a client who has several developers all working on aspects of the same project.

They called me in to implement a suite of custom VI Analyzer tests to match items in their LabVIEW coding style guidelines document.

One of the tests I was asked to implement was to check for the terminal style being employed in their code, or rather to check the same style was being used throughout. Unfortunately, on the first run, this test failed. Some code had the terminal view set to icon view and other code did not.

It was quickly identified that a single developer was doing this where other members of the team were not.

“How could this be” was the question from the team leader, “We have a coding standards document”.

She was correct. The team did have a coding standards document and within the document was a guideline to use terminal view (not icon view) but the developer who had used icon view was new to the team and had not yet read the document.  The VI Analyzer tests to enforce these guidelines were not yet in place. (This is a great way of enforcing style BTW)

The use of icon view for terminals is an IDE setting. It’s configured in the Tools > Options > Block Diagram menu of LabVIEW.

On further investigation, it was also clear that different developers had different settings for items such as fonts, alignment grids and most unsettling of all, automatic error handling and separating source code from compiled code.

In additon, change propagation in SVN was driving them insane, they hadn’t figured out that one person’s machine was set up differently.

None of these settings was specified in the aforementioned coding standards document and even if they were, the time cost of setting this up on each LabVIEW installation (these guys use VMs to support multiple LabVIEW versions) would be large.

Sure, they could make the changes to the LabVIEW.ini (Configuration) file and copy that between machines but that’s kinda clunky and unprofessional.

In this case, the ini file keys they were interested in were:




(I love the phrase FancyFPTerms….there’s several funny configuration keys in LabVIEW.ini if you look hard enough)

They could package a master copy of the file using VIPM, NIPM or INNO Setup but again, that would enforce all settings in the ini file and I believe that some should remain specific to the individual. Fortunately, NI provides a library for interacting programmatically with the configuration file and setting specific items.

lvconfig.llb can be found in <LABVIEW>resource\dialog and provides a number of functions for reading and writing string, numeric and boolean values to the ini file and is platform independent so will work even if you have a mix of Windows, Mac OS or Linux installations in your team.

Fortunately, all of the above keys are boolean so it’s simply a case of programmatically setting them once.

A nice thing to do is put this code within a VI Package. This is then easily distributed amongst team members. To get you started, I’ve included an example below that sets the three settings in the above image (VI Package is zipped so needs extracting first)


Now, my client has an IDE Setup that they install for each and every LabVIEW Installation, no more inconsistencies due to individual developers setups.

Now we need to just to get them to all code in a consistent style and follow their own style guidelines and our work will be done, that’s where VI Analyzer comes in. We’ll be talking about that in the coming weeks.

For now, enjoy adding your own settings to the LabVIEW configuration file and setting up new installations exactly as you like them, every time.

Happy wiring


One Comment

  1. Awesome stuff, Chris. I was already intrigued when you showed us the first time at the ALA summit. Definitely a huge timesaver for teams as well as individuals that change setups often.

Leave a Reply

Your email address will not be published.