vibration related shutdown on USB DAQ-6215

[ambient]

We're using a DAQ-6215 and DAQ-6210 to control and log data from a small, single-cylinder engine.  We are experiencing a strange fault that seems to be vibration induced.  The DAQ will spontaneously shut-down at engine speeds above about 4000 rpm independent of whether they're connected to the various servos and sensors .  The shut down is catastrophic usually causing the application software to hang and resulting in XP reporting  a "USB Device not recognized" error message.  The USB light on the DAQ is dark after this happens.  Sometimes it is necessary to reboot the host PC to clear the error, sometimes simply pulling the USB connector is sufficient to clear the error.   I've opened the 6215 and there's nothing obviously unfastened. 

Does anyone have any knowledge of what can cause this sort of failure?  We're now looking at ways to mount the DAQ on a vibration-isolated platform but volume is very limited.

john

[AnalogKid2DigitalMan]

Can you hang the device in free space in a similar poximity to the engine and replicate the fault? If it does, then another possibility may be that the spark plug firing is inducing electrical transients in the device or the USB cable.

Message Edited by AnalogKid2DigitalMan on 10-15-2007 01:57 PM

[ambient]

Actually, we'd experienced flakey servo operation six or seven months ago that was traced to ignition noise.  At that time we did some very through shielding, grounding and bonding including the ignition wire itself, so i don't think that's the problem.  The only thing that seems repeatable in causing the shutdown is engine rpm.

john

[preston_johnson]

What analysis on the PC are you doing.  Is this LabVIEW?  Perhaps there is some form of divide by 0 error that is not being caught. 

[ambient]

There's no analysis being run in the LabVIEW routines.  The LabVIEW does three basic functions:  generates a 100 Hz pulse-width modulated stream for servo activation, takes a pulse input from the engine and measures/displays/logs the pulse reptition frequency as a tachometer, logs inputs from two sensor classes--thermocouples and DC voltages (0-10 volts)  from several transducer types.  The LabVIEW code performs without error when the DAQ are driven by simulated sources and under actual testing conditions at low RPM.  The failures occur even with all external connections (except the USB) removed from the two DAQ and seem to correlate only with engine RPM.  

My underlying question is what sort of failure mechanisms exist that can cause these USB DAQ to shut down under vibration?  Some more clues are that when immediately before shut down occurs the duty cycle on the servo output is set to 50%--causing potentially  dangerous Wide Open Throttle engine operation and that the data logging is stopped prior to showing the increase in engine speed. 

Any more thoughts?

john

[Paul_C.]

Hi Ambient,

Are you able to run the application without the motor connected and verify that the program doesn't crash when you generate the pulse-width modulation for 4000 RPM?  This would allow us to see if it is in fact the vibrations from the motor that are causing the problem or something with the application.  In regards to AnalogKid's suggestion, I'm more curious to know if the DAQ card is actually connected in some way to the motor or seperated from the motor by some distance (such as suspended from the ceiling).  Could you provide more details on the setup?  I don't know of any specifications for how the USB DAQ will react under such extreme vibrations.  I would only assume that it wouldn't function properly.  If the DAQ card is connected direcly to the motor, do you have some type device to isolate the DAQ cards from the vibrations of the motor?

Thanks,
Paul C.

[ambient]

Please see my previous reply regarding ignition EMI.  The throttle servo is, by far, the most sensitive element in the system in relation to EMI.  Prior to the application of the extensive bonding, grounding and shielding, the servo was unstable at any engine speed.  That is no longer the case. 

In the absence of engine vibration, the control and logging system is completely trouble free at any speed over the engine's operating range from 1000 to 10000 RPM.  We  observe stable servo operation at all throttle settings and simulate the tachometer pulses with an external signal generator.  If we operate the engine at speeds above 4000 rpm under manual control of the servo, there are no EMI effects in the servo operation, but the DAQ do crash even with no connectons to the engine. 

At the present time, we do not have an accelerometer on the engine mount so I cannot estimate the actual vibration level.  It is typical of a single cylinder engine, though.  If you think of the performance of a mid-sized chain saw engine, that is the general vibration level of these engines.

john

[stilly32]

Hi John,

We tested the USB-621x to standard PXI vibration levels:

PXI shock and Vibe ratings:

Operational shock ........................... 30 g peak, half-sine, 11 ms pulse

(Tested in accordance with IEC-60068-2-27. Test profile developed in accordance with MIL-PRF-28800F.)

Random vibration

Operating.................................... 5 to 500 Hz, 0.3 grms

Nonoperating.............................. 5 to 500 Hz, 2.4 grms

(Tested in accordance with IEC-60068-2-64. Nonoperating test profile exceeds the requirements of MIL-PRF-28800F, Class 3.)

From your description it's hard to tell if you're exceeding those or not. If the device LED is dark then it indicates a loss of power - its possible the device is just loosing contact with the USB connection. Are you using the strain relief? I would also recommend not mounting the device directly to the machine if at all possible. Just as a test, if you hold the 621x in your hand but still near the machine while ramping up the RPMs do you see the same behavior? This would give us a better idea as to whether it is the vibration or the EMI - though I agree with your analysis that EMI is the less likely culprit.  

Hope this helps,

Andrew S

MIO PSE

[ambient]

Thanks for this reply,  This is just the information I was looking for regarding failure mechanisms.  The USB cables to the two DAQ are secured with cable clamps to the same mounting surface as the DAQ. so very, very little or no relative motion between the DAQ and the connector is possible.  Your comment on loss of power has caused us to think about  the rest of the path from test stand to the host PC.  There is a powered hub in that path, but no one can remember whether or not it's mounted to test stand.  This is something we'll be looking at later this morning.   If multiple, short power interruptions occurred--like from a vibrating USB connector--could this cause the USB stack in XP or the USB interface to crash?  Could the same multiple quick operations confuse the boot routines in the DAQ to the point that removing power (pulling the connector) would be required to restart it?

One question about your operating vibe spec: Am I correct in interpreting this as a random-vibration spec with constant PSD between 5 and 500 Hz and RMS value of 0.3g? 

john

[Paul_C.]

Hi John,

I'm afraid we don't spec our cards for how they will behave during short power interuptions.  I could only assume that it would disconnect power to the device and cause various other occurances.  As for whether multiple power disconnects might be putting the USB device into a unknown state, I do not know. 

In regards to your second question,  I do not know off the top of my head if the IEC-60068-2-64 standard uses a constant PSD.  I would only assume that it does.  This information should be available within the standard.  If you would like, I will look more into it to verify.

Regards,
Paul C.