[Greg McKaskle]

I know the problem and have a solution, but we were wanting to batch any updates a bit.

The complication is that the design requires that the SmartDashboard server supports connections to multiple clients. Each client opens a TCP connection to port 1735 and gets its own session. That means that the server creates a TCP listener and loops waiting for clients to connect. As each connects, it spins up a unique handler for that client session. There are several ways to spin up an arbitrary number of handlers, and the one I chose, the new one with simpler syntax called the Asynchronous Call by Reference node, has an issue in the corner case of being deployed on RT and being asked to clean up all independent VIs so that the controller can be targeted by a different project.

The RT runtime will correct the corner case, but this year the solution is to use the slightly older Run method and open my own instances to the handler VI and assign the parameters using the ByName method. Not much work, not much risk, but it is painful enough to have one update, so we are waiting just a bit to see if anything else is reported.

The workaround, as Alan mentioned is to exit the SmartDashboard clients. When they close their connection, the server handler completes and the Waiting issue doesn't occur. So you don't need to kill the DS, but the DB and any other SmartDashboard clients.

We hope to have a patch released in a few days.
Greg McKaskle