EVC dtc reading #405
Comments
|
But the ECU LINSCH really does not exist!
The easiest ECU to query is the CLUSTER. If you have CLUSTER running, your
code base is fine.
I hope I didn't misunderstood the problem.
|
|
Code base is fine, I can retrieve CLUSTER DTC's When I ask for EVC DTC's, ELM returns NO DATA Any idea ? |
|
Ah OK, got it. I think the problem is that you compute the code to send (1902ff), instead of taking it from the definitions (19023b). |
|
Ok, i see. How does it work on android CanZE project. RequestIsoTPFrame computes requestID and will also return 1902ff for 5902ff responseID ? so requesting EVC DTC with android CanZE will return same error, right ? I have to add requestID in field class and replace the frame.getrequestId by field.getrequestID in requestIsoTpFrame ? |
|
In the Android code the field is found by responseID (5902ff). There is no specific reason why, but that is littered all over the code base ;-) When sending an IsoTp command, we find the field, then get (instead of compute) the requestID (as initialized by the Fields), so in this case (19023b). So yes, I think what you propose is the safe way to do it, as there will be more ECU classes added soon. |
|
but, if I look at the code, ELM327.RequestISOTPFrame() // 022104 ISO-TP single frame - length 2 - payload 2104, which means PID 21 (??), id 04 (see first tab). and Frame.getRequestId() public String getRequestId () { The code changed, now Frames are requested instead of Fields .... |
|
Class ELM327, it uses getRequestId(), which is initialized using load()
(note that this code assumes requests are always FIRST frames and thus are never longer than 7 bytes. This is a little bit of a shortcut ;-) ) On the application level, fields are requested. This results in getting the corresponding frame and triggering all the embedded fields with new values. It is slightly more complicated for the diagnostic frames, as the same frame can be used for many different queries. However (example: module temperatures), she same is still true: the application asks for one field, the entire frame is requested and all embedded fields (some just one, but some contain many, many fields) are triggered. The only difference is that at initialisation of the Frame instances, subframes are created for each diagnostic command. At the end of the day, a device driver only knows what a frame is. It has no clue about fields at all. |
|
Sorry, but I read the whole code and i stil don't understand. I will have a look tomorrow if i can. Thanks for your help. |
|
After some private emails back and forth we have established it has nothing to do with the code, but some misinterpretation on my end. I had assumed the "give me all DTC" command was the same for all ECUs and this is not the case. I now have reasonable documentation on the proper command per ECU but I want to be reasonably sure the response format is the same too. Assuming (for the moment) that this is true, only an update to the Fields class initialization strings is required. |
|
Cool, great news !
If possible, would you agree to skate tout documentation ?
Frédéric RICHARD
… Le 10 févr. 2017 à 11:09, yoh-there ***@***.***> a écrit :
After some private emails back and forth we have established it has nothing to do with the code, but some misinterpretation on my end. I had assumed the "give me all DTC" command was the same for all ECUs and this is not the case. I now have reasonable documentation on the proper command per ECU but I want to be reasonably sure the response format is the same too.
Assuming (for the moment) that this is true, only an update to the Fields class initialization strings is required.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
No problem. |
|
Example for the EVC Command: 1902AF Response on my car: (Line breaks by me). Meaning 1525 - f3- 68 -> Cruise Control/Speed Limiter Deactivation, Multiple Failure, DTCStatus.testNotCompletedThisMonitoringCycle + DTCStatus.testFailedSinceLastClear + DTCStatus.confirmedDTC 0601 - 92- 68 -> Electric Motor Prestation, performance or incorrect operation, DTCStatus.testNotCompletedThisMonitoringCycle + DTCStatus.testFailedSinceLastClear + DTCStatus.confirmedDTC After a quick change in the code (needs fixing up, so uncommitted) |
|
@fesch @FredLeudon Given that the command to inquire the DTCs is not the same for every ECU, and that it is even possible for an ECU to have more than one command (I assume for the moment this is due to possible sub-systems in an ECU, an example is the BCB / JB2), I will make a change to the Ecu / Ecus classes to include a list of commands to inquire it's DTCs, and of course change the DtcActivity accordingly. |
|
Ok, let me know on witch branch You do that et n github please.
I will report changes in ios code.
Thanks
Frédéric RICHARD
… Le 11 févr. 2017 à 12:06, yoh-there ***@***.***> a écrit :
@fesch @FredLeudon Given that the command to inquire the DTCs is not the same for every ECU, and that it is even possible for an ECU to have more than one command (I assume for the moment this is due to possible sub-systems in an ECU, an example is the BCB / JB2), I will make a change to the Ecu / Ecus classes to include a list of commands to inquire it's DTCs, and of course change the DtcActivity accordingly.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Done in "development". Also added TCU. |
|
Sorry to reopen but I still have trouble to retrieve DTCs When trying to get EVC DTCs there is what I do :
Please, say if I'm right with this sequence ? |
|
other question : in EcuDiagEVC class, at the end of load function, I think there is an error Frames.getInstance().load("7EC,0,0,EVC\n"); |
That is a dumb mistake! Thanks
It SHOULD be right. I will try again this weekend. Tell me, do you have a Q210 or an R240? |
|
i have a Q210 - 03/2013 |
|
I can confirm issuing a "get DTCs"command (1902AF) not only gives no
answer, but in my case knocks off the dongle too and I need to reinitialize
it. This was through my gateway though, not sure if that secondary problem
is in the gateway. I can also confirm the command is correct according to
the documentation.
I will have a look into the CLIP "sniffer" logs to see what I can find.
|
|
Thanks for feed-back. |
|
CLIP tool seems to send 19023b. I cannot test right now, but I will later
today. BTW, this is NOT what the documentation says.
|
|
I will test it tomorrow early too. There are (I think) same issues with others ECU. I had to change the code for reading dtc's |
|
Correct, as the BCB is "2 in 1". The definition files came in two also: one
is called BCB, the other JB2 (Junction box). EVC is one though, as far as I
can tell.
|
|
I have a little request : Could you explain dtc flags as they are given by CanZE ? Thanks |
|
Of course. The flags are located in the fourth byte of the sequence. You
can find is coded in the Dtcs class
https://github.com/fesch/CanZE/blob/master/app/src/main/java/lu/fisch/canze/actors/Dtcs.java
and here is a good description
http://raviprashanthsn-technical.blogspot.nl/2013/10/fault-code-status-bits-in-automotive.html
if ((flags & 0x01) != 0) result += ", tstFail";
if ((flags & 0x02) != 0) result += ", tstFailThisOp";
if ((flags & 0x04) != 0) result += ", pendingDtc";
if ((flags & 0x08) != 0) result += ", confirmedDtc";
if ((flags & 0x10) != 0) result += ", noCplSinceClear";
if ((flags & 0x20) != 0) result += ", faildSinceClear";
if ((flags & 0x40) != 0) result += ", tstNtCpl";
if ((flags & 0x80) != 0) result += ", wrnLght";
*Bit0* => This Bit is “testFailed”. This bit provides the information about
the fault (Error) is still active (injected) or not. If Fault is still
injected or Active, then the value is 1 otherwise the value is
0. Ex: Fault “Short Circuit” is still active.
*Bit1* => This Bit is “testFailedThisOperationCycle”. This bit indicates
whether the fault is occurred anytime during the current operation cycle.
If Fault has occurred in the current operation cycle, then the value is 1
otherwise the value is 0.
*Bit2* => This Bit is “pendingDTC”. This bit indicates whether the fault
is occurred anytime during the current operation cycle. The only difference
between “testFailedThisOperationCycle” and “pendingDTC” is
“testFailedThisOperationCycle” is cleared at the end of current operation
cycle (least bothering whether the fault is still active or inactive) and
“pendingDTC” is cleared only when in next operation cycle the monitor
routine is run and the result shows pass(fault is not present). So if Fault
is still injected or Active in the current operation cycle, then the value
is 1 otherwise if the Fault was active in previous operation cycle and is
inactive (i.e monitor routine is run and fault is inactive) in the current
operation cycle, then the value is 0.
*Bit3* => This Bit is “confirmedDTC”. This bit informs that fault is
continuously active for specific monitor routines and is matured enough in
the current operation cycle so that it can be said Confirmed. If fault is
active and matured, then the value is 1 otherwise the value is 0.
*Bit4 * => This Bit is “testNotCompletedSinceLastClear”. This bit informs
that monitor routine is not run in the current operation cycle(once after
Clearing the DTC is done). The reason for not running in the current
operation cycle can be because particular pin is inactive in the operation
cycle(Ex: Parked or hibernate vehicle mode). If the monitor routine is not
completed this operation cycle, then the value is 1 otherwise the value is
0.
*Bit5* => This Bit is “testFailedSinceLastClear”. This bit informs monitor
routine has reported that test has failed (at least once Bit0 is set) in
any operation cycle at least once after clearing the DTC action is
performed. If the fault has occurred after clear DTC is performed, then the
value is 1 otherwise the value is 0.
*Bit6* => This Bit is “testNotCompletedThisOperationCycle”. This bit
informs that the monitor routine is still not run during this current
operation cycle. This is because the pin is not active for this operation
cycle or when the request is sent from the tester, the monitor routine is
not run. If the monitor routine is not run this operation cycle, then the
value is 1 otherwise the value is 0.
*Bit7* => This Bit is “warningIndicatorRequested”. This bit is used to
bring into the attention of the user or driver when the fault occurs. If
fault occurs and any monitor is required for specific fault, then the value
is 1 otherwise the value is 0.
|
|
Thanks a lot ! |
|
hi, I tried 0319023b and still receiving NO DATA response. 07/03/2017 06:31:47,70 [] cDtcActivity doQueryECU(ecu[Electric Vehicle Controller-EVC-(renault ID:946)] |
|
Yeah. Bummer. I will experiment a bit with what CLIP did, trying to emulate
it. Interesting how we moved from problematic BCB to EVC ;-)
|
|
This will help. I will experiment with the "Extended diag" command
|
|
If some ECU needs extended diag command, perhaps will it be a good idea to add then on ECU/ECUS class ? |
|
Absolutely!!!
The EVC is still resisting me though ;-) But I will break it, Moo haa haa!!
|
|
I'm trying this morning ... Result = !Moo haa haa!! 08/03/2017 10:33:27,75 [] Test : EVC DTC reading |
|
Same results here. Very frustrating!
|
|
Hi, If possible, could You send me a full (from beginning to complete) Clip diagnostic reverse log by mail, I would like to reproduce EVC query by clip. Thanks |
|
There you go Fred
…On Sat, Mar 25, 2017 at 1:38 PM, FredLeudon ***@***.***> wrote:
Hi,
If possible, could You send me a full (from beginning to complete) Clip
diagnostic reverse log by mail, I would like to reproduce EVC query by clip.
Perhaps is there a command sequence we didn't see.
My mail is ioscanze[at]icloud[dot]com
Thanks
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#405 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AEv71ru8NSYM2Q1SOyjU0whCUNJz-NITks5rpQqxgaJpZM4LpQcj>
.
--
Please use Signal to reach me on secure IM and VoIP http://sgnl.link/1KpeYmF
|
|
I would like to reproduce such document. |
|
I am closing this issue due to lack of activity. |
Hi,
I have a problen when I try to read DTCs from EVC.
Below the result of ios CanZE logs (first, trying to read DTC from EVC and second successful read TCU DTCs)
I get a NO DATA or CAN ERROR each time.
20/01/2017 12:05:51,00 Device RealField Value[] ->
20/01/2017 12:06:28,46 CanZE DTCActivity
20/01/2017 12:06:28,91 DTCActivity Constructeur() Stopping poller thread
20/01/2017 12:06:29,17 Device Annulation tache parallèle
20/01/2017 12:07:09,22 ELM327 : initDevice (1)
20/01/2017 12:07:10,09 Device ELM[ELM327 v1.5]
20/01/2017 12:07:11,29 cDevice requestFrame[7ec.5902ff]
20/01/2017 12:07:11,30 ELM327 requestIsoTpFrame : [7e4]
20/01/2017 12:07:11,76 socketManager frame[7ec] sendCommand command[031902ff] timeout(ms)[750] addReturn[oui] stopCar[>]
hexdata[NO DATA>]
queryTime[+000000000000023]
timeout[non]
stop[oui]
20/01/2017 12:07:11,76 cDevice requestIsoTpFrame() -> QueryTime[00:00:465]
20/01/2017 12:07:11,76 Device: request for 7ec.5902ff returned error -E-data empty
20/01/2017 12:07:25,98 Frames Ecu does not exist:LINSCH
20/01/2017 12:07:26,76 ELM327 : initDevice (1)
20/01/2017 12:07:27,76 Device ELM[ELM327 v1.5]
20/01/2017 12:07:29,10 cDevice requestFrame[7da.5902ff]
20/01/2017 12:07:29,11 ELM327 requestIsoTpFrame : [7ca]
20/01/2017 12:07:30,03 socketManager frame[7da] sendCommand command[031902ff] timeout(ms)[750] addReturn[oui] stopCar[>]
hexdata[10AB590239AEF0162110AEF04910AEF0224A10AEF04B10AE23302910AE22291024AE232910AE24622510AE124910AE10264910932411109327241310AE21121028933B1210933B112910930D1210930D2A1110930D1310AE2B311210AE3111102CAE3113109305122D109305111093052E131093281210932F2811109328131020AE839410AE13062110AE322910AE34222910AE917310AE23927310AE33961024AE81491093D98F252893021210930226111093021310AE27064910AE04491028AE01F028505050>]
queryTime[+000000000000065]
timeout[non]
stop[oui]
20/01/2017 12:07:30,05 cDevice requestIsoTpFrame() -> QueryTime[00:00:937]
20/01/2017 12:07:33,34 DTCActivity Destructeur() Re-Starting poller thread
20/01/2017 12:07:37,17 Frames Ecu does not exist:LINSCH
20/01/2017 12:07:37,75 Device Lancement de la tâche parallèle
The text was updated successfully, but these errors were encountered: