Autor Wątek: Następca Mjoy (Założenia konstrukcyjne)  (Przeczytany 68417 razy)

0 użytkowników i 1 Gość przegląda ten wątek.

Odp: Następca Mjoy (Założenia konstrukcyjne)
« Odpowiedź #135 dnia: Stycznia 16, 2011, 16:50:25 »
Cytuj
Przepraszam że się wcinam, ale może by spróbować "załatwić to" w obsłudze przerwania od zbocza na wejściach zamiast męczyć uP poolingiem ?
Intencja jest słuszna,ale dla jednego lub kilku enkoderów.Nam zależy na większej ich liczbie.Nie chcę wchodzić w szczegóły związane z przerwaniami,ale są one na tyle cenne,że programiści stosują je dla ważniejszych zadań.
Druga sprawa to jitter oraz drgania styków.Nie chcę znowu wchodzić w szczegóły,ale rozwiązanie Damosa jest optymalne.

Odp: Następca Mjoy (Założenia konstrukcyjne)
« Odpowiedź #136 dnia: Stycznia 16, 2011, 16:50:42 »
Jestem naprawdę pod wrażeniem. Ale jak rozumiem obsługa 70 enkoderów jest możliwa przy założeniu że nikt nie będzie kręcił wszystkimi jednocześnie ?

Odp: Następca Mjoy (Założenia konstrukcyjne)
« Odpowiedź #137 dnia: Stycznia 16, 2011, 16:55:54 »
Fizycznie jest to niemożliwe.Robimy projekt pod symulator gdzie wirtualny pilot wykonuje określone czynności wg.procedur.

Odp: Następca Mjoy (Założenia konstrukcyjne)
« Odpowiedź #138 dnia: Stycznia 16, 2011, 17:26:09 »
Przy założeniu że powiedzmy 60 enkoderów w wirtualnej kabinie np. F-16 będzie obsługiwane przez jeden "centralny uP" będziecie jak rozumiem zmuszeni do przeciągnięcia ok. 120 przewodów o długości być może 100 cm. Uwzględniając wymagane czasy narastania zbocza sygnału ~ 10 us czy nie obawiacie się zakłóceń, odbić, przerostów itp. Jak rozumiem to nie są pętle prądowe ?

Zauważyłem bardzo dużą oszczędność na dodatkowych elementach pasywnych – ale czy to się nie odbije w końcowym złożeniu wszystkiego w całość ?

Do powyższych pytań zmuszają mnie zawodowe uprzedzenia do długich przewodów jakich się nabawiłem przy projektach pracujących w środowiskach o dużym poziomie zakłóceń.

Czy można gdzieś obejrzeć schemat (może być blokowy) całości ?


Odp: Następca Mjoy (Założenia konstrukcyjne)
« Odpowiedź #139 dnia: Stycznia 16, 2011, 19:18:23 »
jak rozumiem obsługa 70 enkoderów jest możliwa przy założeniu że nikt nie będzie kręcił wszystkimi jednocześnie ?
Można kręcić wszystkimi jednocześnie (przy zastosowaniu diod)

Przy założeniu że powiedzmy 60 enkoderów w wirtualnej kabinie np. F-16 będzie obsługiwane przez jeden "centralny uP" będziecie jak rozumiem zmuszeni do przeciągnięcia ok. 120 przewodów o długości być może 100 cm.
60 enkoderów to 180 przewodów  :010: :021:
Uwzględniając wymagane czasy narastania zbocza sygnału ~ 10 us czy nie obawiacie się zakłóceń, odbić, przerostów itp.
Czas narastania sygnału wyemitowanego przez uC jest ważny. Faktycznie, to powinien być nawet dużo mniejszy niż 10us. Obecnie mam opadanie 19ns, narastanie  20ns.  Podłączenie metrowego kabla daje zwiększenie czasów do 24ns.  A odbić, sprzężeń, zakłóceń boimy się jak jasna... Taka pajęczyna taktowana kilka KHz moze nieźle siać i doskonale zbiera tętnienia z sieci. Dlatego układ jest mały - aby mógł być blisko urządzeń. Można użyć skrętki do krosowania kabli, ekstremalne rozwiązania to ekranowane przewody :) W matrycy należy stosować diody, co pomoże odciąć część część indukowanych prądów dzięki minimalnemu napięciu przełączenia diody.

