• 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

basic_kb

Użytkownik
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

Aktywny użytkownik
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
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.
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
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...
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
Reakcje
0 0 0
#26
gbbsoft napisał(a):
Artee napisał(a):
i oczekiwanie na potwierdzenie
długo? przecież nie ma potwierdzenia...
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

Aktywny użytkownik
Reakcje
11 0 0
#27
Artee napisał(a):
temat ale z tego co oserwowalem na podgladzie i monitoringu to pojawialo sie potwierdzenie (01:04)
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
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...
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
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
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

Aktywny użytkownik
Reakcje
11 0 0
#32
Artee napisał(a):
komenda 0x42 xx xx xx czyli ze specyfikacji Accessory Decoder operation request
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
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"

_________________
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

Aktywny użytkownik
Reakcje
11 0 0
#34
Artee napisał(a):
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.... ?
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
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

Aktywny użytkownik
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
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 ;)
 
Autor wątku Podobne wątki Forum Odpowiedzi Data
DCC 5
DCC 4
DCC 6
DCC 3
DCC 29

Podobne wątki