Autor Wątek:  Sterowanie ruchem przez zewnętrzną aplikację  (Przeczytany 36629 razy)

0 użytkowników i 1 Gość przegląda ten wątek.

Offline Paul

  • Zasłużony dla Symulatora
  • Wiadomości: 523
    • Zobacz profil
    • Beskidzka Strona Kolejowa
  • Otrzymane polubienia: 16
Sterowanie ruchem przez zewnętrzną aplikację
« dnia: 13 Stycznia 2017, 00:48:09 »
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.
automatyka sterowania ruchem kolejowym rox
www.isdr.pl | www.bsk.isdr.pl | pokrzesik.wytnij@gmail.com

Offline firleju

  • Zasłużony dla Symulatora
  • Wiadomości: 1588
  • bawię się (w) exe...
    • Zobacz profil
  • Otrzymane polubienia: 121
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #1 dnia: 13 Stycznia 2017, 08:12:05 »
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.
Skrypty do Blendera dostępne tutaj
W miarę aktualne wiki EXE wiki.eu07.es

Offline El Mecánico

  • Wiadomości: 1067
  • Dawniej El Driver
    • Zobacz profil
    • Stowarzyszenie POLARIS - OPP
  • Otrzymane polubienia: 2
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #2 dnia: 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.
www.polaris.org.pl
www.ciemneniebo.pl
MaSzyna_LD w trakcie tworzenia...

Offline Mariusz1970

  • Zasłużony dla Symulatora
  • Wiadomości: 3931
    • Zobacz profil
  • Otrzymane polubienia: 288
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #3 dnia: 13 Stycznia 2017, 13:23:26 »
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.

Offline Paul

  • Zasłużony dla Symulatora
  • Wiadomości: 523
    • Zobacz profil
    • Beskidzka Strona Kolejowa
  • Otrzymane polubienia: 16
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #4 dnia: 13 Stycznia 2017, 13:30:20 »
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?

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.

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.

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

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.

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.

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.

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

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

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.

Mianowicie, zauwazylem, iz zwrotnice w scenerii maja geometrie bliska linii prostej. Dopiero do koncowek zwrotnicy, masz odpowiednio wygiete tory.

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.
automatyka sterowania ruchem kolejowym rox
www.isdr.pl | www.bsk.isdr.pl | pokrzesik.wytnij@gmail.com

Offline firleju

  • Zasłużony dla Symulatora
  • Wiadomości: 1588
  • bawię się (w) exe...
    • Zobacz profil
  • Otrzymane polubienia: 121
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #5 dnia: 13 Stycznia 2017, 14:22:14 »
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.
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ąć.
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).
Co znaczy istotne sygnały/stany?
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.
Ł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?
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ę).
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.
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.
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.
« Ostatnia zmiana: 13 Stycznia 2017, 14:23:20 wysłana przez firleju »
Skrypty do Blendera dostępne tutaj
W miarę aktualne wiki EXE wiki.eu07.es

Offline Paul

  • Zasłużony dla Symulatora
  • Wiadomości: 523
    • Zobacz profil
    • Beskidzka Strona Kolejowa
  • Otrzymane polubienia: 16
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #6 dnia: 13 Stycznia 2017, 15:02:36 »
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ść.

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.

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.

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.

Co znaczy istotne sygnały/stany?

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.

Ł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?

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.

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.

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.
automatyka sterowania ruchem kolejowym rox
www.isdr.pl | www.bsk.isdr.pl | pokrzesik.wytnij@gmail.com

Offline El Mecánico

  • Wiadomości: 1067
  • Dawniej El Driver
    • Zobacz profil
    • Stowarzyszenie POLARIS - OPP
  • Otrzymane polubienia: 2
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #7 dnia: 14 Stycznia 2017, 12:43:03 »
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.
www.polaris.org.pl
www.ciemneniebo.pl
MaSzyna_LD w trakcie tworzenia...

Offline firleju

  • Zasłużony dla Symulatora
  • Wiadomości: 1588
  • bawię się (w) exe...
    • Zobacz profil
  • Otrzymane polubienia: 121
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #8 dnia: 16 Stycznia 2017, 10:10:01 »
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.
Skrypty do Blendera dostępne tutaj
W miarę aktualne wiki EXE wiki.eu07.es

