PCM Hammer Release 014

They go by many names, P01, P59, VPW, '0411 etc . Circa 1999 to 2006. All VPW OBD2 PCMs.
Posts: 35
Joined: Tue Dec 31, 2019 11:24 am

Re: PCM Hammer Release 014

Postby ColPaul » Sat Aug 01, 2020 1:50 am

Anytime. Happy to test more if you want to work on it more. It is the least I can do after you guys did all the hard work on this. I really like having open source tools that are user community supported. Thank you for this excellent product. My dad is ecstatic that we can change any of the features we want on the PCM. Got his speedometer working and calibrated yesterday. Today we are going to use the Fan #1 controls on the PCM to replace the simple coolant temperature switch. Thank you!

User avatar
Posts: 730
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Release 014

Postby Gampy » Sat Aug 01, 2020 3:22 am

Awesome!
Glad it's making pops happy!

Does the tool need to be power cycled between reads, can you open, read, close, open, read without power cycling??
Temporary is a permanent problem!

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

Re: PCM Hammer Release 014

Postby ColPaul » Sat Aug 01, 2020 5:33 am

I just tested with the latest OBDXProDevice.cs that you sent. I can do back to back full OS reads without power cycling the PCM and without restarting PCMHammer.exe.

User avatar
Posts: 730
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Release 014

Postby Gampy » Sat Aug 01, 2020 6:20 am

Thank you!
Temporary is a permanent problem!

User avatar
Posts: 730
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Release 014

Postby Gampy » Sun Aug 02, 2020 10:09 am

ColPaul,

I was just re-reading some of this, for clarification, moving the delay up in the loop makes the following errors go away ??
Unable to transmit, Error: ...
Temporary is a permanent problem!

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

Re: PCM Hammer Release 014

Postby ColPaul » Sun Aug 02, 2020 11:24 am

I don’t think so as I believe that error pops up even before the 2nd call to ExitKernel. I’ll try the latest working OBDXProDevice.cs file you sent me that works and I’ll comment out the line in the routine after ExitKernel (ClearTroubleCodes?) that switches to the minimum wait time. Let me know if there is a different version of OBDXDevice.cs that you want me to test instead.

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

Re: PCM Hammer Release 014

Postby ColPaul » Sun Aug 02, 2020 1:17 pm

I ran the clean source code plus your latest OBDXDevice.cs file without making any other changes. I don't think the timeout value being set to Minimum in ClearTroubleCodes.cs is the issue as there are these errors reading the response from the OBDX has nothing to do with the wait time. In addition, moving the wait to the beginning of the for loop in FindResponseFromTool should have no effect as ReadDVIPacket is not the bad actor anymore.

