Myślę nad wystartowaniem otwartego projektu sterownika kontrolującego pracę silnika.

Komputer byłby przewidziany do modyfikowanych silników i powinien umożliwiać łatwe dostrajanie sterowania do robionych modów.

Wiele osób na tym forum robi mody i jestem ciekaw waszej opinii. Czy warto w coś takiego wchodzić ( czy jest realne zapotrzebowanie).

Czy też w zupełności wystarczają modyfikacje softu dla już istniejących sterowników ( jak są one robione? bo jak rozumiem dostępu do kodu źródłowego nie ma).

Nie myślę tutaj o projekcie komercyjnym, nie musi to przynieść zysku ani nawet zwrócić kosztów. Interesuje mnie bardziej to czy będzie wystarczające zainteresowanie i ktoś chętny żeby projekt nie umarł śmiercią naturalną

> Czy też w zupełności wystarczają modyfikacje softu dla już

> istniejących sterowników ( jak są one robione? bo jak rozumiem

> dostępu do kodu źródłowego nie ma).

http://autokacik.pl/showthreaded.php?Cat=0&Number=280069165&an=0&page=0#Post280069165 tutaj troche info jest...

> Myślę nad wystartowaniem otwartego projektu sterownika kontrolującego

> pracę silnika.

Nie wiem jakie są Twoje doświadczenia w tej kwestii, ale (wypowiem się jako inżynier w temacie sterowania mikroprocesorowego):

1. Sprawa jest w miarę prosta w odniesieniu do konkretnego silnika i sterowania nim, algorytm kontrolno-sterujący jest jednoznaczny, można napisać program który to wykona.

2. Powyższe do poprawnego wykonania wymaga wykonania pewnej liczby złożonych testów, najlepiej z zastosowaniem symulatora silnika. To jest schodek pierwszy. Jakikolwiek błąd w kodzie objawi się złą pracą silnika, za dużym spalanie, spadkami mocy lub gaśnięciem.

3. Teraz wyobraź sobie, że chcesz to uogólnić do wielu różnych silników samochodowych - ilość pracy i złożoność kodu rośnie wykładniczo. Oczywiście w przypadku open source'a można założyć, że różne ludzie różne silniki zaadoptują do kodu aplikacji, którą potem wystarczy skonfigurować przed załadowaniem do układu.

4. Pytanie zasadnicze w tym momecie pojawia się takie: Chcesz mieć kod działający na istniejących konstrukcjach PCB, czy zaprojektować własną (kolejna bariera inżynierska - czas i koszty). Jeśli opcja pierwsza, to pojawi się problem dostosowywania projektu do różnych platform sprzętowych (patrz: Linux i złożoność zależności międzyplatformowych). Jeśli opcja druga - jak dostosować projekt PCB do różnych wyprowadzeń czujników i wyjść sterujących (nie wiem, czy wymagają dopasowania "analogowego"). Przy "mocnym" mikrokontrolerze, wyjścia są dość konfigurowalne, ale to podnosi koszty urządzenia nieadekwatnie do pełnionej roli (chyba, że chcesz mieć w jednym aucie przełączalne programy, np. "city", "semi-sport", "extreme" różniące się stosunkiem mocy do spalanie, itp.)

5. Wracając do sterowników producentów. Modyfikacje kodu, nawet na poziomie assemblera "hackują" istniejącą funkcjonalność, która wymaga testowania tylko tego, co zmienione zostało. Reszta działa, jak producent zaprojektował (to jak z hackowaniem komórek, zmieniasz interfejs użytkownika, ale kod modemu GSM nie jest zmieniany). Spora część ECU do "zachipowania" wymaga tylko przeładowania map i sum kontrolnych (o ile wiem, w wielu dieslach da się tak tuningować). Część wymaga większej rzeźby, ale nadal na istniejącym i przetestowanym kodzie - w przypadku porażki wracasz do oryginału.

6. Producent ECU wpakował ileś kasy w laboratorium i inżynierów, którzy opracowali taki moduł sterujący. Taka praca w zespole z odpowiednimi narzędziami wygląda zupełnie inaczej, niż robienie otwartego projektu sumptem uczestników "z całego świata".

Podsumowując: Projekt taki jest realizowalny, jednak przy sporych nakładach czasu i kasy. Sugeruję rozpocząć od wybrania jednego modelu samochodu i podjęcia próby zbudowania sterownika do jego opcji silnikowych. Gdy to się powiedzie, można myśleć o dalszych krokach. Projekt jako całość nie musi oznaczać istnienia jednego urządzenia o wspólnym kodzie, ale wiele podprojektów.

Mam kolegę, który na pracę inżynierską wykonał system kontroli trakcji do każdego auta posiadającego ABS. Robili testy tego urządzenia i okazało się, że działa lepiej niż oryginalna kontrola trakcji w Hondzie. Przy czym on miał dostęp do zaplecza, samochodów i sporej wiedzy kilku osób (przywilej pracy w firmie tuningowej).

Ludzi, którzy chętnie takie wyzwanie by podjęli (np. w firmach od tuningu) jest pewnie sporo, więc można warto spróbować z konkretnym samochodem (dlaczego nie Fiat). Trzeba się natomiast poważnie zastanowić, co jest potrzebne by zacząć.

> Myślę nad wystartowaniem otwartego projektu sterownika kontrolującego

> pracę silnika.

> Komputer byłby przewidziany do modyfikowanych silników i powinien

> umożliwiać łatwe dostrajanie sterowania do robionych modów.

> Wiele osób na tym forum robi mody i jestem ciekaw waszej opinii. Czy

> warto w coś takiego wchodzić ( czy jest realne zapotrzebowanie).

> Czy też w zupełności wystarczają modyfikacje softu dla już

> istniejących sterowników ( jak są one robione? bo jak rozumiem

> dostępu do kodu źródłowego nie ma).

> Nie myślę tutaj o projekcie komercyjnym, nie musi to przynieść zysku

> ani nawet zwrócić kosztów. Interesuje mnie bardziej to czy

> będzie wystarczające zainteresowanie i ktoś chętny żeby projekt

> nie umarł śmiercią naturalną

na rynku jest kilka takich produktów zaczynając od Vemona i MS a skończywszy na klonach MM więc można spokojnie czymś się posiłkować.

Kod źródłowy znaczy sie wsady z Epromów i procesorów motorolli są dostępne dla osób które je zgrały, kompletna informacja o instrukcjach jest niedostępna.

Zgadzam się z kolegą w 100% .

Ze swojej strony mogę tylko dodać, ponieważ aktualnie pracuje nad poruszonym tematem, że najprostszym rozwiązaniem byłoby użycie już gotowego ECU od jakiegoś auta. Nie wiem jak jest z innymi producentami ale wcześniejsze modele MM, są w miare "prostym" układem ze względu na zastosowany mikroprocesor. DO 68HC11 jest sporo dokumentacji i programów.

Drugim krokiem jest wybór modelu - tu już jest problem ECU od 1.1 mają tą przewagę że oprogramowanie jest mniej skomplikowane, więc łatwiejsze do "rozgryzienia".

Natomiast ECU od 1.2 mają niewątpliwą zaletę w postaci wbudowanej dodatkowej pamięci SRAM, przez co można tam umieścić wiekszość map i modyfikować je w trakcie jazdy, bez żadnej ingerencji w hardware.

To tyle w sprawie hardware-u.

W przypadku kodu, również wydaje mi się że praca od podstaw, jakkolwiek dająca więcej satysfakcji, jednak w przypadku tak skomplikowanego problemu ( możliwe uszkodzenie silnika ), lepiej probować modyfikować wedle własnych potrzeb kod już sprawdzony i napisany przez specjalistów.

Ponieważ w tym temacie mam tylko doświadczenie teoretyczne, jednak wydaje mi się, że docelowo mając na myśli programowalny, chodzi o to że elementy wykonawcze ( cewki , wtrysk , krokowiec ) pracują zgodnie z naszą wolą a ECU traci nad nimi kontrolę.

Oprogramowanie możemy podzielić na osobne "moduły", jeden z nich oblicza wartości ( czas wtrysku , zapłon itp... ) na podstawie parametrów pracy silnika, następnie te wartości są wykorzystywane przez moduł bezpośrednio sterujący tymi urządzeniami, który oprócz dążenia aby rzeczywiste czasy odpowiadały tym "pożądanym", również weryfikuje czy wszystkie komponenty pracują prawidłowo i jest odporny nawet na błędne wyliczenia czasów.

Z naszego punktu widzenia, wystarczy podjąć działanie na styku tych modułów, w momencie kiedy wyliczony jest np. czas wtrysku, podmieniamy tą wartość na taką jaką chcemy i dalej to już software fabryczny zadba żeby wtrysk pracował jak chcemy.

Na takiej samej zasadzie można postąpić z pozostałymi komponentami ( cewki, krokowiec ). Wydaje mi się że są to jedyne elementy które sterują pracą silnika, dzięki temu możemy przejąć nad nim całkowitą kontrole, pozostawiając całość popranego kodu fabrycznego.

Oczywiście do własnych wyliczeń możemy używać wartości liczonych na bieżąco przez ECU, jak charakterystyki zmian położenia przepustnicy, wyliczenia współczynnika lambda itp...

Co ważniejsze w przypadku 1.1 nie jest to tak mocno skomplikowane, na dzień dzisiejszy byłbym już w stanie przeprowadzić w/w modyfikacje samodzielnie aczkolwiek spędziłem nad kodem sporo czasu, więc naprawdę nie jest to takie trudne a w przypadku większej ilości osób czasowo też źle być nie powinno.

Kolejnym poruszonym tematem jest "uniwersalnośc" takiego rozwiązania. W moich poprzednich wątkach ( o czujniki temperatury ), widać że wartości nie są wpisane na sztywno, za pomocą 2 map można dopasować się do czujnika z dowolną charakterystyką.

Ogólnie wydaje mi się że każdy silnik ( oczywiście po modyfikacji map) używający takich samych elementów ( iat , water , map , tps , lambda , GMP 60 zebów , 2 cewki , 1 wtrysk ) może zostać obsłużony przez ten komputer, i dodatkowo może się obejśc bez paru z nich. Konieczne są jedynie cewki i przede wszystkim czujnik GMP o takiej samej ilości zębów. MAP też by się przydał. Jedyne dosyć istotne ograniczenie to chyba tylko brak obsługi sekwencji.

Jak by spojrzeć na wymagania to większość silników jest w stanie je spełnić.

To chyba tyle ode mnie, mam nadzieje ze trochę pomogłem

Pozdrawiam

Może bardziej sie znam na systemach GNU niz mapach paliwa i zapłonu wrzucanych na epromy i motorole ,ale widziałem kiedyś koles miał Toyote Supre i podpietego laptopa z mapami paliwa i napisany program który miał interfejs użytkownika miał tam kilka różnych map strojonych na hamowni z analizatorem spalin itp auto było doładowane miało cos około 600kM po kilku godzinach zabaw na parkingu i torze silnik explodował w skutek błędu w mapie ,cos z cisnieniem doładowania koleś miał niefajną mine po tej zabawie ale jak dla mnie i tak super można sobie było pokombinowac z softem z poziomu "kierowcy" napewno warto sie w to bawić!!!

> silnik explodował w skutek błędu w mapie

> ,cos z cisnieniem doładowania koleś miał niefajną mine po tej

> zabawie

No właśnie to jest główny argument za pozostaniem przy kodzie fabrycznym, bo ten kod próbuje chociaż korygować podawane wartości jeżeli są dalekie od akceptowalnych, a bez takich korekcji jak się ustawi chociażby wtrysk w czasie zapłonu przy otwartym zaworze to to zostanie wykonane...( a wydaje mi się że to nie będzie przyjemne dla silnika )

> No właśnie to jest główny argument za pozostaniem przy kodzie

> fabrycznym, bo ten kod próbuje chociaż korygować podawane

> wartości jeżeli są dalekie od akceptowalnych, a bez takich

> korekcji jak się ustawi chociażby wtrysk w czasie zapłonu przy

> otwartym zaworze to to zostanie wykonane...( a wydaje mi się że

> to nie będzie przyjemne dla silnika )

Jak dla mnie ktoś kto potrafi zmieniać mapy zapłonów jest mistrzem szacun

> Jak dla mnie ktoś kto potrafi zmieniać mapy zapłonów jest mistrzem

> szacun

Eh, ECU to prymitywny komputer (takie bardziej zaawansowane ZX Spectrum) tylko ma wiele interesujących wyprowadzeń po których gada ze wszystkimi elementami silnika. Problem zagrzebania czegokolwiek (jeżeli da się zczytać EPROMY) to tylko i wyłącznie kwestia czasu spędzonego na debugowaniu kodu maszynowego. Przeciętny student po automatyce powinien dać radę intelektualnie. No i do tego troszkę akcesoriów, żeby się do kompa zapiąć.

Btw. kod w tych komputerkach nie jest zafusowany przed odczytem?

> Btw. kod w tych komputerkach nie jest zafusowany przed odczytem?

W starych MM nie, bo pamięć to zwykły EPROM

W niektórych nowych trochę inaczej to wygląda

> W starych MM nie, bo pamięć to zwykły EPROM

> W niektórych nowych trochę inaczej to wygląda

Czyli na kompie jest napisane "POGRZEB WE MNIE!"

> Czyli na kompie jest napisane "POGRZEB WE MNIE!"

Lepiej bym tego nie określił