Using Network Tables for Configuration Parameters

[jdaming]

What is the best way to send configuration parameters to the robot? Here are some features I am looking for:
Ability to change parameters without reloading code
Able to push changes to the parameters from drive station and or programming computer. (bonus points for not needing LV to do it)
Easy to change parameters.
Easy to setup and configure the use of the parameters
Robust

I have done this before with configuration files. Something similar to here.  I think this is the "standard" way to do this. Things I don't like about it include: pain to transfer the file, getting LV to reload that file on demand, a lot of customization to set up everything related to this, and a poor interface (usually just a text editor) to update the file.

I mentioned this question on an episode of FUN and Greg McKaskle recommended Network Tables, but I have really seen almost no information / examples about people using network tables extensively in LV. Several questions about this:
I know you can double click on things in the variables tab and "log" them, what does that actually do? I found out that you can shift double click to remove that which I hadn't seen documented anywhere.
Can you only manipulate the Network Table variables by default in Test mode?
Is the idea here to create a new interface on the dashboard (or a separate program) to update the NT variables and then read them down on the roboRIO? Is there a simpler way to do this?
If the log function above doesn't handle it how do you make these setting "persistant"?

[BoKnows]

I saw the CD post first.  I'll copy/paste my response here for those that find this thread instead of that one:

Take a look at the Autonomous Selector code.

You have a control on the Dashboard. It uses the NT Read to get the values from the Begin VI's NT Write.

It also has the NT Write related to the user's selection that gets read in the auton VI to determine which case to run.

Replicate this behavior:
Create an appropriate control somewhere on your Dashboard (I suggest creating a tab for the configuration values)
In the dashboard code, use the NT Write to write these variables.
In the roboRIO's code, use the NT Read to get the values.
Build your startup executable and deploy it.

When you want to tweak the values, do so on the dashboard.

[MarkBalla]

In WPI Lib there is a pallet call Dashboard.

In that pallet are the NT (network table) vis these are the vis that allow you to send custom data between your robot and dashboard. 

I believe these are the vis that Greg was referring to.

I like using these for items that are not static and need to be changed during a competition. it requires that you create a custom dashboard. 

[jdaming]

The CD post seemed to die with these questions does anyone here know the answers?

Still have these questions unanswered:
I know you can double click on things in the variables tab and "log" them, what does that actually do? I found out that you can shift double click to remove that which I hadn't seen documented anywhere.

Can you only manipulate the Network Table variables by default in Test mode?

If the log function above doesn't handle it how do you make these setting "persistant"?

How does the system handle complex data types?

I noticed there is a write raw and write variant, but only a read raw (no variant), why?

I tried placing my cluster into the variant but it looks like it puts it through a flatten to string which removes all type def info so that when I read it out its all garbled.

[BoKnows]

I'll answer some of those.  The rest, I'd have to look deeper to get you an answer.

What do you mean by manipulate?  Sending a value by NT Write could be considered manipulation.  That can happen wherever.  If you try to edit them while the code is running, don't be surprised if you get yourself into a race condition between yourself and your code to edit those values.

If you want to make them persistent, I'd add some code to write the values to an INI file as they change and read from that INI file on startup.

By complex, I'm assuming you mean things such as clusters more so than complex numerics.  But, I'll answer both.  Numerics can be handled the same was as clusters or by splitting into the real and imaginary components and saving each as their own numeric and then combining on read.  Clusters can be handled by either the Variant or Raw entry.  Send them through and convert back into your cluster on the other side.

Why?  I don't know.  I imagine the tables themselves have to have something they can "display" and a Variant won't handle that.  I'm sure there's a use case for variant that I'm missing.  Although, if you look at the implementation of both, the variant option chooses Raw internally and flattens to string.

I'm guessing you missed a step here.  If you use To Variant on your cluster and push that into the Write NT (Variant), you're correct that it flattens to string internally.  You can read this string from the NT Read (Raw) entry.  When you do this, you'll want to first use Unflatten from String with a variant constant as the data type.  That will provide a variant output that you can wire into the Variant to Data vi with a matching cluster constant wired into it.  This should remove your data just fine.

If you miss that step, typedefs will likely throw an error and the data you get will be garbled.  If you get that step, you should be able to reconstruct your data.

[Greg_McKaskle2]

Double clicking a variable sets the persistence flag. Shift double-clicking clears the flag.

Persistent variables are saved to an ini file on the robot about once a second. I think the file is located in /home/lvuser/LabVIEW\ Data/persistent.ini But I don't have a controller with me, so the file could be saved somewhere else. When the robot code starts its NT server, it loads the values from the ini file to create and initialize the variables.

Note that any client and the robot can still write to a variable or even change the persistence. Persistence is primarily for initialization.

Writing to an arbitrary variable from your DB involves making a custom DB from a template.

You can make a specific write call on the diagram to update a variable, or you can name the control or indicator the same as the variable and let binding keep them synched. The name binding is accomplished by putting a control or indicator in one of the bound tabs (Basic and Custom are synched by default). Other tabs or variables can be added if they are added to the binding array.

Test mode uses network tables to communicate the values back to the DB, but it is mostly about directly seeing I/O values and directly updating actuators.

Complex data types are best handled by writing them to the variant form of NT. You can then read them as Raw and cast to the original type. There is actually a Read Variant in vi.lib/Rock Robotics/Network Tables. It should have been in the polyVI, but doesn't seem like it made it. If you look at the VIs, the Read Raw and Read Variant are essentially the same and both must be cast to the original type anyway.

If you read the complex cluster and unflatten it to your cluster, you should see your value become ungarbled.

Greg McKaskle

[jdaming]

Thanks Greg that answered the questions I had.

We ended up using a configuration file as we were still having problems working with the variants.  When I get some more time with the bot I will dig deeper and try to set up a simple reproduction project.

We used MGI Read/Write Anything to speed up the complex data type write and read.  And used webdav to pass the file to the RIO.