E-Class (W212) 2010 - 2016: E 350, E 550

When scan tool lied or got dumb or went blind

Thread Tools
 
Search this Thread
 
Rate Thread
 
Old 01-31-2023, 10:20 AM
  #1  
MBWorld Fanatic!
Thread Starter
 
S-Prihadi's Avatar
 
Join Date: May 2018
Location: Jakarta-Indonesia
Posts: 4,377
Received 4,420 Likes on 2,592 Posts
2014 - W212.065 - E400 ( M276.820, 3 liter Turbo) RWD not Hybrid
When scan tool lied or got dumb or went blind

Gents,

Interesting case study here : Branded scanners shows wrong information

01. I think the 3 failed scanners got the units of measure wrong by 10 fold or 1 digit extra zero.


================


02. Does engine need to run when doing full scan or engine must be OFF and only ignition key in ready to crank position aka KOEO KeyOn - EngineOff ?

AA. Depends, on the scanner used and the car I suppose and state of battery voltage of the car, when and if not assisted using battery maintainer.
It seems some trouble-code/DTC but STORED ones , meaning historical fault already not existing... can appear when engine is not running while doing full modules scan. Case to note is @juanmor40 using his naughty version of Xentry, OE tool this is.
However, I do not get such issue when doing full scan in engine OFF state 90% of the time, but I use a battery maintainer. I am also using naughty versionof Xentry
N62 parking sensors is almost always the one showing STORED DTC when and if I do get a STORED code out of nowhere when doing full scan.


BB. I am now testing the Launch Creader Elite for Benz https://mbworld.org/forums/e-class-w...onal-more.html
First I full scanned my car using Xentry. All goods no stored DTC. ENGINE OFF.
I then use the baby Launch and do automatic full scan and got below DTC's . ENGINE OFF

Ignore the red DTC of engine computer ECM. That is because I remove my alternator LIN. That will always be a CURRENT DTC. ALL MODULES SCANNING I DID USING XENTRY OR LAUNCH IS SUPPORTED BY A BATTERY MAINTAINER






I did not clear the DTCs and grab the Xentry to do full scan again. Note : Xentry always shows a lower voltage than true battery voltage is because I use extension OBD2 breakout board, that drop voltage down.

Why Xentry does not show Front SAM ( N2/10) STORED DTC B172B15 ? I shall explain later.
I will show other DTCs first










I then cleared the DTCs using Xentry and try again using Launch to do full scan.

Sure, the alternator is and will always be a CURRENT DTC, but now we can see the Front SAM (N10/1) B172B15 DTC appearing again and as STORED code

Do you know why ?
The dumb azz Launch Creader seems to not understand that I on purpose turn OFF the standing/parking ligh/DRLt whenever I do full scan. One is to reduce battery load and 2nd is to reduce run hours on my front daylight running lights.
Even when one turn off DRL at Instrument Cluster, upon ignition key in KOEO KeyOn - EngineOff position , DRL will be ON and only OFF when engine running.
So Launch seems to expect my DRL to be ON, while I use the one sided parking light feature to turn off DRL, and Launch assumed that this condition is a fault but then it realized it made a mistake ( I suppose ) and hence
produce a DTC of a STORED or historic one.

Launch being dumb is one thing, but what I can not understand here is that, DTCs are created and stored in the car module/s. Once wee see a STORED code, it will stay there until deleted, as with other DTCs
still available in Xentry as STORED DTCs from 1st time scanning using Launch.

So who made the DTC B172B15 at Front SAM ?
Can a scanner lie or get delusional and started seeing a "gremlins" like when one is high on weed or over dehydrated ?


So the point I would like to emphasize here is :
--01-- Be ready when sometimes the scanner chosen or when true battery voltage is not above 12.7V , we may get STORED codes. This may throw us OFF the diagnostic focus, becareful.
--02-- Best to use official scanner of the car brand if possible or always get familiar with a new scanner quirks.


==============================

My theory for why Launch Creader created up to 5 stored DTCs on first try which also is seen on Xentry, maybe its the way interrogation is conducted by Launch Creader which triggered those codes.
When doing full scan, you will see the scan tool doing TEST. Example my radio will be turned ON for some seconds and my parking sensors will show full warning LEDs and beeping.
instrument cluster will also shows some Christmas trees activity.

I believe all modules in the car when in KOEO KeyOn - EngineOff position is already in READY STATE.
So when a scanner does TEST to other modules one by one and overtake communication to the particular module being tested at that point in time , other modules may trigger DTC because it LOST-COM to the module under test.
If the scanner is OE like Xentry, I thinks its software is more mature and and reduce or eliminate those annoying STORED DTCs.

