Here's a pertinent little quote from Albert Einstein

       "Information is not knowledge."

The quote encapsulates automotive diagnosis. In essence, the scantool
can provide most of the *information* that is required in the diagnosis
of a vehicle issue but it is up to the mechanic to be able to dissect,
discern, analyse and react to that information. It is the mechanic's
*knowledge* that will enable him to know where to look and what to do
with the scantool data (information) in order to understand the problem.

And that's where having the right tool for the job and knowing how to
use it comes in real handy! Knowing how to use it includes knowing what
the data that the tool presents actually represents and the
ramifications of said data in the operation of the vehicle.

Darren's scantool is a cheaparse *Chinese* Icarsoft unit with poor
functionality and even poorer support whilst Daryl's Autels are in the
hobbyist range, both being unable to provide the full range of
*professional functionality*. How odd, both of them consider themselves
professionals. Well, one of them is best described as a faker, no points
for guessing who, and he purchased the most cheaparse scanner of all.
Says a lot really. At a guess, I'd say their scantools would be capable
the *basics* mostly limited to modes $01 - $09.

Both of the supposed *professionals* say that OBDII systems don’t store
data. I have repeatedly claimed that they do. In fact *some* systems
post ~2000 stored freeze-frame and mode $06 data in NVRAM, basically in
an EEPROM. There’s a very good reason for this. Way back in ~2000, when
OBDII was introduced, a lot of emissions monitoring was added to the
OBDII specifications. For some extensive reading on the topic, go here;

https://ww2.arb.ca.gov/resources/documents/past-obd-ii-regulatory-documents

Provisions were included for emissions monitoring so that vehicle annual
emissions testing could detect cars with ineffective emissions control
systems and it wasn’t limited to *tailpipe emissions*. It also included
such items as evaporative emissions, PCY systems and EGR systems.
However, circa 2010, it was found that fraudulent mechanics (yeah, they
exist everywhere) were fooling the testing regime by clearing codes,
then sending vehicles in for testing before the full set of drive cycles
had been completed. The problems weren’t fixed and the DTCs returned
after x drive cycles. To combat this, a new mode was *enforced* and
emissions testing rules altered to accommodate it. This mode was the
tenth mode, mode $0A, and if a vehicle presented with no MIL but had
incomplete emissions monitors, it failed the emissions test. What's
more, once mode $0A became mandatory, any PDTCs which were not cleared
also caused a fail on an emissions test.

It was because of its mode $0A ability that, years ago, I purchased my
Actron Autoscanner. At the time it was one of the few low end scanners
that even had a clue what a mode $0A PDTC even was, much less possess
the ability to *extract it* from the OBDII datalink connector. Here is a
pertinent extract from the manual it came with;

Read Codes
To read the codes:
Press and hold the READ key for 2 seconds then release it,
or Select Read Codes from Main Menu.

When viewing codes, the Tool displays Pending, Confirmed and
Permanent Codes.

Pending Codes are only reported if a problem occurs during
the current or last completed drive cycle. Pending Codes
do not necessarily indicate a faulty component or system.
Pending Codes convert to Confirmed Trouble Codes when an
emissions problem persists long enough to be considered a
real problem, not an anomaly. Pending Codes are indicated
by a PENDING icon.

Confirmed Trouble Codes are reported when a component,
sensor, or other part of the vehicle is indicating a
malfunction is present. The malfunction must be present
for a sufficient amount of time before the vehicle records,
and the Tool displays, a Confirmed Trouble Code. Confirmed
codes are indicated by the CONFIRMED icon

Permanent Codes are a special confirmed code. Permanent Codes
began being reported by vehicles beginning around 2010, so
they were not initially supported by every vehicle. While
Confirmed Codes can be erased by the tool, Permanent Codes
cannot. Permanent Codes are erased only by the vehicle when
the vehicle itself has determined that the fault is no longer
present. Permanent Codes are indicated by a PERMANENT icon.

What is so special? Well, pending and confirmed codes can be extracted
using modes $03 and $07 of the scantool. Every scantool has mode $03,
most should now have mode $07 and every scantool has the ability to
*erase* mode $03 and maybe mode $07 codes. But not every scantool had
the ability to *extract* mode $0A codes. That is because they cannot be
erased by *any* scantool. The only thing that can erase them is the
module (ECM, PCM, BCM) that created them. So scantool manufacturers may
leave mode $0A out except on the higher end professional units. In fact,
the functionality could be easily added with a software update on the
scantool. Mode $0A requests emissions related DTCs with *permanent
status*, PDTC for short. This mode is required for *all* emissions
related DTCs post 2010 - a bit later in Australia - though they have
been present in some vehicles, typically US origin, since circa 2000
amid the origins of OBDII. If the MIL is *not* illuminated in the
presence of PDTCs at an emissions inspection, it's an indication that a
proper repair was *not verified* by the on-board emissions monitoring
system. IOW, it's likely that someone erased the Pending and Confirmed
DTCs using the scantool in an attempt to get a car through an emissions
test and, in doing so, erased all the monitors. This is what mode $0a
was designed to circumvent and, to this end, the PDTCs, along with other
relevant information, are stored in NVRAM. The NVRAM is typically an
EEPROM which only the on-board emissions monitoring system can erase. In
order to have the system erase the PDTCs, the *cause* of the problem has
to be *fixed* and then the vehicle has to be driven for a number of
drive cycles. For some minor PDTCs, this could be as few as 2 drive
cycles but for others, such as misfires, random or otherwise, it could
require as many as 15 drive cycles and a total distance covered of 300
kilometres. Here is what a single basic drive cycle consists of;