Jak rozumiem to nie są pętle prądowe ?
Niestety - rezystory podciągające mają średnio po 35K więc prąd jest tam minimalny pewnie poniżej 0,14mA. W ekstremalnym przypadku można dołożyć do układu zewnętrzne rezystory podciągające, nie mniejsze jednak niż 1K (ok. 5mA). Ale zwiększenie obciążenia prądowego zwiększy wymagania dla filtracji zasilania.

Zauważyłem bardzo dużą oszczędność na dodatkowych elementach pasywnych – ale czy to się nie odbije w końcowym złożeniu wszystkiego w całość ?
EMC nie planuję :) Są pojemności blokujące i dławiki na zasilaniu (prawie) zgodnie z wytycznymi Atmela.


Czy można gdzieś obejrzeć schemat (może być blokowy) całości ?
Raczej schemat ideowy :) Na bloki trudno to podzielić - za małe.
« Ostatnia zmiana: Stycznia 16, 2011, 19:29:32 wysłana przez damos »

Odp: Następca Mjoy (Założenia konstrukcyjne)
« Odpowiedź #140 dnia: Stycznia 16, 2011, 19:19:40 »
Prześledź kilka wątków na tym forum.Ten wątek jest jednym z wielu.Kokpity są budowane można to sprawdzić np.na forum viperpits.Generalnie zasada jest taka,że robi się projekt modułowy tzn. kilka niezależnych sterowników.W moim przypadku jest ich kilka i dodatkowo są sterowane z różnych programów.Zaleta jest taka,że są krótkie przewody.Damos oparł swój projekt na specjalnym interfejsie odpornym na zakłócenia i zrobiony na 3 przewodach.
Co do zakłóceń to jest to temat sam w sobie ciekawy.Co innego urządzenia w środowisku przemysłowym lub militarnym a co innego w mieszkaniu.Zgadzam się z Tobą,że w środowisku gdzie jest duży pozim zakłóceń trzeba stosować odpowiednie projektowanie oraz zabezpieczenia.Jak zauważyłeś na forum są konstruktorzy amatorzy,dlatego nikt nie wnika zbyt głęboko w te tematy.
Schematy są dostępne na forum OpenCockpits,na stronie Codeking SimOUT,na stronie Nokera jest MJoy oraz na stronie Damosa są założenia nowych sterowników.

Odp: Następca Mjoy (Założenia konstrukcyjne)
« Odpowiedź #141 dnia: Stycznia 16, 2011, 19:55:43 »
60 enkoderów to 180 przewodów  :010: :021:

Wiem  :002: - to asekuracja z mojej strony - być może wymyśliliście jakiś myk ze wspólnym przewodem ?

Raczej schemat ideowy :) Na bloki trudno to podzielić - za małe.

Nie wiedząc czy chcecie udostępniać schemat ideowy - wolałem zapytać tylko o blokowy  :002:

Prześledź kilka wątków na tym forum.Ten wątek jest jednym z wielu.Kokpity są budowane można to sprawdzić np.na forum viperpits.Generalnie zasada jest taka,że robi się projekt modułowy tzn. kilka niezależnych sterowników.W moim przypadku jest ich kilka i dodatkowo są sterowane z różnych programów.Zaleta jest taka,że są krótkie przewody.Damos oparł swój projekt na specjalnym interfejsie odpornym na zakłócenia i zrobiony na 3 przewodach.

No to teraz już nic nie rozumiem. Z poprzednich postów "powziąłem domniemanie" że w kokpicie ma być jeden centralny moduł na 70 pokręteł i 80 przycisków  :008:

Co do zakłóceń - jak produkt wytrzyma telefon mojej córki leżący w odległości 1 m to będzie OK  :001:.
« Ostatnia zmiana: Stycznia 16, 2011, 20:03:34 wysłana przez Piorun »

