I think you're overestimating the impact. Speed is only an issue today because of a couple bad decisions I made back in the day. When I wrote the original definition parser I was testing with a couple ROM revision definitions that had maybe a dozen tables each. Now that I've seen we have so much more metadata to deal with and I have some xml document parsing under my belt I'm in a much better position to make it fast enough.
Java can READ a file very fast. In ms.
Cheers for the reply Jared
Ah all good then I guess. If you can implement the extra logger defs into the ecu defs without actually increasing load times etc, then that is a big plus.
You're right, logger metadata won't be used in the editor and vice versa (well, probably.. read on). But there will be very little negative impact. The benefit would be better cohesion. A single definition file for a single rom revision. I don't think its such a huge deal, but I think it makes the most sense.
I totally understand the need for cohesion between the defs, and I totally understand the need to reduce number of duplications of definitions for RR Editor and RR Logger and ECUFlash.
What I meant above is that even if RR Editor is changed to use ECUFlash's def format and cohesion is found, which I think is a great idea and something that shouldn't take too much time to implement - the Logger and it's defs are totally different story.
There is no easy way to use the current ECUFlash defs the way they are now for logging purposes without adding a bunch of code in every def for every specific vehicle/ecu model. To be very specific, the ECUFlash defs have no logger support at all. They are very specific to ROM editing, and only include the required table details and scalings needed to convert units.
You could pull the scaling info for the logger from the xxbitbase.xml file, but you then still need the numerous parameter and ecuparam info for logging to work.
I thought a little more about it and you could add the parameter info to the xxbitbase.xml files as they're used by all vehicles/ecus - and then add the ecu specific ecuparam info to the relavant vehicle/ecu def that matches the ecuid defined in the ecuparam. Then you could change the logger to suit, gathering all the required info from different def files.
But this adds a HUGE amount of work to do, just separating out the ecu specific ecuparam info and adding it to the hundreds of ecu defs will take a lot of time, effort and changes itself - and that's not even taking into consideration what needs to be changed in the Logger so it parses everything correctly and retrieves the right parameter, ecuparam and switch info for the vehicle being logged.
What I was suggesting was to move RR editor to ECUFlash defs, and keep the Logger using its current logger defs until sometime in the future when devs can spare time for such things of little gain.
Dev time is a valid argument. Switching to ecuflash's definitions seems like a no brainer since there are deficiencies in the current implementation, but I'm not sure I can justify moving the logger defs so easily. And I'm personally not familiar at all (yet) with how the logger parses and identifies roms.
So.. the benefit of combining logger and ECU metadata is minor. The disadvantage (ignoring dev time) is also minor. I can't even give an estimate of how long it would take me to develop. Do we still think its worth while?
I definitely think moving RR editor to ECUFlash def files is worthwhile. RR doesn't have merchgod doing defs anymore, and Dale and others are stretched for time with the huge undertaking of RR dev already - and since ECUFlash and RR both use the defs, it makes a hell of a lot of sense to share dev resources between the two projects and work to use a single editor def format.
The logger on the other hand, is as explained above, a totally different beast, and I'm not sure there is any real need to change the logger defs format at this time as they do not effect or share components with the editor defs in any way.
Hi: I think you may have been misled. I believe this topic was all about the scaling to use in the ROM editor to allow users to view in units of thier preference.
Hmm, I think I may have been - so this is not about logger defs at all? Purely only editor defs and how they themselves deal with unit scalings/conversions?
I had proposed to combine all attributes of a ROM into one def file. That would be Editing and Logging definitions.
As I replied to Jared above, changing the editor to suit ECUFlash defs is worthwhile and shouldn't be too hard.
But the logger defs is different. You can't just combine them into a single def with the ecu defs - as ECUFlash's defs are not one single file - they are hundreds, specific to each ecu.
If on the otherhand you mean combining RR's editor and logger defs, and not using the ECUFlash defs, then I can understand the suggestions - although, doing that would still not fix the current problem that editor defs are made in quadruplet - standard and metric for RR and standard and metric for ECUFlash.
If you keep the logger defs separate for a moment, you could cut that quadruplet def creation down to a single set of defs, with some changes to RR and ECUFlash editors to support user switching between standard and metric units.
I don't see it being a big problem for a couple reasons:
1) the Standard part of a Logger def is common to all cars and can exist in the base def as we have for the Editor today
I'll assume you are refering to the obd "parameter" sections? If so, then agreed, they can be added to ECUFlash's current xxbitbase.xml defs as they are generic and used by all ECUs.
2) the Extended parameters wouldn't add much more than 50 - 60 additional XML elements to the file and they are very short in length. (They contain an ID, data length, RAM address and a set of conversion, which can be relocated to the scaling def)
You could do it that way, and change the scaling sections, but you are then changing the format of the ECUFlash defs, and
1. Colby should be in on that before any work progresses on the changes.
2. I'm not sure it is the best way, extended parameters (ie. ecuparam) are ecu specific, so it would be more consistant to add them to the specific ecu def. And if adding to the ecu def, you could leave them the same as they are now for simplicity, just adding the sections under the sections already in the ecu def files.
More work, but much better, and more consistant implementation imo.
The Extended parameters are truly ROM dependent and that's why I see them being combined with the Editor info.
Oh and BTW, the current Logger of today reads all your Editor defs you have listed to cross reference the ECU ID to the CAL ID to identify the car. It's so fast you don't even notice it, do you?
The speed was more in relation to the editor, not the logger. But as Jared pointed out, the RR editor can be modified to improve load times and speed, so I guess that is now a moot point.
Lastly, I just wanted to say that I may voice concern loudly, but if nothing is voiced, it then nothing will be discussed and the best, most suitable direction may never be found
Whatever is agreed to for def implementation, I'm more then happy to assist, so I can help free you both for other more important dev work.