Offline Paul

  • Zasłużony dla Symulatora
  • Wiadomości: 523
    • Zobacz profil
    • Beskidzka Strona Kolejowa
  • Otrzymane polubienia: 16
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #9 dnia: 16 Stycznia 2017, 12:20:05 »
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.
automatyka sterowania ruchem kolejowym rox
www.isdr.pl | www.bsk.isdr.pl | pokrzesik.wytnij@gmail.com

Offline El Mecánico

  • Wiadomości: 1067
  • Dawniej El Driver
    • Zobacz profil
    • Stowarzyszenie POLARIS - OPP
  • Otrzymane polubienia: 2
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #10 dnia: 16 Stycznia 2017, 15:08:53 »
A czy możliwe było by przypinanie do poszczególnych stacji/podg (a nawet okręgów) osobnych .anp? Bo z tego co mi z tego topic'u wychodzi, to pojawia się możliwość włączenia do symulacji jednocześnie kilku "graczy" na stanowiska dyżurnych ruchu, więc dobrze by było, żeby sobie w paradę nie włazili :D
www.polaris.org.pl
www.ciemneniebo.pl
MaSzyna_LD w trakcie tworzenia...

Offline Paul

  • Zasłużony dla Symulatora
  • Wiadomości: 523
    • Zobacz profil
    • Beskidzka Strona Kolejowa
  • Otrzymane polubienia: 16
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #11 dnia: 16 Stycznia 2017, 15:27:02 »
W obecnym rozwiązaniu SCS obsługuje jedno stanowisko operatorskie, więc włączenie kilku dyżurnych ruchu będzie polegać na uruchomieniu kilku niezależnych instancji SCS. Każda oczywiście może mieć własny plik .anp.

Z tym, że Maszyna wymienia komunikaty z jednym zewnętrznym programem. Dla uruchomienia kilku SCS trzeba by dodać do tego prosty serwer uruchamiany wraz z Maszyną, który będzie wymieniał z nią komunikaty WM_COPYDATA i przekazywał je do poszczególnych klientów dyżurnych ruchu np. przez TCP/IP. Rozwiązanie obecnie możliwe i proste do zrobienia, ale będzie miało charakter prowizoryczny - zakłada tylko jedną maszynę z Maszyną, docelowo trzeba by pomyśleć jak w to włączyć innych maszynistów. Ale to już po stronie exe Maszyny.
automatyka sterowania ruchem kolejowym rox
www.isdr.pl | www.bsk.isdr.pl | pokrzesik.wytnij@gmail.com

Offline firleju

  • Zasłużony dla Symulatora
  • Wiadomości: 1588
  • bawię się (w) exe...
    • Zobacz profil
  • Otrzymane polubienia: 121
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #12 dnia: 17 Stycznia 2017, 07:07:02 »
Właśnie dlatego chciałem użyć ZMQ, gdyż można zrobić wtedy prostego hub-a rozsyłającego komunikaty po całej sieci podłączonych klientów i serwerów. Można też użyć jednej z instancji jako exe jako taki hub. W każdym bądź razie w takim układzie i tak koniec końców przy multiplayerze kończymy z TCP, a lokalnie można uruchamiać 3 exeki lub za pomocą zmiennej ustawiać w jakiej konfiguracji uruchamiamy daną sesję.
Jeszcze jest inna kwestia, że taki hub może nam służyć też jako miejsce rozsyłania samego pliku scenerii i scenariusza tak aby wszyscy na pewno mieli tą samą wersję. Mam na myśli same pliki tekstowe.
Myślałeś o tym, żeby rozbić to na wątki na takiej zasadzie, że każda stacja ma własny plik anp na własnym wątku? To ułatwia ewentualne włączenie się do sesji w trakcie jej trwania.
Skrypty do Blendera dostępne tutaj
W miarę aktualne wiki EXE wiki.eu07.es

Offline Paul

  • Zasłużony dla Symulatora
  • Wiadomości: 523
    • Zobacz profil
    • Beskidzka Strona Kolejowa
  • Otrzymane polubienia: 16
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #13 dnia: 17 Stycznia 2017, 12:23:00 »
Przy założeniu, że dyżurny może włączyć/wyłączyć się z sesji sprawa się trochę komplikuje, wielowątkowość ANP to przy tym mniejszy problem. SCS po uruchomieniu zakłada, że wszystkie urządzenia srk (oprócz odcinków, których status jest przysyłany po starcie) znajdują się w stanie zasadniczym, głównie dotyczy to stanów związanych z realizacją przebiegów (utwierdzone odcinki, zamknięte zwrotnice, podane sygnały).

