06-08-2018 03:19 AM
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.
06-08-2018 06:55 AM
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.
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.
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
06-11-2018 10:26 PM
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.
06-12-2018 11:29 AM
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
06-12-2018 08:17 PM - edited 06-12-2018 08:20 PM
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
06-13-2018 08:57 AM
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