PCM Hammer Release 014

They go by many names, P01, P59, VPW, '0411 etc . Circa 1999 to 2006. All VPW OBD2 PCMs.
Posts: 656
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Release 014

Postby Gampy » Fri Jul 31, 2020 10:11 am

Good point Antus, still shouldn't crash the app though.
I'm not angry, I'm a brash, blatant, driven, passionate individual that is extremely intense!

Posts: 35
Joined: Tue Dec 31, 2019 11:24 am

Re: PCM Hammer Release 014

Postby ColPaul » Fri Jul 31, 2020 11:40 am

Gampy, I'll have access to a PCM and bench harness through Sunday morning. Let me know what you need and I'll be happy to test with you.

Antus, I ran v14 from Visual Studio using the debug and verified that this.ReadDVIPacket does return a null vs. a ResponseStatus object. I added code that exits the for loop when this happens, which then returns the default error object with timeout as the error. The crash occurs when then if statement checks response.Status, which is an invalid object since response is null.

Posts: 656
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Release 014

Postby Gampy » Fri Jul 31, 2020 1:03 pm

ColPaul,

Thank you, please start with fresh stock code (no modifications) and replace the OBDXProDevice.cs with this one, build and run ... try a read.
Obviously you'll have to remove the .txt extension added to allow uploading here ...

OBDXProDevice.cs.txt
(41.97 KiB) Downloaded 9 times
I'm not angry, I'm a brash, blatant, driven, passionate individual that is extremely intense!

Posts: 35
Joined: Tue Dec 31, 2019 11:24 am

Re: PCM Hammer Release 014

Postby ColPaul » Fri Jul 31, 2020 2:09 pm

The program doesn't crash, but still gives some errors. It looks like there was a problem sending or reading in both calls to ExitKernel.

Results and Debug Log attached. I still think there should be null checking in FindResponseFromTool to ensure that if DVIReadPacket returns a null that the if statement doesn't try to work with that null result. I believe that the 2nd time through the ExitKernel that the timeout was still set to minimum from the 1st call to ClearTroubleCodes. Heading to bed now. Happy to run more test in the AM.
Attachments
Test Debug Log.txt
(159.58 KiB) Downloaded 9 times
Test Results.txt
(12.09 KiB) Downloaded 8 times

Posts: 656
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Release 014

Postby Gampy » Fri Jul 31, 2020 2:57 pm

ColPaul,

It didn't crash, it saved the file ...

ReadDVIPacket()'s return value is a Response<Message>, returning anything other then, means the code is broke!

Therefore FindResponseFromTool() only needs to expect a Response<Message>.

Those errors are coming from SendDVIPacket(...) which suffers from similar issues ...
I'm not angry, I'm a brash, blatant, driven, passionate individual that is extremely intense!

Posts: 656
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Release 014

Postby Gampy » Fri Jul 31, 2020 4:51 pm

Curiosity has me, would you please try this ... This really is just a curiosity killer for me, so if you don't want to spend the time that's fine.
Same thing as before, start with fresh unmodified code, replace OBDXProDevice.cs with this one, build and run ... try a read. Obviously removing the .txt required for upload. (I know, but I gotta say it)

OBDXProDevice.cs.txt
(42 KiB) Downloaded 9 times

Thank you!
I'm not angry, I'm a brash, blatant, driven, passionate individual that is extremely intense!

Posts: 35
Joined: Tue Dec 31, 2019 11:24 am

Re: PCM Hammer Release 014

Postby ColPaul » Fri Jul 31, 2020 11:48 pm

Seems to be a problem sending now.
Attachments
Test Debug Log.txt
(10.92 KiB) Downloaded 7 times
Test Results.txt
(1.52 KiB) Downloaded 5 times

Posts: 656
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Release 014

Postby Gampy » Sat Aug 01, 2020 12:13 am

Awesome, Thank you ...

Not what I was hoping for, though expected results. Those are read errors, it's unable to read the responses.

One more time ... This one has just the two return values fixed, no try catch's.
If this works, it would not negate the fact that Port.Receive(...) needs try catch blocks.

OBDXProDevice.cs.txt
(40.05 KiB) Downloaded 10 times

The first one would still be more correct.

Thank you.
I'm not angry, I'm a brash, blatant, driven, passionate individual that is extremely intense!

Posts: 35
Joined: Tue Dec 31, 2019 11:24 am

Re: PCM Hammer Release 014

Postby ColPaul » Sat Aug 01, 2020 12:55 am

Saved the file and didn't crash. Still has comm errors. BTW, I'm copying and pasting the logs to notepad and then saving. Are these results saved automatically somewhere, like a temp directory or even in the execution directory? If not, that would be a nice feature.
Attachments
Test Debug Log.txt
(156.95 KiB) Downloaded 7 times
Test Results.txt
(11.65 KiB) Downloaded 5 times

Posts: 656
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Release 014

Postby Gampy » Sat Aug 01, 2020 1:32 am

Perfect and exactly as expected ... Many thanks.

I recommend a pull request with just the two returns fixed (line 331 and 342) (that last file), that fixes the immediate issue.

Port.Receive(...) should have try catch(TimeoutException) blocks around it, it's not the only place in need, now is not the time.
One bite at a time.

Better log saving options (IMO) (Automatic and One-Click) are in the queue to be released, waiting for prerequisites and or conflicts to be merged or rejected.

ColPaul,
I really appreciate your time and effort working thru this issue to a resolution, you've been a great help!
And especially thankful for the extra time testing just to satisfy my curiosity ... Thank You!

Edit:
As stated earlier, the
Unable to transmit, Error: ...
messages are coming from SendDVIPackage(...) (line 510 to be exact) and are another bite of the elephant. (or to some, another can of worms)
Last edited by Gampy on Sat Aug 01, 2020 5:19 am, edited 1 time in total.
I'm not angry, I'm a brash, blatant, driven, passionate individual that is extremely intense!

PreviousNext

Return to GM LS1 512Kbyte and 1Mbyte

Who is online

Users browsing this forum: No registered users and 5 guests