Symulator EU07 (i nie tylko) > Na warsztacie
Sterowanie ruchem przez zewnętrzną aplikację
Paul:
Dzień dobry,
Być może niektórzy znają projekt SCS-1 (Symulacyjne Centrum Sterowania), będący interfejsem operatora i systemem zależnościowym współpracującym z symulatorem TD2, imitującym komputerowe urządzenia srk (nie jest to symulator konkretnego typu urządzeń). Program udostępniony jest na forum TD2 jako załącznik dostępny po zalogowaniu, bez zalogowania można przejrzeć ogólne informacje i dokumentację użytkownika: http://td2.info.pl/index.php/topic,100.0.html
Pierwotnie program powstawał z myślą o Maszynie, która również została dostosowana do takiej formy sterowania, choć dotąd nie było to nigdzie szerzej wykorzystywane. W ostatniej wersji uruchomiona została automatyka nastawiania przebiegów, która pozwala na użycie programu w roli systemu samodzielnie sterującego ruchem na scenerii według wczytanego planu przebiegów, z możliwością interwencji użytkownika w proces sterowania. Mamy zatem coś na kształt VD, którego koncepcja przewijała się na forum już dawno temu. Eventy przestają być używane do realizowania logiki sterowania, a stają się warstwą wykonawczą (przynajmniej jeżeli chodzi o srk). Odpadają problemy typu za wczesne przestawienie zwrotnicy spowodowane za długim składem, ruch na scenerii przestaje być sztywny - dodanie pociągu, zmiana kolejności jazd czy miejsca krzyżowania nie stanowi problemu. Rozwiązanie rozwinąć można o kolejną warstwę, nadrzędną w stosunku do SCS-1, która może zarządzać rozkładem jazdy i dynamicznie generować plan przebiegów (jest on odczytywany z dysku cyklicznie). Oczywiście można też wcielić się w rolę dyżurnego ruchu i sterować ręcznie.
W tym wątku przedstawiam przykład scenerii sterowanej w ten sposób, z Maszyną działają praktycznie wszystkie funkcje przewidziane w programie (m.in. nastawianie przebiegów, pip - śledzenie numerów, przejazdy, sbl, ANP). Niezbędne pliki wraz z samym programem zamieszczone są w załączniku. Otwarta pozostaje kwestia dostosowania plików .inc do sterowania przez program - bez zmian plików oraz pewnych zmian w sceneriach nie będzie to możliwe. Pliki .inc zaprezentowane tutaj mają raczej charakter prowizorki.
Ogólne założenia:
* program SCS-1 uruchamiany jest przed uruchomieniem Maszyny, wybierany jest plik pulpitu, po czym program oczekuje na nawiązanie połączenia, tzn. wywołanie eventu "gotow_<nazwa>" przez Maszynę po uruchomieniu scenerii (na pulpicie przestanie migać białe oznaczenie EU07, pojawi się zielone oraz wyświetlony zostanie właściwy stan zajętości odcinków),
* SCS-1 łączy się z Maszyną komunikatami międzyprocesowymi WM_COPYDATA, w razie potrzeby możliwe jest zastosowanie dodatkowego ogniwa transmisyjnego i uruchomienie SCS-1 na innym komputerze, z połączeniem TCP/IP (uzyskujemy wtedy namiastkę symulacji sieciowej dyżurny - maszynista; nie wiem jak wygląda temat multiplayera z wieloma maszynistami - czy cokolwiek było w tym kierunku robione?),
* sterowanie i kontrola odbywa się na zasadzie zdalnego wywoływania eventów typu multiple oraz detekcji ich wykonania w Maszynie (własnych oraz innych, uruchomionych np. eventami torów), ponadto wykrywane są zajętości odcinków izolowanych - są one wymagane w scenerii (działanie komunikacji można podejrzeć w rejestratorze SCS-1 - uwaga: w trybie testowym logi będą trochę inne),
* z uwagi na nieciągłą komunikację stosowane jest cykliczne kontrolowanie zdalnego wykonywania eventu "gotow_<nazwa>",
* plik pulpitu SCS-1 zawiera graficzny obraz stacji wraz z danymi niezbędnymi do realizacji zależności, plik ten tworzony jest przy pomocy dołączonego edytora,
* obsługa programu jest zbliżona do obsługi komputerowego pulpitu nastawczego, z możliwością automatyzacji w pewnym zakresie.
Rzeczy, które wymagają przedyskutowania/przeróbki/dopracowania:
* brak możliwości sterowania niektórymi obiektami bez modyfikacji plików .inc - zdalnie działają tylko eventy multiple, a niektóre są innych typów (dotyczy większości sygnalizatorów - sterowanie W24, również Sp),
* generalnie konieczność usunięcia z plików .inc obiektów wszelkich uzależnień od torów, innych semaforów, opóźnień zadziałania itp. - zależności realizuje SCS-1 (dotyczy głównie powiązań sygnalizatorów oraz przejazdów),
* konieczność usunięcia ze scenerii wszelkich eventów oddzielnie sterujących obiektami, które sterowane i kontrolowane mają być przez SCS-1,
* konieczność uzupełnienia plików .inc zwrotnic o eventy kontrolujące rozprucia (brak detekcji ewentualnych rozpruć może doprowadzić do nieciekawych efektów),
* wskazane jest uporządkowanie nazw obiektów oraz sposobu ich nadawania w sceneriach, jak również rozmieszczania odcinków izolowanych i eventów używanych jako czujniki ssp (dokumentacja użytkownika zawiera wytyczne co do nazw obiektów).
Możliwe rozwiązania:
* adaptacja plików które zamieściłem w załączniku po drobnych poprawkach - część jest nowa, a część stanowi "nakładki" na stare pliki, wszystkie wymagają sprawdzenia - proszę nie traktować ich jak gotowego rozwiązania do stosowania,
* przygotowanie nowych wersji plików .inc przeznaczonych do zdalnego sterowania z zewnątrz, z uporządkowanymi nazwami eventów, najlepiej o formacie "<obiekt>:<akcja>", podobnie jak przyjęte zostało w TD2 (obecnie zgodne z tą konwencją są tylko eventy "forced+" i "forced-" zwrotnic, pozostałe na ogół używają znaku "_", z kolei zwrotnice i wykolejnice jedynie dodają znak +/-/o/z do nazwy).
Interfejs sterowania używany przez SCS-1 może być wykorzystany również przez inne programy, planuję dostosować kiedyś pod tym kątem symulator ISDR.
Wykaz aktualnie używanych w komunikacji z Maszyną eventów:
a) zwrotnice
* "<nazwazwr>+", "<nazwazwr>-" - przestawienie do położenia "+", "-"; wykonanie eventu jest traktowane jako kontrola wysterowania, z określonym opóźnieniem przyjmowana jest kontrola położenia końcowego,
* "<nazwa>:forced+", "<nazwa>:forced-" - event wykonywany w scenerii gdy zwrotnica zostanie rozpruta i przestawiona przez tabor do położenia "+", "-",
b) wykolejnice
* "<nazwawk>o", "<nazwawk>z" - otwarcie, zamknięcie wykolejnicy, analogicznie jak przestawienie zwrotnicy,
c) sygnalizatory (w tym TOP)
* "<nazwasygn>_<sygnal>" - wyświetlenie sygnału; wykonanie eventu jest traktowane jako kontrola wysterowania; w miejscu <sygnal> pojawia się nazwa sygnału zapisana małymi literami, lub "wyg" - wygaszenie TOP/semafora sbl (sygnalizator ciemny), dla wyświetlenia Sz używane jest oznaczenie "sz1", dla wskaźników W24 - "w24" i "w24off",
d) przejazdy
* "<nazwaprzej>_zamykaj", "<nazwaprzej>_otwieraj" - rozpoczęcie zamykania/otwierania; wykonanie eventu jest traktowane jako kontrola wysterowania, natomiast stan zamknięcia/otwarcia przyjmowany jest z pewnym opóźnieniem (za właściwą sekwencję sterowania sygnalizatorami drogowymi, dzwonem i rogatkami odpowiada już sam .inc),
* "<nazwaprzej>_wj1", "<nazwaprzej>_wj2", "<nazwaprzej>_zw" - w przypadku przejazdu zamykanego czujnikami: wjazd na czujnik zamykający od strony 1, wjazd na czujnik zamykający od strony 2, zjazd ze strefy przejazdu (realizowane jako eventy torów, przy czym "_zw" uruchamiany jest warunkowo po cyklicznym sprawdzaniu stanu toru przez oddzielny plik .inc),
e) odcinki izolowane
* używany jest oddzielny rodzaj komunikatów, bez wykorzystania eventów.
Zawartość załącznika:
* SCS.exe - plik programu, jest to nieznacznie zmodyfikowana wersja 2017.01.07 znana użytkownikom TD2 (poprawione zostały funkcje komunikacji z Maszyną; należy wybrać tryb WM_COPYDATA; z uwagi na rozwojowy charakter powiązania z Maszyną wersję tą traktować należy jako roboczą, a nie stabilną),
* EdytorSCS.exe - edytor pulpitów,
* dokumentacja/ - dokumentacja użytkownika (ta sama co na forum TD2),
* scenery/*.inc - nakładki i zmienione wersje plików .inc przystosowane do sterowania z zewnątrz, oryginalne pliki nie są zmieniane/nadpisywane,
* scenery/anp_test.scn - prosta sceneria przystosowana do sterowania przez SCS-1, zawiera cztery małe posterunki ruchu, jeden przejazd włączany czujnikami, jeden przejazd uzależniony w przebiegach, dwa szlaki jednoodstępowe z ruchem na zasadzie utwierdzania przebiegów oraz jeden szlak z czterostawną, dwukierunkową sbl (uwaga: dla włączenia komunikacji WM_COPYDATA konieczne jest ustawienie multiplayer 1 w eu07.ini),
* anp_test.scs - plik pulpitu dla powyższej scenerii (możliwe jest również uruchomienie programu w trybie testowym, bez Maszyny/TD2, z zajętościami zadawanymi ręcznie),
* anp_test.anp - plan przebiegów, po uruchomieniu którego program automatycznie będzie prowadził pociągi z jednego końca scenerii na drugi, realizując krzyżowania w razie potrzeby (po uruchomieniu SCS-1 i następnie Maszyny należy wczytać i uruchomić plan ANP w SCS-1 oraz wprowadzić numery pociągów w SCS-1 - nieparzyste jadą w prawo, parzyste w lewo, zawiera również pewne zautomatyzowane manewry - więcej informacji w komentarzach w pliku).
Działanie niektórych szczegółów dokładniej opisane jest w dokumentacji użytkownika. Powinno ruszyć bez większych problemów, choć nie testowałem tego na standardowych paczkach całościowych - używam własnej, minimalistycznej "dystrybucji" symulatora na potrzeby testów. Proszę o uwagi na temat rozwiązania plików .inc jak i całego programu oraz możliwości jego zastosowania w Maszynie.
firleju:
Super, moje przemyślenia:
1. Tylko TCP/IP lub inne sposoby komunikacji międzyprocesowej, WM_COPYDATA to nie jest sposób komunikacji.
2. Chciałem od dawna zaimplementować w exe ZeroMQ w tym celu. Wymaga opracowania protokołów danych, ale można wtedy przesyłać wszystko binarnie i w trybie push. Czy jest to do zrobienia w SCS?
3. Chciałbym zupełnie wyrzucić eventy ze sterowania. To też było już dyskutowane wstępnie. Czyli
a. Niskopoziomowo nie uruchamiamy eventów do sterowania srk tylko żądamy konkretnego stanu (ustawienia) dla danego urządzenia. Urządzenie wysyła nam swój stan po zmianie lub na żądanie.
b. Średniopoziomowo to łatwiej by było, gdyby nie trzeba generować tego poziomu w ogóle, czyli SCS sam tworzy na swoje potrzeby ten poziom za pomocą parsera scenerii podczas wczytywania.
c. Wysokopoziomowo żeby to zaimplementować jest potrzebny element sterowania scenariuszem: czyli wyznaczanie przebiegów jak i wysyłanie poleceń do pojazdów (zmień kierunek, odepnij się od wagonów i takie tam). To co teraz jest robione za pomocą sygnałów co jest ogólnie chorym pomysłem z punktu widzenia architekturalnego.
Do poziomu 3b da się zrobić multiplayera. Żeby zmienić sposób sterowania niestety 3c jest niezbędny co wcale nie będzie łatwe ale jak najbardziej wykonalne.
El Mecánico:
@Paul: a czy Testowo dało by się do tego modyfikować? IMO pulpit kostkowy wydaje się być bardziej elastyczny w konstrukcji (zarówno w pamięci komputera jak i namacalnego pulpitu dla chętnych) i podpięciu do symka jako źródła danych o ruchu pojazdów.
Mariusz1970:
No ja sie bede musial troche napocic, aby to uruchomic, ze wzgledu na stara paczke calosciowa, ale mam pytanko pawle (sorry, ze z malej litery, ale klawa w telefonie zepsuta). Mianowicie, zauwazylem, iz zwrotnice w scenerii maja geometrie bliska linii prostej. Dopiero do koncowek zwrotnicy, masz odpowiednio wygiete tory. Dlaczego tak? Ja sobie wytlumaczylem, iz w ten sposob zwrotnice sa uniwerslane (np. predkosci), a dopiero tory dolaczone do koncowek, decyduja o typie zwrotnicy. W sumie jesli mam racje, to sprytnie wykombinowane, ale z drugiej strony, to juz sam nie wiem, czy lepsze szablony, czy twoj sposob.
Paul:
--- Cytat: firleju w 13 Stycznia 2017, 08:12:05 ---1. Tylko TCP/IP lub inne sposoby komunikacji międzyprocesowej, WM_COPYDATA to nie jest sposób komunikacji.
2. Chciałem od dawna zaimplementować w exe ZeroMQ w tym celu. Wymaga opracowania protokołów danych, ale można wtedy przesyłać wszystko binarnie i w trybie push. Czy jest to do zrobienia w SCS?
--- Koniec cytatu ---
W obecnym rozwiązaniu stosowane jest WM_COPYDATA, ponieważ zostało już wcześniej przewidziane w Maszynie do takich celów i radzi sobie całkiem dobrze. WM_COPYDATA przewiduje ponadto kilka innych funkcji nieużywanych przez SCS.
Dla zdalnego sterowania docelowo proponuję tekstowe TCP/IP z uwagi na prostotę i możliwość sterowania z innego komputera (Maszyna w roli serwera TCP/IP, tak jak działa to dla TD2). Idealnie było by uzyskać protokół jak najbardziej ujednolicony dla obu obecnie obsługiwanych symulatorów (Maszyna i TD2) - dla TD2 powstawał od zera, bez bałaganu narzuconego przez stare pliki i warto to wykorzystać (notacja "<obiekt>:<akcja>"). Chyba że ZeroMQ również sobie poradzi przez sieć i posiada jakieś istotne zalety w porównaniu do komunikatów TCP/IP.
--- Cytat: firleju w 13 Stycznia 2017, 08:12:05 ---3. Chciałbym zupełnie wyrzucić eventy ze sterowania. To też było już dyskutowane wstępnie. Czyli
a. Niskopoziomowo nie uruchamiamy eventów do sterowania srk tylko żądamy konkretnego stanu (ustawienia) dla danego urządzenia. Urządzenie wysyła nam swój stan po zmianie lub na żądanie.
--- Koniec cytatu ---
Jeżeli eventy z Maszyny zostaną usunięte i zastąpione innym rozwiązaniem, dostosowanie SCS nie będzie większym problemem (pod warunkiem, że jakieś istotne sygnały/stany nie zostaną pominięte).
--- Cytat: firleju w 13 Stycznia 2017, 08:12:05 ---b. Średniopoziomowo to łatwiej by było, gdyby nie trzeba generować tego poziomu w ogóle, czyli SCS sam tworzy na swoje potrzeby ten poziom za pomocą parsera scenerii podczas wczytywania.
--- Koniec cytatu ---
SCS automatyzuje zależności tam gdzie to możliwe, ale nadal niektóre parametry trzeba wprowadzić ręcznie (wszelkie nietypowe uzależnienia i dane których nie da się odgadnąć z samego kształtu układu torowego). Generowanie danych dla tej warstwy automatycznie, wprost ze scenerii będzie i tak wymagało wprowadzania tych parametrów dla obiektów scenerii, co niekoniecznie będzie bardziej wygodne od ich wprowadzenia w przeznaczonym do tego edytorze. Ponadto automat nie wygeneruje estetycznie wyglądającego schematu układu torowego.
--- Cytat: firleju w 13 Stycznia 2017, 08:12:05 ---c. Wysokopoziomowo żeby to zaimplementować jest potrzebny element sterowania scenariuszem: czyli wyznaczanie przebiegów jak i wysyłanie poleceń do pojazdów (zmień kierunek, odepnij się od wagonów i takie tam). To co teraz jest robione za pomocą sygnałów co jest ogólnie chorym pomysłem z punktu widzenia architekturalnego.
--- Koniec cytatu ---
W podanym rozwiązaniu w pliku .anp definiowane jest, które przebiegi są wjazdowe i wyjazdowe dla poszczególnych posterunków, czy też w zależności od kategorii pociągu, manewry itp. Po przyjęciu przejrzystej notacji dla tych przebiegów warstwa wyżej może zająć się już ściśle rozkładem jazdy, bez zastanawiania się jakie konkretnie przebiegi nastawiać, oraz ewentualnymi poleceniami dla pojazdów typu połącz/odłącz - choć te myślałem "doklejać" do definicji przebiegów w planie .anp (typu - gdy pociąg X wjedzie na stację A, ustaw manewr za semafor wyjazdowy i jednocześnie każ odłączyć lokomotywę).
--- Cytat: El Mecánico w 13 Stycznia 2017, 12:25:13 ---@Paul: a czy Testowo dało by się do tego modyfikować? IMO pulpit kostkowy wydaje się być bardziej elastyczny w konstrukcji (zarówno w pamięci komputera jak i namacalnego pulpitu dla chętnych) i podpięciu do symka jako źródła danych o ruchu pojazdów.
--- Koniec cytatu ---
Jest możliwe podłączenie do opisanego interfejsu symulatora urządzeń przekaźnikowych, ale raczej jako symulator urządzeń przekaźnikowych, a nie kompleksowe narzędzie zarządzania i sterowania ruchem w scenerii. Pulpit kostkowy jest bardziej pracochłonny do przygotowania (tu mamy zróżnicowane szczegóły graficzne kostek, różne przyciski dla poszczególnych obiektów, natomiast w wersji komputerowej w zasadzie obiekty i łączące je linie), dla dużych odcinków sterowania będzie niezbyt przejrzysty i kiepsko nadaje się do automatyzacji. Można niby zrobić to samo co w SCS, wyglądające z grubsza jak pulpit kostkowy, ale powstanie twór który nie istnieje w rzeczywistości - tymczasem interfejs graficzny i sposób działania SCS wzorowany jest na rzeczywistych centrach sterowania.
--- Cytat: Mariusz1970 w 13 Stycznia 2017, 13:23:26 ---Mianowicie, zauwazylem, iz zwrotnice w scenerii maja geometrie bliska linii prostej. Dopiero do koncowek zwrotnicy, masz odpowiednio wygiete tory.
--- Koniec cytatu ---
Rozjazd złożony jest tu z części zwrotnicy - mniej więcej o rzeczywistej długości iglic - oraz odcinków stanowiących resztę. Obie części są łukiem o promieniu 300 m. Nietypowy format rozjazdów wynika z tego, że sceneria jest eksportem z edytora którego zasadniczo używam do ISDR.
Nawigacja
[#] Następna strona
Idź do wersji pełnej