Wait for Next Sample Clock error, or 'How do I put this VI on a diet'?

[Kenn_N]

Ralph,

Don't you hate when you forget to attach stuff.  Anyway. it should be there now.

Regards,

[Ralph@NES]

Hey Kenn, I haven't upgraded from 8 to 8.2 yet, box is staring me in the face though.  Can  you maybe please resave that as 8 or back?

Sorry for being such a pest.

Ralph

[Kenn_N]

Ralph,

I am batting 1000 today. Try it now.

Regards,

Message Edited by Kenn N on 10-06-2006 03:33 PM

[Ralph@NES]

Hey Kenn, I see that structure and I *think* I get the concept...  I'm going to put all the 'paused' states in that one, all the 'running' states in another, and all the 'reset' states in yet another, correct?

You said something about not using local variables to pass values to the structure...  What other method is there to get boolean values out of the loop and to the event?

[Jarrod_S.]

Hi Ralph,

Hope I can help out a little here. First of all, the DAQmx Wait for Next Sample Clock VI is really intended for real-time systems, which a Windows PC is definitely not. Real-time systems can deterministically react to events (such as a sample clock tick) in a bounded amount of time. So if your application is programmed correctly, you can guarantee that you will process a given event within a time period that is bounded and has very little percentage error. You could have your application, for instance, read a voltage value and then output another voltage value depending on that within 100ms.

Windows is not this way at all. A Windows PC may be able to respond within 100ms to a given event on average, but if Windows wants to launch your antivirus software, that might jump to 3 seconds. Your percentage error in your application is unbounded. This undeterministic nature will be present regardless of how fast your computer is.

So the difficulty is that you're doing HW-Timed Single Point in combination with DAQmx Wait for Next Sample Clock. This means that the DAQmx driver is not allocating any buffer for your acquisition. The read absolutely must occur within the sample rate period or else an error will occur. Windows doesn't handle this situation well. It is much better suited for buffered acquistions. In that case, if your Antivirus software kicks in, no problem, you've got a backlog of acquired samples to process whenever your application gets some time with the processor.

So here's what I suggest:
1. If you're running Windows or Linux or Mac and don't have a real-time system dedicated to your application and nothing else, forget about the HW-Timed Single Point. You can either do a buffered (continuous) acquisition set to run at 1Hz or do 1 Sample On Demand, meaning your application will query your DAQ board for a set of samples every time the DAQ Assistant runs. If you do a continuous acquisition, your reading of the data will still be "real-time." In other words, you are guaranteed that you will acquire data at the sampling rate, because this is being driven by hardware, not software dependent on Windows. Your application is merely responsible for reading these samples out of the buffer.

2. If you do a continuous acquisition with the DAQ Assistant, get rid of the Wait or Wait for Next Ms Multiple functions altogether in the DAQ loop. You don't need them. They are completely redundant and can only hurt. Your DAQmx functions are throttling the loop and allowing other resources to have CPU time. They do this by yielding processor time while they wait for samples to appear in the buffer, which only happens at your determined sample rate. Also get rid of the DAQmx Wait for Next Sample Clock VI, which is only really designed for use on RT platforms. If you are doing 1 Sample On Demand, you will still need the Wait or Wait for Next MS Multiple functions, since DAQmx isn't in charge of the timing.

Message Edited by Jarrod S. on 10-13-2006 03:48 PM

[Ralph@NES]

I tried continuous at 1hz and deleted my 'wait' in the loop and got the following:

Error -200284 occurred at DAQmx Read (Analog 1D Wfm NChan NSamp).vi:1

Some or all of the samples requested have not yet been acquired.

To wait for the samples to become available use a longer read timeout or read later in your program. To make the samples available sooner, increase the sample rate. If your task uses a start trigger,  make sure that your start trigger is configured correctly. It is also possible that you configured the task for external timing, and no clock was supplied. If this is the case, supply an external clock.

Property: RelativeTo
Corresponding Value: Current Read Position

Property: Offset
Corresponding Value:

Task Name: _unnamedTask<5>

I'm going to add my wait function back and try the '1 sample' method to see what happens.

[Ralph@NES]

Upon changing it to '1 sample' and adding the wait function back, it seems to have smoothed out a bit.  Should that have been a regular 'wait' function or a 'wait for next ms multiple'?  I'm interested in working in the event structures that Kenn got me started on but still pretty confused as to how to format it and control it.

Any other input on event structure here?  Do I have a different structure for each of my 'states' across all timers or do I put all states and timers in one structure?  The way Kenn laid it in, I see one structure that has all of my 'paused' states in it.

I've got a few days downtime on the rig test that this connects to, any input is greatly appreciated.

Thanks in advance!

Ralph

[Kenn_N]

Ralph,

I quickly through in a structure to show you the idea, but here is a working example using the Event Structure.  Take note where the stop button is located, you'll have to do the same in your code and there is no timeout case either.  Play with this to get familiar with how the structure works.  This should cut down on your local variable usage.

Regards,