Nowy program IAW Scan 2

[tzok]

Postanowiłem od nowa napisać IAW ECU Scan, jak mi nie zabraknie motywacji, chęci i czasu to może mi się uda. Na razie jest tylko demo (bez komunikacji z samochodem), które można pobrać tutaj:

http://chomikuj.pl/tzok/IAW+Scan+2/IES_2,963840816.exe

[ignac2004]

Można zmienić language na polish?

[Matts]

Oooo, super, przewidujesz jakieś nowości? Może jakieś opcje strojenia małe

[tzok]

> Oooo, super, przewidujesz jakieś nowości? Może jakieś opcje strojenia małe

W sterownikach które taką możliwość przewidują - tak, ale IAW-16F FASE2 do nich nie należy.

[tzok]

> Można zmienić language na polish?

Językiem podstawowym jest i będzie angielski ale przewiduję możliwość lokalizacji.

[fendt180]

Musisz zapodac te nowosci o ktorych gadalismy

[Lynda]

o, trochę do FES'a się upodobnił

[tzok]

> o, trochę do FES'a się upodobnił

Główna zmiana to możliwość wybierania parametrów o które ma być odpytywane ECU, co znacznie przyspieszy częstość ich odświeżania. Na pewno zniknie część opcji - m.in. wirtualna deska rozdzielcza, wykres w oknie parametrów i prawdopodobnie autodetekcja sterownika.

Jeśli chodzi o stronę programową to tym razem każdy sterownik to osobna klasa, więc łatwiej można będzie dodawać obsługę innych sterowników.

[tzok]

Nowa wersja - jest już komunikacja z ECU:

http://chomikuj.pl/tzok/IAW+Scan+2/Release,966333289.zip

[andre44]

a co trzeba miec zeby sie polaczyc z ECU ??:D

[tzok]

> a co trzeba miec zeby sie polaczyc z ECU ??:D

Kabelek VAG-COM USB z przejściówką FIAT 3-pin, zrezygnowałem z obsługi interfejsu mojego autorstwa.

[andre44]

a dlaczego zrezygnowales?? cos z programem nie tak??

a potrzeba takie kabelki ??

http://allegro.pl/kabel-interfejs-vag-com-409-1-vw-seat-audi-usb-i1778093177.html

http://allegro.pl/fiat-przejsciowka-adapter-obd2-na-obd1-3pin-i1736770651.html

[tzok]

> a dlaczego zrezygnowales?? cos z programem nie tak??

> a potrzeba takie kabelki ??

> http://allegro.pl/kabel-interfejs-vag-com-409-1-vw-seat-audi-usb-i1778093177.html

> http://allegro.pl/fiat-przejsciowka-adapter-obd2-na-obd1-3pin-i1736770651.html

Dokładnie taki zestaw, a zrezygnowałem dlatego, że chyba jedyny działający egzemplarz tamtego interfejsu posiadałem ja a jest to dodatkowy warunek do sprawdzania przy każdym przejściu pętli lub konieczność pisania osobnego kodu komunikacyjnego dla każdego interfejsów.

[tzok]

Zapraszam do testów wersji 0.1 - na razie tylko IAW-16F, ale powinien być "nieco" stabilniejszy i szybszy. Nie ma jeszcze wykresów, logów i adaptacji ale za to jest od nowa przepisany kod odpowiadający za komunikację, nowy interfejs oraz możliwość łatwej rozbudowy o kolejne ECU bazujące na tym samym protokole komunikacyjnym.

http://sourceforge.net/projects/iaw-scan2/files/Bin/Release.zip/download

[tzok]

W chwili obecnej program ma już nieco większe możliwości niż stary IAW ECU Scan.

Jest m.in. odczyt napięcia sondy lambda w sterowniku IAW-18FD, są dynamicznie skalowane wykresy, logi dynamiczne, jest możliwość wyboru odpytywanych parametrów co gwarantuje maksymalną szybkość odświeżania parametrów.

Zapraszam do pobierania i testowania:

http://sourceforge.net/projects/iaw-scan2/

[woj76]

> W chwili obecnej program ma już nieco większe możliwości niż stary IAW ECU Scan.

> Jest m.in. odczyt napięcia sondy lambda w sterowniku IAW-18FD, są dynamicznie skalowane wykresy,

> logi dynamiczne, jest możliwość wyboru odpytywanych parametrów co gwarantuje maksymalną

> szybkość odświeżania parametrów.

> Zapraszam do pobierania i testowania:

> http://sourceforge.net/projects/iaw-scan2/

Akurat miałem właśnie okazję go odpalić (po raz pierwszy wogóle zresztą). Zasadniczo wszystko jest git, ale mam takie uwagi:

1. ECU in Virgin state nie nazwałbym błędem. Jest to po prostu status układu immo i nie ma w tym nic złego. Natomiast komunikat, że centralki nie wykrył itd itp to już będzie IMO error.

2. Gadaliśmy o tym wcześniej, pytałeś o różne rzeczy z tym związane. Wg. mnie odświeżanie jest grubo za wolne. Wybrałem dwa parametry razem trzy bajty i było mało ciekawie. Mój prywatny program napisany w Javie, działający pod Linuxem i korzystający z biblioteki do komunikacji ulepionej przeze mnie w C działa zdecydowanie szybciej. Moduł diagnostyczny do TuneraPro RR, który zrobiłem (znajdziesz w "Tajemnicach ECU") też sobie lepiej radzi. W każdym razie coś jest tutaj nie tak, na pewno powinno dać się szybciej

3. Wywalił mi się program przy wyjściu, ale nie wnikałem co się stało.

4. Podobały mi się bardzo piktogramy w pierwszej wersji programu, trochę ich szkoda.

Aha, sterownik 18F mojej roboty z rozszerzeniami.

[tzok]

> Akurat miałem właśnie okazję go odpalić (po raz pierwszy wogóle zresztą). Zasadniczo wszystko jest

> git, ale mam takie uwagi:

> 1. ECU in Virgin state nie nazwałbym błędem. Jest to po prostu status układu immo i nie ma w tym

> nic złego. Natomiast komunikat, że centralki nie wykrył itd itp to już będzie IMO error.

W/g dokumentacji formalnie jest to błąd, przynajmniej w 8F, w 6F niby jest to słowo statusowe, ale z kolei reszta flag z tego słowa to już raczej błędy. Nie chciałem rozdzielać jednego słowa między status i błędy.

> 2. Gadaliśmy o tym wcześniej, pytałeś o różne rzeczy z tym związane. Wg. mnie odświeżanie jest

> grubo za wolne. Wybrałem dwa parametry razem trzy bajty i było mało ciekawie. Mój prywatny

> program napisany w Javie, działający pod Linuxem i korzystający z biblioteki do komunikacji

> ulepionej przeze mnie w C działa zdecydowanie szybciej. Moduł diagnostyczny do TuneraPro RR,

> który zrobiłem (znajdziesz w "Tajemnicach ECU") też sobie lepiej radzi. W każdym razie coś

> jest tutaj nie tak, na pewno powinno dać się szybciej

Dziwne, bo u mnie na 16F jest na prawdę szybko, 18F ma sporo flag błędów a one są odpytywane co 4'te przejście pętli. Być może Twoja centralka po modyfikacjach nie odpowiada na któreś z zapytań o słowa statusowe/flagi błędów i w tym momencie wisi 300ms na tym zapytaniu.

> 3. Wywalił mi się program przy wyjściu, ale nie wnikałem co się stało.

Szkoda, bo już miałem nadzieję, że rozwiązałem problemy z IAW ECU Scan z odpalaniem zdarzenia po zamknięciu portu.

> 4. Podobały mi się bardzo piktogramy w pierwszej wersji programu, trochę ich szkoda.

Piktogramy były wzorowane na programie VISA (Euroscan), ale trochę niewygodne w implementacji, tym razem wzorowałem się na Fiat ECU Scanie.

> Aha, sterownik 18F mojej roboty z rozszerzeniami.

Po modyfikacjach odpowiada na wszystkie pytania tak jak oryginalny, czy coś wyciąłeś? W programie "na sztywno" odpytywane są następujące pola:

0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x39, 0x3A, 0x3B, 0x3C, 0x3D, 0x3E, 0x40, 0x41, 0x42, 0x43, 0x44, 0x45, 0x71, 0x72

[woj76]

> W/g dokumentacji formalnie jest to błąd, przynajmniej w 8F, w 6F niby jest to słowo statusowe, ale

> z kolei reszta flag z tego słowa to już raczej błędy. Nie chciałem rozdzielać jednego słowa

> między status i błędy.

Podejrzewam, że w 8/18F nie przewidzieli już setup-u bez immo, stąd ta różnica. Podzielam Twoje rozumowanie, chodziło mi głównie o to, że dla co poniektórych użytkowników może być to mylące. I jeszcze polecą z tym do ASO w panice

> Dziwne, bo u mnie na 16F jest na prawdę szybko, 18F ma sporo flag błędów a one są odpytywane co

> 4'te przejście pętli. Być może Twoja centralka po modyfikacjach nie odpowiada na któreś z

> zapytań o słowa statusowe/flagi błędów i w tym momencie wisi 300ms na tym zapytaniu.

> Po modyfikacjach odpowiada na wszystkie pytania tak jak oryginalny, czy coś wyciąłeś? W programie

> "na sztywno" odpytywane są następujące pola:

> 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x39, 0x3A, 0x3B, 0x3C, 0x3D, 0x3E, 0x40, 0x41, 0x42, 0x43,

> 0x44, 0x45, 0x71, 0x72

>

Mój ECU odpowiada na wszystkie standardowe zapytania, ma tylko dopisanych parę pozycji w "pustych" miejscach, m.in. do odczytu O2 i nadciśnieniowej wartości MAP sensora. Tych rejestrów błędów nie ma aż tyle, żeby tak to spowolnić. Obejrzałem ten Twój filmik i drugi też co się pojawił i prędkość jest mniej więcej taka jaką miałem dzisiaj. Jak mi się uda to spróbuję zrobić filmiki swojego i Twojego programu, ale nie prędzej niż w niedzielę Będziesz mógł porównać, bo może się mylę.

[tzok]

> Podejrzewam, że w 8/18F nie przewidzieli już setup-u bez immo, stąd ta różnica. Podzielam Twoje

> rozumowanie, chodziło mi głównie o to, że dla co poniektórych użytkowników może być to mylące.

> I jeszcze polecą z tym do ASO w panice

> Mój ECU odpowiada na wszystkie standardowe zapytania, ma tylko dopisanych parę pozycji w "pustych"

> miejscach, m.in. do odczytu O2 i nadciśnieniowej wartości MAP sensora. Tych rejestrów błędów

> nie ma aż tyle, żeby tak to spowolnić. Obejrzałem ten Twój filmik i drugi też co się pojawił i

> prędkość jest mniej więcej taka jaką miałem dzisiaj. Jak mi się uda to spróbuję zrobić filmiki

> swojego i Twojego programu, ale nie prędzej niż w niedzielę Będziesz mógł porównać, bo może

> się mylę.

Mam dodane, może niepotrzebnie, 4ms opóźnienie po odebraniu każdej odpowiedzi.

[woj76]

Tutaj mój reader w akcji, polecam HD + fullscreen jeżeli masz wydolny sprzęt :

[tzok]

> Tutaj mój reader w akcji, polecam HD + fullscreen jeżeli masz wydolny sprzęt :

Szybko ale kosztem jakiego obciążenia CPU? Ja odświeżam ekran po odpytaniu całej puli (aktualnie wybranych) parametrów, a nie po każdym zapytaniu. Poza tym C# 2.0 do najszybszych nie należy, a już komponent DataGridView zwłaszcza, do tego wszystkie funkcje dekodujące wartości wywoływane są przez delegaty.

[woj76]

> Szybko ale kosztem jakiego obciążenia CPU?

W trybie demo, który odświeża ekran znacznie szybciej ("emulacja" portu bez przestojów komunikacyjnych, ale z czekaniem między komendami) łącznie jakieś 60% jednego rdzenia przy włączonych 8 kontrolkach. Czy to dużo czy mało to nie wiem, ale reszta systemu przez to nie cierpi. Jakbym wyłączył te pasko-progres-bary było by znacznie mniej. TunerPro działający w wirtualnym Windowsie zapewnia podobną prędkość i też daje się całego (zasadniczo dwóch naraz) systemu używać bez problemu.

Ja odświeżam ekran po odpytaniu całej puli (aktualnie

> wybranych) parametrów, a nie po każdym zapytaniu. Poza tym C# 2.0 do najszybszych nie należy,

> a już komponent DataGridView zwłaszcza, do tego wszystkie funkcje dekodujące wartości

> wywoływane są przez delegaty.

Może pora zastanowić się nad zmianą środowiska?

[tzok]

> Może pora zastanowić się nad zmianą środowiska?

Chodziło o zgodność z .NET 2.0 dla zachowania kompatybilności z Windows 2000. FES wcale szybciej nie działa. 60% obciążenia CPU to w/g mnie jest bardzo dużo, mi zależało żeby problem działał na sprzęcie klasy Pentium 3. Przy przyjętej przeze mnie architekturze nie potrafię sensownie powiązać odświeżania konkretnego parametru z otrzymaniem odpowiedzi na jakieś żądanie (trzeba przeszukać całą tablicę).

Znalazłem buga parametry odświeżały się raz na 3 przejścia pętli. W złym miejscu wstawiłem "wyzwalacz".

[woj76]

> Chodziło o zgodność z .NET 2.0 dla zachowania kompatybilności z Windows 2000. FES wcale szybciej

> nie działa. 60% obciążenia CPU to w/g mnie jest bardzo dużo, mi zależało żeby problem działał

> na sprzęcie klasy Pentium 3.

Ma to sens, z tym, że pisałem, że jest to tryb demo, który bardzo męczy okienko. Do tego mam różne gadżety i wodotryski w mendżerze okien, przez które to musi przejść. Podejrzewam, że normalnie nie jest to więcej niż 40% na jednym rdzeniu, co oznacza w praktyce 20-30% obciążenie całego kompa. Biorąc do tego pod uwagę, że jak robisz diagnostykę to jest to zazwyczaj Twoje główne zadanie, to sobiście nie widzę problemu. Aczkowlwiek na PIII faktycznie byłoby słabo.

Przy przyjętej przeze mnie architekturze nie potrafię sensownie

> powiązać odświeżania konkretnego parametru z otrzymaniem odpowiedzi na jakieś żądanie (trzeba

> przeszukać całą tablicę).

Nie wiem czy Ci to coś pomoże, ale u mnie jest to rozwiązane tak, że mam jeden wątek, który szaleńczo czyta dane z interfejsu i ma tablicę do poszczególnych obiektów widgetów, w których to ma być wyświetlone. Znaczy się, jak przypływa odpowiedź to jest pod ręką już obiekt, do którego to ma być wysłane. Widgety to dostają i zmartwiniem dispatcher-a od biblioteki Swing jest nadążanie z wyświetlaniem tego wszystkiego, jak nie daje rady, to zjada to z czym nie nadąży. A że ten dispatcher jest w miarę sensownie napisany, to jakoś to wszystko daje radę.

[tzok]

> Ma to sens, z tym, że pisałem, że jest to tryb demo, który bardzo męczy okienko. Do tego mam różne

> gadżety i wodotryski w mendżerze okien, przez które to musi przejść. Podejrzewam, że normalnie

> nie jest to więcej niż 40% na jednym rdzeniu, co oznacza w praktyce 20-30% obciążenie całego

> kompa. Biorąc do tego pod uwagę, że jak robisz diagnostykę to jest to zazwyczaj Twoje główne

