[cgrey8]

There's probably 1 person thinking "There's no FN1360 in the GUFx strats!" But the most readers are probably thinking, "WTF is FN1360?" If you fall into that category, you'd be in good company since most people that use BE don't remember the various scalar/function/table parameters via their PID names.

So what is FN1360? It's the Fuel - Stabilized OL Table or FN1360 for short. This is a table that describes how to set LAMBSEs during OL. It is similar to the GUFx Fuel - Base OL Table or FN1307 for short. However the difference is that FN1307 is temp/Load% based where the temp is a ratio between ACT & ECT as defined by the scalar FRCBFT. By default FRCBFT is set to 0 which means "temp" is 100% ECT and 0% ACT. So unless you change that scalar, you may assume "temp" is ECT.

The concept of FN1360 was introduced somewhere around GURE. Ford realized that it's method of OL fuel control was cumbersome and needed to be simplified. So they added FN1360 as a flip-over table. FN1307 was developed so that Ford could gain control over AFRs under cold ECT conditions and being able to define the AFRs in terms of temp/Load% made the most sense at the time. The Fuel Startup table or FN1306 accompanies the cold start conditions with even more enrichment that gradually decays, based on time since crank. The limitation with FN1307 is you cannot describe AFRs for different RPMs under non-WOT conditions. The AFR is fixed for all RPMs of a given temp/Load%. People that use the WOT functions, this is not much of a limitation since WOT Fuel Multiplier vs RPM or FN303 lets you do just that. But even with this, the commanded AFRs (i.e. LAMBSEs) aren't explicit. They are defined via a combination of FN1307 and FN303 so if you want to determine what LAMBSEs you'll generate, you have to "do the math". There's not a straight-forward way to set commanded AFRs in an RPM/Load% format like you could if you had a Fuel table based on RPM/Load%. Most people don't really find this a limitation since they run Closed Loop and aren't in FN1307 at non-WOT conditions for long after crank. And when they are at WOT, they don't generally target different AFRs as the RPMs increase. Once they go WOT, they target a single AFR and try to get the tune to maintain that AFR from the start to the end of the WOT run. For these people, the GUFx stock offerings work.

So who should get excited about FN1360? People that run All-Time OL or simply want better AFR control at both WOT and non-WOT Open Loop conditions. Personally, I want to use FN1360 to get my AFRs closer to where I know LAMBSE "want" to be after returning from DFSO. My tune runs a tad lean at idle and off-idle conditions. So when I return from DFSO due to low-RPMs, I need the LAMBSEs to be lower than if I return from DFSO at higher RPMs. FN1360 will allow me to do just this.

Sounds good, so what's the catch? The catch is as previously mentioned, FN1360 isn't part of GUF1, GUFA, or GUFB. It has to be added to the code manually which is exactly what I've been doing, with the help of sailorbob. By the way, this new feature is his handy work, I've just been helping to debug it since I have a TwEECer and the desire to see FN1360 work for my own uses. This morning, we finally got the code working as intended and would like to solicit for others wanting to give it a try. It does require a manual modification to the BIN itself to add the code necessary to use FN1360. Once added, it also requires a new def file that knows where FN1360 and it's related scalars and functions are. The defs aren't ready for release yet, but are good enough for people just wanting to beta test the new feature to see how they like it. I've got some feature requests in with Clint for updating BE to possibly automate the BIN-patching process. But until then, the manual method isn't too terribly difficult with HEX editor experience for those that want an FN1360 table as part of their GUFx tune.

So notice I mentioned there are other scalars and functions associated with FN1360? Here they are in detail:

FN1360 - Fuel Stabilized OL Table based on RPM/Load%. It uses the existing FN070 scalar function to scale its columns. As well, it uses the existing FN072A to scale it's Load% rows. FN1360 is activated when WRMEGO is TRUE and FLG_ECTSTABLQ is TRUE. Until these conditions are met, FN1307 is used. Once the supporting patch code is added to your BIN, the Z_TABOFT scalar is used to activate the code.

ECTSTABL - ECT temp must be at or above this value before FLG_ECTSTABLQ is set TRUE. Setting this scalar to -256 flips to FN1360 as soon as WRMEGO is set TRUE. Recommended value is 180°. Setting this value lower should not be required, however if done may require modification to FN325 (mentioned below).

ECTSTHYS - A hysteresis for ECTSTABL. Default value is 20.