Odp: Następca Mjoy (Założenia konstrukcyjne)
« Odpowiedź #142 dnia: Stycznia 16, 2011, 20:28:24 »
Wiem  :002: - to asekuracja z mojej strony - być może wymyśliliście jakiś myk ze wspólnym przewodem ?
Nie do zrobienia w matrycy :)

No to teraz już nic nie rozumiem. Z poprzednich postów "powziąłem domniemanie" że w kokpicie ma być jeden centralny moduł na 70 pokręteł i 80 przycisków  :008:
To są około-graniczne możliwości jednego modułu z punktu widzenia timingów. Vito_zm myśli o dodatkowych płytkach z osobnym uC (bez USB), które będą się łączyć z "płytą-matką" za pomocą I2C: (ok, sterowanie napięciowe, ale na 2 metry powinno dać radę z odpowiednimi terminatorami)

Jednak nie każdy musi chcieć budować tak złożone układy - wtedy używa bazowej płytki z USB. Wystarczy wgrać jej nowy firmware i zmienia się z emulatora klawiatury (obecnie omawiany) w Joy'a, albo w programator, albo w uniwersalny moduł I/O.
« Ostatnia zmiana: Stycznia 16, 2011, 21:01:23 wysłana przez KosiMazaki »

Odp: Następca Mjoy (Założenia konstrukcyjne)
« Odpowiedź #143 dnia: Stycznia 16, 2011, 20:53:27 »
No teraz wszystko jasne.

Panowie - nie wiem gdzie jest emotka od bicia pokłonów ale wyobraźcie sobie ze to ta  :001:

Wiele razy myślałem o czymś takim - chodzi mi o wielomodułowe rozwiązanie z płytą-matką.

Gdyby powstała analogiczna grupa software'owców o takim zaangażowaniu jak Wasza to można by się pokusić o napisanie własnego symulatora samolotu/okrętu/czołgu itp - ale takiego z najskrytszych marzeń.

Życzę Wam powodzenia i dalszego zapału w pracy - wyniki na pewno będą super.

Odp: Następca Mjoy (Założenia konstrukcyjne)
« Odpowiedź #144 dnia: Stycznia 16, 2011, 22:11:14 »
Wiele razy myślałem o czymś takim - chodzi mi o wielomodułowe rozwiązanie z płytą-matką.
Jak widać - nie tylko Ty :)

Gdyby powstała analogiczna grupa software'owców o takim zaangażowaniu jak Wasza
Ale tutaj software to 95% roboty :)

to można by się pokusić o napisanie własnego symulatora samolotu/okrętu/czołgu itp - ale takiego z najskrytszych marzeń.
Myślisz o takim - własnym symulatorze a'la Lock-On? Awykonalne. Na 120%  - vide Fighter Ops  :118: Zrobienie czegoś takiego to kilka mln $ i kilka lat pracy.

Odp: Następca Mjoy (Założenia konstrukcyjne)
« Odpowiedź #145 dnia: Stycznia 16, 2011, 22:22:46 »
Cytuj
Wiele razy myślałem o czymś takim - chodzi mi o wielomodułowe rozwiązanie z płytą-matką
Wiem,że znasz FalconaAF.Ja mam to rozwiązane w następujący sposób.ICP jest sterowane z sterownika o nazwie MJoy,który jest podłączony do pc przez USB.Ten sterownik steruje także HSI.Są to bardzo krótkie połączenia.
Left Aux Console jest sterowany przez inny sterownik także MJoy.
Left Console jest sterowany przez karty OpenCockpits.Tutaj filozofia jest następująca:płyta komunikująca się z pc do której można podłączyć 4 płyty Master.Do każdej Master można podłączyć inne karty w zależności od potrzeb np.karta Display itd.Jest to konfiguracja modułowa z różnymi opcjami.
Right Aux Console jest sterowane przez inny sterownik SimOUT,który zaprojektował Codeking z naszego forum.
Right Console będzie sterowane przez sterownik Damosa,który jest w fazie końcowej projektowania (soft).
MJoye maja swój soft SVMapper,SimOUT pracuje z softem napisanym przez Codeking HSC.Damos tworzy swój soft.Karty OC pracują z SIOC.
Jak widzisz projekt jest dosyć rozbudowany.
Zapomniałem o jeszcze jednym rozwiązaniu hardware tzn.sterownik Skalarki,który także pracuje z córkami i jest widziany przez HSC Codeking.
Jak widzisz jest na naszym forum paru zapaleńców i są już efekty ich pracy.To co robi Damos, Codeking i Skalarki jest bardzo profesjonalne i porównywalne z rozwiązaniami z viperpits.Hardware nie jest problemem problemem jest soft i tutaj są potrzebni doświadczeni programiści znający także uP.

