pcmhacking.net

Good point Antus, still shouldn't crash the app though.

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.

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 ...

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.

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 ...

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)
Thank you!

Seems to be a problem sending now.

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.
The first one would still be more correct.

Thank you.

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.

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)