https://www.nonda.co/blogs/news/how-to-perform-a-basic-obd2-drive-cycle

Note step 1 - clear all OBDII DTCs with the scanner. What you won't be
able to do is clear any PDTCs because no scanners have that ability.
Only the on-board emissions system module has that ability and then only
on completion of the repair and after performing the requisite number of
drive cycles.
But look at step 2 - fuel tank between 30% and 70% full? That
requirement relates to evap system PDTCs and that part of the emissions
monitoring system requires some vent space in the tank, but not too
much, in order to carry out evap system monitor tests.
Step 3, much the same thing, the entire emissions monitoring and control
systems requires the battery and charging system to be in good order. A
battery or alternator below par will upset all reference voltages and
the monitors will not complete. If they don't complete, the PDTCs will
never be erased.
Step 4, the cycle has to be from a cold start and one of the monitors
assesses the time taken to warm up and go into closed loop mode.
Steps 5 - 10 provide the opportunity for myriad other monitors to do
their thing and test out the emissions system.

Now, if Darren had my little Actron scanner when the VE Commodore with
the random misfire and *cleared codes* turned up in his driveway, he
would have *still seen* the PDTCs even after he cleared *all other data*
that his scantool was capable of clearing. That PDTC would have told him
what was happening, diagnosis done, no guessing.

But his story on that Commodore is suss in so many other ways. One,
injectors are unlikely to develop random misfires when hot since, once
they are warmed up, they get more internal clearance, not less.
Injectors are more likely to misfire when cold, then perform perfectly
once warmed up. I have experienced precisely that effect on my previous
Corolla. That was caused by gummy injector plungers and cured by a
bottle of injector cleaner. It didn't generate *any* DTC since it
occurred only when cold and only prior to warm up when the system was
still in open loop mode. In fact it only occurred on the first few
revolutions of the engine on cold start. Another reason why a drive
cycle requires a *cold start*. What doesn't show up as a mode $0A PDTC
will still show up as continuous monitor values in mode $06 and they can
be very useful in diagnostics. This is why it is inadvisable to clear
codes, the mode $06 continuous and non-continuous monitor data is also
cleared in most cases, and this has a negative impact on diagnostics.

The misfire checking aspect is the most useful part of mode $06. Every
time a cylinder misfires, the system monitor increases the misfire
counter for that particular cylinder. Only if the misfire count exceeds
a certain threshold will a misfire DTC be set. If the misfire count
stays below the limit, no DTC is set and no notice is provided to the
driver but the misfire may still be felt when the engine is under heavy
load or acceleration. With the aid of the OBDII scanner, the actual
misfire counts recorded for each cylinder can be read. The purpose of
the misfire data is to aid in identifying which cylinders are currently
misfiring and identify which cylinders have been consistently misfiring
in previous driving cycles. The misfire count should be equal or close
to zero. In this case, there’s no problem. If a single cylinder misfire
count is higher relative to the other cylinder misfire counts, a
possible issue is present and that cylinder is experiencing abnormal
behaviour. It generally means there's a problem with either the
ignition, fuel or compression in that cylinder. It's important to
remember that misfire counts for cylinders should only be compared
relative to each other.

