Kirby@PCMTec

Request duly noted.

This was a guide I wrote as an example of how it *could* be done. its not the way it must be done. we expect every shop to come up with their own preference based on the car type, fuel system type, packaging etc. The key part is that you have a compatible Flex to CAN converter, that is configured correctly and is connected to the correct can-bus so we can receive the messages at the PCM.

Just a note for anyone that is interested in this and runs off and buys a ECA-2 from Zeitronics. You will also need to buy their serial cable adapter (and a RS232 port or USB to RS232 Adapter) for a one time programming of the CAN ID of the device. AEM make an acceptable OBD sandwich plate that just breaks out the can-bus - this is suitable in this case because we source the power from the fuse tap in the above document. When they went from PFI (Gen2) to DFI+PFI (Gen3) there was a big behind the scenes change, not just in hardware. The Gen2 fuel model was more-or-less in-house code, which had been progressively built up since probably the EEC-V days - but realistically has a lot in common with the CopperheadB Gen1s. In some parts of the assembler we can see similarities or variables that we even had here in the "Australian" PCM's from 20 years ago. Gen3 represents a huge departure in the fuel/spark model as to implement this Ford started to use, what appears to be, somewhat "off-the-shelf" software models provided by Bosch, which means all new parameters and tables, and the code is quite different - as is the order of execution. Effort has been made on Fords' part (probably to save the sanity of the calibrators there) to create tables which somewhat align in function to the old PFI tables, in name etc, but the way we identify them they look completely different to us hence the different ID's.

Its not that straightfoward, they probably are in the template them because technically they "exist" in the calibration, and our tools detect and map them. But just because they exist - doesn't mean they are actually used in the code. If its fuel or spark in Gen2 > Gen3 there is alot of "leftover" code that exists but is never used - its why they are probably zeroed out. There seems to be significant differences in the flex implementations between the f150 and mustang. Honestly, the best option is to disable the ford flex logic and use ours from CustomOS - its about 100x easier.

@bankyf it is auF61902 - "PFI injector offset temp. modifier" as it only applies to the PFI system. Temperature sites are the same, but for some reason we have its unit set to temperature (Celcius) and for it to display correctly the Z data type must be set to Celcius (if you've globally changed to freedom units - it might not display correctly - there seems to be another display bug here I need to look into). make sure its set to deg C in the context menu: Looks like Slope Compensation (auF61903) is similar (and set to 1.0x across the board) I've made a note - and I will fix this shortly (but I am going to have to ask the template team) - I am sure there is some weird data-type conversion that our automated tools have messed up. I think we have said it a thousand times, we have something like 100k parameters in the database, we rely on automatic tools to find and categorise these in every OS. And then we loop back and manually fix it, but it can be slow going - threads like this definitely help us identify "parameters of interest" Teach a man to fish part: 1) Make sure development parameters are turned on 2) I searched for the terms "injector temp" 3) Because its a gen 3 there are two fuel systems in play (DFI and PFI) so the PFI terms were of immediate interest to me. 4) then I looked for tables that had a similar axis and worked back: NB: I suspect the other two terms "Injector Offset Correction as a Function of Temperature" auF30313 might be from the Gen2 (PFI only) code which still exists in the PCM and *may* not be used, or may be additional Ford modifiers ontop of the bosch sub-system for fuel injection. Cheers and have a great weekend.

From memory these are workshop only MIDs'

Hey Guys, Just a quick note to say sorry for all the spam and subsequent spam notifications on the forum. Someone decided to give us alot of grief on pcmtec.com signup - just to post nonsense on the forum - often quicker than we can delete it. We keep making changes, but sometimes they are still sneaking through. Bear with us - we will fix it. Cheers Guys

Hey @Austen Did Roland's advice help? did increasing the decimals fix your issue. I will check and see if we can add a default in for that level. Thanks

Hey Guys, We have just deployed our brand new support portal. It links together several services that have previously been separated. This will improve support for everyone. Available via support.pcmtec.com (and all associated links) Change Log: You can now login using your pcmtec.com login! New searchable knowledge base, which combines our FAQ, User guides and forum articles (we are growing this slowly) New ticket form for submitting tickets New portal for viewing all your ticket history ever (we will be bringing over historical tickets in the future) Please check it out feedback (and patience if there are any issues) is always appreciated. Cheers

Hey Guys, As I go through renaming and brushing up my technical German, here are the parameters that are particularly related to "Fußpunktadaption" (e.g. base adaptation). Temperature: Upper - ZF00026 Lower - ZF00027 Current - (Fuß > Base) - so Base current, TID: 001022 Upper - ZF00326 Lower - ZF00327 ZF01002 - Adaptable Base Current Torque: Upper - ZF02213 Lower - ZF02214 TCC/Turbine Speed: Upper - ZF02441 Lower - ZF02442 RPM: ZF03892 - Maximum permissible control deviation Time parameters of interest: ZF03229 - Time in which to adapt (possible drive time, or limit of running adaption) ZF03230 - Preparation time for soothing (possible hysteresis or settling time) ZF03231 - Time for switching on the switch point (possible drive time?) ZF03113 - Load free must be passed (possible timer for an idle time before/after adaption) TID of interest: TID002456 - Status value of the base point adaptation (so maybe a status flag of adapted/not adapted) TID000916 - Flag of the setpoint being applied (I think this might be a flag for "adaption in progress") TID002212 - Adaption Time Counter (possible relation to the timers above) TID002481 - counter adaptations (possible number of adaptation cycles performed) TID002482 - counter TCC activations For guys playing around with this, might be worth having a look at some of these TIDs and see if we can gleam anything.

The real testament will be getting to a stable adaptation value (over say 100km) then resetting it again, and doing a similar cycle and seeing if you adapt to similar numbers again...

And this has survived a power cycle with ZF02859 set to 2? Would be interested to know how much time/driving is required to see other values start to populate.

Sorry this is my bad. I recently did an update on the website and this page was not updated correctly. It's all fixed now. Downloads page is only available to registered customers who have purchased a products, this page now contains that information. As @Roland@pcmtec mentioned, the demo is no longer available.

Like all things there is lots of ways to skin a cat, the best thing about the CHT method (which we discussed in the office) - was that you can stage it, and by default the first stage adds a bunch of fuel - adding cooling and reducing your power. In the event of a entire LoS of oil pressure or fuel pressure a straight engine kill might be useful, but it might also be incredibly dangerous depending on what speed/gear/corner you are turning.