User Defined Trace Messages...

[Wire Warrior]

I am in the process of debugging an issue that only shows up on a built application. Obviously the Desktop Execution Trace Toolkit is ideal for the job particularly after I sprinkle in some user defined messages. The question comes on the heels of my realizing that some of these messages needed to be placed in our re-use library VI's. For long term I can see where making these custom messages part of the re-use library could be useful should future issues arise but what is the unforeseen impact of leaving these messages in? Is there any worth worrying about?

Jason

[jgcode]

I am in the process of debugging an issue that only shows up on a built application. Obviously the Desktop Execution Trace Toolkit is ideal for the job particularly after I sprinkle in some user defined messages. The question comes on the heels of my realizing that some of these messages needed to be placed in our re-use library VI's. For long term I can see where making these custom messages part of the re-use library could be useful should future issues arise but what is the unforeseen impact of leaving these messages in? Is there any worth worrying about?

Jason

I guess the question I have here is that if a reuse library is tested and vetted code then why does it need DETT calls in it all time or is the dist version? (There may be a logical answer I am missing here).

Anyways, I try and keep my reuse VIs lightly coupled. DETT is an add-on toolkit ($$) so sharing your VIs could be an issue however, if its company standard to have DETT always installed then this might not be a big deal internally.

Cheers

-JG

[Wire Warrior]

Good catch, jgcode. Actually, these are new additions to our re-use library to answer an issue we've had on the MFG floor and these components will be included in all new apps and retro-fitted into some portion of existing apps. That's why I asked this question. Trying to identify the final version of these VI's. The company standard for DETT is a good point. On our development machines we have it installed but on the deployment machines we prefer not to have any development tools (as learned from painful lessons) and that means we would not take the step of installing DETT.

Any other thoughts?

jason

[ShaunR]

Must admit I I havn't had a lot of experience with DETT (labview tends to have very pungent code smells and my DETT tends to crash quite often ). But.....

If you put them in conditional statements you can turn them on and off from a conditional define in the project. You can then build with or without just by changing a value and the compiler will take care of the rest.

Edited April 5, 2011 by ShaunR

[Wire Warrior]

Must admit I I havn't had a lot of experience with DETT (labview tends to have very pungent code smells and my DETT tends to crash quite often ). But.....

If you put them in conditional statements you can turn them on and off from a conditional define in the project. You can then build with or without just by changing a value and the compiler will take care of the rest.

That's what I had in mind as the "take them out option".

My thoughts for leaving them in are that a DETT trace could be initated without having to do a recompile.

Jason