Hot off the press: v0.7 of the config widget, offering these enhancements:
Awareness of the current units, so if tinyg is in G20 (inch) mode, then all distance related data is shown in inch values with labels indicating inch, whereas if tinyg is in G21 (mm) mode, then all distance related data is shown in mm values with labels indicating mm.
Every setting’s label is now a link to the tinyg wiki where that value is described.
Fixed the auto-close when settings are applied, and corrected terminology in the drop down for the archive utility.
Awesome. I’m going to go check it out. I love the idea of linking to the wiki because I keep forgetting what the difference is for motor power setting of 2 and 3.
Not yet, but I will. Was talking with Riley about setting up a “schema” so the app could read and programmatically create tabs for all settings. Going to concentrate on that next.
Yah the “schema” is something we have been talking about for awhile. I would like to put something the wiki and just start having people chime in and help shape it. I will try to post something simple here soon.
My $0.02:
A $$ request reports lines of the form:
[parameter],string1=“parameter name” , parameter_value, string2=“units and/or other info”.
This from observation, not by finding the actual code.
The developers decide what should be reported/revealed, based on the FW’s ability to service requests.
How about the equivalent ‘json$$’ request with a json response?
Internally to tinyG, $$ and ‘json$$’ would return elements from the same array, either as text or in json format.
Objective is to keep the FW self-documenting/self-revealing, rather than dependent on a link that needs to be maintained.
A nice adder would be, for ReadOnly parameters, something like string2=“ReadOnly or Fixed Parameter”
Carl, the json$$ does not exist for the reason alone of building that huge string in memory. Its not possible according to @Alden_Hart1 I talked to him awhile ago about this. @Kevin_Hauser Great, I have some ideas as well that I have been writing down that we will need to handle as well.
@cmcgrath5035 , don’t tell Joe (who actually hasn’t been here since you first asked me to say ‘hi’ to him) but I decided to take 4 minutes out of my work day to post this… @Riley_Porter_ril3y I agree about the json$$ response … it would be missing a huge amount of information I hope to get from our work, such as min and max limits, type of data, enumerations where necessary, and maybe a helpful url. My ideal would be to create a structure that delivers this and groups the commands so that a full dynamic configuration utility could be created and automatically handle any firmware for which a supported argument schema exists.
So despite Riley’s extreme reaction to XML (LOL) that’s where I started. It’s easy to envision the data as JSON from such an XML format anyway … it’s just easier (for me) to model the data this way. That’s what I hope to show a part of later today.
Oh I did not understand the json$$ now I get it. This is basically what we are writing in JSON. Putting all that data in the firmware I think i is a bit heavy handed. Its not just values but urls for wiki addresses, hints etc. So what we have to Key on is hardware version and firmware version. So what we do is we map those keys to the remote json which the UI loads and enforces. I am working this now. I will post what I have in a min.
So I think @cmcgrath5035 was proposing a json-formatted $$ output whereas I am envisioning a stand alone data file that describes the possible settings. I’m not expecting the firmware to produce it. I’m expecting it to be another product of the build process, even if it is manually produced.
My suggestion of a "json$$’ , as I believe you both now interpret correctly, was to return the same content as is currently returned with text mode $$, and assume would continue to be in future tinyG FW releases, in json format that would be structured in such a manner to automagically set up Kevin’s GUI interface.
But I realize that Kevin has broader goals for the widget, which look interesting and helpful to users, so I am in watch mode for now on this discussion.