Jump to content
Duser

Pytanie za 100 punktów do programistów

Recommended Posts

Witam i pytam.

Chodzi o sterowniki ASCOM.

Dlaczego komendy przesyłane poprzez CommandString z jakiegoś programu zewnętrznego , działającego poprzez sterownik ASCOM , nie wykonują się , jeżeli sprzęt podłączony jest przez HUBA  ( POTH, General Hub itp)  , a wykonują się bez problemu, gdy urządzenie podłączymy bezpośrednio ( w Chooser wybieramy bezpośrednio dane urządzenie) ? ???

Dodam, że wywalany jest wyjątek :

"ASCOM.DriverException: „CheckDotNetExceptions POTH.Dome CommandString System.Reflection.TargetParameterCountException: Określona liczba parametrów jest niezgodna z liczbą oczekiwaną. (See Inner Exception for details)”

Jak widać sprawa dotyczy obsługi sterownika obserwatorium. Dziwne, zważywszy, że ilośc przekazywanych parametrów w CommandString jest prawidłowa ( 2 parametry).

 

Nie wiem , czy jasno ;) się wyraziłem.....  .

 

Share this post


Link to post
Share on other sites

Nikt nie wie? :hmm:

Coś tam poszukałem i znalazłem, że POTH ma inną  definicje niektórych funkcji - w tym CommandString, CommandBlind i CommandBool, w których występuje jeden tylko parametr. Natomiast w głównym driverze Dome w ASCOM-ie  w definicjach tych funkcji występują już dwa parametry . Co prawda drugi parametr jest niby opcjonalny, ale Visual Studio podczas pisania kodu nadal wymaga obecności drugiego elementu  ( czego w sumie nie rozumiem).

Wygląda na o, że POTH działa w oparciu o starszą implementację programową niż reszta Ascoma . Dziwne , dziwne - tym bardziej że mimo wielu update Ascoma nikt nie zmienił kodu w POTH.

 

Cóż, rozumiem, że nikt nie zetknął się z w/w problemem i rady raczej nie będzie .......

 

 

Edited by Duser
  • Sad 1

Share this post


Link to post
Share on other sites

Może odpowiem za 60 punktów. Jeśli kompilator wypisuje że ma nieprawidłowa liczbę elementów to zazwyczaj ma. Niestety nie bawiłem się w pisanie sterowników ale można łatwo sprawdzić ile elementów jest wysyłanych poprzez wypisanie ich czy to do pliku czy też w konsoli. Mając jedynie kod ciężko będzie coś powiedzieć ( o ile nie ma w nim błędu) czy wina leży po stronie sprzętowej choć nie wydaje mi się. Jeśli chodzi o ilość parametrów to chyba będzie można wpisać pusty parametr i  będzie po problemie ( jest 50 % szans że zadziała :))

Edited by BlackPitchPL

Share this post


Link to post
Share on other sites
6 godzin temu, BlackPitchPL napisał:

Może odpowiem za 60 punktów. Jeśli kompilator wypisuje że ma nieprawidłowa liczbę elementów to zazwyczaj ma. Niestety nie bawiłem się w pisanie sterowników ale można łatwo sprawdzić ile elementów jest wysyłanych poprzez wypisanie ich czy to do pliku czy też w konsoli. Mając jedynie kod ciężko będzie coś powiedzieć ( o ile nie ma w nim błędu) czy wina leży po stronie sprzętowej choć nie wydaje mi się. Jeśli chodzi o ilość parametrów to chyba będzie można wpisać pusty parametr i  będzie po problemie ( jest 50 % szans że zadziała :))

Tylko że to nie kompilator ma za mało argumentów, tylko POTH ma za dużo. I wszystko działa, dopóki nie używasz POTH właśnie.

Hub programowy, jakim jest POTH , ma zaimplementowaną starszą wersję DriverInterface . Nie posiada ona wielu funkcji , którą obsługuje driver ASCOM-a ( brakuje kilku metod i własności), a w niektórych ( np CommandString) ma wpisany tylko 1 parametr. I jak dostaje do przepuszczenia komendę z 2 parametrami ( jak to jest w najnowszym Ascomie) , wywala błąd ( nieprawidłowa ilość parametrów).

Do kitu ten POTH i tyle :fool:

Share this post


Link to post
Share on other sites

Nie możesz napisać wyjątku lub funkcji która przechwytuje oba parametry i wypuszcza tylko jeden ?

Share this post


Link to post
Share on other sites
12 godzin temu, Duser napisał:

Nikt nie wie? :hmm:

Coś tam poszukałem i znalazłem, że POTH ma inną  definicje niektórych funkcji - w tym CommandString, CommandBlind i CommandBool, w których występuje jeden tylko parametr. Natomiast w głównym driverze Dome w ASCOM-ie  w definicjach tych funkcji występują już dwa parametry . Co prawda drugi parametr jest niby opcjonalny, ale Visual Studio podczas pisania kodu nadal wymaga obecności drugiego elementu  ( czego w sumie nie rozumiem).

Wygląda na o, że POTH działa w oparciu o starszą implementację programową niż reszta Ascoma . Dziwne , dziwne - tym bardziej że mimo wielu update Ascoma nikt nie zmienił kodu w POTH.

 

Cóż, rozumiem, że nikt nie zetknął się z w/w problemem i rady raczej nie będzie .......

 

 

Widzę, że na pytanie "dlaczego" już sam odpowiedziałeś :)

 

jak z tym sobie poradzić? Programista wziąłby kod źródłowy i coś nim zmienił, przekompilował i voila. Ale nie wiem, czy to akceptowalne rozwiązanie. Alternatywnie mail do producenta z prośbą o łatę...

Share this post


Link to post
Share on other sites
8 godzin temu, BlackPitchPL napisał:

Może odpowiem za 60 punktów.

Ja odpowiem za 70 punktów, kto da więcej? :P

2 godziny temu, Duser napisał:

Hub programowy, jakim jest POTH , ma zaimplementowaną starszą wersję DriverInterface . Nie posiada ona wielu funkcji , którą obsługuje driver ASCOM-a ( brakuje kilku metod i własności), a w niektórych ( np CommandString) ma wpisany tylko 1 parametr. I jak dostaje do przepuszczenia komendę z 2 parametrami ( jak to jest w najnowszym Ascomie) , wywala błąd ( nieprawidłowa ilość parametrów).

Do kitu ten POTH i tyle :fool:

Rozumiem, że piszesz swój driver do kopuły?

Cóż, mam dwa pomysły na obejście problemu, ale nie mam za bardzo jak sprawdzić czy działają (a POTHa nie używałem). Jak rozumiem, POTH chce tylko argumentu command, a nie chce raw?

1) Ustaw parametrowi raw wartość domyślną, czyli w deklaracji metody daj np bool raw = false

2) Utwórz drugą wersję metody, o tej samej nazwie, pobierającą tylko jeden parametr (w środku możesz wywołać oryginalną metodę, żeby nie duplikować kodu)

Oba sposoby powinny sprawić, że będzie się dało wywołać metodę CommandString z jednym lub dwoma parametrami

 

Raczej skorzystaj z pierwszego sposobu, bo teraz widzę, że w deklaracji interfejsu IFocuserV2 jest użyty właśnie parametr domyślny. Szczerze mówiąc nie wiem, jak się ma parametr domyślny w interfejsie do tego w implementacji (czy powinny być tu i tu, czy jakoś inaczej). W każdym razie, skoro zawiera to interfejs, to zewnętrzny program będzie miał możliwość użycia tego.

 

Swoją drogą, do czego używasz CommandString?

Share this post


Link to post
Share on other sites

Problem rozwiązany :headbang:

Wystarczyło podczas tworzenia obiektu nie tworzyć go jako odwołanie do ASCOM.DriverAccess, a po prostu "zwyczajnie", jak obiekt COM.

Czyli nie tak :

Private driver As ASCOM.DriverAccess.Dome
driver = New ASCOM.DriverAccess.Dome(My.Settings.DriverId)
driver.Connected = True

A po prostu tak, po bożemu i bez wydziwiania:

Dim driver
driver = CreateObject(My.Settings.DriverId)
driver.Connected = True

 

Wtedy można wpisać sobie , cokolwiek się chce, bo kompilator nie protestuje.

A więc zamiast :

driver.CommandBlind("PWON#", false)

, gdzie PWON# włącza zasilanie obserwatorium, można wpisać :

driver.CommandBlind("PWON#")

