Another change I had to make to the CCC functionality was to the CCC Server (ccc_Server.vi) that runs on the cRIO system. When opening the TCP connection, you need to set the input "resolve remote address (T)" to False. There's no benefit to setting it to True that I have ever found, and if you try to connect directly to the cRIO (without going through an intermediate network), the system hangs for about 10 seconds or so until the request for address resolution times out. In the meantime, your app has probably given up internally and thrown an error or an impatient user has already Ctrl-Alt-Deleted and ended the program on the PC-side. Either way, it's no good.
This is a problem that I have encountered many times when developing TCP applications for the cRIO where you need the cRIO app to work both on a network and when connected directly to a computer.
So set resolve remote address to False, and the TCP connection can be made even when connecting directly to the cRIO. This is a nasty bug since you might not notice it until after you deploy your system for the first time.
The attached project uses a Status Tag4.xml for the Tag set. There is a unbound network tag under the HMI called tag.
Anyway if I don't watch for errors the CCC Client Write vi reports the error only once and the subsequent iterations return no errors. Of course the work around in watch for errors but it was quite hidden. This also affects data from being sent from the client to the server (using Sup Write to turn on ProcRead). Data sent from Server to Client works fine.