Neil Pate's post in Unable to Access Shared Variable Programmatically on CompactRIO Real Time Target was marked as the answer
Sorry, sounds like you know more than I do about shared variables. Can you see the variables using the Distributed System Manager?
Have you taken a look at Network Streams? I find them much easier to setup and debug when things don't work. Think of them as TCP/IP with all the re-connection and other management stuff taken care of.
Neil Pate's post in It takes couple minutes to open class private data .clt in small project was marked as the answer
Could it be default data saved in the class "cluster"?
That or mutation history as James suggested are the only things I can think of that would make the .lvclass file so big.
Neil Pate's post in For-loop in case structure on FPGA was marked as the answer
The rules of data-flow are still valid, the value of the Triggered indicator is taken from the tunnel going into your for loop, so will have the same value for every iteration of the loop as it is really only "sampled" once on the very first iteration of the loop.
One thing to add, perhaps put in a control in the path of the Timed Out? feedback node to allow you to reset the timed-out latch, this can be useful during development.
Neil Pate's post in Built classes directly into an exe for dynamic loading. But now the installer builder claims that the files can't be found in the built exe? was marked as the answer
I use Inno Script Studio to generate the actual installer. There is nothing I can actually think of that caught me out, other than it just took some time to figure everything out (like admin rights, banner graphics, unlocking directories etc).
Neil Pate's post in Preventing System-Style Controls From Resizing With OS Font Settings was marked as the answer
Fonts in LV do suck quite a bit. I use system style controls exclusively for GUI type FPs.
I normally shove these settings into my LabVIEW.ini and app.ini file
appFont = "0" 13
dialogFont = "2" 13
systemFont = "1" 13
BDFont = "2" 13
This way the fonts are consistent between OSs that do and do not support high res fonts (i.e. WinXP). I have just tested it out with Win7 set to 150% (I normally use 100%) and it also works fine. These keys also stop the BD getting messed up when a VI is edited on a WinXP and then a Win7 machine (due to font size differences). Note: I have only a vague understanding of what these keys actually do, but they work for me I think these settings force the app to use the fonts specified, and the sizes, so they are not affected by font changes. I have seen similar settings where the actual font is specified (i.e. appFont = "Tahoma" 13 etc) Not sure this is exactly what you are after, but its worth a try.