RT hardware timed DQA

[eesen]

I have problems with daq on RT target.

Please see the previous post

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

[Matt_A]

Hello eseen,

It looks like there have been several solutions posted in the discussion forum you linked. Did you have any other specific questions that were not answered by these posts?

[eesen]

I'm repeating my last post.

I want to ask two questions.

Firstly, it is stated 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,  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?

[Matt_A]

eesen,

Let me try to address your issues in order:

1. The LabVIEW help for DAQmx indicates that you do not need to start the task and that "The Timed Loop starts the task automatically." This is slightly different than your understanding where you state that "sampling starts automatically when DAQ read vi call." Sampling begins when the timed loop starts the task; so, samples may be recorded into the device's buffer between entering the loop and the execution of DAQmx Read.vi. It appears that the DAQmx Read.vi in your program is in a Case structure controlled by a boolean. What determines the transition between cases in this structure? A delay between these events could cause some samples to be acquired and not immediately transferred to the device. I also wanted to clarify your attachment. I assume you are using the AvailSampPerChan property in a DAQmx Read property node, is this correct? Also, I cannot tell from your Front Panel, but is the 5282 value given a constant? That is, does every iteration of the loop return 5282 points? Is this value returned on the first iteration and subsequent iterations return expected values? Does this value grow as the loop iterates? The more details you can provide the better.

2. The DAQmx Create Timing Source VI is used to create a timing source that uses a combination of the sample clock and the specified sleep time to determine when to send ticks to a Timed Loop. Therefore, it uses the timing configured in DAQmx Timing.vi. For this question I would reiterate Kevin's suggestion of using an RT FIFO to pass data between your two functions. You could enqueue the data in your acquisition loop and then dequeue the data in your interrupt loop. You could also consider using a Timed Sequence structure instead of your Timed Loop. From the LabVIEW help, the Timed Sequence "Consists of one or more task subdiagrams, or frames, that execute sequentially." You could perform your acquisition in the first frame and then set your interrupt in the next frame. I would recommend you consider these options as it you cannot change the timing source from the DAQmx Create Timing Source VI other than by modifying the sleep time. I hope this information helps.

[eesen]

Thank you for your good explanation. now i understand when sampling starts.
But i have still problems with "DAQmx Create timing source".

When i adjust sampling rate 1khz, and period of timed loop to 1 tick, i see a constant available sample" which is zero. no problem..
When i adjust sampling rate different from 1khz (2khz, 5khz etc), "Available sample" number continuously increacing or it just give error -200279. I expect that when i change sampling rate to 2 khz,(adjust period again 1 tick), my timed loop should run at 2khz
and so "available sample" number again should be constant. But it seems that time loop doesn't run at 1khz? Is there any constaint while using create timing source vi? For example i can use only 1khz, 10khz or 29khz time base clock?

[Matt_A]

Hello eesen,

It sounds to me like you are pushing the edge of the performance you can get out of your code. This has less to do with the sample clock being used in the DAQmx Create Timing Source.vi and more to do with the execution time of the code you have in the Timed While Loop. One way to determine if this is the case would be to monitor the Finished Late? [i-1] property of your Timed While Loop. If Finished Late? [i-1] is true, then you know that your code is taking longer than the period given by the DAQmx Create Timing Source.vi. There is also a tutorial on our website that discusses benchmarking single-point performance on National Instruments Real-Time hardware. This document can help you determine the maximum performance you can expect from your program and can be found here. Another thing to keep in mind is that your code will execute differently in the development environment than it would on a deployed system. The specifics of this difference are discussed in this document, but I would specifically point out the section that says:

"The RT Development System displays the front panel of the VI while the RT Engine executes the block diagram code. The RT Development System front panel communicates with the RT Engine block diagram through a user interface thread."

At this point, it may be helpful to know what kind of controller you are using. What is your real-time device? Are you planning on running on this device or will you be deploying to a separate real-time target?

[eesen]

