Otrzymane polubienia

1

Wydział zamówień / Odp: linia 139

« dnia: 06 Maja 2019, 16:18:13 »

W tej scenerii brakuje modeli, sieci trakcyjnej i dopracowania całości. Gdyby ktoś chciał zająć się modelami (dworce, nastawnie, charakterystyczne obiekty/budynki), to może spróbowałbym ten temat ruszyć, bo sporo pracy w nią swojego czasu włożyłem, a linia jest dość ciekawa terenowo i ruchowo.

1 Lubię to

2

Infrastruktura kolejowa / Odp: Rozjazdy krzyżowe (angliki) w symulatorze.

« dnia: 22 Listopada 2017, 12:45:04 »

Pojęcia "+" i "-" nie wzięły się z sufitu a zostały zaczerpnięte z dziedziny srk i oznaczają położenie zasadnicze i przeciwne do zasadniczego. Tak samo działało to zawsze w exe i w plikach inc - "+" odpowiada stanowi switch 0, a stan ten jest położeniem zasadniczym w którym zwrotnica znajduje się po uruchomieniu symulatora. Określenie, który kierunek to "+", a który to "-" sprowadza się do zdefiniowania odpowiedniej kolejności punktów wpisu zwrotnicy (pierwsze zdefiniowane odgałęzienie będzie kierunkiem zasadniczym). Symulacja ruchu po zwrotnicy działa poprawnie niezależnie od tej kolejności. Exe najwyżej może mieć problem z prawidłowym rysowaniem iglic w niektórych przypadkach, choć wydawało mi się że jakiś czas temu zostało to już poprawione.

To, że w symulatorze "+" interpretowane jest jako położenie na wprost, a "-" w bok wzięło się pewnie z tego, że prawie nikt nie zmienia położenia zasadniczego (kolejności punktów) przy wstawianiu zwrotnicy. Skoro używamy już oznaczeń "+" i "-", to ustalanie teraz, że w symulatorze w odróżnieniu od rzeczywistości "+" to ma być zawsze położenie na wprost, a "-" w bok wprowadzi zamęt, zwłaszcza gdy ktoś w realistyczny sposób próbuje rozwiązać kwestie srk. Lepiej już zmodyfikować pliki sterujące zwrotnic i przewidzieć dodatkowe zdarzenia sterujące, np. "L" i "P" - lewo i prawo, lub "W" i "B" - "na wprost", "na bok". Operowanie przy sterowaniu scenerią na położeniach zasadniczych i przeciwnych wbrew pozorom jest wygodne - położenie zasadnicze to z reguły położenie najczęściej używane, np. prowadzące na tory bliższe torom głównym zasadniczym (często jest to właśnie położenie "na bok") - nie mówiąc już o potencjalnych aplikacjach srk, w których wszystko się porozjeżdża albo trzeba będzie definiować dwa różne rodzaje "plusów" i "minusów".

Co do rozjazdu krzyżowego, są to dwa niezależne układy napęd-zwrotnica, funkcjonalnie odpowiadające dwóm zwrotnicom zwróconym do siebie ostrzami. Dwie zwrotnice razy dwa położenia każdej zwrotnicy dają cztery możliwe kombinacje położeń zwrotnic rozjazdu krzyżowego, używane dla czterech możliwych kierunków jazdy: na wprost w jednym kierunku, na wprost w kierunku do niego ukośnym i dwie możliwości jazdy po łuku (o ile rozjazd krzyżowy jest podwójny). Nie do końca rozumiem skąd wzięły się wspomniane trzy położenia, jeżeli to mają być takie położenia jakie zostały pokazane jako "złe" na screenach w pierwszym poście, to lepiej szybko to poprawić.

Jeżeli planowane będą zmiany w plikach inc zwrotnic, proponuję przy okazji uwzględnić dodatkowe zdarzenia rozprucia które opisałem w wątku o sterowaniu z zewnętrznej aplikacji srk.

3 Polubienia

3

Na warsztacie / Odp: Sterowanie ruchem przez zewnętrzną aplikację

« dnia: 03 Marca 2017, 21:09:55 »

Jesli to nie problem, czy mozesz dolaczyc tutaj wersje SCS, ktora komunikuje sie z klasa GLFW30? Moge wtedy sprawdzic czy jakiekolwiek komunikaty przychodza z SCS.

W załączniku. Teraz wysyła do GLFW30, ale nie wygląda na to żeby EU07 na to reagował. Przy czym SCS czeka na komunikat gotowości od EU07, i dopiero potem sam zaczyna wysyłać komunikaty, w pierwszej kolejności żądanie stanu odcinków. Dorobiony został przycisk ODBL udający zgłoszenie gotowości, po jego kliknięciu można przez kilkanaście sekund próbować coś wysyłać (aż SCS nie wykryje oszustwa i ponownie się nie zablokuje). Jak jest potrzeba, to przygotuję prosty program do testowania wysyłania komunikatów WM_COPYDATA bez takich kombinacji.

Właśnie ja myślałem że scs powinien być serwerem żeby można było w przyszłości podłączyć więcej symulatorów do jednej nastawni.

W takim razie w miejsce SCS w tej koncepcji potrzebny jest serwer, do którego podłączać będą się klienci: EU07, właściwy SCS i opcjonalnie inne programy. W takim układzie EU07 może być klientem TCP/IP. Nie wiem jak tu w przyszłości wcisnąć innych klientów EU07 dla multiplayera - całość wymaga dokładniejszego przemyślenia, chyba że traktujemy to rozwiązanie jako "tymczasowe".

Ze źródłami mi chodzi o to, że jeżeli scs miałby być kiedyś wykorzystany jako zamiennik eventów przy tworzeniu scenerii, to imo raczej wymogiem jest żeby wszystkie komponenty dostarczane z maszyną były otwartoźródłowe. Dopiero co otworzone zostały źródła eu07 i są prace nad wieloplatformatyzacją kodu, więc wracanie do zamkniętych blobów to moim zdaniem krok wstecz.

SCS nie jest elementem Maszyny, tylko oddzielnym projektem, łączy się z Maszyną dynamicznie. Niezależnie używany jest w TD2 oraz jednym komercyjnym projekcie. Nie wydaje mi się, żeby przez dostosowanie do Maszyny przechodziła na niego licencja kodu Maszyny. Chyba że to wymóg dla wszystkiego co włączane ma być do paczki z Maszyną - w takim razie SCS będzie musiał być udostępniony oddzielnie.

2 Polubienia

4

Na warsztacie / 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.

10 Polubienia