I ran the compiled program 5 times and captured the debug log. Each of the "Unable to transmit, Error:" errors happens at the same place in the process. Below is a grep of the debug logs for the error string. If I understand J1850 correctly, the error happens only when trying to Clear Codes (mode 04, 14), Send Test device present (mode 3F) or whatever mode 3d does.
[Pauls-MacBook-Pro:~/Downloads] paul% grep Unable Debug*
Debug.rtf:[09:26:13:099] Unable to transmit, Error: 8C FE F0 3F\
Debug.rtf:[09:30:34:271] Unable to transmit, Error: 68 6A F0 04\
Debug.rtf:[09:30:35:139] Unable to transmit, Error: 68 6A F0 04\
Debug2.rtf:[09:26:13:099] Unable to transmit, Error: 8C FE F0 3F\
Debug2.rtf:[09:30:34:271] Unable to transmit, Error: 68 6A F0 04\
Debug2.rtf:[09:30:35:139] Unable to transmit, Error: 68 6A F0 04\
Debug2.rtf:[09:33:14:862] Unable to transmit, Error: 8C FE F0 3F\
Debug2.rtf:[09:33:19:242] Unable to transmit, Error: 6C 10 F0 3D 00\
Debug2.rtf:[09:37:36:522] Unable to transmit, Error: 68 6A F0 04\
Debug2.rtf:[09:37:38:104] Unable to transmit, Error: 8C FE F0 14\
Debug3.rtf:[09:51:34:775] Unable to transmit, Error: 68 6A F0 04\
Debug3.rtf:[09:51:36:438] Unable to transmit, Error: 8C FE F0 14\
Debug4.rtf:[09:51:34:775] Unable to transmit, Error: 68 6A F0 04\
Debug4.rtf:[09:51:36:438] Unable to transmit, Error: 8C FE F0 14\
Debug4.rtf:[09:53:19:939] Unable to transmit, Error: 8C FE F0 3F\
Debug4.rtf:[09:53:24:333] Unable to transmit, Error: 6C 10 F0 3D 00\
Debug4.rtf:[09:57:44:501] Unable to transmit, Error: 68 6A F0 04\
Debug4.rtf:[09:57:46:673] Unable to transmit, Error: 8C FE F0 14\
Debug5.rtf:[09:51:34:775] Unable to transmit, Error: 68 6A F0 04\
Debug5.rtf:[09:51:36:438] Unable to transmit, Error: 8C FE F0 14\
Debug5.rtf:[09:53:19:939] Unable to transmit, Error: 8C FE F0 3F\
Debug5.rtf:[09:53:24:333] Unable to transmit, Error: 6C 10 F0 3D 00\
Debug5.rtf:[09:57:44:501] Unable to transmit, Error: 68 6A F0 04\
Debug5.rtf:[09:57:46:673] Unable to transmit, Error: 8C FE F0 14\
Debug5.rtf:[09:59:58:776] Unable to transmit, Error: 8C FE F0 3F\
Debug5.rtf:[10:00:03:358] Unable to transmit, Error: 6C 10 F0 3D 00\
Debug5.rtf:[10:04:52:511] Unable to transmit, Error: 68 6A F0 04\
Debug5.rtf:[10:04:54:220] Unable to transmit, Error: 8C FE F0 14\

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

Re: PCM Hammer Release 014

Postby ColPaul » Sun Aug 02, 2020 2:04 pm

It may be the Fireball talking, but it looks to me like SendDVIPacket calls ReadDVIPacket. I added a this.Logger.AddDebugMessage statement and confirmed that all the SendDVIPacket errors come from ReadDVIPacket in the block starting at OBDXDevice.cs line 337. Not sure the details of DVI Packets, but hopefully this will point people smarter than me in the right direction to fix the remaining errors. Should SendDVIPacket call ReadDVIPacket again if the first call to ReadDVIPacket received a network message vs. a device message? If so, should the code in the block starting at line 337 return ResponseStatus.Timeout vs. ResponseStatus.Error?

User avatar
Posts: 730
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Release 014

Postby Gampy » Sun Aug 02, 2020 6:18 pm

Thank you!

Mode 3D is specific to PcmHammer.
Submode 00 is Get Kernel Version.
Thus 3D00 is PcmHammer asking the Kernel it's Version.

As for the rest, haven't taken the time to understand the logic of that device or it's code ... Yet!
Temporary is a permanent problem!

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

Re: PCM Hammer Release 014

Postby ColPaul » Mon Aug 03, 2020 1:20 pm

I changed line 474 of OBDXDevice.cs to:

if ((m.Status == ResponseStatus.Timeout) || (m.Status == ResponseStatus.Error))
{
continue;
}
break;
}

This added the ability to ignore a ResponseStatus.Error vs failing out of SendDVIPacket. Assuming the program is not on the 10th read attempt in the for loop on line 471, then the ResponseStatus.Error (presumably from network frame) will be ignored and ReadDVIPacket will be called again. When I made this change, it eliminated all the "Unable to transmit" errors. Ignoring ResponseStatus.Error and retrying regardless of the error source is probably not what is needed as ResponseStatus.Error is returned from ReadDVIPacket for several reasons, one of which is if this.Port.Receive(rx, 0, 1) on line 229 receives a network frame vs. device message.

I don't know anything about network messages vs. device messages, but it seems like ReadDVIPacket should return something other than ResponseStatus.Error if it receives a network message. Maybe line 342 should recursively call ReadDVIPacket and return the response from the recursive call or ReadDVIPacket could return a unique response for receiving a network frame. Maybe return ResponseStatus.UnexpectedResponse, so that SendDVIPacket could fail gracefully from one of the other error sources and retry ReadDVIPacket if ResponseStatus.UnexpectedResponse is received.

PreviousNext

Return to GM LS1 512Kbyte and 1Mbyte

Who is online

Users browsing this forum: No registered users and 1 guest