Back in February I wrote about my new Ford Escape and the massive amounts of testing that must go into verifying features like the hybrid electronics or the SYNC software. Well, Test & Measurement World just named Henry Huang their Test Engineer of the Year. It just so happens that he is the "specialist and supervisor for the SYNC platform QA group" at Ford.
I must be psychic...
Monday, May 16, 2011
Saturday, May 14, 2011
Labview versioning hell
I've been traveling a lot for work the past year or so. A few weeks ago one of the people I work with on the west coast complained about the different versions of LabVIEW (LV) and how they don't communicate well with each other. I brushed it off at the time, but like Chekhov's Gun, this came back to haunt me...
======================
This series of events illustrates a simple question that I doubt has a simple answer. Why can't LabVIEW work like a text-based programming language where you can open it regardless of what programming environment you use? At it's root, code written in C++ or Java is just text, and you can open it in any compiler. You can't necessarily do that with different versions of LV code. I often see requests for reverse compiling in the NI LabVIEW Forums ("Downconver t VI Requests"), so I know this is a common problem. Maybe it's because LabVIEW is not a public language but rather owned by NI? Is it the nature of a graphical language? Is there some other reason? I don't know, but it's really annoying.
======================
About a year and a half ago I wrote a camera program that takes a picture and does some processing of that data. This program runs on a station with LV2009 and NI Vision (v8.5) installed. A couple of weeks ago someone asked to make an executable of this program and install it on another computer. So I compiled the program and then tried to create an installation.
This is where I got stuck in LabVIEW version hell. I could not create the install because (as the NI support people told me) the version of Vision had to match the LV version. My choice was to either a) buy a new copy of a program I already had (Vision), or b) install LV 8.5 and compile with that. So I downloaded LV v8.5, installed that on that computer, then I used LV2009 to downconvert the software to v8.5.
But of course it wasn't that simple. When I tried to compile the install, I got a "data space type map" error and LV crashed. After some digging on the NI Forums I found out that this is a known issue with that version of LabVIEW. The solution was to downconvert to v8.2, and THEN open it in v8.5. BUT, I couldn't do it in my version of LV2009. I had to either upgrade to a later release of LV2009 or do it in LV2010. So I installed LV2010, opened the code in LV2010, downconverted it to LV v8.2, and then opened the v8.2 code with LV v8.5. Finally I created the install.
======================
This series of events illustrates a simple question that I doubt has a simple answer. Why can't LabVIEW work like a text-based programming language where you can open it regardless of what programming environment you use? At it's root, code written in C++ or Java is just text, and you can open it in any compiler. You can't necessarily do that with different versions of LV code. I often see requests for reverse compiling in the NI LabVIEW Forums ("Downconver
Subscribe to:
Posts (Atom)