Weird dashboard gauge/ini quirk

For discussion of Phil Tobin's Tuner Studio software (Only about the tuning software itself, not about how to tune or firmware features)

Moderator: LT401Vette

Post Reply
msoultan
Super MS/Extra'er
Posts: 1021
Joined: Sun Jun 27, 2004 12:04 pm
Location: Long Beach, CA - USA

Weird dashboard gauge/ini quirk

Post by msoultan »

Hey Phil,
I've been doing some testing with the new expanded temp gauge stuff and James noticed a problem with celsius settings. I'm posting this now, but when I get home and can connect my tuning computer to the internet, I'll upload my updated megasquirt-ii.ini file so you can try this out on your machine. Anyways, take a look:

- load ts, set to celsius and deactivate expanded_clt_temp. clt gauge should show -40 to 150 (low range). close ts. save dash if asked.
- Reopen ts and activate expanded temps - no change to clt gauge (showing low range).
- reload dash, gauge updated with new temp range (showing high range).
- deactivate expanded temps - do not save dash - gauge updated (showing low range)
- activate expanded temps - gauge not updated - reload dash - gauge updated (showing high range)
- deactivate expanded temps - do not save dash - gauge updated (showing low range)
- activate expanded temps - gauge not updated - reload dash - gauge updated (showing high range)
- deactivate expanded temps - SAVE dash - gauge not updated (showing high range!)
- reload dash - gauge not updated (still showing high range!)
- quit ts - save dash
- load ts - gauge not updated
- load dash - gauge updated

I threw in a few extra steps there as a sanity check. Pretty much if you load TS, activate expanded temps, reload gauge, then deactivate expanded temps and save, you won't be able to reload the dash to get the correct temp range without quitting TS to force a read of the megasquirt-ii.ini

It seems as though something quirky when saving the dash, even though the dash was not really changed. In other words, if you change a preference when using celsius, you're asked to save the dash even though the dash wasn't really changed. I'm not sure if this has to do with the nested ifs in the INI or if it's or it's just a bug, but I thought I'd letcha know regardless.

I guess one interesting fact is that this only happens with celsius, not with fahrenheit. When you hop back and forth with fahrenheit, everything works as expected.

thanks!
Mike
msoultan
Super MS/Extra'er
Posts: 1021
Joined: Sun Jun 27, 2004 12:04 pm
Location: Long Beach, CA - USA

Re: Weird dashboard gauge/ini quirk

Post by msoultan »

Hey Phil,
Attached is my INI. Let me know if you need any more info.

thanks,
Mike
LT401Vette
Super MS/Extra'er
Posts: 12697
Joined: Sat Jul 16, 2005 8:07 am
Location: Moorseville, NC
Contact:

Re: Weird dashboard gauge/ini quirk

Post by LT401Vette »

I think I can shed a little light on this for you... Before we go into what can be done, let me give you a quick run down on how the Dash files work...

The dash board file is detached from the ini files (mostly I'll get to this). The ini really only provides templates for the predefined gauges (I'm thinking I should rename this to Gauge Templates) and the "Default" Dash is generated purely from the ini file. The others are ones that I made for each of the Firmware families and are provided in the app.
But by generating the Default dash from the ini, you can be sure to have at least 1 working dash for any firmware even if I haven't made one by hand.

However it should be noted that any dash you select, even the "Default one becomes it's own file in your project. So if you apply changes to the setting, they won't necessarily show up in your Dash unless you reload the dash from the menu "Load Dash". Even the Default dash is only used as a template for that first load, after that it is just the projects dash.

The thought here is that the dash should be detached as users would likely want to customize mins, maxes, redlines... and not be tied to the original template values in the ini file.

From what you said above, I think you already understand how this is working. :)

Now comes the exceptions... :)
Because different settings can really drive up the number of dashes I would need to manually create to support all the different combination, I am doing this instead:
- All my Custom Dashboards are created in Fahrenheit and AFR.
- Then during Dash loads I check if Celsius is set and and the gauge is in Fahrenheit, I look for a Gauge Template from the ini with the same Output Channel assigned, and apply those min's and maxed, and swap out the labels.

So, that is why you are being prompted to save the dash, because your dash was edited. The Fahrenheit gauge was swapped out for the C one based on the template.
If you don't save, then the next time you load the dash, it will still be the Fahrenheit one and it will be swapped out with the new extended values gauge in C.
However, if you do save the dash, it will now be saved with the temp gauges in C, so next time it loads it will be seen as your saved dash with the units you had set, so it won't mess with your mins and maxes.

Similar if NarrowBand is set or there is no afr channel, I find the O2 gauge template and replace the afr gauge with that.

So currently to be sure your extended temp values are applied you either need to right click on it and select the Predefined gauge, or re load the dash with a right click --> Load / Save --> Load Dashboard

