[Application Builder] What does "disconnect type definitions" accomplish?

[JKSH]

Hi all,

Inside the Build Specification properties, there's an option "Additional Exclusions" -> "Disconnect type definitions".

The only piece of documentation I've found is at https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/resource/framework/providers/builds/appbui... but it's not very descriptive. It suggests that disconnecting might cause front panel objects to be displayed incorrectly. Is this the case?

What does this option do? Its existence suggests to me that type definition info persists inside a compiled LabVIEW application, unless we choose to disconnect them.

When should I disconnect, and when should I leave type definitions alone?

Thanks in advance!

[PiDi]

I only know one use case for this option: when application builder throws errors during builds or exe itself doesnt work.

One reason to use it is when you use Network Shared Variables with typedefs - I recall problems with shared variables not founding theirs typedefs after build. This option also happens to fix more exotic problems - see LV2014 bug fixes: 

426523

A specific large project fails to build with a GenIL error and then crashes if you do not select Disconnect Type Defs

So, other than to workaround app builder problems - I don't know any other reason to mark Disconnect Type Definitions.

[JKSH]

Thanks for sharing your observations, PiDi.

I've also noticed a few cases where some CompactRIO code runs fine from source code, but won't start for some mysterious reason when built and deployed. The workaround was to disconnect the type definitions.

It would be great if someone from NI could provide more insight into the topic.

• What was the original reason for the introduction of this option?
• What goes on behind the scenes -- how/why does disconnecting solve the problems mentioned?
• Are there any cases where it's better to leave type definitions connected?

[netsirk]

Hi JKSH,

Type definitions are used to preserve source code - however, when building/running an executable, this is not a priority. In this case, type definitions can be disconnected to preserve memory usage. The disconnect option is also used as a troubleshooting step when LabVIEW perceives conflicts among different type definitions. The Additional Exclusions Page for LabVIEW 2014 offers a little more information than the 2011 version:

https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/resource/framework/providers/builds/appbui...

Best,

[JKSH]

Thanks, Kristen! Your explanation and link answered 2 out of 3 questions from my last post:

• Type definitions should not be disconnected when you want your users to be able to modify the VIs (e.g. when building a source distribution).
• Disconnecting type definitions can save memory, and it can help with troubleshooting in cases where LabVIEW perceives type conflicts.

This leads to other questions:

• PiDi and I (and probably other developers out there) have encountered problems where a built executable fails to run if type definitions were not disconnected. Is this related to the "conflicts among different type definitions" that you mentioned earlier?
• The problem of non-functional applications seems quite common. Would it be possible to open a CAR for NI R&D to investigate? It would be great if the problem was fixed, or at least if we geet better diagnostic info/error messages.

[Sam_Sharp]

There was a bug in LV2011 RT that caused RT executables to not run when deployed if you had type-def bound shared variables in your project/application. I know because this caused no end of headaches trying to debug why on earth my executable wasn't running when deployed (but would in any other circumstances). Disconnecting the typedefs of the shared variables fixed it for me.

[SBach]

Hello,

I know this thread is quite old but i stumbled upon it and I have one more case in which that option might be useful:

If you  have a enumeration typedefinition and encounter changes to a constant of that enumeration type in a built executable, the problem might be solved by setting this option. 

( I know "constant" and "changes" should exclude each other but it happened to me.

See this thread for details. In there you will also find an explanation given by Ben, why that might happen)

Regards,

SBach