MattWhitlock

Agree with Jason, please post some code and more info. There's no reason the the 9219 cannot do different measurements on each channel, so it's likely a configuration or code issue. I assume you have the module itself configured correctly (right-click the module in the project and do properties). Also, please let us know if you're using cRIO, cDAQ, USB, ENET, or WLS. Thanks, Matt

I've got a couple computers running off SSDs so I'm biased, but my 2 cents: Overall reliability has been a focus of SSD development for quite some time and lifetime should be at least as good as a 7200rpm HD. Warranties and MTBF numbers for SSDs are generally quite a bit better than with HDs. I certainly wouldn't be concerned with write cycles as even under the worst and most contrived circumstances put the write cycle limit at > 10 years. (20GB written to a 160GB Intel SSD every day would wear it out in 5 years) (See link #1). I don't think anything in addition to normal backup procedures is required. I do Mozy.com daily backups with weekly local backups and have zero concerns. (I also use Subversion for version control and Live Sync to keep my computers in sync.) As far as speed versus a regular HD, a decent SSD (Intel, SandForce or Indilinx controllers) is night and day faster. I put a 120GB OCZ Vertex SSD in a 2.5 year old Core 2 Duo 2.0GHz laptop with 3GB ram and it drastically outperformed my brand new quad core i7 2.0GHz, 500GB 7200rpm and 6GB RAM laptop until I shoved an SSD in it. Pay attention to benchmarks of random small block reads of SSDs versus spinning platters to see why SSDs will change your system. Small random reads (loading hundreds of VIs, Windows startup, file searching) 30x to 100x faster with a good SSD. (see link 4) My favorite quote on the issue was: "Someone needs to remind Sandisk that SSD vs HDD is not like Pepsi vs Coke, but more like Dr. Pepper vs Dr. Seuss" In addition to getting one of the "good" SSD drives, you should use a modern OS (Windows 7, recent Linux, OS X 10.6, Not XP) to get TRIM support and do not use an imaged drive. You must install the OS from scratch on a clean drive so that it will recognize that it's an SSD and do the appropriate things: enable TRIM, disable unneeded caching algorithms and align the partition on 4kB boundary rather than 512B. Partition alignment is especially important as it will double performance and reduce wear versus unaligned partitions. Cost is still a factor but Intel is releasing its 34nm flash toward the end of this year which should double storage for the same price. There's too much information out there to put in this post, but here are a few of the most relevant links: Anandtech has the best SSD coverage from a deep technical perspective: 1 - Updated Anandtech article on SSDs 2 - Original Anandtech article on SSDs 3 - Random read speed 4 - Boot time comparison benchmark: 5 -SSD Tweak Utility: (turns off the things that you don't need with an SSD) Can't go wrong with any of these devices: Intel SSD on Newegg OCZ Vertex on Newegg Lot's of info out there to delve into the details, but if you're willing to install a modern OS on a decent drive, it's a dream and the best performance per $ upgrade you can do.

Agreed. Upgrading to a SSD drive is the second best productivity improvement with LabVIEW after a second monitor.

That's great I would like to know what the issue was as I am pretty dependent on virutal machines working so I can develop in the various versions of LabVIEW. I'm a glutton for punishment, so I'll still do my experiment with 2009 SP1.

Wow, I was certain the web-based activation would do the trick. I only have two suggestions to try: 1. Just double-check that you can get LabVIEW FPGA activated on a regular machine (to double extra check that it's not your license # - though that's unlikely to be the issue). 2. Have your local NI salesperson sit next to you while you do the activation steps and make them sit there until the problem gets resolved. Make them share your pain. I know there are things they can do to help that may not be an option otherwise. I'll try installing LV2009 SP1 with FPGA in VMware to try to reproduce your situation and let you know what I find. I usually do Windows 7 x86 virtual machines rather than XP Pro, but I'll try both.

I use VMware for a number of LabVIEW installs but haven't had this particular issue. I think the best work-around is to try the activation process with the option to register via web browser (2nd option in NI Activation Wizard). This will give you a URL to submit your computer's information and it will give you back the proper activation codes. You should then be able to activate it using the last option in the NI Activation Wizard. In early versions of the Alliance program software lease, this was the only method that would reliably activation LabVIEW and I am confident it will work for you. The web activation method should allow you to avoid any weird VMware communication issues, provided you can get the URL to work. Matt

I was a big fan of LabVIEW Embedded for Blackfin and designed a couple custom boards using it. But it appears that it wasn't very popular and is certainly being de-emphasized by NI (didn't realize till today that it had been removed from NI.com, it's only been a couple weeks since I last saw it on there). Last I talked to NI (a few weeks ago) about it, my understanding is that it LBE for BF is getting folded into the Micro SDK. The LabVIEW for ARM product seem is much more in vogue and appears to be getting the additional attention. If I had a legacy investment in Blackfin designs or software, I would try to wrangle with NI to use LabVIEW for Blackfin. If you're not set on the Blackfin family, then I'd definitely go with LabVIEW for ARM. If you want to get your hands dirty in tool chains and C cross-compilers then the Microprocessor SDK is a fine choice for all the other processors. LabVIEW Embedded for * and the Microprocessor SDK are really cool products, just not for the main-stream LabVIEW crowd.