Real Time Execution Trace Toolkit problems

[Thoric]

I'm having trouble with the RT execution trace toolkit.

No matter how large the value I provide to the  Buffer Size input of TraceTool Start Trace.vi, I only ever get back about 110 to 120 ms of data.

I know I'm running the Trace Tool in my Real-Time code for a much longer period of time (up to 3 or 4 seconds), but I never see any more than 120 ms of data.

Does anyone know if the Start vi takes a few moments to begin tracing the code execution? I've wired up the error out terminal sequentially into my code, so if it has a delayed start then my code should wait for it.

Any ideas anyone?

[Thoric]

OK, I've read the detail help and, bizarrely, you can't change the size of a RT Trace buffer without rebooting first. Odd. But I still have problems. My returned trace is now only about 500ms, again no matter how large I set the buffer, when I'm pretty certain my code is running for at least 3 seconds. (Three seconds between the RT Trace Start and Stop vis).

Consequently I can't be sure when the trace data synchronises to my code. SO my question remains:

Is there a delay in the Trace Start vi?

and

Is there a way to register user-flags/events in the RT trace session?

[gt3000]

Hello Thoric,

I can confirm that the Real-time target must be rebooted for a new buffer on the 'Tracetool Start Trace.vi' to take effect.  This VI also has 3 input terminals for "Detailed Tracing?", "Thread Tracing?", and "VI Tracing?".  Wiring a False constant into these terminals decrease the amount of Memory buffer use.

The Detailed Help contains a topic called "Creating an Appropriate Memory Buffer (Execution Trace Toolkit)".  This states that "The default size of the memory buffer is 250 KB. You can set the size of the memory buffer equal to the largest contiguous block of memory available on the RT target. "  In LabVIEW Real-time, it is preferred that you allocate the largest amount of required memory at the start of the application.  This allocation is the largest contiguous memory of the Application, and will be large enough to host the all other memory requirements.  This then reduces the jitter created by the allocation task later on in the application.

Therefore, if you create the largest possible memory allocation early on in your VI, that will also be the maximum buffer than can be used by the "Start Trace.vi'. 

This link provides further information on Memory allocation with Real Time.

http://zone.ni.com/devzone/cda/tut/p/id/9988 

As for user events, further examples are installed with the NI Example Finder. 

Navigate to 'Help'->'Find Examples'

Under the 'Browse' tab, find 'Toolkits and Modules'->'Execution Trace tool'->'User events.lvproj'

Regards,

[Thoric]

Hi George,

Many thanks for your input, I appreciate it.

---

This VI also has 3 input terminals for "Detailed Tracing?", "Thread Tracing?", and "VI Tracing?".  Wiring a False constant into these terminals decrease the amount of Memory buffer use.

---

Yes, I noticed those, but they make very little difference to the length of the resultant trace.

---

In LabVIEW Real-time, it is preferred that you allocate the largest amount of required memory at the start of the application.  This allocation is the largest contiguous memory of the Application, and will be large enough to host the all other memory requirements.  This then reduces the jitter created by the allocation task later on in the application.

Therefore, if you create the largest possible memory allocation early on in your VI, that will also be the maximum buffer than can be used by the "Start Trace.vi'.

---

I have read the detailed help and it didn't state anything about needing to allocate this RAM at the start of the app'. That leaves me with a problem, because I don't want the tracing to begin until I've started a particular process, but if I allocate the RAM at the beginning of the app by inserting the Start Trace.vi, then it will begin recording execution stats too soon. I don't see how I have any choice here?

---

This link provides further information on Memory allocation with Real Time.

http://zone.ni.com/devzone/cda/tut/p/id/9988 

As for user events, further examples are installed with the NI Example Finder. 

Navigate to 'Help'->'Find Examples'

Under the 'Browse' tab, find 'Toolkits and Modules'->'Execution Trace tool'->'User events.lvproj'

---

Thanks for the links.

I kinda gave up with it all recently following many exasperated hours of trying to get it to work, but maybe I'll take another look today.

CHeers.

[gt3000]

Hello Thoric,

You are correct in putting the Start Trace VI exactly at the point where you would like to begin tracing the data.  What I am saying is that, according to the documentation, the maximum buffer size you can select on the trace depends on the largest memory allocation you have made at some point in your VI.  For example, if you had an 'Initialize Array.VI' that was several KiloBytes at the start of your VI whose elements were used later on, then the largest buffer you could you use with the Execution Trace toolkit is the size of that Array. 

In terms of using the Execution Trace Toolkit, the recommended use is that you try and trace the required event within a small period.  Milliseconds are often suitable.  The tool is not necessarily intended for many seconds of use, as large amounts of data are collected and need to be send back to the Host.

Memory allocation can be reviewed in the Tutorial supplied in an earlier post.  The following link gives a small, brief overview on Memory Allocation.

http://zone.ni.com/devzone/cda/tut/p/id/4537 

Regards,

[Thoric]

Hi George,

I think you've misinterpreted the Help. To say my Execution trace buffer size must match some other previously allocated buffer size from within my code makes little sense. Why should the execution trace have it's buffer size restricted in such a way? If this were true, then the large majority of the 2Gb of RAM on my cRIO would be unavailable to the trace tool when my code itself only uses, say, 2kB. A trace buffer of 2kB would be very ineffective.

Re-reading the detailed help for the Start Trace vi, "You can set the size of the memory buffer equal to the largest contiguous block of memory available on the RT target". This indicates the buffer size can be set to any value so long there is sufficient unfragmented RAM available, and indicates no dependency on previously allocated data buffers.