Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQ wierd behaviour measuring counter input

Odd number iterations (1/3/5/7 ....) are all getting alternating behavior while even number iterations for loops are always successful.

Removing create task and/or adding stop task does nothing at all.

0 Kudos
Message 11 of 16
(1,535 Views)

That sounds like Twilight Zone behavior.  I can't help but suspect a more rational explanation though I don't have one at hand.  Let's get really detailed and systematic to see if we can uncover something.

 

1. Start with the shipping example "Counter - Count Edges (Continuous Clock).vi".  Save a copy somewhere and work with the copy so the changes we make don't inadvertently change the real shipping example. 

    Wire the iteration terminal "i" to a front panel indicator (right-click, create indicator).  Configure PFI terminal wiring & #samples per loop to match your real program.   Do not use the "run continuously" button in your testing.

  • Manually run 10 times.  For each run, allow at least 10 loop iterations unless an error terminates the loop earlier.   For each of the 10 runs, did you get an error and if so, on which iteration?

2. If errors occurred in test #1, turn on highlight execution and manually run several times again.  Allow at least 4 loop iterations per run.  What are these error and iteration # results?

 

3. Turn off highlight execution.  Change the While loop to a For loop and retry your odd/even iteration count experiment.

  • What error/iteration count results do you get when your For loop has N=1,3,5?
  • What do you get when N=2,4,6?

 

4. Change the For loop back to a While loop.  Add the property node you use in your real code to set the sample clock overrun behavior.  Repeat test #1 and #3 with this property setting in place.  What'd you get?

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 12 of 16
(1,530 Views)

i= 107

i= 21

i= 21

i= 41

i= 31

i= 36

i= 0:timeout

i= 21

i= 26

i= 0:timeout

i= 12

i= 0:timeout


It's now quite obvious there's something wrong if attempting to make odd iterations. (last output i=odd is even iterations)

I've played around with the frequency of function generator and the setting but nothing changed, the iteration counts were the only factor affecting the outcome.

0 Kudos
Message 13 of 16
(1,513 Views)

It isn't clear which of the suggested test cases led to the results you posted, nor whether the timeout error was *always* the terminating condition or only for the i=0 runs indicated.  Were you running your own code or working from the shipping example?

 

Have you tried troubleshooting that attempts to eliminate the signal as a suspect?  If not, try the following:  run another shipping example to generate a continuous pulse train and then use it as the sample clock for your measurement task.   Again, no theories on the odd/even iteration anomaly, just probing at possible suspects.

 

It remains hard for me to suppose that the root cause for a timeout failure on iteration 0 ends up being whether the loop was designed to terminate on an odd or even # of iterations.  I understand that's what you're *seeing*, but the needed mechanism for such a root cause would be so bizarre that I start from a point of skepticism on that explanation.  As they say, "extraordinary claims require extraordinary evidence." 

 

I just yesterday had a similarly bizarre troubleshooting theory of my own shot down by a more careful examination of the test conditions.  I had eliminated a much less bizarre suspect early on due to some not-quite-careful-enough analysis of the test environment and parameters.

 

I've seen weird inexplicable symptoms plenty of times; very few didn't eventually yield to a rational explanation or correction (such as a reboot or reinstall).

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 14 of 16
(1,504 Views)

That was shipping code

 

No luck, sending itself a pulse train as sample clock doesn't affect the outcome

when i= odd (even iterations) the next run will be successful

when i = even (odd iterations) the next run would timeout and abort itself

both pulse train and counter edge count were using NI's own example code

0 Kudos
Message 15 of 16
(1,496 Views)

Wow, I'm all out of ideas.  Do you have any other DAQ devices you can try this on, like a desktop PCI or PCIe board?  Can you get direct support from NI?

 

Please update the thread if/when you get to the bottom of things, I'm interested to find out what the root cause could possibly be.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 16 of 16
(1,486 Views)