pci 6154 noise(s)

[photon28]

Have a PCI 6154 board that I'm using with shielded cable going to CB-37F-LP screw terminal. Anyway, I have two noise questions :

1) Is a glitch noise of ~0.04V normal for this board at say ~180kHz? This is the first time we've used PCI S series boards and with the glitch it seems to perform much more poorly than the cheaper NI USB boards we've been using. Waveforms in picture below is a ~3kHz sine wave on slowly rising ramp. Low pass filtering the output hasn't adequately cured the problem.

2) When self calibrating the board also makes an odd audible sound. Sounds like baseball card in spokes for a few, second long bursts. Could be some chain of relays on the board firing off fast but I've never heard this noise from other boards calibrating. Normal?

Wondering if this board is performing normally or not. Self tests say it's fine but it performs more poorly than the other (M and C series) boards we've had and more and more it seems this may be the primary source of noise in our system.

Thanks for any thoughts.

Kregg

[Steve_B]

Hi Kregg,

You are not describing the typical behavior of the PCI-6154. Can you confirm that the device is in a PCI slot and not in a PCI-X slot? What version of the DAQmx driver are you using? Are you looping back the output into an input channel or are you acquiring the data on another device? Your images clearly show the issue and I will take a look to see what I can determine about it. Can you reproduce this on the other channels of your device? Are you running an example or your own code to produce this issue? Let me know if you have some additional background information. Thank you for posting your question.

[photon28]

Hi Steve -

   Thanks for the reply:

1)Am using a standard PCI slot (not PCI express or anything else)

2)MAX says I'm using DAQmx version 8.7.1f2 (installed with the labview 8.5.1 update)

3)The prior images are captured with a 6259 USB (b/c I had it lying around and was hard to loop back only part of the system to the 6154). Signal was after going through shielded NI 1m cable, NI screw pin terminal board, and about a foot of shielded wiring to another connector (no electronics passed through though).

   I'm posting two more images now, both under same settings as above but using the 6154 for input and output. One image is taken with a DB37 connector right at the 6154 board (back of computer) looping AO1 right back to AI0. Second image is the same ports but now with the shielded 1m NI cable also in the loop. Is this size considered 'normal'? Glitch does occur to same magnitude with other channels. Note glitch occurs anytime passing through that voltage level (so it is a glitch).

4)This is my own code. I can attach it later if desired but currently it's a lot of custom code for a larger project. I could boil down something simpler that reproduces it if that helps. (but I'm just doing continuous IO with one output, one input, and simultanteous starts).

Just did another little experiment and if I output just a ramp (no sine wave) get a glitch at multiples of ~0.31V with corresponds to about the 10th bit flipping on a -10V to 10V scale.

   How about the audible noice recalibrating thing? I could be convinced it's a normal thing but haven't heard it on any other daqs recalibrating.

Thanks for any help.

Kregg

[Steve_B]

Hi Kregg,

Thank you for the additional information. Can you confirm that you were testing by generating a 3kHz sine wave with a sample rate of 180kS/s? I would like to isolate the issue from the cabling at this point and perform an internal loopback. The glitching seemed to be reduced when you were performing an external loopback. To perform this test you can use the test panel to generate and acquire your sine wave. You can choose 'DevX/aoY' as your AO channel for your Analog Output tab and for the Analog Input tab you can choose the channel with the name 'DevX/_aoY_vs_aognd'. This will internally route the signal between the pins and eliminate the cabling. Also, can you try changing your AO sample rate to see if the glitches are affected? This can be helpful in characterizing the issue. Let me know how this goes. I will work on reproducing this on my end as well as testing the switching noise associated with the self calibration.

[Kregg]

Will try those experiments it first thing monday (away from instrument today) and get back to you. Sample rate was 180kS/s, sine wave was technically 2.86kHz.

[photon28]

Might need a bit more guidance on the internal loopback. Assumed you meant the test panels in MAX. Tried those but there is no drop down option for the input for anything but ai0, ai1, ... ai3. I tried typing in the strings you suggest (substituting the appropriate values for X & Y of course) in the MAX test panel but it says 'physical channel specificed does not exist on this device'. I tried writing a labview VI instead and using 'DAQmx connect terminals' to route the signals but individual analog I/O channels don't show up as options.

My MAX version is 4.4.1f0

[Dan_K]

Hello photon28,

You might want to check out the following document:

NI Communities: Internal Read of the Analog Output

With a little modification to your specific device identifier you should be able to read your analog output internally without any problem.

[photon28]

Thanks for the help so far Dan and Steve.

Dan, some of your VI was blocked but I hooked up what you showed and filled in from there. Note my 6154 is 'Dev2'.

1) 'Internal Loopback Error VI 1.jpg' shows the results of this. The create task VI throws an error when the shown input (Dev2/_ao0_vs_aognd) is routed to the physical channels or task input. It only runs without error if a value is entered which could be selected from the drop down channel list.

I was going through the labview help file and found "Internal Channels for S Series Devices". This indicates that there are only 8 accessible internal channels on this device and that using them requires first picking a DAC, then switching the input.

2) In 'Internal Loopback Error VI 2.jpg' I tried switching to the internal input you suggest but it throws an error. It runs fine and collects data if one of the 8 listed input sources is used though.

If you want to play with it, here is a vi that reads and writes, simult start, with the DAQmx property node shown above wired up. None of the 8 allowed internal channels allow the input to gather the data being generated. (and again, 'Dev2' references throughout it).

Labview Version 8.5.1

DAQmx 8.7.1f2

MAX 4.4.1f0

If you see anything I should change to make this work, or another way to locate the glitch problem I'm open to suggestions. Glitch noise seems to be the roadblock in our system right now.

Thanks

Kregg

[Mcdan]

Kregg,

I modified your attached VI such that I think it should work for you.  Reading internal channels are a little different on S-Series devices than other multifunction DAQ devices.  If memory serves me correctly, the 6154 is a bit odd in the way it reads analog output channels internally.  The _aoX_vs_aognd input source on the 6154 will connect AO(channel)_vs_aognd to ai(channel).  For example, if your AI.InputSrc is set to AOX_vs_aognd and your AI task is set up to read ai1, then ai1 should be configured to read ao1_vs_aognd.  I hope that makes sense.

I don't have a PCI-6154 at my disposal, so I had to modify your VI using a simulated device, however the programming logic should work for you.

Hope this helps,

Dan

[photon28]

Thanks for catching my DAQ setup error in your mod of the vi.

Pics below show the data with internal routing of signals only (no cable connected to 6154 at all). Ran at 186kS/s for 3 of these runs and tried various sine frequencies on ramps. 1.2kHz and 2.86kHz are shown but the sine frequency didn't affect the behavior much. Sampling rate did affect things though as the 4th pic shows a lot more glitch noise at 250kS/s. The 0V crossing glitch noise is about 5mV for 186kS/s and about 10mV for 250kS/s. Noise was also apparent at about 0.64V level though more like 2 or 3mV at 186 kS/s (0.64 V on full scale would give be about the 11th bit flipping). I tried this on several channels with similar results.

Time to send board back? Is this noise level expected on 6154? Or is it something that can be fixed?

Thanks

ps - looks like I can only post 3pics per post so I'll put last pic in another post

Kregg