Six simultaneous DAQmx pulse width measurements using 660x counter/timer card

[schm1347]

Hi -

We have a product in which we do not know when or in what order six pulses will occur (each being on its own channel).  We need to effectively measure the pulse widths in parallel for test.  I'm wondering if there are any limitations to the number of threads one can run at once on the 660x card or in DAQmx.  When running up to 4 pulse width measurements, the results come in immediately when they occur.  However, at 5 or 6 simultaneous pulse width measurements, it appears that 1 or 2 threads don't get executed until some of the other ones have come back.  So it appears that 4 threads run and 2 sit and wait for their turn to run.  Is there any way around this or a recommended remedy?  We are on a tight schedule and are trying to get this system finished up over the next couple days.  We just happened to run into this roadblock.

Thanks

[Matt_W1]

Is there some reason you couldn't collect data from all six channels with one DAQmx task, then just process the outputs for the pulse widths and starting times?

If you want more than 4 threads (Note: I don't think this is the right solution for you)
In the labview directory under vi.lib\utility\sysinfo.llb is thread config vi, which can incress the number of threads up to 8.





Message Edited by Matt W on 12-18-2007 02:11 AM

[samantham]

 Hello,

The 6601 has 4 counters and the 6602 and 6608 have 8 counters.   I am assuming that you have a 6601, since it is only allowing you to run 4 threads at one time.  Please confirm if this is the 660x board you have.

[falkpl]

This is probably a transfer issue, these cards have 3 DMA channels so 3 operations will run super fast (10khz+)  after vthe 1st 3 channels you will run into interrupt transfer of data and your balancing act will begin.  Interrupts are very slow and the more interrupts that are running (i.e. at 5, 6, 7 and channel 😎 your system will slow down and your code might not keep up with the data transfer to ram.  once this haqppens, the buffered data will build up and you will eventually have errors in the additional threads.  Do you capture the error clusters and manage daq errors?  This is just a guess.  if you are doing low speed pulse width measurments continious at <1000Hz or just a finite # of acquisitions then you probably will not be a data transfer limitation due to the lack of dma transfer channels.

Paul

[Kevin_Price]

Tough to be sure -- can you provide more detail and/or code?

From my experience, I'm doubtful that the problem is a limited # of threads available.  Samantha M's reply sounds quite plausible depending on your actual hardware device and how you've put together your program.  Do you have a 6602 to support >4 simultaneous input measurements? 

It sounds like you can vary the # of pulse width tasks to run -- how is this managed at run-time?  Or do you have different programs to support the different # of tasks?  When you have 4 run and 2 wait, is it the same 2 waiting every time?  Could there be some dataflow sequencing causing this?

From the time you want to start your 6 measurements, how long until all 6 should have registered a valid pulse width?  Do you want to wait for them all no matter what?  Have you set your timeouts appropriately?  Are you checking for timeout errors?

See, mostly questions until you can describe things in more detail and, better yet, post the code.

-Kevin P.