Buffered event counting. Why can't I explicitly sequence generating the Sample Clock Pulse and reading the counters?

[cebailey]

OK, here's the tidy test case, AfterPulseRevisited.vi. This is a rework of AfterPulse.vi which was part of the opening post of this thread. What's changed includes using PFI and internal timebase to eliminate physical wiring, using a channel node, running error lines everyplace, explicitly setting the buffer control digital output line low, and commenting the constants on the left edge with the ends of the strings they must contain after anybody alters this code to use their own DAQ. What's the same includes the basic intent & principle and the flat sequence and timing that dictates execution orders where it should matter. This vi is meant to run on DAQ hardware that has NO PHYSICAL WIRES connected to it. AfterPulseRevisited.vi is the neat embodiment of all the ground we've covered, or at least I hope so.

On my development DAQ system, Laplace, which uses the USB, this vi generates timeouts. Iterations that run before the timeout generate huge values of "Diff".

On my full-up DAQ system, Multi, which uses PXI, this vi ran dozens of iterations without any timeout and give "Diff = 0" or occasionally +/-1, which is what I want to see. I could also merge the last two frames of the flat sequence and maintain expected behavior, which is consistent with dataflow principles but unlike some earlier posted vi's behaviors on Laplace.

I wonder why AfterPulseRevisited.vi fails on one of my systems, and how many other systems it runs or fails on?

[Kevin_Price]

I would suggest you slightly change the error-based sequencing prior to the loop.  You should have the DO task fire its False value *before* starting up the counter tasks.  Starting the DO first makes sure that the line is driven to a steady False state, making the counters less susceptible to any phantom strobes.  It's a subtle thing that may not matter in your particular test environment, but it's a good habit to anticipate and prevent such things than to just wait and see.

You should defnitely followup with your NI field/sales engineer about the timeouts you get with the USB M-series board.  That still seems like unexpected and unacceptable behavior.  Even though USB is known to have some latency, the 50 msec waits you put in the code seem like they should be far more than enough to produce standard count-buffering operation.

P.S.  Looked for your email but it didn't show up.  You'd have to change privacy settings under the Preferences sections of your ni.com profile.

-Kevin P.

[cebailey]

>You should have the DO task fire its False value *before* starting up the counter tasks.   ---   Well, of course I should! I puzzled over this yesterday and decided the opposite, for reasons now unknowable. Do you debug liveware? Never mind. I changed this in ...Reordered below, and answered a bus latency timeout question by increasing both counter timeouts to 5 seconds. I did try a 30 second timeout, too. ALL these still time out on the Laplace USB system. In any case I agree I should fire False before configuring counters in future versions.

>You'd have to change privacy settings...    ----   Sorry, I misread my setup. Try again?

[cebailey]

Something does appear to be wrong with some NI hardware. A NI engineer ran a version of these VIs on different systems and found USB-6259 hardware generates a timeout while a PCI counterpart does not. He's submitted the VI to other NI engineers for further analysis. I'll post further news.

[David S.]

Hi cebailey -

If you have an open Service Request with that engineer, please let him know about this forum thread, so he can monitor it and post as necessary.

[cebailey]

David, thanks, he's reading the thread.

Actually, I didn't speak very precisely. My post might be misleading, though I didn't intend it. Nobody at NI is saying anything is wrong with any hardware. All the engineer actually said was that running a related VI he got a timeout on some hardware and not on other hardware.

I'm the only one to whom it appears hardware may be at fault, or at least the only one saying so.

It is hard to resist thinking that, when I think I've understood the instructions and things still don't go right.

[Erik_J]

Hi Chris,

It was nice meeting you today.  Correct me if I am wrong, but the odd behavior in which you've discovered can be described as follows:

Using a USB M-Series, begin a Continuous Buffered Counter Input acquisition.  Send the source of the acquisition only one pulse to indicate that you would like to latch the counter value into the onboard buffer.  Then, if you request exactly one sample, a timeout error will be retuned even though there is exactly one sample on the buffer.  This behavior is only found on USB M-Series, PCI an nd PXI M-Series do not show the timeout error and return one sample as expected.

The workaround here is to change your number of samples per channel input from 1 to -1, indicating you would like to read all available samples on the buffer.  This should effectively do the exact same thing because instead of asking for one sample, you are asking for all samples and there is only one sample on the buffer.  Therefore that single sample is returned.  An alternate and less ideal workaround would be to send the source of the counter more than one pulse, which will return additional unnecessary data.

Our R&D engineers are looking into finding a permanent fix to this problem.  The problem is likely related to the USB bus, which is not ideal for sending bursts of small data, but more ideal for large data transfers.  Regardless, you should be able to do what you are trying to do here.

Thank you for bringing this to our attention Chris!  Please let me know if you have trouble with the provided workaround.

Best Regards,
Erik J.
NI Field Engineer

Message Edited by Erik J on 08-24-2007 08:58 PM

[cebailey]

Erik, thanks, I greatly appreciate the meeting and your posting.

I *thought* there was something amiss - well, hardware, or software, I don't know, but the confirmation is certainly nice.

So far I have not found any case where the first workaround proposed does not give a useable result. If it does, the second proposed still might.

I'm curious to hear the final resolution of this, and where exactly the problem arises.

Thanks again!  -Chris