Z_TABLOFT - This is the switch value that activates FN1360 when the supporting code is present in the tune. This parameter should NEVER be activated by someone working with a BIN that doesn't have the supporting patch code applied to their BIN file. Setting this switch without the supporting patch code and attempting to execute the unpatched BIN in the EEC is unpredictable with the most likely result being the engine going dead. I would really prefer to have this setting hidden from the user interface but BE doesn't currently have a way to "always hide" a scalar. I'll just do the best I can at warning people NOT to mess with this scalar if they don't have a patched BIN. I'll also see if I can get a website link put into the description pointing them to this thread where they can get more info on what's required for FN1360 support.

FN325 - Stabilized Fuel Multiplier vs ECT. With the recommended ECTSTABL value, this function should only contain multipliers of 1. No known EEC-IV stock tune has values other than 1 here insinuating Ford used this function only for testing purposes. Modification of this function should not be required. However if lower ECTSTABL values are entered, adjustments in this function may be needed to enrich the values from FN1360 to accommodate for colder ECT temps.

Once I get BE's 3 GUFx defs updated to support "patched" BIN files, I'll make these available...somehow. Likely, I'll pass the necessary files to Clint to post on the BE website. But for now, I just wanted to get a feel for how many people, if any, are actually interested in this new feature. BTW, to make use of this requires that you have your tune in *.BIN format and that you use BinaryEditor to maintain your defs.

[Foxfan88]

Sounds like a great idea, i would be really interested in the feature, i always liked how CBAZA had its fuel tables reference load and RPM.

to me the ECT part of the FN1307 is almsot useless since the FN1306 can be adjusted for cold start conditions.

one thing i am wondering is what will be the best way to adjust lambses based on ECT, i am mostly concerned about cold start AFRs, with my combo, with a cam and etc i find that my car seems to like slighty more enrichment on cold starts than the stock tunes give. and i am talking REAL cold, like lately, if its above 40 degrees i dont usually have problems. just when its colder than that.

it seems like FN325 could be used effectively for enrichenment based on ECT, for colder starts and for perhaps hotter temps if the engine is overheating, extra fuel can be dumped in to engine to cool it off, this would work assuming its kicking into OL based on to high of an ECT.

but it almost seems like FN1306 would still be the best bet right??

[cgrey8]

The intention is to continue to use FN1306 and FN1307 during startup until the ECT is above ECTSTABL. Assuming you crank with the engine warm and above ECTSTABL, you'll still use FN1306/FN1307 until the HEGOs indicate they are warm as defined by EGOCL1. So you don't abandon FN1307, you just flip over to FN1360 once it no longer makes sense to control LAMBSEs via ECT...i.e once ECT has stabilized or the engine has gotten warm enough that it no longer needs special enrichment.

Because FN1306 and FN1307 are more appropriate for warming up an engine, it's best to leave them as the enrichers until the engine is at least into the low 100s. That's about as low as I'd recommend setting ECTSTABL. However if there's still some enrichment that's needed beyond that point, then FN325 could do it, but like I said, the real intention is that FN1360 not be used until the engine is up near running temps. But to each his own how he wants to setup his tune.

[bender460]

Great work! I sure am interested.

[Foxfan88]

The intention is to continue to use FN1306 and FN1307 during startup until the ECT is above ECTSTABL. Assuming you crank with the engine warm and above ECTSTABL, you'll still use FN1306/FN1307 until the HEGOs indicate they are warm as defined by EGOCL1. So you don't abandon FN1307, you just flip over to FN1360 once it no longer makes sense to control LAMBSEs via ECT...i.e once ECT has stabilized or the engine has gotten warm enough that it no longer needs special enrichment.

Because FN1306 and FN1307 are more appropriate for warming up an engine, it's best to leave them as the enrichers until the engine is at least into the low 100s. That's about as low as I'd recommend setting ECTSTABL. However if there's still some enrichment that's needed beyond that point, then FN325 could do it, but like I said, the real intention is that FN1360 not be used until the engine is up near running temps. But to each his own how he wants to setup his tune.

ahh yes, that makes much more sense now, sorry i didnt realize that before. so in a nutshell you guys are going to implement the fuel table features of CBAZA (and others like it) into the older GUFx defintions.

should work awesome!

[Cougar5.0]

