error with rapid data acquisition

[Mcdan]

Hi Tim,

Can you explain your comment, "Of course, to get hundreds of thousands points in a few seconds isn't going to happen."?

Is this because your measurements need to happen over a wide range of RPM for your device?  If you have a known range of RPM you will be operating over, one method would be to set the read timeout to be the amount of time it would take to acquire 4304 samples over the longest possible revolution.  If you are not able to set reasonable limits like this, another approach would be to use the DAQmx Read->Status->Available Samples Per Channel Property.  This could be queried before calling DAQmx Read, and DAQmx Read called only if the value it returned was greater than some threshold (likely 4304).  With a solution like this, DAQmx Read would never have to wait for data (ie... use a very small timeout).  The code which was querying available samples per channel would then be responsible for determining if the encoder had stopped (ie, no increase in 'available samples per channel' for some amount of time).  This approach makes defining what a timeout is, and how it behaves the programmer's responsibility rather than DAQmx's.

Hope that helps.  Let me know if I've misunderstood what you need.

Dan

[elset191]

Depending on the application one acquistion could last up to a few minutes.  In our lab we run anywhere from 100 to 1000 rpm, with anywhere from 60 to 4000 pulses per revolution.  If we spin the tool manually (to try to align something, e.g.), the encoder will trigger the acquisition.  To wait (potentially up to) a few minutes until we see an error dialog is...undesired. 

I just got into the office after reading your post so I haven't tried anything, but I will look into the property.  Thanks again, I'll keep you posted if I have any troubles.

[elset191]

I wrote this up and it seems to be working.  So I've basically got a 1.5 second timeout.  Is there a more direct approach?

[Mcdan]

Tim,

That looks like a very reasonable approach.  Be careful with that Wait (ms) primitive.  With no data dependency, I think you could end up with some strange behavior if it runs at different times relative to the DAQmx Read property node on consecutive loop iterations.

Dan

[elset191]

So, I think what you're saying is that it may execute before or after the property, correct?  So, it would be prudent to put it inline with the property.  Shouldn't matter if it's upstream or downstream, should it?  Just as long as it's consistent?

EDIT:

"This function makes asynchronous system calls, but the nodes themselves function synchronously. Therefore, it does not complete execution until the specified time has elapsed."

This line from the help on wait(ms) pretty much means that as long as the property executes in less than ~1500 ms, there shouldn't be any problem, doesn't it?

[Mcdan]

My concern was that without data dependency, on iteration n, the wait (ms) primitive could run before the property node is executed, then on iteration n+1, the property node could execute before the wait (ms) primitive.  I'm no LabVIEW guru, so maybe you're safe as implemented.  I generally would force a data dependency between the property node and Wait (ms) primitive to make the behavior explicit.

Dan

[Kevin_Price]

I've found that in actual practice, this particular type of data dependency is generally inconsequential.  McDan is definitely correct that in theory, LabVIEW is allowed to wait for none, all, or any other fraction of the wait time before the property node is accessed.  In practice, nodes don't sit around idly NOT executing unless they are waiting to receive an input value.

Even if the Wait is called first, the property node will almost certainly be accessed within the next few microseconds because it doesn't need to, ahem, wait for the Wait function to end.

-Kevin P.

[John_P1]

The polling solution should work as well, but if you are interested you can also register a dynamic event to occur every time N Samples are acquired into the buffer:

See here for an example use case.

I'm not saying that you should switch to this necessarily (that's up to you determine within the context of your application).  I just wanted to point out that the possibility exists if you like to use event-based programming.

Best Regards,

[elset191]

I'm back, and more confused than ever.

In our most recent tests we've been trying to run at 950 RPM, acquiring 2262 pulses per revolution, again with 4 input channels.  By my calculations this puts us at 35,815 samples/second on each channel.  This is actually less than my original query, but for some reason I've been getting a slew of errors. 

The first thing we were noticing is that my timeout code (polling method I posted above) was tripping.  So, I probed the output from Available samples per channel, and it was getting to about 3000 only.  At this point there were no DAQmx errors, just my timeout error, because the property was not counting like I thought it should have been.  (Oh, I also forced data flow from the wait to the property, like was previously discussed in this thread, it made no difference)  Confused, I commented out the entire 'timeout loop' and ran the code again.  (By this point we had dropped to 850 RPM).  This time the code worked.  The next time, the code did not work.  For some reason I was getting ADC conversion errors saying that my period was too small.  My rate is set to 60000, which should be close to my limit, and well above my needs.

I have no idea why my code keeps generating errors, and it seems to be two different things as the culprits, the Available Samples per Channel property and the DAQmx Read itself.  Like I said, I'm more confused than I've been since creating this thread.

[Mcdan]

Tim,

Let me take a guess at what might be happening.  Is it possible that the clock signal from the encoder is noisy and you're getting a false edge on your sample clock?  In this case, the AI timing engine would error and disarm (ie... stop converting samples).  Perhaps the query to available samples per channel does not error in that case.  If this is so, you can add a call to 'DAQmx Is Task Done.vi' to your timeout loop.  This would ensure that you catch an error like the scenario I mentioned above.  If this is indeed what is happening, you may want to try to filter the line on which you import the signal from your encoder.  To do this, you can look at the example here.

Hope that helps,

Dan