• Ten serwis używa "ciasteczek" (cookies). Korzystając z niego, wyrażasz zgodę na użycie plików cookies. Learn more.
  • Szanowny Użytkowniku, serwisy w domenie modelarstwo.info wykorzystują pliki cookie by ułatwić korzystanie z naszych serwisów. Jeśli nie chcesz, by pliki cookies były zapisywane na Twoim dysku zmień ustawienia swojej przeglądarki.

Sterowanie z GBB i pierwsze problemy

B

basic_kb

Użytkownik
#21
Reakcje
0 0 0
#21
Sprawdź czy dziala z tym http://wiki.rocrail.net co prawda to nie GBB ale za darmo i daje sie uruchomić bez wiekszych problemów.

Pozdrawiam
Basic_KB
 
gbbsoft

gbbsoft

Aktywny użytkownik
#22
Reakcje
11 0 0
#22
Właśnie... Sprawdź z jakimś innym softem...
W najgorszym razie mogę wstawić jakieś opóźnienie, aby program nie wysyłał tyle danych na raz...

Niestety protokół LI-101F ma tą wadę, że dla pewnej grupy rozkazów interfejs nie transmituje zwrotnie żadnych potwierdzeń. Więc program ma prawo wysyłać kolejne rozkazy dalej.

W LI-USB zmieniono protokół i po każdym rozkazie zawsze jest potwierdzenie: albo z centralki, a jeżeli XPressNet takiego nie przewiduje, to LI-USB generuje "wirtualne" potwierdzenie przesłania komendy dalej. W ten sposób niejako LI-USB może sterować programem, aby ten nie wysyłał kolej komendy nim poprzednia nie zostanie obsłużona.

Może być tak, że GenLI po prostu nie był nigdy testowany na taki zalew komend i ma zwyczajnie błąd. Spróbuj np: wysłać dużą ilość komend zmiany prędkości (np: przy 126 krokach)...

Komenda 52:AA:8D:XX (zmiana wyjścia w dekoderze akcesoriów) jest właśnie taką komendą, dla której wg specyfikacji nie jest przewidziane przysłanie potwierdzenia. Nawet otrzymanie negatywnego potwierdzenia nie bardzo wiadomo do której komendy dotyczy, jak się wysłało najpierw n komend...
 
OP
OP
Artee

Artee

Użytkownik
#23
Reakcje
0 0 0
#23
basic_kb napisał(a):
Sprawdź czy dziala z tym http://wiki.rocrail.net co prawda to nie GBB ale za darmo i daje sie uruchomić bez wiekszych problemów.
Kliknij by rozszerzyć..
Zainstalowałem, uruchomiłem ale nic tym nie wysterowałem. Wyrzuca mi timeout on serial port i ze odzytal tylko 1 z 4.
Wiec chyba to problem z tym GenLi. Już sam nie wiem.
W GBB większość chodziła. Tutaj już wogóle nic.
 
OP
OP
Artee

Artee

Użytkownik
#24
Reakcje
0 0 0
#24
gbbsoft napisał(a):
W najgorszym razie mogę wstawić jakieś opóźnienie, aby program nie wysyłał tyle danych na raz...
Kliknij by rozszerzyć..
Duża szansa, że to by pomogło. Wysyłąnie 1 maks 2 komend i oczekiwanie na potwierdzenie. Jeśli nie wymaga to zbyt wielkich nakładów to wdzięczny byłbym bardzo :) To póki co dla mnie ostatnia szansa.
 
OP
OP
Artee

Artee

Użytkownik
#26
Reakcje
0 0 0
#26
gbbsoft napisał(a):
Artee napisał(a):
i oczekiwanie na potwierdzenie
Kliknij by rozszerzyć..
długo? przecież nie ma potwierdzenia...
Kliknij by rozszerzyć..
Hmmm. Dokladnie nie znam specyfikacji XpressNeta i całosci sterowania,dopiero "wgryzam" się w temat ale z tego co oserwowalem na podgladzie i monitoringu to pojawialo sie potwierdzenie (01:04). Ale ono jest chyba generowane przez LI100...no nie wiem :???:

To może wprowadzić po prostu opcje "opóźnienie pomiedzy wysłąniem kolejnych rozkazów" które byłoby regulowane i wtedy doświadczalnie można by sprawdzić czy jego zastosowanie rozwiąże problem.
 
gbbsoft

gbbsoft

Aktywny użytkownik
#27
Reakcje
11 0 0
#27
Artee napisał(a):
temat ale z tego co oserwowalem na podgladzie i monitoringu to pojawialo sie potwierdzenie (01:04)
Kliknij by rozszerzyć..
tylko, że... to nie jest zgodne ze specyfikacją... To pewnie jest jakiś dodatek zrobiony w GenLI, aby rozwiązać jakiś (może ten) problem, tylko czy aby na pewno? Masz to gdzieś opisane czarno-na-białym? Jakbym dodał takie założenie, to mogło by przestać działać współpraca z oryginalnym LI-101F, a takie użytkownicy (jeszcze) mają.
Bardziej mi się podoba pomysł opóźnienia po każdym rozkazie, który nie wysyła potwierdzenia...

A nie możesz zrobić takiego GenLI, aby komunikował się protokołem zgodnym z LI-USB? To jest zdecydowanie lepszy protokół niż protokół LI-101F...

PS. W chwili wolnej zrobię parametr opóźnienia w msek - domyślnie będzie 0 - czyli brak opóźnienia.
 
OP
OP
Artee

Artee

Użytkownik
#28
Reakcje
0 0 0
#28
gbbsoft napisał(a):
A nie możesz zrobić takiego GenLI, aby komunikował się protokołem zgodnym z LI-USB? To jest zdecydowanie lepszy protokół niż protokół LI-101F...
Kliknij by rozszerzyć..
I bym zrobił....tylko, że ja jestem hardware-owcem i ze sprzętu moge zrobić dużo, ale jeśli chodzi o sfere programową to moje możliwości są niewielkie, jakieś proste sterowniki do syntez, przełączniki A/V i tego typu proste rzeczy :neutral:
A nie da sie zrobić tutaj nic bez odpowiedniego softwaru dla np. mikrokontrolera. I tu niestety sam nie poradzę.
Gdy znajde jakiś gotowiec tak jak ten co mam to zrobię ale póki co nic z tego :sad:
 
OP
OP
Artee

Artee

Użytkownik
#29
Reakcje
0 0 0
#29
Siedziałem do późna w nocy, przestudiowałem specyfikację i zaczałem testy sprzętu przez ręczne wysyłanie z programu do obsługi portu COM komend sterujących. Póki co sterowałem tylko dekoderem akcesoriów ale w końcu wyczaiłem jak dziłała ta komenda. Zauważyłem też że centralka ROCO odpowiada na niektóre komendy poleceniem odpytującym o stan dekodera. Ale tylko w niektórych przypadkach. Zauważyłęm też kilka innych ciekawych dla mnie zjawisk, które nie wiem z czego wynikaja. Czy z GenLi czy centrlaki ROCO. Jednym słowe po wczorajszym jestem dużo mądrzejszy w temacie sterowania :grin:
 
OP
OP
Artee

Artee

Użytkownik
#31
Reakcje
0 0 0
#31
Źle napisałem. Zestw GenLi z Centralką odpowiada. Czyli nie koniecznie ROCO tylko może GenLi. A dokładnie chodzi o to że po wysłaniu komendy 0x52 xx xx xx w niektórych przypadkach zostaje mi odełana na COM komenda 0x42 xx xx xx czyli ze specyfikacji Accessory Decoder information request. Tylko nie wiem czemu tylko w pewnym zakresie trzeciego bajtu w komendzie 0x52 ta odpowiedż przychodzi.
 
gbbsoft

gbbsoft

Aktywny użytkownik
#32
Reakcje
11 0 0
#32
Artee napisał(a):
komenda 0x42 xx xx xx czyli ze specyfikacji Accessory Decoder operation request
Kliknij by rozszerzyć..
0x42 to jest to, co piszesz, ale tylko jak jest wysyłane od urządzenia do centralki.

Jak centralka wysyła 0x42 do urządzenia, to jest to "Feedback Broadcast"
;)
 
OP
OP
Artee

Artee

Użytkownik
#33
Reakcje
0 0 0
#33
gbbsoft napisał(a):
0x42 to jest to, co piszesz, ale tylko jak jest wysyłane od urządzenia do centralki.

