Wątek: Aplikacja DomowyKokpit

[vito_zm]

Cieszę się,że już są robione testy z platformą.Mam nadzieję,że niedługo także dołączę do testujących.Teraz próbuję teoretycznie poznać DomowyKokpit.
Jestem po testach skryptu 12.Zrobiłem tak jak sugerowałeś i test wypadł pomyślnie.Podmieniłem w skrypcie zmienne np. $aviador_button_001 na $Logitech_Extreme_3D_przycisk_000.Przy okazji zauważyłem,że można kopiować zmienne jedno lub wielowierszowe.Wersja jednowierszowa jest bardzo praktyczna (zajmuje mało miejsca).
Próbowałem zastosować drugi sposób uruchomienia skryptu 12 na Logitech wg.Twojego opisu,ale powstał błąd.

....W module 'GameControllerInput' nie znaleziono zmiennej o identyfikatorze 'Logitech Extreme 3D:button_001'....

Przy okazji taka uwaga szkoda,że nie można kopiować informacji z log.Prześlę na pw mój zmodyfikowany skrypt,może znajdziesz błąd.
Teraz będę testował działanie funkcji wysyłania kombinacji klawiszy do Falcona.

[codeking]

Próbowałem zastosować drugi sposób uruchomienia skryptu 12 na Logitech wg.Twojego opisu,ale powstał błąd.

....W module 'GameControllerInput' nie znaleziono zmiennej o identyfikatorze 'Logitech Extreme 3D:button_001'....

Sprawdź na liście zmiennych modułu czy istnieje zmienna o takim ID.

Przy okazji taka uwaga szkoda,że nie można kopiować informacji z log.

Kopiować można przy pomocy skrótu klawiaturowego CTRL+C. Menu podręczne też się przyda więc wezmę to pod uwagę.

[vito_zm]

Witam ponownie.Próbowałem tą drugą metodę,ale miałem problemy i dałem sobie spokój.Ważniejsze jest przesyłanie kombinacji klawiszy do symulatora.
Próbuję wysyłać skrót CTRL+ALT+1 do Falcona i nie widzę efektu.Skrypt jest uruchomiony,mam informację w log,że działa.Po uruchomieniu DK oraz skryptu uruchamiam Falcona.
Skrypt jest prosty.
 script "Skrypt_12 - wysyłanie wirtualnych klawiszy"
{
   variable $Logitech_Extreme_3D_przycisk_011 { module = "GameControllersInput"; id = "Logitech Extreme 3D:przycisk_011"; type = bool; direct = in; }
      variable_changed $Logitech_Extreme_3D_przycisk_011
   {
      if ( $Logitech_Extreme_3D_przycisk_011 )
      {
         // wysłanie skrótu klawiaturowego CTRL+ALT+1
         KeyboardOutput:SendShortcut( "^%1" );
      }
   }
}
Czy robię coś nie tak?

[vito_zm]

Jest pewien postęp.Uruchomiłem ten sam skrypt,ale pod MJoya i działa.
script "Skrypt_12 - wysyłanie wirtualnych klawiszy"
{

   variable $MJ16_przycisk_000 { module = "GameControllersInput"; id = "MJ16:przycisk_000"; type = bool; direct = in; }

   variable_changed  $MJ16_przycisk_000
   {
      if ($MJ16_przycisk_000  )
      {
         // wysłanie skrótu klawiaturowego CTRL+ALT+1
         KeyboardOutput:SendShortcut( "^%1" );
         
      }
   }
}
Nie wiem na czym polega konflikt pomiędzy Falconem a Logitech.Zmieniałem w skrypcie dla Logitech 3D przyciski,ale to nie pomogło.Nie ma problemu z MJoy.Robilem próbę na razie tylko z jednym przyciskiem.Jutro zrobię próby z kilkoma przyciskami i z enkoderem,zobaczymy jak to będzie działać.

[codeking]

Próbuję wysyłać skrót CTRL+ALT+1 do Falcona i nie widzę efektu.

Sprawdziłem dokładnie i znalazłem błąd przy wysyłaniu klawiszy w module KeyboardOutput. Wiem na czym polega błąd, będę chciał go w miarę szybko poprawić. Ciekawe jest to, że Falcon nie potrafi "odczytać" tych klawiszy a inne programy oraz FS'y nie mają problemu.

