PCM Hammer Release 015

They go by many names, P01, P59, VPW, '0411 etc . Circa 1999 to 2006. All VPW OBD2 PCMs.
User avatar
Posts: 520
Joined: Fri Feb 02, 2018 3:13 pm

PCM Hammer Release 015

Postby NSFW » Fri Dec 25, 2020 9:55 am

PcmSantaHatCropped.jpg
PcmSantaHatCropped.jpg (152.98 KiB) Viewed 1716 times


Zip file updated January 30 2021

New in this release:

* A bunch of fixes and improvements from Gampy (check out the progress bar!)
* A completely rewritten data logging app from me

Known issues in this release:

* The data logger is slow and unreliable when I try to log just two or three parameters. Adding a couple more parameters makes it fast and reliable. This might only be an issue with the AllPro, but I recently redid my bench setup and that's the only interface that's working at the moment. I'd love to know whether this is an issue with other interfaces too.

The zip file below is not an official release yet - it's an invitation to test a bunch of new code. :) Especially the data logger. My car is on jack stands right now so I've only tested it on my workbench.
Attachments
PcmHammer015.zip
(2.01 MiB) Downloaded 105 times
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!

Posts: 127
Joined: Mon Feb 11, 2019 12:48 pm
Location: DFW, Texas

Re: PCM Hammer Release 015 (Preview)

Postby jlvaldez » Fri Dec 25, 2020 4:02 pm

I'm interested in the datalogging. Particularly if you can do the VPW raw logging ;)

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

Re: PCM Hammer Release 015 (Preview)

Postby Gampy » Fri Dec 25, 2020 6:37 pm

Sweet ... Thank you!

How about 015a (Preview) ... :lol:
Feed the beast, the beast gets bigger, DON'T FEED THE BEAST!

User avatar
Posts: 520
Joined: Fri Feb 02, 2018 3:13 pm

Re: PCM Hammer Release 015 (Preview)

Postby NSFW » Fri Dec 25, 2020 6:58 pm

jlvaldez wrote:I'm interested in the datalogging. Particularly if you can do the VPW raw logging ;)


If you mean passively recording everything on the VPW line, that was on my "some day maybe" list, but now that you're making such good progress on that front... :)

This release is totally focused on logging batches of parameters from the PCM, just for standard tuning purposes ("under what conditions is the engine knocking?"). But if we can find some good parameters to log from other modules, that could happen in a future release. I have a hunch we could get brake pressure from the EBCM for example. I haven't tried yet though. And I'm a little concerned that the data rate would be too slow to be useful. I get about 6 rows of data per second just logging from the PCM, which IMO is just barely enough, and pulling just one parameter from another module might cut that down to 3 or 4 rows per second.

On the other hand, I also think that I could almost double the data rate if I (or someone) can figure out how to command the PCM to send data continuously rather than querying for each batch of data... but I haven't been able to get that to work reliably yet. I works for a while but it randomly stops. I'm pretty sure it's possible with some more experimentation though.
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!

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

Re: PCM Hammer Release 015 (Preview)

Postby Gampy » Fri Dec 25, 2020 10:05 pm

An inquisitive mind desires to know the reason for the return move, are both locations not effectively the same ??
Code: Select all
diff --git a/Apps/PcmLibrary/Devices/ElmDevice.cs b/Apps/PcmLibrary/Devices/ElmDevice.cs
index 96ac2bb..ecf74d7 100644
--- a/Apps/PcmLibrary/Devices/ElmDevice.cs
+++ b/Apps/PcmLibrary/Devices/ElmDevice.cs
@@ -105,15 +105,14 @@ namespace PcmHacking
                 this.MaxSendSize = this.implementation.MaxSendSize;
                 this.MaxReceiveSize = this.implementation.MaxReceiveSize;
                 this.Supports4X = this.implementation.Supports4X;
+                return true;
             }
             catch (Exception exception)
             {
-                this.Logger.AddDebugMessage("Unable to initalize " + this.ToString());
-                this.Logger.AddDebugMessage(exception.ToString());
+                this.Logger.AddUserMessage("Unable to initalize " + this.ToString());
+                this.Logger.AddUserMessage(exception.ToString());
                 return false;
             }
