I think you might have two ecu's responding to the request.
If you turn headers on you should be able to see if different addresses are responding
I am having problems reading my Hyundia Tucson 2007 2.7 OBD2 Crossover
I tried Hyperterminal and have found that every reply has an extra line
"7F 01 12" (01 is mode 1 am guessing if I do a 9 mode extra line is 7F 09 12)
09 02 (read vin)
>49 02 01 00 00 00 4B
49 02 02 4D 38 4A 4D
49 02 03 37 32 44 34
49 02 04 37 55 35 39
49 02 05 34 36 38 37
7F 09 12
>41 0C 80
7F 01 12
the 7F is a standard response afaik. i forget what it means but you should be able to just ignore it.
I agree with michbound that the 0x7f??12 response is probably from a second controller.
The 0x7f response is a negative response (are you seeing this on ISO14230?) while the ?? part indicates the service ID you requested (09 for the VIN, 01 for the RPM) and the 12 part indicates "subFunctionNotSupported-InvalidFormat" (according to the SAE J1979-2002.04 doc). So this is likely some other controller responding (negatively) that it does not support requests for VIN or RPM.
It responds with 7F 01 12 (01 is the mode) for every command
Even if I
04 to clear codes
7F 01 12
Anyone run into this and know how to eliminate it?
There must be a way to shut this off?
How do other programs work?
I would heed what michbound suggested, and that is to turn headers on (presumably you're using an ELM or ELM derivative device, in which case you would do this with the "ATH1" command). When you do this, you will likely see the positive responses coming from one ECU and the negative response (0x7f??12) coming from another ECU. The headers will show you which ECU sent the negative response. Unfortunately, I'm not sure if you can address the RPM & VIN requests directly to the ECU that responds positively (and not send to the NACK-ing ECU), at least not on an ISO9141 network (though you can address OBD requests to individual ECUs on a CAN network).
Does your ELM device show you as having OBD on ISO14230 on your vehicle?