VPW Analyzer Tool

[jlvaldez Profile]

That is exactly what is supposed to happen ... It is followed by ATZ, atz needs to be tested to ensure it returns OK, then the rest of the commands while also checking each for their proper response.

Welp, I just finished commiting and doing a pull request to the main branch with these bug fixes.

Sadly, I did the pull request incorrectly and it merged all the commits into the main branch instead of just the latest one... I'll have to try again next time. Oh well, it's my test project to try to learn how this crap works lol

It does now send a \r and then verified response from device.


Aaron, can you test the latest version with your OBDLink and let me know what you get? It should also now recognize that you have an OBDLink (i think it'll show up as an STN part, maybe...)

My desktop doesn't have a bluetooth module, so I can't easily test this. All the sleeps have been removed and instead verification of response is done before sending more commands (the proper way).


I also fixed the shutdown bug. As expected, it was indeed a threaded task issue where the forked thread was hanging the main process. I am no UI developer, and don't have much of a concept of how UI threads are supposed to work.

I tagged the latest version as 0.2. Almost useful now...

[Gampy]

Working with your own repository ...

As long as no other changes happen to Master in the meantime, the simple steps are ...

Checkout Master
Create new branch
. . Make your modifications/feature
Stage Changes
Commit Changes
Checkout master
Merge new branch
Push origin

[jlvaldez Profile]

Working with your own repository ...

As long as no other changes happen to Master in the meantime, the simple steps are ...

Checkout Master
Create new branch
. . Make your modifications/feature
Stage Changes
Commit Changes
Checkout master
Merge new branch
Push origin

Yeah that's exactly what I did. I think I might've done the wrong kind of merge. Need something that flattens all the commits in the dev branch for a single commit to the main branch.



I made a dev branch, did all my updates in that. Had commits A, B and C. When I switched to main to do the merge of dev, it simply moved commits A B and C from Dev to main.

[Gampy]

Exactly what it's supposed to do ...

I assume Main is Master and Dev is your Feature branch.

I suspect, you wanted to do a Commit for A, then a Commit Amend for B and C ... That would result in a single commit, thus a single commit to merge into master.

In Visual Studio, Commit Amend is called Amend Previous Commit, it's under the Actions drop down in Changes!

[edit]
I should mention that personally, as a repository owner/maintainer, I prefer not to merge locally, I prefer to push my feature branch, create a Pull Request, then Rebase and merge from the Github GUI, then locally check out the master branch and do a pull to update the local repository ...

[aaronc7 Profile]

That is exactly what is supposed to happen ... It is followed by ATZ, atz needs to be tested to ensure it returns OK, then the rest of the commands while also checking each for their proper response.

Welp, I just finished commiting and doing a pull request to the main branch with these bug fixes.

Sadly, I did the pull request incorrectly and it merged all the commits into the main branch instead of just the latest one... I'll have to try again next time. Oh well, it's my test project to try to learn how this crap works lol

It does now send a \r and then verified response from device.


Aaron, can you test the latest version with your OBDLink and let me know what you get? It should also now recognize that you have an OBDLink (i think it'll show up as an STN part, maybe...)

My desktop doesn't have a bluetooth module, so I can't easily test this. All the sleeps have been removed and instead verification of response is done before sending more commands (the proper way).


I also fixed the shutdown bug. As expected, it was indeed a threaded task issue where the forked thread was hanging the main process. I am no UI developer, and don't have much of a concept of how UI threads are supposed to work.

I tagged the latest version as 0.2. Almost useful now...

Code: Select all

PS C:\Users\aaron\vpw_analyzer> python .\vpw_analyzer.py
Opening serial port: COM10
Exception in thread Thread-1:
Traceback (most recent call last):
  File "C:\Users\aaron\AppData\Local\Programs\Python\Python39\lib\threading.py", line 973, in _bootstrap_inner
    self.run()
  File "C:\Users\aaron\vpw_analyzer\vpw_analyzer.py", line 395, in run
    self.obd.open()
  File "C:\Users\aaron\vpw_analyzer\vpw_analyzer.py", line 80, in open
    if (b'OK' not in reset_response and reset_response[-1] != b'>'): raise Exception("Device did not acknowledge reset request")
Exception: Device did not acknowledge reset request


[Gampy]

Looks like a Port Open failure ... Check the COM port is valid.

[jlvaldez Profile]

Pulling out my laptop now so I can do some testing on the OBDLink device. It could very well be something simple. For whatever reason it seems like it did not receive the expected response from the device. I should have the exceptions also dump the raw output.

Edit:
Found out what it is. OBDLink doesn't return "OK" when you send atz. Seems like the OBDX and OBDLink respond differently to reset commands... ha....

Guess we're just checking for a > afterwards!

[Gampy]

It's not supposed to, it's supposed to return the ELM version ...

STN_ATZ_Response.png (2.9 KiB) Viewed 1800 times

The key strokes were,
enter
ate1 enter
atz enter

If you just test for the prompt, all you know is it returned, not if it was successful or not ... You should test against expected values!
I would create a function SendExpectResponse(atCommand, expectedResponse) that does this and returns true on success.

[Tazzi]

Pulling out my laptop now so I can do some testing on the OBDLink device. It could very well be something simple. For whatever reason it seems like it did not receive the expected response from the device. I should have the exceptions also dump the raw output.

Edit:
Found out what it is. OBDLink doesn't return "OK" when you send atz. Seems like the OBDX and OBDLink respond differently to reset commands... ha....

Guess we're just checking for a > afterwards!

OBDX responds different for ATZ. It was an oversite on my behalf.

ELM protocol dictates sending ATZ results in full reset of the device and then sending the device name (ELM327 v1.4 or v2.1 ect). I kinda disagree with that method but being elm compliant, its suppose to. Hasnt seemed to stop it working with any other software's though.

[Gampy]

OBDX responds different for ATZ. It was an oversite on my behalf.

Shame on you!

All them atta boys wiped out by that one awe shit!

Technically, according to Hoyle (the specs), ATZ returns the Product ID so software can configure appropriately, the important part being, so software can configure appropriately.