Parameter locking/hiding [SOLVED]

[johu]

As more boards are rolled out it seems to be an increasing issue that people change parameters that make absolutely no sense to change and just disturb normal operation (like encoder type on a Tesla motor).

I thought of introducing a new command:

Code: Select all

flag <parameter> hidden/~hidden

(other flags possible in future)

Basically those parameters would no longer show up in the "json" "list" and "atr" command (and thus not on the web interface). Even setting them with the "set" command could be inhibited. The hidden status would be saved to flash.

Of course before hiding a parameter it can be set to its appropriate value.

Any other ideas?

[damian.lo]

Hello,

Like already You knows, I have Your board v2 connected with Leaf sync motor. Also like You maybe remember I asked You about some parameters, which changes had no sense in my case
And now: maybe will be possible to make a list of parameters which are important for motor types and then will be visible only important group for me and rest will be hidden? Something like batch - hidden list.
And other: now if my motor is working it is easier, but for totally newbies like I was some weeks ago was important to have something like step by step parameters setting. I know, that something like this You have on website, but from my POV is missing explanation how this board-brain takes parameters and what impact have changes for working and other parameters. Do You know what I mean? Other thing is of course to find time to write this explanation for us

[johu]

I have just pushed the source code for this to github. Haven't made a new release yet.

So like said, you can type

Code: Select all

flag boost hidden

This will hide the parameter "boost" from the "list", "json" and "atr" command and thus the web interface. It is still possible to set the parameter on the console though. Likewise

Code: Select all

flag boost ~hidden

Will show it again. When parameters are saved, the hidden flag is saved along with them.
Their value stays unaffected, so you can set a parameter and then hide it.

The flash image is backward compatible with some limitations. As long as no parameters are hidden, older versions can read the flash image of the current version. The current version can always read older flash images. If you do hide a parameter and save to flash, older firmware versions will not be able to load the parameters and you will end up with default settings. You can still use the parameter download/upload function of the web interface, though.

I might merge in some more changes and make a new release soon. Meanwhile you can test by compiling yourself. Instructions on github.

[doobedoobedo]

I've been perusing your code and have had a thought that I'd like to share.

I'm not going to profess to know all that's going on in there yet as I'm not particularly familiar with C++ (my C is nearing passable ), but I'm an Oracle database dev by trade so bear with me.

You build the web interface based on parameter data and for some common configurations some of the data is irrelevant.
If you were to have a dropdown in the web UI with a choice of common configurations eg.tesla, leaf etc. You could store an additional field in your parameter structure (a single byte would be enough for a short list of flags) as to whether to show with the chosen configuration. Defaulting to show all.

Feel free to tell me why it's a terrible idea.

[johu]

Actually I think thats a good idea. I'm not quite sure if the firmware is the right place for it as there are quite many motor/inverter combos out there.
I'd rather add that info to the parameter files. So where it now says

Code: Select all

{
  "boost":20
}

it would say

Code: Select all

{
  "boost":{"value":20,"hide":true}
}

But hands up everyone if you want default parameter sets in firmware, set also hide irrelevant parameters.
In that case I'd add a parameter called "loadef" that you could set to "LeafGen2", "Tesla", "Ampera" etc. Contribution wanted!

[doobedoobedo]

Excellent . I'll trust your judgement on how best to implement.

I think default parameter sets would make it much more accessible.

[dima]

I think motor specific parameters should just be handled outside of controller. Maybe a dedicated "Motor Database" forum section?

[johu]

Apparently it's possible to link mediawiki to the phpbb user table (https://www.mediawiki.org/wiki/Extensio ... ntegration). So then we could have a wiki for all sorts of things including a page on motor setup. I believe you can allow arbitrary downloads on mediawiki that can be linked to that motor page.
Having a thread or section on the same document might be a bit hard to use?

[johu]

I installed an article extension as you might see. The integration is not really good, it created a white and lightgrey menu bar instead of using the existing one. Anyone knowledgeable how to fix this?
Can someone try to edit the Motor Parameter article?

[dima]

Edit this file ext/ger/cmbb/styles/all/theme/cmbb/modu ... tyling.css

color: #000000;

Code: Select all

#main-menu > li > a {
    display: block;
    line-height: 35px;
    padding: 0 20px;
    color: #000000;
    text-transform: uppercase;
}

EDIT: OK I did it, had FTP permissions.

[johu]

oh I was wondering why there was no change
Do you think the "Articles" link could be places in the blue bar next to "Members"?
The other 3 links are actually redundant.

[doobedoobedo]

Something needs to be done with it - it's white on light grey and hence almost invisible.

[johu]

Oh, Dima did it. Looks brilliant. Now, can everyone edit the article?