Member
Revtor. You are the man and the new NCS for Dummies is perfect for coding the CIC module and enabling VIM! I just coded my first CIC VIM today!
Member
that's what I changed-
PARZUWEISUNG_FSW : {00003000} 00000017 0001 1C5E {} (FF) {h} {} // SPEEDLOCK_X_KMH_MIN_C0E
PARZUWEISUNG_PSW1 : 0007 (FF) // aktiv
PARZUWEISUNG_PSW1 : 0008 (00) // nicht_aktiv
PARZUWEISUNG_PSW1 : 05E3 (08) // 8_kmh
PARZUWEISUNG_PSW1 : 0636 (03) // 3_kmh
PARZUWEISUNG_FSW : {00003000} 00000018 0001 1C5D {} (FF) {h} {} // SPEEDLOCK_X_KMH_MAX_C0E
PARZUWEISUNG_PSW1 : 0007 (FF) // aktiv
PARZUWEISUNG_PSW1 : 0008 (00) // nicht_aktiv
PARZUWEISUNG_PSW1 : 05E2 (0A) // 10_kmh
PARZUWEISUNG_PSW1 : 0636 (03) // 3_kmh
Member
Originally Posted by ARGOS
PARZUWEISUNG_FSW : {00003000} 00000017 0001 1C5E {} (FF) {h} {} // SPEEDLOCK_X_KMH_MIN_C0E
PARZUWEISUNG_PSW1 : 0007 (FF) // aktiv
PARZUWEISUNG_PSW1 : 0008 (00) // nicht_aktiv
PARZUWEISUNG_PSW1 : 05E3 (08) // 8_kmh
PARZUWEISUNG_PSW1 : 0636 (FF) // 3_kmh ------change from 03 to FF
PARZUWEISUNG_FSW : {00003000} 00000018 0001 1C5D {} (FF) {h} {} // SPEEDLOCK_X_KMH_MAX_C0E
PARZUWEISUNG_PSW1 : 0007 (FF) // aktiv
PARZUWEISUNG_PSW1 : 0008 (00) // nicht_aktiv
PARZUWEISUNG_PSW1 : 05E2 (0A) // 10_kmh
PARZUWEISUNG_PSW1 : 0636 (FF) // 3_kmh ----change from 03 to FF
Member
PARZUWEISUNG_PSW1 : 0007 (FF) // aktiv
Last edited by ARGOS; 04-15-2012 at 02:32 PM. Reason: Automerged Doublepost
Member
Member
I sincerely apoligise if this specific topic is a repeat. . .
Is it possible to disable a module function that contains sub-functions IF that primary function only shows a single possible value in the FSW file? An example:
From e39 lcm.c18 FSW - KALTUEBERWACHUNG Seems to be the Primary Function for Cold Monitoring. However there are not any associated "wert" values with it except for "01". I really just want to disable ALL cold monitoring functions. . .(even the sub-functions that may not be listed in the FSW)
KALTUEBERWACHUNG COLD MONITORING
wert_01 value 01
KALTUEBERWACHUNG_AL COLD MONITORING LOW BEAMS
aktiv active
nicht_aktiv not active
KALTUEBERWACHUNG_BLK_HI COLD MONITORING REAR TURN INDICATORS
aktiv active
nicht_aktiv not active
KALTUEBERWACHUNG_BLK_VO COLD MONITORING FRONT TURN INDICATORS
aktiv active
nicht_aktiv not active
KALTUEBERWACHUNG_FL COLD MONITORING HIGH BEAMS
aktiv active
nicht_aktiv not active
KALTUEBERWACHUNG_NSW COLD MONITORING FRONT FOG LIGHTS
aktiv active
nicht_aktiv not active
Member
That's a question that can only be answered on a case-by-case basis. In the case of function "KALTUEBERWACHUNG" in the E39 "LCM.C19" module I'm afraid the answer is no. The problem is not really coding a different value for this particular function, but I don't think the function has anything to do with disabling or enabling the cold lamp monitoring. If you enable "control unit data" in NCS Dummy you can see the "KALTUEBERWACHUNG" function spans an entire byte (mask FFh). That means this function can have any value between 0h and FFh (0 and 255) - regardless of the fact that the module description file only has one value defined (74h - "wert_01"). It's completely pointless to waste an entire byte in the module's coding memory if all it represents would be enabled or disabled. In other words, function "KALTUEBERWACHUNG" has very likely a different purpose.
If you want you can still experiment with different values for "KALTUEBERWACHUNG", though. Nettodata coding is not possible on older bimmers like the E39, but the disassembly method described in the opening post should work to get custom values in there.
Member
Thanks Revtor - awesome software - saved me a ton of headache!!!
I was afraid that this would be your answer -looks like I'm sourcing a LCM IV allowing me to get more granular with cold monitor functions!
Member
Revtor: Thank you for the nice piece of sofware!
I was just wondering, have you thought making a NSC Dummy as a web service? As advantage there could be different language versions and community-based data update and also possibility to add comments etc?
A friend of mine could possibly code the system, if someone could make a good specification.
What do you think about that?
And another question: I have 0.5.0.5 and the trace editor -tab is missing. What have I done wrong?
Last edited by Larppa; 04-26-2012 at 03:25 PM.
Member
Larppa: I don't like localization. I prefer a single language, that not everyone may speak fluently but at least the majority will understand, over shattering the knowledge over many languages that only (relatively) small groups understand. With regards to the webservice idea, keep in mind that quite a few NCS Dummy users use the application on a computer with limited, no permanent or no Internet connection at all...
Concerning the trace editor: it's only available when you have loaded a trace file.
Member
it would be cool to generate a nettodat.trc with ncsdummy using only a fsw_psw.trc file.
ncsdummy could read out the hex-values of the CBD by reading the values of the fsw_psw.trc?!?
could you implement this feature?
at the time you only can generate a nettodat.trc when we loaded a nettodat.trc
when you load only a fsw_psw.trc you are not able to generate a nettodat.trc
Member
ypoc: I'm aware of that, but it seems to be more complicated than you would think. For example, nettodata lines normally begin with B but as you probably know there's also an alternative syntax using a masked notation where lines begin with M. A short excerpt from the E38 "KMBI_E38.C12" module:I know exactly how to interpret both, but I'm clueless as to why the M notation is used and more importantly how to know when to use it. This behavior is not described in the CDB module description file...Code:M 00000002,0001,00FF,000B B 00000003,0001,0000 M 00000004,0001,CFFF,0EFA B 00000006,0008,FFFF,FFFF,FFFF,FFFF,0000,0000,0000,0000
Another strange thing is that for some modules the nettodata trace file is missing entries that are nonetheless defined in the CDB file. For example, the E31 EKM nettodata trace file is missing address range F6h to FBh. Using ToolSet32 the missing bytes can be retrieved and they match the meaning given in the CDB file. So why aren't they included in the first place?
That's why at this moment NCS Dummy will only create a "NETTODAT.MAN" manipulation file if a "NETTODAT.TRC" trace file is loaded. NCS Dummy will then just mimic the input nettodata trace file. That way one can be sure the "NETTODAT.MAN" file always has the correct layout. Until we know exactly what causes the anomalies (and I'm afraid that's in the *.PRG files), I cannot guarantee correctly generated nettodata files from scratch.
But even if we can work around that, I don't think generating nettodata from FSW/PSW trace files is a good thing to do. A lot of data is lost in the conversion from nettodata to FSW/PSW trace files. A conversion in the opposite direction would leave the nettodata incomplete and very likely with with incorrect data...
Member
ah ok...i understand that problem.
thx for explaining
i just found out how to generate a nettodat file of a specific ecu without beeing connected to a car.
u have to use a ssd file to simulate the car. in this ssd you can write the type of the car and what VO and production-date the specific car must have.
after that you can generate a nettodat file of the cbd of the ecu of your choice.
it is very nice to compare the coding differences of different production-dates or VO configurations
Last edited by ypoc; 05-02-2012 at 05:48 AM. Reason: Automerged Doublepost
Member
copy: where do you get this .ssd from? I searched in NSCExpert to save such a file after reading the VO, to load it from file later on to do excatly this. But I did not find such ...
Member
you have to creat it....like this one
just delete the .txt
Member
Thanks a lot, I'll surely get rid of this. But which app is able to create this file ... or, how did you get it?
Member
manual creation
how it works you can read in the helpfiles of ncs
its easy to create
M E90_CODIERSCHL ALL <- there you write your model...in this case E90
A 001 WBAPP31030A7502352 <- the A and 001 are always the same...followed by the VIN...but this vin has not to be the real vin
E90_*PR96#0914%0475&LUSW$1CA$1CB$205$216$226$235$2 49$255$320$386$402$413$423$428
$431$441$473$481$488$493$494$4AD$502$508$521$522$5 34$548$563$609$610$612$614
$615$616$633$677$6VC$6FL$6nf$6nr$6aa$6ab$6va$761$7 75$7SP$840$851$863$879
$8SC$9BE <- this line is the same as you will find in your FA.TRC file in your ncs work directory...if you want to create a file, you can copy that line out of the FA.TRC file and paste it in the ssd file.
|0000000|0000000|0000000 <- don´t realy know about that but i let it where it is
to create a ssd for a E46 or E39 you have to write the ZCS after the vin...but this is explained in the help of ncs....
Last edited by ypoc; 05-02-2012 at 08:32 AM. Reason: Automerged Doublepost
Member
Hi Bimmerforum Members
please excuse my bad english, i'm from germany
i've already learned much from the Bimmerforums, helped me quite a lot, but now i have a problem, where i'm stuck, and i'm hoping for good advise
i'm capable of coding lot's off funny stuff into my e38, including a LCM-4 for automatical driving lights. my new project is a e30 convertible with an m60 v8 engine.
Parts are nearly complete, i have a convertible with broken engine, and a second, very smooth runging m60 including 6gear manual transmisson from a bj94 e38.
My "Problem" is the following:
i want to retrofit the ABS and the ASC from the e38 to the e30, Parts are easily swaped, and most will work plug&play, but i want to use the Instrument-Combination (IKE) from the e38. The e38 was the last generation without an EWS, so no problem there, but:
The e38 IKE generates it's speed signal from the ABS-Sensors, wich would deliver wrong values, since the wheel-diameter is a different one. i did a little research and found out, that the Instrument combination has a integrated factor to translate the rotations of a wheel to an actuall speed signal.
i've done no netto-data coding so far, because i didn't need it until now.
i've checked up in NCS-Dummy and found the folling points:
these numbers should be responsible for the impulse/speed conversion. i've calculated that (if the 4486 is for the e38 and the 4571 is for the e39) i would need 5094_imp/km to get a prescise speed signal.Code:K_ZAHL_TACHO_KOMPL 000000AE (02) 4571_imp/km EE,24 4486_imp/km EE,79 K_ZAHL_TACHO 000000BA (02) 4571_imp/km 11,DB 4486_imp/km 11,86 K_ZAHL_WEG 000000BC (02) 4526_imp/km 02,0E 4441_imp/km 01,B9 K_ZAHL_WEG_KOMPL 000000BE (02) 4526_imp/km 1D,F1 4441_imp/km 1E,46
i don't know how to continue, and i also don't know why there are 2 different values in the upper and lower to K_ZAHL blocks.
i've read the manual many times, and i'm not sure if it is even possible to write that netto coding data to make a e38 IKE fit into an e30.
the values behind the speed informations (EE,24 / EE,79) are the deciaml values for: 65535-4571 / 65535-4486, so i would need 65535-5094 ->Code:K_ZAHL_TACHO_KOMPL 000000AE (02) 4571_imp/km EE,24 4486_imp/km EE,79
so it should be EC,19 (this is an easy one i think because the mask is FF,FF)
am i right?
the values behind the speed informations (11,DB / 11,86) are the deciaml values for: 4571 / 4486, so i would need 5094 ->Code:K_ZAHL_TACHO 000000BA (02) 4571_imp/km 11,DB 4486_imp/km 11,86
so it should be 13,E6 (this is also straight forward, isn't it?)
am i right?
this is where i'm stuck, first off all, there's a mask included, and i haven't fully unterstood how it's used, second: i can't find the full value (perhaps of the mask), and third: these values are different from those above.
if one can ausume linearity, the value i would need here, was: 5043
the 01,B9 is decimal for 441, the first three digits (same with the value below)Code:K_ZAHL_WEG 000000BC (02) 4526_imp/km 02,0E 4441_imp/km 01,B9
both values in decimal are (3224+value) (is the mask responsible for this?)Code:K_ZAHL_WEG_KOMPL 000000BE (02) 4526_imp/km 1D,F1 4441_imp/km 1E,46
this is how far i've come whilst making my brain only hurt a little bit.
am i on the right path?
is it possible to fit this IKE into an e30, is there a more simple solution for what i'm trying to accomplish?
how shall i continue?
some advice would be really helpfull
thanks in advance!
greeting from germany
andrej
Member
The "K_ZAHL" functions with "KOMPL" in the name have inverted (complementary) binary values. I am not really sure why BMW uses the complementary values, but it is found in other BMW models as well. It might have been intended as an extra barrier against odometer fraud. Take for example function "K_ZAHL_TACHO" parameter "4571_imp/km":So you are correct in your calculation of "K_ZAHL_TACHO" and "K_ZAHL_TACHO_KOMPL" for 5094 impulses per kilometer:Code:4571 = 11 DB = 00010001 11011011 = K_ZAHL_TACHO K_ZAHL_TACHO_KOMPL = 11101110 00100100 = EE 24 = 65535 - 4571"K_ZAHL_WEG" and "K_ZAHL_WEG_KOMPL" are again complementary values, but this time the decimal values in the parameter keywords do not translate directly to the hexadecimal data. However, an interesting observation can be made looking at the decimal values of both "K_ZAHL_WEG" parameter values:Code:5094 = 13 E6 = 00010011 11100110 = K_ZAHL_TACHO K_ZAHL_TACHO_KOMPL = 11101100 00011001 = EC 19 = 65535 - 5094Both values have an offset of 4000. Strange, yes, but not uncommon (for example the E31 speedometer scale coding uses an offset as well). You want value 5043 impulses per kilometer for "K_ZAHL_WEG", so that becomes:Code:4526_imp/km --> 02 0E = 526 --> 4526 - 526 = 4000 4441_imp/km --> 01 B9 = 441 --> 4441 - 441 = 4000But what's up with the complementary values? Let's take "K_ZAHL_WEG" "4526_imp/km":Code:5043 - 4000 = 1043 = 04 13We got FD F1 as complementary value, but we know from NCS Dummy that the correct value is 1D F1... What went wrong? Nothing actually, but we forgot about the mask. Masks are used to reduce the bit width. The mask for "K_ZAHL_WEG" and "K_ZAHL_WEG_KOMPL" is:Code:4526_imp/km --> 526 = 02 0E = 00000010 00001110 = K_ZAHL_TACHO K_ZAHL_TACHO_KOMPL = 11111101 11110001 = FD F1Out of the 16 available bits in the 2 bytes, only the least significant 13 bits are used. So let's retry to determine the complementary value:Code:MASK = 1F FF = 00011111 11111111
That's more like it. Now we can calculate the complementary value of 5043 impulses per kilometer:Code:MASK = 1F FF = 00011111 11111111 = 8191 4526_imp/km --> 526 = 02 0E = 00010 00001110 = K_ZAHL_WEG K_ZAHL_WEG_KOMPL = 11101 11110001 = 1D F1 = 8191 - 526So to summarize, the values you are looking for are:Code:MASK = 1F FF = 00011111 11111111 = 8191 4526_imp/km --> 1043 = 04 13 = 00100 00010011 = K_ZAHL_WEG K_ZAHL_WEG_KOMPL = 11011 11101100 = 1B EC = 8191 - 1043
- K_ZAHL_TACHO_KOMPL (5094 impulses per kilometer) = EC 19
- K_ZAHL_TACHO (5094 impulses per kilometer) = 13 E6
- K_ZAHL_WEG (5043 impulses per kilometer) = 04 13
- K_ZAHL_WEG_KOMPL (5043 impulses per kilometer) = 1B EC
You can forget about nettodata coding. Nettodata coding is something for newer bimmers only. You will have to modify the NCS Expert DATEN files and even this is not always guaranteed to work. But it's your best option at this moment. You can modify theNCS Expert DATEN files through the NCS Dummy disassembly and assembly tool. The quickest and easiest approach would be simply disassembling the E38 "IKE.C02" file and change the hexadecimal values for the for the currently selected parameters, but the nice way is to add new keywords. Disassemble the "NCSEXPER\DATEN\E38\SWTPSW01.DAT" parameter keywords file and append following keywords:i've read the manual many times, and i'm not sure if it is even possible to write that netto coding data to make a e38 IKE fit into an e30.Values 0597 and 0598 are the identifiers. Identifiers can have any value from 0000 to FFFF, but each parameter should have a unique identifier. The parameter keywords file is sorted alphabetically instead of numerically by identifier which makes it a bit more complex to see what identifier values are still free, but if you tick checkbox "Identifiers" on the "Modules and Traces" tab, select the "E38" chassis and then export the parameter keywords through the "Chassis Functions" button, you'll get a numerically sorted list. 0597 and 0598 are the first available numbers (although you do not have to number sequentially). Reassemble the "SWTPSW01.DAT" file and overwrite the original file (always make sure you have backups of the original files).Code:SWT_EINTRAG : 0597 "5094_imp/km" SWT_EINTRAG : 0598 "5043_imp/km"
Next disassemble the "IKE.C02" file, search for the occurrences of "K_ZAHL_TACHO_KOMPL", "K_ZAHL_TACHO", "K_ZAHL_WEG" and "K_ZAHL_WEG_KOMPL" and add for each one the new parameter using the freshly created parameter identifiers and the calculated values:The comments after // are ignored upon reassembly, so you do not have to enter them. They are only used to make the file more readable upon disassembly. Reassemble the file and overwrite the original "IKE.C02" file. Restart NCS Dummy (or press CTRL+ENTER in the "Path to NCS Expert DATEN folder" textbox) to reload the "Modules and Traces" tab with the modified DATEN files.Code:PARZUWEISUNG_FSW : {} 000000AE 0002 00AD {} (FF,FF) {h} {} // K_ZAHL_TACHO_KOMPL PARZUWEISUNG_PSW1 : 0222 (EE,24) // 4571_imp/km PARZUWEISUNG_PSW1 : 0223 (EE,79) // 4486_imp/km PARZUWEISUNG_PSW1 : 0597 (EC,19) PARZUWEISUNG_FSW : {} 000000BA 0002 00AC {} (FF,FF) {h} {} // K_ZAHL_TACHO PARZUWEISUNG_PSW1 : 0222 (11,DB) // 4571_imp/km PARZUWEISUNG_PSW1 : 0223 (11,86) // 4486_imp/km PARZUWEISUNG_PSW1 : 0597 (13,E6) PARZUWEISUNG_FSW : {} 000000BC 0002 0102 {} (1F,FF) {h} {} // K_ZAHL_WEG PARZUWEISUNG_PSW1 : 0224 (02,0E) // 4526_imp/km PARZUWEISUNG_PSW1 : 0225 (01,B9) // 4441_imp/km PARZUWEISUNG_PSW1 : 0598 (04,13) PARZUWEISUNG_FSW : {} 000000BE 0002 0103 {} (1F,FF) {h} {} // K_ZAHL_WEG_KOMPL PARZUWEISUNG_PSW1 : 0224 (1D,F1) // 4526_imp/km PARZUWEISUNG_PSW1 : 0225 (1E,46) // 4441_imp/km PARZUWEISUNG_PSW1 : 0598 (1B,EC)
From now on it's plain and simple FSW/PSW coding... In NCS Dummy on the "Modules and Traces" tab, select chassis "E38" and module "IKE.C02" and load the "FSW_PSW.TRC" trace file you read from the IKE module with NCS Expert. Select the "Trace Editor" tab and search (CTRL+F) for the K_ZAHL entries. Tick the checkboxes in front of your newly created parameters and use the "Editor Functions" button to export to a "FSW_PSW.MAN" trace manipulation file. Head back to NCS Expert and recode the IKE module as explained in chapter "Coding modules from a FSW_PSW.MAN manipulation file with NCS Expert". If all goes well, the module should now have be coded with your impulse per kilometer values.I have no experience with it, but this screenshot from the IKE coding suggests that P.A. Soft BMW Scanner 1.4.0 can change the K_ZAHL values as well ("Speed, imp/km" and "Distance, imp/km" in the lower right corner of the screenshot). No hexadecimal and binary calculation necessary - BMW Scanner does that for you.is it possible to fit this IKE into an e30, is there a more simple solution for what i'm trying to accomplish?
Member
Thanks a lot revtor
it will take a while until the engine and Ike swap will be complete, but i will post the results here
Member
Do you need bmw scanner interface or is there another way of using it?
Member
Hi Revtor,
My head is about to blown up to make sense out of this line from HUD:
PARZUWEISUNG_FSW : {00003070} 00000002 000E 102E {62} (FF) {h} {} // DREHZAHL_KENNLINIE
NEW => PARZUWEISUNG_PSW1 : 0026 (00,5C,B5,9C,9F,A2,A5,D1,00,82,3B,2E,21,14) // wert_01
OLD => PARZUWEISUNG_PSW1 : 0026 (0E,3C,64,9B,9F,A2,A5,D2,B4,87,3B,2E,21,14) //wert_01
Those lines with "NEW" and "OLD"
Can you please help intepret it?
Here is the situation:
I have E60 550i with HUD, and I enable HUD_M to show the tach line on HUD.
The line with "OLD" seems to show the range incorrectly (probably because it's M5 RPM range).
The line with "NEW" is from some forum members for diesel engine.
I'd like to make it calibrate correctly for 550i engine, so your guidance is appreciated.
Thanks!
Member
my550i: Unless someone else went through this before, I'm afraid the only way to decipher those values will be trial and error. Find out what the difference is between "old" and "new" in your HUD, then experiment with changing the values that are different between "old" and "new" (especially the values that are far apart from each other). Once you know which value affects what you can try to find out what they represent (or simply adjust them until the result is satisfying).
Member
Hi,
can i use NCS dummy to find out what module a specific function resides in?
i am looking for the ringtone function in my E65 but i dont know what module it is in. it is not in my TCUM module and i dont have a MULF or CIC modules like other people suggested.
i ran NCS dummy for E65 chassis (without choosing a specific module) and found the ringtone function but i dont know what module it is in. the function id is 1442 in the function keyword text file.
any help would be appreciated
thanks
Member
tamir15: I might add a chassis-wide search function in a future version, but I'm afraid that at this moment your only option is checking each module individually. Also keep in mind that the presence of certain keywords in the functions/parameters/options keyword files does not mean they are actually used in any of the modules.
Anyway, I ran a scan over all E65 modules and "RINGTONE" occurs in one module only: "TCU15MOS.C13".
Posting Permissions
Reply With Quote
Bookmarks