On 3/04/2023 2:38 pm, Xeno wrote:
> Here's a pertinent little quote from Albert Einstein
>
>        "Information is not knowledge."
>
> The quote encapsulates automotive diagnosis. In essence, the scantool
> can provide most of the *information* that is required in the diagnosis
> of a vehicle issue but it is up to the mechanic to be able to dissect,
> discern, analyse and react to that information. It is the mechanic's
> *knowledge* that will enable him to know where to look and what to do
> with the scantool data (information) in order to understand the problem.
>
> And that's where having the right tool for the job and knowing how to
> use it comes in real handy! Knowing how to use it includes knowing what
> the data that the tool presents actually represents and the
> ramifications of said data in the operation of the vehicle.
>
> Darren's scantool is a cheaparse *Chinese* Icarsoft unit with poor
> functionality and even poorer support whilst Daryl's Autels are in the
> hobbyist range, both being unable to provide the full range of
> *professional functionality*. How odd, both of them consider themselves
> professionals. Well, one of them is best described as a faker, no points
> for guessing who, and he purchased the most cheaparse scanner of all.
> Says a lot really. At a guess, I'd say their scantools would be capable
> the *basics* mostly limited to modes $01 - $09.
>
> Both of the supposed *professionals* say that OBDII systems don’t store
> data. I have repeatedly claimed that they do. In fact *some* systems
> post ~2000 stored freeze-frame and mode $06 data in NVRAM, basically in
> an EEPROM.  There’s a very good reason for this. Way back in ~2000, when
> OBDII was introduced, a lot of emissions monitoring was added to the
> OBDII specifications. For some extensive reading on the topic, go here;
>
> https://ww2.arb.ca.gov/resources/documents/past-obd-ii-regulatory-documents
>
> Provisions were included for emissions monitoring so that vehicle annual
> emissions testing could detect cars with ineffective emissions control
> systems and it wasn’t limited to *tailpipe emissions*. It also included
> such items as evaporative emissions, PCY systems and EGR systems.
> However, circa 2010, it was found that fraudulent mechanics (yeah, they
> exist everywhere) were fooling the testing regime by clearing codes,
> then sending vehicles in for testing before the full set of drive cycles
> had been completed.  The problems weren’t fixed and the DTCs returned
> after x drive cycles. To combat this, a new mode was *enforced*  and
> emissions testing rules altered to accommodate it. This mode was the
> tenth mode, mode $0A, and if a vehicle presented with no MIL but had
> incomplete emissions monitors, it failed the emissions test. What's
> more, once mode $0A became mandatory, any PDTCs which were not cleared
> also caused a fail on an emissions test.
>
> It was because of its mode $0A ability that, years ago, I purchased my
> Actron Autoscanner. At the time it was one of the few low end scanners
> that even had a clue what a mode $0A PDTC even was, much less possess
> the ability to *extract it* from the OBDII datalink connector. Here is a
> pertinent extract from the manual it came with;
>
>    Read Codes
>    To read the codes:
>    Press and hold the READ key for 2 seconds then release it,
>    or Select Read Codes from Main Menu.
>
>    When viewing codes, the Tool displays Pending, Confirmed and
>    Permanent Codes.
>
>    Pending Codes are only reported if a problem occurs during
>    the current or last completed drive cycle. Pending Codes
>    do not necessarily indicate a faulty component or system.
>    Pending Codes convert to Confirmed Trouble Codes when an
>    emissions problem persists long enough to be considered a
>    real problem, not an anomaly. Pending Codes are indicated
>    by a PENDING icon.
>
>    Confirmed Trouble Codes are reported when a component,
>    sensor, or other part of the vehicle is indicating a
>    malfunction is present. The malfunction must be present
>    for a sufficient amount of time before the vehicle records,
>    and the Tool displays, a Confirmed Trouble Code. Confirmed
>    codes are indicated by the CONFIRMED icon
>
>    Permanent Codes are a special confirmed code. Permanent Codes
>    began being reported by vehicles beginning around 2010, so
>    they were not initially supported by every vehicle. While
>    Confirmed Codes can be erased by the tool, Permanent Codes
>    cannot. Permanent Codes are erased only by the vehicle when
>    the vehicle itself has determined that the fault is no longer
>    present. Permanent Codes are indicated by a PERMANENT icon.
>
> What is so special? Well, pending and confirmed codes can be extracted
> using modes $03 and $07 of the scantool. Every scantool has mode $03,
> most should now have mode $07 and every scantool has the ability to
> *erase* mode $03 and maybe mode $07 codes. But not every scantool had
> the ability to *extract* mode $0A codes. That is because they cannot be
> erased by *any* scantool. The only thing that can erase them is the
> module (ECM, PCM, BCM) that created them. So scantool manufacturers may
> leave mode $0A out except on the higher end professional units. In fact,
> the functionality could be easily added with a software update on the
> scantool. Mode $0A requests emissions related DTCs with *permanent
> status*, PDTC for short. This mode is required for *all* emissions
> related DTCs post 2010 - a bit later in Australia - though they have
> been present in some vehicles, typically US origin, since circa 2000
> amid the origins of OBDII. If the MIL is *not* illuminated in the
> presence of PDTCs at an emissions inspection, it's an indication that a
> proper repair was *not verified* by the on-board emissions monitoring
> system. IOW, it's likely that someone erased the Pending and Confirmed
> DTCs using the scantool in an attempt to get a car through an emissions
> test and, in doing so, erased all the monitors. This is what mode $0a
> was designed to circumvent and, to this end, the PDTCs, along with other
> relevant information, are stored in NVRAM. The NVRAM is typically an
> EEPROM which only the on-board emissions monitoring system can erase. In
> order to have the system erase the PDTCs, the *cause* of the problem has
> to be *fixed* and then the vehicle has to be driven for a number of
> drive cycles. For some minor PDTCs, this could be as few as 2 drive
> cycles but for others, such as misfires, random or otherwise, it could
> require as many as 15 drive cycles and a total distance covered of 300
> kilometres. Here is what a single basic drive cycle consists of;
>
> https://www.nonda.co/blogs/news/how-to-perform-a-basic-obd2-drive-cycle
>
> Note step 1 - clear all OBDII DTCs with the scanner. What you won't be
> able to do is clear any PDTCs because no scanners have that ability.
> Only the on-board emissions system module has that ability and then only
> on completion of the repair and after performing the requisite number of
> drive cycles.
> But look at step 2 - fuel tank between 30% and 70% full? That
> requirement relates to evap system PDTCs and that part of the emissions
> monitoring system requires some vent space in the tank, but not too
> much, in order to carry out evap system monitor tests.
> Step 3, much the same thing, the entire emissions monitoring and control
> systems requires the battery and charging system to be in good order. A
> battery or alternator below par will upset all reference voltages and
> the monitors will not complete. If they don't complete, the PDTCs will
> never be erased.
> Step 4, the cycle has to be from a cold start and one of the monitors
> assesses the time taken to warm up and go into closed loop mode.
> Steps 5 - 10 provide the opportunity for myriad other monitors to do
> their thing and test out the emissions system.
>
> Now, if Darren had my little Actron scanner when the VE Commodore with
> the random misfire and *cleared codes* turned up in his driveway, he
> would have *still seen* the PDTCs even after he cleared *all other data*
> that his scantool was capable of clearing. That PDTC would have told him
> what was happening, diagnosis done, no guessing.
>
> But his story on that Commodore is suss in so many other ways. One,
> injectors are unlikely to develop random misfires when hot since, once
> they are warmed up, they get more internal clearance, not less.
> Injectors are more likely to misfire when cold, then perform perfectly
> once warmed up. I have experienced precisely that effect on my previous
> Corolla. That was caused by gummy injector plungers and cured by a
> bottle of injector cleaner. It didn't generate *any* DTC since it
> occurred only when cold and only prior to warm up when the system was
> still in open loop mode. In fact it only occurred on the first few
> revolutions of the engine on cold start. Another reason why a drive
> cycle requires a *cold start*. What doesn't show up as a mode $0A PDTC
> will still show up as continuous monitor values in mode $06 and they can
> be very useful in diagnostics. This is why it is inadvisable to clear
> codes, the mode $06 continuous and non-continuous monitor data is also
> cleared in most cases, and this has a negative impact on diagnostics.
>
> The misfire checking aspect is the most useful part of mode $06. Every
> time a cylinder misfires, the system monitor increases the misfire
> counter for that particular cylinder. Only if the misfire count exceeds
> a certain threshold will a misfire DTC be set. If the misfire count
> stays below the limit, no DTC is set and no notice is provided to the
> driver but the misfire may still be felt when the engine is under heavy
> load or acceleration. With the aid of the OBDII scanner, the actual
> misfire counts recorded for each cylinder can be read. The purpose of
> the misfire data is to aid in identifying which cylinders are currently
> misfiring and identify which cylinders have been consistently misfiring
> in previous driving cycles. The misfire count should be equal or close
> to zero. In this case, there’s no problem. If a single cylinder misfire
> count is higher relative to the other cylinder misfire counts, a
> possible issue is present and that cylinder is experiencing abnormal
> behaviour. It generally means there's a problem with either the
> ignition, fuel or compression in that cylinder. It's important to
> remember that misfire counts for cylinders should only be compared
> relative to each other.
>
> It needs to be said that any major PDTC that remains uncorrected after a
> drive cycle or three will definitely turn on the MIL again. Misfire
> related PDTCs are considered major and the system is designed to flag
> them if not repaired - but it takes a three or more drive cycles, and
> the monitors to go through their paces, for the system to determine
> that. As well, a misfire will create further DTCs, some of which will
> lead to other PDTCs. The obvious one is Bank x lean if the injector
> sticks shut. Think about that, the injector sticks shut, no fuel is
> injected on that cycle and no oxygen will be consumed because the fuel
> wasn't there to ignite. All that oxygen will go into the exhaust stream
> and simulate an extremely lean condition overall on that bank. If the
> injector sticking fault hangs around long enough to create a confirmed
> misfire DTC that turns on the MIL, at the very minimum it will also be
> creating another DTC related to exhaust gas makeup as detected by O2
> sensors and, because these will both be serious emissions related DTCs,
> they will definitely be stored in NVRAM as *Permanent DTCs*. And my
> scanner will see these PDTCs even if the owner has attempted to clear
> them.  ;-)
>
> Isn't it odd, I seem to recall some clown saying nothing is stored in
> NVRAM and all codes can be erased. Well, yes, he's half right,  all
> codes can indeed be erased but *Permanent DTCs* can *only be erased* by
> the *module* that initially *created them*, not by a scantool, and that
> erasure will only occur if the initial cause of the PDTC is correctly
> repaired and the requisite number of drive cycles confirm an effective
> repair. Since PDTCs, and sometimes mode $06 data, are stored in NVRAM, a
> power cycle doesn't erase their contents. All Darren had to do with that
> VE Commodore was plug in a mode $0A capable scantool, seek out the
> *permanent code, the *PDTC* and, voila, he knows the cylinder that isn't
> firing all the time. If the injector had stuck open, man would there be
> some *extra* codes along with a LHM - but you wouldn't want to use LHM.
> It could get to the point of hydralocking the engine if an injector
> sticks open - nasty.
>
>
^c^v