Need to think through this though, because technically it seems like Fahrenheit would be the broken one if you are not using the "Default" dash, the Ext Temp ranges would never get applied unless you right click the gauge and select the predefined gauge :(.
Phil Tobin
EFI Analytics, helping to simplify EFI
Next Generation tuning software.
Supporting all MegaSquirt versions and firmwares.
http://www.TunerStudio.com
http://www.efiAnalytics.com/MegaLogViewer/
Support the firmware running your engine:
http://www.msextra.com/doc/donations.html
msoultan
Super MS/Extra'er
Posts: 1021
Joined: Sun Jun 27, 2004 12:04 pm
Location: Long Beach, CA - USA

Re: Weird dashboard gauge/ini quirk

Post by msoultan »

LT401Vette wrote:The dash board file is detached from the ini files (mostly I'll get to this). The ini really only provides templates for the predefined gauges (I'm thinking I should rename this to Gauge Templates) and the "Default" Dash is generated purely from the ini file. The others are ones that I made for each of the Firmware families and are provided in the app.
But by generating the Default dash from the ini, you can be sure to have at least 1 working dash for any firmware even if I haven't made one by hand.
Ok, here's where I think we need to differentiate things. First, I would rename the default dash to something like "INI-based dash (read-only)" or something similar. This will let the code authors set up their own INI-based dashes that they feel are best and it's very obvious to the user where the gauges are being generated from. If a preference is changed or something else (not having to do with gauges or the dash layout) is changed, the user should not be asked whether or not they want to save the gauges because the one their using is based on the INI - the appropriate changes (i.e. change from F to C) should just happen as you'd expect them to.

Now, if the user does make a change to the dash, upon quitting or doing something that would require a save request, they should be prompted to save the dash under a different name. This makes the user very aware of what's going on and would be much more intuitive.

So, that is why you are being prompted to save the dash, because your dash was edited. The Fahrenheit gauge was swapped out for the C one based on the template.
If you don't save, then the next time you load the dash, it will still be the Fahrenheit one and it will be swapped out with the new extended values gauge in C.
However, if you do save the dash, it will now be saved with the temp gauges in C, so next time it loads it will be seen as your saved dash with the units you had set, so it won't mess with your mins and maxes.
Like I mentioned above, if the user is using the INI-based dash, they should never be prompted to save the dash if nothing on the dash was changed. This is regardless of what is happening underneath, especially because the end-user has no idea what's really happening under the hood. It is especially confusing if the user is asked to save the dash when they haven't actually made a change the dash - I understand that changing from F to C changes the actual gauge on the dash, but that should not be considered a change to the dash - it's a project setting that is assumed to be saved to the project and the dash adjusts accordingly per that project setting (that's how I'd assume things would work).
msoultan
Super MS/Extra'er
Posts: 1021
Joined: Sun Jun 27, 2004 12:04 pm
Location: Long Beach, CA - USA

Re: Weird dashboard gauge/ini quirk

Post by msoultan »

jsmcortina wrote:Just a few thoughts here.

As I said in the other topic, being able to change the settings right there in Tuner Studio is so much more intuitive and easy to use - great!
Yeah, I think it is an awesome feature, however, I would still think there should be a default set of ini-based, read-only gauges and dashes that are distributed in the INI by the code authors and not by the tuning software authors (phil, you'd obviously help). I think this is important because it keeps the tuning software authors (phil, eric, dave, etc) from having to adjust their gauge panels every time the code authors (bruce, al, james, ken, etc) make a new feature and want to have the changes roll out as quickly as possible. Giving the end-user the flexibility to change their dash is nice, but I think it would be even better for the code-authors (or dash designers) to spend some time designing a bunch of default dashes that are released in the INI such that the user rarely even needs to change their dash because everything they'd need is right there. They might change their default dash, but never change the actual limits within the dashes.

Should the user decide to change their gauges, then they'd need to save their changes in a new dash config. Unfortunately you then run into problems when the code authors release a new version of the code with updated dashes. I'm not sure how you (phil) would mitigate those differences but I think starting with a good set of default dashes is the key. I rarely ever change the MT dash as it has most of the information I need - if you provide a good set of dashes, I think you will keep the majority of users happy.
On the temperature settings. The way it presently is within the Megatune ini is a little funky already where each gauge must be redefined and such. If there was a way (maybe there already is) to globally set "coolant temp max" and use that through out instead of #ifdef-ing each gauge then maybe that would be easier.
Maybe in TS this could be a special case to prompt the user "You have changed the global temperature settings -> Update project and dash?" Then update the CLT gauge and all of the temperature related settings / curves.
What might be interesting is what phil mentioned in another thread (http://www.msefi.com/viewtopic.php?f=104&t=34077) about overriding the standard MT settings with TS-specific gauges/ini-based dashes with max temp specifications. The problem is that everything that is TS-specific ends up duplicating MT stuff just so it's backwards compatible with MT which would probably be more work than it is now.

The other thing that is bad about TS-specific stuff is that it doesn't play nicely with other current/future tuning software. We already got into this mess with MT so I think it's really important that everyone (bruce, al, james, dave, phil, etc) start discussing global standards and conventions and a plan of attack to move away from MT gracefully (if that's the plan) instead of everyone designing their own custom thing. Then the code authors would be able to push out new features without worrying about what tuning software they're breaking.
Post Reply