Skip to content

DETT Saves the Day!

by Nancy on November 7, 2011

Disclaimer: ¬†This is not a veiled marketing post, attempting to entice you to purchase Desktop Execution Trace Toolkit (DETT). However, we and our customers have experienced much value from this tool and we think it’s valuable for anyone writing large LabVIEW applications. (Perhaps we would should have listened to NI’s marketing presentations earlier. ūüėČ )

Are you currently using Desktop Execution Trace Toolkit (available for LabVIEW 8.6.1 or later)?

If you answered yes, skip this post, or rather fast forward to the comments and let us know if you have additional feature requests.

For those of us who are not using DETT, does anyone actually have a reasonable excuse? Cost? Time? One more tool to learn?

Costs Too Much?

NI wisely rolled DETT (as well as VI Analyzer and the Unit Test Framwork) into the LabVIEW Developer Suite in 2011. ¬†So if you own Developer¬†Suite, you have no additional cost. ¬†Otherwise, it’s a $999 investment with an enormous payback. ¬†One customer was able to identify and fix 90% of the memory leaks in less than a day. ¬†Another was able to identify the source of unreported errors in minutes. ¬†Those undetected issues would have been far more expensive had they not been repaired prior to deployment.

Time Consuming?

Yes, this is one more step in your process.  It does take time to run your code through various scenarios.  However expending a few hours or a day during development may save you that or far more after deployment.

One More Tool to Learn?