Odp: Następca Mjoy (Założenia konstrukcyjne)
« Odpowiedź #146 dnia: Stycznia 16, 2011, 22:44:38 »
Ja znam ARM-y, zwłaszcza  z seri AT91SAM7XXX. Drivery pod WinXP też pisałem. Zgłosiłbym się "na ochotnika" ale w najbliższym czasie będę niestety mocno zajęty (mam nadzieję bo z czegoś trzeba żyć).

Jak znajdę więcej wolnego czasu to może pomogę - oczywiście jeśli chcecie.


Odp: Następca Mjoy (Założenia konstrukcyjne)
« Odpowiedź #147 dnia: Stycznia 17, 2011, 07:33:20 »
Pomoc jest mile widziana zwłaszcza programistów.Dodam tylko,że jest teraz tendencja do projektowania gotowych paneli tzn.mechanika z sterownikiem jako całość np.Right Console wskaźniki.EGHI zrobił tańsze rozwiązanie oparte na sterowniku z OpenCockpits http://www.f16pit.dbv.pl/news.php
Teraz myślimy o zastosowaniu silników krokowych,ale musimy poczekać na soft Codeking.Reasumując mamy ambicję zrobić polską wersję hardware oraz softu dla symulatorów.Jest to możliwe dzięki zaangażowaniu Codeking oraz Damosa,którzy robią to za free.Pozostali koledzy próbują im pomóc w miarę swoich możliwości.

Odp: Następca Mjoy (Założenia konstrukcyjne)
« Odpowiedź #148 dnia: Stycznia 17, 2011, 15:26:52 »
Witam,
robię prosty tester do sprawdzania konfigurowania DMKeys.Dwa sznury 34 pin łączą sterownik z płytką,która jest rozdzielaczem sygnałów.Mam do dyspozycji tzw."handheld" czyli moją starą pomocniczą klawiaturę z wyjściem na DB9.Dołożę jeszcze enkoder i przełączniki 3 pozycyjne.


Uploaded with ImageShack.us
Po wykonaniu testów płytkę przerobię na rozdzielacz dla mojego kokpitu.

Odp: Następca Mjoy (Założenia konstrukcyjne)
« Odpowiedź #149 dnia: Marca 27, 2011, 17:50:04 »
Mam pytanie do Damosa.Wiem,że kończysz soft do konfiguracji DMKeys,dlatego pytanie.Czy jest możliwość konfigurowania "makroinstrukcji"?
Wyjaśnię na przykładzie.W Falconie jest dużo komend związanych z komunikacją radiową.Np.wywołujemy AWACS (dokładnie stronę pierwszą) klawiszem Q.Na tej stronie mamy 9 możliwości wyboru komendy (klawisz 1 do 9).Możemy wybrać stronę drugą naciskając dwa razy klawisz Q.Na stonie drugiej mamy 7 możliwych komend.
Oczywiście nie ma sensu robić makroinstukcji dla wszystkich kombinacji ale można je zrobic dla kilku,które są często powtarzane.
Teraz konkretne pytanie czy jest możliwość przypisania do klawisza takiej sekwencji : Q -> Q -> 4.
W profilu Jagnstanga dla Cougara są makroinstrukcje w Foxy dla 4 komend radiowych,króre są przypisane do jednego przełącznika 4 poz.(hat).
Pytanie traktuję jako ciekawostkę,ponieważ w SIOC nie doczytalem czy to jest możliwe,ale może czytałem niedokładnie.