DAQ Sampling senqronization.

[Kevin_Price]

There's a bunch of excellent info already supplied in this thread.  I'd like to pose a question or two to get a better understanding of *why* you're interested in reading single samples at a software loop rate of 1 kHz.

When I hear someone planning a software loop that reads single samples at a rate equal to the sampling rate, I tend to assume that they are attempting some kind of high-bandwidth real-time control application.  Those are the kinds of apps where you wish to update outputs immediately on the fly without any lag time.  Usually there are some calcs done to determine the appropriate values for the outputs, and those calcs probably depend on something like input signals that can also change on the fly.

Is this your situation?  If so, then:

1. Using a timed loop with the sample clock as the timing source is already the best approach under Windows, as far as I know.  Much of the time, your timing diagram would likely look closest to diagram 1, though you will get some non-zero phase lag between sample and read.  Probably less than a half cycle or full cycle as shown in diagrams 2, 3.

However, entirely outside your control, the OS will sometimes find other things to do besides servicing your app which will cause your timing to vary.  And not always very subtly.  If you drag a window around the screen, launch or shutdown another app, wiggle your mouse some, or some network service decides to do stuff, you could easily get intervals in the 10's of msec (or even more) between loop iterations rather than the desired 1.00 msec.

If indeed you're working on such a control system, you really should look into LabVIEW RT.

If not, can you describe the purpose of your app a bit more?  What is your reason for wanting to read single samples at a 1 kHz rate, rather than buffering them at 1 kHz in hw and occasionally reading bigger chunks of data out of the buffer?

-Kevin P.

[eesen]

Hello,

I try to answer quesitons and advicees and try to explain what I try to do.

Once you have configured the DAQmx Timing VI,  you are only specifying the timing and not actually acquiring anything.
--> You are right I don't acquare anything but DAQ card start sampling and start to fill buffer so when I acquare sample after say 100 ms wait,
there are 100 sample in the buffer which I don't want.

This means that you can do a DAQmx Read in two different loops and your data will still be read at the rate that you specified in the DAQmx Timing VI (see attached). 
--> I don't want to desire something like that. So I don't undestand this. Let me clarify my purpose again. Say I have two timed loop(Actaually more than this)
In the first loop I read sample data, ın the second loop I do other operation. (send interrupts to other systems) I want these two timed loops use my DAQ card onbourd clock
as an external time source. But to use onbourd clock, to block diagran I need to place "DAQ create channel vi" "DAQ timing vi" and "DAQ create time source vi" , this couse sampling to start.What I need somehow reach to onbourd clock of the DAQ card without create a DAQ channel or DAQ timing.

If you just specify continuous samples in your DAQmx Timing VI and use only a while loop for your DAQmx Read, you will still acquire data at the rate you specify.
--> I don't want to use while loop. I'm developing a real time application. I need to assign priorities to timed loops, besides this if I used while loop, since it does not have "finished late"property, I can't know wheather there is a finish late condition for some reason or not. This not accapteble for my application.

The DAQmx driver is actually shipped with an example that continuously acquires data based on the internal clock of the device.  You can find this example in your LabVIEW environment by clicking on Help > Find Examples.  A new window called NI Example Finder will open.  You will see folders in the middle window.  Click on Hardware Input and Output > DAQmx > Analog Measurements > Voltage  and then click on the Cont Acq&Graph Voltage-Int Clk.vi.
--> You can be sure that I look these exaples many times.

If indeed you're working on such a control system, you really should look into LabVIEW RT.

--> I'm sorry I forget to say, I have already used LabVIEW RT. But I suspicious about to continue use it. Since, I can't solve  timing issues.
why* you're interested in reading single samples at a software loop rate of 1 kHz
--> Let me explain. At every msec ı read one sample and transfer it to another system with a reflective memory card. (Reflective memory part does not seen at my previous attachment, since it needs a specaial driver, it can cause you not open that part so I just erased it). After transfer this one sample to other system I need send an interrupt. But interrupt send should be in another timed loop for some reason. And interrupt send sometimes continue even if I don't transfer sample data. So I have three important requirements

•   DAQ sampling and read that sampling should be synchronize.----> I can achieve this by using on bourd clock for externel clock to timed loop. Since now both samling and reading use same clock they run syscronized.
• Reading sampling(first timed loop) and sent interrupt timed loop (second timed loop)should be synchronized. I plan to use onbourd clock for the second timed loop as well. But I stated beforeI don't know a way to use onbourd clock without  placing "DAQ create channel vi" "DAQ timing vi which somehow start sampling. In short, I want to use onbourd clock for all my timed loop without startingsampling.

I'm sorry, thread is so long. Since english is not my native language I have diffuculties to tell problem, I try to explain as clear al possible.

[Kevin_Price]