Sounds interesting - certainly adds a measure of control over AFR that could prove useful. Huh, I just noticed that the equivalent to FN1306 in CBAZA - FN1361 has the FN018 y-axis scaled out to 80-240 seconds versus 45. I was just thinking how FN1306 hands over to FN1307 a little too soon.

So, you can add this code to your present bin in combination with a compatible def file. Would these defs & a matching "starter" bin ever be added to BE by default, or do you think this will remain something that will have to be manually downloaded by someone who pursues it? Probably be good if the splicing could be automated and the code could be removed if needed. I assume you'd need a unique naming convention for the new defs & bins. I'll be looking for feedback from those who can still drive their car - mine is trapped in the garage with snow now on the ground

[cgrey8]

...I just noticed that the equivalent to FN1306 in CBAZA - FN1361 has the FN018 y-axis scaled out to 80-240 seconds versus 45. I was just thinking how FN1306 hands over to FN1307 a little too soon...

Even in GUFx, that's adjustable if you want it to "hand over" a little later. But to be technically accurate, FN1306 doesn't really relinquish control. It is ALWAYS in the FN1307 calculations. This is why it is important that the top cells of FN1306 in your engine's running ECT temp range (i.e. 180-210) be 1s so that FN1306 no longer has an effect on your OL LAMBSEs. Making those top cells a value other than 1 keeps FN1306 in the mix all the time. I made that mistake.

...So, you can add this code to your present bin in combination with a compatible def file. Would these defs & a matching "starter" bin ever be added to BE by default, or do you think this will remain something that will have to be manually downloaded by someone who pursues it?...

Currently, I have the existing GUFx defs modded to support FN1360. This was accomplished by first conditionally hiding FN1360 when the scalar Z_TABLOFT is disabled. As well there are duplicate function entries in the def where the only difference in them are comments that make reference to FN1360. One duplicate is conditionally hidden when Z_TABLOFT is enabled, the other is hidden when Z_TABLOFT is disabled. So people with stock tunes should never see a reference to FN1360. However if you get your BIN modded and activate the feature, then the associated scalar functions and comments in FN1307 update to make reference to FN1360. This gives us the ability to move forward without the need for 6 GUFx defs.

...Probably be good if the splicing could be automated and the code could be removed if needed...

Already asked Clint what he can do about that. As for BINs that start off with the patches applied, I don't think that is unreasonable.
GUF1 can have a patched A9P.
GUFA can have a patched A9S.
GUFB can have a patched A9L, X3Z, and S0Z.

Since the 3 BINs in GUFB are so radically different from each other, it makes sense that those 3 would need to be patched.

The interesting thing is FN1360 & FN325 are put in the same locations for all 3 GUFx strats. The locations for the table and function were arbitrary based on a location that wasn't being used by GUFB. Since GUFA and GUF1 are "smaller" tunes, those same locations are vacant in them as well. Z_TABLOFT is the switch that "enables" the FN1360 logic. It is located in the section of code that is common between all 3 strats. Therefore adding these additions to GUF1 and GUFA was a piece of cake...no differences in memory offsets for any of the components. As well, the instructions for applying the patch code and table data to a GUFx BIN file will be the same no matter whether you have a GUF1, GUFA, or GUFB based BIN.

BTW, the updated GUFx def files, patch code, and instructions have been sent to Clint to get posted. I'm not sure whether he's going to post a tool to help you patch your BIN or if he will just post up the patch files for me to link to so I can instruct people on how to manually patch a BIN using a HEX editor.

[Cougar5.0]

...I just noticed that the equivalent to FN1306 in CBAZA - FN1361 has the FN018 y-axis scaled out to 80-240 seconds versus 45. I was just thinking how FN1306 hands over to FN1307 a little too soon...

Even in GUFx, that's adjustable if you want it to "hand over" a little later. But to be technically accurate, FN1306 doesn't really relinquish control. It is ALWAYS in the FN1307 calculations. This is why it is important that the top cells of FN1306 in your engine's running ECT temp range (i.e. 180-210) be 1s so that FN1306 no longer has an effect on your OL LAMBSEs. Making those top cells a value other than 1 keeps FN1306 in the mix all the time. I made that mistake.

True, it is always there as an "adder" (or subtractor to be accurate) - I forgot about that. I think I will extend the time as it gets a little iffy at cold temperatures. BTW, you meant to say "0", not "1" on the top cells (I noticed CBAZA zeros some columns before the top row at higher temps).