> zadanie, to sobiście nie widzę problemu. Aczkowlwiek na PIII faktycznie byłoby słabo.

> Przy przyjętej przeze mnie architekturze nie potrafię sensownie

> Nie wiem czy Ci to coś pomoże, ale u mnie jest to rozwiązane tak, że mam jeden wątek, który

> szaleńczo czyta dane z interfejsu i ma tablicę do poszczególnych obiektów widgetów, w których

> to ma być wyświetlone. Znaczy się, jak przypływa odpowiedź to jest pod ręką już obiekt, do

> którego to ma być wysłane. Widgety to dostają i zmartwiniem dispatcher-a od biblioteki Swing

> jest nadążanie z wyświetlaniem tego wszystkiego, jak nie daje rady, to zjada to z czym nie

> nadąży. A że ten dispatcher jest w miarę sensownie napisany, to jakoś to wszystko daje radę.

Po przemyśleniu doszedłem do wniosku, że przecież nie ma znaczenia czy będę odświeżał parametry pojedynczo bezpośrednio po otrzymaniu odpowiedzi go dotyczącej czy hurtem po otrzymaniu odpowiedzi na wszystkie odpytywane parametry - średnia częstość odświeżania musi być w obu przypadkach mniej więcej taka sama (nawet na korzyść "hurtowego" odświeżania).

U mnie wątek działający w tle odpytuje ECU o wybrane parametry (3x cała pula) a następnie o błędy silnika i błędy immo. Po odpytaniu każdego zestawu jest generowane zdarzenie z odpowiednim parametrem, które powoduje odświeżenie właściwego bloku danych (parametry, błędy ecu, błędy immo) na ekranie.

Błąd był tylko w tym, że pomieszały mi się klamry i parametry były odświeżane raz na 3 odpytania ECU, czyli po usunięciu buga, odświeżają się 3x szybciej.

Obciążenie CPU jest na poziomie 3%, tylko okresowo są "piki" na ok 45% spowodowane aktywnością Garbage Collectora.

[woj76]

> U mnie wątek działający w tle odpytuje ECU o wybrane parametry (3x cała pula) a następnie o błędy

> silnika i błędy immo.

Wg. mnie odpytanie immo wystarczy zrobić raz po inicjalizacji. Tak układ immo zresztą w programie działa, raz odpytuje centralkę i jest po frytkach, choć tego nigdy nie sprawdzałem. Wydaje mi się, że jakbyś odłączył centralkę po odpaleniu silnika, to status immo i tak się nie zmieni (jest to niezbędne ze względów bezpieczeństwa). Co do błędów, to po co tak na prawdę je odpytujesz razem z resztą parametrów? Przecież i tak zakładka błędów jest niewidoczna i viceversa, jak masz błędy na ekranie to nie widać pracy parametrów. Zrób po prostu tak, jak ja, odpytaj błędy raz po inicjalizacji, załóż event-a na zmianę zakładek, i przy wygaszaniu pierwszej zakładki i aktywacji drugiej pauzuj zczytywanie parametrów i zacznij zczytywać błędy (raz, albo ciągle, jak uważasz). W sytuacji odwrotnej zapomnij o błędach i wznów zczytywanie parametrów. I jesteś w domu Przy testach i tak musisz wyłączyć zczytywanie czegokolwiek, więc pewnie patent na to w programie już jest.

> Po odpytaniu każdego zestawu jest generowane zdarzenie z odpowiednim

> parametrem, które powoduje odświeżenie właściwego bloku danych (parametry, błędy ecu, błędy

> immo) na ekranie.

> Błąd był tylko w tym, że pomieszały mi się klamry i parametry były odświeżane raz na 3 odpytania

> ECU, czyli po usunięciu buga, odświeżają się 3x szybciej.

> Obciążenie CPU jest na poziomie 3%, tylko okresowo są "piki" na ok 45% spowodowane aktywnością

> Garbage Collectora.

