Syncing Counters in "Counter Input Frequency" mode

[michaelboiger91]

Hello LabView Community,

another problem that i can't get solved for some days now...

What i want to do is to acquire rotation speed (frequency) on up to 10 counter channels and analog inputs on up to 15 analog input channels (for that, i have a NI 6602 and a NI 6341 device in a PXIe-1073 system, which provides me 8+4 counter plus 16 RSE analog input channels).

The problem is that i can't find a possibility to synchronize the counters when they are set to Counter Input - Frequency (CI Freq). If i simply place 10 CI Freq tasks into a while loop, it's working, but it isn't really synchronized. In the attachment "Problem.png" you can see a graph displaying all 10 CI Freq channels, all being fed by the same signal generator, and it's obvious they are delayed.

I have read through many posts on the web, and tried to modify many example VI's. The quintessence is that syncing counters works well with a dummy analog task to provide a clock source, using one PFI digital port as a common start trigger. Basically, this is already what i want. But this does only work if i select "Count Edges", if i select CI Freq or CI Period as input, i get an error message at the DAQmx Timing node. The error message tells me that i may not select "Sample Clock" there, but only either "Implicit" or "On Demand". As there is no "On Demand" option in the dropdown menu, i can only set "Implicit", this seems to work only if i use not more than three counters in a loop - and i may not add a "Wait x ms" delay into this loop because then the measurement will stuck on the same value, no matter what the input signal says. However, without a "Wait x ms" delay, the CPU consumption goes up to 100% (you guessed it).

Another idea would have been to take the "Count Edges" function and then calculate the frequency out of that tick count (current tick count minus tick count at t=n-1, provided through a shift register, divided through loop execution time from timer), but this does not work either. It seems that somewhere something is not working fast enough to do this calculation correctly, and even at constant input frequency the indicator still rises quickly instead of remaining (relatively) constant.

Anyway, i think that this task should be designed in a completely different way, and i hope some of you can tell me what i'm doing wrong and how to correct it.

Thanks in advance!

[Kevin_Price]

You have several hurdles to overcome.  Each may be solvable, but you'll be dealing with some unwelcome constraints and complexity.  Consider them, then consider whether you'd be better served with different hardware that eases those hurdles, either 2 more X-series boards or perhaps 1 PXIe counter/timer board that uses the same timing chip & architecture (PXIe-6614).

1. It's my understanding that the X-series boards support a frequency measurement mode with a constant-rate sample clock.  The 660x boards definitely do not (nor do M-series or older MIO boards).   I haven't used this X-series feature and don't know intricate details about how it works, but it seems at first glance to provide an easy way to sync up the sampling with your analog task.

2. When using implicit timing (the only mode you can hope to use with the 6602), you will need to configure an "Arm Start" trigger to set your t=0 time.  Then you can cumulative sum the measured freq intervals to get a timestamp array which can correlate to your analog data, provided it was start triggered from the same signal edge.

  However, I don't think you can configure your X-series counters this way effectively.  The 6602 will buffer its 1st sample on the 1st edge of the signal being measured; the buffered value represents the interval from arm start trigger to 1st edge.  The X-series counters will *NOT* buffer a sample on the 1st edge.  It will buffer its 1st sample on the 2nd edge of the signal being measured; the buffered value represents the 1st *full* interval of the signal being measured.  The implication is that the 1st "sample" for the X-series counter task will correlate to the 2nd sample for the 6602 counter task and the 2nd sample for the analog task.

3. The 6602 only supports 3 DMA channels for high-speed acquisition.  Additional tasks need to be configured to use interrupts instead, greatly reducing the max freq that can be measured.  I am not sure how many DMA channels are available for tasks on the PXIe-6614.  I do know that each of the 4 counters on an X-series board has access to its own DMA channel.

Those are the main things I can think of.  #'s 1 & 2 are solveable but will likely add considerable time to development & debugging.  #3 may not be solveable if your frequencies are pretty high (10's of kHz or higher?).

-Kevin P

[michaelboiger91]

Hello Kevin,

thank you for your detailled answer containing facts that i suppose i never would have found out. I have to admit that i'm struggling to find the relevant informations in the NI product specs.

To keep it short:

* The measuring frequency range is from approx. 10 Hz up to 2,5 kHz.

