No "VI VIEW" window in RT Execution Trace Toolkit 2.0

[davidc10]

Often there is no "VI VIEW" window when I run the RT Execution Trace Toolkit, and it is greyed out and unselectable from the menu.  I'm running LV RT 8.5.1 on a cRIO, and creating a buffer of 6 MB, which is confirmed as created. The log files themselves are much smaller - in the 50 to 200 KB range and span times ranging up to 300 ms - so unless they are compressed, buffer overwrite shouldn't be the issue.

Sometimes if I stop and re-start the application on the cRIO - without making any changes that would required a re-download - the VI VIEW will appear when it hadn't on the first run.

Also, sometimes when the VI VIEW does appear, it doesn't start at TraceToolStartTrace.vi as it should if there has been no buffer overwrite.

I have tried both writing to a log file and a straight send and they behave the same way.

Is this typical of buffer overwrite - and if so is there a flag or something to test for it?

Are the log files compressed or should a 6 MB buffer have been adequate for a 200 KB log file?

There were no error messages generated.

Thanks,
David

[StephenB]

Hi David,

I've looked through our support database and found an issue very similar to yours. The resolution of that issue came from renaming all the VIs to have shorter file names (<15 chars). The names of the VIs the customer was using were too long for the trace toolkit to handle, a bug report was filed and this workaround implemented.

Let me know that helps!

[davidc10]

Stephen,

Thanks for the quick reply, but have they verified this information? I have some good traces that have 70 or more VIs with names of 16 chars, many of them library functions, some with names as long as 45 chars.

If longer names are the problem, I'm surprised anyone gets this tool to work. But they must because I don't get many hits when I search for it.

Did you get chance to look again at the prior thread you were helping me with: http://forums.ni.com/ni/board/message?board.id=170&message.id=399315#M399315?

Thanks for your help.

David

[StephenB]

The quote from R&D is:

"(Redacted) has finished his debugging and discovered a potential issue with the trace buffers. As it turns out, the number of VIs and length of the VI names is causing the VI tracing ring to overflow, losing data and failing to set the token for the ETT viewer to interpret the VI tracing logs.

The simplest workaround we have found is to shorten VI names as much as possible. As a standard I would suggest shortening all VI names to under 15 characters. If this renaming is done through the project the VIs will relink automatically, which will save time in comparison to renaming on disk. I have found this workaround also shows timed loop flags more reliably as well.  "

I just inquired into R&D to find out if this has been fixed or a bug report filed and they deemed that the trace ring was appropriately long and no change has been made. 

As far as the other post you linked, that is another Stephen. Try posting again, it will go through our system again

[davidc10]

Stephen,

Thanks for the detail. It makes more sense now, but if it means I have to rename all the dependencies also, then it's not going to work for me. As a matter of curiosity, how many 15 character names would it take to overrun the ring buffer?

I wanted to use this tool as part of our Robotics education program. It's not only a great way for the kids to see the power of LabVIEW's multi-threading capabilities in general, but also a very practical way to check on the deterministic behavior of their real-time programming.

Unfortunately, I don't think that renaming the entire WPI Robotics Library is practical. Also, since it is deeply nested, the total number of VI names is large.

A different issue is that the VI VIEW doesn't differentiate between VIs with the same name. For example, the WPI Library is full of VIs named "Open.vi", (which causes many collisions when building), and which are not differentiated in the trace.

Sorry for the confusion on the names - I'll be more careful next time!

Regards,
David