migration to LabVIEW

[ElectroLund]

Given the latest CVI news, I'm now seriously considering migration to LabVIEW for future projects, while keeping CVI around for maintenance of old projects.  While daunting a proposition, there are some benefits that I would be eager to realize:

• DIADem looks to be super powerful.  I basically made my own lite version of this a couple years ago, having discovered the TDMS data file format and realizing how much potential there was for data plotting.  It's a tool that I'm very proud of, one that we use across several products, used by several departments.

But DIADem has even more power, with query capability and reporting.

• Test Stand - I've built so many test executives in CVI over the years. I'm basically the only one here that can manage this task, so I'm very spread thin.  If we brought in something like Test Stand so that other less-experienced engineers could start doing some of that work, that's actually a win for me.
• LabVIEW - This has been an interesting bit of tribalism in my company's site. Some of the (now retired) old timers were adamantly anti-LV.  They were consummate software types, believing that the only good application was written in Notepad and checked into some CVS.  LV was seen by them as a non-controllable, bug-prone antithesis. It smacked of antiquated thinking, probably due to getting burned by it at some point and never looking back.

But again, I'm the only person here that full time develops & maintains CVI apps.  If I could spread the development time among 3-4 people, such that they all could confidently get an app off the ground from start to finish... that again is a win for me, not a threat.  

Case study: Recently my manager asked for help on a very small temperature sampling project with a little LabJack based sensor.  Super easy.  Log temperature to file, receive barcode scanner inputs, create a log file, plot data.  And yet for me, with over 10 years CVI experience, this project took about 10-20 hours total, making prototype, testing, refine, add some more features, bug hunting.

I have to believe that this same project could have been done quicker and by more people in LV, particularly since there are a much broader array of LV drivers in the industry for instruments.

[TestEngineer11]

Hi Electrolund,

Might I suggest a third route? When I worked for a large defense contractor, they were heavily invested in the NI environment. We used TestStand as the executive (with some custom 'Process models' - which are just TestStand sequences that control executive functioning). 

Most of our code modules at the company were either CVI or LabVIEW. But, there was a group that handled development of a common test framework, with the goal of getting everyone onto a standard executive architecture and UI. They used C# for all their work, and it looks like that is the direction the company was eventually going (especially given the demise of CVI). 

C#/.NET fully integrates with the NI environment and is supported by the TestStand API. It is syntactically very similar to C, but with the bonus of being modern and object-oriented. The TestStand/C# combo is a great way of being able to remain in the NI environment (take advantage of all their drivers, libraries etc...) while also having the full power of the .NET framework at your disposal for things like GUIs (See WPF framework) etc... Plus TestStand is a very powerful test executive with an extensive API. It is certainly the industry standard "out of the box" executive for test automation. 

It is a good solution if you are not wanting to have to go the LabVIEW route. For me, it was a bit of a learning curve to move from C to C# (and from CVI IDE to Visual Studio), but you pick it up quickly. And like I said, in terms of interoperability with the NI environment, you are not really losing much, since almost every NI driver or library has a C# implementation. You are more "on the hook" for some things like UI design, since CVI provides that stuff right out of the box, but that kind of thing shouldn't be a huge impediment. 

PS: Another test automation framework to check out is the OpenTAP framework from Keysight. It is fully C# based. 

[TestEngineer11]

CORRECTION:

Not every driver or library is implemented in C#, but plenty are. And those that aren't can be implemented yourself.