On 13/04/2023 10:02 pm, Keithr0 wrote:
> On 3/04/2023 2:38 pm, Xeno wrote:

<Insane irrelevant bullshit flushed>

> ^c^v

And the point of reposting all of that nonsense was?

If you want to get to the bottom of this Keith, and discover whether or
not this imbecile has a clue at all, then ask him to present you with an
example of a car, *any* car, that will allow you to go into it's ECU
with a scan tool and check to see what the short term fuel trims were at
precisely 3:04pm 4 Tuesdays ago.

He and his fucktarded Clog wearing dickhead mate *both* claimed that
engine data is continually and permanently stored and can be read at any
time, but despite this nonsensical shit neither of them has presented a
single example of any vehicle that permits you to do so.

This is standard fare for these mental cases. They make all kinds of
ridiculous claims safe in the knowledge that they will never have to
back them up with evidence :)

--
--
--
Regards,
Noddy.

On 15/4/2023 8:57 am, Noddy wrote:
> On 13/04/2023 10:02 pm, Keithr0 wrote:
>> On 3/04/2023 2:38 pm, Xeno wrote:
>
> <Insane irrelevant bullshit flushed>
>
>> ^c^v
>
> And the point of reposting all of that nonsense was?
>
> If you want to get to the bottom of this Keith, and discover whether or
> not this imbecile has a clue at all, then ask him to present you with an
> example of a car, *any* car, that will allow you to go into it's ECU
> with a scan tool and check to see what the short term fuel trims were at
> precisely 3:04pm 4 Tuesdays ago.
>
> He and his fucktarded Clog wearing dickhead mate *both* claimed that
> engine data is continually and permanently stored and can be read at any
> time,  but despite this nonsensical shit neither of them has presented a
> single example of any vehicle that permits you to do so.
>
> This is standard fare for these mental cases. They make all kinds of
> ridiculous claims safe in the knowledge that they will never have to
> back them up with evidence :)
>
None of our 3 cars store that sort of data in a way that is readable by
most scan tools, I even plugged my scan tool (Autel MS906BT) into each
car and went looking for the data (either STFT or LTFT), there was none
to be found, best was "live data".
Very likely ecu's save LTFT data but in general its not accessible with
most scan tools, possible that some factory scan tools can read it or
even some very expensive aftermarket tools but a $2000 scan tool like
mine can't.

