Atrodo, kad daugelis gedimų, su kuriais šiais laikais susiduriu, yra susiję su komunikacija, ir šis automobilis — ne išimtis. Gerai suprasti, kaip sukurtas automobilio tinklas, darosi vis svarbiau, tačiau iš esmės viskas tiesiog susiveda į įtampą. Nepanikuokite iškart vien todėl, kad yra 30 gedimo kodų, visi rėkiantys apie komunikacijos problemas. Yra keletas paprastų ir elementarių dalykų, kuriuos galime atlikti norėdami išsiaiškinti, kas vyksta, o su PicoScope galime pasikapstyti dar giliau.
Pokalbis su klientu yra viena svarbiausių bet kurio diagnostikos darbo užduočių. Klientas turi visą informaciją apie automobilį ir gali žinoti tą vieną esminę detalę, kuri nebuvo įrašyta į darbų lapą. Šįkart nusiskundimas toks: automobilis staiga užgeso ir nebeužsivedė. Tokiu atveju gali padėti šiek tiek nuovokos — atviri klausimai leidžia iš kliento gauti daugiau informacijos. Skatinkite jį kalbėti. Paklauskite apie orą, kiek laiko važiavo, ar šis gedimas jau buvo pasikartojęs, ar neseniai buvo atlikti kokie nors darbai, ar prieš gedimą prietaisų skydelyje degė kokios nors įspėjamosios lemputės, kokiu greičiu važiavo, kokia pavara ir taip toliau. Paaiškėjo, kad svarbiausia informacija, kurią gavau iš šių klausimų, buvo ta, jog šaltas automobilis veikė gerai, tačiau pavažiavus kurį laiką jis staiga užgeso. Klientai ilgokai laukė pagalbos kelyje tarnybų, kurios, žinoma, bandė automobilį užvesti — ir štai, jis užsivedė! Tačiau pajudėjus su iš paskos važiuojančia pagalbos tarnyba, netrukus variklis vėl užgeso. Šiame etape būtų neteisinga daryti prielaidas, tačiau pagalvojau, kad galbūt susiduriame su nuo temperatūros priklausančiu gedimu.
Kitą dieną atvykus apžiūrėti automobilio jis jau buvo turėjęs pakankamai laiko atvėsti, todėl galėjome jį patikrinti tomis pačiomis sąlygomis, kokiomis vairuotojas jį naudojo prieš pat gedimą. Be to, niekada nevertėtų ignoruoti serijinės diagnostikos, jei yra galimybė ją peržiūrėti. Ji dažnai gali nukreipti į reikiamą sritį, nors ne visada turi atsakymus. Šiuo atveju turėjome 12 aktyvių gedimo kodų, iš kurių 11 pranešė apie CAN komunikacijos gedimus. Dar tiksliau — 4 iš jų tiesiogiai rodė į variklio ECU. Nors tuo metu tai dar nebuvo visiškai akivaizdu, tai padėjo nubrėžti kryptį. Turėdamas tai omenyje, nusprendžiau, kad būtina stebėti CAN linijas, einančias į variklio ECU.
Šiame etape būtina patikrinti, kaip sudarytas tinklas, nes visų tipų automobiliuose yra keli tinklai. Tai reiškia, kad dominanti ECU gali būti ne tame tinkle, prie kurio esate prisijungę, todėl visada dukart patikrinkite elektros schemą. Mums rūpėjo variklio ECU, ir pasirodė, kad ji priklauso keliems tinklams, tarp jų ir tam, kuriame yra OBD jungtis. Šis tinklas buvo tipinės sandaros — su dviem 120 Ω terminuojančiais rezistoriais, jungiančiais CAN H ir CAN L. Paprastai jie būna ECU blokuose tinklo galuose, todėl tinklo vientisumui patikrinti galima atlikti paprastą CAN tinklo varžos matavimą. Čia galėjome pasinaudoti išvadų skydeliu (breakout box), kad lengvai pasiektume kontaktus, o kartu galėjome įsitikinti, kad tinklas nebeaktyvus ir išsijungęs. Gera praktika — varžos matavimą tinkle atlikti tik tada, kai jis nebeaktyvus; paprastai atjungtumėte akumuliatorių, kad tinklas nepabustų. Šiame automobilyje atjungti akumuliatorių buvo nepraktiška dėl sumontuotos papildomos įrangos, todėl geriausia alternatyva buvo stebėti išvadų skydelio šviesos diodus, ieškant neaktyvumo. Norėdami būti visiškai tikri, galėjome ir PicoScope stebėti bei laukti, kol tinklas išsijungs, tačiau, kaip minėjau, geriausia praktika yra atjungti akumuliatorių.
Tinklui nebeveikiant greitas varžos matavimas parodė stebuklinguosius 60 Ω, kurių ir tikimės iš dviejų lygiagrečiai sujungtų 120 Ω rezistorių.
Kitas žingsnis — pabandyti pagauti gedimą veikiant. Tam pasinaudojome PicoScope gebėjimu fiksuoti duomenis laike ir tikėjomės pagauti momentą, kai gedimas pasireiškia. Pastaruoju metu daug dirbome su CAN ir netgi parengėme vaizdo įrašą su CAN diagnostikos apžvalga bei du vedamųjų testų vaizdo įrašus. Diagnostikos ir dekodavimo vaizdo įraše kalbame apie tai, kaip nustatyti osciloskopą CAN tinklo analizei, apie kai kuriuos tipinius gedimus ir kaip dekoduoti duomenis.
Šiuo atveju testų griežtai nesilaikėme, nes susidūrėme ne su tipiniu gedimu, tačiau pirmieji signalo vientisumo patikrinimo etapai išlieka. Turime naują vedamąjį testą, kaip patikrinti CAN magistralės fizinį sluoksnį:
Grįžtant prie gedimo fiksavimo — norėjome pailginti laiką, kad ekrane tilptų daugiau duomenų. Naudojau 2 ms/padalai — taip gauname daugiau bendro laiko, bet išlaikome pakankamai detalumo dekodavimui.
Jei sekėte bet kurį mūsų ankstesnį atvejo tyrimą, dažnai girdėsite mus kalbant apie matematinių kanalų naudojimą CAN diagnostikai. Pasinaudojome integruota matematika A+B ir A−B, kad geriau suprastume tinklą ir dekoduotume signalus taip pat, kaip tai daro valdikliai. Tai taip pat padėjo parodyti CAN atsparumą ir tai, kaip net esant trikdžiams pranešimai vis tiek praeidavo nepakitę. Matematinius kanalus rasite spustelėję Tools > Math Channels. Atsivers dialogo langas, kuriame galėsite pasirinkti integruotus matematinius kanalus.
Kaip matote aukščiau, priartinau tris pranešimus. CAN H yra A kanale, CAN L — B kanale, o apačioje turime vieną rezultatą, kur CAN H pridėtas prie CAN L, ir kitą, kur CAN L atimtas iš CAN H. Pastebėsite, kad CAN linijose yra šiek tiek trikdžių. Jie gana aiškiai matomi 1 pakete A+B kanale, tačiau kai atimame juos taip, kaip tai daro CAN valdiklis, buvę trikdžiai nebeegzistuoja — tai įrodo CAN atsparumą gedimams. Dar vienas dalykas, kurį pastebėjau apžiūrėjęs keletą sunkvežimių ir ne kelių transporto priemonių, yra tai, kad šie tinklai leidžia gerokai daugiau trikdžių. Paprastai lengvuosiuose automobiliuose, sudėję CAN H su CAN L, gauname labai tiesią liniją ties 5 V (2,5 V + 2,5 V = 5 ir 3,5 V + 1,5 V = 5 V). Sunkvežimiuose visada atrodo esant leistiną nuokrypį nuo 5 V. Jis niekada nebūna didelis, bet gali siekti iki 0,4 V. Tačiau kai pažvelgiame į fizinį sluoksnį, A−B, viskas labai tolygu ir leidžia naudoti integruotą serijinio dekodavimo įrankį. Dažnai gauname klausimą, kas yra tos smailės kiekvieno baito gale ir ar dėl jų reikėtų nerimauti. Šios smailės, arba skambėjimas (ringing), gali kilti dėl daugelio veiksnių, tačiau dažniausiai jas lemia matavimo laidų ribotumas. Norint jų atsikratyti, patartina naudoti 60 MHz osciloskopo zondą, kuris duos gerokai švaresnį signalą. Peržiūrėkite šį forumo įrašą, kuriame išsamiau aprašomi skirtumai tarp šių dviejų laidų. Vis dėlto, jei žinome apribojimus ir mums priimtina tai, ką matome, galime tęsti testavimą.
Įšildę sunkvežimį iki darbinės temperatūros pradedame justi gedimą: pasireiškia nedidelis strigimas, o tada variklis staiga sustoja. Būtent taip, kaip aprašė klientas. Palikę osciloskopą fiksuoti duomenis ir po įvykio, turėjome duomenų tiek prieš, tiek po jo.
Pamatėme visišką tinklo tylą dviejuose buferiuose, kurie kartu sudarė 40 ms, o tada — vienas paketas ir vėl tyla. Pastebėjome, kad tinkle buvo gerokai mažiau CAN srauto. Kas toliau?
Na, argi nebūtų puiku, jei galėtume nustatyti, ką iš tiesų reiškia tie duomenų paketai, arba pasakyti, kurios ECU yra prisijungusios, o kurios ne? Steve Smith yra pateikęs daugiau medžiagos šioje forumo temoje, kurioje jis naudoja įvairius metodus, padedančius iššifruoti tinklą ir nustatyti, kuri ECU yra kuri. Tame įraše yra labai daug informacijos, bet ką, jei galėtume tai dar labiau supaprastinti? Sunkvežimiuose ir ne kelių mašinose ECU atpažinimo užduotis paprastesnė, nes jose dažnai naudojamas J1939 protokolas. Jis gerokai labiau standartizuotas nei tipinis lengvojo automobilio tinklas, bet vis tiek nėra visai paprasta, o gamintojai kai kuriuos valdiklius pateikia savaip.
Pirmiausia turėjome atlikti fizinio sluoksnio serijinį dekodavimą, kad pradėtume atpažinti pavienius ID. Tam spustelėkite Tools > Serial Decode. Dabar turėsite galimybę sukurti dekoderį spustelėję Create ir iš sąrašo pasirinkę CAN. Atsivers nustatymų langas, kuriame būsite paprašyti pasirinkti, kokius duomenis dekoduosite. Mūsų atveju naudosime A−B, kuris bus išskleidžiamajame sąraše. Jame rodomi tik tie kanalai, kurie aktyvūs tinklelyje, todėl jei kuris nors buvo paslėptas, jo pasirinkti negalėsite. Kita parinktis — pasirinkti slenkstį. Tai įtampa, kurią nurodote programinei įrangai naudoti kaip dekoderio „kirtimo tašką“. Per mūsų klausimų ir atsakymų sesiją buvo užduotas klausimas apie CAN įtampos slenksčius ECU gedimų aptikimui. Sąžiningas atsakymas — nežinome, bet aktyviai dirbame, kad rastume atsakymą. Prašome sekti forumą, kur bus skelbiami būsimi atnaujinimai ir CAN tyrimai. Šiam testui taikėme 1 V kirtimo tašką. Histerezę galima sumažinti net iki 20 mV, nes mūsų matematiniame kanale turėtume matyti tiesias kylančias ir krintančias linijas. Puikų histerezės ir jos poveikio kirtimo taškams paaiškinimą rasite mūsų naudotojo vadovo 157 puslapyje. Duomenų perdavimo sparta (Baud rate) kartais gali būti mįslė, tačiau yra labai paprastas būdas ją nustatyti naudojant PicoScope laiko liniuotes. Naudodami rėmelio priartinimą apibrėžkite duomenų paketą. Tada laiko liniuotėmis pažymėkite abi mažiausio bito puses. Apatiniame dešiniajame kampe pamatysite reikšmę kHz. Ji ir atitiks jūsų duomenų perdavimo spartą.
Atlikus nustatymus mūsų CAN dekodavimo konfigūracija turėtų atrodyti maždaug taip:
Dabar mums bus pateikta lentelė, kurioje esamo buferio duomenų paketai konvertuoti į HEX kodą. Sąmoningai pasirinkau pradėti nuo to buferio, kuris buvo prieš pat pirmąjį „tylųjį“ buferį (be CAN srauto), nes ten gedimo dar nebuvo. Turiu 10 duomenų paketų, kurie visi dekoduojami teisingai, be klaidų.
Anksčiau minėjau, kad J1939 yra gerokai labiau standartizuotas nei J2534. Tai reiškia, kad šiuos duomenis galime išnarstyti ir pradėti atpažinti ID. Sukūrę susiejimo (link) failą galime paversti ID tikrais žodžiais. Iš serijinių duomenų matėme, kad nemažai ECU praneša apie variklio ECM problemą, todėl būtų logiška dekodavimo lentelėje ieškoti variklio ECM ID. Pirmiausia reikėjo nustatyti, kuris ID yra variklio ECM.
Į detales čia per daug nesigilinsiu, tačiau noriu parodyti galimybes, kurias PicoScope suteikia serijinio dekodavimo srityje. Vis dėlto turime prisiminti, kad PicoScope nėra specializuotas CAN dekoderis / registratorius, o osciloskopas su ribotomis dekodavimo / registravimo funkcijomis. Nepaisant to, nuveikti galima labai daug. Pirmiausia reikia suprasti, kaip sudarytas J1939 pranešimo ID. Pranešimo antraštę sudaro 29 bitai, tačiau paprastumo dėlei pranešimą nagrinėsime HEX formatu. Kiekvienas pranešimas turi unikalų parametrų grupės numerį PGN (Parameter Group Number), kuriame yra įtariamojo parametro numeris SPN (Suspect Parameter Number). Šiame etape mums rūpi tik PGN, nes jis nurodo grupės lentelę, susietą su ECU. PGN antraštėje randame pažvelgę į du vidurinius ID baitus, pavyzdžiui — 0C F0 04 00, o tai reiškia, kad mums rūpi tik F0 04. Dabar F004 konvertuojame į dešimtainį skaičių ir, pasinaudoję programuotojo skaičiuotuvu, gauname skaičių 61444. Greita paieška SAE standartuose pagal PGN 61444 patvirtina, kad tai yra Electronic Engine Controller 1. Todėl galime drąsiai teigti, kad 0C F0 04 00 atitiko variklio ECU, arba EEC1.
Kad tai pritaikytume savo dekodavimo lentelėje, šią informaciją turime įrašyti į susiejimo failą ir jį išsaugoti. Norėdami gauti šį failą, dekodavimo lentelėje spustelėkite kortelę Link. Pamatysite parinktį Create File. Ją spustelėjus bus paprašyta išsaugoti CSV failą. Pasirinkite tinkamą vietą, tada suraskite ir atidarykite išsaugotą CSV failą. Atidarę failą pamatysite keletą laukų, panašių į PicoScope dekodavimo lentelę, tik su papildoma ID aprašymo antrašte. Nukopijuokite ID iš PicoScope lygiai taip, kaip jis yra dekodavimo lentelėje, ir ID aprašymo stulpelyje įrašykite aprašymą. Mums tai buvo Engine Controller 1. Būtinai išsaugokite pakeitimus.
Kad nurodytumėte PicoScope naudoti šį susiejimo failą ir pakeisti ID mūsų susiejimo faile nurodytais aprašymais, spustelėkite Link > Open, nueikite į susiejimo failo vietą ir jį pasirinkite. Pasirinkus turėtumėte matyti ID, pakeistus mums suprantama kalba.
Kaip pasisekė, tai ir buvo ta variklio ECU, kurios ieškojome. Dabar galėjome peržiūrėti duomenis ir ieškoti šio ID bei su juo susijusių gedimų. Dekoderį išplėtėme visiems buferiams, išskleidžiamajame sąraše, kuriame buvo pasirinktas esamas buferis, pasirinkę All Buffers. Dabar galėjome visus šiuos duomenis eksportuoti į Excel tolesnei analizei arba pasinaudoti dekodavimo lentelės filtro parinktimi. Pasirinkite Filter ir įveskite ID, kurį norite matyti; mums tai buvo Engine Controller 1.
Žinojome, kad gedimas įvyko ties 96 buferiu, todėl nuo jo ir pradėjome paiešką. Pastebėjome, kad po 96 buferio Engine Controller 1 nebebuvo matomas ir, atrodo, buvo atsijungęs, nors ankstesniuose įrašo buferiuose šis ID buvo labai aktyvus. Ar tai galėtų reikšti, kad kalta variklio ECU? Tai būtų logiška, ir mes tikrai turėjome įrodymų savo neapdorotuose CAN duomenyse. Matėme, kad po 96 buferio kažkas įvyko, tinklas nutilo, ir nuo tada variklio ECU nebebuvo prisijungusi. Tai davė pakankamai pagrindo išsiųsti ECU patikrinti, ir iš tiesų buvo patvirtinta, kad ji sugedusi. Buvo sumontuota nauja variklio ECU, ji užkoduota ir perprogramuota, o automobilis grįžo į kelią.
Tai buvo intriguojantis atvejis, kuris, neteisingai nustačius diagnozę, būtų brangiai kainavęs ir savininkui, ir mums, tačiau PicoScope dėka turėjome pakankamai įrodymų pagrįsti pasirinktą remonto kelią. Kaip minėta anksčiau, PicoScope nėra specializuotas CAN dekoderis / registratorius. Tai osciloskopas su ribotomis dekodavimo / registravimo funkcijomis, tačiau naudodami išplėstines programinės įrangos funkcijas galime atrasti gerokai daugiau. Tikiuosi, matote, kad galimybes riboja tik jūsų vaizduotė — na, ir, žinoma, laikas!
Straipsnis išverstas iš Pico Technology bibliotekos su gamintojo leidimu. Originalas: picoauto.com. PicoScope įrangą rasite mūsų kataloge.