Dobrze, że testujesz każdy aspekt działania, dzięki temu wykrywasz właśnie takie błędy

[vito_zm]

Próbowałem dzisiaj powtórzyć wczorajsze testy i mam problem.Nie działa funkcja wysyłanie skrótów klawiaturowych do Falcona z MJoya.Podejrzewam,że wczoraj to działało ponieważ miałem w tle włączony SVMapper i tego faktu nie zauważyłem.Jest to jedyne logiczne wyjaśnienie.
Jeszcze jeden fakt przemawia za moją pomyłką związaną z SVMapperem.Wydaje się nielogiczne,że MJoy działał a Logitech Extreme 3D nie.Reasumując nie mogę wysyłać skrótów klawiaturowych do Falcona stosując DK.
Ponieważ codeking zauważył jakiś błąd w programie to jest szansa,że to ruszy.Czekam na poprawiony KD.Pytanie do EGHI,czy robiłeś podobne testy jak ja
pozdrawiam i czekam na poprawiony KD.

[codeking]

Podejrzewam,że wczoraj to działało ponieważ miałem w tle włączony SVMapper i tego faktu nie zauważyłem.Jest to jedyne logiczne wyjaśnienie.

Nowa wersja (z poprawionym modułem do obsługi klawiatury) dostępna na stronie http://fs.angus.foxnet.pl/

Dołączyłem do niej moduł do obsługi płytek Skalarki, więc można zobaczyć jak to wygląda.

Moduł do obsługi wyświetlaczy HD44780 na LPT jest w fazie testów i na razie mogę do udostępnić posiadaczom tak podpiętych wyświetlaczy (schemat http://www.mikkila.org/fsbus/lcd/index_e.php), obsługuje już wyświetlacze zgodne z HD44780 ale z tą zgodnością różnie bywa więc trzeba jeszcze poprawić obsługę tych "mniej zgodnych".

[vito_zm]

Moje gratulacje codeking.Nowa wersja współpracuje z FalconemAF.Test wykonałem na przycisku w moim minikokpicie (stara wersja).Teraz rozpocznę z spokojem robić testy z przełącznikami oraz enkoderami.Przy okazji taka refleksja,jeśli platforma skalarki jest tak dobra jak program DomowyKokpit to mamy bardzo dobry produkt.
Teraz na gorąco kilka moich uwag.Tak jak wspomniałem DK jest rewelacyjny.Na czym polega jego wyjątkowość w porównaniu do SVMappera oraz SIOC.Tutaj uwaga, nie mogę porównywać DK z innymi programami ponieważ ich nie znam.
Programując przyciski w DK nie musimy znać fizycznych adresów naszego sterownika,który jest podłączony do fizycznych przycisków,przełączników itp.Programując w SVMapper trzeba znać mapę połączeń tzn.do której kolumny oraz wiersza jest podłączony dany element.Podobnie w SIOC deklarując zmienne musimy wskazać fizyczny adres.W DK ten problem nie istnieje.Mamy adresy przycisków,które programujemy.Jedynie co musimy znać to fizyczne miejsce w panelu gdzie jest umieszczony dany przełącznik i jaka jest jego funkcja w symulatorze.Pisząc ten tekst tak myślę,że wprawdzie fizyczne adresy nie są potrzebne przy pisaniu skryptu,ale musimy wiedzieć jaką funkcje wykonuje przycisk/przełącznik w symulatorze.Pomimo tego stwierdzenia twierdzę,że w DK jest łatwiejsze programowanie przycisków niż w pozostałych wymienionych programach.
Nurtuje mnie jedna sprawa związana z MJoyem.Tutaj myślę,że codeking może to wyjaśnić.Na początek jedna uwaga nie musimy stosować SVMappera do uruchamiania MJoya,można to zrobić stosując DK.
Teraz pytanie do codeking,który ma także MJoy.Czy można robiąc odpowiednie deklaracje w module GameControllersInput->konfiguracja->przyciski zrobić z wejść typu pushbuttons toggle switch.Są tam różne opcje typu oczekiwanie zdarzenia,sprawdzanie cykliczne,powtarzanie jak często i po jakim czasie.
Przy okazji prośba o wyjaśnienie w jakich sytuacjach użyć te opcje.
Nie wiem czy moje uwagi są słuszne dlatego proszę o korekcje.Z mojego doświadczenia wynika,że najlepsza metoda testu jakiegoś nowego programu to pytania nawet jeśli są naiwne.
Na koniec jeszcze jedno spostrzeżnie dotyczące wysyłania kombinacji klawiszy.W DK wysyłane są klawisze wg.kolejności umieszczenia ich  w tekscie tak się domyślam.W SIOC jest podobnie,ale rozróżniają w sekwencji oprócz kolejności wysłania naciśnięcie (down) oraz puszczenie (up).
Są to moje uwagi na gorąco,teraz z spokojem wykonam następne testy
pozdrawiam
vito_zm

[vito_zm]

Kolejna relacja z testów KD.Sprawdzilem działanie przełączników 2 i 3 pozycyjnych jest o.k.Przy okazji przypomnienie,znaki specjalne np.F1 w nawiasach {}.
Nie działa enkoder.U mnie enkodery są podłączone do MJoya i realizuję funkcję HSD Range Dec oraz Inc co odpowiada kombinacji klawiszy Shift+F11 oraz Shift+F12.Próbowałem ustawić w opcjach przycisków powtórzenia w ms,ale to nie miało wpływu.W SVMapper to działa.
Wracając do składni pisania kombinacji klawiszy w SIOC to naciskanie i puszczanie  kombinacji klawiszy z shift,ctrl oraz alt jest wyróżnione znakiem określającym kierunek działania down,up.Wspominam o tym jako o ciekawostce,że tak to zrobiono.
Przy okazji apel do kolegów testujących KD,napiszcie o swoich testach,ten wątek jest odpowiedni dla tych tematów.

[codeking]

Czy można robiąc odpowiednie deklaracje w module GameControllersInput->konfiguracja->przyciski zrobić z wejść typu pushbuttons toggle switch.

Na chwilę obecną nie da się tego zrobić poprzez konfigurację, jedynie pisząc odpowiednio skrypt. Podaj przykład co chciałbyś zrobić przy pomocy toggle switch'a, to postaram się opisać jak to zrealizować przy pomocy skryptu, jeśli okaże się, że lepiej żeby to moduł odpowiednio traktował przyciski to dodam taką opcję do modułu.

Są tam różne opcje typu oczekiwanie zdarzenia,sprawdzanie cykliczne,powtarzanie jak często i po jakim czasie.
Przy okazji prośba o wyjaśnienie w jakich sytuacjach użyć te opcje.

Opcje dotyczące samego kontrolera:

• ID - wiadomo, to ID dopisywane jest automatycznie do nazwy zmiennej, można zmieniać dowolnie wg. własnego uznania
• Identyfikator systemowy - wartość odczytana z systemu, nie można jej zmieniać
• Stan - informacja o tym czy kontroler jest podpięty do komputera (można konfigurować kontrolery, które były już konfigurowane ale obecnie nie są podpięte do komputera)
• Sprawdzanie stanu kontrolera - tutaj wybieramy jak aplikacja ma sprawdzać czy przyciski i osie zmieniły swój stan (naciśnięto/zwolniono przycisk, przesunięto przepustnice itd.), obydwie opcje mogą być dobre w różnych sytuacjach, tutaj potrzeba naprawdę sporo testów żeby wyłapać różnice w działaniu, głównym powodem dla którego dałem tą opcję są niestabilne osie w kontrolerach, w takiej sytuacji opcja "Oczekuj zdarzenia" będzie praktycznie non stop "męczyła" moduł, będzie on cały czas powiadamiany o zmianach stanu (np. niestabilnej osi, która cały czas drga), miałem niedawno problem z Saitek Aviator, oś X mocno drgała, dorobiłem więc opcję "Sprawdzaj cyklicznie", co ustawiony czas moduł odpytuje o stan kontrolera, odpada wtedy problem drgających osi, tak więc obydwie opcje mają swoje plusy i minusy, "Oczekuje zdarzenia" uśpi moduł gdy nie będzie w ogóle zmian stanu kontrolera albo będzie obciążać niepotrzebnie gdy będą drgania, "Sprawdzaj cyklicznie" stale odpytuje o stan, nie pozwala więc nudzić się modułowi ale za to nie straszne są drgania osi

Opcje dotyczące przycisków:

• Powtarzanie - opcja pozwala na włączenie powtarzania generowania zdarzenia o zmianie stanu zmiennej odpowiadającej danemu przyciskowi, gdy ją włączymy, to moduł po ustalonym czasie co wskazany okres będzie generował zdarzenia "zwolniono przycisk" i "naciśnięto przycisk", będzie to robił do czasu aż fizycznie przycisk na kontrolerze zostanie zwolniony, gdy ta opcja jest wyłączona (brak ptaszka) to przy naciśnięciu przycisku będzie wygenerowane zdarzenie i kolejne dopiero przy jego zwolnieniu
• Powtarzaj po (ms) - czas w milisekundach po jakim moduł będzie generował w/w zdarzenia, czas liczony od momentu naciśnięcia przycisku
• Powtarzaj co (ms) - czas w milisekundach określający odstęp czasowy pomiędzy generowanymi zdarzeniami ("zwolniono" - czeka - "naciśnięto" - czeka - "zwolniono" - itd.)

Opcje dotyczące osi:

• Odwróć - proste odwrócenie osi (reverse), max zamienia się na min a min na max
• Minimum i Maksimum - określamy przedział wartości jakie będą raportowane przy przesuwaniu osi, nie jest to kawałek osi, moduł będzie skalował całą oś i w zależności od położenia ustawi wartość zmiennej z podanego zakresu, domyślnie jest 0-100 ale równie dobrze można dać -1000 - 1000 lub 500 - 600, wartości graniczne to -32768 i 32767
• Stan - kolumna wyświetla aktualną wartość osi kontrolera

Przycisk "Usuń konfigurację" pozwala usunąć konfigurację kontrolera. "Panel sterowania" wyświetla standardowe okienko z panelu sterowania Windows dotyczące wybranego kontrolera. "Raportuj" zapisuje do pliku raport o kontrolerach dostępnych w systemie - przydatne przede wszystkim dla mnie bo udało się wykryć kilka błędów i problemów, których nie mogłem u siebie odtworzyć ze względu np. na brak konkretnego kontrolera.

Z mojego doświadczenia wynika,że najlepsza metoda testu jakiegoś nowego programu to pytania nawet jeśli są naiwne.

Nie ma głupich pytań - są tylko głupie odpowiedzi, tak więc będę odpowiadał aż wszystko stanie się jasne i zrozumiałe

Na koniec jeszcze jedno spostrzeżnie dotyczące wysyłania kombinacji klawiszy.W DK wysyłane są klawisze wg.kolejności umieszczenia ich  w tekscie tak się domyślam.W SIOC jest podobnie,ale rozróżniają w sekwencji oprócz kolejności wysłania naciśnięcie (down) oraz puszczenie (up).

Tak, wysyłane są w takiej kolejności w jakiej się wpisze. Jeśli chcemy inną kolejność np. nacisnąć klawisz, nacisnąć inny, puści pierwszy i puścić drugi to można skorzystać z pozostałych funkcji z modułu KeyboardOutput: SendKeysDown i SendKeysUp.

Mimochodem wychodzi tu niezły podręcznik użytkownika

EDIT:

Nie działa enkoder.U mnie enkodery są podłączone do MJoya i realizuję funkcję HSD Range Dec oraz Inc co odpowiada kombinacji klawiszy Shift+F11 oraz Shift+F12.Próbowałem ustawić w opcjach przycisków powtórzenia w ms,ale to nie miało wpływu.W SVMapper to działa.

Enkoder w MJoy'u jest jak zwykły przycisk, nie trzeba konfigurować mu powtórzeń itd. Nie działa enkoder czy wysyłanie klawiszy SHIFT+F11 i SHIFT+F12 ?
 

[EGHI]

Witam,
dołączam do szkółki niedzielnej. Napisałem niedzielnej bo tylko w weekendy będę prowadzić testy.
Jak wiadomo SkalarkiIO współpracuj już z DK. Postanowiłem spróbować napisać prosty skrypt dla Falcona do zapalenia jednej diody. Według wskazówek codekinga wyglada to tak:
// test SK
script "SK"
{

      variable $AOAAboveLED
  }
     module = "SkalarkiIO";
     id = "usb:output_014";
  }
}
Próba wczytania pliku do przebiega pomyślnie. Zakładam, że nie ma błędów.

"Wczytywanie skryptów z pliku 'C:\Documents and Settings\arek2\Pulpit\DomowyKokpit_1_0_2_6\TestSK.hcps'...
Ilość wczytanych skryptów: 1.
   "SK"
Niestety, kiedy chcę uruchomić skrypt "SK" pojawia się błąd i skrypt kończy działnie:

Uruchamianie skryptu 'SK'...Uruchomiono wątek skryptu...Błąd działania skryptu: DomowyKokpit.Parser.CheckingScriptException: W module 'SkalarkiIO' nie znaleziono zmiennej o identyfikatorze 'usb:output_014'.   at DomowyKokpit.Main.ProcessingThread(Object p)Zakończono działanie skryptu.

I teraz pytanie, czy jest to błąd w module SkalarkiIO?  Błędnie napisany skrypt?
Do wyjścia 014 jest podłączona dioda i kiedy testuje komunikacje miedzy płytką a softem, dioda zapala się czyli w tym miejscu wszystko jest ok.
 Zastanawiam się też nad variable $AOAAboveLED. Czy tak powinien wyglądać zapis, czy może raczej tak:
{
        $AOAAboveLED = GetBitState( $lightBits ,  0x1000 );   
}

Kolejne pytanie to zapis bitu, czyli po przeliczeniu w kalkulatorze 0x1000 wynika, że jest to 12. Czyli zapis powinien wyglądać tak?-
{
        $AOAAboveLED = GetBitState( $lightBits , 12 );   
}