These modules are broadcasting on CAN BUS its state of being , some 10 times a second , some 2-3 times a second. So when say X module knows that it is to expect messages from Z module 10 times a second, but the message went dead for 1 second because our scanner is testing that Z module, module X will then assumed a LOST-COM and produce a DTC and some seconds later when scanner stop testing Z module ,
X then realized the messages from Z module is back, all is then well and DTC becomes STORED, not CURRENT.
Above is my hypothesis.

The CAN bus is a broadcast type of bus. This means that all nodes can “hear” all transmissions. There is no way to send a message to just a specific node; all nodes will invariably pick up all traffic.
The CAN hardware, however, provides local filtering so that each node may react only on the interesting messages.

https://www.kvaser.com/lesson/introduction-can-bus/


===================


I love the baby Launch, for the money this small unit is powerful, capable and FAST too.
Now I asked myself, how do modules in a car generate messages to a scanner ? How do modules "speak" or what "language" do they speak ?
I am thinking of how a text message or WhatsApp messenger we use on our phones , based on ASCII will always produce the exact same alphabet/word/term between transmitting device to another receiving device.

How come then a scanner seems to have its own term/language ?

XENTRY, the OE




The other dudes. None showed WORD for WORD exactly as Xentry. I think the data sent out by the modules is surely not ASCII ... LOL


Anyone care to put his knowledge or theory ?



==============================


Now, if a scanner either is a drunk, a liar, or a c.ock-eyed half-blind


ABOVE : Component which do not exist in Xentry



Below : Component which do not exist in LAUNCH.




Till we meet again when I have new information.........









Last edited by S-Prihadi; 01-31-2023 at 12:40 PM. Reason: add info
The following users liked this post:
CaliBenzDriver (01-31-2023)
Old 01-31-2023, 03:46 PM
  #2  
MBWorld Fanatic!
 
CaliBenzDriver's Avatar
 
Join Date: Apr 2019
Location: Silicon Valley
Posts: 5,535
Received 3,392 Likes on 2,261 Posts
MY'14 W212 M276 3.5NA @60kMi
"scam_ners" 😳

Allow me read'n digest ... i have the feeling it's going to be interesting - Thank you Surya!



Direct Select stored DTC !

It looks like you have a case of poor "Direct Select" faults all over the place.


> As for OBDII messaging :
it has to work around the world with all languages, double-bytes included.
This type of interface is usually done with token message ID's. This ties with data interface protocol of what goes over the wire.
Token numbers are written in Hexadecimal and sent in bits and bytes packets.

When a scanner is used to display any token number, it is done by using a dictionary table to translate machine tokens into device user language.

So everything a machine work with is only a collection of data + command bits until we use a scantool to display user readable equivalents.

What DiagnoseDan was facing is a software BUG. Thank you for bringing up that issue to our attention. You bet there are tons of similar untested software.

It cost resource to produce quality products.

It's a business opportunity to manage a collections of issues while extracting revenue streams.

Last edited by CaliBenzDriver; 01-31-2023 at 07:04 PM.
Old 02-01-2023, 06:50 AM
  #3  
MBWorld Fanatic!
Thread Starter
 
S-Prihadi's Avatar
 
Join Date: May 2018
Location: Jakarta-Indonesia
Posts: 4,377
Received 4,420 Likes on 2,592 Posts
2014 - W212.065 - E400 ( M276.820, 3 liter Turbo) RWD not Hybrid
Originally Posted by CaliBenzDriver
Direct Select stored DTC !

It looks like you have a case of poor "Direct Select" faults all over the place.

Ha ha ha, that is the Launch Creader being disliked at first handshake with an MB group of modules. I guess Launch was not polite during its data request .. LOL.


Dang, how could I forget that there are two kinds of CAN DBC. One is public domain OBD2 emission related thingy and one is proprietary one by car manufacturers



=========== from : https://www.kvaser.com/developer-blo...and-dbc-files/ =======

Summary

The DBC file is an ASCII based translation file used to apply identifying names, scaling, offsets, and defining information, to data transmitted within a CAN frame.
For any given CAN ID, a DBC file can identify some or all of the data within the CAN frame.
The data in a CAN frame can be broken up into eight one-byte values, sixty-four one-bit values, one sixty-four bit value, or any combination of these,
and a DBC file can be used to identify, scale, and offset the data represented by any or all of these values.
=============

It was only less than a year ago I was forced into reading this CAN DBC thingy when I tried to get the command of High Beam for my car . Forgetful man I am.
https://www.csselectronics.com/pages...sical%20values'.


