Desktop Execution Trace Toolkit (DETT) programmatic API

[rik_aspinall]

I was thinking it would be nice to call the DETT programmatically, in particular:

1) Start and stop a capture

2) Save and load a configuration

3) Save the log file to a user-defined location

(4) Perhaps even compare log files, although this bit can also be done using existing technology

As we get used to more multithreaded programming ideas, such as the actor framework, the DETT will become more important as debugging with independently executing clones is not straightforward. One such really nice feature for the AF has been created by niACS (https://decibel.ni.com/content/docs/DOC-44158).

The next step to me now is to allow it to be called, for example, during a unit test, so that I can measure performance. There is clearly a chicken and egg problem, because the code in which I call the event may preload the code under test, but I can easily imagine being able to set up and tear down the test using different VI's.

How will this help?

1) We can do something correctly, record the trace, save the file and then diff a unit test against the good file, checking that it still produces the same output (if we fire user events as niACS did with the AF). This might not be the best way of unit testing (we ideally develop the test before the code, a la Test Driven Development) but we also should be allowed perhaps to look inside the process (white box testing) to see if more calls are used, say, than the last time the code was run.

2) We can create performance benchmarks for code with tests that are easily re-run. Sure, we ideally should use the same machine with no more software than the last time the test was run, But we can also

 a) See variation across different machines, platforms, etc.

 b) Assess code smells at a quantitative level

 c) Assess upgrades across versions of Labview

[Mr._Jim]

I vote for this idea because I would love to be able to programmatically start and stop a DETT trace, very much in the manner one may do this with NI IO Trace. This feature alone would prevent me from having to babysit code that must run for a long time before exhibiting problematic behavior.

[MrQuestion]

This is a great idea!

In many debuggers such as Microsoft visual studio you can have compiler directives that tell the system to skip certain segments of code during debugging. 

[TurboPhil]

Found this as I was about to post the same idea myself. My particular interest is for automated regression testing, to be included in part of a Continuous Integration pipeline. It would be great to have a step in the pipeline that could run my application with execution tracing and report if there are any reference leaks, etc. Automating it would help us identify if we accidentally introduced a regression like that.

Reference leaks seem like the most straightforward thing we could automatically detect; memory leaks or errors would also be helpful to monitor for, but the former would probably be difficult to find without long run times, and the latter would probably require the ability to whitelist.

[drjdpowell]

I also found this idea after a disire to automate testing with the DETT.

[əʞɐſ]

I'll second this! Being able to write a memory leak test would be sweet!

[Ajay_MV]

I second this idea.  I'm looking for a way to log the execution traces for a long running application which crashes occasionally.

[wiebe@CARYA]

DETT has an API.

Or rather, DETT's API to LabVIEW can be used in LabVIEW. So all DETT's functionality can be replicated in LabVIEW. It just isn't documented...

[Ajay_MV]

@wiebe@CARYA  That's interesting to know.. Can you give some idea on how we can make use of it if you have experience in it?

Regards,

AJ

[wiebe@CARYA]

With scripting (probably the secret scripting) you get some Desktop Tracing methods under Application. That is the full API that is used by DETT, but it isn't documented. There are a few fields that aren't that obvious, so it takes some fiddling to get it to do something useful.

[Kevin.Shirey]

The API is available in LabVIEW 2020 (possiblly lower but untested) by enabling the secret INI Tokens in the LabVIEW INI File found on LabVIEW Wiki. Some of these may not be needed but I tend to add them all. 

server.viscripting.showRiskyScriptingItems=True
enableSecretPopups=True
SuperPrivateScriptingFeatureVisible=True
SuperPrivateSpecialStuff=TRUE
SuperSecretPrivateSpecialStuff=True
SuperSecretListboxStuff=True

Example explained...

Get all the possible application instances (context) from all projects/targets as well as the default. DTT.Setup each instance with the name, enable, and the options on what to trace. DTT.IsTracingEnabled to check the tracing is enabled. 

Run the code and fetch as often as you want to Get the Trace Data (DTT.GetTraceData). The example shows the fetch twice. At the end, disable the DTT in each app instance. 

Use the DTT.FilterVILibEvents for each instance before calling the DTT.GetTraceData. 

The fun part is decoding the events cluster. 

Each event is in the timestamp array cluster with the event type. It refers to a dataSpaceID which you can see in the next array which refers to the VI Name and Path. The event also refers to the callChainID which resides in the last array of clusters to view the dataSpaceID (actual VI) and its callerCallChainID (look in the same array for the dataSpaceID). 

I'm only interested in the events 27 (VI Call) and 28 (VI Return). The other b item refers to the UID which you can use to highlight the object. Run a static code routine in LabVIEW, record, and the same in the DETT App and compare the eventType. 

I hope this provides some context for those who want an API-level call within LabVIEW instead of using DETT manually.