[codeking]

Niestety, kiedy chcę uruchomić skrypt "SK" pojawia się błąd i skrypt kończy działnie:

Uruchamianie skryptu 'SK'...Uruchomiono wątek skryptu...Błąd działania skryptu: DomowyKokpit.Parser.CheckingScriptException: W module 'SkalarkiIO' nie znaleziono zmiennej o identyfikatorze 'usb:output_014'.   at DomowyKokpit.Main.ProcessingThread(Object p)Zakończono działanie skryptu.

I teraz pytanie, czy jest to błąd w module SkalarkiIO?  Błędnie napisany skrypt?

Błąd konfiguracji, sprawdź czy w konfiguracji płytki masz wpisany ID "usb".

Czy tak powinien wyglądać zapis, czy może raczej tak:
{
        $AOAAboveLED = GetBitState( $lightBits ,  0x1000 );   
}
Kolejne pytanie to zapis bitu, czyli po przeliczeniu w kalkulatorze 0x1000 wynika, że jest to 12. Czyli zapis powinien wyglądać tak?-
{
        $AOAAboveLED = GetBitState( $lightBits , 12 );   
}

Wartość 0x1000 to bitowo 1 0000 0000 0000. Licząc od prawej i numerując od zera. To 1 jest na pozycji 12, więc do funkcji przekazujemy 12.

[vito_zm]

Mimochodem wychodzi tu niezły podręcznik użytkownika

Ja myślę,że po testach powstanie coś podobnego do manuala  MJoya.Chętnie pomogę w redagowaniu.
EGHI ja się temu przyjrzę.Nie robiłem tego tematu ponieważ nie mam platformy,ale mogę zrobić teoretyczny skrypt odczytu bitu z Falcona.Nie wiem jak zapalić LED,ponieważ jest to chyba związane już z platformą.
Enkodery działają,przyczyna była jak zwykle trywialna,pomyliłem ^ z + i zamiast shift wysłałem ctrl.

skorzystać z pozostałych funkcji z modułu KeyboardOutput: SendKeysDown i SendKeysUp.

