Latest LCode version

[NEtech]

So we agree on removing "Expert user"

 

[Sebastian]

No, but the standard behavior when being started externally (w/o VCDS) should be to allow bit selection.

If this was a first release of a new assist/tool, I'd agree of this being an expert view/functionality but since both LCode 1 & 2 have always behaved this way, it's IMO not good practice to change this behavior - especially w/o notice.

 

[Boki Ar]

Thank You!

Then you see a button [Remove VIN

1150600F492A00FB880E06E792220041BF0C00
11666066496600668866066692660041BF0C00 insert 66 VIN
11__60__49__00__88__06__92__0041BF0C00 w/o VIN

I like it

 

[NEtech]

Latest download here.
{2.1.8.0 - 9.Oct.2023}
{Changed text appearance in About}
{Bug not showing bit selection without expert user setting}
{Bug not showing bytes from search in every Byte}

 

[NEtech]

Latest download here.
{2.1.10 - 15.Feb.2024}
{Polish translation}
{Czech translation}
{Fix bug in experimental view}

 

[NEtech]

Latest download here.
{2.1.11.0 - 18.Feb.2024}
{Problem with ; within text string}
{Removed support for TOD files}
{Byte values in Statusbar not correct}

 

[hadez16]

I finally pushed myself discarding the old LCode and start using the new LCode....
Excerpt from label file:

LC,09,0,Market,0=ECE / 1=NAR
LC,09,4~7,headlamp_coding_word (HEX)

Why is LCode not displaying that placeholder label "headlamp_coding_word (HEX)" ?
It only says "none found".

EDIT: I just tried 2.1.11.0, same behaviour.

 

[Sebastian]

Because the syntax in your example is incorrect.

 

[hadez16]

The syntax comes from the label file which was not created by myself, it's a grabbed experimental label from Unit 4B (3Q0-907-338).
The old LCode does show it:

 

[NEtech]

I can look at it, but experimental data is loaded in experimental "mode" (yellow screen).
Is it not loading okay, when it is standard label format file?

 

[Sebastian]

IMO LCode behaves as expected here, the input data is incorrect due to VW supplying incorrect data. This is why "experimental data" should not be used as a standard, only as a fallback.

 

[hadez16]

IMO LCode behaves as expected here, the input data is incorrect due to VW supplying incorrect data. This is why "experimental data" should not be used as a standard, only as a fallback.

VW datasets incorporate the translation to LCode label files? Didn't know about that....

I can look at it, but experimental data is loaded in experimental "mode" (yellow screen).
Is it not loading okay, when it is standard label format file?

Does the "yellow mode" read label files different to "normal mode"?
It is just a label file with a description of a bit-range that worked in old LCode but not in new LCode

 

[Uwe]

the input data is incorrect due to VW supplying incorrect data.

Is it incorrect, or just incomplete?

I would guess the newer LCode wants at least some values for the bit field?

@hadez16, try:

LC,09,4~7,00,Headlight Type 1
LC,09,4~7,10,Headlight Type 2
... and so on.

-Uwe-

 

[hadez16]

I try to clarify again: this is *not* a custom label file created by one individual, it comes like this out of VCDS for the experimantal coding!
So there is either some issue with LCode by having changed the expected syntax for bit-ranges, or some issue with VCDS because it does not follow that new syntax

 

[NEtech]

To clarify, that label file is not public available.

Does the "yellow mode" read label files different to "normal mode"?

Yes, "yellow mode" data is "Machine made".

It is just a label file with a description of a bit-range that worked in old LCode but not in new LCode

Is a bug in old LCode

 

[AINils]

I have access to a car (my own) with this ECU tomorrow in the evening. Can try different things if some help is needed

 

[NEtech]

And as Sebastian wrote incorrect syntax.
What should LCode show, for that string, HEX, 00, 10, 20, 80 etc. !

 

[Sebastian]

@Uwe @NEtech let's discuss this internally.

 

[hadez16]

I just tested this at my car.

"Yellow mode" does it correct:

Why the hell does "yellow mode" read that piece:

LC,09,4~7,headlamp_coding_word (HEX)

...differently compared to "normal mode"?

Some reason for switching back to buggy old LCode

 

[Sebastian]

Step 1: Understand, that you do not know all context.
Step 2: Understand, that you are using data in a way it was never meant to be used.
Step 3: Understand, that this is not a problem a regular user would ever see/experience.