PCM Hammer Release 014
Re: PCM Hammer Release 014
I did just notice that it is failing on the second call to Cleanup().
Timeout issue maybe in the loop ... still should not crash, it should gracefully bitch and quit.
Never quite understood that, the finally block has worked all the time I have been involved in the project, maybe at an earlier point in development it wasn't being triggered and it's a left over, there is a note in the code that says,
Maybe it's time to remove it ...
Timeout issue maybe in the loop ... still should not crash, it should gracefully bitch and quit.
Never quite understood that, the finally block has worked all the time I have been involved in the project, maybe at an earlier point in development it wasn't being triggered and it's a left over, there is a note in the code that says,
- Code: Select all
await this.vehicle.Cleanup(); // Not sure why this does not get called in the finally block on successfull read?
Maybe it's time to remove it ...
Windows 10 is like an off idle flat spot ... It stumbles when it's time to go!
Re: PCM Hammer Release 014
I just got v14 compiled. I’ll remove the first call and leave the finally block to see if that resolves it.
Re: PCM Hammer Release 014
That might get you past the issue, but not solve it ...
It would be better to find the issue and fix it first.
I assume you know right were to look.
It would be better to find the issue and fix it first.
I assume you know right were to look.
Windows 10 is like an off idle flat spot ... It stumbles when it's time to go!
Re: PCM Hammer Release 014
Gampy, I'm guessing here, but it looks like it having a problem changing back to 4x mode on the 2nd reset. Something in the FindResponseFromTool function.
Re: PCM Hammer Release 014
I verified that this.ReadDVIPacket on line 164 of OBDXProDevice.cs returns null and line 165 triggers the exception. Line 184 of Vehicle.Kernel.cs sets the device time to a minimum. I assume that the software is not waiting long enough for the response on the 2nd reset request. If so, what should the wait time be. I'll try reseting the wait time at the beginning of ExitKernel() to see if that will avoid the crash. Alternative, should there be null checking in OBDXProDevice.cs after this.ReadDVIPacket to ensure that the device actually responded appropriately?
Re: PCM Hammer Release 014
You're guessing pretty right ...
Stack trace says it failed in FindResponseFromTool(...), FindResponseFromTool(...) is called from SetVpwSpeedInternal(...).
I suspect ReadDVIPacket(...) returns a 'null' when it should return a Response<Message> ... Might have a look at line 331 and 342 in ReadDVIPacket(...).
Stack trace says it failed in FindResponseFromTool(...), FindResponseFromTool(...) is called from SetVpwSpeedInternal(...).
I suspect ReadDVIPacket(...) returns a 'null' when it should return a Response<Message> ... Might have a look at line 331 and 342 in ReadDVIPacket(...).
Windows 10 is like an off idle flat spot ... It stumbles when it's time to go!
Re: PCM Hammer Release 014
Ah Ha, Port.Receive(...) will bail if it's not in try catch blocks, that is most likely the problem ...
Something like the following,
Obviously adjusted to fit each location in ReadDVIPacket(...) ...
Something like the following,
- Code: Select all
try
{
await this.Port.Receive(rx, 0, 1);
}
catch (TimeoutException)
{
this.Logger.AddDebugMessage("Timeout.. no data present.");
return Response.Create(ResponseStatus.Timeout, (Message)null);
}
Obviously adjusted to fit each location in ReadDVIPacket(...) ...
Windows 10 is like an off idle flat spot ... It stumbles when it's time to go!
Re: PCM Hammer Release 014
I think the delay between this.Port.Send(Msg) in SetVpwSpeedInternal and the this.ReadDVIPacket in FindResponseFromTool is too short. I moved the await Task.Delay(50) to the start of the for loop in FindResponseFromTool in OBDXProDevice.cs, as well as added null checking. The null checking (without moving the wait to the front of the for loop) did catch the error and prevented the crash, but didn't perform the function. Moving the delay to the front of the for loop made the switch to 4x work. Below is the modified FindResponseFromTool for your consideration for change in the next build.
I also commented out the first call to await this.vehicle.Cleanup(); in the try section of ReadContents, which avoided the double call to Cleanup.
public async Task<Response<Message>> FindResponseFromTool(byte[] expected)
{
//this.Logger.AddDebugMessage("FindResponse called");
for (int iterations = 0; iterations < 5; iterations++)
{
await Task.Delay(50);
Response<Message> response = await this.ReadDVIPacket(this.GetReceiveTimeout());
if (response == null)
break;
if (response.Status == ResponseStatus.Success)
if (Utility.CompareArraysPart(response.Value.GetBytes(), expected))
return Response.Create(ResponseStatus.Success, (Message)response.Value);
}
return Response.Create(ResponseStatus.Timeout, (Message)null);
}
I also commented out the first call to await this.vehicle.Cleanup(); in the try section of ReadContents, which avoided the double call to Cleanup.
Re: PCM Hammer Release 014
Pretty sure the issue stems from my previous thoughts ...
Are you willing to try some changes from me ??
Are you willing to try some changes from me ??
Windows 10 is like an off idle flat spot ... It stumbles when it's time to go!
Re: PCM Hammer Release 014
Good debugging there. Are you sure the dvi (xpro) isnt crashing, and it really is not returning a response? Can you exit pcmhammer, start it again, and does the xpro init ok from software or does it need a power cycle?
Have you read the FAQ? For lots of information and links to significant threads see here: viewtopic.php?f=7&t=1396
Return to GM LS1 512Kbyte and 1Mbyte
Who is online
Users browsing this forum: No registered users and 10 guests