Timing analysis

[FLng]

I wanted to use the RT Get Timestamp.vi and the RT Timing Analysis.vi to do a timing analysis of a timed-loop using a 1MHz clock in a Real-Time Project.

When I vary the period of the timed-loop, I get some strange results.

For periods around 10 (i.e. 10 us), the mean-time is about 50 us.

For periods around 35 (i.e. 35 us), the mean-time is about 70 us.

For periods around 60 (i.e. 60 us), the mean-time is about 60 us.

The fastest the loop can execute seems to be about 50 us, even if I make the period less than 10.  This threshold does not worry me much, but I am confused as to why periods around 35 produce a longer mean-time than periods around 60.

Any thoughts?

Also, any extra knowledge on using a 1MHz clock in a timed-loop in a Real-Time project would be appreciated.

The files should be attached.

[FLng]

Also, it seems as though if I set the period to say 13 us and the deadline flag to like 14 us, the deadline flag only rarely is set.

This makes sense because I know there will be some variation in the exection times of the loop.

However, it does not seem to be consistent with the mean-time result of 50 us.

The only other thing I can think of is that, the actual timing analysis process I've done has a resolution around 60 us.  In other words, even though the loop is really executing at the 13 us period, the timing analysis itself is adding about 47 us or so to the mean-time result.

[Jon_S.]

Hello FLng,

You are configuring this benchmark wrong.  You are benchmarking the overhead to create a timed loop.  If you want to benchmark how accurate a timed loop is configure the code to look something like this.

[FLng]

Thanks. I was referring to LabVIEW help -> RT Get Timestamp VI previously, which I must have misunderstood.

[FLng]

I made changes as shown in your diagram.

It seems to be working.  However, I do have some questions:

1) Why do I run into problems when I set the number of iterations to like 1000 ( I think anything over 185 actually)?

2) There seems to be some correlation between the sample execution times.  It looks like the large variations occur in intervals of 10.  Any thoughts?

Files should be attached.

[Jon_S.]

Hello FLng,

I still am a little confused about where you are putting the RT Get Timestamp.vi.  Do you only want the timed loop to iterate once, because in the program you sent this is what is happening.  In the configuration you have set up, you are benchmarking the time it takes to configure the timed loop.  Is this what you are trying to do?  If you want to benchmark the code inside the timed loop you will need to put the RT Get Timestamp.vi in the timed loop.  To get an accurate benchmark you should run the timed loop a good number of times and specify a number of warmup iterations on the RT Timestamp Analysis.vi.  Another thing to note is that TCP communication is inherently not deterministic.  Typically you will have a time critical loop (or several) that transfer data via RT FIFO to the communication loop.  In the communication loop you send the data over the network.

[FLng]

Joe,

Thanks. Sorry for the delay in response.

1) I put the RT Get Timestamp inside the timed loop b/c I wanted to check how fast the loop was really running.

2) Referring to the TCP communication, can you explain how you are defining non-deterministic?

Thanks.

[FLng]

Joe,

Also, can you explain why I need the warmup iterations?

Thanks.

[George_P_Burdell]

Fred-

TCP communication is considered non-deterministic due to the fact it relies heavily on your network connection.  Should your network not respond at the speed necessary for your application, it can introduce jitter.  I found a few articles discussing using TCP/IP communications and how to make them more deterministic (links below).

NI Developer Zone: Command-based Communications Using Simple TCP/IP Messaging
NI Developer Zone: TCP/IP between the Host PC and Real-Time Series Hardware
NI Developer Zone: Advanced LabVIEW Real-Time Development Resources and Benchmarks

Warmup iterations are necessary for Real-Time applications to ensure synching and clock sources running correctly.  Generally 1 or 2 iterations are suggested before executing time-critical loops.  This can be confirmed in the LabVIEW Help “Creating Deterministic Applications (RT Module).