Cannot Deploy Code

[Alan Anderson]

I don't know if it can be called a solution, but closing the Dashboard application is an effective workaround. If there's no SmartDashboard communication going on, deploying code works as it should.

[rfolea]

We are seeing the same issue ...

[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

[rfolea]

Thanks for the update Greg!

[wolfeman]

Greg,

I'm not using the smartdashboard at all and am having fits with
the 8-slot cRIO. The 4 slot ones are working fine.
I simply cannot deploy code to the 8-slot with symptoms similar
to those described by others in this thread. I can successfully
"run as startup" right after imaging and then subsequent "run as startup"
attempts just hang. You can't cancel the dialog - you have to kill Labview.

I have two 8-slotters and they both were fine last year. The only
workaround I've found is the no-app dipswitch. Having that
on allows me to "run as startup" successfully.

pete, team 2590

[Alan Anderson]

Originally Posted by wolfeman

I'm not using the smartdashboard at all...

You misunderstand. It's not a program called "smartdashboard" that's the problem. It's the "smart dashboard" protocol that the cRIO uses to communicate with the Dashboard.

For now, just terminate the Dashboard before you attempt to send code to the cRIO, and the symptoms you're seeing will go away.

[wolfeman]

I dont' have the dashboard, smart or otherwise, running at all.
I'm just have labview up. I still have the "waiting for RT target"
problem. It's only for the 8-slot cRIO.

[Greg McKaskle]

As a test, can you open RobotMain and delete the SmartDashboard Server icon. It is just below the while loop.

Then do the NoAPP switch or whatever you need to do to deploy the new code. Then try a regular deploy.

Greg McKaskle

[Alan Anderson]

Originally Posted by wolfeman

I dont' have the dashboard, smart or otherwise, running at all.
I'm just have labview up. I still have the "waiting for RT target"
problem. It's only for the 8-slot cRIO.

Just so I understand completely what you're describing: do you have a Driver Station connected when this is happening?

[wolfeman]

Thanks, I'll try that out. I was assuming that this thread
was referring to running the dashboard on the driver's station side
vs. the dashboard component on the cRIO side... If
it's the cRIO side, that explains why No App works - the
run at startup code doesn't run and so the cRIO-side
dashboard code doesn't run.

[Greg McKaskle]

The bug that was discovered is on the cRIO side. The bug is that a deployed app that uses the new Asynchronous Call by Reference will not abort properly when it is a part of a deployed app. When I implemented SmartDashboard, this is how I chose to handle multiple connections from different clients. Each client connection is handled by spinning up a unique independent VI that self-terminates when the connection closes. This means that if any client is running and attached to the cRIO, it has a piece of server code running for it, and the RT bug means that the deployed app cannot be aborted.

So, the workaround being described is indeed to close all client SmartDashboards such as the Dashboard.exe. That should be sufficient to workaround the RT bug until the new update which will not use the new asynchronous node, but will use an older technique that takes a few additional VIs.

My suggestion of removing the Server will ensure that there isn't a connection from another computer like a programming laptop that is causing the "waiting" dialog. If this happens without the Server even running, then the plot thickens and there is another cause for this.

Greg McKaskle