Subpage of Help index
For support, the following is required so that we can review the setup and help:
1) Editable thematically organized page (separate page for each project). Preferrably: according to this
2) Reasonable description of engine, trigger wheel, igncoils, output wiring; anything special, and any effected input. (for 20VT motronic55 : auxiliaries on SSC6 or econoseal10, and deviations from standard would be listed)
3) See the "validate check" in VT, and declare that there are no VT-validation errors. Otherwise full listing of VT-validate errors and while they are considered acceptable instead of fixing
4) Triggerlog (first without ign and inj; but also with ign and inj) ... and vemslog ; Notes about what seem good and bad with them; try to separate experienced symptoms from guesses. Eg.: "in ... log at 3:42 igadv is ... but I would expect ... because..."
Note: VT calc model (SHIFT+5) shows details/intermediate results for spark advance (fuel pw, iac, ...): useful to see which firmware functions / config variables contribute to the final result.
Step 1-2) applies always (even pre-purchase, for preparation of components to buy).
Step 3) applies after 1st powerup and communication with controller.
Step 4) applies for any no-start condition or RPM-jerk, or camshaft-control related procedure (best to do it always anyway).
Please note that cooperative behavior is required for support.
Bypassing steps, not mentioning important details (about pre-life of ECU/install also) misleads support crew (=> drawing wrong conclusions)
=> makes it virtually impossible to support (and support requirements must be met for support obviously).
Follow steps, and be clear about what is intended, what procedure is followed, what exact steps have been completed, what is the result of each;
which have been bypassed (sometimes justifiable) and why. What is not according to expectations and in what way, what indications show this
(and what can be shown to a remote party). What is feeling, conclusion, symptom, measurement, intention (try to clearly separate these and mark as such).
Might seem a bit long but it isn't. It saves time (if applied) from the very first issue, and saves a lot of time for any complex or tricky situation
(which initially usually looks like "just a simple question" of course). Please read
How to Report Bugs Effectively
article and while you read, think about similar non-software examples that happened, or could happen.
It will help you (and your partners) in all areas of your professional career, for granted.
VemsTune can help with steps 3-4. In simple trivial cases that might be enough (usually 1-2 also required).
Creating attachments from VemsTune / Help / Sharing (or Issue-report) menu:
In the message box:
Please provide a detailed description of the found error e.g. when does it occur, what are the observations; A good description is imperative for the developers to be able to recreate,
narrow down and fix the potential offending behaviour.
Minimum VemsTune version in which in VemsTune error reporting is available: 0.20.26. 2010-02-10.
Find earlier shared report / issue by key: