Ir vėl stoviu purvinoje statybvietėje. Šįkart apžiūriu mašiną, kurioje užfiksuota nemažai įspėjamųjų gedimų. Operatorius nebegalėjo padidinti variklio sūkių, kad mašiną nuvarytų iš objekto. Kaip esu minėjęs ankstesnėse studijose, dirbti su statybine technika yra iššūkis: informacijos trūksta, o grandinių tarp variklio ir hidraulikos konfigūracijų yra be galo daug. Beveik niekada iš anksto nežinai, su kuo teks susidurti. Kadangi universalių diagnostikos skaitytuvų rinka šiame sektoriuje yra artima nuliui, pamatęs krūvą įspėjamųjų lempučių ekrane gali griebtis telefono ir kviesti gamintojo atstovą. Vis dėlto, turėdami osciloskopą, prieš tokį skambutį galime bent jau susidaryti vaizdą, kas vyksta.
Kai kurie statybinės technikos gamintojai iš tiesų stengiasi padėti su borto diagnostika — jeigu paspausite reikiamus mygtukus, ji parodo, kas vyksta „už scenos". Būtent taip buvo ir su šia mašina: laimei, operatoriaus vadove radome serviso meniu ir iš jo gavome papildomos informacijos. Šiame meniu buvo skiltis, leidusi peržiūrėti tai, kas atrodė kaip serijiniai duomenys. Tai puiku, nes, jei tik nereikia programavimo galimybių, diagnostiką galėjome tęsti be atstovybės įrangos.
Turėjome gedimą — nevaldomus variklio sūkius, todėl logiška sutelkti dėmesį į siekiamus ir faktinius variklio sūkius. Nustebome pamatę, kad abi reikšmės tuščios! Be to, kai kuri informacija, pavyzdžiui, alyvos ir aušinimo skysčio temperatūra, buvo rodoma — vadinasi, ekranas „matė" dalį su varikliu susijusių komponentų. Dar viena maloni šio serviso ekrano savybė — galimybė matyti siurblio slėgį, nes hidraulinėje sistemoje buvo įrengtas jutiklis. Tačiau ir ši reikšmė buvo tuščia.
Žinojome, kad variklis užsiveda ir dirba, tad teoriškai alkūninio veleno signalas turėtų būti geras, nes tai „common rail" dyzelinis variklis. Vis dėlto niekada nieko nelaikau savaime suprantamu, tad nusprendžiau, kad verta tuo įsitikinti — o kartu ir progą pasiimti skirstomojo bei alkūninio velenų atskaitos signalus ateities darbams. Prieiti prie statybinės technikos komponentų nėra pats maloniausias užsiėmimas. Dauguma jų užkasti už apsauginių skydų, skirtų neįleisti purvo ten, kur jo neturi būti. Tačiau tai reiškia ir kitką: tai, kas vis dėlto pateko vidun, nebeišeina, todėl lieka riebaluota, dulkėta aplinka, pasiruošusi aptepti jus ir viską, kas priartės.
Alkūninio veleno jutiklis
Skirstomojo veleno jutiklis
1-o purkštuko srovė
Pastebėsite, kad į matavimą įtraukiau ir skirstomąjį veleną bei 1-ą purkštuką — grynai ateičiai, nes prie jų buvo lengva prieiti iš variklio viršaus. Logiška: jei jau imate alkūninio veleno jutiklio signalą, verta pridėti ir skirstomąjį veleną bei galimą sinchronizacijos signalą. Jei variklio veikime gedimų nėra, turėsite žinomai gerą atskaitos signalą būsimiems atvejams. Įkėlus į signalų formų biblioteką (waveform library), jūsų signalų formos taip pat saugomos Pico serveriuose, taigi jų niekada nepamesite. Daugiau informacijos apie signalų formų biblioteką rasite mūsų svetainėje – https://www.picoauto.com/library/waveform-library arba mūsų YouTube vaizdo įraše – https://youtu.be/8ePHLmRI5YY
Įsitikinę, kad variklis pateikia teisingus signalus, dėmesį nukreipėme į mašinos komunikacijos pusę. Kažkokiu būdu variklio ECU perduoda variklio sūkius į informacinį ekraną kabinoje, o mes žinome, kad jis nerodo nei siekiamų, nei faktinių sūkių. Kaip ši informacija patenka į ekraną? Atsakymas — CAN, ir elektros schemos poreikis tapo būtinybe. Nemažai tokių mašinų vadovą galima rasti internete. Susidūrus su tokio tipo problemomis, jie gyvybiškai svarbūs.
Būtent taip, kaip ir maniau. Kartais pastebiu, kad perbraižius tik tą grandinės dalį, kuri jus domina, lengviau susitelkti į tai, ką norite išmatuoti. Mus domino tik CAN tinklas ir variklio sūkių rankenėlė, naudojama sūkiams didinti ir mažinti.
Aukščiau — perbraižyta elektros schema, sudaryta iš originalios schemos, paliekant tik šiuo metu mus dominančias dalis. Kaip matote, sūkių keitimo užklausa iš greičio valdymo rankenėlės keliauja ir į informacinį ekraną (INF), ir į mašinos valdymo ECU (MCU). Tačiau pranešimas apie variklio sūkių didinimą eina per CAN — greičiausiai iš MCU į ECM, o papildoma informacija ir duomenys siunčiami į INF ekraną. Tai paaiškintų, kodėl dalis variklio duomenų vis dar buvo rodoma — jie buvo dalijami tinkle.
Turėti teoriją ir ją įrodyti — du visiškai skirtingi dalykai. Žinant, kad variklio sūkių signalai siunčiami per CAN tinklą, verta į tą tinklą pažvelgti. Ryšiui tarp ECU stebėti naudojau PicoScope. Niekas nemėgsta nurašinėti ECU, tad kuo daugiau įrodymų surinksime, tuo geriau. Galbūt tinklas parodys ką nors kita. Prieiti prie CAN laidų daugumoje automobilių su OBD jungtimi gana paprasta, tačiau su statybine technika ne taip lengva. Mums pavyko rasti reikiamus laidus ir stebėti tinklą. Tai, ką pamatėme, buvo labai įdomu.
CAN High
CAN Low
A+B matematikos kanalas
A-B matematikos kanalas
Naudodami matematikos kanalus CAN gedimams tirti, matome, kad ties tam tikrais duomenų paketais A+B kanale vyksta kažkas keisto. Pažvelgus į duomenis dešinėje buferio pusėje, matome tris paketus, po kurių eina dar keturi. Pirmieji trys, duomenims persiunčiant, turi nedidelį trikdį, tačiau vis tiek telpa į tuos 5 V, kurių tikėtumėmės. O paskutiniai keturi, atrodo, visi patraukti aukštyn. Priartinus ir palyginus abu, paaiškėjo dar daugiau.
1-ame osciloskopo vaizde matome vieną iš pirmųjų trijų paketų, o 2-ame — paketą iš paskutinės paketų grupės. Skirtumas akivaizdus. Sudėjus kanalus, 2-o vaizdo duomenys turi tam tikrą iškraipymą ir atrodo labai netvarkingi, palyginti su 1-o vaizdo duomenimis. Su A-B vis dar matome, kad nepaisant įtampos nesklandumų, paketas aiškiai yra ir bus puikiai dekoduotas. Ką čia galbūt pastebėsite — įtampų skirtumą žiūrint A-B. Šiuo metu tai gali nieko nereikšti, ir be žinomai geros atskaitos esame kiek tamsoje, tačiau tai gali būti nulemta ECU elektrinio „parašo". Daugiau apie tai rasite šioje forumo temoje: https://www.picoauto.com/support/topic21680.html#p98339
Nežinodami, ar taip ir turi būti, nusprendėme atidaryti valdymo rankeną ir patikrinti greičio valdymo rankenėlę. Paprastas 3 laidų įtaisas su 5 V maitinimu, mase ir signalo išėjimu. Logiška: jei jis nebesiunčia signalo į MCU, nebus ir užklausos keisti variklio sūkius.
Greita patikra įjungus degimą turėtų parodyti, kad MCU tiekia rankenėlei 5 V. Neturėjome nieko. Būtų buvę malonu atlikti varžos matavimą — manau, būčiau galėjęs išlituoti kontaktus, tačiau, kaip įprasta, laikas spaudė. Tai galėjo būti dar vienas testas, atliktinas pagal kito bandymo rezultatus.
Matydami, kad šios 5 V maitinimo nėra, ir grįžę prie elektros schemos supratome, kad 5 V naudojo ne tik greičio valdymo rankenėlė. Sekdami laidus pamatėme, kad ta pati linija maitino ir hidraulinio siurblio slėgio jutiklį, kurio reikšmė prietaisų skydelyje buvo tuščia. Gal čia ir slypi problema? Ar būtent 5 V trūkumas neleidžia valdyti sūkių?
Kitas žingsnis — rasti MCU valdiklį; po ilgų paieškų aptikome jį už skydo virš akumuliatorių, prisuktą prie variklio ECU.
Įsitikinome, kad MCU maitinimas ir masė yra tvarkingi, ir galėjome patvirtinti, kad 5 V variklio sūkių valdymo rankenėlei nėra. Atėjo akimirka, kurios visi bijome — teko užsakyti naują MCU.
Naujo MCU sumontavimas buvo paprastas „prijunk ir naudok" veiksmas ir mašinos gedimą tikrai pašalino. Pradžioje trūkusi 5 V atskaita atsirado, o informaciniame ekrane buvę gedimo kodai išnyko. Tai reiškė ir tai, kad mašinos sūkius vėl buvo galima keisti skydelio greičio rankenėle.
O kaip dėl mūsų atlikto tinklo matavimo? Dabar žinome, kad mašina yra žinomai gera, tad žinomai gerų duomenų surinkimas visada padės sprendžiant būsimas mįsles.
Štai matavimas iš tos pačios vietos kaip anksčiau, tik ekrane šiek tiek daugiau laiko. Diskretizavimo dažnį palikau gana aukštą, kad paketai būtų aiškesni. Iškart matyti, kad CAN H + CAN L atrodo labai panašiai — paketai tolsta nuo 5 V linijos, kurios paprastai ieškotume. Vis dėlto matome, kad pritaikius A-B turime teisingai dekoduojamus duomenis. Tačiau pastebėjau, kad dabar tinkle daug daugiau srauto. Padaliję ekraną per pusę, gauname iš viso 50 ms — tiek pat, kiek pirminiame matavime, ir aiškiai matome, kad duomenų yra daugiau.
Kaip minėjau anksčiau, nurodžiau forumo įrašą apie ECU elektrinį „parašą". Cituoju: „Dominuojančios įtampos (CAN Hi 3,5 V ir CAN Lo 1,5 V), esančios magistralėje perduodant pranešimą / naudingąją apkrovą, bus unikalios pranešimą siunčiančiam CAN valdikliui dėl gamintojo tolerancijų ECU viduje, jungčių, skirtingų komponentų ir jo fizinės padėties magistralėje." Šis unikalus ECU parašas statybinėje technikoje bus dar ryškesnis, nes mašinos kūrime dalyvauja įvairūs gamintojai. Variklio ECU gali būti Mercedes, Isuzu arba Doosan. Informacinis ekranas — bet kurio gamintojo, o mašinos ECU — tų, kurie visa tai surenka į vieną. Esant tokiam kintamųjų kiekiui, komunikacijos tinklams turime taikyti didesnę toleranciją ir susitaikyti su CAN įtampų skirtumais. Būtent čia žinomai gera signalo forma gali sustabdyti jus nuo klaidingo kelio. Patartina, patvirtinus savo „sprendimą", jį išsaugoti ateičiai arba įrašyti ir bendrinti signalų formų bibliotekoje. Taip visi jūsų žinomai geri matavimai saugomi saugiai ir bus pasiekiami, kai jų prireiks.
Žinome, kad MCU valdiklio pakeitimas gedimą pašalino, bet kas iš tikrųjų nutiko, kad gedimas apskritai atsirado? Galimybė parsivežti ECU atgal į Pico ir jį detaliau ištirti buvo proga, kurios negalėjau praleisti.
Pirminės apžiūros metu, kai viskas padengta dulkėmis, nieko visiškai perdegusio nebuvo. Vis dėlto pastebėjome vieno plokštės komponento koroziją. Pažiūrėjus pro mikroskopą, atsivėrė dar daugiau.
Sunku pasakyti, ar MCU gedimą lėmė būtent tai, tačiau padėties tai tikrai negerino. Turint omenyje priešišką aplinką, kurioje šios mašinos dirba, kyla klausimas, kodėl ECU nėra geriau apsaugoti nuo aplinkos poveikio.
Straipsnis išverstas iš Pico Technology bibliotekos su gamintojo leidimu. Originalas: picoauto.com. PicoScope įrangą rasite mūsų kataloge.