Multiplexing error

[geddavis]

I'm having a problem with collecting voltage data from 3 channels of a USB-6009. Using a simple vi, where I've used DAQassistant to create 3 channels; the data is collected continuously at 1KHz. The channels are then spilt and displayed on 3 separate waveform charts for channel 0, 1 and 2. When I put a sine wave into channel 0 and run the vi it appears in channel 0. If I stop the vi, using the stop button, and restart the vi, the sine wave appears in one of the other channels. When I stop and start the vi the output channel jumps randomly. I can recreate this inside DAQassistant by clicking on the run button and the using ABORT instead of stop. When the DAQ is restarted the input channel has switched to one of the other channels. What I imaging is happening is that the multiplexer is not resetting itself to TRUE channel 0 before starting to collect samples, it is considering the channel that it is pointing to at that moment to be channel 0.

Attached is the vi I have put together to explore this problem.

To my question(s). What is going on with the USB-6009?

and, perhaps more importantly,

How can I prevent it occurring?

Thanks

Ged

[Hillman]

Hi Ged,

Thanks for your post and I hope your well today.

Generally hitting Abort isn't advisable - as you can see, it can cause strange behavior and issues with Data Acquisition.

However, you can reset the device using a LabVIEW VI or in Measurement and Automation Explorer (MAX). If you start your LabVIEW code with a reference to the dev, or example Dev1 and then wire it to the input of the DAQmx Reset Device.VI it will return the device to an initialized state. You should then be able to keep the rest of your code the same - remember to make sure that the Reset is done first and not during, otherwise you will get resource errors.

To find the vi just perform a search by right-clicking your block diagram and type in DAQmx Reset. 

Please let me know if this helps at all with the error using seeing, 

Message Edited by Hillman on 03-11-2009 02:15 PM

[geddavis]

Hi James,

Thanks very much for your quick response. That was the vi I was looking for. However, the problem remains. 

In the Test vi, I have put the DAQmx Reset Device outside the loop and used the error cluster to ensure that it is executed first. I believe this is what you suggeted. 

Some additional background that may be relevant. I'm using LabVIEW 8.5 for windows xp. The windows opperating system is running on a MacBook with and Intel processor. Windows is accessed via VMFusion software.  I hope this is not an issue with the normal communication with the USB-6009.

Yours

[Hillman]

Hi Ged,

Good Morning and I hope your well today.

Genereally NI doesnt support the use of VMware because there are issues with if the sofware maps the ports correctly, usb& PCI. This is because the software ist designed for data transfer between the software layers for such measurement devices - but more designed for keyboard and mouses which a far lower amount of data to send. 

I would recommend trying the code if possible on a standard Windows Machine and see if its works, and then is there any reason your not just using the Mac OS?

Also, if you could send me the code I will try it (if you prefer on my windows machine) and let you know,

Thanks, 

[geddavis]

Dear James,

Thanks for your reply. I will run the vi on a native Windows machine - but that will have to wait until next week when I am back in my own lab. Do you know if I access Windows via Boot Camp, would that remove the data transfer issues you believe are occurring? 

Thanks for your time and thoughts

Ged

[Hillman]

Hi Ged,

Thanks for your update and I hope your well today.

I am unsure whether boot camp would resolve the issues. I would firstly suggest trying it on the native windows machine and then maybe look into the support for running windows on the mac - if it supports the high usb transfer rates.

Please update me next week on your findings - i'd be very interested in the results..