My most recent use of LabVIEW RT was version 6.1, before Timed Loops existed.  We had a 1 kHz hardware-timed loop too.  Our technique for synchronizing loops was to use "Occurrences" to signal the other independent while loops when to wake up and do something.  I've always thought of Occurrences as another name for interrupts, so our application had some similarity to yours.  You could do the same thing, and I think maybe you *should*.  I'll explain more below.

Thanks for the screenshot.  In the circled region, *none* of the calls makes sampling actually start.  You would need to call DAQmx Start to make sampling start.  The items you circled merely configure the task to get ready.  Your call to DAQmx Read inside your loop may cause sampling to 'auto-start' -- check the default value of the boolean input you didn't wire.

Tip -- I'd suggest that you don't build up an array of error clusters on the border of your For Loop.  I'd preserve a single error cluster thread using shift registers.  I'd also use shift registers on the outer Timed Loop for the error cluster wire(s).  Finally, I'd wire that error cluster to your Timed Loop's "Stop" terminal.

If you have 2 different Timed Loops that are both driven by a 1 kHz hardware clock, configured to run every 1 Tick, you may have a problem.  Both of them want to execute simultaneously.  You *may* be able to solve this by giving the data acq Timed Loop higher priority, but I'm not 100% sure.  You won't have any way to set them to a different Offset, because both need to have an Offset of 0.

An alternate approach might be to drive the Timed Loops with a higher frequency hardware clock.  If you used a 1 MHz clock, you could set the period to 1000 Ticks and then you *could* set different Offsets on the two loops.  Choosing the best Offset value may not be easy though.  If it's too small, the executions want to overlap, putting more strain on CPU.  If it's too big, you're wasting CPU time doing nothing.

My opinion is that using a mechanism like Occurrences or Notifiers or possibly the RTFIFO would be a better option.  You could then make sure that the last thing done in the data acq Timed Loop is to cause the processing While Loop to wake up and do its work.  Then they'd never be fighting over CPU usage, and your execution times should have less jitter.

Summary: Hardware Timed Loop is a good idea for data acq.  It would be best to create a >1 kHz Timing Source with >1 Tick period.  Doing so allows you to learn more from the Timed Loops properties.  A while loop is better for your processing loop.  It should be sync'ed by having it wait for an Occurrence, Notification, or RTFIFO element that gets set or sent at the end of the data acq loop's processing.

-Kevin P.

[eesen]

Thank you for your good explanation.

I want to ask two questions.

Firstly, you said that sampling starts automatically when DAQ read vi call. But I don't understand this. If sampling starts automatically, (I sampling 1 khz, and read cycle use same clock , as a attaced before), how can I see such a available sample count(see the attechment). I see it for a while. If sampling starts when reading starts, such a number is impossible.

Secondly, one of your advice is to use 1 mhz clock. My sampling rate 1 khz. Is there any way to use 1mhz timed base hardware clock for timed loop. I asked this, since when I adjust sample rate to 1 khz at "DAQmx timing vi, "creating timing source" vi automatically used 1 khz timed base. Can I change it?

[Kevin_Price]

1. Re: 'available samples' count

I'm not sure how you get a number for 'available samples' based on what I see in the screenshot.  I know the call to DAQmx Timing does not actually start the sampling clock.  I didn't think the call to Create Timing Source would start it either.  But if the sampling clock isn't started before entering the loop, I don't see how the loop will even execute because no ticks are being generated by the timing source.

Do you have a call to DAQmx Start in the loop's "False" case?  And does the Timed Loop have a fairly short timeout value?  I'm only guessing but perhaps the absence of sample clock ticks eventually wakes up the Timed Loop for the "timeout" reason, at which point the False case executes, which in turn starts sampling, which in turn lets the Timed Loop start to iterate normally.

I haven't used RT under DAQmx and don't really know the behavior of "HW Timed Single Point" timing.  It appears to create a buffer anyway, but perhaps when you Read it only returns the single next sample?  Just a guess, but perhaps the 'available samples' count increments as a means for you to determine whether your reading rate is keeping up with the hardware sampling rate?

2. Re: 1 MHz clock

Again, no experience with Timed Loops under RT, but I've read that they can be timed off an internal CPU-based 1 MHz clock.  There could be benefit in having separate Timed Loops for data acq and for processing which have the same period but a different offset (phase) for waking up.  In order to accomplish a phase offset, the period must be many ticks worth of timebase -- that's where the 1 MHz internal hardware clock can be used.

However, there are some conceptual timing issues to work through.  When your data acq Timed Loop wakes up, do you want to request the next future sample or the most recent past sample?  How sensitive is your control scheme to this unknown delay between input readings and output control settings?

Maybe you should post to the RT board where people with more up-to-date expertise might help?  If you do, please insert a link back to this thread to give folks the background info they'll need.

-Kevin P.

[eesen]

Thanks for all your help.

I continue this thread in the following

http://forums.ni.com/ni/board/message?board.id=170&message.id=236724