NetworkTable Client Questions

[Araknos]

In the past, I have used the SmartDashboard vis in my Labview Dashboard code, but this year, it seems to have gone missing from the WPI Robotics Library. As a result, I have had to use the base for SmartDashboard: NetworkTables.

This is the first time I have used NetworkTables directly, and I had a hard time figuring it out due to the lack of Labview help (or even javadocs on the robot code side), but after a hard day's work and searching, I got it working.

I know that the server hosting the NetworkTables and values is the roboRIO and that the Dashboard is a client. I know how to run the NetworkTables viewer and collect data about the current state of the server and tables.

However, I do not completely understand the mechanics behind the NT Client vi in the Dashboard.

I noticed that the Bind Controls to SmartDashboard vi contains the NT Client vi, and that when I added additional instances of the NT Client vi, even with unique names, the communication between robot and Dashboard would stop working.

My hypothesis is that only one instance of the NT Client vi, somewhere in the vi hierarchy, is required to establish communications via NetworkTables, and that multiple instances will cause the Dashboard to stop working.

Am I correct? Why does this library behave this way? Is there a better way to do this?

Thanks in advance for your help.

[Greg McKaskle]

Sorry for the naming confusion.

In previous years, the SmartDashboard VIs prepended /SmartDashboard/ to the variable name and were promoted as the main VIs that you'd use for robot<->dashboard communication. We decided to simplify and combine the functions.

In 2016, a variable name that doesn't start with / will be prepended with /SmartDashboard. If you are writing lower level stuff, just use absolute paths. So then, which name to use since they are now merged? We decided to go with NetworkTables for the overall name.

To your question about the client. NT Client is the root VI for a client. Bind wraps it with some messaging hooks for the control binding. A given LV context only needs one client running. We could put in some prevention code to keep a second instance from doing any harm, but that doesn't exist. The reason why only one client is allowed to run is that the network table storage is implemented with functional globals that aren't instanced to the client. Architecturally, we only expected one server and one client per process.

Happy to answer other questions or confirm other spelunking observations.
Greg McKaskle