USB-6218 with a High Freq/ High Voltage Motor Drive

[andyh]

I'm using a USB-6218 to acquire data from instrumentation that is attached to a high speed motor test rig (temps, displacement, speed).   The motor is a 32 kW, asynchronous inductive motor.  The motor is driven with a Sieb & Meyer FC80 (http://www.sieb-meyer.de/sieb-meyer/en/produkte/frequenzumrichter/FC80/index.php).  This is a relatively high frequency, high voltage asynchronous motor drive.  The 6218 is located about 5 feet from the Seib & Meyer drive.  I'm running labview 8.6 on a Dell laptop that is located in an adjacent room.  Everything works when the motor drive is not running the motor.  The problem I have is when the motor drive is running, Labview will freeze and the computer no longer recognizes the USB-6218.  The problem does not occur every time, or at any predicable frequency.  It does occurs often enough that it is a big problem.  I am forced to ALT+CRTL+DEL out of labview, unplug and replug the USB-6218 into the computer and start over.  It appears that something is causing the computer to think that the USB-6218 is OFF.  The result is identical if you unplug a 6218 while Labview is running.  I have all instrumentation grounded to the same power supply.  Is the problem excessive noise on my analog inputs or from the motor’s magnetic field, or RF noise from the drive?  It would be difficult to move the 6218 away from the test rig, but it can be done if necessary.  I’d rather figure out the cause of the problem first before I tear everything down and move instrumentation.

[RavensFan]

All most certainly due to EMI coming from the drive.  The drive almost certainly has a base frequency of 3 -6 kHz.  And it can radiate that strongly enough to interfere with other cabling.

The first thing I would check is to put an oscilloscope on the analog wires going to your USB-6218 and see if you get any high frequency noise on that.

I'm not sure why LabVIEW would freeze, unless the DAQ functions you use are waiting for data from the USB device that has disappeared and all other code in you program is waiting for the data to be returned from the DAQmx functions.  That or the noise coming in from the USB cable is not just screwing up the reading from the DAQ device, but also the basic operation of the PC.  Does everything else on the PC seem to run normally while LabVIEW appears frozen?

[andyh]

I was incorrect in saying Labview freezes.  The VI that is reading from the USB-6218 goes haywire.  I recieve all NAN on my anolog inputs and the code becomes extremely sluggish. The easiest thing to do is kill the VI with ALT+CRLT+DEL.

I failed to mention another detail.  I am trying to run a second VI at the same time.  This VI controls the Seib & Meyer motor drive via serial port communication.   This VI does not have any problems when the USB-6218 goes haywire.  We have tried running the serial communication code from a second PC to determine which VI has the problem.  The problem only occurs when both the USB-6218 and the Serial code are running from the same PC.  The Serial communication does not exhibit any problems when the USB-6218 goes haywire.

I have run serial communication VI's and DAQ VI's simulaneuously before.  I only have this problem with i combine all 3; serial communication, USB-6218 and the high freq motor drive.

[johnsold]

Like Ravens Fan, I suspect that your problem is EMI or possibly a ground loop.  The USB-6218 is isolated.  I think that means that the signal inputs are isolated from the USB ground.  If your 32 kW motor drive is inducing significant currents (perhaps on the order to 10s to 100s of mA) into the USB cable, the OS could lose communications with the device.

You indicate that you are getting NaN from the device. That suggests that the subVI is still running.  Are you getting any error messages or timeouts? Specifically what error messages?  Have you put any indicators on loop counters or state selector lines to show what is happening in your code when it gets sluggish?  What is your code architecture?

Lynn

[andyh]

The architecture can best be described as "amateur".  I'm a self-taught Labviewer, and for our needs around here, my limited knowledge has been sufficient.  This application seems to be reaching my limitations.  Any suggestions on the code structure is welcomed. Thanks.

[RavensFan]

Actually, your code looks quite good.  There are a few things that could be improved.

1.  Replace the old file open/close functions with the new versions.  If you do that and a little bit of rewiring, you can completely eliminate the stacked sequence structure.

2.  The index array function is expandable, so you don't need two or more of them to get out multiple elements.

3.  In the DAQ VI, you could wrap up the waveform manipulations and Mean calculations in a For Loop and use auto indexing on the output.  If you reorder you DAQ task just right, you could easily do that and order the outputs in the same order that your later graph and write to file can use.

Back to the problem at hand:

You said, "The problem only occurs when both the USB-6218 and the Serial code are running from the same PC.  The Serial communication does not exhibit any problems when the USB-6218 goes haywire."  So if the serial code is running on a separate PC from the DAQ code, then the DAQ code runs okay?

I think you'll definitely need to do what you can to move and isolate the USB DAQ device.  Perhaps even mount it in its own metal box and ground the metal box.  Is the motor controller in the open or in its own control panel box?

If you find that the serial communication is somehow affecting or being affected by the EMI, then try putting an isolator on the serial wiring.  I would also recommend lowering the timeout on your serial communication from 10 seconds to something like 2-3 seconds.  Basically just a little bit longer than whatever your expected time is between when you initiate a read and expect to get the data back.  No reason to wait any longer than necessary for data that is not coming.  On your DAQ side, you may want to lower the timeout value as well from the default 10 seconds.  It won't work any better, but it will come back quicker with an error if the USB gets lost and not seem as sluggish.  Also put an indicator on your Error Out wire from the DAQ assistant.