Desktop Execution Trace Toolkit 2011 Ignore VI's during logging

[MrQuestion]

I'm using LabVIEW 2011 Desktop Execution Trace Toolkit for Windows. 

I'm coming across issues where my log gets large and causes the tool to crash. This is a fairly knows issue with the tool and I can adjust the log file limits via the INI.

National Instruments\MAX\Assistants\Trace Toolkit\TraceTool.ini

By adjusting the MaxEvents key.

I want to know if there is a feature that allows the tool to ignore certain VI's?

I'm doing some CRC checks in my software, and the recursive math functions count is very high, and the CRC checking takes up about 90% of my log before I hit my limit.

I know there is no issue with my CRC math. (I"m using the openG CRC checks)

I also know the issue I'm hunting down comes not long after the CRC checks.

Is it possible to tell the Trace Toolkit to ignore logging VI's that are called from another VI?

I know I can filter the log post logging, but I need to filter out some of these VI's before they are ever logged so I don't overflow my memory in the Trace Toolkit.

There should be a way to do this. 

Or at the very least tell the Trace Toolkit to stream the log to a disk drive so that it doesn't store everything under the sun in ram like a timebomb.

Thanks,

[cbutcher]

I'm not sure if this is possible for you, but if you're not connected to the hardware whilst you're testing, could you use conditional disable/remove the CRC subVI? That would seem the most straightforward way to prevent it being tracked by the DETT.

If your problem is in a known location, perhaps you could alternatively place a breakpoint before you reach that part of the code, then start the DETT during the breakpoint, before resuming? That could cut out whatever happened earlier in the code (although maybe you need that information too...)

[MrQuestion]

Sigh,,,

I guess that Is the probably the best option.

The DETT is a very nice tool, I just wished it offered a few tweeks.

It's strange that the tool doesn't offer real time streaming to disk. Or an option to save the log in a standard TDMS file format. 

Thanks for replying. 

[cbutcher]

I wait with baited breath for a real answer and apologise that I couldn't provide one - if it is possible I would also be keen to know!

However, it wouldn't surprise me if the way DETT hooks into execution prevents pre-processing beyond the wide dropdown selections. It's still a great tool.

[even-And]

LabVIEW 2013 Desktop Execution Trace Toolkit has a Do Not Capture Events For This VI feature. In which, you can select VIs to include and exclude from the trace. 

As for LabVIEW 2011 DETT, cbutcher's work around sounds like the best option moving foward. 

[cbutcher]

So I was looking for the feature described by Steven and discovered if I click on the upper, larger portion of 'Capture Settings' I get a far more detailed control over what is captured!

Nice to know this is there - can't believe I didn't notice I could click that before (previously only used the dropdown part).

[MrQuestion]

It's a shame that I can't have multiple version of DETT installed at once.

I often switch between LabVIEW 8.6.1 and LabVIEW 2011. The bulk of of our software is stuck in 8.6 land. 

How does DETT work? I assume that it uses the VI server. If DETT uses VI server, couldn't I use the same VI Server commands to collect the same data?

Is this information published anywhere?

[MrQuestion]

I remember back in the Windows xp days that there was a switch that you could enable at Windows startup that would allow programs to access more than 3Gb of ram.

I might be off, or wrong about this, but I think windows limited max ram size to 2Gb, and programs if written for it could go larger than 2Gb.

Is there such limitations of RAM size access for DETT? I have 16Gb of ram. Is DETT taking advantage of the larger RAM space? Is there a special or secret switch for DETT out there to utilize more ram?

[even-And]

I unfortunately could not find any documentation in regards to the server DETT uses.  Since DETT is an .exe utilizing more RAM space might be difficult to enact.

I can recommend switching to LabVIEW DETT 2013 and upconverting your 8.6 files to at least LabVIEW 2011. However, I'm sure that will be very time intensive. If you’re not aware of  Version Conversion Board, it’s a great resource: http://forums.ni.com/t5/Version-Conversion/bd-p/VersionConversion