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. There are only 15 folders at the root level that will be returned by this vi, however. "dataDir" contains 647,458 files in 900 folders, with 376 GB of data. The machine might hang, or return an error after 455653 ms, or execute successfully after 168076 ms. If I run this code from the virtual XP machine, with "stripped path" pointing to "dataDir", various things can happen. 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. I wrote the code pictured in the attachment to illustrate the problem. I'm having some trouble with some basic file and folder functions though. 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 want to write the data that the hardware generates directly to the W7 partition, so I can analyze it using my W7 Labview. After some messing around I got the hardware working, but now I'm having a strange problem. 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. It would be awsome.Īny ideas? I hope this reply is usefull. If the processor in a RT Target is x86 h/w? It seems there should be a way to do this. The virtual PC can run any OS that a PC can, so Now we use cRIO (and LV 2010) and I have a new need for a virtual PC. Win7 Virtual PC Rocks!! One of the best things MS has done in a loooong time. 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. 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. And it only uses 2Gb of disk space and 500Mb RAM when running. But I just baught a new PC with Win 7, XP mode virtual PCĪnd fired it up, put all the above drivers in it and our old s/w, written in 2002 with XP updates in 2005.Īnd DOOM! It Works! (in Offline mode of course) Fantastic! I'm sure with the right h/w it would run the instrument too.īut just being able to rebuild the customers s/w and know I had the right drivers is all I needed. Up till now I have gone the traditional route and keep an old PC with a PCI-1200 card. ![]() ![]() Still using LVTR 5.1 FP3.0 and NiDaq 6.9.1 I have a customer needing support for a very old version of our sofware. 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 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. 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. ![]() 32-Bit Applications FAQ, explains some of the difference. This KnowledgeBase article, LabVIEW 64-Bit vs. 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. 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. ![]() NI-DAQmx 9.0.2 is the first version "officially" supported on Windows 7, both 32- and 64-bit. 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. 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. 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.
0 Comments
Leave a Reply. |