Możliwość włączania/wyłączania się z trwającej sesji wymagać będzie przechowywania tych stanów na serwerze (w zasadzie na żywo, żeby przypadkowe rozłączenie nie spowodowało ich utraty), realizacji zależności i sterowania przez serwer w czasie, gdy stacja jest bez obsady oraz pobrania stanów przy objęciu sterowania.

W zasadzie w tym przypadku aplikacja sterująca ruchem powinna działać na serwerze, najlepiej pod nadzorem jednego z użytkowników - "dyspozytora sesji", z możliwością objęcia sterowania przez klienta dyżurnego ruchu. Powinna być przy tym możliwość przekazywania uprawnień do sterowania poszczególnymi stacjami, tak aby jeden dyżurny mógł objąć jednocześnie dwie lub więcej stacji na jednym kliencie. Na razie nie przymierzałem się do takiego rozwiązania, zależnie od ilości rzeczy które chcemy osiągnąć będzie to dostosowanie SCS-1 lub stworzenie czegoś od nowa. Dobrze byłoby też przewidzieć możliwość użycia w sesji symulacji innych typów urządzeń, np. przekaźnikowych.

Dla porównania w TD2 zastosowane zostało inne podejście, w którym stacja nie może działać bez zalogowanego dyżurnego ruchu, przy włączeniu do sesji startuje pusta i w stanie zasadniczym, a przy rozłączeniu znika z sesji (razem z maszynistami) - tu SCS może pracować lokalnie, bez zapisywania stanów. Nie polecam jednak tego rozwiązania do Maszyny.
« Ostatnia zmiana: 17 Stycznia 2017, 12:24:53 wysłana przez Paul »
automatyka sterowania ruchem kolejowym rox
www.isdr.pl | www.bsk.isdr.pl | pokrzesik.wytnij@gmail.com

Offline firleju

  • Zasłużony dla Symulatora
  • Wiadomości: 1588
  • bawię się (w) exe...
    • Zobacz profil
  • Otrzymane polubienia: 121
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #14 dnia: 17 Stycznia 2017, 12:39:21 »
Przy założeniu, że mamy hub pośredniczący to jest to dobre miejsce do przechowywania stanów sesji. To można używać niezależnie czy jest to uruchomione tylko lokalnie czy także globalnie (przez sieć). Masz pewność, że dopóki hub się nie wywróci będziesz miał stan w miarę na żywo. Jeśli SCS miałby pracować jako część wykonawcza scenariusza to i tak musisz mieć automatyczne prowadzenie ruchu, czy to w SCS czy w warstwie wyższej. O tym właśnie piszę wcześniej. Może troszkę nie zrozumieliśmy się odnośnie tej kwestii.
Skrypty do Blendera dostępne tutaj
W miarę aktualne wiki EXE wiki.eu07.es

Offline Paul

  • Zasłużony dla Symulatora
  • Wiadomości: 523
    • Zobacz profil
    • Beskidzka Strona Kolejowa
  • Otrzymane polubienia: 16
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #15 dnia: 17 Stycznia 2017, 13:48:30 »
Przetwarzanie poleceń ANP z kilku oddzielnych plików jest do zrobienia, dla objęcia ręcznego sterowania wybraną stacją myślałem też o możliwości wyłączenia ANP dla danej stacji.

Trzeba by się jednak zastanowić na czym ma polegać włączenie się dyżurnego ruchu do sesji i z czym warstwa nadrzędna zarządzająca ruchem miałaby się komunikować. Można trzymać stany w hubie, ale musi być zapewniona jeszcze ciągłość sterowania po rozłączeniu się dyżurnego ruchu - działanie srk nie może być zawieszone do czasu aż ktoś obejmie sterowanie (z uwagi na ruch składów po parunastu sekundach stany elementów przebiegów staną się nieaktualne względem sytuacji na gruncie), chyba że wtedy cała symulacja się zatrzymie i będzie czekać na połączenie brakującego dyżurnego. Stąd wydaje mi się, że najlepiej będzie SCS (lub jego odpowiednik) uruchamiać na serwerze, z możliwością objęcia sterowania lokalnie przez klienta, przy czym proces sterowania nadal będzie realizowany na serwerze - klient dyżurnego ruchu będzie jedynie terminalem do wprowadzania poleceń i zobrazowania stanu. Warstwa nadrzędna wtedy również pracuje na serwerze.
automatyka sterowania ruchem kolejowym rox
www.isdr.pl | www.bsk.isdr.pl | pokrzesik.wytnij@gmail.com

