Issue Reports/Vems Tune - VEMS wiki www.vems.hu

IssueReports/VemsTune (2011-12-13 14:24:17)

Add issues/bugs to most recent release at the top

Do not forget to mention :

VemsTune version
V3 firmware version.
Zip and publish your saved config (vemscfg) and Tools/firmware/config download when appropriate.

Known issues

On V3 ECU newer than 2011 03 01 do not use coolant and air patch files with VemsTune older than 2011 03 23
Documentation needs to be added
CPU consumption and eye candy
- Graphics performance of gauges, multi graph, and all eye candy are dependant on certain combinations of hardware video drivers and wxWidgets.
- ATI graphics chipsets are known to have unreliable 2D grahpics acceleration.

Vemstune 2011-15-11

If created a table and changed table data to other then default the new layout is not being saved. Groups -> Groups editor -> new

Vemstune 16/6/2011

firmware 1.1.88

Vemstune is unable to load any config and brings up a message of SQlite unable to load database. i have already reported this through the report error module of vemstune.

it cannot load any config or log. I turned back to 20/1 version.

latest vemstune seems to work fine on windows XP

Old firmware trouble

Tried this on VT 06-04. If connecting to an old ECU which lacks an ini-file, then you should at least be given the option of downloading config and upgrading firmware. It was not able to connect to 1.0.71 to even enable any kind of upgrade path with VemsTune.

Here is a video of the problem : [27 MB download]

I used the old bat-scripts of 1.0.73 from MegaTune packages to upgrade to 1.0.73 and then up to recent firmware with VemsTune.

Will be fix in the next release.

VT 06-15

With older firmware, I tried 1.1.64, config validation complains about invalid output chosen for VVTi. This symbol doesn't exist until more recent firmwares.

Also got a config from a guy running 1.1.64, who on config validation not only gets the above (VVTi) but also a warning about too high cranking enrichment values, but the table looks ok ?

[screenshot] and [vemscfg]

Try loading the default configs that come with VemsTune, many of the older firmwares fail the validate config test. Some, like the above are bugs and others are "INVALID" values.

Config different with 05-27 vs 06-04

validate config reports bad anytrim settings which were good before.
fixed: config saved with 06-04 also misses the t, b, p, e and b tables.

The config files are here : [05-27] and [06-04]

Can't really explain any of it, and I'm not there to oversee it.

[Mattias]

Please download the latest version, and if the problem still exist, report via VemsTune / Help menu / Error reporting.

FIXED: VT 2011-06-04 flags fake warning

For the Audi trigger divide by 3 setup (default VemsTune/QuickStartAudi ) show a warning on validate.

also displays an error for the greyed out secondary trigger=25 raw value
- fixed since 2011-06-15
- was showing fake warning with rising edge (no warning when falling edge).
- since this was a 1-liner ini fix (configcriteria) maybe also fixed with earlier releases by ini-update ? Maybe, but new VT is better anyway!

In vemstune/config/include page-config-[version].ini

change sdcard_choice sdcard_choice = bits, U08, 149, [1] , "INVALID", "INVALID", "INVALID"

In to

sdcard_choice = bits, U08, 149, [2], "Disabled", "Enabled"

I don't know if its good but it works getting your knock working again in channel 0.

VemsTune 2011-05-27

(report by Mattias)

Overall : All windows with any kind of text in them are not possible to mark and copy text. This is very useful if you want to describe a problem or just cut and paste some information to anyone.
- F1 for help dialogs
- Verify config window

When making offline changes to a config, like changing values of a VE table, then pressing the remap button erases all changes you made. Very, very irritating.

In "injector settings" dialog:
- Strategy is not spelled startegy. Traditional is not spelled Tradicional.

In "PWM Idle control", make drop down for frequency wide enough
- only displays "00."
- should read "100.00"

Boost rpm bins should have reasonable defaults: 1000 rpm, 2000, 3000, etc.

In all 2D tables, when using remap function it should be possible to change the upper and lower most bins to more extreme values. Extrapolate from previous extremes?

Upgrade scenario

Done on a workstation with real serial port (COM1) running Windows XP (32 bit).

1. Install 2011-05-27

2. Start application

3. Enable comms, pick COM1, detection works straight away, ECU comes online and uses firmware 1.1.70 [config here].

4. Firmware validation complains about :

