So I came across this yet again just this week. I'll provide a few details and then mention how I got around it once and for all...
The issue is always the same. I have a cluster type def that is used on a cRIO system. It is found on the FPGA, the RT intermediary and the host. The FPGA stuffs the collected data to a front panel indicator of the type def'd cluster. The RT system reads this front panel indicator and immediately writes it to a Network Shared Variable (based again on the same type def'd cluster). The host then periodically reads the network shared variable (NSV) so that it ultimately ends up with the data the FPGA took. The RT portion of the cRIO really does nothing than act as a communication gateway between the FPGA and the host.
When I want to add a new control to the cluster, I open the type def from the project and modify it. I then open the FPGA code and find that the front panel indicator is indeed updated. I write the code to acquire the value and stuff it in to the front panel cluster. That all works great. However, the simple act of opening the RT code makes LabVIEW (2014) absolutely explode. I get a crash report and LabVIEW evaporates. I open the RT VI again and exactly the same thing happens (over and over again). If I open the type def and remove the item I just added, the RT code opens fine. So, I leave the RT code open and I modify the type def. Everything seems great... I can program to my heart's content. If I save the new RT code, LabVIEW explodes again.
I'm able to eliminate this behaviour if I change the FPGA reference in the RT code. You get three choices here... reference a bitfile, reference a build spec or reference a VI. I originally was referencing the bitfile. If I changed this to reference the build spec, LabVIEW no longer explodes when I change the type def.
Unfortunately I was still having communication problems. Everything should have been working fine, but the host VI was just getting the default value. I talked with some colleagues and they suggested not using NSVs unless absolutely necessary. I converted each NSV operation (open, write and close) with the equivalent network stream operation and it worked like magic. After the initial success I had to add some code to handle things like dropped connections and the like, but I can now add items to the type def cluster at will and everything updates like it was made to.
My takeaway on this is two-fold: Don't use NSVs unless you have to and don't reference the FPGA bitfile in your RT code unless you have to. I'm sure there are cases where these must be done... I'm glad this was not one of those cases.