A z GC też daje się rozwiązać sprawę do pewnego stopnia, ale jest to już trudniejsze. Trzeba napisać tą całą główną pętlę tak, żeby nie generowała "śmieci" tylko używała obiekty w "cyklu zamkniętym", wtedy GC nie powinien mieć nic do roboty. W Javie w każdym razie tak się da, ale nie zawsze jest to proste (nie można np. rzecz jasna zmienić procedur bibliotecznych, żeby nie generowały śmieci).

[tzok]

> Wg. mnie odpytanie immo wystarczy zrobić raz po inicjalizacji. Tak układ immo zresztą w programie

> działa, raz odpytuje centralkę i jest po frytkach, choć tego nigdy nie sprawdzałem. Wydaje mi

> się, że jakbyś odłączył centralkę po odpaleniu silnika, to status immo i tak się nie zmieni

> (jest to niezbędne ze względów bezpieczeństwa).

Możliwe, ale to w końcu tylko dwa bajty... z drugiej strony kontrolka CODE potrafi się zapalić w trakcie jazdy. VISA też odpytuje o te kody cyklicznie (sprawdzałem).

> Co do błędów, to po co tak na prawdę je

> odpytujesz razem z resztą parametrów? Przecież i tak zakładka błędów jest niewidoczna i

> viceversa, jak masz błędy na ekranie to nie widać pracy parametrów.

Na potrzeby logu tworzonego w tle i tylko po to.

> Zrób po prostu tak, jak

> ja, odpytaj błędy raz po inicjalizacji, załóż event-a na zmianę zakładek, i przy wygaszaniu

> pierwszej zakładki i aktywacji drugiej pauzuj zczytywanie parametrów i zacznij zczytywać błędy

> (raz, albo ciągle, jak uważasz). W sytuacji odwrotnej zapomnij o błędach i wznów zczytywanie

> parametrów. I jesteś w domu Przy testach i tak musisz wyłączyć zczytywanie czegokolwiek, więc

> pewnie patent na to w programie już jest.

Poniekąd tak było w IAW ECU Scan, tyle że dotyczyło to wyłącznie dekodowania, pula zapytań była tam stała i nie mogła się w ogóle zmieniać w trakcie połączenia. Zresztą były ikonki więc trzeba było odpytywać ECU o flagi błędów i stanu, by je obsługiwać.

> A z GC też daje się rozwiązać sprawę do pewnego stopnia, ale jest to już trudniejsze. Trzeba

> napisać tą całą główną pętlę tak, żeby nie generowała "śmieci" tylko używała obiekty w "cyklu

> zamkniętym", wtedy GC nie powinien mieć nic do roboty. W Javie w każdym razie tak się da, ale

> nie zawsze jest to proste (nie można np. rzecz jasna zmienić procedur bibliotecznych, żeby nie

> generowały śmieci).

W tym przypadku to jest nierealne pisząc program pod jedno konkretne ECU może dałoby się to jakoś ogarnąć. Procedury obsługi zdarzeń tworzą własne zmienne lokalne, funkcje zwracają obiekty. Bardziej zależało mi na ładnym i czytelnym kodzie - każde ECU to jest osobna klasa (wraz ze wszystkimi procedurami dekodowania parametrów i błędów oraz ich opisami), jest też nadrzędna klasa abstrakcyjna po której dziedziczą wszystkie ECU. Pewnie można to było zrobić jeszcze lepiej, ale ja zrobiłem najlepiej jak potrafiłem, rozdzielając GUI od implementacji ECU, niestety nie do końca udało mi się oddzielić warstwę komunikacji od GUI.

[woj76]

> Możliwe, ale to w końcu tylko dwa bajty... z drugiej strony kontrolka CODE potrafi się zapalić w

> trakcie jazdy. VISA też odpytuje o te kody cyklicznie (sprawdzałem).

Może niech mnie ktoś poprawi, bo z immo mam małe doświadczenie i może błądzę, ale kontrolkę CODE zapala centralka IMMO, a nie ECU. Więc w ECU i tak nie będzie zmiany żadnej, dopiero przy następnym odpalaniu. W tym przypadku to jest nierealne pisząc program pod jedno konkretne ECU może dałoby się to jakoś

> ogarnąć. Procedury obsługi zdarzeń tworzą własne zmienne lokalne, funkcje zwracają obiekty.

> Bardziej zależało mi na ładnym i czytelnym kodzie - każde ECU to jest osobna klasa (wraz ze

> wszystkimi procedurami dekodowania parametrów i błędów oraz ich opisami), jest też nadrzędna

> klasa abstrakcyjna po której dziedziczą wszystkie ECU. Pewnie można to było zrobić jeszcze

> lepiej, ale ja zrobiłem najlepiej jak potrafiłem, rozdzielając GUI od implementacji ECU,

> niestety nie do końca udało mi się oddzielić warstwę komunikacji od GUI.

Z pisaniem bardzo "pięknych" programów dałem sobie siana już jakiś czas temu. Piszę je zazwyczaj tak, żeby łatwo było mi je adaptować potem do potrzeb i rzeczy, które jestem w stanie przewidzieć jeszcze w czasie pisania. Potem i tak się okazuje, że w końcu trzeba coś mocno przebudować, takie życie programisty

[tzok]

> Może niech mnie ktoś poprawi, bo z immo mam małe doświadczenie i może błądzę, ale kontrolkę CODE

> zapala centralka IMMO, a nie ECU. Więc w ECU i tak nie będzie zmiany żadnej, dopiero przy

> następnym odpalaniu.

To racja - kontrolkę zaświeca centralka CODE, ale nie mam jak sprawdzić czy ECU ma ciągłą komunikację z centralką CODE czy tylko w momencie inicjalizacji. Zauważyłem niestety jeden problem - w czasie gdy świeci się kontrolka MIL po wyjściu z trybu aktywnej diagnostyki centralka potrafi zwracać losowe błędy, w zasadzie to nawet nie losowe a wszystkie słowa flag błędów są przez chwilę ustawione na FxFF.

> Z pisaniem bardzo "pięknych" programów dałem sobie siana już jakiś czas temu. Piszę je zazwyczaj

> tak, żeby łatwo było mi je adaptować potem do potrzeb i rzeczy, które jestem w stanie

> przewidzieć jeszcze w czasie pisania. Potem i tak się okazuje, że w końcu trzeba coś mocno

> przebudować, takie życie programisty

Właśnie po to starałem się ładnie pisać, żeby dało się łatwo modyfikować.

[tzok]

Kilka screenów na zachętę:

http://sourceforge.net/projects/iaw-scan2/

[kobra180]

Wygląda to coraz lepiej . Współpraca z Jani przynosi efekty w obie strony . Gratulacje

[tzok]

> Wygląda to coraz lepiej . Współpraca z Jani przynosi efekty w obie strony . Gratulacje

Tu akurat żadnej współpracy z Yanim nie było, poza odgapieniem layoutu jego programu jego czynna współpraca to dostarczenie dokumentacji do jednego ze sterowników.

[j2kyller]

mister tzok

sterownik 8F

co oznacza podczas proby testu komunikat BLAD INICJ.

jak powinna wygadac procedura czyszczenia błedów,?

thanks from the mountain

za ewentualne wyjasnienia

[tzok]

> mister tzok

> sterownik 8F

> co oznacza podczas proby testu komunikat BLAD INICJ.

> jak powinna wygadac procedura czyszczenia błedów,?

> thanks from the mountain

> za ewentualne wyjasnienia

Błąd Inicjacji oznacza niewłaściwe warunki do zainicjowania trybu aktywnej diagnostyki (np. uruchomiony silnik).

Czyszczenie błędów powinno wyglądać tak, że klika się [Wyczyść] i... już. Silnik powinien być wyłączony, a żaden błąd nie powinien być aktywny (choć nie jest to warunek konieczny).

[muchasso]

Witam, nowy program sprawuje sie dobrze, ale że jestem laikiem w dziedzinie diagnostyki to brakuje mi nim paru rzeczy które by "niedzielnym" diagnostą ułatwiłby trochę życie.

