Error -200284 When Reading -1 Samples On Continuous Task

[John_P1]

This is a long shot... but can anybody tell me why my DAQmx Read call might be returning a timeout error in the following configuration?

Initialization looks like this:

The read call looks like this:

The idea is that I'm always reading the most recent (up to 50) samples in the buffer and averaging them together.  The false case doesn't have any DAQmx calls in it (but if you're curious... it keeps track of the time since the last good sample and then reports a speed of 0 if the time exceeds 200 ms--also it will set "Samples acquried when web stopped" so that I don't average in old data when motion starts back up again).

The timeout error was reported by my customer halfway around the world, I could not reproduce it at my office (I could acutally run this app continuously generating a simulated encoder pulse up to every 60 ns... however at my customer site the signal is going through an external 10 us digital filter so it shouldn't be anywhere near this fast).  As reported by my customer, the error is very intermittent (It has occurred maybe 4 times in the last week or so with 24/7 operation).  We have shipped a few dozen systems and only this one is reporting the error (but... it also is getting the most runtime, and even on this system the error occurs pretty intermittently).

I'm thinking that perhaps I was a little too clever here and ended up using a configuration that isn't very thoroughly tested?  As far as I can tell though reading -1 samples on a continuous task should never timeout, and even more so since I am reading relative to the most recent sample with an offset between -1 and -50.

I'm just looking for any suggestion from someone who can check under what circumstances -200284 might occur.  I can't experiment with alternative solutions since I am having trouble reproducing the behavior myself (but am still working on it).

Best Regards,

[Kevin_Price]

Not sure this is actually the problem, but I've done this same kind of thing to query a task for the most recent samples plenty of times, and I"ve *always* wired the DAQmx Read call with the specific number I'm asking for.  Just wire the value prior to the negation function "(-x)" over to DAQmx Read.  For anyone else reading, here's an older post that shows it visually.

I never thought of trying it your way before.  I can't think of any *good* reason for the intermittent hard-to-reproduce error, but I also don't recall ever seeing any such errors doing it the way I described above.

-Kevin P

[John_P1]

This is a good idea and I will try it--reading "all available" samples isn't necessary since I already know exactly how many samples should be available in the first place.  The two methods are functionally equivalent in my testing (but then again I have not reproduced the timeout error either...).

If the error persists after making this change, my workaround is going to be to specifically handle the timeout error so it doesn't interrupt the rest of my program.

Best Regards,

[Kevin_Price]

Agreed that the two methods should be functionally the same.  My only convoluted after-the-fact rationale is that "all available samples"  leaves the driver more wiggle room to do some of its own thinking and deciding.  What if, for example, there's an off-by-one  error somewhere down there.   I could at least imagine a scenario where the customer's web stops, the request for "all availble" gets turned into a request for 1 more than all available, which then times out because the web is stopped.

Any such (possible) bug in the driver might stay hidden since the majority of data acq tasks have an explicit continuous sample clock so a potential extra sample will be taken soon enough.  Also, apps that request "all available" would generally not notice this extra sample since they're kinda expecting a variable # of samples returned anyway.

All that said, it'll probably turn out that your customer's dealing with some other yet-unexplained problem and you'll end up just having to handle the rare timeout.  Not many of these off-the-wall convoluted explanations turn out to be right.

-Kevin P