Pytanie za 100 punktów do programistów

[Duser]

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.....  .

 

[Duser]

Nikt nie wie?

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 .......

 

 

Edytowane 22 Stycznia 2019 przez Duser

[Tayson]

Może Jolo na FA

 

[BlackPitchPL]

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 :))

Edytowane 22 Stycznia 2019 przez BlackPitchPL

[Duser]

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

[BlackPitchPL]

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

[Behlur_Olderys]

12 godzin temu, Duser napisał:

Nikt nie wie?

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ę...

[MateuszW]

8 godzin temu, BlackPitchPL napisał:

Może odpowiem za 60 punktów.

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

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

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?

[Duser]

Problem rozwiązany

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

 

[Piotr4d]

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

[Duser]

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 .