Basically unless an aftermarket scanner has a good working relationship with MB, they have to sniff and work their azz off decoding those messages or perhaps steal some .....of the MB CAN DBC.


.

There is something else I was reading, it is called UDS or Unified Diagnostic Services
https://en.wikipedia.org/wiki/Unifie...ostic_Services

=======
UDS uses different operating sessions, which can be changed using the "Diagnostic Session Control". Depending on which session is active, different services are available.
On start, the control unit is by default in the "Default Session". Other sessions are defined, but are not required to be implemented depending on the type of device:
  • "Programming Session" used to upload software.
  • "Extended Diagnostic Session" used to unlock additional diagnostic functions, such as the adjustment of sensors.
  • "Safety system diagnostic session" used to test all safety-critical diagnostic functions, such as airbag tests.
In addition, there are reserved session identifiers that can be defined for vehicle manufacturers and vehicle suppliers specific use.
=========

The service "ECU reset" is used to restart the control unit (ECU). Depending on the control unit hardware and implementation, different forms of reset can be used:
  • "Hard Reset" simulates a shutdown of the power supply.
  • "key off on Reset" simulates the drain and turn on the ignition with the key.
  • "Soft Reset" allows the initialization of certain program units and their storage structures.
Again, there are reserved values that can be defined for vehicle manufacturers and vehicle suppliers specific use
============

No wonder, when I do relative compression test in Xentry, there are MUST DO steps involving ignition key ON and OFF at least twice, which is before and after the test.
I believe this is to delete the DTC which will happen when doing Compression Test, as this process will deactivate some components like injectors, ignition coils and some others probably.

I think this UDS thingy answered my question too, as to why the baby Launch shows standing/parking/DLR light error while Xentry doesn't when I had my light switch to most left side ( one sided light for parking ) during a full scan.
I guess the general wisdom of saying : do no operate anything in the car while doing full scan, comes from this facts ... technician probaly saw more errors when they operate componetns in the car while doing full scan


.


Some interesting reading from MB engineer trying to save energy used by the modules/ECU
https://past.date-conference.com/pro...LES/02.4_3.PDF

I like this part of the information :
Electronic components in modern cars, such as ECUs, and sensors and actuators, are interconnected by a complex heterogeneous communication network.
Depending on bandwidth, timing and safety requirements, CAN, LIN, MOST and FlexRay are typically used to connect ECUs.
Ethernet is only just emerging. A good overview of the different bus technologies can be found in [4], [5].

Communication in most automotive networks is dominated by a cyclic communication paradigm: the vast majority of signals are sent with a defined cycle time, even if their value has not changed compared to the last transmission.
Cycle times vary between a few milliseconds and several seconds, depending on the signal’s criticality.
Cyclic communication results in lower system complexity and increases robustness against temporary network failures or inadvertent resets of ECUs.

Missing signal reception for several cycle times is treated as an error, handled by the receiving node.


From someone's study
https://hps.vi4io.org/_media/researc...g_platform.pdf





To IT stupid me.... all these simply means :
Any scan tool doing full scan where modules are each one by one being put in diagnostic mode, will one way or the other may cause those false DTC, mainly LOST-COM type of DTC.
I think it is then the duty of the scan tool engineering team to write a program to auto delete all DTCs caused by a diagnostic event, to prevent confusion on the technician side.
The understanding of the special UDS session identifiers OE uses is another challenge for aftermarket scanner engineering team to learn.


So I guess this also qualifies as what you call as : software BUG, Cali
Old 02-01-2023, 09:41 PM
  #4  
MBWorld Fanatic!
 
Left Coast Geek's Avatar
 
Join Date: Dec 2020
Location: 122W, 37N
Posts: 2,136
Received 1,290 Likes on 882 Posts
2016 E350 4Matic wagon, 2019 Ford Expedition 4x4
CANbus messaging is all binary. unlike a computer data bus, there is no request/response, or sending a message from X to Y, there is only listening, all messages are broadcast, and have a source address, but no destination. a variety of different control units can be connected to the same CANbus, each one has an address, which is just an arbitrary 8 bit number. each message that CU sends has a code, which is another arbitrary number, and then may optionally have data, which is yet more arbitrary numbers. the definitions of all these numbers, the addresses, the message codes, and any data, are entirely implementation specific.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 


You have already rated this thread Rating: Thread Rating: 0 votes,  average.

Quick Reply: When scan tool lied or got dumb or went blind



All times are GMT -4. The time now is 08:29 PM.