Crashing Labview

[pallen]

Hello fellow wire workers. I've got a bit of a problem DAQmx...at least I think that's what it is. I can't tell for sure because LabView is crashing completely when I get to the State that's in the picture.

Is this because I've got two tasks running essentially at the same time?

This was a problem with my analog acquisition at first. Then I configured a task to acquire on two channels and just split the data afterwards. Unfortunately I don't see a way of adding a digital input to an analog task.

If I can't include the digital input in this state, I'm not really sure how else I can capture the trigger.

[gleichman]

You can't acquire analog data in multiple instances from the same hardware as you have discovered, but there should not be a problem with your seperate analog and digital calls. A few follow up questions:

What DAQ hardware are you using?

Is LabVIEW crashing or is your program hanging?

Have you tried execution highlighting to pinpoint the problem?

Have you verified the trigger with a scope? (Is it waiting for a trigger that never comes?)

Have you tried the program with the digital part removed?

Good Luck,

Alan

[pallen]

Thanks for the reply.

The DAQ hardware is a USB 6008.

It appears to be LabView itself crashing. Windows shuts it down and asks if I want to send a "report" to MS.

I haven't tried highlighting the execution yet. But because of the way things are timed in this application, it wouldn't be an entirely accurate picture of what's happening when the code is running at full speed. Definitely part of my troubleshooting plan though.

The trigger itself is working. Its been verified in MAX as well as code snippets.

The acquisition of the two channels simultaneously works fine in that state without the digital input there. I've been thinking about how I might monitor the digital input in another while loop if I have to. I was just wondering if there was something fundamentally wrong with what I was doing in the code. The documentation doesn't seem to say so. But I thought I'd ask around.

[gleichman]

Thanks for the reply.

The DAQ hardware is a USB 6008.

I've recently worked with USB 6008's and I had problems with analog and digital together. My system used (5) USB 6008's and LabVIEW would hang about every 10 or so executions. Here are a few suggestions:

Install motherboard specific drivers for your USB chipset.

Remove other USB devices (mouse?)

Don't use a USB hub. Connect directly to the USB port on the back of your computer. (Although a hub worked better for me than PCI-USB cards.)

Acquire your digital data on an analog channel.

Revert back to NIDAQmx Base 2.0?

I hope one of these will help.

Alan

[pallen]

Thanks for the suggestions Alan. This is the first time I've worked with USB DAQ devices.

Originally we were using a PCMCIA 6024E card for this project. But we switched to USB to save $$. But if we're going to run into problems with different target PCs it would be better to find out about it now rather than later.

Unfortunately the laptop I use for development has limited driver support and I have noticed stability problems before with USB webcams.

It bothers me a little to hear that USB hubs can be a problem. We'd hoped to package USB key or alternative storage device for data storage or perhaps even to house the executable code itself.

I need to take a closer look at exactly how I'm building my state machine too I think. But switching that one input to analog shouldn't be too much of a problem if it's necessary.

Thanks for the reply.

[Irene_he]

I've recently worked with USB 6008's and I had problems with analog and digital together. My system used (5) USB 6008's and LabVIEW would hang about every 10 or so executions. Here are a few suggestions:

Install motherboard specific drivers for your USB chipset.

Remove other USB devices (mouse?)

Don't use a USB hub. Connect directly to the USB port on the back of your computer. (Although a hub worked better for me than PCI-USB cards.)

Acquire your digital data on an analog channel.

Revert back to NIDAQmx Base 2.0?

I hope one of these will help.

Alan

USB hub should be no problem as long as it's self powered, not bus powered.

I think NI USB 6008 and MCC USB daqs are using HID class, which is the same class for mouse, keyboard etc. Maybe that's why you suggested to remove other USB devices (mouse?), because they may affect the performance of the HID based USB daqs. I used one of them before from MCC, it hangs/freeze the computer once in a while.

Our iUSBDAQ uses microchip general class, not HID, so far we haven't experienced any hanging or freezing of computer. Maybe you would like to take a look?

http://www.hytekautomation.com/Products/IUSBDAQ.html

Thank you.

Irene

[AnalogKid2DigitalMan]

pallen:

You mentioned that you were switching to USB to save $$. Be careful, I have looked at the specs of the 6008/6009 and I am not too impressed with the analog inputs, they have an input impedance of only a few hundred kohm. Some people have ran into problems saying their measurments were innaccurate- it turns out that the analog inputs were loading down their circuitry. No counter/timer support and software timed analog output too on the 09, I believe.

You may want to look over the specs of the USB devices before commiting to them. Granted I have never used one, but have heard other people issues and some have had to go back to traditional cards (PCI, PCMCIA)

[Neville D]

pallen:

You mentioned that you were switching to USB to save $$. Be careful, I have looked at the specs of the 6008/6009 and I am not too impressed with the analog inputs, they have an input impedance of only a few hundred kohm. Some people have ran into problems saying their measurments were innaccurate- it turns out that the analog inputs were loading down their circuitry. No counter/timer support and software timed analog output too on the 09, I believe.

You may want to look over the specs of the USB devices before commiting to them. Granted I have never used one, but have heard other people issues and some have had to go back to traditional cards (PCI, PCMCIA)

I have used the USB 6015 with 5 analog Input chans with no problems. I am using an old Toshiba laptop which has only 2 USB ports, so I have the DAQ connected into a powered hub, with a USB mouse, and a USB-Serial converter on the other USB port direct to laptop.

It all works like a charm; the 6015 is like an E series card but running off USB. Works great.

Note that the USB DAQs use interrupts and not DMA for data transfer and this may affect speed.

Neville.

[pallen]

Thanks for that info.

The low impedance might cause some problems here as I'm measuring from an amplifier connected to film type pressure sensor. I'm not certain yet. But I believe I was seeing a much higher signal to noise ratio than I had on the original hardware.

1000 samples over one second on two channels is the most I need to ask from this system. Although I do need to monitor that digital input while this acquisition is happening.

We did read the specs before we bought the unit, and it appeared to be capable of the job. But there have been a few "weird" things I've noticed since I started with them. The most annoying was not being able to close an opto relay with a digital output in the way we always have. I wouldn't think much current would be required for that. But apparently it was too much. The only way around it was to follow the "open drain" example in the documentation and essentially wire things "backwards".

Tomorrow night I'll have some time to play with this system again. If I can't find a solution, I'll at least try to better document my failure.

...that sounds like a quote!