01-26-2010 09:22 AM
I have to support some LV7.1 programs (along with newer versions). I just bought a new laptop with Windows 7 Home 64-bit. LV7.1 loads and runs, but the drivers disk pukes on the 64-bit OS. (This was not unexpected...)
The new PC does have an Intel processor that will support Windows Virtual PC and Windows XP mode.
Solved! Go to Solution.
01-26-2010 12:17 PM
NI-DAQ will likely install correctly, but you will not be able to interact with any real hardware. Hardware interaction requires the driver to have access to the kernel of the operating system, and in WinXP Mode and any other type of virtualization, the virtualized OS kernel does not interact with the real OS kernel. As a result, you won't be able to use hardware with a virtual OS.
Are you using Traditional NI-DAQ or NI-DAQmx?
01-26-2010 03:02 PM
Thanks for the speedy reply.
I try to use NI-DAQmx, but I won't swear that I don't have traditional DAQ routines out there. I would like to run real hardware (USB DAQ) on my new laptop, de-bug and burn executables.
What are my options? I could keep LV7.1 on my old desktop, newer versions on my new laptop. Would I be running afowl of LV's EULA? Does NI care about antique versions of LV?
I see that NI-DAQmx 9.0 supports versions LV8.2.1, 8.5.1 and 8.6.1. If I put these on my 64-bit, will executables I make run on 32-bit target systems?
I don't want to flush Windows 7 64-bit to install the 32-bit. I want it all!
My company has let my subscription lapse. I don't have LV 2009. Not much chance of an upgrade this year...
01-27-2010 08:37 AM
Good morning John,
Traditional NI-DAQ isn't going to work on Windows 7 64-bit at all, even if you install the (very limited) Traditional NI-DAQ 7.5 beta driver. I don't work with LabVIEW licensing a lot (DAQ is my purview) but my understanding is that you can have different versions on different PCs. If this is the case, then you should use NI-DAQmx 9.0.2 with LabVIEWs 8.2.1, 8.5.1, and 8.6.1. NI-DAQmx 9.0.2 is the first version "officially" supported on Windows 7, both 32- and 64-bit. As long as you are using a 32-bit version of LabVIEW (which, if you aren't using LabVIEW 2009, it will inherently be 32-bit) you executables will run fine.
Note: When I say "As long as you are using a 32-bit version of LabVIEW" I don't mean a version that won't run on a 64-bit OS. This KnowledgeBase article, LabVIEW 64-Bit vs. 32-Bit Applications FAQ, explains some of the difference. The main thing to keep in mind is that because Windows Vista and Windows 7 can emulate 32-bit programs to 64-bit pretty well, you can still use a version of LabVIEW that is only 32-bit on a 64-bit machine.
I don't know how much testing we've done on installing older versions of LabVIEW like 8.2.1 on Windows 7, but I imagine it should work fine. I would recommend this install order:
Hope this helps!
05-06-2011 02:31 PM
I know this is an old thread, but i just had to add Win7 Virtual PC Rocks!! I'm doing just what you were asking about.
I have a customer needing support for a very old version of our sofware. Still using LVTR 5.1 FP3.0 and NiDaq 6.9.1
Up till now I have gone the traditional route and keep an old PC with a PCI-1200 card. But I just baught a new PC with Win 7, XP mode virtual PC
and fired it up, put all the above drivers in it and our old s/w , written in 2002 with XP updates in 2005.
and DOOM! It Works! (in Offline mode of course) Fantastic! I'm sure with the right h/w it would run the instrument too.
But just being able to rebuild the customers s/w and know I had the right drivers is all I needed. And it only uses 2Gb of disk space and 500Mb RAM when running.
I now have an old XP PC with LV 6.1, LV 8.2 and LV8.6 just to support old s/w, But 2010 and RT seemed a bit much to add, pluse I needed to test on Win7 anyway. So I got a Win7 PC and now I can do it all on one PC (!!) with a seperate virtual PC for each LV if I like.
Win7 Virtual PC Rocks!! One of the best things MS has done in a loooong time.
Now we use cRIO (and LV 2010) and I have a new need for a virtual PC. To simulate an RT target. The virtual PC can run any OS that a PC can, so
If the processor in a RT Target is x86 h/w? It seems there should be a way to do this. It would be awsome.
Any ideas? I hope this reply is usefull. Thanx,
05-10-2011 11:38 AM
I like the idea of being able to simulate a RT target using a virtual machine. That would be pretty awesome. It wouldn't really be possible to run a real-time OS on top of Windows though, since Windows is inherently non-deterministic. It might be interesting to see if you can run the Desktop PC Evaluator just to see if it meets the proper specs for installing the Real-Time OS. That can be found here. I have to say again that a real-time operating system isn't going to be supported on a virtual machine, though.
10-05-2012 02:05 AM
To deal with some old hardware, I'm running 32-bit LV 2009 9.0.1 on the virtual XP machine of my Windows 7 Enterprise box. After some messing around I got the hardware working, but now I'm having a strange problem. I want to write the data that the hardware generates directly to the W7 partition, so I can analyze it using my W7 Labview. It's a lot of data, the analysis is slow on the XP virtual machine, and even takes a long time to copy the data from the XP partition to the W7 partition (this is my workaround if I'm stuck with it). I'm having some trouble with some basic file and folder functions though.
I wrote the code pictured in the attachment to illustrate the problem.
If I run this code from the W7 machine, with "stripped path" pointing to my "dataDir" (which is on the W7 partition), it executes successfully in 9 ms.
If I run this code from the virtual XP machine, with "stripped path" pointing to "dataDir", various things can happen. The machine might hang, or return an error after 455653 ms, or execute successfully after 168076 ms.
"dataDir" contains 647,458 files in 900 folders, with 376 GB of data. There are only 15 folders at the root level that will be returned by this vi, however.
If I run this code from the virtual XP machine, with "stripped path" pointing to "smallerDir", where "smallerDir" has less depth and data, the vi executes successfully in, say 10-20 ms, so there's nothing wrong with what I'm trying to do in principle. It seems that this "list folder" function is choking on the deep folder, but I can't figure why it would care.
10-08-2012 11:48 AM
This is a very interesting problem, I am not sure if the folder depth is causing the problems but you might be able to craft a workaround with network shared variables.
You could pass the data over the network with network shared variables and then write it to disk from Windows 7 instead of from Windows XP.
Shared variables resource:
Troubleshooting if problems arise:
I know it sounds weird to pass data over the network from a VM to the host, but if the way you're doing it now is really slow, maybe this is a better option. Hopefully this gives you some more ideas to work with.
10-16-2012 05:19 PM
Is there any possible way to get my DAQMX NI-USB 6008 device to work correctly in XP mode/Windows Virtual PC (host = Windows 7 64 bit)? It is the only H/W device that doesn't work with an abundant amount of H/W USB devices/serial ports. It always comes up with an exclamation point/ Windows -10 error (device couldn't start) in the virtual machine environment, therefore, it is not known to MAX and/or my application.
Ironically, the same DAQMX driver loads correctly in Windows7 however, I can't get my GUI app to load most likely due to some of the objects I'm using (switches/led's) are with NI Measurement Studio 8.6 which, I've been told, are incompatible with Windows 7.
ahh migration headaches <grin>.