Offline firleju

  • Zasłużony dla Symulatora
  • Wiadomości: 1588
  • bawię się (w) exe...
    • Zobacz profil
  • Otrzymane polubienia: 121
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #16 dnia: 17 Stycznia 2017, 21:09:13 »
No tak, wtedy serwer jest jednocześnie hub-em oraz zajmuje się wykonastwem poleceń. Każdy posterunek ruchu ma swojego klienta, jeśli nie ma człowieka to wtedy uruchamiany jest klient AI.
Skrypty do Blendera dostępne tutaj
W miarę aktualne wiki EXE wiki.eu07.es

Offline maciek001

  • Wiadomości: 137
    • Zobacz profil
    • FanPage symulatora ET22
  • Otrzymane polubienia: 33
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #17 dnia: 28 Lutego 2017, 19:45:08 »
Jedno mam pytanie. Czy w MaSzynie są zaimplementowane blokady liniowe i automatyka?
Wszystko da się zrobić tylko jeszcze nie wiem jak.

Offline firleju

  • Zasłużony dla Symulatora
  • Wiadomości: 1588
  • bawię się (w) exe...
    • Zobacz profil
  • Otrzymane polubienia: 121
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #18 dnia: 28 Lutego 2017, 19:55:16 »
Nie ma nic. Dlatego chciałbym wykorzystać soft Paula. Po co pisać drugi raz to samo.
Skrypty do Blendera dostępne tutaj
W miarę aktualne wiki EXE wiki.eu07.es

Offline maciek001

  • Wiadomości: 137
    • Zobacz profil
    • FanPage symulatora ET22
  • Otrzymane polubienia: 33
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #19 dnia: 28 Lutego 2017, 21:19:04 »
Pytanie brzmi, czy zewnętrzny program powinien kontrolować w pełni wszystko w MaSzynie czy powinien np przejmować kontrolę nad blokadą (tak jak to działa w rzeczywistości) w celu wypuszczenia jakiegoś pociągu? Wtedy AI lub użytkownik w LCS "pyta" czy są warunki do wypuszczenia pociągu ze stacji a reszta już po stronie automatu.
Wszystko da się zrobić tylko jeszcze nie wiem jak.

Offline El Mecánico

  • Wiadomości: 1067
  • Dawniej El Driver
    • Zobacz profil
    • Stowarzyszenie POLARIS - OPP
  • Otrzymane polubienia: 2
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #20 dnia: 01 Marca 2017, 12:28:05 »
To co na gruncie dzieje się automatycznie i samoczynnie powinno zostać w MaSzynie (planowo puścić przez LD), a na zewnątrz wyprowadzić tylko interakcje.
www.polaris.org.pl
www.ciemneniebo.pl
MaSzyna_LD w trakcie tworzenia...

Offline maciek001

  • Wiadomości: 137
    • Zobacz profil
    • FanPage symulatora ET22
  • Otrzymane polubienia: 33
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #21 dnia: 01 Marca 2017, 13:53:23 »
Nie ma nic. Dlatego chciałbym wykorzystać soft Paula. Po co pisać drugi raz to samo.
Na pewno przyspieszyłoby to prace. Pytanie czy będzie to dobre rozwiązanie na dłuższą metę? Nie chciałbym, żeby okazało się, że potrzebuje włączyć SRS żeby pojeździć na maszynie ;)

El Mecánico:
Czyli tak: ustawianie się semaforów powinno być w MaSzynie, przebiegi i uzależnienia też.
Zmiana zwrotnic i podawanie sygnałów zezwalających ląduje po stronie kontrolera (zewnętrzny lub wbudowany w maszynę).

