PCI 6520 vs PCIe 6351, large delay between channels for 6351

[nyq]

We are replacing PCI 6520 with PCIe 6351. Currently, we found that with the same software (using DAQmx C interface). PCIe 6351 showed a much longer delay between channels (around 500 to 600 us, sampling three channels at 200k/s) while 6520 is much better. The delay between channels was barely noticeable for our applications. Anyone had experienced this and has any suggestion to fix this?

[Kevin_Price]

This doesn't make a lot of sense to me -- can you describe more details?  Here are some sticking points:

1. Delay between channels generally comes up for analog input tasks on a multiplexing device.   Here your base device is a digital-only 6520 so I assume you'd be talking about digital acquisition on the 6351 as well.  The thing is, whole ports of digital lines get sampled simultaneously on either of these devices.  Channel-to-channel delay isn't a thing.

2. Even if you were comparing a digital acquisition on a 6520 to an analog multiplexing acquisition on a 6351, a 200 kHz sample rate allows only 5 usec total summed delay time among all the analog channels in the task.  That's nowhere near the 500-600 you mention.

3. What kind of signals are you dealing with and what exactly is your method for measuring and characterizing the delay you report?

4. Can you confirm whether your "200k/s" is supposed to mean 200 samples/sec or 200 kilosamples/sec?

-Kevin P

[nyq]

Hi Kevin,

sorry, it is PCI 6250. Yes, the sampling rate is 200 kHz. It is strange that the delays were so large. I am collecting resolver signals, which consist of a Sin and Cos waveforms. They are 90 degrees out of phase. But when collecting with PCIe 6351. SIN and COS showed 500 to 600 delays. However, PCI 6250 didn't have this problem. The delay is shown in the following picture. Thanks for the help.

[Kevin_Price]

I can't say what IS the reason for the "wrong" phase shift of the sin/cos signals, but I'm pretty sure that it ISN'T that your DAQ device is sampling both signals at 200 kHz (that is, every 5 usec) while also inducing a 500 usec delay to one of them. 

You should be able to check this pretty easily by swapping which channels you wire your sin/cos signals into.  Your graph shows a Cos signal that leads the Sin by less than 90 deg.  If the DAQ system were the problem, then after the swap it should lead by *more* than 90.  But if the lead remains less than 90, the cause is elsewhere in the signal or data processing chain.

-Kevin P

[nyq]

I am sure it is related to PCIe 6351, just don't know how since PCI 6250 did not have this problem with the same software and configuration. Feeding the same signals to a Non NI card (Alphi IP-AD8250) on the same test computer didn't have this delay either. But AD8250 is a simultaneous A/D card so should not have this issue. We had a second test computer which behaved the same. Right now, I am trying to see whether I could change their input characteristics (like input impedance etc.) of the input source to see whether we could get better results. This is our first attempt to use 6351 instead of 6250 because 6250 is no longer available.

[Kevin_Price]

Same PC as well as same software?  Same DAQmx driver version?

For quite a while now, the default assumption DAQmx will make for multi-channel multiplexed acquisition is to spread out the channel conversions within a sample interval as much as practical.  This give the converter more time to bleed off charge and helps minimize effects of one channel on the next.

    With a 5 usec sample interval, I wouldn't be surprised if the convert clock rate is set such that the Sin and Cos conversions end up > 2 usec apart.  There's a DAQmx property for the convert clock rate that can be queried.  It can also be set when you need more control over channel-to-channel delays.

As I recall, in the early days of DAQmx the convert clock rate wasn't set in a consistent manner from one DAQmx version to the next and I *think* sometimes even from one device to the next.  For example, I recall a version where the default was to set the convert clock to the max rate the device was spec'ed for.  This made for a minimal channel-to-channel delay, but made systems more sensitive to having large signal channels influence subsequent small signal channels.

All this background to say that different DAQmx driver versions might make *some* difference in the delay between the two devices, but it wouldn't be any more different than about 2 usec. 

Try the channel swap experiment and see what you get.

-Kevin P

[nyq]

Hi Kevin,

Thanks for the great information.

No, 6250 and 6351 were installed in different PCs. They were installed in different locations. Same Siemens industrial PCs, same OS, Ni drivers and application software are used but have different external conditioning circuits. We were trying to order one 6351 to compare with 6250 at our location but the delivery time for 6351 would be too long (quoted 30 to 35 days) for the study so we will have to try something else. Definitely would try swap the channels as you suggested.