Actually, I haven't figured out myself yet. There's a function in NCS Expert that suggests it's meant for coding by nettodata ("Basic functions" (F5) ---> "coapiCodeSgByNettoData"), but I can't get it to work. Function "coapiCodeSgByNettoData" takes two arguments, the "CBD name" (*.C?? module name) and the "Nettodatenliste". But as soon as I hit "OK" I get error message "COAPI-1063: CABD-parameter error NETTODATEN_CODIEREN". The error log doesn't provide more (useful) information. If anyone knows how to use "coapiCodeSgByNettoData", please let me know.
Up to now I used a completely different approach: I simply modify the CBD module file. After all, it's the *.C?? module file that contains the possible parameters for each function. Modifying the binary data in these files allows me to code through classic "FSW_PSW.MAN" manipulation but with my own custom data. The problem with this approach is that it's very time consuming and extremely prone to making mistakes. The next version of NCS Dummy will feature a tool to make this process a lot easier, but obviously I would prefer a method that does not involve modifying the CDB module files.
that would be awsome!!!
to code nettodata with ncs, you are on the right way.
try this
-read out the ecu with ncs (SG_auslesen)
-edit the nettodat.trc
-save the edited nettodat.trc
-then in ncs hit "basic functions" -> select coapiCodeSgByNettoData
-the CBD name will be the right one automaticly wich was used to read out the ecu
-below write the name of your modified nettodat.trc (if you didnīt change the name, just type NETTODAT.TRC and hit OK
-some seconds later you will see a popup that the coding was successful
hope it helps
Oh my... Is it really that simple? I always tried entering the full path to the nettodata file. I've been breaking my head over this for quite a while. I can't test it right now, but thanks a lot for the information!
yes itīs that simple
the modified nettodat.trc has to be in the WORK folder of ncs of course
ah very nice, thanks a lot!
does changing sysdaten.trc work the same way?
Last edited by cheffi; 01-21-2011 at 11:42 AM.
hm no
all trcs are trace files...you canīt do anything with them...except the NETTODAT.TRC and FSW_PSW.TRC (ony useable as FSW_PSW.MAN)
use 3.1.0...successfully coding E9x and E6x with nettodata
the edited file you want to use to code the car has to be in the WORK folder!
@revtor
are you still working on ncsdummy?
Last edited by ypoc; 01-24-2011 at 06:53 PM.
Hi do you know how to use and what is the ..VM..that is a choice in the basic functions menu in NCS?...
I finally found some time to experiment with the nettodata coding. Sadly, I still can't get it to work . I'm getting the same error message ("COAPI-1063: CABD-parameter error NETTODATEN_CODIEREN") for all modules and all chassis I try to code this way - even for the simplest modules that store only a single byte (like the E31 LKM). Both for modified and unmodified nettodata files. Traditional coding through the "FSW_PSW.MAN" manipulation file works just fine. I am using NCS Expert version 3.1.0.
I used SysInternal's Process Monitor to see what's going on. When I use the "coapiCodeSgByNettoData" kernel function it automatically enters the correct "CDB name". The "Nettodatenliste" field is empty. If I leave it empty and hit "OK", I get "Fehler beim Einlesen der Nettodatenliste" or in English "An error occurred while reading the nettodata list". Process Monitor does not show any attempt to read from a default nettodata file location. Immediately after pressing "OK" the "error.log" file is written. In other words, it doesn't take a blank argument for "Nettodatenliste". When I enter a file name ("NETTODAT.TRC", "NETTODAT.MAN", "C:\NCSEXPER\WORK\NETTODAT.TRC",...) I get the dreaded "COAPI-1063: CABD-parameter error NETTODATEN_CODIEREN" error after pressing OK. Process Monitor reveals that in all situations, the entered nettodata file was successfully opened for reading, read and closed. This confirms NCS Expert does read the given nettodata file and it's quite safe to assume you can use any path name for the nettodata file, as long as it exists obviously.
After the nettodata file is read by NCS Expert it successfully opens, reads and closes the "DATEN\<chassis>\<chassis>SGET.000" and appropriate "SGDAT\A_<module>.IPO" files (it doesn't do that when no nettodata file is given). Right after that it starts writing the "error.log" file - the error message. The problem is not with the "<chassis>SGET.000" and "A_<module>.IPO" files - they are also used for coding through the "FSW_PSW.MAN" manipulation file. The "COAPI-1063" error occurs even before communication is established with the actual module. If I disconnect the module from the car and try nettodata coding through "coapiCodeSgByNettoData", I get the same "COAPI-1063" error. When I use "FSW_PSW.MAN" coding, I get "COAPI-2020: no answer from ECU, IFH-0009: NO RESPONSE FROM CONTROLUNIT" after a short time-out period.
Process Monitor does not provide deeper process detail, but it seems to me that reading the files is not the problem, but for some reason NCS Expert doesn't consider the data it (successfully) read from the nettodata file to be valid...
To the people who have nettodata coding working... Are you using my or fister's (unmodified) profile? If modified or when using a different profile, could you please mail it to me so I can see what is different ("NCSEXPER\PFL\*.PFL").
ypoc: Yes, I'm still working on NCS Dummy, but don't expect a new version in the next weeks. Once it's ready it will be announced here.
On my E65 (11/06) with NCS 3.1.0 your profile works o.k., but little different from my attached profile (FktSgetEingeben=0 is different).
I get an error message only, when the ignition is off.
First I "read" the NETTODATA with the "coapi Read from Sg... (...or so)" in the "Kernfunktionen" (to find the correct *.ipo and *.C**) and give them a DOS-conform Name like LMNET.txt. Then I change the hex, save and close the file, then "coapiCodeSgByNettoData" with the same file. No error message!
I suppose, your Interface, settings an cable are correct?
Thank You very much for Your great "ncsdummy-beta"
montanus
Last edited by montanus; 01-25-2011 at 12:09 PM.
revtor : found this somewhere ,, maybe it helps completing the translation
thanks for the great tool anyway
Still no go. This is getting embarrassing... Developing NCS Dummy and not being able to code nettodata .
It doesn't make sense to me but perhaps the "coapiCodeSgByNettoData" kernel function only works on newer bimmers? I tested the E31 and E46 and no matter what I do I always get the "COAPI-1063" error. Nothing is wrong with the interface. It's working great for reading FSW/PSW and nettodata trace files, and coding through the "FSW_PSW.MAN" manipulation file also works like a charm. Monitoring the interface while attempting nettodata coding reveals no communication, so the problem occurs long before the interface is being used. In fact, if I disconnect the interface I still get the "COAPI-1063" error instead of the usual time-out or initialization errors. Clear evidence the interface is not involved at all...
ehssan78: Thanks!
this could be...
i coded only E9x and E6x at this time with nettodata
in attachment is my own profile
perhaps it helps
Last edited by ypoc; 01-26-2011 at 05:42 AM.
I found the definitive answer...
The successful reports of nettodata coding all come from newer chassis (E6x/E9x). That got me thinking... As explained in a previous message, NCS Expert would throw the "COAPI-1063: CABD-parameter error NETTODATEN_CODIEREN" message immediately after (successfully) reading the appropriate "A_<module>.IPO" file. Simply put the *.IPO files contain a list of jobs supported by the module. Although I do not have a decompiler for the *.IPO files, I made some interesting observations using a hex editor. *.IPO files for, for example, E65 modules contain a string field "NETTODATEN_CODIEREN". *.IPO files for E31 modules do not. Now remember the error "COAPI-1063: CABD-parameter error NETTODATEN_CODIEREN" and it suddenly makes sense. NCS Expert cannot find the requested job ("coapiCodeSgByNettoData" - "NETTODATEN_CODIEREN") in the *.IPO file and naturally throws an error... So there was nothing wrong with my NCS Expert installation, the nettodata file, the interface, my workflow... Nettodata coding is just not supported by these older chassis/modules. Bummer ...
For chassis like the E38, E39 and E46 that isn't much of a problem because custom data coding is still possible through P.A. Soft's BMW Scanner, but older chassis like the E31, E32, E34 and E36 are out of luck.
Hello from Russia
I developed another utilities to work with SGDATEN files, they useful mostly for advanced users, but I think revtor could see something nice from them. Also, I want to ask revtor's permission to use translations.csv in mine tool too.
First utility I want to show is data2txt, it is parser/editor for any file, found in DATEN directory, it has support for loading ASW/PSW/FSW to get more meaner output.
Directions to use:
1. Run data2txt
2. Do File->Load *conf.bap, and point it to some DATEN's .bap file, for example if you want to mess with E60, load e60conf.bap
3. Then you can open any file in DATEN and see/edit it's contents in human readable form.
http://storage.v12.su/data2txt05022011.rar
@russiane39
nice work
but ncsdummy is easier to understand :P (for me)
Last edited by ypoc; 02-05-2011 at 06:19 PM.
This is made for different things, i.e. for example, you can't compare "What's better cube or sphere" ?
Aha, it seems that this portion of KMBI_E38.C12 makes NCSDummy unhappy:
CODIERDATENBLOCK : {} 00000084 0006 "Fahrgestell-Nr"
PARZUWEISUNG_DIR : {} 00000084 0001 01EB {} (FF) () 61
PARZUWEISUNG_DIR : {} 00000085 0001 01EC {} (FF) () 61
PARZUWEISUNG_DIR : {} 00000086 0001 01ED {} (F0) ({-0,'','',''}) 61
PARZUWEISUNG_DIR : {} 00000086 0001 01EE {} (0F) ({-0,'','',''}) 61
PARZUWEISUNG_DIR : {} 00000087 0001 01EF {} (F0) ({-0,'','',''}) 61
PARZUWEISUNG_DIR : {} 00000087 0001 01F0 {} (0F) ({-0,'','',''}) 61
PARZUWEISUNG_DIR : {} 00000089 0001 01F1 {} (F0) ({-0,'','',''}) 61
Last edited by russiane39; 02-05-2011 at 09:22 PM. Reason: Automerged Doublepost
Excellent application! This is actually what I was working on for the upcoming NCS Dummy version .
I wonder if I should go through with implementing this in NCS Dummy... Your application makes it somewhat redundant.
What exactly is the third block in your application's output? The first are the definitions that describe the file's data structure, the second block the actual data, but the third somewhat puzzles me. It seems like a list of the used parameters, but what's the purpose? Somehow "KENNUNG_D" seems involved as well.
In the fourth and last block "descr_count" is the number of fields in the data block, but what is the "ks" value?Of course, go ahead!No, NCS Dummy trips over the following (generated with your application):Also, I want to ask revtor's permission to use translations.csv in mine tool too.
Function keyword "ACC_V_EFF_ANZ" defines a data length of 20 (14h) bytes, but as you may notice parameter keyword "kennlinie_02" has 21 (15h) bytes - it's one byte longer than the other parameters... That means the last byte runs into the next function (ACC_V_EFF_ANZ_RES at 00000118) which is obviously an invalid situation. I could of course make NCS Dummy ignore this, but the problem is that I don't know what bytes are wrong in the "kennlinie_02" data. Ignoring incorrect/corrupt data does not seem like a good idea to me...Code:PARZUWEISUNG_FSW : {} 00000104 0014 034D {63} (FF; FF) {68} {} : ACC_V_EFF_ANZ PARZUWEISUNG_PSW1 : 0025 (00; 49; 00; 64; 01; D1; 01; F4; 04; 7F) : kennlinie_01 PARZUWEISUNG_PSW2 : (04; B0; 06; CB; 07; 08; 09; 79; 09; C4) PARZUWEISUNG_PSW1 : 00DE (00; 49; 00; 64; 01; C0; 01; E3; 04; 85) : kennlinie_02 PARZUWEISUNG_PSW2 : (04; B7; 07; 9A; 07; DC; 00; 97; 32; 09; BE) PARZUWEISUNG_PSW1 : 00DF (00; 64; 00; 64; 01; F4; 01; F4; 04; B0) : kennlinie_03 PARZUWEISUNG_PSW2 : (04; B0; 07; 08; 07; 08; 09; C4; 09; C4) PARZUWEISUNG_PSW1 : 0195 (00; 49; 00; 64; 01; D1; 01; F4; 04; 7F) : kennlinie_04 PARZUWEISUNG_PSW2 : (04; B0; 07; F1; 08; 34; 0B; 63; 0B; B8) PARZUWEISUNG_PSW1 : 02DE (00; 49; 00; 64; 01; C0; 01; E3; 04; 85) : kennlinie_05 PARZUWEISUNG_PSW2 : (04; B7; 08; 38; 08; 7D; 0B; 4C; 0B; A1) PARZUWEISUNG_PSW1 : 02DF (00; 64; 00; 64; 01; F4; 01; F4; 04; B0) : kennlinie_06 PARZUWEISUNG_PSW2 : (04; B0; 08; 34; 08; 34; 0B; B8; 0B; B8) PARZUWEISUNG_FSW : {} 00000118 0014 034E {} (FF; FF) {68} {} : ACC_V_EFF_ANZ_RES
A similar issue occurs with the "ARS.C0E" CDB file with parameter keyword "e70" for function keyword "SCHENKEL_V":The difference here is that I know (00; 08) is the correct data (from the other ARS.C?? files), so I can easily rebuild a correct "ARS.C0E" module file.Code:PARZUWEISUNG_FSW : {00003001} 00000020 0002 0BC0 {65} (FF; FF) {68} {} : SCHENKEL_V PARZUWEISUNG_PSW1 : 000A (00; E9) : e60 PARZUWEISUNG_PSW1 : 0020 (00; E9) : e61 PARZUWEISUNG_PSW1 : 0022 (00; E9) : e63 PARZUWEISUNG_PSW1 : 0024 (00; E9) : e64 PARZUWEISUNG_PSW1 : 0044 (00; FF) : e65 PARZUWEISUNG_PSW1 : 0317 (00; FF) : e65mu PARZUWEISUNG_PSW1 : 0171 (00; FF) : e66 PARZUWEISUNG_PSW1 : 0318 (00; FF) : e66mu PARZUWEISUNG_PSW1 : 019F (00; FF) : e68 PARZUWEISUNG_PSW1 : 02BD (00; 01; 08) : e70 PARZUWEISUNG_FSW : {00003001} 00000022 0002 0BC1 {65} (FF; FF) {68} {} : SCHENKEL_H
Apparently the compiler used by BMW doesn't check for erroneous input ...
Last edited by revtor; 02-09-2011 at 02:20 PM.
Revtor, great you responded. So there is my replies:
1. To understand for what third block is needed - just open any .dat in my prog I bet -you are smart
PS: Correct answer is sorted indexes.
2. "ks" value is checksum value. It looks uncommon, because in Russian language checksum is "Kontrolnaya Summa"
3. Check PM, there is some another gift for you
EH, seems this forum have no PMs here at all, so it would be gift for everyone here.
1) Updated data2txt w/o ugly richedit search. http://storage.v12.su/data2txt14022011.rar
2) And second new app. http://storage.v12.su/DecodeIpo13022011.rar (Guess what it does )
Last edited by russiane39; 02-13-2011 at 06:29 PM. Reason: Automerged Doublepost
russiane39: Thanks for the explanation! I understand the sorted list of parameter keyword indexes, but why are the "KENNUNG_D/KENNUNG_X" fields also listed? As far as I know "KENNUNG_D/KENNUNG_X" represents an address range, not a parameter/function/option keyword index? For example, take the extremely simple E31 LSM module ("LSM.C25"). An excerpt from the output generated with your application:"010E", "010F", and "0134" are parameter keyword indexes, but "0016" is an address location. In this case the value pair of "KENNUNG_D" means from "0016" to "0016" - thus a single byte at address location "00000016". I don't think it should have been included in the sorted list, right?Code:[..] KENNUNG_D : 0016 0016 () CODIERDATENBLOCK : {} 00000016 0001 "LSM-Codierung" PARZUWEISUNG_FSW : {} 00000016 0001 01CE {} (FF) {68} {} : BAUREIHE PARZUWEISUNG_PSW1 : 010E (00) : e31 PARZUWEISUNG_PSW1 : 0134 (80) : e32 PARZUWEISUNG_PSW1 : 010F (80) : e34 --------------- 0016 : 0016 () 010E : (00) 010F : (80) 0134 : (80) [..]
I'm also not sure about the checksum. After checking a few files, it seems you take the last byte of each file for this. But that's the checksum of the last field - not the checksum of the entire file (there isn't one), so the use of displaying the checksum is very limited and applies only to the last field in the file.
DecodeIPO... Very interesting development ! Am I right that at the moment it only reads the "Constant Data" section at the end of the *.IPO files (I only tried a few files)?
PS: Private messaging (PM) does work on this forum, but it's disabled for new members until they reach a certain amount of posts (10 posts and 7 days of registration last time I checked). If you wish, you can always contact me through e-mail at .
1) Sorted indexes outputs something meaningful only if you open .dat file
2) Yes, ks outputs only last field checksum. I don't remember why I left output of that in program
3) Yes, DecodeIPO only reads/writes (it's an editor) Constant Data section. I have no plans adding any additional functionality into it.
Hi Revtor
If you still need nettodat.trc from KMBI_E38.C12 here is one.
Code:M 00000002,0001,00FF,000B B 00000003,0001,0000 M 00000004,0001,CFFF,0EFA B 00000006,0008,FFFF,FFFF,FFFF,FFFF,01CE,C13C,0000,0000 B 0000000E,0008,0000,0000,0000,0000,FFFF,FFFF,FFFF,EFFF B 0000001F,0001,FFFF B 00000026,0006,FFFF,FFFF,FFFF,FFFF,FFFF,FFFF M 0000002C,0001,7FFF,7F00 M 0000002E,0001,00FF,0070 B 00000039,0007,3314,FFFF,0006,87FF,FE5E,FF2C,FE3C B 00000042,0002,444E,4573 M 00000044,0001,00F0,0000 B 00000046,0008,4061,0003,5A20,0100,7699,0040,404F,1D04 B 0000004E,0005,2840,D74E,2502,1104,FFFF M 00000053,0001,FF00,1200 B 00000054,0005,0804,8053,0041,EE24,6FFF M 0000005A,0001,FC00,DC00 B 0000005D,0008,11DB,09DE,9621,005A,28BE,5122,7986,9DD6 B 00000065,0008,005A,28BE,5122,7986,A5E0,10F0,0507,0402 M 0000006D,0001,00FF,0000 M 0000006E,0001,00FF,0010 M 0000006F,0001,00FF,00E0 M 00000070,0001,00FF,00A5 M 00000071,0001,00FF,00FF B 00000072,0004,1C1A,0B74,877A,12CC B 00000077,0003,17FF,0845,14E8 M 0000007A,0001,00FF,000F M 0000007B,0001,00FF,0032 M 0000007C,0001,00FF,004B M 0000007D,0001,00FF,0073 M 0000007E,0001,00FF,0078 M 0000007F,0001,00FF,007D M 00000080,0001,00FF,0072 B 000000BF,0003,F606,1904,3206 B 000000CA,0006,01FF,FF40,FDFF,0000,FFFF,FFFF
Thank you for the nettodata file, Node. I received "KMBI_E38.C12" trace files from a several other NCS Dummy users as well, but it seems the corrupt function keyword ("ACC_V_EFF_ANZ") is never present in the nettodata files. So it's probably relatively safe to ignore the invalid data. I will think of making "KMBI_E38.C12" work "properly" in the upcoming NCS Dummy version (by ignoring the invalid data)...
Bookmarks