Our OBDNet API is completely free. But in order to fully use the OBDNet API (as a client) you will need a copy of our ScanXL Professional software (which contains the OBDNet server) which is not free.
I'll try to get bored enough to write you a better VB.net snippet tonightBreak out my mad VB skills that I haven't used since I learned c#. I had a .net library for obd2 reading once upon a time but I rewrote it in c++ a long time ago
Our OBDNet API is completely free. But in order to fully use the OBDNet API (as a client) you will need a copy of our ScanXL Professional software (which contains the OBDNet server) which is not free.
Brian @ Palmer Performance Engineering, Inc.
http://www.palmerperformance.com
NitroKing: See attached for a simple project that uses a thread to constantly make OBD2 requests. It should operate pretty much as fast as the scan tool you are using is capable of operating, but for cheap chinese tools as Vitaliy said, you may have to add a delay in the loop. This is just a quick example, it has no error checking, no real way to end the loop, etc etc, but it should get you started on the right track.
Also...
ELM327 datasheet:
http://www.elmelectronics.com/DSheets/ELM327DS.pdf
P.S. This is GPLv2 of course![]()
Malcom,
This is great stuff, I really appreciate it. I read the pdf and it has everything one may need. Regarding your app, I cannot open it, I have visual studio 2005 currently installed. Which version is required for it to open?
Thank you very much!
Malcom,
I opened it with VB 2010 express.. I also tested it hard..
With the loop we request answers very fast from the interface but we don't accept them if they do not have a > in the end.. The problem is that the interface concatenates the responces.. What I figured out is that when it responds,if you query it again it will start writing in the out buffer from the point it can. For example, if the request is 010C, then it may return "010C 41 0C 010C 41 0C 0C 77 010C" this is three responses in a row.. OR it may give half of the first answer and half of the next ie "0C 77> 010C 41 0C" so the code finds the > symbol and it proceeds. In addition, the RetVal variable concatenates the result as well so it may end up having a huge value of unwanted symbols in it. What I have thought is that each time the loop starts again, we have to discard the out buffer, I tried using serialport1.discardoutbuffer() but with no luck, then it does nothing. I think it is about thread synchronization.
The only way I managed to get continuous results was the following:
Timer with 300ms interval
250 sleep delay in Datareceived procedure
and it is responding about 3 times/sec which is great.
The problem is, if I want to monitor a number of sensors, how do I do it? I tried to sleep the tick event prior requesting the 2nd sensor but no luck. What I would REALLY want to happen is the commands to be executed sequentially, for example, request in timer tick procedure, WAIT for the respond, then continue to the next request and so on.
Is there any way I can synchronize the two threads (the main and the serial port handling thread) so that the commands are executed sequentially and avoid all this chaos?
Thank you again
The really proper way to implement it would be to have a circular buffer constantly reading in, and whenever you come across a > then you pop the entire message off the buffer and parse it. That's a trivial task, so I'll leave that to you.
The only reason you should get multiple responses back before a >, is if your car has multiple ECU's. Keep in mind, I'm speaking from experience with ELM327, and nicer tools. The cheap chinese tools don't guarantee any of this stuff :P
As for multiple requests, if you implement the circular buffer as stated above, after sending off a request you wait for the message to pop off, and then you send the next message, wait for the response, and so on and so forth. Possibly the reason why multiple requests didn't work is because the circular buffer is not implemented.
Aw hell, I'll write up some nicer code :P
Edit: Come to think of it, you should not be seeing any messages after the > until you send more commands... That's specified in the ELM data sheet.
Can you give an example of where you are seeing this?
Yes I totally agree with you, I should not see if I don't send any commands but that's what happening when I debug the code.. Lets say the timer_tick interval is 300ms. I put a break point in the timer_tick and another one in the datareceived procedure.. Then what the system does is stop three times in the .write("010C") command and THEN stop incide the datareceived procedure.. That's odd, It should do one stop in the tick, next in the datareceive, then in the tick and so on.. But because they are different threads probably it gives priority to the main thread, I don't know.. The commands to discard the in and out buffer are the serialport.discardoutbuffer() and serialport.discardinbuffer() or are there any more?
Thanks
Those are the commands to clear the buffer, however you should not be sending commands on a timer. After you have sent one message, wait until you receive the response (Either the proper data, NO DATA, or ?), then send the next message. That way you are not sending multiple messages before getting a response back.
The same was happening with the infinite loop
While (true)
blah blah
end while
So i used the timer in order to be able to request in specific times. I explained it better in a previous post.. So what I'm thinking of now is to set a global variable and control the sending from there, I don't really know yet.. I found the solution yesterday when I was in bed but then I slept and forgot it.. :P :P This app is making me nervous hahaha..
Bookmarks