1. Tekst pomocy powinien znajdować sie w osobnej zakładce obok ustawień bo w obecnej formie jest mało czytelny .

2.Fajnie jakby w zakładkach bledy/testy były jakieś powiadomienia np. przed kasacja błędów wyłącz silnik albo jak wyżej wspomniany błąd inicjalizacji.

3 . Przy parametrach przydała by się jeszcze jedna kolumna z wartościami poprawnymi, fabrycznymi dla danych parametrów.

I na koniec mam jeszcze pytanie który to jest przekaźnik główny w Seicento SPI chodzi o przekaźnik systemu wtryskowego

[tzok]

> Witam, nowy program sprawuje sie dobrze, ale że jestem laikiem w dziedzinie diagnostyki to brakuje

> mi nim paru rzeczy które by "niedzielnym" diagnostą ułatwiłby trochę życie.

Jestem przeciwny używaniu programu przez niedzielnych diagnostów, najpierw trzeba się znać na mechanice i elektryce, a dopiero potem brać się za diagnostykę.

> 1. Tekst pomocy powinien znajdować sie w osobnej zakładce obok ustawień bo w obecnej formie jest

> mało czytelny .

Tekst pomocy to tylko zapełniacz miejsca, miało go w ogóle nie być - jak się powiększy okno będzie bardziej czytelny.

> 2.Fajnie jakby w zakładkach bledy/testy były jakieś powiadomienia np. przed kasacja błędów wyłącz

> silnik albo jak wyżej wspomniany błąd inicjalizacji.

Nie mam samochodu do testów, nie mam jak tego sprawdzić.

> 3 . Przy parametrach przydała by się jeszcze jedna kolumna z wartościami poprawnymi, fabrycznymi

> dla danych parametrów.

Niestety poprawne (oczekiwane) wartości nie są raportowane przez ECU ani nie znam dokładnych algorytmów do ich wyliczania, potem były by teksty w stylu "zalecany czas wtrysku mam 2,9ms a ja mam 3,2ms czy to znaczy, że mam silnik do remontu"? Jak ktoś ma pojęcie o mechanice to wie jakie powinny być odczyty, a jak nie ma to niech lepiej nie odda auto do mechanika.

> I na koniec mam jeszcze pytanie który to jest przekaźnik główny w Seicento SPI chodzi o przekaźnik

> systemu wtryskowego

Trudno powiedzieć który to, z tego co zauważyłem to zależy od ECU ale generalnie obydwa testy dotyczą tego samego przekaźnika - przekaźnika pompy paliwa. Zadaniem testów jest jedynie wysterowanie poszczególnych komponentów, poprawność ich działania nie jest sprawdzana.

[tzok]

> 2. Gadaliśmy o tym wcześniej, pytałeś o różne rzeczy z tym związane. Wg. mnie odświeżanie jest

> grubo za wolne. Wybrałem dwa parametry razem trzy bajty i było mało ciekawie. Mój prywatny

> program napisany w Javie, działający pod Linuxem i korzystający z biblioteki do komunikacji

> ulepionej przeze mnie w C działa zdecydowanie szybciej. Moduł diagnostyczny do TuneraPro RR,

> który zrobiłem (znajdziesz w "Tajemnicach ECU") też sobie lepiej radzi. W każdym razie coś

> jest tutaj nie tak, na pewno powinno dać się szybciej

Sprawdź teraz...

[woj76]

> Sprawdź teraz...

No niestety, przez dłuższy czas nic nie sprawdzę, bo samochód jest czasowo użytkowany przez kogoś innego. Jak będę miał możliwość to nie omieszkam

[wojtala]

> No niestety, przez dłuższy czas nic nie sprawdzę, bo samochód jest czasowo użytkowany przez kogoś

> innego. Jak będę miał możliwość to nie omieszkam

zony i auta sie nie pozycza

[woj76]

> zony i auta sie nie pozycza

A auto żonie ?