Parameters file for quick code updates
 

This year we're planning to add the ability to update our most frequently adjusted parameters via a file loaded onto the cRIO.

We're thinking that this will make code changes much faster since we spend a lot of time adjusting setpoints, limits and gains. We'll also be using this same technique to do a scripted auton.

Questions:

Are there teams out there that are using this extensively?

About how many variables are you managing this way?

Did you write any error checking to see if a value is being sent to the wrong place or is out of bounds?

Did you place this file read in "Disabled?"

Can this method actually create a global variable and assign it the appropriate value? I'm currently unpacking a file, reading the "name" and comparing this to the existing global variable name....then writing error info if things don't match.

Can any of this be done in real-time via the dashboard?

Thanks for your help.

Re: Parameters file for quick code updates
 

There are a number of variations that will make this work. It is possible to send the data from the dashboard at any point, and if this is your approach, I'd agree that disabled is a good time to have the data sent to the robot. To be field legal, be sure to use legal ports that will be open on a competition field.

If you want to read a file on the cRIO, I'd do it outside the main loop in RobotMain, perhaps in Begin. I'd read the values and update the globals there.

Greg Mckaskle

Re: Parameters file for quick code updates
 

One alternative that worked well for our team using labview was to simply have the gains/etc controls on the front panel. Then you just have to remember to set them as defaults (I've forgotten to this so many times...)

Of course, this only worked when we had our programming laptop attached and were "run"ing our code anyway.

Re: Parameters file for quick code updates
 

Is Begin called only once at power up? Or each time you disable?

I'd like to read new values in immediately after updating the files via FTP....without powering down.

Is there any special process supported for what we'd like to do? We're currently unpacking a file one entry at a time and writing the values to global variables. My issue with this process is that it seems very tedious and easy to mess up.

I did devise a simple error check based on the label name, but adding a new variable means adding new code to read it and check ing it for errors.

It would be amazing to support a Parameter File protocol of some sort that generated global variables directly from the file....is it possible to actually create a variable without manually adding it to the front panel?

Re: Parameters file for quick code updates
 

My team (Team 20) did this. We read in variable to control multiple autonomous modes. We do it while the robot is disabled. Recently, we switched to using virtual switches on he dashboard. We don't use it for anything teleoperated, but I won't rule it out as a possibility.

One thing to do is make sure you have a backup plan if the read fails. Error checking is key here. Don't was some variable set to an undefined value because the file failed to read for whatever reason.

Re: Parameters file for quick code updates
 

Currently the code writes the previous value if it detects an error...it then lights a feedback light on the robot to help diagnose the problem.

I hope to test it very soon.

Can the robot global data be exported to a list of names with values? Perhaps I can do things in reverse order to generate a text file.

Re: Parameters file for quick code updates
 

Begin is called once each time your app starts up. If you want to put the code in Begin, you only need to reboot the cRIO, not repower the robot.

If you wish to redo the globals more often, I'd recommend putting it in a subVI. Then you can call the subVI whenever you like, such as in disable.

If you want to simplify the code needed to update the globals, you may want to consider grouping globals together into larger groups, then look to using XML or another format to encode the values. Then you can use the Unflatten from XML to set all of the global cluster elements at once. The downside is that they are grouped and you'll need to use a named unbundle or similar to be able to access the elements of the global.

An alternate pattern for this is to use something like the refnum registry uses. You need to determine what the output types are and group globals by type, but then you can decide to use the runtime name and replace the globals entirely.

Greg McKaskle

Re: Parameters file for quick code updates
 

...I was actually writing code to do this not too long ago...

My plan was to save an array of constant/name pairs. I currently use something like this to lookup non-setpoint constants for the elevator (such as gains, limits, sensor calibrations, etc.) on a per-robot basis. What it basically does is stores an array of name/comp/pratice values, and finds the right one each time the variable is requested. I have no speed issues doing this, although I am only using it for about 20 constants.

I use a scripted autonomous system (Beescript) that allows me to write an auto script that looks something like this:
But due to the modular design of the interpreter, the list of possible commands (and the functions for these commands) is separate from the interpreter itself (I actually debugged all of the Beescript code using a function that popped up with message boxes in a blocking way). And I was thinking of just adding a command to set constant, then running the same interpreter to read the file. Writing the files would be even simpler - Just print a new line for each constant in storage, plus a few comments here and there.

Realistically, the LV interface is good enough for fine-tuning work. It gives me a UI to change variables and I don't have to write any code at all (always a good thing). What the script gives you is the ability to change constants rapidly, without re-downloading. The benefits are HUGE - seriously. This is awesome.

@ajlapp, feel free to use Beescript (get it here).

Re: Parameters file for quick code updates
 

For storing parameters on the cRIO, I think it would be a good idea to use INI files, which LV can handle pretty well. It's a nice section/key/value system that seems pretty good for storing robot parameters. (DISCLAIMER: I've not actually used this, my team is just planning on doing so next season. Your individual mileage may vary)

