Thread Rating:
  • 1 Vote(s) - 3 Average
  • 1
  • 2
  • 3
  • 4
  • 5
fault blocking with calterm
#6
(12-20-2018, 10:58 AM)MaraJin Wrote:
(12-18-2018, 04:43 PM)sjw1987 Wrote: Hi, sorry for the late reply. But basically I have a paid someone to do a scr delete file for me and he has half done it and said put into the ecm and he will finish the delete. But has ignored me and left me with nothing worth having. So looking at the calibration compare and some values have been adjusted. So was going to try blocking the remaining codes that are active and try that on my truck. Any suggestions greatly appreciated

what year, make, model engine / truck?. Sounds like your dealing with a ameture not worth destroying engine over experiments of some idiot. It one thing to hack into ecm. I know guys who r expert at getting into ecm and running CT and other software but have no clue how engine work internally. Oh, wait, i just described most guys doiong that stuff lol . -  - It totally another to know how not to cause engine damage. Removing those systems in itself causes great harm to engine without a lot of proper custom re-mapping of the combustion process. If the guy cant get even the simple stuff turned off correct, theres no way he gonna understand how to re-map the fual-air, timing, burn control, aux emissions, and all other stuff in motor the right way.


evevryone think its just a matter of shut stuff off or block it from working, but they are badly mistaken and only end up with failed engine a year or so later.

btw: a decent delete does not need a single block code in block table if things were switched off properly.

here is a quote from a famous document..

Quote:There is a method to the Parameter Editing madness!!! ...

    Now that we have covered the main portion of the EGR system, Engine Emissions system, its sensors, and the EGR Valve,.. ,.. I would think you are starting to see a repeating pattern here. That pattern is how to properly deal with the individual system components and sensors one at a time properly. It is not just random madness, or guess-work at play here to get the right set of changes, but rather a set process towards accomplishing your goals. These goals follow a set set of tasks that are repeated for every sensor and system in an ECM,.. and it helps us to understand what is going on with a clearer picture.

    Every sensor has a hardware input, some kind of output or result, it has a default or 'Fall-back' setting if it fails or is switched off, it has sub-system logic that is specific to it, it has upper and lower limits, digital to Analog (DAC) conversions, bit-counts, User Override settings, etc.etc.etc. – And many of them also include perhaps an auto-zeroing function, some kind of In-range diagnostic, and don't forget that the ECM will report to external engine software to let it know if that sensor is or is not present, can or cannot be monitored, can or cannot be changed or overridden, edited,.. etc. too.

    To put is bluntly, THERE IS NO SIMPLE OFF-SWITCH for sensors and systems insidee an ECM. It is a complex integrated system, that is all tangled up into itself. Remember the tangled mess of fish-hooks analogy I mentioned on the CM871? – Yup,.. its like that!. – So how does one make sense of it all and keep track of what to do so that nothing gets missed or overlooked?,.. How does make sense of this? --- Well,.. by taking a basic engineering approach to it,... it is not any kind of secret method,.. You deal with it by creating a set pattern or process out of what you need to accomplish, then stick to that process.

    These set set of tasks should be performed for each sensor,.. or system,.. to bring it into check,.. any time you intend to alter something, or even perhaps disable it all together, here is what to do...

    For input devices, like feedback sensors,... This is the standard issue list of things/tasks you need to perform in order to control or remove the device properly. Not finding or dealing with every one of these tasks, only leads to problems in the ECM. You will end up with faults that should not happen,.. or an unexplained instability or eroneous results. Every time you are dealing with any sensor or logic system, you have these same set of tasks you need to perform,.. or ask yourself,.. how can I apply this set of tasks? ...

For Input Devices and sensors...

    *Unassign the hardware pin and/or resource. Some ECM's have programmable resistor pull-ups that can be assigned to hardware pins too, so that has to be considered as well.
    *Adjust any digital to analog fault control logic so that errors do not occur. Many ECMs use up/down counters to pass fail the feedback values. those counters have to be dealt with.

    *Adjust the allowed upper/lower boundry limitys of the digital to analog feedback so that a value of 0x00 or 0xFFFF (or whatever the max val. is) does not trigger a fault after it is unplugged/disabled.

    *Establish any default value(s) to replace the now missing  feedback so that systems that ely on that data in the ECM do not become unstable.

    *Disable any auto-zeroing or other functions in ECM that take place at startup/shutdown. Also any systems directly related to any of these functions.

    *Disable any in-range and/or other self-diagnostic features for the sensor or system.

    *Disable or deal with any reporting to external engine software so that someone connected to the engine with diagnostic software does not see a sensor that is no longer present or active and think there is a problem.

    *Disable any associated engine Fault processing, derates, or engine shutdowns related to the sensor.

    *Adjust/Disable any other associated logic/sub-logic systems that rely directly on the sonsor.

    *For Control Devices, you also need to  disable/turn off any functions, outputs, or associated tasks that it may want to perform.

    If you are trying to 'switch off' a sensor in an engine, and you cannot satisfy or answer how to perform each and every one of these tasks mentioned, or at least were able to definitively answer each one of these concerns, You likely have not done a proper job yet. Sticking to a set process and covering all the required areas that need to be looked at, or altered, will set you on the right track towards accomplishing your final goal. You should take such things as your starting point, not your ending point. – Every system and sensor in an ECM is heavily integrated into it,.. and it requires a lot of thinking 'outside the box' a bit. One good example of this is the measure of charge flow in an engine. There is no single sensor for this in most ECMs, yet the engine knows what it is. HOW? – By reading several sensors at once and then doing some math to get an end result. Taking out one of these sensors will ultimately destroy the math and you get problems real fast. sometimes it is even with some other system in the engine that you may not have even known was even in control.

    Preventing these kind of logic failures consists of doing research for what that system is ultimately for,.. what it effects,.. and what its new values should be. If your removing it,.. what default setting it should have for those systems still attached to it, or that have to rely on data from it. – Think about what happens when someone tries to remove the turbo inlet temp sensor. It messes up a lot of things in the ECM including charge flow calculations, combustion offsets, final crank angle estimation, and a whole lot more. The only way it can be done properly is to deal with every one of those systems at once and set a default for it in the mid-range of what it would normally read. Even so, the charge flow logic now has to be corrected to include the missing data in its tables. – I am not trying to promote removing this important sensor,.. I just know the typical butcher-shop delete companies like to kill it because they don't want to take the time to mount it onto those crappy fixed-vane turbo they push onto their victims so readily.

Hi thank you for this, has gave me a very good insight into whats involved. I guessed there was going to be abit more involved than blocking the codes just felt abit stuck as paid out and ended up with nothing worth having so was trying to do the best i could with it
  


Messages In This Thread
fault blocking with calterm - by sjw1987 - 12-13-2018, 07:56 AM
RE: fault blocking with calterm - by zyNoT - 12-16-2018, 04:21 PM
RE: fault blocking with calterm - by sjw1987 - 12-18-2018, 04:43 PM
RE: fault blocking with calterm - by fazooley - 12-20-2018, 03:24 PM
RE: fault blocking with calterm - by zyNoT - 12-20-2018, 06:37 PM
RE: fault blocking with calterm - by Zezima - 01-31-2019, 09:47 PM

Forum Jump:


Users browsing this thread:
8 Guest(s)