Fuel pump prime time pid?

[jonygeorge]

I have an aeromotive fuel pressure regulator and always have to cycle my key 2-3 times to fully pressurize my fuel lines so the engine starts on the first try. I found an old post from 2015 where the same topic was discussed and decipa said he changed the a9l2 base tune so that it would run the pump for three seconds? No mention was made of how he did it just that he did. I am already using a9l2 as my base and would like it to prime for 5 or 6 seconds. If anyone knows which pid to use or how to make this happen on GUFB, let me know. Thanks !

[LeadHead]

Basically the EEC-IV hardware is configured so the fuel pump control circuits by default are activated. Once the processor finishes initializing, the fuel pump turns off. You'd have to hack in some code to keep the pump priming.

Why is your regulator bleeding down? It should be able to hold pressure over night. Additionally it should only take like 1 second to pressure the fuel lines. It sounds like your fuel pump has a bad check valve allowing the rail to bleed down.

[cgrey8]

My old adjustable FPR was the same way. With a fuel gauge connected, I could watch it bleed down in a matter of about 5-10 seconds. And I too had to switch the ignition ON and OFF a few times right before cranking to prime the line. Otherwise cranking took noticeably longer. When I put the 331 in, I just reverted back to the stock FPR which holds pressure just fine.

I only put the AFPR on because at the time, I thought my injectors were undersized...and it was something I could use to toy with to experiment. Once I got a WB, I could see, they weren't but the FPR was already on, so I just got used to having to prime the truck before cranking. I was glad to go back to the stock FPR with injectors that were no where near being undersized.

[jonygeorge]

Thanks for the reply, maybe I’ll look into a different regulator or just eliminating the aeromotive one, actually I think my problem might be related to my having switched to an in tank pump and still having an external regulator at the same time. I installed a gas tank out of a newer model 1998 jeep Cherokee after I had everything all set up for the external pump that needed the regulator and just left it on, I could be wrong but my understanding is that the in tank pump that I am using doesn’t need a regulator at the fuel rails at all and it should be self regulating at 42 psi. Although I don’t understand how that type of pump-regulator works accurately without a vaccume line?

[decipha]

i broke that scalar out a couple years ago, download tunerpro and my gufx xdf, you can simply change the pump prime time scalar to anything you want.

Theres prob 40-50 custom parameters I have added to gufx that isnt in the regular gufb.

[Vortech347]

Decipha,

Is there anyway to get this magical scalar into an older BE2010 with a Tweecer R/T?

[jsa]

Decipha fell out with some here.

If your BE def is plain excel you could add the scalar by getting the info from the xdf and manually adding.

[Vortech347]

Sounds good. I'll research how to do this process. Thank you.

[motorhead1991]

I've added this hack to every tune I've worked on in the last 6 months

[Vortech347]

Motorhead, you wouldn't by chance be able to insert that into my current bin tune?

I did some searching and I can't find GUFX.XLS that Binary Editor will recognize.

This is clearly above my paygrade to get this Scalar into my current tune. The GUFB I'm running is from quite some time ago just downloaded from the Binary Editor website. I saw that there is a GUFX patch, but again, I have no clue how to implement...

[cgrey8]

If it's just a simple exposure of a scalar, let me know what the offsets are for GUF1, GUFA, and GUFB. I can get them added. It'd make a nice addition to the rescaling of BZZTM that was found at fault here recently. With these two things, maybe it'd actually feel like an update to the defs worth releasing.

[Chucko]

The fuel pump prime time in GUFB isn't a calibration PID, it's an immediate constant in this code:

Code: Select all

#################################################################
# Tasklist Routine at 2151, routine offset 2E
# Update fuel pump enable. Skip if flag set.
# turn pump off if more than 1 sec elapsed since last PIP occurred
#################################################################


  Update_fpump:
50ee: 38,d9,11            jb    B0,Rd9,5102      if (Vip_fp_override == 0)  {
50f1: a3,72,be,14         ldw   R14,[R72+be]     R14 = TSLPIP;
50f5: 89,00,04,14         cmpw  R14,400          
50f9: d3,04               jltu  50ff             if ((uns) R14 >= 400)  {          # 1024 = 1 second
50fb: 71,7f,46            an2b  R46,7f           Pump = 0;
50fe: f0                  ret                    return; }

50ff: 91,80,46            orb   R46,80           Pump = 1; }
5102: f0                  ret                    return;

You're looking at a 2-byte constant at 0x50f6 (offset 0x30f6), the units are 1/1024 seconds. The factory value of 0x400 = 1024 = 1 sec.

Have at.

[motorhead1991]

The fuel pump prime time in GUFB isn't a calibration PID, it's an immediate constant in this code:

Code: Select all

#################################################################
# Tasklist Routine at 2151, routine offset 2E
# Update fuel pump enable. Skip if flag set.
# turn pump off if more than 1 sec elapsed since last PIP occurred
#################################################################


  Update_fpump:
50ee: 38,d9,11            jb    B0,Rd9,5102      if (Vip_fp_override == 0)  {
50f1: a3,72,be,14         ldw   R14,[R72+be]     R14 = TSLPIP;
50f5: 89,00,04,14         cmpw  R14,400          
50f9: d3,04               jltu  50ff             if ((uns) R14 >= 400)  {          # 1024 = 1 second
50fb: 71,7f,46            an2b  R46,7f           Pump = 0;
50fe: f0                  ret                    return; }

50ff: 91,80,46            orb   R46,80           Pump = 1; }
5102: f0                  ret                    return;

You're looking at a 2-byte constant at 0x50f6 (offset 0x30f6), the units are 1/1024 seconds. The factory value of 0x400 = 1024 = 1 sec.

Have at.

Yup, offset 50f6 and 50f7. It's technically a hack but doesn't adversely affect things to my knowledge.

[cgrey8]

Just for my own understanding, what makes it a hack vs being like any other scalar that has an offset location and conversion? I'm sure it has something to do with the structure of the code. But being I'm not intimately familiar with how Ford structured the code, the nuance is lost on me.

[Chucko]

The GUFx code, and probably lots of other strategies, are organized such that the code itself doesn't change between calibrations. Only the constants, functions, and tables differ. Those have PIDs associated with them.

This is a "hack" because you have to modify the code itself. There are several other such "hacks" in the existing GUFB strategy, including the patch that reads the zero page registers out of the 8065.

[cgrey8]

In the case of a more modern program where there's storage like a file system with executable files and data files, it's easier to describe what's data and what's code and where it comes from. However in the case of a completely compiled application, it just seems like splitting hairs to differentiate what's code and what's data. But again, I'm saying this without nearly the knowledge and experience reading and deciphering the code as others.

In my head the best I can make of the difference in this case is an opcode that references a register that holds a pointer pointing to the data that the opcode operates on vs an opcode where the data is an operand (no pointer). Is that at least in the neighborhood of being the difference?

[Chucko]

In my head the best I can make of the difference in this case is an opcode that references a register that holds a pointer pointing to the data that the opcode operates on vs an opcode where the data is an operand (no pointer). Is that at least in the neighborhood of being the difference?

Yeah, that's right on the money.