Yes, but this tool is very simple and you should be up and running over your lunch break, even if you only have a spare 30 minutes.  Follow these steps:

  1. Enable VI Server Support by going to Tools>>Options>>VI Server and selecting TCP/IP under Protocols. ¬†If you don’t, the DETT will remind you about this step. ¬†(Note that the reminder
  2. Once you are in DETT, select new trace.
  3. Specify the instance that you want to trace.
  4. Select Start.
  5. Run your code.

It’s really that simple.

But Wait… ¬†There’s More…

Actually we have two very minor bugs to mention.  Both have Corrective Action Requests (CARs) submitted, and fixes should be integrated into future releases.

  1. If you do not turn on VI Server Support, you will see a warning from DETT.  The error message could be clearer. See #1 above.
  2. If you are using the evaluation version of DETT you have to use a small trick to start the trace. ¬†When you select New Trace, you are now in the New Trace Connection dialog box. ¬†If you leave the selection on “Local Application Instance”, the “OK” button is disabled. ¬†It may appear that you cannot start a new trace. ¬†However, if you select one of the other options, and then reselect “Local application instance,” then the “OK” button is enabled and you can now start a new trace and proceed. ¬†This does not occur with a licensed version of DETT.

What Does the DETT Do For Me?

First, you choose what you want to capture.  You see a stream of all of the specified events, when they occurred and additional notes about each.


You can quickly find memory leaks due to references that have not been closed.  If the Queue is named and you are also tracing general use of the Queue, then you can easily fine the source of the leak.

What about that error that you did not process or catch? (Note:  This is a common error that can cause havoc.)

Unsure about how your code is functioning?  You can insert your own messages into the trace with the Generate User-Defined Trace Event function.  This is a useful way to add debugging code to your application.

Are you finding discrepancies between running your code in the Development System versus the Run Time System? Run DETT for both instances and compare. ¬†If you’ve deployed your code to a remote machine with only a runtime engine installed, you can still connect to and trace the application running remotely!



DETT should be easy to incorporate into your LabVIEW workflow, and is worth learning and applying.¬† Let us know if it isn’t.

… Oh, and Those New Features…

This screenshot is from an NI-internal prototype we created as an alternate way of visualizing the trace data.  It uses the 3D Picture Control.  Here, time extends off into the distance, call depth extends vertically up (the deeper the call hierarchy, the taller the trace), and threads are left to right in different colors.  In the prototype, you can scroll around, zoom in, and rotate around the data for more scrutiny.  We currently have no plans to productize this kind of visualization, but please let us know if you think something like this would be valuable.  What other new features would help you?




20 Comments Leave one →
  1. Aaron permalink

    Loved using it with LabVIEW 32 bit. When will it be available for LabVIEW 64 bit?

    • @Aaron, I just tried it with my 64-bit LabVIEW 2011, and it looks like tracing worked fine. The only thing I noticed missing was the DETT functions palette, which contains the Generate User-Defined Trace Event primitive.

      So to get the palette, I copied
      C:\Program Files (x86)\National Instruments\LabVIEW 2011\menus\Categories\Programming\_DETT
      C:\Program Files\National Instruments\LabVIEW 2011\menus\Categories\Programming\_DETT

      Just to be sure, I created a VI in 64-bit LabVIEW with this function in it, and captured a trace. Worked perfectly.

      For completeness, you could copy the examples and help files from 32-bit to 64-bit, as well.

  2. jcarmody permalink

    Re: 3D Picture Control

    Were you analyzing your traces, Neo? Or were you looking at the woman in the red dress?

  3. Aaron permalink

    Features I would like to see/feedback:

    Ability to look at the time delta between paired events. Simply highlighting paired events still requires me to have to calculate the time.

    Better ability to save/load traces. I have had several traces that were fine when captured (well as fine as having DETT take 100’s of megabytes of memory) but when saved as a trace then re-imported, DETT crashed with out of memory messages.

    Ability to save/recall filter settings.

    Ability to de-select all instances of a cloned VI once.

    When filtering, if the results are smaller than the current position in the table, it does not automatically scroll up misleading you to think all results have been filtered.

    Updates to documentation to say that it works with LabVIEW 64 bit.

    • To everyone here… the team working on DETT is reading all of your feedback and considering your ideas for future releases.

      @Aaron, as part of that process, I learned something new from the DETT team. If you click on one event, and then shift-click on another event, the status window at the bottom shows the time difference between the two events. You can keep shift-clicking on other events to see the time difference from the original event you clicked on.

      From what I can tell, this is not documented.

  4. Ron permalink

    I have the Developer Suite 2011. Where is DETT located?

    • Are you looking at the August 2011 DVDs? If you look under “NI Developer Suite Core”, you should see an option for “LabVIEW 2011 Desktop Execution Trace Toolkit”.

  5. Aaron permalink

    Additional feature: I would like the Errors enable/disable treated like the VIs. Specifically, in addition to a global enable/disable, I would like to see a list of the error codes and be able to filter specific codes.

    For example, if you use the NI STM toolkit versions 1.1 or 2, you will frequently be generating error code 56 (several times a second). Being able to unselect error 56 and only see other errors would be beneficial.

  6. Aaron permalink

    Yet more features:
    1) Ability to only trace events from a chosen “top-level” VI. For example, if I have multiple top-level VIs or Consumer loops, I may only want to debug one of them and the others are providing a great deal of noise for me to filter out.
    2) Ability to get statistics from a trace. For example, if I select a particular VI execution, I can right-click and see statistics such as number of copies in the trace (if a re-entrant clone VI), number of times it appears in the trace, average/min/max execution time in the trace.

    • reid permalink

      Aaron, on feature request 1, would you want to just see trace data from the chosen top-level VI or would you want that VI and VIs in his hierarchy?

      For example, I have and Both of them call If you wanted to trace just TopLevel1 (and not TopLevel2), would you want traces from TopLevel1 and SubVI1 (since TopLevel1 calls it)? Or would you prefer it to be explicit and if you wanted trace data from subVI1, you’d have to list that?

      • Aaron permalink


        Sorry for my delayed reply. If I have SubVI1 that is called by both TopVI1 and TopVI2, I would like to be able to filter and only show the instances called by TopVI1. So I guess I would describe this as a VI filter where I can choose a specific VI and only see subVIs that are called by the chosen VI.

        If you have a number of parallel state machines/loops, and are big into re-use, certain subVIs may be called by a several of the state machines, but I many only want to debug one of the loops, and it can be difficult to figure out whether a given instance of the subVI is being called by the loop I am debugging or a different loop.


        • reid permalink

          Thanks for clarifying Aaron. That use case makes sense.

          One other question for you. Right now, DETT has filtering, which means DETT still captures all trace data, but you can use filtering to only show what you want. You still have access to all the data by changing or removing filter settings.

          Do you see value in limiting what DETT captures? In this use case, you might pre-configure DETT to only capture messages from This would allow for better control over memory usage. The drawback is that we won’t have any trace data except for what you specify.

          Is it easy for a user to understand the difference between them? If I were to define it as follows:

          “Capture settings” will control what information DETT will query from LV and keep in its memory. This is what you already have some control over in DETT’s “Configure Trace Session” dialog where you can specify capturing events, queues, VI execution, etc. This could be expanded to VIs (by name, and possibly by caller, like I mentioned in my previous question).

          “Filter settings” is what you have in DETT to show/hide particular trace data. The data is still in DETT’s memory, but just limits what is shown in the table.


          • Sorry to interrupt your conversation, but as you can see in my reply, the filtering in DETT doesn’t really work. If you set the filter to remove everything except one type, the entire list is left blank.

            My workaround has been to decide ahead of time what I want to capture, but it would be much better if the filters worked.


          • Aaron permalink


            I see benefit to filtering during capture to limit memory usage. I would like to see the filters be capable of being used both pre-capture and post-capture. The Pre-capture could be used to log very specific data, while the post-capture could be used to narrow in on things.

            I also see benefit in adding a stream to disk option where you only keep the most recent 1000 entries in the table (to limit memory usage) but you log everything. Then on loading the logged file, you do not attempt to keep the entire thing in memory, but only load portions at a time depending on the filtering settings. For example, if you had capture 1 million lines, you could scroll through 1000 at a time, but if you chose to only show errors and there were 560 errors, you would see all of them. Obviously reading/filtering the file would be time consuming, but it would be much more valuable than the current “Out of Memory”.


  7. Thanks for posting this, great article, I am sorry I had missed it.

    I love DETT, specially when I have to debug exes. I only need to make sure I build a debug enabled exe and that my computer running DETT and the computer running the exe are on the same network. BTW, I don’t think it is documented that when you build the exe, the VI server needs to be enabled at the target level in the project (right click My Computer>>properties>>VI Server) and not necessarily at the LabVIEW level (Tools>>Options>>VI Server)

    My number one complaint is that the filtering does not work, either it doesn’t scroll up as Aaron mentioned or the table is completely empty. I have worked around by only selecting the cases I want and starting a new trace and using the “Generate User-Defined Trace Event” as landmarks in my program.

    I would love to have a way to run longer traces, unfortunately for some applications that generate a lot of events, I start getting “out of memory” errors and I am not able to run for more than 5 minutes at a time. My work around has been to trace from a remote computer with a lot more memory.

    When double-clicking on an entry on the trace table, the related code is supposed to get highlighted. When I am working in a double monitor computer this is no problem, but if I am working in a single monitor computer, then I need to remember to make the DETT window smaller so I can see the highlighted code, otherwise DETT stays always on top and I don’t see the highlighted code.

    Next time I am using DETT, I will make sure to comeback with other suggestions and feedback.



    • reid permalink

      Yes, we are aware of issues with the current filtering and those will be fixed (in addition to expanding “Capture” settings).

      • reid permalink

        Oh I forgot to mention one common problem with filtering. It is not clear in the current version but you must have at least one thread ID and one VI checked, otherwise the entire table will be blank.

        • Aaron permalink


          I learned that one by trial and error. Are you aware that there are cases in which DETT will miss errors? I do not have use case example code at the moment (former employer’s code), but I did see cases in which my code would generate an error but DETT would not see it. I do not remember if I simply passed an error cluster constant out of a case statement or if it was a matter of bundling new status/code into an existing error cluster, but DETT did miss it.


          • reid permalink

            We will try to reproduce. If you come across sample code that does it, let us know.

Trackbacks and Pingbacks

  1. Help Beta Test the New LabVIEW Desktop Execution Trace Toolkit! | LabVIEW Field Journal

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.