Greg, Am 03.01.21 um 04:15 schrieb Greg D.:
So I see the mention of obdii and it got me to pay attention...:)
Regarding obdii "complexity"... I've always wondered why the obdii command only has 'ecu' as a second and only parameter. If obdii is essentially the command front-end to the obd2ecu task, that split is odd. What else was considered for the obdii framework?
I don't know of any master plan for the "obdii" framework, but of course it's the natural place for all OBD2 tools to come. The general single OBD request command has been on my list since I added that to the Twizy code, always felt it should become a framework feature. As I recently got my new car (a Seat Mii, which is basically a VW e-Up), I now needed this command to start investigating the ECU registers on this car. While you technically could use the "re obdii" scanner for this, some fine people in the german forums already found all device addresses and most register addresses, so we're now already at the level of decoding the values. The next stuff I'd like to add in "obdii" is a general DTC tool, probably along with a new alert feature on DTC occurrence. But that won't reuse much of the Twizy code on this, as the Twizy had no support for standard OBD DTCs. Another concept fitting into "obdii" would be control for a full featured ISO-TP service process. The current implementation as the "poller" inside the vehicle class has it's limitations and oddities, although we've made quite some progress on this lately. A service worker concept as the one I've implemented for CANopen would be better. But that's more a long term todo. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26