Pokrótce: mam skład na torze 1 na stacji A. Odjazd o godzinie 12:00 zapisany jest w planie. O godzinie 12:00 świeci się wyjazd (w zależności od następnych sygnalizacji czy układu przebiegu). Po minięciu Semafora wyjazdowego zapala się na nim STÓJ. Dojeżdżam do stacji B. W planie wjazd mam podany o godzinie 12:30 lub jakiś ivent z uzależnieniami. W planie wjeżdżam na tor 3 i taki dostaję przebieg. Sygnał na semaforze wjazdowym zależy od przebiegu. AI lub użytkownik wysyła tylko komendę "podaj wjazd" lub "podaj wyjazd". Dobrze kminię?
« Ostatnia zmiana: 01 Marca 2017, 13:56:57 wysłana przez maciek001 »
Wszystko da się zrobić tylko jeszcze nie wiem jak.

Offline El Mecánico

  • Wiadomości: 1067
  • Dawniej El Driver
    • Zobacz profil
    • Stowarzyszenie POLARIS - OPP
  • Otrzymane polubienia: 2
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #22 dnia: 01 Marca 2017, 14:01:46 »
Eee, nie do końca. Ktoś musi jeszcze wajchy poustawiać, i to też powinno iść na karb kontrolera (chyba że robimy dziś za "przekaźnik" na ręcznych wajchach :D).
www.polaris.org.pl
www.ciemneniebo.pl
MaSzyna_LD w trakcie tworzenia...

Offline maciek001

  • Wiadomości: 137
    • Zobacz profil
    • FanPage symulatora ET22
  • Otrzymane polubienia: 33
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #23 dnia: 01 Marca 2017, 14:13:09 »
Nie mam pojęcia o czym piszesz :)
Wszystko da się zrobić tylko jeszcze nie wiem jak.

Offline miko22

  • Wydział Promocji
  • Wiadomości: 619
  • Promocja MaSzyny w terenie
    • Zobacz profil
    • Nasze-Symulatory.pl
  • Otrzymane polubienia: 200
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #24 dnia: 01 Marca 2017, 16:42:42 »
Jeśli chodzi o sterowanie za pomocą urządzeń przekaźnikowych i pulpitu kostkowego, to polecam pobawić się trochę symulatorem ISDR, na początek np. stacją Testowo: http://www.symulator.isdr.pl/download.php Można tam zobaczyć co i jak obsługuje dyżurny, a co i jak wykonuje się automatycznie. Do MaSzyny trzeba by też dodać odcinkowe sprawdzanie zajętości torów, m.in. do wygaszania semaforów, co obecnie jest realizowane eventami oraz do innych uzależnień związanych z bezpieczeństwem.

Offline dymus

  • Zasłużony dla Symulatora
  • Wiadomości: 1046
    • Zobacz profil
  • Otrzymane polubienia: 274
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #25 dnia: 01 Marca 2017, 17:44:54 »
Odcinki izolowane są obsługiwane i są wykorzystywane w SCS do sygnalizowania zajętości, a wygaszanie semaforów to klasyczy event _s1, mozna by albo zostawić klasyczy event albo wg zajętości toru za semaforem. Czyli do sterowania MaSzyny z SCS'a wystarczy przerobić scenerie (dodanie odcinków izolowanych i pozbycie się większosci klasycznych eventów, a zamiast tego eventy które będą ewentualnie przesyłanie informacje do programu) oraz napisać program które będzie sterowało i konstrolowało co się dzieje na scenerii i w SCS i będzie umiało tym sterować (czy to ogólne zasady sterowania czy konkretne dla danego sceneriusza. A sam SCS potrzebuje przebieg od semafora do semafora/punktu końcowego, a sam sobie ustawi rozjazdy.
Cytuj
Jeśli chodzi o sterowanie za pomocą urządzeń przekaźnikowych i pulpitu kostkowego, to polecam pobawić się trochę symulatorem ISDR, na początek
Pulpit kostkowy mógłby byc fajnym dodatkiem, ale do samego sterowania SCS naprawdę daje radę, tylko potrzebny automat czy wirtualny dyżurny  który będzie nim sterował. Pulpit kostkowy moze by się przydał na jakieś oficjane pokazy czy coś, więc mozna o tym też pomysleć ale jak na razie SCS chyba sam w sobie jest bardziej potrzebny.

