Real-Time Measurement and Control

cancel
Showing results for 
Search instead for 
Did you mean: 

How long does it take to call a function in LabView RTOS & what is the time load of the Execution Trace Toolkit?

Dear all,

 

I’m writing (in CVI) an application to be executed in a Desktop PC Target with LabView RTOS 10.0 installed. I’m using a PCI 6289. My HW Dual Core E5400 GHz + mem DDR2-800 2GB

 

I’m having many latency problems detected by waitfornextsampleclock() function, due to diverse issues, e.g.., when the waitfornextsampleclock() must wait less than 40 us, it returns an error (BTW I’m running a 100 us loop). To this date, nobody gave me an answer to this fact.

 

Anyways, I have to optimize at maximum my code if I want to see running my application.

 

As debugging tool I’m using the RT Execution Trace Toolkit (RTETT), but I discovered some particularities:

 

The inclusion of the TraceStart() - TraceStopAndSave() functions, modifies the efficiency of the loop, i.e., if my code is reaching the time limit, the wait function starts returning latency errors. Then, what is the time load of the Execution Trace Toolkit?

 

On the other hand, I have a more important issue. Basically, this is the code I’m using:

 

while(end_process>0){

TraceUserEvent (0);

flag_wait = DAQmxWaitForNextSampleClock(ctrlHandle,1.0,&isLATE);

errorread  = DAQmxReadAnalogF64(aInHandle,10, 1, DAQmx_Val_GroupByChannel ,readDATA, 20, &readLOG,NULL);

EmptyFunc1();

 

control_t--;

if(control_t<=0)

end_process=0;

}….

 

The EmptyFunc1() will be my control loop code… and it is defined as:

 

void EmptyFunc1(void){

       EmptyFunc2();

}

 

void EmptyFunc2(void){ }

 

i.e., I’m calling an empty function. Now, when I analyze it with the RTETT, I see that a call to these empty functions takes a very long time, around 10 us which is, among others, not admissible to my application. Please take a look to the attached snapshoot of the RTETT. Honestly, I'm not sure if the code while executing is actually performing that way or if this behavior is induced by the presence of the RTETT.

 

I know that each call to a function involves a copy of the variables and so on…. but in this case there are not variables to be salved, so is this the actual time for calling functions?

 

Thanks in advance.

WAB.

0 Kudos
Message 1 of 6
(6,279 Views)

Hi Wilbert,

 

can you please make a screenshot of the whole RTETT's display, please?

As I see from the command list you attached, it seems you're benchmarking not only the calling of the void VI, but also the waiting of the next sample clock and the analog reading from the daqMX, so maybe the only void function call will be fastest.

 

Hope it's useful.

 

FBM

0 Kudos
Message 2 of 6
(6,241 Views)

Hi FatBoyMonchi,

 

thank you for your answer. I’m including another snapshoot of the RTETT as well as the log file (source of the RTETT). As you said, the traces include the waitfornextsampleclock() and the Read64 functions. In my build setup I’ve included both user and library function.

 

I’ve left those functions because they are a minimum part of what my application is, in fact, it is still missing the DAQmxWriteCtrFreqScalar() which varies a PWM duty cycle according to my control law.

 

I’m starting to think that most effects or delays seen in this trace are due to the RTETT tasks (whatever they are), however it is also clear that calling a function in this system takes a long time. Maybe all this is designed for slower applications, where 3us between functions are not so important. But in my case I only have 100 us for all my control tasks; 3us just for calling a function, another 3us for returning to the place where the function was called, is simply too much.

 

I just wanted to be sure because this implies to modify a lot of code I’ve been writing last year, keeping in mind that not using functions is not a beautiful programming experience.

 

Following your idea, I'm also including a trace without Wait or Read64, same results as you could see,

 

thanks again,

WAB.

0 Kudos
Message 3 of 6
(6,238 Views)

Hi Wilber,

 

thanks for the screenshots.

I see that there's a process called RTmain that keeps running during the benchmarking...since that process is using risources, maybe that's the reason why the void function calling takes about 10us to be executed.

 

Have a nice day,

 

FBM

 

0 Kudos
Message 4 of 6
(6,212 Views)

Hi FatBoyMonchi,

 

thanks for your answer. The RTmain() is the main thread of the RT application, so it must be running all the time (everything runs inside it). Please follow this link.

 

http://zone.ni.com/reference/en-XX/help/370051V-01/cvi/programmerref/rtmain/

 

thanks,

WAB.

 

 

 

0 Kudos
Message 5 of 6
(6,208 Views)

Hi Wilber,

 

what is your RTmain supposed to do?

I mean, is it used only for the void function call, or is it doing anything else in the meantime?

If you can post your code, I'll try to see what's going wrong with that.

 

Bye

 

FBM

 

0 Kudos
Message 6 of 6
(6,200 Views)