Fórum témák
» Több friss téma |
Autóhoz szeretnék motorvezérlőt építeni.
A fejlesztést több lépcsőben képzelem el. 1. Az autó beinduljon és működjön alapjáraton 2. Az autó reagáljon a gázadásra 3. Az ECU vegyen figyelembe egyre több értéket és ezek alapján szabályozza a gyújtást és a befecskendezést. 4. Az ECU befecskendezési térképeit PC-ről lehessen frissíteni. Szerintem mikrokontrollernek valamilyen 32bites PIC-et fogok választani, ami majd USB-vel lesz összekötve a PC-vel. Amihez keresek szakirodalmat az első körben, az a főtengely szöghelyzet jeladó jelének a feldolgozása. Először egy központi injektoros parazita szikrás autón fogok kísérletezni. Oszcilloszkóppal megmérem a befecskendezési időket + a gyújtást hol adja az indítózásnál és alapjáraton.
Rendben. Ezekben olvasgass.Bővebben: Link
Ez nem lesz valami egyszerű. Milyen típusba szeretnéd?
A végső cél, hogy univerzális legyen. Azaz a windows-os programtól függjön, hogy milyen autóban lesz.
Kezdetben egy központi injektoros fiat pandában lenne. Úgy szeretném már az alap programot is megcsinálni, hogy a jeladó fogszáma már el legyen tárolva az eepromba, és ebből az értékből számoljon. Úgy gondoltam, hogy egy komperátor lenne a jeladó bemenetén, amiből számolja a főtengely szögjelet, és ehhez képest a gyújtást és befecskendezést. Amikor a fog kimarad, akkor nagyobb feszültség indukálódik. A kérdés, hogy ezt vezessem rá egy másik komperátorra, mert fontos tudni, hogy mikor maradt ki a fog, vagy az alap komperátor is elég, ami a fogakat számolja?
Frank Tibornak van 2 könyvet amit érdemes elolvasni első körben:
Benzinbefecskendező és motorirányító rendszerek Dízel befecskendező rendszerek Az utóbbit én személyesen picit elvaultabbnak tartom mint a Benzinest mert az elektronikára nem megy annyira rá. De ez magánvélemény. Ha ez megvan akkor felvetődik a kérdés, hogy milyen képeségekkel rendelkezel nyáktervezés és beágyazott programozás terén. Illetve mennyi pénzed van amit rá tudsz fordítani. Illetve, hogy teljesen sajátot akarsz tervezni vagy egy meglévővel akar kisérletezgetni. Érdemes gogol bácsiba berni, hogy Open source ECU. Ha nullarol akarsz indulni esetleg a Freescale MPC5554-es procit ajanlanam a belso eTPU miatt. Ehhez van befencskendezesi demo. Es az MMU miatt könnyű benne paraméterteret váltani.
Ismerem ezeket a könyveket.
Nyáktervezés: Sok projektet terveztem és kiviteleztem. Többek között USB-vel programozható etanol elektronikát is. Mikrokontrollereket több éve programozok. Mindenképpen PIC-el szeretném megoldani, mert az eredeti elgondolás szerint egy külső program számolná ki, hogy mit és mikor kell befecskendezni. A mikrokontroller a konfig alapján csak kiválasztaná az értékeket és vezérelné a gyújtást, befecskendezést. A gázpedál értékeknél is azt nézné meg, hogy az hány% és kivenné a megfelelő táblából az értékeket. A lényeg, hogy ne a mikró számolgasson, hanem a rátöltött konfig fájlból tudja, hogy mikor mit kell csinálnia. Motec elektronikákat is programozok. Ez hasonló lenne, csak saját HW és SW párossal. Annyi pénzt azért nem szeretnék a projectre szánni, amibe egy új motec kerül.
Szia!
A táblázatos megoldást azért nem javasolnám, mert nem véletlen, hogy mindig számol az ECU. Nincsen egy jó megoldás az éppen aktuális helyzetre. Számos bemenő adatból számolja ki az esetleges "jó megoldást". Ezenfelül a táblázatos értékekkel való dolgozás azért is bajos mert az u.n. kopogás szenzor is fontos elemét képzi a rendszernek ennek az a feladata, hogy ha "detonációs" égés következik be állít a befecskendezésen. Mivel a motor kopogása nem egy adat hanem nagyban függ az üzemanyag minőségétől ezt egy táblázatban igen nehezen tudod eltárolni. Írtad, hogy csináltál etanol elektronikát ott azért volt "könnyű dolgod" mert nem közvetlen az ECU-t tasztatod, hanem a Lambda-szonda jelét változtatod és azt küldöd az ECU-nak, hogy a keverék szegény ezért dúsítsa a keveréket. A diesel befecskendezős könyvben mert azért nincs olyan sok elektronika mert diesel befecskendezőket már jóval azelőtt használtak minthogy egyáltalán világítás került volna a járművekre  ... Én azt javaslom első körben derítsd ki milyen a Panda befecskendező rendszere mert az oké, hogy központi befecskendezős de én Mono-Jetronik vagy Motronic rendszerre tippelnék. Ha ez meg van az már félsiker mert tudjuk milyen benmenő jelei vannak az ECU-nak.A fejlesztési lépcsők nagyn szépek csak az a gond velük, hogy ez első három szervesen összefügg. Addig nem fog elindulni míg meg nem kapja a szükséges jeleket. Nem tudom, hogy tudod-e mekkora fába vágtad a fejszéd, ember legyen a talpán aki ezt egyedül összerakja. Csatoltam egy képet egy átlagos befecskendezésitérképről és egy átlagos befecskendezőszelep vezérlésről. A gyári ECU-kat mérnökök hada rakja össze ami nem véletlen, de ez egy szép téma és ha komolyan bele akarsz vágni én bátorítalak. Ha elfogadod, amiben csak tudok segítek neked ebben az igen szép összetett mérnöki feladatban. Üdv.: Joci
Az etanol elektronikánál sem néztem a lambdát (azt nézze a motorvezérlő). Ott is egy táblázat volt: fordulatszám, motorhőfok, terhelés, amiből a befecskendezési időt meghatározta.
A tapasztalatom az, hogy a 100000km feletti autók 50%-ban már nem működik a lambda szonda. rengeteg autóban világít a motorcheck lámpa. Az emberek nem cserélgetik ezeket az alkatrészeket. A motec-nál, ami azért a standalone motorvezérlők rolls-roysa. Ott is be lehet állítani, hogy milyen szenzorokat vegyen alapul. Versenyelektronika programozásnál az alap koncepció, hogy egy fajta üzemanyagra van az autó beállítva. Így a kopogó szenzornak olyan nagy szerepe már nincs is. A lambda jelet is figyelmen kívül hagyja, azaz egy széles sávú szonda csak logol, és ez alapján lehet a befecskendezési táblákat és a különböző kompenzációkat finomítani. A mostani autóknál a sokfajta üzemanyag, motorkopás, károsanyag kibocsájtás, gazdaságosság stb. mindenre fel kell készülni, ezért van a sok szenzor. Ahhoz, hogy beinduljon kevesebb dolog is elég. A fő kérdés az még mindig az, hogy a szöghelyzetet hogyan dolgozzam fel. Enélkül nem tudok elindulni.
A panda mono-motronic.
Azért választottam ezt, mert a központi injektor miatt egyszerűbb. A motronik miatt pedig a gyújtást is nekem kell vezérelnem. Idézet: „A fő kérdés az még mindig az, hogy a szöghelyzetet hogyan dolgozzam fel.” Ebben tulajdonképpen mi a kérdés? Hogy hogyan kösd össze a jeladót a digitális bemenettel? Vagy hogy sw-ből mit kezdjél egy érkező impulzussal?
Igazából mind a kettő.
Egyrészt a bemeneti fokozat a kérdés, amíg a jel a mikrokontrollerhez eljut. (tranzisztor, komparátor, műveleti erősítő és AD átalakító páros) Igazából a kimaradt fogat is detektálni kellene. Gondoltam arra, hogy a meredekséget nézek. Mer ott nem olyan meredek a jel, ahol a fog kimarad. Ennek az a bizonytalansága, hogyha a fordulatszám változik, akkor nagyobb lesz az amplitúdó ezáltal a meredekség is változik.
Én komparátor + digitális bemenet kombinációt használnék. Az A/D szerintem ide totál értelmetlen. Ahhoz nem tudok hozzászólni, hogy a jeladó és a komparátor közé mit érdemes rakni (hogy a komparálás szintje értelmesen fix lehessen).
A kimaradt fogat egyértelműen sw-ből kéne detektálni. Azaz mérni az egymás után jövő impulzusok közti időt, és ahol ez látványosan (duplájára) megugrik, na ott volt kb. félúton a jel. Ha valamihez kell real-time a kihagyási pont (azaz nem elég a következő jelnél reagálni), akkor az előző körben észlelt kihagyás után számolni kell az impulzusokat (meg átlagot számolni az impulzusok közti időre), és amikor kéne jönnie a következő kihagyásnak, na akkor az előtte levő utolsó impulzustól kell indítani egy timert.
Lehet így csinálom meg.
Ahány autó, annyi jel alak. Az sem mindegy, hogy 1 v. 2 fog marad ki. Komperátor, mikrokontroller. 1 timer nézi a fogakat -> így tudja a szöghelyzetet. 1 timer akkor indul, amikor a kihagyás után az első fog megjelenik, és ez fogja mérni a fordulatszámot.
A kimaradt fogdetektalasra pont jo lenne egy MPC5554 proci, mert a benne levo eTPU-hoz adnak eleve ilyen mintakdot
Erdemes lenne elmeletben kiszamolni, hogy mekkora processzorteljesitmenyre lesz szukseg. Pl 5000 fordulat/perc eseten kb 3ms-enkent kell gyujtani. Befecskendezni lehet hogy folyamatosan lehetne PWM-el, mert vegulis ugysem a hengerbe megy kozvetlen. Szoval ide akar n*3ms idoket tudok elkepzelni.
A fotengely szogjeladojahoz mindekeppen HW-es segitseg kell a uC-n belul. (MPC5554-en pont erre a problemara van HW-es segitseg hianyzog fog detektalassal) PIC-nel esetleg egy timerre lehetne kotni es azzal szamoltatni a fogakat. Foghianynal meg nullazni. A timer erteke meg megadja a mindenkori tengelyszogallast. A fordulatszamot lehetne a szogadobol szamolni vagy kulon jeladobol. Ez inkabb a motor terheles meresenek megallapitasanal lehet fontosabb. Tehat nem biztos hogy feltetlen gyujtasonkent kell uj valid fordulatszamjel. Ha a befecskendezes sem kotott a gyujtas ciklusidejehez akkor a legmennyisegmeres sem. Persze ovatosan az idokkel, mert minel lasabban vannak uj jelek annal lasabb lesz a vezerles/szabalyzas. A 3ms-es ciklusido worst case, de ha azt vesszuk hogy a vegcel egy mukodokepes ECU akkor szamolni kell ezzel a lehetoseggel. Nehez megsaccolni mekkora szamitasi kapacitas kell, de raerzesre dsPIC vagy PIC32-ot ajanlanek. Az alatt semmikeppen sem. Megjegyzem a PIC-et nem pont ECU-nak talaltak fel. A Freescalnek van motorvezerlesre keszult uC-je. Pl az MPC5554 pont ilyen. Sajnos ez inkabb a nagyobb cegeknek keszult akik meg tudjak venni a debuggert, forditot es operacios rendszert.
Szia!
Mailban küldtem egy szakdolgozatot, amiben az illető egy gyújtásvezérlést fejlesztett PC kapcsolattal, PIC-el. Hátha találsz benne hasznosat a te projektedhez. Érdekes a téma. Magam is foglalkozom járműelektronikával, azt is tanultam. Bár motorvezérlést még sosem fejlesztettem, de érdekel a téma, ha valamiben tudok, szívesen segítek. Az előzetes megfontolások és a célok pontos kitűzése szerintem nagyon fontos. Valószínűleg addig "könnyen" el lehet jutni, hogy a motor beinduljon és még reagáljon is, de a nehezebb dolgok onnan kezdődnek a különböző szabályozásokkal, lambda, alapjárat, kopogás, nyomaték, stb. a különböző kényelmi szolgáltatásokról, diagnosztikáról már nem is beszélve. Ahogy kyrk írja, ki kell kalkulálni előre, hogy mekkora memóriaterületekre és processzorsebességre lesz szükség. Egy prémiumkategóriás autógyártónál pl az a szabály, hogy a kész program nem foglalhat 30%-nál több memóriát, mert a tapasztalat, az, hogy a tesztelések során igencsak bele kell nyúlni még a kódba, és a jövőnek is kell helyet hagyni. Valami hasonló van a ciklusidőkre/órajelre is. Üdv! Kaszi
Ajánlanám a következő cikket is!
Egyszer regen vettem egy baromi regi ECU-t. Gondoltam szetszedem es megnezem mi van benne. Hatha valami uC meg ilyesmi. De vegul kiderult hogy analog elektronika van benne. Ha ebbol a szempontbol nezzuk akkor nem lehet tul nehez egy mukodo ECU-t leprogramozni ha az analogot vesszuk alapul.
Bar a jelek illesztese nyilvan mas egy digitalis ECU eseten mint egy regi analognal. A tengelyszogjeladora tuti van valami trukk, hogy mivel lehet a jelet jol feldolgozni. Valami remlik, hogy mintha a jel az az indukciovaltozast koveti, ezert ha differencialo tagon keresztul megy akkor szep negyszog jel lesz belole. Lehet ezzel lenne erdemes kezdeni es utana egy hiszterezis komparatort rakni. A hianyzo fog detektalas sem nehez. Meg kell merni az elotte levo jel frekijet es nezni, hogy az adott idon belul jon e kovetkezo jel. Ha nem akkor kimaradt egy. Esetleg fordulatszambol is ki lehet szamolni az idoablakot amibe bele kell hogy essen a jel. Feltetelezem, hogy egy korbefordulas alatt annyira nagyon nem valtozik a fordulatszam. Ha valtozik is akkor csak annyit hogy azt meg biztosan lehessen detektalni. Amugy missing pulse-ra pl az MPC5554-ben van ra direkt HW tamogatas. PIC-ben sajnos meg kell irni kezzel. Ez termeszetesen elvesz eroforrast. Picit az eroforrasokrol. En float,double fan vagyok, ha lehet akkor hasznalom oket. Persze 16F-esen nem, ott szopok neha emiatt. Konnyebb felfogni a tortszamos matematikat mint az egeszesszamos matematikat es mindig odagondolni, hogy most a 0xFFFF az 100%. Van egy olyan sanda gyanum, hogy akarmilyen PIC mellet az ECU csak akkor fog mukodni ha egeszszamos matematikat hasznalsz a szamolasokhoz. Kulonben neccess lesz beleferni az idobe. Es amugy a HW tamogatas hianyat SW-bol kell kikompenzalni.
Sajnos az ECU rajzok titkosabbak a katonai műholdak és a NASA űrszondáinak dokumentumainál együttvéve.
Párat azért lehet találni a neten, de elég régiek. Pl. a d-jetronic, uC nélkül, talán valami ilyesmit láthattál: http://members.rennlist.com/pbanders/ecu.htm Vagy egy modernebb motronic már uC-vel ebben a topicban: http://www.924board.org/viewtopic.php?t=30380&postdays=0&postorder=...ce9c75 Az előző eszmefuttatásomból még kimaradt, hogy mondjuk egy bosch, nem úgy fejleszt, hogy most ismerkedik a motorvezérlés elméletével, hanem szinte minden meg van már valamelyik korábbi projektjükben. Ha jön egy újabb megbízás, gyakorlatilag Ctrl+C, Ctrl+V az egész. Max a megbízó szájaízére kell formálni kicsit a dolgot, vagy ha valamilyen innovációt vezetnek be, csak azzal kell alapjaiban is foglalkozni. Ezeknél a cégeknél nem is egy emberesek a projektek, hanem komplett teamek dolgoznak külön a HW és külön a SW kérdéseken. A topicban felvetett témát szerintem nem úgy kell kezdeni, hogy nekimegyünk a fordulatszámjeladó feldolgozás kérdésének, hanem sokkal messzebbről kell az egészet áttekinteni, mit akarunk megvalósítani, milyen szenzorok, aktorok lesznek, kelle e az ECU-nak valami más vezérlővel együttműködnie, lesznek e diagnosztikai funkciói, esetleg vészüzemmódjai, stb. Ha ez ez elején elmarad, akkor lehet, hogy a fejlesztés közben két három generációval nagyobb procira kell váltanunk, mert időközben kinőttük. Bár lehet, hogy az indító ezt megtette, csak nem írta le. Még egy megjegyzés, a már fent említett autógyártónál van egy lista arról, hogy milyen mikrovezérlőket alkalazhatnak a beszállítói, hát PIC-ek eszerint a lista szerint, csak valamilyen másodlagos funkciót láthatnak el. Üdv! Kaszi
Köszönöm a dolgozatot. A felénél tartok. Nem pont az, ami nekem kell, de hasznos anyag. Sok egyéb áttérinfót össze lehet belőle szedni.
Autóipari cégnél dolgozom.
Az biztos, hogy egy project fejlesztésén több ember dolgozik. Az a baj az új motorvezérlő elektronikákkal, hogy un. ASIC (olyan cél IC, ami direkt arra a funkcióra van tervezve, egy tokon belül kis és nagy áramú részek + kommunikáció) van bennük. 1 IC végzi az összes analóg is digitális jel feldolgozását és illesztését, majd soros vonalon kommunikál a mikróval. A mikro pedig szintén egy más típusú ASIC-et hajt meg, ami a kimeneteket vezérli. A korszerű motorok motorvezérlője attól bonyolult, hogy elég nagy környezetvédelmi normának kell megfelelnie. A vevők határozzák meg, hogy milyen diagnosztikai protokollt használjon, milyen CAN üzeneteket küldjön, stb. Ami a tapasztalatom ilyen projektekben: Elindul a fejlesztés, amire az ember próbál felkészülni és tervezni a funkciókat. Aztán ez vagy jó irány, vagy rossz. Az biztos, hogy nem egy nyáklap verziót kell majd legyártani a project alatt. Biztos, hogy a HW-ben is lesznek apróbb korrekciók vagy komplett gyökeres módosítás. PIC-et eddig csak szerszámgépben láttam. Ha jól tudom nincs autóipari minősítése. Talán a PIC32-esnek van. Ennek ellenére ezt választanám a projekthez, mert olcsó és van már vele tapasztalatom.
Bármilyen mikrokontrollert is választasz, mindenképpen nézz bele az errata doksijába is, mert minél bonyolultabb egy kontroller, általában annál több a hiba a szilíciumon. Nálam volt már olyan, hogy igen nagyot szívtam volna, ha nem nézem meg az errata-t.
Közben, megnéztem, hogy milyen időkkel kellene számolnom.
Excelben a 100-as és 10000 fordulatot vettem alapul. Megnéztem a fordulatszám változás mértékét foganként. Úgy fok kinézni a dolog, hogy a négyszögjellé alakítás után elkezdem nézni a jelet felfutó élre. Elindul egy 16bites timer. Megnézi, hogy a két fog hány mikroszekundumra van egymástól. Azután a kapott értéket elmentem, majd elosztom 4-el, mialatt a timer újra kell indítani. Ezzel egy időben egy másik timert is indítok, ami akkor fog megállni, mint a 4-el osztott jel. Itt megvizsgálom, hogy a jel magas állapotban van-e. Ha igen, akkor nem hiányzott a fog. Ha a hiányzó foghoz ér, akkor pedig tudja, hogy egyszer körbeért a főtengely. Ekkor fogja ellenőrizni azt is, hogy annyi fog volt-e, amennyi be van állítva. Mivel tényleg sok erőforrást elvesz, erősen gondolkodom azon, hogy ezt egy kis 8 lábú pic vogja végezni ami valamilyen soros vonalon kommunikál a "nagy" mikrokontrollerel. Így a fő mikrokontoller be tudja a kis pic-et is konfigolni, hogy hány fognak kell lennie és mennyi a kimaradt fog. A kis pic-nek lenne 3 kimenete, az egyik a fogszámmal megegyező négyszögjel, a másik pedig a holtpont jel, a harmadik pedig a hiba jel.
Közben halad a project. Nem olyan gyorsan, mint kellene de halad.
Párhuzamosan írom a PIC programot és fejlesztem a hardvert. Ami eddig készen van a SW-ben: 3D lineáris interpoláció. Ez nagyon fontos, hogy a megfelelő táblából a köztes adatokat ki tudja a program kalkulálni. Ez a rutin 25us alatt lefut. Ez talán elfogadható, de sokkal gyorsabbra már nem nagyon lehet írni. Így is lebegőpontos számokat kezel a táblában, ami a későbbi precíz működéshez fontos lesz. A program a táblából kivett értéken a megfelelő időpontban indítja a gyújtást. A hardver is alakul. USB-vel lesz a PC-vel összekötve, és a PIC-en egy bootloader fog futni, hogy a firmwaret könnyen lehessen updatelni. Most a gyújtás részt tervezem. Az az ötletem támadt, hogy amikor gyújtás van, akkor a jelet bevezetem egy AND kapuba a PWM jellel együtt. Ez arra lesz jó, hogy amikor a gyújtás van, és a kis ellenállású tekercsen elkezd folyni az áram, akkor csak 8 amperig engedem, és ott a PWM elkezdi áramkorlátban tartani a tekercset, amíg a gyújtás tart. Ha van valakinek jobb ötlete, hogy hogyan korlátozzam a tekercs áramát, akkor ne tartsa magába.
Esetleg használhatsz zárásszögvezérelt primeráram határolós gyújtómodult.
Hogyan működnek ezek a modulok?
Be lehet állítani az áramkorlátot, és csak egy FET-el kell vezérelni, hogy hány ms-ig legyen gyújtás? Vannak konkrét típusok? |
Bejelentkezés
Hirdetés |
