Confirmation after page burn to ecu possible?

[Zaphod]

Hi,

I really like the latest TS version and would like to use it istead of Megatune (especially because of the nice possibilitys of the dash).
But I have a little problem - I made some changes to my MSQ yesterday (boost open loop to boost closed loop) and pressed the burn to ecu button.
After a while I noticed, that my changes where not burned to the MS. (Maybe I closed the menu too early)

Would it be possible to add a confirmation, when the page is entirely burned to the ECU? (Same with the whole MSQ)
I am never quite sure, when the burn is finished...

Thanks

[LT401Vette]

It will print a burn message in the lower right corner.

But I really tried to eliminate all that burn confusion, what you said happened, should not happen in TS unless there is a bug. TunerStudio automatically takes care of burns. Any time you close a dialog or write to a new page, a burn command is sent. So you should never need to click burn.

[jsmcortina]

It will print a burn message in the lower right corner.

But I really tried to eliminate all that burn confusion, what you said happened, should not happen in TS unless there is a bug. TunerStudio automatically takes care of burns. Any time you close a dialog or write to a new page, a burn command is sent. So you should never need to click burn.

Oh, that's a little confusing.
Sometimes if I've made a mistake in entry I will intentionally close the dialogue without burning so the data is lost!

I agree about the message though, when loading an MSQ I'm never quite sure when it has done.

Also, when connecting to the ECU I've found that I can open a menu before TS has finished reading from the ECU and get all zeros or other funny stuff.

James

[Zaphod]

^Thanks, I'll keep an eye on this.

[LT401Vette]

Oh, that's a little confusing.
Sometimes if I've made a mistake in entry I will intentionally close the dialogue without burning so the data is lost!

I tried to think like a new person. I have seen a lot of people that were using megatune for over a year and still get confused over what is local verse on the controller. So TS tries to make sure they always stay the same. To undo something, I put in undo / redo buttons that are more commonly found in applications. The down side is that if you have already gotten used to the way Megatune works, you can expect the same results.

Oh, that's a little confusing.
I agree about the message though, when loading an MSQ I'm never quite sure when it has done.

I think the biggest reason that gets confusing is because the msq usually loads so fast as TS only sends the changes and does it in another thread so it doesn't hang the application. It does say in the bottom left corner that it has done. The blue bar streams across while it is still writing, if there is no blue bar cycling across, it is done. I have made it pop a dialog when finished, but that ended up seeming like a pain. Perhaps I should come up with a way to make the info in the lower left corner more pronounced? If you hold the mouse over it you get all the historical messages.

Also, when connecting to the ECU I've found that I can open a menu before TS has finished reading from the ECU and get all zeros or other funny stuff.

Yep you will, but the values should turn to the correct values once they have been read. I have thought of putting a delay on opening dialogs if that segment of memory hasn't been initialized yet. The same as if you open the same dialog twice, any changes you make in one will immediately appear in the other.

I try to think about how the app should work if you are looking at it walking in fresh, not expecting it to work like MegaTune. Also, there are several behavioral difference driven by core application design. Many of MegaTune's behaviors are do to it's limitations of being a single threaded synchronous app. Almost everything in TunerStudio works asynchronously with call backs. This is why it doesn't care about having a bunch of dialogs open at the same time, or the same dialog open 2 times and the dash and data logs can continue to run while you have the dialogs open.

All thoughts on what is confusing or can be more straight forward are very much appreciated, just try to think about whether it is confusing because MegaTune did something different, or you think it will be confusing to someone starting fresh.

[tristanlee85]

Just my input here... I have seen th indicator at the bottom-left of the app that shows me what the burn has completed, but sometimes I am still in doubt if it fully burnt. The only reason is, when you burn a MSQ, I believe it says something like Burned Page 1, Burned Page 2, Burned Page 3, (or however many pages there are) and while there is a progress bar indicating the state of the burn, I do not know the MS code well enough to know how many pages are left to be burned. For all I know is, the last text in the indicator could mean that the application is hanging on burning that page since the indicator doesn't change until you change something else.

I hope I didn't lose anyone there. I don't know what data is readily available for you to display, but say I modified boost controls params, maybe something like "Boost Control set (12:33:05)" or whatever. I think a time and maybe a better description of what's going on would be helpful for those who are not fully aware what it means to "burn a page". Also, maybe a timer of some sort could be used to display the status for say 10 seconds, and then go blank.

That's all I can think of though. I do agree that a dialog after every burn would be very annoying. I think displaying a time of the last burn or maybe displaying an indicator that eventually fades away (like when someone signs on to their instant messenger and a notification pops up then fades away).

[jsmcortina]

I agree with Tristan, I've also been thinking, "is that all of them?"

James

[LT401Vette]

Makes sense... I almost think I was falling for the MegaTune mind set when putting the page number in there . If the page was burned, it really means all writes have been burned. I'll revamp that message. I like the fading message idea.

It seems there are probably 2 user categories.
The majority of users probably don't know or want to know about writes verse burns. They just want to change the settings and be able to safely assume the changes are saved to the controller.

Higher control users, users who either are very familiar with the write burn concepts already or do a good deal of bench use. There are certainly times that the higher level of control is beneficial.

For one, I'll think about what I may be able to do with the messaging, but also perhaps put in an option to disable automatic burns. Perhaps this option is only enabled by editing the properties file. There are really 2 places that burn commands are sent:
- Dialog closed
- Write sent to different page
I'm thinking only disabling the automatic burn when dialogs are closed, still doing automatic burns when the write page changes, otherwise data loss will happen unintentionally. Primarily if you have either a complex dialog with panels from different pages, or if you just have 2 dialogs open at once. For example the Spark table and the VE table. Make changes in the VE table, then the spark table, your ve changes are lost if the automatic burns are performed.