Trim Sw and Trainer switches

[GoogleCodeExporter]

Bertrand

In model SETUP, there is still 'Trim Sw'. Is this still supposed to be there, 
now that there is a similar option on the new FUNCTION SWITCHES screen?

Also, the ability to set what switch to use for Trainer is no longer on the 
TRAINER screen but moved instead to the FUNCTION SWITCHES page.

Both of these seem counter-intuitive to me. I think that the trainer switch 
should be set on the TRAINER scree, like it used to be. I also think it's 
better to have "Trim Switch" right next to the trim options, in the model SETUP 
screen, no?

I do like the functions switches screen. But I don't think this is a good use 
for it. 

Also, although I decided to get rid of the 'TRIMS to Offsets" function, I have 
a local user here who would like the option to work that way for some things. 
Would it be easy to have that function added back to FUNCTION SWITCHES?

Another good thing to have on FUNCTIONS SWITCHES would be to assign a switch to 
get straight into telemetry view. Whilst I do prefer the new "telemetry in main 
views" thing, it is actually quite frustrating not being able to just use [DOWN 
long] to go straight to telemetry view, like we used to. So at least having a 
function switch for that would be good.

I would like to resolve all of the above before committing to stable, as we 
plan to do soon, if that is reasonable and agreeable to you.

Original issue reported on code.google.com by gru...@gmail.com on 4 Oct 2011 at 8:00

[GoogleCodeExporter]

No problem. My concern is that I have seen too many times people using the same 
switch for both trainer function and instant trim function. Then I thought it 
would be better to have these switches configured in the same screen so that 
they know what they do.

My idea was to remove this TrimSw from the model setup screen, right! But I can 
leave it as it is, you decide!

No problem for the "Trims to Offsets". It's somewhere in my workspace.

Only reports then, could be quick. Let-me know what you would like to see here!

Bertrand.

Original comment by bson...@gmail.com on 4 Oct 2011 at 8:10

[GoogleCodeExporter]

Ah yes I remember now about the same switch for multiple things issue. It is a 
valid point. Hmmm. I'll sleep on it.

Cam, are you reading this? Care to venture an opinion?

In the past, we have tended to sort of 'catch' ourselves doing the task of 
trying to prevent others doing silly things and realised that the project 
shouldn't suffer for the sake of silly things people haven't actually done yet. 
(If you get my meaning.) My thinking now, before I sleep, is tending that way. 
Comments welcomed.

Original comment by gru...@gmail.com on 4 Oct 2011 at 9:56

[GoogleCodeExporter]

Ok then, it seems urgent to wait a little bit :)
Bertrand.

Original comment by bson...@gmail.com on 4 Oct 2011 at 10:03

[GoogleCodeExporter]

Yes indeed. We must hurry up and wait, quickly and we must wait without further 
delay! :P

I really cant decide. On the one hand, I really want to have the trainer switch 
assignment on the trainer screen. On the other hand, it is too easy to forget 
that instant trim is configured and try to use the trainer function. Also, 
trainer activation should be a model set-up decision, not global.

I thought of all kinds of complex ways to try and protect users from accidental 
double-assignment. Nothing much seems practical.

It simply remains that Instant Trim is a very, very dangerous function. That 
and only that is the real problem here. I really don't like that just one 
dangerous function forces us to make the rest of the project difficult to 
understand. 

My preference would have been to move the trainer switches back to the TRAINER 
screen and leave Instant Trim in Function Switches. Since Instant Trim is the 
dangerous function, it should be that function that takes on the responsibility 
to be safer, if it can. Therefore, Instant Trim should examine the Trainer 
Switches and if it is assigned to the same switch as any of the trainer 
assignments, it should NOT activate. Perhaps it could have a little '!' appear 
next to its switch assignment, too? But no, this doesn't really work because ..

This is still problematic, because the TRAINER stuff is in the global set-up 
menus, not model menus. Clearly, the activation of trainer or not should be on 
a per model basis, not global -- but the actual configuration of the PPM_IN 
system probably should still be global. So once again, we arrive back at having 
trainer activation in the per model Function Switches menu.

Bottom line? I guess it has to stay how it is now -- but mostly because trainer 
activation needs to be per model, much less because of anything to do with the 
very dangerous Instant Trim function.

Original comment by gru...@gmail.com on 4 Oct 2011 at 9:36

[GoogleCodeExporter]

TrimSw removed to be consistent with current state.
Trims2Offsets needs to be reported back.

Original comment by bson...@gmail.com on 7 Oct 2011 at 5:29

• Changed state: Started

[GoogleCodeExporter]

Trims2Offsets re-added. Shouldn't we open a new issue to avoid mixing 
everything between stable and future release?

Original comment by bson...@gmail.com on 10 Oct 2011 at 9:51

[GoogleCodeExporter]

Yes -- always. But this was needed for stable release, because there's people 
here waiting for it who use that feature! (Much to my disgust. :P)

This issue is finished with. Quoting from above ...

"Bottom line? I guess it has to stay how it is now -- but mostly because 
trainer activation needs to be per model, much less because of anything to do 
with the very dangerous Instant Trim function."

Original comment by gru...@gmail.com on 10 Oct 2011 at 9:12

• Changed state: Fixed

[GoogleCodeExporter]

It was already per-model you know, remember the traineron bit in the model 
structure.

Original comment by bson...@gmail.com on 10 Oct 2011 at 9:25

[GoogleCodeExporter]

Yes, I realised that later on in the above text, I believe. That's why it made 
so much sense to keep things as they were.

Original comment by gru...@gmail.com on 10 Oct 2011 at 9:56