LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Broken VIs when opening a LabVIEW 2018 project in LabVIEW 2019

I have a really old LabVIEW project written in LabVIEW 2014 however when I tried opening the project in LabVIEW 2014 I got the error: "File version is later than current LabVIEW version". So I found that you can open it in a later version and "save as previous version". So I opened in my latest version of LabVIEW (which is 2019) and saved it as LabVIEW 2014 project. While saving I noted that certain VIs could not be found ie. AI waveform Scan (scaled array).vi, after some research, I found the problem was this project is very old and used the Traditional DAQ.

 

So I tried a few variations of LabVIEW versions and VMs until it got to:

 

  • Creating a Windows 7 32Bit VM running LabVIEW 2014 32bit
  • Installing the Traditional DAQ and locating the missing VIs

 

This seems to work until I ran into more issues after attempting to build the project. I got a lot of the following errors:

 

  • Recursive reference in non-reentant VI
  • Wire has loose ends
  • You have connected two terminals of different types
  • Bad linkage to subVI
  • LabVIEW subroutine link error
  • Object code is not loaded
  • SubVI is not executable etc.

 

I think this maybe have been caused when I save the project as the previous version from LabVIEW 2019 to LabVIEW 2014, I also notice a little later that when I got the error: "File version is later than current LabVIEW version", the version it was previously saved in was LabVIEW 2018. 

 

Looking at some of the advice from the other forum topic where re-write the project to use updated DAQmx however due to the nature of this I can only make minor changes to the code, a complete re-write of the DAQ interface to use DAQmx is not an option. 

 

So the above is the background my questions are:

 

Is there any advice or thing I need to consider when saving projects from a later version to an earlier version of LabVIEW? 

 

Is it possible that saving projects from a later version to an earlier version of LabVIEW could have caused the errors listed above?

 

Any other advice would also be appreciated. 

 

 

 

0 Kudos
Message 1 of 6
(829 Views)

I recall learning LabVIEW with LabVIEW 7.0, and being handed a large existing (and "mostly working") LabVIEW Real-Time Project that used Traditional DAQ (DAQmx was not yet present, I think).  The code was a little buggy, slow, and bloated.

 

I made a real effort to understand Traditional DAQ.  We got some new PXI hardware, and I tried to update the DAQ, no success.  Called a local LabVIEW Expert to help me understand the Traditional DAQ code, didn't help.  Decided to upgrade to LabVIEW 8.something and try DAQmx.

 

So much simpler!  So much more robust!  And this was before the White Paper "Learn 10 Functions in NI DAQmx and Solve 80 Percent of your Data Acquisition Applications" (find it on the Web, just ignore the first point talking about the Dreaded DAQ Assistant!).

 

My advice -- Byte the Bullet and switch to DAQmx!  Move to Windows 10.  Move to a recent version of LabVIEW.  If necessary, hire a Consultant.

 

Bob Schor

Message 2 of 6
(815 Views)

As best as I can see or remember LabVIEW 2014 does not support traditional NI-DAQ, so the code would not have been written in LabVIEW 2014. NI-DAQ was replaced with DAQmx in the early 2000s. Do you have the original source code (not the version that someone opened in a later version and saved, but the source code control version that hasn't been touched)? 

 

In any event, I agree with Bob_Schor that you would be well served to upgrade to DAQmx. What will happen when you have hardware failures and cannot get hardware that is compatible with traditional NI-DAQ? Do you really want to have to go through a development cycle while the system is down? Do those who are telling you to only make minor changes understand the potential consequences to continuing to use obsolete technology?

0 Kudos
Message 3 of 6
(800 Views)

Inheriting old projects are a unique challenge.  You never know exactly what you're going to get until you take the lid off and poke around inside. 

 

I think Bob gives some great advice.  Had something similar in my own experience around 2004 or 2005 I think.  

 

Inherited a project where the Traditional DAQ that had been used didn't quite work.  DAQmx was the newest thing, and everything I was reading was telling me to go that way.  But the only other LabVIEW guy at work didn't think that was way to go. 

 

Eventually I replaced the DAQ section of the code with DAQmx.  It worked so much better than previously, that all of our LabVIEW projects switched after that.  

 

In your case, I think it would help you a lot to try and open an unaltered version of your inherited code in the version of LabVIEW it was programmed in. 

 

However, LabVIEW 2018 is not compatible with Traditional DAQ.  You have to go all the way back to LabVIEW 8.6 for that.  

 

See:  https://www.ni.com/en-ca/support/documentation/compatibility/17/traditional-ni-daq--legacy--and-labv...

 

Somewhere there should be a LabVIEW 8.6 (or older) version of your code.  Ideally, find THAT version...before someone opened it (and then saved) in LV 2018.  

 

This could be quite a bit of work.  If your DAQ tasks are not that complicated, it will probably be easier to just isolate them and replace them with DAQmx.  

 

There is some documentation on transitioning here:  https://www.ni.com/en-ca/support/documentation/supplemental/06/transition-from-traditional-ni-daq--l...

---------------------
Patrick Allen: FunctionalityUnlimited.ca
0 Kudos
Message 4 of 6
(796 Views)

@pallen wrote:

However, LabVIEW 2018 is not compatible with Traditional DAQ.  You have to go all the way back to LabVIEW 8.6 for that.  

 

See:  https://www.ni.com/en-ca/support/documentation/compatibility/17/traditional-ni-daq--legacy--and-labv...

 

Somewhere there should be a LabVIEW 8.6 (or older) version of your code.  Ideally, find THAT version...before someone opened it (and then saved) in LV 2018.


What I did was take the VIs from a LabVIEW 7 install for Traditional DAQ and stripped out all of the DLL calls.  This enabled me to see what the old code was doing while I upgraded to use DAQmx and LabVIEW 2014-ish.  The results can be found here: https://forums.ni.com/t5/LabVIEW/Modifying-old-VI-for-LabVIEW-2015/m-p/3370067#M992248 


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 5 of 6
(790 Views)

FYI I was able to get Traditional DAQ to continue to work in LabVIEW 2011, after I had to update some code written in 6.1 originally.  So while 8.6 might have been the last supported version, it isn't impossible to go beyond that.

Message 6 of 6
(738 Views)