Mystery "USB Firmware Updater"

[RavensFan]

You are correct.

I had googled to find the compatibility page, and the way I read the result was that it "started" with 15.5.  But in reality it just happened to be a link showing that 15.5 supported it without really indicating the start of support was much earlier.

(Might still be a good idea to install a more recent version of DAQmx.)

[CoastalMaineBird]

So, I reinstalled NIDAQ 9.8 - no change.

I wiped LABVIEW 2013 and reinstalled - no change.

I was about to reinstall Windows 7 when it told me that the cDAQ 9172 would not work after the upgrade because there was no driver for it.

If I uninstall the "firmware upgrade" thingy, it just keeps coming back.

The Device manager tells me to click a button that it disables for me.

But yet, it installed the updater anyway.

What the heck is it, anyway?  If I'm supposed to update the firmware on the chassis, do I run this thing?  If so, how?  I can't find a file called "firmware updater".

Why did it decide that now would be a good time to do that, after several years of operation?

Here's a movie showing the self-installation:   JING

[CoastalMaineBird · Accepted solution]

For the record, there seems to be a fundamental incompatibility between the cDAQ 9172 chassis and VMs running under VMWare WorkStation 14.0.

I repaired the situation by plugging the cDAQs into an old machine, running Vista and LV2013. The cDAQs had never been attached there.

There, Windows recognized the device as a "USB Firmware Updater" and loaded a driver for it.  Then, a few moments later, it recognized it as a cDAQ 9172, and loaded a driver for that.

Then MAX recognized it, and the modules starting popping into place (in the MAX list).  All without any action on my part.

I plugged the other one in, with similar results. 

Then when I moved them back to my main machine, MAX saw them as cDAQ 9172, serial number xxx, but there was no driver.  A Windows bubble appeared saying INSTALLING DRIVER.  When I looked for details, I saw the list of modules, with each one "waiting", "searching for driver", "installing driver", or eventually "Ready" and all was OK.

Here's a JING of that process.

So, I tested them out and all seemed OK.

Feeling bold, I tried again, this time with a VM running Win7 and LV2013, same as the host machine.  As soon as the connection dialog was answered, MAX on the host machine reported the cDAQs as disconnected (expected), but MAX on the VM reported them as firmware updaters (unexpected).  Whatever damage had been done the first time was done again.

Shutting down the VM left the host in a damaged state.  

I had to plug them into the older machine again, and go through the whole process again.

BOTTOM LINE:  VM's use of cDAQ devices might damage your host setup.

[protocoled]

I just wanted to say thank you for taking the time to document your issue so thoroughly on here. It will be helpful to us moving forward and I will update our documentation with this new information you have discovered.

In general, it does appear NI Hardware is, in general, not supported through ANY virtual machine:

 http://digital.ni.com/public.nsf/allkb/31B0985265CA167886257831003F5536

It is interesting that this caused a corruption of your cDAQ device. It seems that the 'repair' process was simply connecting the device to a secondary machine? I am surprised you didn't need to do a firmware update. Can you confirm that to do the repair you have to use a third machine, seperate from the VM and it's host machine?

[CoastalMaineBird]

I am surprised you didn't need to do a firmware update.

Oh, but I did. I've no idea why.

At least I THINK it did.

Plugging the cDAQ 9172 into a third machine (already equipped with LabVIEW/NIDAQ, but never having cDAQs attached before), the things first appeared as FIRMWARE UPDATER.

MAX showed them as such.

But then, on their own, this changed to cDAQ-9172, after 10-15 seconds.  I presume that it updated something in that time.

After that, MAX started showing them.  This was the first time around. The second time, they were recognized right away, by this third machine.

Then when I plugged them into the host machine, I got a similar response - it was searching for a driver, then they mounted as FIRMWARE UPDATER, then a driver was found (automatically), and then drivers for the individual modules were found.  See the JING I mentioned above, and watch the bottom of the screen.

Given the fact that the updater was mounted for about 10-15 seconds, I assume that some update operation happened.  I don't really know.

It is interesting that this caused a corruption of your cDAQ device.

I'm not sure that it did. I'm not sure that it didn't. The cDAQs didn't need updating after the SECOND corruption, only after the first. But yet, sticking them into the third machine did allow them to work in the host again.  So, I've no idea what really happened.