Shop OBEX P1 Docs P2 Docs Learn Events
OBD II CAN object in obex by Chris Gadd. Anyone tried this? — Parallax Forums

OBD II CAN object in obex by Chris Gadd. Anyone tried this?

T ChapT Chap Posts: 4,223
edited 2014-07-01 19:52 in Propeller 1
I have several sensors I need to trace down and was going to buy a OBDii CAN bus scanner, but thought it might be a fun project to put together his design posted in obex by Chris Gadd. http://obex.parallax.com/object/690

Basically I want to read the error codes and hit reset.

Comments

  • ChrisGaddChrisGadd Posts: 310
    edited 2014-06-12 20:44
    This should do the job. The demo object lets you send commands through the serial terminal. For stored diagnostic codes, use the Direct entry command to query mode 3, any PID. It's up to you to figure out what the returned codes mean. To clear the codes, use the Direct command to query mode 4, any PID. The other commands in the demo view current data, but with a little editing can be made to show freeze-frame data instead.
  • T ChapT Chap Posts: 4,223
    edited 2014-06-12 20:54
    Thanks Chris. I am not clear what you mean on clearing codes. If I read all errors back and take note of them, I then want to reset the errors. You are saying that if I send a direct command with ANY PID, it makes no difference which, and it will reset the errors? This is a new study for me, I had assumed you need a specific command the clear the errors. Edit: Maybe what you are saying is that there is no clear "all", that to clear a specific error, you need to enter that specific error in mode 4.
  • ChrisGaddChrisGadd Posts: 310
    edited 2014-06-13 05:08
    Have a look at the wikipedia page. Mode 1 is for current data and mode 2 is freeze-frame data. Mode 3 returns trouble codes, two codes can be returned in a single frame, three or more require multiple frames. I haven't messed with it so not sure how that's supposed to work. Mode 4 doesn't care about PID, it will clear all error codes and turn off malfunction lights.
  • T ChapT Chap Posts: 4,223
    edited 2014-06-27 15:32
    No luck today on my first test, there was no response from the car. I went over the schematic a dozen times and it seems right. I just ran the demo from the obex files, type L and it shows no response. A store-bought cheap scanner works but does not return a full spectrum of errors that I need to see.
  • ChrisGaddChrisGadd Posts: 310
    edited 2014-07-01 17:11
    Sorry 'bout not getting back sooner; had some things I wanted to try.

    I wrote a troubleshooter object that'll test the idle condition, look for traffic on the Rx pin, and if present measure the bit rate somewhat accurately. Then starts a reader and attempts to read a few messages just to see if that part works. Next it starts a writer to send a test message, which the reader should see being transmitted, and since the message is one that an OBD computer should recognize, waits for a response.

    The reader seems to be having issues, in that sending an ack causes interference on the CANbus, and the reader uses an 8-message buffer, with any messages coming in while the buffer is full being dropped. I've commented out the ack instruction, and I'm trying to think of a solution for the buffer issue.
    The OBD demo object still works fine with my Cobalt.

    CANbus troubleshooter - Archive.zip
  • T ChapT Chap Posts: 4,223
    edited 2014-07-01 19:33
    Thanks Chris for the info. I was using a the usb protoboard which should accept 14VDC, but the 3v3 switching reg smoked so I don't have a working module at the moment. When it blew, the dash went crazy and would not clear. Fortunately I had a cheap store bought scanner that did clear the multiple errors that were set off. I am leaving this alone for now and getting a pro unit designated to my car type.
  • ChrisGaddChrisGadd Posts: 310
    edited 2014-07-01 19:41
    Absolutely understandable, and the reason for the disclaimer on the OBD object. My original plans were to have it record to a SD card while I was driving, but that was before I realized just how much traffic was on the bus accessible through the OBD connector. I thought the sole purpose of that connector was to talk to the computer, never woulda guessed that it could interfere with the dashboard if I hadn't seen it.
  • T ChapT Chap Posts: 4,223
    edited 2014-07-01 19:52
    BTW I am not blaming your code, I think the proto was supposed to handle up to 16V, but something changed when moving from a shop 6V supply to the car supply on the OBD2 port.
Sign In or Register to comment.