* As you supposed, syncing counters to a constant sample clock works fine if i only use channels from the X series board.

* This must be because of the NI-STC3 advanced timing/sync/triggering chip, and i'm wondering why they put it on the 6341 card and not on the nearly same-priced 6602, which, as a specialized card for selected purposes, should provide more features for its specific task than a general purpose multifunction card (at least in my opinion).

* Using the Arm Start Trigger, delay between counters is quite low, which will probably be enough for my application (see screenshot)

* I'm wondering about what time-bases are used by the two cards, and whether delay between counters will grow the longer the measurement runs?

* Why is the 6602 satisfied with one single start trigger impulse (and then does continuous measuring),  but the 6341 constantly expects a "Trigger HIGH" state on the Arm Start Trigger button and times out if the latter didn't appear?

* I've read something about a RTSI synchronization cable from NI, but i think that this is already included in the PXIe-system bus?

* Curiously, while running accurately most of the time, at some points single channels of the 6341 produce offsets (see picture). It's always about one single channel. I'm not really sure where this problem comes from, maybe this is due to different timebases for 6602 and 6341? Is there a way to set the counter time-bases to the same size, or could this problem come from the fact that the cards handle buffering differently, as you told?

Greetings,

[Kevin_Price]

Sorry, can't look at your code b/c I'm still on LV2013.  As to other questions/comments:

* The measuring frequency range is from approx. 10 Hz up to 2,5 kHz.

At that top frequency, I think you'd stand a good chance of using interrupts for some 6602 counter tasks.  (Only 3 can use DMA).

* This must be because of the NI-STC3 advanced timing/sync/triggering chip, and i'm wondering why they put it on the 6341 card and not on the nearly same-priced 6602, which, as a specialized card for selected purposes, should provide more features for its specific task than a general purpose multifunction card (at least in my opinion).

When introduced more than 15 years ago, the 6602's timing chip (NI-TIO) offered the best feature set of any of NI's counter/timers.  X-series boards with the NI-STC3 weren't introduced until about 6 years ago.  NI now offers a new-ish 6612 dedicated counter/timer board based on the NI-STC3.  Not sure when it came out, but probably within the last couple years.  It appears to offer 1 DMA channel per counter/timer, so you could potentially substitute a 6612 in place of your 6602 and ease your development & troubleshooting.

* I'm wondering about what time-bases are used by the two cards, and whether delay between counters will grow the longer the measurement runs?

A legit concern and good catch to anticipate this.  If each board uses its own internal timebase, there *will* be a systematic error in their respective measurements of time.  It's quite small (specs are something like 50 parts per million, in practice I've usually seen very much less), but it's still a good idea to drive all sync'ed tasks off of a common clock.  This too will get easier if you use all NI-STC3 counters as you'll only need to share a sample clock, not the raw timebase used to derive it.

* Why is the 6602 satisfied with one single start trigger impulse (and then does continuous measuring),  but the 6341 constantly expects a "Trigger HIGH" state on the Arm Start Trigger button and times out if the latter didn't appear?

Does not sound normal or expected.  Double-check this observation, I'd be pretty surprised if your diagnosis is fully correct.  There's probably some other factor causing the behavior you observed.

* I've read something about a RTSI synchronization cable from NI, but i think that this is already included in the PXIe-system bus?

Yes, the PXI chassis shares RTSI (and other) digital timing signals across all its slots without need for a RTSI cable.  RTSI cables are needed to sync boards in desktop PCs.

* Curiously, while running accurately most of the time, at some points single channels of the 6341 produce offsets (see picture). It's always about one single channel. I'm not really sure where this problem comes from, maybe this is due to different timebases for 6602 and 6341? Is there a way to set the counter time-bases to the same size, or could this problem come from the fact that the cards handle buffering differently, as you told?

I can't identify what you're referring to, so can't really comment.  Both issues (different timebases, buffering behavior with implicit timing mode) are things that would be in effect full-time though, not just occasionally.

-Kevin P

[michaelboiger91]

Hi Kevin,

thank you so much for your detailled answers. It looks like unfortunately i won't get the funds neither for a new 6612 nor some more X series cards (who knew?!) and have to live with what i got.

* ...it's still a good idea to drive all sync'ed tasks off of a common clock.

