LIN (Local Interconnect Network) – atrodo, kad ji yra visur! Klimato sistemoje (HVAC), durų užraktuose, šildomose sėdynėse, veidrodėliuose, akumuliatoriaus stebėjimo ir įkrovimo sistemose. Ji dažniausiai pasitaiko ten, kur ryšys nėra kritinis saugai ir kur greitis nėra prioritetas. Kaip ir kituose apie tinklus rašytuose forumo įrašuose, turime prisiminti, kad PicoScope nėra specializuotas duomenų kaupiklis (data logger). Rinkoje yra šiam darbui labiau pritaikytų prietaisų, tačiau kai turite tik jį, vis tiek galima nuveikti labai daug.
LIN yra visiškai konfigūruojama, t. y. automobilių gamintojai gali priskirti ID reikšmes bet kuriam ECU ar valdymo blokui – šia prasme ji panaši į CAN: jei norite dekoduoti aukštesniu lygiu, jums reikės DBC failo, kad galėtumėte interpretuoti dekoduotus duomenis. LIN atveju reikėtų LDF (Lin Description File) failo, kuriame ir slypi raktas duomenims atrakinti. Prašome nepainioti LIN valdomų generatorių su PWM ar BSD valdomais, kurie paprastai sutinkami atitinkamai Ford ir BMW automobiliuose.
Kad šis įrašas būtų suprantamas, reikia bazinių žinių apie LIN. LIN – tai vienos gyslos dvikryptė duomenų magistralė, perduodanti duomenis santykinai mažu greičiu: maksimalus greitis 20 kBaud (kbit/s), tipiniai greičiai – 9,6 kBaud ir 19,2 kBaud. LIN gali aptarnauti iki 16 ECU: 1 pagrindinį (master) ir 15 pavaldžiųjų (slave). Ji kur kas pigesnė už CAN dėl vienos gyslos konstrukcijos ir daugiausia naudojama ten, kur nereikia didelės spartos ryšio. LIN veikia pagal pagrindinio ir kelių pavaldžiųjų mazgų principą, pavyzdžiui, centrinės elektronikos ECU, kuris susisiekia su visais durų užraktais. Šio signalo įtampos paprastai yra perjungiamos nuo akumuliatoriaus įtampos iki masės – būtent todėl jį dažnai galima supainioti su PWM signalu. LIN specifikacijos dokumentą, kuriuo rėmiausi rašydamas šį straipsnį, rasite čia.
Kadro (frame) struktūrą sudaro keli elementai, tačiau pagrindinę jo formą sudaro dvi dalys – antraštė (header) ir atsakas (response), kurios toliau skaidomos smulkiau.
Antraštę sudaro pertrauka (break), sinchronizacijos baitas (sync byte) ir ID laukas. Pertrauka yra pranešimas visiems magistralės mazgams, kad reikia klausytis, nes bus transliuojami pranešimai. Ji paprastai gana ilga – užima bent 11 bitų, o daugumoje šiuolaikinių automobilių matomi 13 ir daugiau bitų. Dėl šios dalies ilgio jos neįmanoma supainioti su jokiu kitu pranešimu. Iškart po pertraukos eina sinchronizacijos baitas. Šis 8 bitų sinchronizacijos baitas užtikrina, kad pavaldieji mazgai suderintų savo perdavimo spartą su pagrindinio mazgo sparta. Įprasta šį baitą matyti šešioliktainiu pavidalu kaip 0x55.
Identifikatoriaus dalis yra viena svarbesnių pranešimo dalių, nes ji perduoda pavaldiesiems mazgams nurodymus, kokios informacijos reikia pagrindiniam mazgui. ID sudaro 6 bitai ir 2 lyginumo (parity) bitai. Visi 8 bitai sudaro apsaugotą identifikatorių (protected identifier). Pavaldieji mazgai žiūri į lyginumo bitus, kad įsitikintų, jog pranešimas galiojantis, ir arba ignoruoja tolesnius duomenis, arba klausosi kitų pavaldžiųjų mazgų, arba atsako į ID atsako lauke. Pico LIN dekoderis dekodavimo lentelėje ID iš apsaugoto identifikatoriaus išskiria automatiškai.
Šis Texas Instruments dokumentas puikiai paaiškina kadro struktūrą.
Prieš pereidami prie atsako lauko, turime aptarti skirtingus kadrų tipus. LIN protokole yra 6 skirtingi būdai, kaip pagrindinis mazgas gali prašyti duomenų iš pavaldžiųjų. Tai:
Besąlyginis (Unconditional)
Tai dažniausias būdas, kai pagrindinis mazgas antraštėje siunčia ID, prašydamas duomenų iš konkretaus pavaldžiojo mazgo.
Įvykio inicijuotas (Event Trigger)
Čia pagrindinis mazgas prašo duomenų iš kelių pavaldžiųjų mazgų, jei mano, kad duomenys buvo atnaujinti.
Sporadinis (Sporadic)
Šiuo režimu pagrindinis mazgas elgiasi kaip pavaldusis – atsako į savo paties antraštę. Tai leidžia pavaldiesiems mazgams „matyti“ pagrindinio mazgo siunčiamus duomenis ir juos naudoti. Būtent tokį formatą naudoja LIN valdomi generatoriai, kuriuos apžvelgsime išsamiau.
Diagnostinis (Diagnostic)
ID 0x3C ir 0x3D naudojami diagnostinei informacijai iš pagrindinio ir pavaldžiojo mazgo surinkti. ID 0x3C skirtas informacijai iš pagrindinio mazgo, o ID 0x3D – iš pavaldžiųjų.
Naudotojo apibrėžtas (User-defined)
ID 0x3E apibrėžia naudotojas ir jame gali būti bet kas.
Rezervuotas (Reserved)
ID 0x3F negalima naudoti LIN 2.0 tinkluose, tad jei matote jį dekodavimo lentelėje – kažkas nutiko negerai!
Dažniausiai pasirenkamas besąlyginis metodas ir dekodavimo lentelėje paprastai matysite būtent tokį formatą, nebent žiūrite į kažką, kur naudojami sporadiniai kadrų tipai, pavyzdžiui, LIN valdomus generatorius. Bet prieš gilindamiesi į generatorius, užbaikime LIN kadrą – apžvelkime atsako dalį.
Duomenų laukas yra būtent tai, kas pasakyta: jame yra duomenys, kurių pagrindinis mazgas paprašė ID kadre. Jį gali sudaryti 2, 4, 6 arba 8 baitai. Duomenų ilgį galima susieti su ID kadru, tačiau paprastai jį nurodo tiekėjas.
Galiausiai kadras baigiasi kontroline suma (checksum). Ji būna klasikinio arba išplėstinio formato. Klasikinė kontrolinė suma skaičiuojama naudojant tik duomenų baitus. Išplėstinė kontrolinė suma naudoja duomenų baitus ir apsaugotą identifikatorių. ID kadrai 0x3C ir 0x3D, t. y. diagnostiniai kadrai, visada naudos klasikinę kontrolinę sumą.
Būtų puiku, jei egzistuotų nustatytas standartas, leidžiantis dekoduoti antraštės identifikatorių ir geriau suprasti duomenų atsaką, tačiau, deja, jo nėra. Visa ši informacija užrakinta LDF faile ir eiliniams naudotojams neprieinama. Kelis paprastus dalykus vis dėlto galime stebėti – tai pažadinimo (wake-up) signalai ir užmigimo (go to sleep) pranešimai.
Pažadinimas
LIN magistralę galima pažadinti, kad būtų aktyvuota kokia nors funkcija, pavyzdžiui, durų užraktai bekontakčio atrakinimo sistemose. Tai taip pat gali sukelti rimtesnių problemų ieškant akumuliatoriaus išsikrovimo priežasties, kai automobilis trumpam pabunda. Tai lengva pagauti su PicoScope, nes LIN ryšys vyksta pagal nustatytą šabloną. Bet kuris mazgas gali paprašyti tinklo pažadinimo, siųsdamas impulsą – nutempdamas įtampą į dominuojančią būseną, kurioje ji turėtų būti išlaikoma ilgiau nei 150 µs. Dominuojančias įtampas galima nustatyti pagal tai, kad signalas nukrenta beveik iki 0 V, o slenksčių lygiai pagrindiniam ir pavaldiesiems mazgams skiriasi. Kodėl būtent taip – nesu tikras, tačiau tai leidžia gerokai varijuoti signalo lygiams ir, tikėkimės, daro tinklą atsparesnį. Pavyzdžiui, pagrindinis mazgas privalo nuvesti magistralės įtampos lygį iki 20 % akumuliatoriaus įtampos ribų, o recesyvūs bitai turi būti 80 % ribose. Pavaldieji mazgai pripažins dominuojantį bitą, jei jis yra 40 % akumuliatoriaus įtampos ribose, o recesyvų – jei 60 % ribose.
Jei mazgas išsiunčia pažadinimo užklausą ir grąžina magistralę į recesyvią būseną, užklausa yra galiojanti, o mazgas grįžta klausytis magistralės komandų. Jei per 100–250 ms nėra atsako iš kito mazgo, jis gali siųsti dar vieną pažadinimo užklausą. Tai jis gali padaryti tris kartus iš eilės, o paskui privalo palaukti bent 1,5 sekundės, kol vėl bandys pažadinimo užklausą – ir taip šis šablonas tęsiasi neribotą bandymų skaičių.
1. Uždegimas ĮJUNGTAS
2. Pažadinimo pranešimas
Aukščiau pateiktame paveikslėlyje matoma LIN magistralė buvo užfiksuota prie generatoriaus. Matote, kur buvo įjungtas uždegimas, po to seka pažadinimo pranešimas, kuris „prikelia“ generatorių, ir tada prasideda ryšys.
Užmigimas
Kai pagrindinis mazgas nusprendžia, kad magistralė nebeturi palaikyti ryšio, jis išsiunčia tokį pranešimą – 00 FF FF FF FF, nurodydamas, kad magistralė dabar turi nutilti. Užmigimo komanda aiškiai matoma paskutiniame šio įrašo pakete:
Šiame paskutiniame duomenų kadre man įdomu tai, kad ID yra 0x3C, o mes žinome, jog jis rezervuotas diagnostikai. Atrodo, kad šis ID naudojamas ir visų pavaldžiųjų mazgų išjungimui. Galbūt taip užtikrinama, kad pavaldieji mazgai, pamatę šį ID, negalėtų jo su niekuo supainioti. Žinome tai, kad jei pirmasis baitas po ID 0x3C lygus 0, magistralė bus priverstinai užmigdyta. Taip pat verta paminėti, kad jei magistralė būna neaktyvi maždaug 4 sekundes, pavaldieji mazgai automatiškai užmiega, kad būtų taupoma energija.
LIN valdomi generatoriai
Nepaisant informacijos apie LCF stygiaus, ne viskas prarasta kalbant apie LIN valdomus generatorius. Duomenų dekodavimas turi reikšmingų privalumų.
Toliau pateikti tyrimai atlikti remiantis šiuo NXP techninių duomenų lapu. Yra 11 konfigūracijų, kuriomis galima apibrėžti informaciją, siunčiamą į generatorių ir iš jo. Kai kurios jų nuo šio dokumento parašymo galėjo pasikeisti, tačiau kol kas atrodo, kad jos vis dar aktualios. Šios konfigūracijos remiasi ID, naudojamais duomenų paketams perduoti ir gauti.
Konfigūracijos:
Kadangi šiame taškas-į-tašką (peer-to-peer) tinkle paprastai yra tik du mazgai, su Pico integruotu dekoderiu galime nustatyti, kurią konfigūraciją naudoja generatorius. Atidus skaitytojas pastebės, kad aukščiau pateiktoje lentelėje ID kartojasi skirtingose versijose. LIN1 A versija, kurią nagrinėsime išsamiau, naudoja ID 29, 11, 12 ir 15. Peržvelgę sąrašą taip pat matome, kad LIN1 B versija taip pat naudoja 29, 12 ir 15, o LIN1 D versija taip pat turi 29, 11 ir 12.
Kaip nustatyti, kurią versiją turėtume naudoti? Galėtume šiek tiek pasidomėti internete, remdamiesi gamintojo informacija, nors nesu tikras, kad ją lengva rasti. Kur kas paprasčiausias būdas – dekoduoti užfiksuotus duomenis. LIN dekoderis atliks visą sunkų darbą už mus ir parodys generatoriaus bei ECM ID, kuriuos tada galėsime palyginti su aukščiau pateikta lentele.
Aukščiau pateiktoje dekodavimo lentelėje matome, kad po kadro identifikatoriumi yra du labai aiškūs ID: 29 ir 11. Tai galime susieti su LIN versijų lentele, kur matome dvi galimas parinktis – LIN 1 A versiją ir LIN 1 D versiją.
Peržvelgę AR6000 techninių duomenų lapą, randame šių dviejų versijų pranešimų konfigūraciją, kur tiek Rx, tiek Tx formatuose yra tam tikrų skirtumų, tačiau yra ir panašumų. Manau, svarbiausi gedimų paieškai yra Rx įtampos nuostatis (voltage setpoint) ir Tx diagnostinės vėliavėlės (diagnosis flags), rodančios gedimus.
Prieš atidžiau pažvelgdami, ką šie duomenys reiškia, turėtume suprasti šių duomenų kadrų paketo sandarą. Rx atveju turime 4 baitus duomenų, kurių bitai naudojami skirtingai, priklausomai nuo to, ką jie reiškia.
A. Įtampos nuostatis
B. Apkrovos atsako rampos laikas
C. Apkrovos atsako atjungimo sūkiai
D. Žadinimo srovės riba
E. Kintamas, priklauso nuo to, ar yra Tx15
F. „Aklioji zona“ (daugiau informacijos AR6000 dokumente)
G. Įtampos ribojimas esant aukštai temperatūrai
H. „Akliosios zonos slopinimas“ (daugiau informacijos AR6000 dokumente)
Skirtumas tarp LIN 1 A versijos ir D versijos tas, kad D versija nenaudoja jokių 4-ojo baito duomenų, o tai tam tikra prasme supaprastina dekodavimą. Taigi, remiantis tuo, kas pasakyta, diagnostiniu požiūriu gedimų paieškoje galime efektyviai panaudoti 2 duomenų elementus. Jei žinome, koks nuostatis turėtų būti, galime jį palyginti su tuo, ką generatorius iš tikrųjų išduoda. Panašiai, kaip stebėtume tikslinę ir faktinę kokio nors EGR vožtuvo reikšmę.
Iš to, ką sužinojome apie 6 skirtingus kadrus, kuriuos galime naudoti, esame beveik tikri, kad vienintelis būdas, kaip aukščiau aprašytas formatas gali veikti, yra sporadiniai kadrai. Priminsiu: tai atvejis, kai pagrindinis mazgas pats atsako į savo išsiųstą ID, kad pateiktų papildomų duomenų pavaldiesiems mazgams. Kadangi paprastai turime tik vieną pavaldųjį mazgą – generatorių – tai aukščiau pasakyta būtų teisinga.
Pavyzdžiui, pažvelkime į aukščiau pateiktą kadrą. Pagrindinis mazgas siunčia ID 0x29, į kurį pats ir atsako, pateikdamas informaciją apie įtampos nuostatį duomenų lauke 1F A5 1F 00. Po to pagrindinis mazgas siunčia ID 0x11, prašydamas informacijos iš pavaldžiojo mazgo, kuris atsako duomenimis 2A 02.
Kad visiškai suprastume ID 0x29 ir ID 0x11 duomenis, turime šešioliktaines reikšmes paversti dvejetainėmis. Spustelėkite LIN dekoderį po kanalo parinktimis, pirmajame dekoderio skydelyje spustelėkite Next ir prieš spausdami Finish rodymo parinktyse pasirinkite dvejetainį (binary) formatą.
Naudodami anksčiau pateiktą lentelę, kurioje aprašytas ID 0x29 bitų paskirstymas, gauname štai ką:
Vien pažvelgę į įtampos nuostatį žinome, kad jį sudaro pirmieji 6 pirmojo baito bitai, kurie pagal aukščiau pateiktą lentelę yra 111110. AR6000 dokumente pateikta nemažai peržvalgos lentelių, kuriose šias reikšmes galima paversti žmogui suprantamu pavidalu. Šiuo atveju 111110 atitinka 16 V.
Dirbant su LIN duomenimis paprastai geriausia žiūrėti į dvejetainius duomenis. Taip yra todėl, kad LIN formatas naudoja mažiausiai reikšmingo bito (Least Significant Bit, LSB) tvarką.
LSB yra bitas, atitinkantis mažiausią galimą reikšmę (t. y. jis bus 0 arba 1), o svarbiausias bitas (Most Significant Bit, MSB) yra bitas, atitinkantis didžiausią galimą reikšmę (pvz., 255 arba FF, jei kalbame apie beženklį baitą). Todėl, kai perduodami dvejetainiai duomenys, svarbu žinoti, ar jie ateina didėjančia bitų reikšmingumo tvarka (t. y. pirmiausia LSB, arba pirmiausia 0-oji bito pozicija), ar mažėjančia bitų reikšmingumo tvarka (t. y. pirmiausia MSB, arba pirmiausia 7-oji bito pozicija). Pirmuoju atveju perduotų bitų rinkinį reikia skaityti iš kairės į dešinę, kad teisingai nustatytumėte atitinkamas dešimtaines ar šešioliktaines reikšmes, o antruoju atveju (pavyzdžiui, žiūrint CAN duomenis) skaitoma iš dešinės į kairę.
Jei teisingai nepakoreguosite bitų tvarkos, jūsų apskaičiuotos šešioliktainės reikšmės gali būti neteisingos, kai turite LSB-first dvejetainius duomenis (dvejetainės į šešioliktainę konversijos paprastai daro prielaidą, kad duomenys yra MSB-first). Tas pats galioja ir konvertuojant iš šešioliktainės į dvejetainę.
PicoScope LIN dekoderis tuo pasirūpina automatiškai, sudėliodamas dvejetaines pozicijas LSB tvarka, tad papildomų veiksmų nereikia. Vis dėlto, kad įsitikintumėte, jog tai veikia, pabandykite Windows skaičiuotuvo programuotojo (programmer) režimu įvesti šešioliktainę reikšmę 1F, kuri yra pirmasis bitas iš pirmojo duomenų paketo aukščiau pateiktuose paveikslėliuose. Konvertavus 1F į dvejetainę Windows skaičiuotuvu gaunama 00011111. Kadangi daroma prielaida, jog naudojama MSB tvarka, pirmas eina 7-asis bitas. Šiuo atveju jis yra 0, o LSB 0-ojoje pozicijoje yra 1. Pertvarkę formatą pagal LIN protokolą, apverčiame tvarką, kad pirmas būtų LSB, ir gauname 11111000 – būtent tokią reikšmę matome PicoScope dekodavimo lentelėje.
Patikrinę, kad mūsų dvejetainis formatas teisingas, galime pasinaudoti nuosekliojo dekodavimo lentelės eksporto funkcija ir apdoroti duomenis Excel programoje – panašiai, kaip braižome SENT susijusius duomenis šiame straipsnyje.
Atvėrę eksportuotus duomenis CSV formatu, turėtumėte matyti kažką panašaus į žemiau pateiktą paveikslėlį. Šiuo atveju eksportavau tik vieną buferį, tačiau būtų prasminga eksportuoti visus buferius, kad turėtumėte daugiau duomenų darbui.
Prieš darydami ką nors kita, turėsite šį CSV dokumentą įrašyti kaip Excel darbaknygę. Priežastis ta, kad uždarius dokumentą jūsų įvestos formulės nebus išsaugotos. Dėl to man teko šiek tiek pasikankinti, nes iš pradžių to nepadariau. Įrašęs dokumentą ir kitą dieną prie jo grįžęs, radau praradęs visas savo formules ir peržvalgos lenteles!
Įrašę darbaknygę, kitu žingsniu pridėkite filtrą. Tam viršutinėje įrankių juostoje spustelėkite Data, tada Filter. Taip prie kiekvienos stulpelio antraštės atsiras nedidelis išskleidžiamasis meniu, leidžiantis greitai rikiuoti duomenis pagal pasirinktas parinktis. Šiuo metu mus domina tik kadras su įtampos nuostačiu, kuris, kaip žinome, yra 8 baitų duomenų lauko pradžioje. Duomenis galime surikiuoti taip, kad būtų rodomi tik šie kadrai: spustelėkite apsaugoto identifikatoriaus stulpelio išskleidimo rodyklę ir pasirinkite ID, kuriame yra 8 baitai duomenų.
Taip liks tik su tuo ID susiję duomenys, todėl galėsime sutelkti dėmesį vien į įtampos nuostatį per visą buferį. Tie, kurie yra susipažinę su Excel, žino, kad duomenims apdoroti galima naudoti be galo daug formulių. Excel turi labai naudingų patarimų apie formules, ir jei kada užstrigsite, būtinai pasinaudokite pagalbos mygtuku. Mane jis išgelbėjo ne kartą!
Kaip žinome, mus domina pirmieji 6 duomenų lauko bitai, iš kurių nustatomas įtampos nuostatis. Norėdami juos atskirti nuo likusių duomenų, naudosime funkciją MID. Kai kas paklaus, kodėl tiesiog nenaudoti LEFT, tačiau jei paaiškinsiu, kaip naudoti MID, ją bus galima pritaikyti ir kitiems bitams, kurie neprasideda nuo kairiojo langelio krašto. Funkciją MID lengviausia suprasti naudojantis Excel patarimais.
Ši funkcija grąžina langelio simbolius pagal pradžios poziciją, skaičiuojamą nuo kairės, ir po jos einančių simbolių skaičių. Pavyzdžiui, paimkime baitą iš pirmosios duomenų lauko eilutės, kuris yra 10101000. Žinome, kad mums reikia 6 bitų, pradedant nuo kairės, tad funkcijai reikia nurodyti pradžios tašką 1 ir grąžinti 6 simbolius – taip gausime 101010.
Tuomet mūsų formulė atrodo taip:
=MID(I2, 1, 6)
Dabar galime pasirinkti šį langelį ir tempdami užpildyti likusius langelius.
Kita dalis šiek tiek užima laiko, nes reikia nukopijuoti lentelę iš AR6000 dokumento į Excel, tačiau tai verta pastangų! Aš paprastai lentelę sukeliu į naują lapą, kad ji būtų atskirai nuo duomenų.
Turėkite omenyje, kad Excel nemėgsta pradžioje esančių nulių. Dėl to lentelės dvejetainėse reikšmėse juos turime pašalinti, nes formulė vlookup neras atitikmens, jei juos paliksime. Užbaigę lentelę, dabar galime naudoti funkciją VLOOKUP, kad paverstume savo 6 bitus mums tinkama reikšme.
Turiu paminėti vieną dalyką: Excel nemėgsta ieškoti reikšmių, kurias sukūrė formulė, nes techniškai langelio reikšmė yra =MID(I2, 1, 6). Kad Excel žiūrėtų į reikšmę, į savo paieškos formulę turime įterpti funkciją Value.
Toliau galime nurodyti Excel, kur yra duomenys, kad jis rastų reikšmę mūsų pasirinktame langelyje ir grąžintų lentelėje esančią reikšmę. Mūsų formulė turėtų atrodyti taip:
=VLOOKUP(VALUE(O2),’Voltage Set Point table’!B2:C65,2)
Mes prašome Excel paimti langelyje 02 esančią reikšmę ir jos ieškoti lape „Voltage Set Point table“ tarp langelių B2 ir C65. Radęs reikšmę, jis turi grąžinti 2-ajame stulpelyje esančią reikšmę.
Deja, dabar negalime tiesiog tempti ir užpildyti, kaip darėme su ankstesne formule, nes tai pakeis peržvalgos lentelės langelių rėžį. Kadangi nenorime, kad lentelės rėžis keistųsi, prieš lentelės rėžį turime įterpti simbolį $, kad formulė atrodytų taip:
=VLOOKUP(VALUE(O2),’Voltage Set Point table’!$B$2:$C$65,2)
Dabar tempiant ir užpildant likusias eilutes keisis tik ieškomos reikšmės langelio numeris, o ne lentelės rėžis.
Dabar turime visą to vieno buferio įtampos nuostačio reikšmių sąrašą. Žinoma, abi formules galėtumėte sujungti į vieną išvesties stulpelį. Tokia formulė būtų:
=VLOOKUP(VALUE(MID(I2,1,6)),’Voltage Set Point table’!$B$2:$C$65,2)
Vis dėlto manau, kad naudinga pamatyti, kaip viskas dera tarpusavyje, paliekant tai atskirais etapais. Dabar, kai turime duomenis, galime juos pavaizduoti grafiškai ir pamatyti, kaip pagrindinis mazgas bandė valdyti generatorių pagal įtampos nuostatį.
Tą patį metodą galime pritaikyti ID 0x11, kuriame yra iš generatoriaus pagrindiniam mazgui siunčiami duomenys. Atsako duomenys sudaro tik 2 baitus, tačiau juose yra labai naudingos informacijos. Vėl remiantis AR6000 dokumentu, yra 2 variantai, kaip minėjome anksčiau – LIN 1 A versija ir LIN 1 D versija. ID 0x11 atveju yra dvi versijos, priklausančios nuo to, ar perduodama temperatūra. Kadras atrodo taip:
A. Aukštos temperatūros diagnostinė vėliavėlė
B. Mechaninio gedimo diagnostinė vėliavėlė
C. Elektrinio gedimo diagnostinė vėliavėlė
D. Žadinimo srovės PWM užpildos koeficiento reikšmė (yra peržvalgos lentelė)
E. Išmatuota žadinimo srovė ir (arba) temperatūros matavimas (yra peržvalgos lentelė)
F. LIN klaidos diagnostinė vėliavėlė
G. LIN ryšio laiko limito viršijimo diagnostinė vėliavėlė.
Kaip matote, šiame kadre yra labai naudingų elementų, ir, laimei, bitams atskirti bei duomenų lauko reikšmėms gauti galime naudoti anksčiau aptartą funkciją MID. Susitelkime į elementus, kurie yra tik 1 bito ilgio.
Kaip matyti iš lentelės, šis konkretus generatorius pažymėjo mechaninį gedimą. Šios vėliavėlės gali padėti geriau suprasti, kodėl generatorius sugedo arba kodėl skydelyje užsidega EML lemputė, kai gedimo kodai nėra itin informatyvūs. Vėliavėlės taip pat gali padėti suprasti, kodėl naujas generatorius gali kelti problemų – stebint vėliavėles ties LIN klaidos ir LIN laiko limito įrašais.
Aukščiau pateiktoje informacijoje apie generatorius nemažai rėmiausi AR6000 dokumentu. Tame dokumente yra daugiau dalykų, kurių nepaminėjau, tačiau turėkite omenyje, kad tai tik vienas šaltinis. Gali būti, kad generatoriuose naudojami ir kiti LIN lustai, kurie šio dokumento atžvilgiu turi nedidelių skirtumų. Vis dėlto tai kol kas išsamiausias dokumentas, padedantis suprasti ECM ir generatoriaus tarpusavio ryšį, ir, tikiuosi, jis padės diagnozuoti LIN valdomus generatorius.
Straipsnis išverstas iš Pico Technology bibliotekos su gamintojo leidimu. Originalas: picoauto.com. PicoScope įrangą rasite mūsų kataloge.