-
-            return true;
         }

         private async Task<bool> SharedInitialization()
Feed the beast, the beast gets bigger, DON'T FEED THE BEAST!

User avatar
Posts: 520
Joined: Fri Feb 02, 2018 3:13 pm

Re: PCM Hammer Release 015 (Preview)

Postby NSFW » Sat Dec 26, 2020 5:09 am

They'll run the same way but I think the newer one is slightly more maintainable / easier to debug. And I'll admit in advance that this is splitting hairs. :) But it's not about what the computer does, it's about what the code says to the developer who is maintaining it.

The new way makes it a little bit clearer that unless an exception is thrown, this function will return true. And if an exception is thrown, it will always return false. Thinking about the code this way just makes it easier to maintain, because it's a very simple and common pattern.

The old approach basically says, to the developer reading the code, "after executing the code in the try/catch block we'll find out whether to return true or false." Placing any code after the try/catch block (even one trivial line like "return true") implies that there's a reason to continue execuring after the try/catch. But there isn't. Moving the 'return' up above the 'catch' makes the simpler pattern easier to recognize and stick to.

Also, I just noticed that I screwed up the AddDebugMessage / AddUserMessage change. The "unable to initialize" message is something that belongs in the user log, but the exception call stack (exception.ToString()) belongs only in the debug log. I really don't ever want an ordinary user to see a call stack, because those are just noise to anyone who doesn't have a copy of the source code. EDIT: And I fixed that a minute ago.
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!

User avatar
Posts: 520
Joined: Fri Feb 02, 2018 3:13 pm

Re: PCM Hammer Release 015 (Preview)

Postby NSFW » Sat Dec 26, 2020 6:05 am

Gampy wrote:Sweet ... Thank you!

How about 015a (Preview) ... :lol:


That would have been a good idea because we're on 15 B now. :)

I've updated the zip file, it now includes the status with progress indicator. Nice work on that, Gampy!
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!

Posts: 351
Joined: Mon Mar 09, 2020 4:35 pm
Location: California

Re: PCM Hammer Release 015 (Preview)

Postby In-Tech » Sat Dec 26, 2020 4:29 pm

Just a fyi, both files trigger a malware scream. I haven't found anything wrong though. You guys rock :)

User avatar
Posts: 520
Joined: Fri Feb 02, 2018 3:13 pm

Re: PCM Hammer Release 015 (Preview)

Postby NSFW » Sat Dec 26, 2020 4:44 pm

I've seen that warning with other apps from GitHub, I think it's just because they're so new that the malware scanners haven't had time to analyze them yet.

There's nothing in here but tuning tools though, I swear! :)
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!

Posts: 37
Joined: Mon Jun 15, 2020 12:35 pm

Re: PCM Hammer Release 015 (Preview)

Postby aaronc7 » Sun Dec 27, 2020 1:17 am

NSFW wrote:
jlvaldez wrote:I'm interested in the datalogging. Particularly if you can do the VPW raw logging ;)


If you mean passively recording everything on the VPW line, that was on my "some day maybe" list, but now that you're making such good progress on that front... :)

This release is totally focused on logging batches of parameters from the PCM, just for standard tuning purposes ("under what conditions is the engine knocking?"). But if we can find some good parameters to log from other modules, that could happen in a future release. I have a hunch we could get brake pressure from the EBCM for example. I haven't tried yet though. And I'm a little concerned that the data rate would be too slow to be useful. I get about 6 rows of data per second just logging from the PCM, which IMO is just barely enough, and pulling just one parameter from another module might cut that down to 3 or 4 rows per second.

On the other hand, I also think that I could almost double the data rate if I (or someone) can figure out how to command the PCM to send data continuously rather than querying for each batch of data... but I haven't been able to get that to work reliably yet. I works for a while but it randomly stops. I'm pretty sure it's possible with some more experimentation though.


Is this just Mode $22 and $23 for now? Or have you got $2C / dynamic working? EFI also has some mode they call 'stream-fast' which allows 24 bytes to be logged at 10 hz. I'm definitely not knowledgeable enough at the programming level to make this work, just curious!

Next

Return to GM LS1 512Kbyte and 1Mbyte

Who is online

Users browsing this forum: No registered users and 2 guests