openecu.org

v2
Added Enginuity compatible XML output. Detailed instructions in the readme file included in the .zip

Update v3
* added ecuedit single offset format

Update v4
* fixed reverse conversion expressions

What's "reverse conversion expressions"?

To real world numbers and back to byte values

According to colby it already works correctly in ecuEdit. I made changes to a ROM with the first version of xmlwrite and the changes were exactly the same as they were with version 2.

xswrex, I found, that you are not correct interpret #85 and #84 map type. I fix it in my <map_struct> description.

yes this was listed in the known issues

now it won't be an issue anymore!

new version will be out shortly, i am adding output type 3 which will produce the xml using the single offset. With this format the ecu ROM file will not be needed to be present in order to create the XML

xswrex, also you have some problems in reverse formulas:

AFR direct = 1881.59999999999991/([value]+(128))
your AFR reverse = ([value]-(128))*1881.59999999999991
correct AFR reverse = 1881.59999999999991/[value]-128

Main ignition timing direct = ([value]*0.3515625)+(-20)
your reverse = 0.3515625/([value]-(-20))
correct reverse = ([value]-(-20))/0.3515625

and simple

Ignition Correction direct = ([value]*0.3515625)
your Ignition Correction reverse = 0.3515625/[value]
correct Ignition Correction reverse = [value]/0.3515625

I hope you fix this

v4
* fixed reverse conversion expressions (for both output types)

Does this mean we need to recreate the xml files we currently have created by the old version?

I think a good feature would be to have it create definitinos for all the files in a directory you specify.

JRSCCivic98 wrote:Does this mean we need to recreate the xml files we currently have created by the old version?

yes. old version had some bugs with reverse conversion expressions

subscribe...

good news....working on another update to add ecuflash XML format support. So far it is going well but i have a request to Colby: parse and allow the storagetype in the <table> tag to overload the inherited <scaling> storagetype. If possible, it will save quite a bit of coding....if not i have a workaround in my mind

Are you saying that you want "inline" scalings? My experience has been that the scalings of a particular map are almost never unique and you will want to re-use some of them later for another map. That's why I pushed them out of the tables to the "ROM" level...

xswrex wrote:good news....working on another update to add ecuflash XML format support. So far it is going well but i have a request to Colby: parse and allow the storagetype in the <table> tag to overload the inherited <scaling> storagetype. If possible, it will save quite a bit of coding....if not i have a workaround in my mind

cboles wrote:Are you saying that you want "inline" scalings? My experience has been that the scalings of a particular map are almost never unique and you will want to re-use some of them later for another map. That's why I pushed them out of the tables to the "ROM" level...

Completely understood, i see scaling as conversion expression only like ecuedit conversion functions.
My point is that an expression can be shared for more than 1 maps axis/data but the "cell" size can be different across maps. So you can have a map with 16bit Z-values and one with 8bit Z-values and they can use the same expression. This would require 2 different scalings, one uint16 and another uint8, whereas if the storagetype was in the map level only 1 scaling would be needed. Essentially the result will be the same, it would enhance the flexibility for the automated XML creation process.