"Hall-dirac filtering" which doesn't even exist in this firmware.
iac_speed_step has INVALID value (40)
- [screenshot of validate config window]
- First you must enable stepper idle control to even access this setting
- Settings iac_speed_step to 61 (lowest value you can select in dialog)
- Disable stepper control. Now frequency changed for PWM valve. Change back to 50 Hz (common with Bosch valves) and you are back at square one.

5. Now upload new firmware 1.1.92. Some observations.

The "VEMS Message" window for flash upload and verify progress stay on top of ALL windows, should only stay on top of VemsTune main window. This might be happening with other windows too. Not a high priority to fix, only annoying if you work with other applications at the same time.
The "config upload" window that asks if you want to load default config makes it impossible/difficult to use Alt-Tab back and forth to VemsTune which always stays in the back and only comes forward if you click on the application window.

6. When the new config is uploaded to the ECU, the application hangs.

[vemstune hangs]

Second attempt. Ok. Restart VemsTune, now running 1.1.92 firmware after failed config upload, use the upload advanced (to A and B) function in the file menu, picking the latest 1.1.70 config file, conversion and upload goes well this time. Still, validate config fails on these points :

[screenshot of validate config window]
Secondary trigger Hall dirac filtering is not even in the old 1.1.70 firmware, and the default is "enabled" with 1.1.92 ? Set that do disable.
Also enabled is "LS1 forgiving", this should also be disabled by default.
Misc 1 and 2 output condition sensors have INVALID values, set these to Disabled in the default config.
Boost alternate settings use an INVALID control frequency, set this to lowest valid frequency.
Does not complain (like 1.1.70 and other firmwares) about stepper iac_speed_step, good.

Detection issue

Hard to understand exactly what happens. I did this on my Lenovo T61 laptop using a fresh install of 05-27.

Tested on WinXP, laptop has bluetooth COM port besides USB serial port adapter.
Go to dialog : Preferences -> ECU communication and enable communication. Press detect. Press close while detection is going on hangs the application indefinately but does not consume any CPU during that time.
The entire dialog is greyed out during detection, at least the part where the progress for detection is happening should not be greyed out (where it says which COM port it's trying). The close button is not greyed out, but pressing it hangs the application (described just above).
The detection process should be interruptible, and at least display what it's trying to do or waiting for.
In one test, with remote control through TeamViewer I started a freshly installed 05-27 VemsTune, after enabling comms and picking the COM port for the FTDI adapter (COM4) it brought up a "ECU detection" window with small progress bar, and just hung there (waited 5 mins) and could not close or interrupt the process (kill through task manager). Starting VemsTune again started the detection at once, and hung there waiting for detection (of something) indefinately (5+ minutes, as long as I had patience to wait).

Graphics issue

Still in 05-27, due to slow graphics on some laptops - it's a known problem but still worthwhile to bring up a scenario. Bringing up a simple table, like "warmup enrichment table" or "idle reference duty cycle", can bring graphics display to a complete halt in the active gauge group in the background. This needs to be fixed, wxWidgets must have some means of drawing all elements of the application without being interrupted, before continuing to make the next redraw. It seems only a few elements are redrawn, then interrupted by some kind of timer (too short time) and the redraw starts over, which leaves some elements never seing an update (most gauges).

INVESTIGATING: 2011-05-27 sometimes crashes before (or after) firmware upgrade (in same usecase, 2011-04-26 worked well)

upgrading from ... firmware ?
upgrading to ... firmware ?
- AIR=, CLT=
v3 serialnr= ? (purchased after 2011-03-01 ?)
at what step (exactly) does it crash ?
- when the box is stuck in bootloader mode, does VT crash repeatedly immediately after VT is instructed by the user to "stay" ?
- any message or pointer that could be useful ?

DONE: Issureport ergonomy improved after 2011-04-26, more userfriendly in 2011-05-27

VemsTune 2011-01-20

When changing from Celcius to imperial measurements in File->Firmware parameters, digital gauges do not change unit description.

Gauges move down by 73.3px and to the left by 1.3px on Main overview each time display is changed from group to group. Gauges shrink in size by 1px in horizontal and vertical directions each time as well. Example: view Main overview group, press Shift+8, press Shift+1. Repeat to watch gauges migrate down the page. Same thing happens if Main overview tab is closed and reopened.
- How do you mean "73.3px", and "1.3px"? You can move and resize every windowed items only by whole integer value.

If all gauges are removed in gauge edit mode, then a gauge file is imported, gauges are added twice and in different positions.

Fixed items

May not appear until next release.