Jak centralka wysyła 0x42 do urządzenia, to jest to "Feedback Broadcast"

_________________
Kliknij by rozszerzyć..
Być może. Ale czemu jak wysyłałem polecenie hex 52:04:80 do 8f (no i Xor) to w zakresie 80-87 nie ma tego a 88-8F dostaje odpowiedź z cyklu 0x42.... ?
Zresztą zapisałem sobie tabelke co wyslalem co otrzymalem i jaka byla reakcja dekodera.
 
gbbsoft

gbbsoft

Aktywny użytkownik
#34
Reakcje
11 0 0
#34
Artee napisał(a):
Ale czemu
Kliknij by rozszerzyć..
nie wiem... Pamiętaj że centralka Roco nie jest wyrocznią. Wyrocznia jest centralka Lenz'a. Centralka Roco robi jeszcze kilka innych dziwnych rzeczy poza specyfikacją robi. Np: manipulatory same sobie nadają adresy... A pakiety, które to obsługuja mają skopaną sume kontrolną - specjalnie, aby "porządne" urządzenia działające wg specyfikacji XPRessNet zawsze je odrzucały, jako błedne... W sumie - ciakawa metoda... tylko że niestandardowa...

Artee napisał(a):
Ale czemu jak wysyłałem polecenie hex 52:04:80 do 8f (no i Xor) to w zakresie 80-87 nie ma tego a 88-8F dostaje odpowiedź z cyklu 0x42.... ?
Kliknij by rozszerzyć..
Popatrz dokładnie w specyfikacje. W ostatnim bajcie cztery niższe bity należy rozpisać bit po bicie na D1, B1, B0 i D2. Zauwazych wtedy, że 80-87 to bit D1=0, a dla 88-8f masz D1=1.

Więc: dostajesz potwierdzenia, gdy wysyłasz rozkaz wyłaczenia wyjścia w dekoderze.
 
OP
OP
Artee

Artee

Użytkownik
#35
Reakcje
0 0 0
#35
PRzeczytam całą specyfikację to zobaczę wtedy czego jeszcze nie rozumiem :) Ale takie testy z wysyłaniem poleceń wiele mi dały w zrozumieniu funkcjonowania moich dekoderów.

Odnośnie problemu z błędami w komunikacji GBB GenLi to poprawnie chodzi kiedy w jednym ciagu wysyłane sa dwie komendy mamksymalnie. Przy większej ilosći już sie gubi. Myślę, że to opóźnienie o którym pisaliśmy może rozwiązać problem.
 
gbbsoft

gbbsoft

Aktywny użytkownik
#36
Reakcje
11 0 0
#36
Wystawiłem nową wersję testową, w które dodałem w konfiguracji systemu DCC Lenz'a parametr umożliwiający określenie wielkości opóźnienia po wysłaniu komendy nie wymagającej potwierdzenia. Domyślnie ten parametr ma wartość 0, co nie powoduje żadnych opóźnień. Ponieważ nie posiadam już interfejsu LI-101F, to prosiłbym o sprawdzenie, czy ten parametr w ogóle działa (np: ustawić 1s i poobserwować log komunikacji z DCC) oraz jaki jest optymalna wartość tego parametru dla GenLI. Wtedy dodam nowy system DCC "GenLI", który będzie automatycznie ustawiał wartość tego parametru, aby kolejni użytkownicy nie musieli robić ponownie doświadczeń.
 
OP
OP
Artee

Artee

Użytkownik
#37
Reakcje
0 0 0
#37
Ok. Przetestuje dokladnie jutro. Tylko link jaki rozumiem mial byc przy słowie "testową" chyba się nie wczytał bo kursor nie reaguje ;)
 
Musisz być zalogowany, żeby tu odpowiedzieć.
Autor wątku Podobne wątki Forum Odpowiedzi Data
T
Sterowanie z21 i gbbkolejka DCC 5
Larry
Gbbkolejka - sterowanie makietą z kompa DCC 4
F
Sterowanie DCC 6
arch_przemo
Sterowanie rozjazdami w Piko Digi1 DCC 3
T
Sterowanie cyfrowe obrotnicą DCC 29

Podobne wątki