PCM Hammer Release 014
Re: PCM Hammer Release 014
Good point Antus, still shouldn't crash the app though.
Intelligence is in the details!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
Re: PCM Hammer Release 014
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.
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.
Re: PCM Hammer Release 014
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 ...
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 ...
Intelligence is in the details!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
Re: PCM Hammer Release 014
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.
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 212 times
-
- Test Results.txt
- (12.09 KiB) Downloaded 211 times
Re: PCM Hammer Release 014
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 ...
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 ...
Intelligence is in the details!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
Re: PCM Hammer Release 014
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!
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!
Intelligence is in the details!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
Re: PCM Hammer Release 014
Seems to be a problem sending now.
- Attachments
-
- Test Debug Log.txt
- (10.92 KiB) Downloaded 225 times
-
- Test Results.txt
- (1.52 KiB) Downloaded 203 times
Re: PCM Hammer Release 014
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.
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.
Intelligence is in the details!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
Re: PCM Hammer Release 014
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 203 times
-
- Test Results.txt
- (11.65 KiB) Downloaded 212 times
Re: PCM Hammer Release 014
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
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
messages are coming from SendDVIPackage(...) (line 510 to be exact) and are another bite of the elephant. (or to some, another can of worms)Unable to transmit, Error: ...
Last edited by Gampy on Sat Aug 01, 2020 5:19 am, edited 1 time in total.
Intelligence is in the details!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!