Incorrect data type when writing to FPGA Read/Write Control

Question

I have run in to a problem this morning that is causing me substantial headache.  I am programming a CompactRIO chassis running in FPGA mode (not using the scan engine) with LabVIEW 2012.  I am using the FPGA Read/Write Control function to pass data from the RT Host to the FPGA Target.  The data the RT host is sending comes from a Windows host machine (acting as the UI) and is received by the RT Host through a network published variable.
The network published shared variable (shared between the RT and Windows system) is a Type Def cluster containing several elements, one of which is a Type Def cluster of fixed point numerics.  The RT system reads this shared variable and breaks out the individual elements to pass along to various controls on the FPGA code's front panel.  The FPGA's front panel contains a type def cluster (the same type def cluster, actually) of fixed point numerics.
The problem comes in the RT code.  After I read the shared variable I unbundle the cluster by name, exposing the sub-cluster of fixed point numerics.  I then drop an FPGA Read/Write Control on the RT block diagram and wire up the FPGA reference.  I left click on the FPGA Read/Write Control and select the cluster of fixed point numerics.  I wire these together and get a coercion dot.  Being a coercion dot hater, I hover over it the dot and see that the wire data type is correct (type def cluster of fixed point numerics), but the terminal data type is listed as a cluster containing a Boolean, code integer and source string, also known as an error cluster.  I delete the wire and check the terminal data type on the Read/Write Control, which is now correctly listed as a type def cluster of fixed point numerics.  Rewiring it causes the terminal to revert back to the error cluster.  I delete the wire again and right click on the terminal to add a control.  Sure enough, a type def cluster of fixed point numerics appears.  Right clicking and adding an indicator to the unbundle attached to the network shared variable produces the proper result.  So, until they are attached to each other, everything works fine.  When I wire these two nodes together, one spontaneously changes to a error cluster.
Any thoughts would be appreciated.

Answer 1

My apologies I never got back to responding on this.  I regret that now because I got it to work but never posted how.  I ran in to the exact same problem today and returned to this post to read the fix.  It wasn't there, so I had to go through it all over again.
The manifestation of the problem this time was that I was now reading from the Read/Write FPGA front panel control and writing to a network published shared variable.  Both of these (the published shared variable and the front panel control) were based on a strict type defined cluster, just like in the original post.  In this instance, it was a completely different cluster in a completely different project, so it was not a one-off thing.
In addition to getting the coercion dot (one instance becoming an error cluster, recall), LabVIEW would completely explode this time around.  If I saved the VI after changing type definition (I was adding to the cluster) I would get the following error:
Compile error.  Report this problem to N.I. Tech Support.  Copy cvt,csrc=0xFF
LabVIEW would then crash hard and shutdown without completing the save.  FYI, I'm running LabVIEW 12.0f3 32-bit.
If I would then reopen the RT code, the same crash would occur immediately, ad nauseam.  The only way to get the RT code to open was to change the type defined cluster back to the way it was (prior to adding the new element).
I didn't realize it last time around (what originally prompted this post), but I believe I was adding to a type def cluster when this occurred the first time.
So, how did I fix it this time around? By this point I tried many, many different things, so it is possible that something else fixed it.  However, I believe that all I had to do was to build the FPGA code that the RT code was referencing.  I didn't even have to deploy it or run it... I just had to build it.  My guess is that the problem was the FPGA Reference vi (needed to communicate with the FPGA) is configured (in my case) to reference a bit file.  When the development FPGA Main.vi ceases to match the bit file, I think that bad things happen.  LabVIEW seems to get confused because the FPGA Main.vi development code is up and shows the new changes (and hence has the updated type def), but when you ask the RT code to do something substantial (Open, Save, etc), it refers to the old bit file that has not yet been updated.  That is probably why the error getting thrown was a compile error.
I'm going to have to do an additional round of changes, so I will test this theory.  Hopefully I will remember to update this post with either a confirmation or a retraction.