driver/LabVIEW version conflicts

[LV_Pro]

I am tasked with deploying a major upgrade/rewrite of an inhouse developed LabVIEW .exe program to a test system that is located at our facility a long distance away (different country) and I won't be onsite to perform/debug the install. Currently it is running a version 8.2 "EXE" and LabVIEW RTE, NI-VISA 3.4.1, DAQmx 8.0.0f0 and MAX v4.0.0.3010. My new program is in LabVIEW v2011sp3, MAX 5.1, DAQmx 9.3.5, NI-CAN 2.7.3. My question is whether installing these updates will cause the existing test system not run, which not a desirable state as it is running production testing and I expect that the software/hardware integration will take longer as I will not be onsite and I haven't had the target hardware here to debug my code on.  Any thoughts or experience in this regard will be helpful. In the last several years I haven't had a similar issue, most of my projects have been either new, or updates in the same version.

As always, thank you in advance.

[crossrulz]

The DAQmx could cause problems for you.

DAQmx LabVIEW Version Compatibility

[LV_Pro]

Yes, that is one of my concerns. I had thought that the program had been done in 8.6, as that is the oldest version we have in our repository here, but had the technician at our other plant used MAX to give me the versions and I was surprised to see it was in 8.2.  Originally I assumed I was going to be making a trip there, but they decided not have me go, so now I'm trying to talk a relatively inexperienced person through installing software, configuring the software and then helping me debug my code, all while working around the production schedule on the existing machine.

[ErnieH]

For situations like this, I have set up a virtual machine with different versions installed. I use Windows 7 and that works well. Then I create and pass an executable to the end user. That way if they they can go back to the old version to keep things running. If you decide to go with 2011, once you upgrade, it is unlikely your old system will work. I would go with a new PC so ,again, they can go back to what worked and not interrupt production.  I also use PC anywhere for remote sites to help with the setup,etc. Also a life saver. Good luck.

[Wart]

If they are running on a PC, and they are in a country that is reasonably easy to import stuff, then I would just ship them a spare PC with DAQ card and your version of the software already installed.  Then they can swap back and forth between PCs.  Bonus points if you ship a KVM switch to make the process easier on them.  If you're on any other hardware it might be cost prohibative to replicate.

If you can accurately replicate their installation locally then you can try putting the two versions of software side-by-side and seeing what happens.  It wouldn't be the first time things worked beyond the published NI charts.

If you can recreate your code in LabVIEW 2009 then you can run DAQ-mx 9.1.1 and both versions are supported.  Once you work out any issues you can move to a more modern version of LabVIEW.  Depending on how complex the code is this might be cost prohibative.

If there is another identical installation somewhere more accessable then you could use that location as a proving ground prior to deploying your code to the location we're discussing.

Just a few ideas to think through.

[John_P1]

I'd expect the built executable (assuming it is a built LV .exe) to still work after upgrading the underlying DAQmx version (unless you have uncovered some odd corner case).  However, when upgrading there is always the possibility of running into issues (even if everything is supported) so if you want to try it I would very strongly recommend making a backup image so you can revert if the upgrade doesn't work out.

If you're using the LabVIEW development environment and just running unbuilt VIs, upgrading DAQmx will uninstall the older version and thus remove ADE support for your earlier version of LabVIEW.  If you know which files to copy you can probably still make it work, but I'd feel less inclined to do this (traceability and such).

Here is a relevant idea exchange that could probably use some more kudos.

Best Regards,

[LV_Pro]

Thank you all for your suggestions! We had also come to the conclusion that building up a second PC here was possibly the best idea, but I was informed this morning that it could take two weeks + to get it there through customs. I also don't have some of the actual hardware that exists on the remote machine, but we might be able to simulate it here, or at the very least, debug it there while still able to revert to the old system to run existing production between bouts of debug.

[Intaris]

---

John_P1 wrote:

Here is a relevant idea exchange that could probably use some more kudos.

Best Regards,

---

Hmm.  I thought your link would point HERE but it didn't.  It could use some Kudos also.

Shane