--
Daryl

On 15/4/2023 8:57 am, Noddy wrote:
> On 13/04/2023 10:02 pm, Keithr0 wrote:
>> On 3/04/2023 2:38 pm, Xeno wrote:
>
> <Insane irrelevant bullshit flushed>
>
>> ^c^v
>
> And the point of reposting all of that nonsense was?

So *you* could *read it* and *respond*. You didn't let him down either!
>
> If you want to get to the bottom of this Keith, and discover whether or
> not this imbecile has a clue at all, then ask him to present you with an
> example of a car, *any* car, that will allow you to go into it's ECU
> with a scan tool and check to see what the short term fuel trims were at
> precisely 3:04pm 4 Tuesdays ago.
>
> He and his fucktarded Clog wearing dickhead mate *both* claimed that
> engine data is continually and permanently stored and can be read at any

Now you're bullshitting here. That is *not* what was said at all. Please
go back over the relevant thread.

> time,  but despite this nonsensical shit neither of them has presented a
> single example of any vehicle that permits you to do so.

If you have an engine misfire that is serious enough to light up the
MIL, then you will definitely have a *Permanent* DTC, or two, or three.
What you will also have is freeze frame data stored and, on some
vehicles, as with PDTCs, this too is stored permanently in an EEPROM. If
you clear the DTC, you will *still* have a PDTC visible which is stored
in an EEPROM and will be visible on any scanner, like my Actron, that
can show mode $0A data. What you will also have is *other DTC codes*
such as those related to O2 & HO2 sensors, typically system lean P0171 &
P0174 and fuel trims P0170 & P0173. These will also be *Permanent* DTCs
and will be retained in the OBDII system even after a mode $04 clear
data request so they can be accessed via a mode $0A request.
>
> This is standard fare for these mental cases. They make all kinds of
> ridiculous claims safe in the knowledge that they will never have to
> back them up with evidence :)
>
This from the clown who *never* backs up his claims with *evidence*.

FWIW, assuming your bullshit story on the VE Commodore stuck injector
has any truth to it, you should have advised the owner to do two things.

First, run a dose of injector cleaner through the fuel system. It works,
I know because I have done it successfully, and will likely clean up a
sticky injector issue.

On a recurrence of the stuck injector, and it will be *from cold*, if
the injector is reasonably accessible, tap the injector bodies with the
handle of a screwdriver whilst the engine is running. That should
unstick the injector plunger if that is indeed the cause of the random
failure.

The cause of injector sticking is typically varnish/resin from the fuel.
It can build up on the plunger and/or it can partially block the nozzle
orifice. Either way it will trigger DTC codes.

Since all injectors have been subjected to the same mileage and varnish
buildup, *all injectors* should be, at the very minimum, removed from
the vehicle and subjected to an ultrasonic clean, reverse flush, basket
filter change and flow test.
But, before that step, running a dose of injector cleaner through the
fuel system is a good start - even as a *maintenance procedure* - and
will likely solve the random misfire issue all by itself.
Just changing out one injector and not even doing a full service on the
others is shortchanging the customer in a big way. Talk about a half
arsed repair! All the other injectors could be, and likely are, on the
verge of misfire failure.

--
Xeno

Nothing astonishes Noddy so much as common sense and plain dealing.
(with apologies to Ralph Waldo Emerson)

On 15/4/2023 10:39 am, Daryl wrote:
> On 15/4/2023 8:57 am, Noddy wrote:
>> On 13/04/2023 10:02 pm, Keithr0 wrote:
>>> On 3/04/2023 2:38 pm, Xeno wrote:
>>
>> <Insane irrelevant bullshit flushed>
>>
>>> ^c^v
>>
>> And the point of reposting all of that nonsense was?
>>
>> If you want to get to the bottom of this Keith, and discover whether
>> or not this imbecile has a clue at all, then ask him to present you
>> with an example of a car, *any* car, that will allow you to go into
>> it's ECU with a scan tool and check to see what the short term fuel
>> trims were at precisely 3:04pm 4 Tuesdays ago.
>>
>> He and his fucktarded Clog wearing dickhead mate *both* claimed that
>> engine data is continually and permanently stored and can be read at
>> any time,  but despite this nonsensical shit neither of them has
>> presented a single example of any vehicle that permits you to do so.
>>
>> This is standard fare for these mental cases. They make all kinds of
>> ridiculous claims safe in the knowledge that they will never have to
>> back them up with evidence :)
>>
> None of our 3 cars store that sort of data in a way that is readable by
> most scan tools, I even plugged my scan tool (Autel MS906BT) into each