Offline maciek001

  • Wiadomości: 137
    • Zobacz profil
    • FanPage symulatora ET22
  • Otrzymane polubienia: 33
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #26 dnia: 01 Marca 2017, 18:26:26 »
W sumie to na razie nie jest ważne czy będzie sterowaniem SCS czy pulpitem bo tak czy siak potrzebny jest jakiś interfejs do wymiany sensownych danych. Jeden interfejs można wykorzystać do komunikacji z każdym programem ;) Zrobić trzeba sprawną komunikację z SCS a w przyszłości może uda się podpiąć pulpit kostkowy do SCS-a albo bezpośrednio
Wszystko da się zrobić tylko jeszcze nie wiem jak.

Offline miko22

  • Wydział Promocji
  • Wiadomości: 619
  • Promocja MaSzyny w terenie
    • Zobacz profil
    • Nasze-Symulatory.pl
  • Otrzymane polubienia: 200
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #27 dnia: 01 Marca 2017, 18:33:29 »
Pulpit kostkowy mógłby byc fajnym dodatkiem, ale do samego sterowania SCS naprawdę daje radę, tylko potrzebny automat czy wirtualny dyżurny  który będzie nim sterował. Pulpit kostkowy moze by się przydał na jakieś oficjane pokazy czy coś, więc mozna o tym też pomysleć ale jak na razie SCS chyba sam w sobie jest bardziej potrzebny.
Miałem na myśli wygląd ekranu sterującego, który imitowałby pulpit kostkowy (jak w ISDR), czyli od razu trochę przyszłościowo w stronę multiplayera, kiedy będzie mogło być kilku dyżurnych obsługujących poszczególne stacje/posterunki. Chodzi mi o to, aby zostawić możliwość zrobienia takiego pulpitu dla poszczególnych stacji, żeby każdy dyżurny mógł sobie ew. wybrać, na jakim sprzęcie chce pracować - nowoczesny system komputerowy czy klimatyczny pulpit kostkowy (na ekranie). Podłączenie rzeczywistego pulpitu (czy to z prawdziwych elementów, czy wykonanego samodzielnie) to zupełnie inna kwestia (i nie ten temat) oraz przesyłanie odpowiednich danych przez UART do jakiegoś mikrokontrolera obsługującego wszystkie przyciski, szczeliny świetlne, powtarzacze itd., ale to już @maciek001 ma chyba opanowane... ;)
Edit:
Zrobić trzeba sprawną komunikację z SCS a w przyszłości może uda się podpiąć pulpit kostkowy do SCS-a albo bezpośrednio
Racja, to w pierwszej kolejności.
« Ostatnia zmiana: 01 Marca 2017, 18:39:49 wysłana przez miko22 »

Offline maciek001

  • Wiadomości: 137
    • Zobacz profil
    • FanPage symulatora ET22
  • Otrzymane polubienia: 33
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #28 dnia: 01 Marca 2017, 19:12:02 »
@miko22: W SCS-ie trzeba od razu mieć wszystkie stacje? ;) Osobiście wolałbym, żeby całość sterowania ruchem była zamknięta w maszynie a SCS miał możliwość sterowania ale jestem świadom, że to bardzo dużo roboty.
Swoją drogą: ciekaw jestem czy można zrobić nakładkę graficzną na SCS żeby sterować jak kostkowym :)
Wszystko da się zrobić tylko jeszcze nie wiem jak.

Offline firleju

  • Zasłużony dla Symulatora
  • Wiadomości: 1588
  • bawię się (w) exe...
    • Zobacz profil
  • Otrzymane polubienia: 121
Odp: Sterowanie ruchem przez zewnętrzną aplikację
« Odpowiedź #29 dnia: 01 Marca 2017, 21:08:07 »
Z SCS jest jak z Rainsted. Nie ma launchera w exe więc korzystamy z dobrego zewnętrznego softu. Paul ma pomysł na sterowanie scenariuszem więc to jest lepsza droga niż zabawa w implementację logiki układania przebiegów, która już została zaimplementowana i przetestowana.
Dla mnie nie jest problemem, że automatycznie odpalasz na kompie drugi proces, który komunikuje się z tym głównym. Może być nawet bezokienny jeśli komuś to będzie wadziło.
Skrypty do Blendera dostępne tutaj
W miarę aktualne wiki EXE wiki.eu07.es