Hello,
I will read documents you stated.
sorry i don't mentioned before, i'm alraeady using Finsihed Late property. In my previous posts, ı sent a front panel picure."Late"
indicator shows late count.
When i try to sample at 2khz (or higher)"late" count does not change.(zero).This was in my previous trails.Today i try to sample at 2 khz again in order to send a screen shot,i can not run the vi. When i try to run it just freeze.
As a real time target , i'm using real time deskop. I run application in the RT target.
My PC connect to RT target via TCP. When i try to run application at 2khz first it freeze than
TCP connection with target lost.
For months, i try to write a DAQ application, but i can't solve timing problems:(

[Matt_A]

Hello eseen,

I'm not sure what is going on with your data acquisition, but the fact that your communication is locking up suggests that the real-time target processor is being consumed by the timed loop and cannot spare the resources to manage the communication protocol. You may want to monitor the real-time system using the Real-Time System Manager. Aside from this utility, some good information might be: Are you deploying this program as an executable to run on the real-time system? Are you running the program from you development machine? If you are running as a deployed executable, how are you monitoring the front panel? When, exactly, does the freeze occur?

[Kevin_Price]

Referring all the way back to your block diagram screenshot "sampling_exp.jpg" in the thread you linked at the top of this thread...

Your data acq loop looks pretty tight and clean to me with 1 particular exception (maybe) -- the function call to VMI5565 in a loop that must execute 31 times.  Do I remember right that it's some kind of reflective memory driver?  Perhaps the reflective memory driver has some latency, and having that function call in your loop is what limits your execution speed to the 1 kHz realm.  Try an experiment without that function call and see if you can't execute faster.  If it helps, then I'd advise putting all the array processing and VMI5565 call in an independent loop which you feed via a RTFIFO or similar mechanism.

Other little tips:

• You could use auto-indexing in your For loop at the array tunnel input instead of performing explicit indexing inside the loop.  The difference may get optimzed out, but then again it may not. 
• Also, could you perform your AI Read using I16's instead of DBL's?  (If you do this, be sure you understand any board calibration coefficients that you may need so that you can take those I16's and produce the exact same DBL's you would have gotten).  You could send those directly to reflective memory. 
• Maybe there's a function that lets you bulk write an array of values instead of looping 31 times to write individual ones?
• If you need to keep the loop, you better plan to initialize the left-hand shift register to 0 from outside the loop.  This appears to be incrementing a memory pointer.

Also, putting a hw-timed AI Read inside a Timed Loop may not be the ideal approach under RT.  In the earlier linked thread, the discussion got pretty far along before it became clear you were using RT. 

Looking back at the code snapshot again, the way you're set up appears to guarantee that if you ever start falling behind, you'll never be able to catch up.  The Timed Loop only wakes on an AI sample clock.  If you miss one, then AI Read will give you the earliest available sample, leaving 1 in the buffer.  Your Timed Loop won't wake up again until a 2nd sample goes into the buffer.  You'll again read the earliest, leaving 1 in there.  Etc.

Maybe it's worth describing the big picture of what your app needs to do, what the response speed needs to be and why, etc.  Maybe we're too deep into one specific approach when there may be better general approaches that can still satisfy your main goals.

-Kevin P.

[eesen]

hello,
I make some test and realize that Matt is right about "It sounds to me like you are  pushing the edge of the performance you can get out of your code. This has less to do with
the sample clock being used in the DAQmx Create Timing Source.vi  and more to do with the execution time of the code you have in the Timed While Loop."
For now 1 khz is enough for me, i try different sampling rate since these can be necessary  for me in the future. If i need, i will do process about reflective memory card in another independent loop as Kevin advice. Thanks for all your reply, i learn a lot.
Regarding the tips, at the beginning of my implementation, i didn't use HW timed time loop but since i cant't solve sychronization issue between sampling and reading , i have to use HW timed. Regarding to risk of to read  one sample back, can i solve this if i adjust DAQ Read property node to "Most recent" ?