Odd then, isn't it, that my Actron autoscanner can read mode $0A data
and has been able to do so since I bought it some 9 or 10 years ago.

> car and went looking for the data (either STFT or LTFT), there was none
> to be found, best was "live data".
> Very likely ecu's save LTFT data but in general its not accessible with
> most scan tools, possible that some factory scan tools can read it or
> even some very expensive aftermarket tools but a $2000 scan tool like
> mine can't.

I did say that in a previous post. You need *professional* scan tools.

--
Xeno

Nothing astonishes Noddy so much as common sense and plain dealing.
(with apologies to Ralph Waldo Emerson)

On 15/04/2023 12:17 pm, Xeno wrote:
> On 15/4/2023 8:57 am, Noddy wrote:
>> On 13/04/2023 10:02 pm, Keithr0 wrote:
>>> On 3/04/2023 2:38 pm, Xeno wrote:
>>
>> <Insane irrelevant bullshit flushed>
>>
>>> ^c^v
>>
>> And the point of reposting all of that nonsense was?
>
> So *you* could *read it* and *respond*. You didn't let him down either!
>>
>> If you want to get to the bottom of this Keith, and discover whether
>> or not this imbecile has a clue at all, then ask him to present you
>> with an example of a car, *any* car, that will allow you to go into
>> it's ECU with a scan tool and check to see what the short term fuel
>> trims were at precisely 3:04pm 4 Tuesdays ago.
>>
>> He and his fucktarded Clog wearing dickhead mate *both* claimed that
>> engine data is continually and permanently stored and can be read at any
>
> Now you're bullshitting here. That is *not* what was said at all. Please
> go back over the relevant thread.
>
>> time,  but despite this nonsensical shit neither of them has presented
>> a single example of any vehicle that permits you to do so.
>
> If you have an engine misfire that is serious enough to light up the
> MIL, then you will definitely have a *Permanent* DTC, or two, or three.
> What you will also have is freeze frame data stored and, on some
> vehicles, as with PDTCs, this too is stored permanently in an EEPROM. If
> you clear the DTC, you will *still* have a PDTC visible which is stored
> in an EEPROM and will be visible on any scanner, like my Actron, that
> can show mode $0A data. What you will also have is *other DTC codes*
> such as those related to O2 & HO2 sensors, typically system lean P0171 &
> P0174 and fuel trims P0170 & P0173. These will also be *Permanent* DTCs
> and will be retained in the OBDII system even after a mode $04 clear
> data request so they can be accessed via a mode $0A request.

A PDTC can only be erased from memory if the OBD system extinguishes the
MIL (e.g., when the current DTC changes to a History DTC). If the memory
is not cleared with a scan tool, the ECM will need to see the related
monitor test complete and pass on three consecutive trips. The PDTC will
not be removed from memory until the fourth key-on cycle.

Note:-

If the memory is cleared with the scan tool, the MIL will be
extinguished; the MODE $03 DTC and MODE $02 Freeze Frame Data will be
cleared. The PDTC will still be in memory, _but it will take only one
good trip to remove it from memory_.

On 15/04/2023 8:57 am, Noddy wrote:
> On 13/04/2023 10:02 pm, Keithr0 wrote:
>> On 3/04/2023 2:38 pm, Xeno wrote:
>
> <Insane irrelevant bullshit flushed>
>
>> ^c^v
>
> And the point of reposting all of that nonsense was?
>
> If you want to get to the bottom of this Keith, and discover whether or
> not this imbecile has a clue at all, then ask him to present you with an
> example of a car, *any* car, that will allow you to go into it's ECU
> with a scan tool and check to see what the short term fuel trims were at
> precisely 3:04pm 4 Tuesdays ago.
>
> He and his fucktarded Clog wearing dickhead mate *both* claimed that
> engine data is continually and permanently stored and can be read at any
> time,  but despite this nonsensical shit neither of them has presented a
> single example of any vehicle that permits you to do so.
>
> This is standard fare for these mental cases. They make all kinds of
> ridiculous claims safe in the knowledge that they will never have to
> back them up with evidence :)
>

As I understand it, the long term and short term fuel trims are used
together to set the injector valve open time and so the amount of fuel
injected ie. the mixture. The LTFT is the baseline setting, and is open
loop, ie. not directly affected by any feedback. The STFT is closed
loop, ie. it responds to feedback corresponding to the current driving
conditions. The two are added in order to get the actual fuel trim sent
to the injectors. The LTFT is affected by the STLT in that it integrates
the STLT values, if the STLT is consistently positive then the value of
the LTST will increase somewhat to return the average value of the STLT
to zero and vice versa if the STLT is consistently negative. Turn the
engine off and the LTFT is retained but the STLT goes away. Historic
values are not stored.