I'll comment more on the patch stuff once I see it for real.

[cgrey8]

You are absolutely right. I meant adder, not multiplier. And I meant 0, not 1. Thanks for keeping me honest. I frequently make mistakes and do not mind being corrected. I don't want to be the source of "bad" information.

[Cougar5.0]

No prob, I knew what you meant - that's why I wasn't a d!(k head about it

[Frit]

You should also use ECTSTHYS which sets up the temperature hysterisis to go back to the "cold" tables. The temperature to reenter is ECTSTABL - ECTSTHYS which in GURE is defaulted to 20 degrees. You may also want to adjust your Base OL table in the higher temperature and higher load areas to match FN1360. Lots of time I've sat at the track on a cold day, went for a blast and wonder why the heck my AFR was at 10.1 instead of 11.78 and it was because my ECT went below the above settings and I was running off of the Base OL table.

I've even seen this on the dyno as well, and almost started correcting for it until I realized what was going on. In GURE, the stock settings are 180 to go into FN1360 and obviously 160 to come out of. I typically lower that to about 165 or so when I tune an SC and leave the ECTSTHYS alone and that works really well.

Frit

[cgrey8]

Those are the same defaults we have for this GUFx addition. Like I said, a lot of the values, code, and behavior is inspired from GURE.

However, I've been experimenting with an ECTSTABL value of 80 instead of 180 just to see how that works. I adjusted FN325 down in the lower temp range as well to make sure I still got some enrichment up till the 160s. Once the engine is that warm, it's long since gone CL and even if I crank it that warm, it doesn't need that much enrichment at all. It's only at the ECTs lower than that where enrichment is pretty much a must. So far, setting ECTSTABL that low is not having any undesirable effects. I'm in FN1307 until WRMEGO kicks TRUE, then in FN1360, then CL. But I've only had it this way for a day or so AND I enter CL pretty quickly so it's not like I'm using FN1360 that much to get a feel for how well this is working.

[Foxfan88]

are the only requirements for CL on a GUFx eec is that WRMEGO= 1???
and the OCPLT timers delay things so you cant go into CL early and TEMPFB is there for cold/medium starts. and hotstarts always above TEMPFB (in factory tune).

so i wonder how well it work work to set the TEMPFB scalar to the same value as the new ECTSTABL, that way on cold starts. the EEC will use just the FN1307 during warm up and before CL, once CL kicks in (TEMPFB is exceeded and timers have passed, WRMEGO is set true assuming the HEGO has already switched... and then CL begins) and then kick over the FN1360 (since ECTSTABL is the same as TEMPFB so ECTSTABL becomes true and WRMEGO will be true.)

then on hot starts all you have to wait for is the hot start timer OPCLT3 to pass and then WRMEGO is set and both CL and the FN1360 table will kick in at the same time.

that way WRMEGO and TEMPFB/ECTSTABL (sort of the same in a way) will control when CL and the FN1360 table kicks in.

really doesnt matter but if someone is anal enough and wants things perfect. that way CL isnt entered when your still using the Base table FN1307.... not that it matters but AFAIK the OL tables have absolutly no affect on CL fuel control right???

[cgrey8]

I enter CL as fast as the HEGOs will allow. I've found my HEGOs are warm in 30 seconds, so even when the engine is VERY cold, CL still kicks in just shy of 35 seconds after crank. Even if the HEGOs aren't warmed up enough, the worse they'll do is run the engine a little richer...not a bad thing with the engine being cold. So far, I haven't had any ill effects of running CL this soon. It's been this way for well over a year. Until the engine "tells" me it doesn't like this anymore or I have a good reason to change this, it'll stay this way.

[xr4x4ti]

I just wanted to post a quick note and say you guys are amazing

To me, this was the one problem with using the A9L ECM and you have fixed it! I even considered switching to the CBAZA strategy to just get this function.

Thanks again,
Tim
XR4X4Ti

[cgrey8]

The credit goes to sailorbob for developing the patch. I just did the testing. What absolutely amazes me about him is he's shown exhaustive dedication to the GUFx defs over the years. To my knowledge, he doesn't even own a GUFx EEC. He has developed the GUFx defs because learning them has enabled him to better understand his UK strats which unfortunately don't have an accessible strategy document to reference like the GUFB doc and some of the other strategy docs.

[Cougar5.0]

Yep. sailorbob is one smart/determined dude. He must have a great deal of patience to grind through the code.

[svojohn]

Yep. sailorbob is one smart/determined dude. He must have a great deal of patience to grind through the code.

Sailorbob is definitely a stand up guy. I'll add to your post by saying "he has a great deal of patience answering questions from people like myself".

[86GT]

Chris when I get back from vacation I will post the def files. I will still need to create some sort of tool to insert the code into a bin and so forth.

Sailorbob is an oustanding standup guy.

[cgrey8]

Just an update, I'm working with Clint to get the necessary files visible so people interested in giving this new feature a try can patch their existing BIN(s). He's got the files posted, I just don't have the link(s) to them yet. Once I do, I'll get a link to them into this thread. There's already a rudimentary Readme.txt file I wrote up explaining where in the BIN to patch. But for those not familiar with HEX editors, it may take more than just the Readme.txt to get you moving in the right direction.

If you don't have a HEX Editor, you might want to search the Internet for a free one. I use HEX Editor v2.0 by Alexander Bessonov of HHD Software. Although looking at their website, they have something called HEX Editor Neo for free now. I don't know anything about it or how it works as an editor. But I'd expect it to work similar to any other HEX editor.

[Cougar5.0]

Chris, can't the hex editor in TunerPro be used?

[cgrey8]

Sure. I've never used it, but I don't see why it wouldn't work. All you'll be doing is opening a patch.BIN file, Ctrl-C copying out the contents of that file, and Ctrl-V pasting it at a specified location in your existing BIN, then saving. That's about it as far as getting the patch code into your BIN. From there, you use BE to activate FN1360 and begin manipulating the data in FN1360 and FN325.

The FN1360-supporting GUFx def files (version "y") are already posted on the BE website in their respective locations.

[86GT]

The patch code is now at the following.

http://www.eecanalyzer.net/tech/

Look at the last entry named FN1360

[Foxfan88]

perhaps someone could post of a detailed "how-to" about patching a BIN.

i downloaded the hex editor chris linked to above. i opened a BIN of mine, and opened both the patch_code.bin and table_data.bin in there also. i copied the stuff in the smalle files and pasted them into the places it said in the readme file.

i have 56k BINs so i used the values it said to use for those. i enables the FN1360 in BE and one time it screwed up the BIN, alot of tables and functions were just off the wall crazy. tried it on another BIN and it didnt screw it up. i got FN325 to show up in the BIN but i cant find the NF1360 table.

i am a newb to working with code so i dont know if i screwed up or not or if its a problem elsewhere. kept trying and i get the FN325 function to show up but the FN1360 table is nowhere to be found. i also am running the correct defintion, the "y" version, downloaded from the site the other day.

[86GT]

I will have a BE tomorrow that will have the import routine for these patches. I will explain how it is done when i post it.

[cgrey8]

It sounds like you were doing it correctly particularly if FN325 was showing up. My gut feeling is FN1360 was also there, but you may have been glazing over it.

BTW, Clint sent me the pre-released BE that has the patch code import feature and it seems to work. I found some usability issues with the 1st version and this morning he got me a version that works exactly as I'd expect it to. I had the patches applied and the scalar turned on in less than a minute...far easier than messing around with a HEX Editor. And when I did those things, both FN325 and FN1360 showed up for me in BE. BTW, the FN325 and FN1360 would show up in BE regardless of whether you actually applied the patchs or not. But the BIN simply wouldn't work if you didn't have the patch code applied since what that the Z_TABOFT scalar is doing is vectoring off the EEC's processor to a location in memory that wouldn't have any valid instruction code. So your success applying the patch files would be completely independent of FN325 and FN1360 showing up in BE. However I do have to admit I've only tested this patch on a GUFB processor using the GUFB def file. It's quite possible there's a bug somewhere in the GUF1 or GUFA def file. I'll go check that out right now and see what's happening with them.

In anycase, Clint should have that version of BE posted sometime today since I can't find any further bugs with it.

[cgrey8]

You are absolutely right, FN1360 didn't make it into GUF1 and GUFA. All the other supporting stuff was there, but the main entry for FN1360 didn't get copied over from GUFB. I'll send the updated GUF1 and GUFA defs to Clint to post along with the BE updates.

The updated defs will be GUFx Rev 43z. Note the GUFB Rev will remain at "y" since no modification was required for it.

[cgrey8]

Clint's got the GUF1 and GUFA def files posted. As well, he's also got his latest version of BE posted that allows you to do the patch file application from within BE. Run the web updater for BE and you should get both the defs and the BE updates to support applying BIN patch files to tunes.

Once you get everything installed, open the new def file & your tune into BE, and apply the FN1360 patches via the Bin Explorer which is the very infrequently used button directly under the Binary File Open button. Inside the Bin Explorer (BE's HEX editor), you should now have an Insert button. Click that and navigate to the patch_code_1_13.bin file. Once you've selected it, BE will ask you where to insert it. Most people using BE to tune for the TwEECer will have 56k BINs. So enter 6800 for a value. You'll notice BE jumps to 0x6800 in the BIN and shows that stuff was applied there. Do the same thing with the table_data.bin inserting at 7ea2 (the address doesn't appear to be case sensitive in BE), and that should be it for applying the patches.

If your BinExplorer doesn't have the 3rd Insert button, then you don't yet have the BE update. Force the update or download the latest BE installer and manually reinstall BE to get that feature.

[Foxfan88]

awesome. it works now. turns out i did patch the BIN correctly after all beacuse once u loaded up the new definition, the FN1360 showed up. didnt even have to mess with the bin explorer.

this should be an excellent addition to have. thanks for all the help.

[cgrey8]

No problem. I hope having it helps people to better perfect their tunes. But the real thanks and credit goes to sailorbob. Without him, MOST of what you see in the GUFx defs wouldn't be here. He took the time to COMPLETELY break out the GUFx defs leaving no known scalar, function, or table unexposed...some of which were really needed. Others were just for reference to help other people that want to break out similar strats.

But if anybody feels compelled to show their thanks monetarily, PM sailorbob for details. I've tried multiple times to donate to his "Tea and Biscuits" fund in an effort to show my appreciation for his determination in helping us, but he won't take my donations.

By the way, here's the broken out procedure to follow to get FN1360 into your tune using BE:

1. Unzip the contents of FN1360.zip to a location on your harddrive. Remember that location.
2. Open your tune in BE.
3. Click the Explore BIN button that is right below the button that opens a tune.
4. Select the Range to go from the default of 100, to 8000
5. Hit Refresh
6. Click the Find Address Button
7. Assuming your tune's BIN file is a 56k BIN file (most users of the TwEECer are 56k), then you'll want to enter 6800 which is a HEX value and hit <ENTER> to accept. This should take you to 6800 in your tune. Notice there's nothing in the 6800-6850 lines...just a bunch of FFs. This is an indication that you are at the right place.
8. Click the Insert button inside the BIN Explorer Window
9. Browse to where you unzipped that zipfile up in step 1.
10. Double-Click the patch_code_1_13.bin file to select it.
11. Insert the patch at 6800. Now you should see that something has been inserted in the 6800-6850 rows. That's the patch code.
12. Click the Find Address Button
13. Enter 7EA2 which is a HEX value and hit <ENTER> to accept. This should take you to the 3rd cell of the 7EA0 row in your tune. Notice there's nothing from that cell on except a bunch of FFs.
14. Click the Insert Button again
15. Browse to where you unzipped that zipfile up in step 1.
16. Double-Click the table_data.bin file to select it.
17. Insert the table data at 7EA2. Now you should see that something has been inserted in the 7EA2 cell and continues on until the 7EF0 row. That's the FN325 and FN1360 data.
18. Close out of the BIN Explorer window to get back to Binary Editor.
19. Search for the scalar Z_TABOFT.
20. Enable it.
21. Now Go to your Table View and Look for a table called Fuel - Stabilized OL. That's FN1360. It should be populated with various values that resemble AFRs. If it doesn't then something went wrong in the process. If it does, then save this tune.

EDIT:
These directions worked with the version of BE I had at the time. However since then, BE made some relatively major changes going into BE2012. It has been added back to BE. In my current rev 5.27.23, it can be found under the Open Icon at the top of the screen. If you don't have the open icon visible, add it. When clicked, Binary Explorer should be the last entry in the menu that appears when the Open icon is clicked.

However if you are still finding using BE to be problematic, here's links for patching BINs the "original" way before BE had the Binary Explorer user interface.

FN1360 Application Instructions.doc

hexedfull.ex_