i jest to przepuszczane przez POTH oraz łykane przez sterownik ,  oczywiście po odpowiedniej modyfikacji definicji funkcji CommandBlind w samym kodzie sterownika (C#):

public void CommandBlind( string command, bool raw=false) 

dopuszczającej stosowanie drugiego parametru opcjonalnie z domyślną wartością false.

 

I wsio ŚMIGA

 

  • Like 2

Share this post


Link to post
Share on other sites

@DuserPiotr jak już uporałeś się z problemem, to może zdradź konkretnie co takiego realizujesz.

Share this post


Link to post
Share on other sites

A, nic wielkiego.

Po prostu mam układzik sterujący moim  obserwatorium roll-off . Do tej pory był obsługiwany przez mały programik, łączący się bezpośrednio przez port COM . Sterowanie obejmuje obsługę dachu oraz włączanie zasilania , światła oraz flatownicy. Ale od pewnego czasu zacząłem używać SgPro , w którym jest oczywiście także obsługa obserwatorium , tyle, że przez ASCOM. Napisałem więc sterownik na ASCOMA i wszystko pięknie , ale w SGpro nie ma możliwości sterowania nietypowymi funkcjami mojego urządzonka- jak np właśnie zasilanie czy flatownica. Wobec tego musiałem odłączać na chwilę obserwatorium w SGpro i włączać mój programik ( bo inaczej SGPro blokował port COM) , załączać, co tam chciałem, potem znowu podłączać do SGPro .

Ale można napisać program obsługujący obserwatorium z poziomu ASCOMA i obsługujący dodatkowe funkcje - z tym nie ma problemu.

Żeby program łączył się z obserwatorium bez rozłączania w  SGPro ( czyli równolegle z SGPro), trzeba go podłączyć poprzez serwer sterownikowy, dopuszczający jednoczesne połączenie wielu klientów do jednego urządzenia - czyli np. ASCOM-owski  POTH.

I tu nastąpił właśnie problem - POTH operuje na innym( starszym) protokole i niektórych nietypowych funkcji nie chce zaakceptować. A po staremu nie da się już pisać w kompilatorze, który używa nowych wersji ASCOMA.

No, ale , jak widać, można to obejść w miarę prosto :Lighten:.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Our picks

    • Zdjęcie Czarnej Dziury - dzisiaj o 15:00
      Pamiętajcie, że dzisiaj o 15:00 poznamy obraz Czarnej Dziury. Niezależnie od tego, jak bardzo będzie ono spektakularne (lub wręcz przeciwnie - parę pikseli), trzeba pamiętać, że to ogromne, wręcz niewyobrażalne, osiągnięcie cywilizacji. Utrwalić coś tak odległego i małego kątowo, do tego wykorzystując mega sprytny sposób (interferometria radiowa), ...no po prostu niewyobrażalne. EHT to przecież wirtualny teleskop wielkości planety. Proste?
        • Love
        • Like
      • 141 replies
    • Amatorska spektroskopia supernowych - ważne obserwacje klasyfikacyjne
      Poszukiwania i obserwacje supernowych w innych galaktykach zajmuje wielu astronomów, w tym niemałą grupę amatorów (może nie w naszym kraju, ale mam nadzieję, że pomału będzie nas przybywać). Odkrycie to oczywiście pierwszy etap, ale nie mniej ważne są kolejne - obserwacje fotometryczne i spektroskopowe.
        • Like
      • 4 replies
    • Odszedł od nas Janusz Płeszka
      Wydaje się nierealne, ale z kilku źródeł informacja ta zdaje się być potwierdzona. Odszedł od nas człowiek, któremu polskiej astronomii amatorskiej możemy zawdzięczyć tak wiele... W naszym hobby każdy przynajmniej raz miał z nim styczność. Janusz Płeszka zmarł w wieku 52 lat.
        • Sad
      • 163 replies
    • Małe porównanie mgławic planetarnych
      Postanowiłem zrobić taki kolaż będący podsumowaniem moich tegorocznych zmagań z mgławicami planetarnymi a jednocześnie pokazujący różnice w wielkości kątowe tych obiektów.
      Wszystkie mgławice na tej składance prezentowałem i opisywałem w formie odrębnych tematów na forum więc nie będę się rozpisywał o każdym obiekcie z osobna - jak ktoś jest zainteresowany szczegółami bez problemu znajdzie fotkę danej mgławicy na forum.
        • Love
        • Thanks
        • Like
      • 22 replies
    • SN 2018hhn - "polska" supernowa w UGC 12222
      Dziś mam przyjemność poinformować, że jest już potwierdzenie - obserwacja spektroskopowa wykonana na 2-metrowym Liverpool Telescope (La Palma, Wyspy Kanaryjskie). Okazuje się, że mamy do czynienia z supernową typu Ia. Poniżej widmo SN 2018hhn z charakterystyczną, silną linią absorpcyjną SiII.
        • Thanks
        • Like
      • 11 replies
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.