XMLWRITE v2

[xswrex]

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

[JRSCCivic98]

What's "reverse conversion expressions"?

[qoncept]

To real world numbers and back to byte values

[JRSCCivic98]

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.

[epifan]

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

[xswrex]

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

[epifan]

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

[xswrex]

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

[JRSCCivic98]

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

[qoncept]

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

[epifan]

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

[crispyduck]

subscribe...

[xswrex]

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]

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...

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

[xswrex]

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.