Matthew Zaleski

Posts 7, 8 and 9 from me in this thread give the solution that worked for me. I have not had reason to re-install LV2009 on my Win7 machine so I don't know how much those instructions can be simplified. Suffice to say I really don't understand why it was so difficult to get it installed.

Off topic but Tom's Hardware recently crushed the performance of the video you saw: 3.4 GB/s Sorta on topic, be very careful about the brand and model SSD you buy. There are a ton of useless drives that shouldn't even be sold. The good ones like Intel, Samsung, OCZ are insane performance coming from the world of spinning disks. I have an OCZ Vertex 250 GB drive. With 512 KB blocksize (reasonable for your data acq I/O), the drive averaged 145 MB/sec reads and 185 MB/sec writes. It could keep that up all day since the blocksize you are writing is >= to the internal flash blocksize.

In general you need to know what is your frequency range of interest. If the data contains usable frequency content from 0 to 3 Hz, then applying a 5 or 6 Hz lowpass filter should help. But sometimes your frequency of interest is not near 0 Hz. In those cases, look at passband or highpass filters. Your initial post seems to indicate you may need a notch filter (60 Hz noise from electrical?).

Essentially, this is how MKS Integrity implemented their Requirements Solution. Integrity allows multiple issue types, each with their own list of fields and states they move through, AND they can link from one issue type to another. I'm getting ready to add the Requirements Management Solution to my MKS Integrity installation. The whole package ain't cheap but I've yet to find a freebie solution that comes close to its power. I think the MKS website itself is a piece of **** though. It has all the hooks for building Requirement Documents from all the little Requirements and reusing Requirements from previous projects.

My post just prior to yours was full success. I'm running LabVIEW 32 to actually do my work. I only installed LabVIEW 64, based on other suggestions in the thread, in order to get all of the hardware drivers loaded. I doubt I will ever use LabVIEW 64 2009. It looks like it is only good for NI-Vision work; No other modules are supported. It looks like the 3.2.1 install/upgrade doesn't play well with a 3.2.0 install. Now I'm just beating my head against the wall trying to get the FPGA to compile; Doesn't want to fit in 3 MGate anymore I'm beginning to think that each new version of FPGA compiler becomes LESS efficient at using slices. Are the NI-FPGA and Xilinx boys taking lessons from Microsoft Windows? It's funny that you say the cRIO is far too expensive. Compared to equivalent hardware from non-NI companies: it's the cheapest. I do agree that there are other cheaper solutions but we needed the rugged external i/o without requiring continuous connection to a PC.

I just put a OCZ Vertex 250 SSD in my home machine. Holy Cow! LabVIEW starts up fast and even a big project loads faster than I can get a cup of coffee. Now I just need to get my work machine upgraded (spending freeze with the economy, go figure, hehe).

I attacked the problem again tonite. Using the logic of a computer scientist, I uninstalled all NI-RIO stuff, rebooted, then re-installed NI-RIO 3.2.1. The project is now working. It shouldn't be this difficult...

