Symulator EU07 (i nie tylko) > Na warsztacie
Sterowanie ruchem przez zewnętrzną aplikację
firleju:
--- Cytat: Paul w 13 Stycznia 2017, 13:30:20 ---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.
--- Koniec cytatu ---
WM_COPYDATA zostanie zapewne jeszcze przez jakiś czas z nami. ZMQ działa na TCP/IP. To jest po prostu mechanizm kolejkowania, buforowania i zapewniania dotarcia wiadomości do nadawcy. W niego można jak najbardziej wsadzić dowolną treść i nie dekodujesz komunikatu TCP tylko obiekt daje Ci event do przepracowania jak przyjdzie wiadomość. Notacja może zostać jeśli to jest jakiś problem aczkolwiek widzę problem przypisywania wtedy do SCS logiki SRK każdego elementu wykonawczego, np sem_f:s1 co jest troszkę bez sensu. Lepiej byłoby mieć elementy wykonawcze po stronie exe. Chodzi mi o to, że SCS wysyła wtedy co dokładnie chce mieć wyświetlone zamiast co chce osiągnąć.
--- Cytat: Paul w 13 Stycznia 2017, 13:30:20 ---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).
--- Koniec cytatu ---
Co znaczy istotne sygnały/stany?
--- Cytat: Paul w 13 Stycznia 2017, 13:30:20 ---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.
--- Koniec cytatu ---
Ładny wygląd jest potrzebny do zabawy w dyżurnego. Do sterowania może nie być nawet nic wyświetlane. Ale rozumiem, że to może nie być najprostsze.
Edytor jest tak łopatologiczny, żeby przeciętna osoba się obsłużyła w nim nie znając do końca przepisów?
--- Cytat: Paul w 13 Stycznia 2017, 13:30:20 ---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ę).
--- Koniec cytatu ---
Warstwa wyżej powinna mieć informacje o torze podstawowym i ewentualnych alternatywach na danej stacji. Pliki dla przebiegów powinny umożliwiać napisanie na nim dowolnego scenariusza, czyli wszelkie sterowanie pojazdami bezpośrednio odpada w takim przypadku. Jeśli w SCS masz informacje o tym na którym torze masz dany pociąg to możesz z VD dawać polecenie dla pociągu tego na tej stacji podstawowy tor to 1, a alternatywne 3 i 5. Na tej podstawie SCS wie czy pociąg jest na parzystym / nieparzystym na szlaku i na które tory może wjechać pociąg. Chyba, że wolisz to wyrzucić do góry. Ale wtedy VD musi mieć tą informację i wysyłać do SCS polecenia ustawienia poszczególnych przebiegów.
--- Cytat: Paul w 13 Stycznia 2017, 13:30:20 ---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.
--- Koniec cytatu ---
Pulpit kostkowy nadaje się do odwzorowania obwodów poszczególnych posterunków / najwyżej stacji. Nie całej scenerii. Aczkolwiek wydaje mi się, że można to zrobić jako nakładka do zabawy dla dyżurnego, tak samo jak rysujesz schematy dla komputerowych.
Paul:
--- Cytat: firleju w 13 Stycznia 2017, 14:22:14 ---WM_COPYDATA zostanie zapewne jeszcze przez jakiś czas z nami. ZMQ działa na TCP/IP. To jest po prostu mechanizm kolejkowania, buforowania i zapewniania dotarcia wiadomości do nadawcy. W niego można jak najbardziej wsadzić dowolną treść i nie dekodujesz komunikatu TCP tylko obiekt daje Ci event do przepracowania jak przyjdzie wiadomość.
--- Koniec cytatu ---
Tak czy inaczej używam bibliotek które załatwiają sprawy sieciowe, sama logika SCS wysyła/dostaje gotowy komunikat tekstowy i nie interesuje się, czy to było TCP/IP, WM_COPYDATA, zapętlenie w trybie testowym czy coś innego. W razie potrzeby mogę je rozszerzyć o ZMQ.
--- Cytat: firleju w 13 Stycznia 2017, 14:22:14 ---Notacja może zostać jeśli to jest jakiś problem aczkolwiek widzę problem przypisywania wtedy do SCS logiki SRK każdego elementu wykonawczego, np sem_f:s1 co jest troszkę bez sensu.
--- Koniec cytatu ---
Pozostawienie starych nazw eventów nie jest problemem, jednak skoro piszesz że eventy zostaną całkiem usunięte, to może warto przy okazji uporządkować nazwy komunikatów dla obiektów srk.
--- Cytat: firleju w 13 Stycznia 2017, 14:22:14 ---Co znaczy istotne sygnały/stany?
--- Koniec cytatu ---
Chodziło mi o zachowanie zakresu obecnie używanych w komunikacji SCS - Maszyna komunikatów (stany urządzeń oczywiście mają charakter pseudo-ciągły, bez ciągłej kontroli), tak aby nie okazało się, że po zmianie rozwiązania na dole będzie czegoś brakować do poprawnego działania.
--- Cytat: firleju w 13 Stycznia 2017, 14:22:14 ---Ładny wygląd jest potrzebny do zabawy w dyżurnego. Do sterowania może nie być nawet nic wyświetlane. Ale rozumiem, że to może nie być najprostsze.
Edytor jest tak łopatologiczny, żeby przeciętna osoba się obsłużyła w nim nie znając do końca przepisów?
--- Koniec cytatu ---
Czytelny graficzny interfejs, jeżeli nawet wykluczamy ręczną obsługę jako dyżurny ruchu, bardzo ułatwi choćby testowanie na sucho działania systemu dla danej scenerii.
Edytor jest dość łopatologiczny, ale trzeba mieć minimum wiedzy na temat srk i ruchu aby zrobić porządny plik pulpitu (system sygnalizacji, logika zależnościowa, niektóre reguły rozmieszczania urządzeń srk itp.). Moim zdaniem nie da rady wiele dalej zautomatyzować tworzenia danych zależnościowych, chyba że kosztem odejścia od realizmu sterowania (typu ustawianie przebiegów które nie mają sensu lub pomijanie pewnych zależności). Zakładam, że do tworzenia scenerii czy danych do sterowania niezbędna jest znajomość przynajmniej podstawowych przepisów - w przeciwnym razie powstawać będą buble.
--- Cytat: firleju w 13 Stycznia 2017, 14:22:14 ---Warstwa wyżej powinna mieć informacje o torze podstawowym i ewentualnych alternatywach na danej stacji. Pliki dla przebiegów powinny umożliwiać napisanie na nim dowolnego scenariusza, czyli wszelkie sterowanie pojazdami bezpośrednio odpada w takim przypadku. Jeśli w SCS masz informacje o tym na którym torze masz dany pociąg to możesz z VD dawać polecenie dla pociągu tego na tej stacji podstawowy tor to 1, a alternatywne 3 i 5. Na tej podstawie SCS wie czy pociąg jest na parzystym / nieparzystym na szlaku i na które tory może wjechać pociąg. Chyba, że wolisz to wyrzucić do góry. Ale wtedy VD musi mieć tą informację i wysyłać do SCS polecenia ustawienia poszczególnych przebiegów.
--- Koniec cytatu ---
W obecnym rozwiązaniu zakładam, że warstwa nadrzędna informuje SCS, w którym kierunku i o której godzinie dany pociąg ma jechać, oraz w razie potrzeby na które tory może zostać przyjęty. Czyli generalnie zajmuje się dostarczeniem danych zawartych w rozkładzie jazdy. Jeżeli możliwa jest pewna dowolność jazd, wybór toru odbywa się już w SCS zależnie od stanu i dostępności elementów infrastruktury. Czyli warstwa nadrzędna w zasadzie planuje ruch bez kontroli wykonania planu, choć nie wykluczam dodania przepływu informacji z SCS do góry (lokalizacja pociągów, dostępność torów) gdyby było to potrzebne.
El Mecánico:
Odnośnie przekazywania informacji pomiędzy aplikacjami/komputerami. O ile na jednej maszynie fizycznej między różnymi aplikacjami można wykorzystać mechanizm stosowany w D-Bus (który nawet ma porta na winde), to przy sieci trzeba po prostu znaleźć albo coś podobnego, ale sposób na tunelowanie D-Bus.
firleju:
Paul, wydaje mi się, że mieszasz w SCS funkcjonalność dwóch różnych warstw. Jeśli w SCS będzie już wybór konkretnego toru z dostępnych to albo będziesz mieć bardzo skomplikowany algorytm wyboru torów dla kolejnych pociągów, żeby to było elastyczne i przewidywało przyszłość, albo oddajesz to autorowi scenariusza. Jeśli to drugie to powodujesz, że pliki układu torowego nie będą przypisane do scenerii tylko scenariusza, czy dokładnie to samo co mamy teraz i z czego chcemy zejść.
Oczywiście obowiązkowe wpisanie na które tory pociąg może wjechać wielce upraszcza algorytm sterowania nie komplikując przesadnie pracy scenarzysty.
El, ZMQ jest o tyle fajne, że automatycznie wybiera sposób przesyłania danych zależnie od tego gdzie jest uruchomiony drugi program. Jeśli na tej samej maszynie to wybiera np. D-Busa, jeśli gdzieś w necie to TCP.
Paul:
To jest rozdzielone. Podstawowo SCS odpowiada za kontrolę scenerii, realizację zależności i sterowanie (nastawianie przebiegów, sygnały, sterowanie przejazdami itp.) na podstawie pliku .scs, przypisanego do scenerii, nie zawierającego danych dla konkretnych scenariuszy. Przy użyciu tylko tego pliku można jedynie sterować ręcznie.
Nakładką na to jest funkcja ANP, która automatycznie nastawia przebiegi na podstawie pliku .anp, w którym definiowane jest, kiedy i dla jakich pociągów jakie ma nastawiać przebiegi. Plik ten przypisany jest do scenariusza i wybierany opcjonalnie po uruchomieniu SCS z daną scenerią. W tym pliku możliwe jest zdefiniowanie przebiegów z grupy torów/na grupę, dzięki czemu w razie niedostępności jednego toru, przebieg nastawiony zostanie na inny. Nie jest to jednak obowiązkowe - można zdefiniować przebieg tylko na jeden tor.
Plik .anp może zawierać reguły ogólne, np. przepychanie wszystkich pociągów parzystych/nieparzystych w określonych kierunkach bez zdefiniowanych godzin, może również zawierać reguły dla konkretnego pociągu z uwzględnieniem godzin odjazdu. Ponieważ SCS przeładowuje ten plik w cyklu pracy ANP (co ok. 10 s), może być on na bieżąco modyfikowany ręcznie lub przez inną aplikację, która stanowiłaby interfejs do wprowadzania rozkładu jazdy czy też sama zarządzałaby ruchem.
Nawigacja
[#] Następna strona
Idź do wersji pełnej