PXI-6624 and PFI's

[Kevin_Price]

Once I can see the code, I may have some more to say.  Meanwhile, YES it's possible to decide explicitly which tasks get to use DMA.  (Otherwise, DAQmx will assign it on a first-come first-served basis.)   It's been quite a while since I mucked about with such things, but I'm pretty sure the following will get it done.

The property to set DMA as the "Data Transfer Mechanism" is many layers deep in the DAQmx property tree.  The subsequent call to either "reserve" or "commit" might also be necessary.  Back around 20 years ago when I *was* mucking about with DMA and interrupts, I hadn't yet learned about the DAQmx Task State Model.  So I didn't use that 2nd node, which might explain why I felt like I was merely mucking about rather than being in control.  I *now* suspect it's pretty important.

Use dataflow to make sure your preferred tasks have DMA resources reserved (or committed) *before* any of the other counter tasks are started.

-Kevin P

[SnackNStack]

Good morning,

    All right, attaching our code.  If the password hits you again, it's "root root".  Had a run with this software yesterday.  While our CH 0 and CH 1 still blipped at around 7500 Hz and up, it blipped to max (10000) momentarily instead of zero.  Better for us, but still something to delve into.  I should also add that this run didn't have anything connected to CH's 2 & 3.  They still were allocated for their purpose, but nothing coming in to trigger interrupts or anything like that.  

     When we get some downtime today (it's Friday, every employee there will disappear at noon,) he and I will get into this vi I attached.  I can't say I've seen it yet.

    Thanks again,

      Nick

[Kevin_Price]

The code only shows how the tasks are configured, not how reads are performed, how they're timed, or how data is transferred to the host.  I suspect the "blips" are most likely caused by something downstream of the config.

WIthin the config though, I see that the CI tasks are always set for "Interrupts" as the Data Transfer Mechanism.  That's not helping.

I find another aspect of the config to be unusual.  I'm not even certain I know what to expect from the combo of "overwrite unread samples" and read relative to "current read position".   That *seems* like a recipe for getting out of sync with the data stream (and also out of sync with other data acq tasks).

My recommendations:

1. Change your counter config to use DMA.  Temporarily, only include the 3 unique counter channels in your config file -- this will use up the 3 available DMA channels.  See if that clears up the "blips" and lost ethernet comms.

2. Reduce your read rate to something more like 10 Hz rather than 100 Hz.  Excessive interactions with driver and hardware are a CPU cost with no apparent benefit.

3. Change other parts of counter config to stop using the combo of "overwrite unread samples" and read relative to "current read position".  The better choice depends on your overall app.

    Do you want to be sure to capture all the freq measurements contiguously?  Then stop allowing the task to "overwrite unread samples".  Also, when you call DAQmx Read for the counter tasks, specify the magic # (-1) as the number of samples to read.  This has the special meaning, "retrieve all samples that have arrived since my previous read".   You'll be getting a variable # samples each time you read, so the code needs to be ready for that.

    There are other possible approaches if your needs are something more like, "just tell me the most recent handful of frequency measurements each time I call DAQmx Read.  I don't need a continuous stream."

4. Change config file to allow specification of DMA or Interrupts for each counter task.  Change the code to read that in and configure accordingly.   Add back your 3 redundant counter channels, make sure you only use DMA for a total of 3.

-Kevin P

[SnackNStack]

Thank you, Kevin.  We got sidelined for some higher priority job at the site, so we lost our engine operator for the next few days.  We'll start sifting through the code tomorrow morning and see what we can come up with based on your recommendations. 

It's been about ten years since I've had to modify LabView code.  I've read through the pxi-6624 spec sheet, and have been looking at the NI-DAQmx Overview page, but is there a LabView online code example reference you can suggest?  

Thanks again,

  Nick

[SnackNStack]

Hey Kevin,

    I'm hoping we'll get to run an engine tomorrow, but we tried a couple scenarios with my function generator hooked up to simulate things.  The DMA/Interrupt didn't change too much in terms of dropout (I only had my generator on one channel, so maybe that's why,) but doing away with the overwriting and cutting sampling down to ten per second helped significantly.  Didn't see any drops.  I look forward to seeing how things go in a real run situation.

   Thanks again for all of your help.  

[Kevin_Price]

Interested in what you find.  I'm surprised the change from Interrupts to DMA wasn't a bigger help -- especially when limiting the # frequency channels being captured down to 3 or fewer.

Good to hear that dropping the read rate down from 100 to 10 Hz seemed to help more noticeably.  FWIW, the "overwrite" change shouldn't have affected "blips" and CPU usage, it was more about keeping the data stream gapless and in the correct order.

-Kevin P