It took me longer than expected to reload Windows 7 64-bit RTM. I ended up doing the following: Installed LabVIEW 64 by itself (since it isn't on the DVDs afaict) Ran normal DVD installer and picked all the toolkits for which I have licenses. The installer seemed to recognize the existing LabVIEW 64 and automatically activated the appropriate entries for it along with LabVIEW 32. Reboot Ran the NI-RIO 3.2.1 installer from NI.com Reboot Opened my project and went to the CRIO FPGA node I'm further along than before since Realtime nodes are now recognized. But LabVIEW still thinks I don't have all my files. Look at the screenshot: I tried rerunning NI-RIO 3.2.1 and picking all the options. It resulted in a no-op and didn't see the need to install any files. A google search didn't give me any useful hits. Any suggestions?

Hrmm, interesting. I didn't try the "Run as administrator" option. I expected that as a Vista aware installer it would elevate itself properly. I am installing the LabVIEW 32 bit and the driver installers realize I have a 64 bit OS and pick the 64 bit drivers. From what I could find on the web LabVIEW x64 doesn't have any toolkits other than Vision. I need Realtime, FPGA, Advanced Signal Processing, the trace toolkits, etc. From that info, I determined that what I need to install is LabVIEW x32 on my Win 7 x64 machine. Is that an incorrect conclusion? The signed drivers may be an issue. I'll give that a try this weekend too. I did see the installer status mention driver signing for each driver. However, since it was the installer mentioning it, I assumed that NI had signed all of their drivers. Regardless, I'm glad to see there is proof that I should be able to install LV2009 on Win7 x64.

That is a good suggestion. I did a variation on that. I re-ran the setup last night with compatibility mode Vista SP1. I chose that because I need the installer to realize it needs to install 64-bit Vista drivers. Again, I got the same failure as before. I think I will be forced to install LabVIEW into a virtual machine in VMWare. It will take a few days but I will get VMWare running, install Win7 32 bit and then see if LabVIEW is compatible with that. If that doesn't work, then I'll install Vista in a VM. It really shouldn't be this many hoops. Win 7 is really nothing more than an optimized Vista kernel with some new UI tricks. I installed plenty of Vista drivers in Win 7 early on in Win 7 testing when native drivers were much rarer. My gut feeling is that NI's installers are doing queries that are looking for Vista-specific identifiers rather than querying for "must be Vista or newer". There have been several articles in the Windows 7 developer blogs talking about how there are many programs and installers using poorly designed OS detection methods. On the flip side, it looks like NI is using an MSI installer which is supposed to limit the chance of this occurring.

I know it's not officially out yet. But I'm attempting to install the 32 bit edition on my copy of Win7-x64 (Release Candidate); I've downloaded Win 7 full release via my MSDN account but haven't loaded it since it will wipe my hard drive. It looks like nearly every 64 bit driver is failing during the install and rolling back. Given that LV2009 supports Vista 64 this shouldn't be happening. Vista drivers generally work well in Win 7. There isn't any error codes beyond a "failed to install XXX x64, do you wish to continue with rest of install?". Does anyone know of a workaround? A google search came up with no good hits.

QUOTE (crelf @ Apr 8 2009, 02:28 PM) I think the underlined should read "optionally doesn't even install MAX". It looks like you are able to create a custom installer with exactly the components you want.

QUOTE (Neville D @ Apr 8 2009, 12:53 PM) Thanks for the tip. I've sent an email his way. QUOTE (crelf @ Apr 8 2009, 01:16 PM) I'm not in front of my system at the moment, so this might be a little rusty: when you're in the build installer dialog, and you select DAQ as one of the things to install, there is an option in the top right where you can select between 5 types. From NI's website: There's a table on ni.com somewhere, but I can't find it right now. Thanks Chris. I've bookmarked that NI page for further review. I think that will at least let me get the right drivers on the laptops accessing the cRIOs without the user wading through that massive list of choices.

QUOTE (Neville D @ Mar 24 2009, 06:41 PM) That's unfortunate. Does anyone know if the NI-MAX CD/DVD installer can be fully scripted to only install the drivers I know are needed and not ask the user any questions? And can NI-MAX itself be driven by a LabVIEW app to do all of the necessary driver updates of a cRIO target? I need a way of automating this. My users don't know, nor do they want to know, how to configure the gobs of settings needed to support a cRIO target. And as I mentioned before, these units are now deploying worldwide; I can't walk up to them to update the software.

QUOTE (NeilA @ Apr 6 2009, 03:43 PM) Welcome to the world of XML. What MJE is telling you is that you did a deliberate override of the namespace for the UUID element (you gave it the namespace "http://RMS/"). Therefore /soap:Envelope/soap:Header/UUID/UUID will fail at the first UUID element since it isn't in the default namespace within the XML. I'm not familiar with the namespace "http://RMS/". Did you make that up? If so, modify your XML header: <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rms="http://RMS/"> and add that rms: prefix to your UUID element in XML file. Then the following XPath will be valid: /soap:Envelope/soap:Header/rms:UUID