New and Improved LabVIEW Desktop Execution Trace Toolkit Now in BETA

[reidl]

I didn't know about that double clicking the ribbon tab minimizes it... very nice Eli!

Oh, and just to comment on a few of the new improvements (since the readme is VERY detailed):

Updated User Interface

• Introduce ribbon to replace previous toolbars and menus
• Fix mouse-wheel bugs

Enhanced Capability to Trace Large Application 

• Allows configuration of message limits and out of limit options to prevent out of memory issues that existed in previous DETT versions.
• Allows log data to file when tracing
• Enhance capture settings capability. You can now specify DETT to include/exclude VIs when capturing data.

Usability

• Search bar(Crtl+F) allows searching all text fields in your trace
• Navigation traces to a VI or any VIs in the call chain

New Features

• Adds compare traces dialog. Allows you to diff between two trace sessions
• Adds bookmark to trace line number when starting or resuming tracing

[MattP]

reidl wrote:

• Adds compare traces dialog. Allows you to diff between two trace sessions

Hooray!

[David_Staab]

I see that User-Defined Trace Events are now listed with "; Integer: #" at the end. That's visual noise to me, since I don't use the integer field in my custom traces. Any way we can get a filter option to leave that part off the Details string? (The more legible the trace list is, the easier the tool is to use.)

[Jifan]

I change the behavior to be consistent to DETT 2012. Thanks for your feedback!

[David_Staab]

In the "Capture Settings" dialog, how does the "Exclude the following VIs" interface work? Am I expected to type in the fully qualified name of each VI by hand? I can't figure out a way to get a listing of VIs to select from.

What I really need is the ability to easily exclude VIs by selecting them individually or selecting a group of them by a folder on disk, a Project Virtual Folder, a Class, or a Library. (I'm debugging Actor Framework designs and need to filter out events generated by specific actors, as well as events generated by platform/toolkit VIs that support the projects.)

Oh! And checkbox options to exclude traces from VIs in vi.lib and user.lib too.

Being able to paste an LF/CR delimited list of names into the dialog would also be very useful.

Message was edited multiple times by: David_Staab

[reidl]

You can use wildcards in that window... so you can configure Exclude the following VIs and add an entry for Actor Framework.lvlib:*

We could possibly add a feature (not sure about this version) to have DETT query the LV project you're connected to and asking for all VIs.

Side note:  The filter settings dialog DOES show the list of VIs because this is a post-run operation.  At that point, DETT does know all VIs that have generated trace events and thus, we can display the list of VIs. 

[David_Staab]

Ah, now I see. Thank you!

The existing functionality works for most of the things I requested. The only feature I would still push for in the current release is a pair of checkboxes to ignore all VIs in <vi.lib> and <user.lib>. For example, my current project uses 7 diferent components and packages in <user.lib> and <addons>. Typing a wildcard phrase for each of them into the dialog is still a bit tedious.

[reidl]

Great, glad it worked.  Also, you may notice "load/save" functionality on the dialog.  You can save those filter settings to use again (in reference to your user.lib request) instead of retyping every time.  We will still file a CAR for that request.  Side note:  I believe we already filter out vi.lib from the trace data.  But perhaps that should also be configurable.

[David_Staab]

Thanks for the save/load tip. Regarding <vi.lib>, I think you should make it an option because there are toolkits that install to <addons>, and at times I want to watch what a toolkit is doing, too.

[David_Staab]

Is there a way to tell the DETT to automatically clear and start itself when I begin running a VI (as well as stop itself when all VIs in the context stop running)? My normal workflow is to capture a trace while running, review it afterward, fix some things, then run again. I'd like the tracing to be as automatic as possible so I don't have to remember to manage multiple applications.

(Yes, this is a first-world problem. )