Error - 200141 occurred at Counter - Read Pulse Width and Frequency (Continuous).vi

[cthunterMC]

Situation: Per this instruction I have been using the example Counter - Read Pulse Width and Frequency (Continuous).vi (2 edge separation tab) and continue to run into Error - 200141.

Mission: I need to be able to continuously record and log delta time between rising edge of two separate pulses (PFI10 and PFI9 inputs on PXI-6221/SBC-68)

Execution: The error seems to be after the I have only completed CORE1 and am a novice. What is the minimum delay between rising edges that the 6221 will register? I also have 5122 (digitizer) and 5170R (scope) in this chassis. Would these be better suited for my setup? 

Hardware:

• PXIe1082 chassis
• PXI-6221
• SCB-68

Software:

• Labview 2018 Full Development System
• Counter - Read Pulse Width and Frequency (Continuous).vi

First Input Terminal (PFI10):

• Pulsed waveform
• Period = 5 us
• Amplitude = 3.5 Vpp
• PW = 200 nsec

Second Input Terminal (PFI9):

• Same as above except 3.0 Vpp and 500 nsec delay

[Kevin_Price]

I don't know enough about your digitizer or scope cards to comment on their suitability.

You may be approaching the sample rate limits for counter measurements with your M-series device.   Here's one good discussion I found that referenced a system-dependent benchmark of 380 kHz sampling for an M-series counter task, and you're aiming for a nominal sample rate of 200 kHz.  Also read through the comments found below this example.

The core reason for this limitation is the tiny 2-sample onboard FIFO of the device, which puts a big demand on the PXI bus to keep transferring data off the device and into PC memory almost instantly.   Newer X-series devices support very much faster sampling rates due largely to the much larger 127-sample FIFO. 

Another common reason for -200141 errors would be a noisy digital signal that registers multiple transitions where there should be just one.  I would have thought that 2 Edge Separation measurements would be less susceptible to this due to having two distinct inputs defining the start and end of each interval.  But I don't know that for sure.  It'll be worthwhile to make sure you have good clean digital transitions from your input signals.

Sorry, I think all I've got is commentary, probably not a specific solution.

-Kevin P

[cthunterMC]

Thanks for the input. After further research I was able to use a DAQmx with the 6221/SCB-68 and the edge counter configuration. As long as my pulses are 1.5 Vpp, delta time can be calculated. The next phase is amplification through a set delay and then converting tdms log files to excel. Thanks again!

[cthunterMC]

Kevin, thanks again for the help. One more question,  it looks like the 6221 sample rate is 250 kS/s. When I look at the timestamped sample rate in the attached VI, it looks like I'm only getting 30 S/s. What can I do to increase the sample rate to at least 200 kS/s? I have attached output data as well. Thanks!

[Kevin_Price]

The 250 kS/s spec is probably for analog input.

With 2-edge separation measurement, you should set up DAQmx Timing to be "Implicit", which means that the effective sample rate will be determined implicitly by the timing of the signals you're measuring.

I'd recommend you use regular DAQmx functions to give yourself more control over your task.  You can copy / paste from the shipping example I recommended in another thread as a pretty good head start.

BTW, I find that a lot of people that are somewhat new to counters assume they need a high sample rate to make sure they "see" all the edges of interest.  That's frequently not the case.  There's a distinction between the count register, which increments in hardware, and sampling, when the instantaneous count value is passed along to your task buffer.

For buffered 2-edge separation measurements, the board will count cycles of a high speed internal timebase (probably 80 MHz for your M-series device) starting on receipt of the 1st edge you specify.  When the 2nd edge arrives, the count value will get "sampled" and passed along to your task buffer, the internal count will reset to 0, and the counter will be armed to repeat that process again starting with the next 1st edge.

-Kevin P

[cthunterMC]

Attached code as requested. I tried to recreate your code from this thread as suggested. I continue to get the attached error. Thanks!

[cthunterMC]

Just to simplify what I am trying to accomplish, attached is a quick snapshot of my setup.

[Kevin_Price]

I made a few fairly minimal mods to your code to try to fix it.  This should work, or at least be really close.  The main change is to configure a Two Edge Separation task rather than a Period measurement task.

Compare it to your prior version, ask questions as needed.

-Kevin P

[cthunterMC]

Almost there! Just two quick questions.

1. I reconfigured the VI so that I can control runtime in seconds. Why am I getting twice the samples/second (Example: 1 second runtime * 200k sample/sec = 400 samples?). 

2. In my spreadsheet, the timestamp in column A does not correlate to actual test time. Why is this? 

See attached for test data and updated code. Thanks again for all the help!

[Kevin_Price]

1. It's a dataflow issue.  The "Elapsed Time" evaluation is free to execute *before* your task has completed.  So it'll quickly evaluate as False early in the first iteration and then (probably) evaluate as True early in the second.  Meanwhile, you're doing a 2nd acquisition of 200k samples to make a total of 400k.

2. You haven't provided any timing information to the file writing vi.  To a fairly large extent, you *can't*.   That's the essential meaning of "Implicit" timing for many counter measurement tasks.  The timing isn't preset or known, it's an *outcome* based on the characteristics of the input signal itself.

It'll take some more work to attach timing information to your samples.  The most complete way would involve a 2nd counter task configured to measure periods of the "2nd Edge" signal.  The cumulative sum of the periods would give you an elapsed time since task start.  You'd probably also need to get away from the Express VI and do your own file writing (and formatting).  Then you have better control over the timing information you want to attach to your measurements.   

    And for that matter, you'll also have control over the precision of your measurement data.  As it is, you're stuck with some kind of default fixed resolution of 6 digits after the decimal point.   Unfortunately, that's the size of your typical measurement at 3e-6, so you only save your measurements with 1 significant digit.

Here's another small mod.  It changes over to Continuous Sampling, iterating the Read loop at ~20 Hz so you can control your capture time to be more nearly 1 sec.   I didn't make any changes to the file format.

-Kevin P