That's as I understand it, if I'm wrong I have no doubt that I will be
corrected.

On 15/04/2023 3:45 pm, Keithr0 wrote:
> On 15/04/2023 12:17 pm, Xeno wrote:

<rambling incessant bullshit flushed>
> A PDTC can only be erased from memory if the OBD system extinguishes the
> MIL (e.g., when the current DTC changes to a History DTC). If the memory
> is not cleared with a scan tool, the ECM will need to see the related
> monitor test complete and pass on three consecutive trips. The PDTC will
> not be removed from memory until the fourth key-on cycle.
>
> Note:-
>
> If the memory is cleared with the scan tool, the MIL will be
> extinguished; the MODE $03 DTC and MODE $02 Freeze Frame Data will be
> cleared. The PDTC will still be in memory, _but it will take only one
> good trip to remove it from memory_.

This is *precisely* how they work.

There is no such thing as a "permanent" DTC in the form that Clasener is
trying to claim there is, where he is suggesting that it is a record
that lives permanently stored in the ECU and can be retrieved at any
time in the form of some "historical check". That's complete rubbish
that only someone with zero experience could ever suggest.

As far as OBDII goes, a "permanent" DTC works exactly as you explained.
As opposed to a random fault which can pull on a check engine light and
then clear itself if it goes away on it's own, a fault which exceeds a
set number of failure counts will record a DTC which the ECU classes as
"permanent" which will live in memory until such time as the DTC has
been cleared and the device goes through a minimum number of successful
cycles without error.

Once it does the fault is permanently erased and can never be retrieved
again, which makes it impossible to plug in a scan tool an
retrospectively determine a fault that has been cleared and hasn't
occurred in some time since.

Just like in the case of the Clubsport Commodore I mentioned originally,
which is why I never bothered plugging my scan tool in in the first place :)

--
--
--
Regards,
Noddy.

On 15/04/2023 4:02 pm, Keithr0 wrote:
> On 15/04/2023 8:57 am, Noddy wrote:

>> This is standard fare for these mental cases. They make all kinds of
>> ridiculous claims safe in the knowledge that they will never have to
>> back them up with evidence :)
>>
>
> As I understand it, the long term and short term fuel trims are used
> together to set the injector valve open time and so the amount of fuel
> injected ie. the mixture. The LTFT is the baseline setting, and is open
> loop, ie. not directly affected by any feedback. The STFT is closed
> loop, ie. it responds to feedback corresponding to the current driving
> conditions. The two are added in order to get the actual fuel trim sent
> to the injectors. The LTFT is affected by the STLT in that it integrates
> the STLT values, if the STLT is consistently positive then the value of
> the LTST will increase somewhat to return the average value of the STLT
> to zero and vice versa if the STLT is consistently negative. Turn the
> engine off and the LTFT is retained but the STLT goes away. Historic
> values are not stored.
>
> That's as I understand it, if I'm wrong I have no doubt that I will be
> corrected.

Near enough :)

Fuel trim values are a measure of fuel mixtures over two different
scenarios: short term is the "live" fuel mixture data showing what the
engine is doing at the precise moment you look at it, and long term is
the average over a longer period. Both of them are the measure of
voltage coming from the O2 sensor, and the output of that sensor is fed
into the ECU to calculate the pulse length of the injectors to control
the mixture.

Both work off the baseline map, with the object of the long term
readings to be as close to the baseline as possible. However due to
variables such as engine state of tune and operating conditions, it's
not always possible for an the engine to perform at it's optimum best in
terms of fuel requirements. So the ECU "learns" and makes adjustments on
the fly as necessary. These adjustments are recorded in the form of a
look-up table which the ECU uses as the benchmark which itself
constantly evolves as the engine state changes.

--
--
--
Regards,
Noddy.

On 15/4/2023 3:45 pm, Keithr0 wrote:
> On 15/04/2023 12:17 pm, Xeno wrote:
>> On 15/4/2023 8:57 am, Noddy wrote:
>>> On 13/04/2023 10:02 pm, Keithr0 wrote:
>>>> On 3/04/2023 2:38 pm, Xeno wrote:
>>>
>>> <Insane irrelevant bullshit flushed>
>>>
>>>> ^c^v
>>>
>>> And the point of reposting all of that nonsense was?
>>
>> So *you* could *read it* and *respond*. You didn't let him down either!
>>>
>>> If you want to get to the bottom of this Keith, and discover whether
>>> or not this imbecile has a clue at all, then ask him to present you
>>> with an example of a car, *any* car, that will allow you to go into
>>> it's ECU with a scan tool and check to see what the short term fuel
>>> trims were at precisely 3:04pm 4 Tuesdays ago.
>>>
>>> He and his fucktarded Clog wearing dickhead mate *both* claimed that
>>> engine data is continually and permanently stored and can be read at any
>>
>> Now you're bullshitting here. That is *not* what was said at all.
>> Please go back over the relevant thread.
>>
>>> time,  but despite this nonsensical shit neither of them has
>>> presented a single example of any vehicle that permits you to do so.
>>
>> If you have an engine misfire that is serious enough to light up the
>> MIL, then you will definitely have a *Permanent* DTC, or two, or
>> three. What you will also have is freeze frame data stored and, on
>> some vehicles, as with PDTCs, this too is stored permanently in an
>> EEPROM. If you clear the DTC, you will *still* have a PDTC visible
>> which is stored in an EEPROM and will be visible on any scanner, like
>> my Actron, that can show mode $0A data. What you will also have is
>> *other DTC codes* such as those related to O2 & HO2 sensors, typically
>> system lean P0171 & P0174 and fuel trims P0170 & P0173. These will
>> also be *Permanent* DTCs and will be retained in the OBDII system even
>> after a mode $04 clear data request so they can be accessed via a mode
>> $0A request.
>
> A PDTC can only be erased from memory if the OBD system extinguishes the
> MIL (e.g., when the current DTC changes to a History DTC). If the memory
> is not cleared with a scan tool, the ECM will need to see the related
> monitor test complete and pass on three consecutive trips. The PDTC will
> not be removed from memory until the fourth key-on cycle.
>
> Note:-
>
> If the memory is cleared with the scan tool, the MIL will be
> extinguished; the MODE $03 DTC and MODE $02 Freeze Frame Data will be
> cleared. The PDTC will still be in memory, _but it will take only one
> good trip to remove it from memory_.
>
That's what I have basically said on all my posts on this topic. You can
only erase pending and confirmed DTCs with the scantool. PDTCs can only
be erased by the module that created it.

