Maximum read/write latency for PCI-DIO-32HS using NI-DAQmx?

[AliasMe]

Thanks Chris and John for this info.

I believe that changing to an M series board will not be a problem on this project.  I also like the idea of going with PCIe, as I believe that PCI is essentially deprecated on Macs -- trying to look to the future a bit.

However, project constraints mean that it won't be possible to use LabView.  I'll have to use the C interface to NI-DAQmx.  Additionally, my experience with LabView is measured in mere hours, so porting anything complicated could prove difficult for me.

Every 10 ms the hardware generates an interrupt, at which time the software must read three sets of encoders and tachometers, compute some stuff, then write three command values -- basically closing motor control loops.  A couple other bits may need to be read/written as well.

Additionally, two other interrupts are generated every 48 ms each.  I believe they are out of phase by 180 degrees (I'll have to check on this to be sure), so it's effectively an interrupt every 24 ms.  At each interrupt, 256 16-bit values must be read from the hardware (they are clocked in over the same 16 pins).   These values eventually percolate up to the application layers.

I realize that these times are very slow by today's standards, but it's critical that we don't miss any interrupts, and I worry about achieving that requirement from user space code.

[John_P1]

Hi AliasMe,

I hope all is well.  While this may be feasible with an M series, keep in mind that your loop rate is at the mercy of the OS, so there can be no guarantees.  Chris's application used a Real-Time controller to ensure the 1 ms loop rate. 

Having said this, 10 ms should not be unheard of on a standard PC for single-point reads and writes (assuming the "compute some stuff" part doesn't consist of anything too complicated).  

The potential problem I see with this is that the correlated digital inputs of the M series (port 0) share timing circuitry.  So, you can't have different lines acquiring at different rates based off of a HW-timed signal.  You might be able to do static digital I/O on the 10 ms lines and clocked digital I/O on the others, but then we run into the problem of synchronizing your software loop with the 10 ms hardware interrupts.

The M series devices also have two on-board counters that may be of use, but without more information about the big picture I can't say for sure if they would be of benefit.  If possible, could you post a timing diagram and any additional information that you have that you think might be helpful.  Based on what you've said so far, it is very likely that we do have hardware/software that is capable of what you need, but I'd like to narrow it down before making any specific recommendations.

-John