How do i achieve that? Is it just adding a DAQmx Timing Property Node and selecting a timebase from one of the two cards as SampleClock.Source?

* Why is the 6602 satisfied with one single start trigger impulse (and then does continuous measuring),  but the 6341 constantly expects a "Trigger HIGH" state on the Arm Start Trigger button and times out if the latter didn't appear?

I can't find any causes for that behavior. I've added a very simple VI in LV2013, can't imagine what could be the problem. The acquisition either starts immediately when i do not explicitly select the start trigger type, or will only run if the trigger source pin level is HIGH (no matter if "rising" or "falling" edge is selected).

* Curiously, while running accurately most of the time, at some points single channels of the 6341 produce offsets (see picture)

I've added a second screenshot that points that problem out in more detail. Within the red circles some of the counters (curiously it's just the 6341 counters in 95% of the cases) show delay, respectively different frequency values. I can't imagine why (and why just occasionally), but i think it could be something about the loop duration time. I've tried to fix it to constant 100ms by "Wait ms", by "Wait next ms multiple" and even using a Timed Loop. But, as the yellow graph in the middle of the diagram shows), none of that features works, the loop execution time varies. In some cases the loop even finishes in less than 100ms, which is completely incomprehensible to me because i defined to wait till next 100ms no matter how quickly the code in that loop was finished. I think that as a consequence, some of the counters will take some more (or less) ticks.

Another general question: At DAQmx Read for Counter, i can select "Single Sample" and "Multi Sample 1D DBL". In both cases, i only get one single value, either a DBL for single sample, or a DBL array but with dimension only 1x1. What happens behind the surface? Does the counter task only wait for one period to complete (e.g. counts time between two edges) and then wait for the buffered value to be picked before next measurement takes place? Or does it count as many period durations as possible during the while loop period, and then sends a single averaged value to the buffer when requested? Why is it that i don't get an array with multiple samples, as it is with equally configured AnalogRead tasks?

[Kevin_Price]

1.  Without the option of buying better-suited hardware, we're back to my first post in this thread -- you'll be facing some considerable hurdles in development and debugging.  Unfortunate, but true.

With the 6602, you will not be using anything called a "Sample Clock", you will need to use implicit timing.  I'll recommend you do the same with the X-series board for the sake of consistency.  Yes, there are DAQmx property node settings you can specify to have them both operate off the same timebase, but I think that counter timebase settings are found in channel properties. 

Syncing implicitly-timed freq measurements with analog data will require shared triggering for the tasks.  You'll also need to drive the analog task from the same timebase as the counter tasks.  And you may need to post-process to interpolate because you won't be capturing your measurements at the exact same instant.

And then some of the 6602 counters will need to be specially configured to use Interrupts rather than DMA.  On and on it goes...

2. Still suspcious about your arm start trigger observations -- seems to me that that any such systematic flaw would have been widely noticed and reported before now.  Maybe something you've got is damaged in a subtle way, but it still doesn't strike me as a likely damage scenario.

3. Loop timing variability is unavoidable, largely due to Windows not being a Real-Time OS.   The counters should do all their timing measurements from hardware signals, so they shouldn't care about loop timing.  As to differences in measurements, I can think of three possible sources: the measurements graphed at the same sample # don't always refer to the same interval, the two boards have different quantization effects due to their different internal timebases (a much smaller effect than pictured though), or perhaps the details of how X-series boards calculate Freq in a constant-sample-rate task cause these differences.

4. I can only refer to the latest mini-code you posted that was saved as LV version 2013.  When a task is configured without a call to DAQmx Timing.vi, it will be in on-demand mode.  For a counter task, a subsequent call to DAQmx Read will make it initiate a single measurement and return a single measured value.  That's why it didn't matter which version of Read you selected.

   You'll need to call DAQmx Timing with the sampling mode set to "Implicit (Counter)".  Then it will buffer up a continuous stream of freq measurements that you can retrieve in chunks with the "Multi Sample 1D DBL" read.

   Odds are this lack of DAQmx Timing plays into issue #3 above.  On occasion as you loop through your counter tasks, some measurements are requested just *before* the next freq edge, others are requested just *after* it, causing them to measure the next interval instead.

-Kevin P