Ja to zauważyłem.Napisałem o tym dlatego,że nie rozumiem dlaczego w SIOC piszą tak precyzyjnie zwykłą czynność wciśnięcia i puszczenie klawiszy.U nich sekwencja np.shift+ctrl+alt+klawisz jest rozpisana na shiftdown/ctrldown/altdownklawisz/altup/ctrlup/shiftup dokładnie w takiej kolejności.
Napisałem o zamianie pushbutton na toggle tylko dlatego,że koledzy próbowali za pomocą hardware oszukać SVMapper,ale się nie udało.W platformie OC nie ma to większego znaczenia co podłączamy do wejść,wystarczy odpowiednia deklaracja typu wejścia.Podejrzewam,że w platformie skalarki jest podobnie.
Codeking dziękuję za wyjaśnienia,ale dopiero jutro je przetrawię i jak zwykle będę pytał
pozdrawiam
vito_zm

[vito_zm]

Tak na gorąco moje uwagi do KD.Sprawdziłem script"Falcon-Skalarki-diody".Jest on związany z Falconem co widać w nazwie skryptu.Codeking w tym skrypcie opisał dokładnie co jest wykonywane i dlaczego.Zrobił to bardzo przejrzyście (zrozumiale).Przez analogię w SIOC jest to zrobione w podobny sposób tylko są inne nazwy funkcji zamiast GetBitState() jest TESTBIT () itp.
Zauważyłem,że są problemy z zapisem i odczytem liczb w postaci hex.Zasada jest prosta.W przykładzie codeking 0x... oznacza liczbę w postaci hex,gdzie kropki oznaczają zapis liczby w postaci hex.Najlepiej wyjaśnić to na przykładach:
0xff oznacza 15 dziesiętne lub 1111 1111 binarnie
0x0a oznacza 10 dziesiętnie lub 0000 1001 binarnie
0x07 ozn.7 dziesiętnie lub 0000 0111 binarnie itd.
Następna sprawa to miejsce bitu w rejestrze.W rejestrach bity są liczone od zera do n-1,gdzie n jest długością rejestru.W przykładzie od liczby reprezentującej bit dla danej funkcji odejmujemy 1 tak aby uzyskać właściwą pozycję w rejestrze.Tak rozumiem zapis w skrypcie.Mam nadzieję,że nie zamieszałem.
Teraz prośba do codeking.Czy możesz przysłać maile z plikiem ShareMemHeader.cs z opisami funkcji.Sprawdzę opisy i pozycje bitów z opisem FAST.Jeśli są różnice to je zaznaczę.Będzie to duże ułatwienie dla piszących skrypty dla Falcona.
Reasumując mogę stwierdzić,że potrafię odczytać przyciski/przełączniki oraz zapisać LED przy pomocy DK.Teraz rozpocznę testy z  wyświetlaczem LCD połączonym do LPT oraz przechwytującym dane z Falcona.To zajmie trochę więcej czasu ponieważ muszę zrobić hardware i rozeznać temat.
Będę miał jeszcze pytania dotyczące DK,ale muszę  sprawdzić parę spraw.

[codeking]

Z tymi światłami w Falcon'ie to są jakieś dziwne rzeczy, są problemy ze światłami położenia podwozia, u EGHI bardzo szybko są raportowane i to od razu 3 naraz - brak synchronizacji z tym co widać w Falcon'ie. Trzeba to jakoś wyprostować. Na szybko napisałem program monitorujący zmienne lightBits, lightBits2 i lightBits3, można pobrać stąd: http://angus.foxnet.pl/fs/falcon_monitor.zip Do archiwum wrzuciłem plik SharedMemHeaders.cs.

Pytanie do vito_zm: czy FAST dla OC dobrze raportuje stan podwozia tzn. czy jest dobra synchronizacja ? Być może jest to inaczej odczytywane niż w bibliotece F4SharedMemReader (autorem jest lightning z viperpits.org).

Poczytałem też trochę forum viperpits.org i okazuje się, że kolejne wersje OpenFalcon zmieniają adresy zmiennych w pamięci i stąd prawdopodobnie taki rozjazd z odczytem tych świateł. W ostateczności można je odczytać odpowiednio interpretując zmienne noseGearPos, leftGearPos i rightGearPos, ale lepsze byłoby oparcie się na flagach.