Only the module that created the PDTCs can erase the PDTCs and only
after all relevant monitors have completed successfully. Any given
emissions DTC, whether confirmed or permanent, will likely trigger other
DTCs which, if Permanent, will likely require up to 3 and at times up to
15 completed drive cycles. You can short circuit those drive cycles by
using the factory service drive cycle instead of the generic.

It was Darren saying you could erase *all* DTCs with the scantool.
Please get it right.

--
Xeno

Nothing astonishes Noddy so much as common sense and plain dealing.
(with apologies to Ralph Waldo Emerson)

On 15/4/2023 5:20 pm, Noddy wrote:
> On 15/04/2023 3:45 pm, Keithr0 wrote:
>> On 15/04/2023 12:17 pm, Xeno wrote:
>
> <rambling incessant bullshit flushed>
>> A PDTC can only be erased from memory if the OBD system extinguishes
>> the MIL (e.g., when the current DTC changes to a History DTC). If the
>> memory is not cleared with a scan tool, the ECM will need to see the
>> related monitor test complete and pass on three consecutive trips. The
>> PDTC will not be removed from memory until the fourth key-on cycle.
>>
>> Note:-
>>
>> If the memory is cleared with the scan tool, the MIL will be
>> extinguished; the MODE $03 DTC and MODE $02 Freeze Frame Data will be
>> cleared. The PDTC will still be in memory, _but it will take only one
>> good trip to remove it from memory_.
>
> This is *precisely* how they work.
>
> There is no such thing as a "permanent" DTC in the form that Clasener is
> trying to claim there is, where he is suggesting that it is a record
> that lives permanently stored in the ECU and can be retrieved at any
> time in the form of some "historical check". That's complete rubbish
> that only someone with zero experience could ever suggest.

Only the module that created the PDTC can erase the DTC and only if the
requisite number of drive cycles are completed. As I also stated, any
serious emissions related PDTC will create *other* PDTCs. They too will
only be erased by the module that created them.
>
> As far as OBDII goes, a "permanent" DTC works exactly as you explained.
> As opposed to a random fault which can pull on a check engine light and
> then clear itself if it goes away on it's own, a fault which exceeds a
> set number of failure counts will record a DTC which the ECU classes as
> "permanent" which will live in memory until such time as the DTC has
> been cleared and the device goes through a minimum number of successful
> cycles without error.
>
> Once it does the fault is permanently erased and can never be retrieved
> again, which makes it impossible to plug in a scan tool an
> retrospectively determine a fault that has been cleared and hasn't
> occurred in some time since.
>
> Just like in the case of the Clubsport Commodore I mentioned originally,
> which is why I never bothered plugging my scan tool in in the first
> place :)
>
You always plug in the scan tool and look at the PIDs. Ok, your scantool
is crap, don't bother plugging that in.

--
Xeno

Nothing astonishes Noddy so much as common sense and plain dealing.
(with apologies to Ralph Waldo Emerson)

Noddy <me@home.com> wrote in news:u1clpg$1n6db$2@dont-email.me:

snip irrelevant

> This is standard fare for these mental cases. They make all kinds of
> ridiculous claims safe in the knowledge that they will never have to
> back them up with evidence :)

What an astounding hypocrite you are.

Where's *your* evidence of the manifold bullshit claims that you've been
challenged on Fraudster?

You're a joke Fraudster.

alvey

On 16/4/2023 9:52 am, alvey wrote:
> Noddy <me@home.com> wrote in news:u1clpg$1n6db$2@dont-email.me:
>
> snip irrelevant
>
>> This is standard fare for these mental cases. They make all kinds of
>> ridiculous claims safe in the knowledge that they will never have to
>> back them up with evidence :)
>
> What an astounding hypocrite you are.
>
> Where's *your* evidence of the manifold bullshit claims that you've been
> challenged on Fraudster?

Darren's *my little runaway!*
>
> You're a joke Fraudster.
>
The joke is getting a tad stale! ;-)
>
>
> alvey
>

--
Xeno

Nothing astonishes Noddy so much as common sense and plain dealing.
(with apologies to Ralph Waldo Emerson)