Read up on using configuration files in LabVIEW:
http://zone.ni.com/reference/en-XX/h...tion_file_vis/

And maybe on INI Files themselves:
http://en.wikipedia.org/wiki/INI_file

Re: Parameters file for quick code updates
 

I agree that ini files are a good option. I believe they work on the cRIO, but you should test it. BeeScript sounds like a great approach.

I'm curious if anyone downloads just their autonomous code changes? They are dynamically loaded, but built into the startup. I suspect that a small change to the build script would allow the compiled auto to be deployed, leaving the other code unchanged. Has anyone experimented with this?

Greg McKaskle

Re: Parameters file for quick code updates
 

They do work, we've used them.

Re: Parameters file for quick code updates
 

Joe,

Care to expand on your usage?

My CSV file approach seems to be working fine right now, but INI might be more scalable.

Also, Beescript does look great. We however are using the HibnerScript system (I just made that name up) presented by Chris Hibner at last year's World's event.

HibnerScript

His approach is remarkably simply, has a built in simulator and follows a state machine approach that I really believe in....so far all of his material has been rock solid. I'm very excited to implement it.

Re: Parameters file for quick code updates
 

Okay, I looked into the "Read Configuration File" VI. I modified it and I think I understand its utility.

However I'm not seeing how I can use this to implement my idea.

I've attached my Global Read VI. I apologize in advance for the mess, but it helps highlight my open issues. I think my solution will work well enough, but it doesn't feel easy to manage.

Maybe I'm looking for a solution to a problem that doesn't exist. With this strategy we have to create a Global Variable. We then have to update the Read File VI to assign the proper value to the variable and check its label to make sure someone didn't transpose something incorrectly.

Once this is done we should be able to update the CSV file, upload it and be on our way lickety split, but If we wanted 100+ parameters I wouldn't have confidence that we could manage this VI.

Maybe my idea is sound but I need to be more clever with an array and indexing of some sort?? Any suggestions?

Re: Parameters file for quick code updates
 

I:

-Have a single array of clusters which stores all of my data. Since I was not loading the data via script (but setting the constants in the array directly, via the front panel), I had a cluster which contained:
-String name
-Dbl comp
-Dbl practice

When I needed a constant in code, I called the get constant VI which:
-Got the array (it was a global variable)
-Got the robot (it was also a global variable)
-Ran a FOR loop on the array, which:
>-Unbundled the cluster (all of it)
>-Selected which constant it liked (what robot we are on) and output it (it ended up as an array of floats)
>-Compared the name string to the desired variable string
>-Output an array of booleans of the comparisons
-Searched the 1d boolean array for a True
-Case on the result
>Default: Index output float array for desired value, output
>-1 (not found) - Output NaN. This causes all math to fail and is bad, so it tells you VERY quickly that you made a mistake.

In LV, if you pass an array into a FOR loop without an i count, it will run the for loop as a FOREACH loop. When you pass a variable out of a for loop, it defaults to create an array of the values at each iteration (you can disable this by rt-clicking on the output and selecting "Disable Indexing" - this also works for inputs)

I only used this system for elevator calibration excluding elevator/wrist setpoints (those were stored in a separate array and indexed by the state), plus a set of modifiers which were indexed by modifier (both state and modifier were enumerated). So, things like analog limits (and their "sane number" counterparts), gains, anti-death boundaries, and such were stored in this (about 20 variables in all).

This seemed to me as the most sane way to handle large amounts of data in LV.

Edit: Added example. If you were to import the data from a file of some sort, I would just populate the array. If you spell something wrong in the file, then the code that requests the variable will get NaN.

Edit 2: Added another example which loads the data from your CSV into the array. I copypasta'd the CSV loading code from your gloal_read.vi

Re: Parameters file for quick code updates
 

Awesome. Both examples worked great.

How would you handle Boolean values? Would you have a separate array with just booleans, or maybe add a boolean value to the current cluster?