Pokaż wiadomości

Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.


Wiadomości - Paul

Strony: [1] 2 3 ... 17
1
Na warsztacie / Odp: Bałtyk - SKM - Multi
« dnia: 15 Lutego 2022, 18:48:43 »
Początkiem przebiegu w tych urządzeniach (to chyba MOR-3, albo coś bardzo do niego zbliżone) jest semafor lub tarcza, ale końcem powinien być symbol szarego pełnego trójkąta przed semaforem wyjazdowym (w przypadku przebiegu wyjazdowego), a nie semafor wjazdowy do następnej stacji albo jak w przypadku wyjazdu na sbl żółta strzałka jej sterowania. Przez to jak próbowałem podać wyjazd normalnie jak to robię w pracy i się nie udawało. Chyba trzeba to będzie poprawić.

Nie jest to odwzorowanie urządzeń żadnego konkretnego typu - z założenia miał być to program ogólnie naśladujący działanie pulpitu komputerowego.

Dla szlaków z sbl przyjęte jest nastawianie przebiegu do symbolu blokady, analogicznie jak w urządzeniach ESTW L90 5/C900. Dla szlaków bez blokady liniowej nastawianie przebiegów działa tak jakby był to tor stacyjny, więc jako koniec wybiera się semafor wjazdowy do następnej stacji - takie rozwiązanie również spotykane jest w rzeczywistości, choć rzadko - zwykle projektuje się półsamoczynną blokadę liniową z uwagi na decentralizację urządzeń zależnościowych.

Istnieje możliwość takiego skonfigurowania pulpitu, aby punktem końcowym przebiegów na szlak był mały szary trójkąt - jednak aktualnie tylko dla szlaków bez sbl. Być może w przyszłych wersjach zostanie to zmienione aby móc bardziej upodobnić obsługę do konkretnych urządzeń.

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

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

4
Niewielkie prawdopodobieństwo że w najbliższym czasie się coś ruszy, bo brakuje mi zautomatyzowanego rozwiązania do wygenerowania porządnego terenu (a odcinek za Żywcem jest typowo górski i nie jest to prosta sprawa) i paru innych rzeczy... oraz czasu aby się tym zająć.

Gdybym kiedyś jeszcze podjął ten temat (szkoda zmarnować dotychczasowej pracy), to pomoc przy budynkach i modelach otoczenia jak najbardziej się przyda (sam raczej bym się ograniczył do infrastruktury kolejowej).

5
Mojej "części serwerowej" SCS/sterowania nie ładowałbym na pewno do exe EU07, zwłaszcza że być może będzie też używana w TD2. To raczej będzie klient serwera EU07, obsługujący klientów nastawni, być może uruchamiany na tej samej maszynie co EU07.

Co do "scenariuszy" w SCS, raczej widzę to jako rozkłady jazdy poszczególnych pociągów, uzupełnione o dodatkowe polecenia, z których przez jakiś interfejs automatycznie będzie generowany plan przebiegów dla SCS. Rozdzielanie tego na osobne instrukcje dla każdej stacji będzie niezbyt wygodne.

6
- W wizji Pawła każda instancja SCS steruje tylko jednym obiektem
- obiekt może być całą scenerią lub pojedynczymi stacjami, tak?

Tak, instancja SCS steruje "tylko" pojedynczymi stacjami lub całą scenerią. Czym więcej miałby sterować?

Przewiduję ponadto możliwość zmiany zasięgu sterowania, np. wprowadzone są dane całej scenerii, a obejmowane jest sterowanie połową stacji. Druga połowa stacji może być sterowana czymś innym, albo może jej nie być (przy modułowej budowie scenerii z wybranych odcinków, czy tam komórek scenerii).

- w jaki sposób instancje SCS przekazują sobie informacje o kolejnych pociągach?

Tym zająłby się serwer trzymający topografię sieci, stan blokad i pip (numery pociągów), do którego logowały by się instancje SCS (albo inne aplikacje sterujące, np. pulpit kostkowy). Ale na razie to tylko koncepcja.

- czy jest sens uruchamiać więcej niż jedną instancję jeśli nie mamy multiplayera?

Niezbyt. Chyba że multiplayer typu kilku dyżurnych steruje jednym maszynistą...

- może osobne scenerie dla muli i osobne dla single, wtedy wiele rzeczy by się upraszczało

Raczej wspólne, a przynajmniej ze wspólnym opisem infrastruktury i otoczenia, różniące się ewentualnie jakimiś incami ze szczegółami sterowania. Nie powinno być ograniczeń zastosowania scenerii tylko offline, lub tylko w multiplayerze.

- należy posiadać warstwę nadrzędną zlecającą SCS poszczególne kroki (tj obecnie połączenie dyspozytora z dyżurnym jak mniemam)
- aby to działało potrzebny jest opis senariusza (co jak sądzę jest w opracowaniu)

Multiplayer z dyżurnymi nie wymaga warstwy nadrzędnej - dyżurni sami będą sterować. Gdy sterowanie ma być automatyczne, SCS potrzebuje planu przebiegów, będącego czymś w rodzaju opisu scenariusza (co, skąd, dokąd, kiedy ma pojechać), i to już działa. W razie potrzeby można dodać warstwę nadrzędną która będzie dynamicznie modyfikować plan przebiegów, czyli zarządzać ruchem.

- aby móc zrobić docelowo miltiplayer potrzeby jest hub wymieniający dane, więc można to wykonać od razu
- w każdej opcji dobrze jest przenieść komunikację na TCP. Co do big/little indian może to robić hub, i tak będzie musiał być osobnym procesem / programem

Z pewnością jakiś hub musi być, jeżeli w symulacji ma brać udział coś więcej niż jedna instancja EU07 i jedna SCS. Na potrzeby sterowania hub będzie przekazywał polecenia i meldunki stanów między EU07 i instancjami SCS/innych aplikacji sterujących. Na poziomie huba lub za hubem z mojej strony potrzebny będzie jeszcze jakiś serwer zajmujący się działaniem blokad i przekazywaniem informacji pomiędzy SCS/aplikacjami sterującymi, oraz być może dodatkowo zarządzający uprawnieniami do sterowania poszczególnych stacji przez poszczególne aplikacje nastawni, trzymający stany sterowania na wypadek wyłączenia się klienta nastawni. Otwarta pozostaje kwestia roli i zasad działania huba przy wielu instancjach EU07.

7
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 04 Marca 2017, 16:16:14 »
Powinno się udać, wygodniej jednak będzie SCS uruchamiać na drugim komputerze - przyszłościowo przewidziana jest taka możliwość (w aktualnie udostępnionej wersji nie zadziała, bo potrzebna jest dodatkowa aplikacja działająca jako serwer komunikacji sieciowej).

8
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 04 Marca 2017, 15:21:57 »
Ten semafor to SSd5zpcpbIW24.inc, jest tam jeszcze kilka podobnych. Problem w tym, że normalnie w jego wpisie podaje się nazwę następnego semafora (p7), i wyświetlany sygnał jest uzależniany od komórki pamięci następnego semafora. Ponieważ zależności sygnałowe realizuje SCS, w miejscu (p7) znajduje się none, i symulator próbuje sprawdzać komórkę none_sem_mem. W starych wersjach brak komórki był ignorowany i dawało się sterować sygnałami. A skoro działało, to tak zostało to rozwiązane, dzięki czemu nie trzeba było dodatkowo mnożyć inców semaforów. Można to oczywiście zmienić i dorobić wersje semaforów bez uzależnień.

9
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 04 Marca 2017, 13:59:01 »
Według tego co napisałeś, to robisz dobrze, tylko prawdopodobnie wybierasz zły semafor końcowy - trzeba zaznaczyć kolejne, bez pominięcia pośrednich. Dla nastawienia od A_H kliknij podwójnie na B_A. A jak chcesz do B_E za jednym zamachem, to kliknij pojedynczo na A_H, pojedynczo na B_A i podwójnie na B_E.

Uprzedzając pytanie, dla wyjazdu na szlak z sbl trzeba podwójnie kliknąć na żółtą strzałkę blokady zamiast na następny semafor.

10
W eu07++170304b komunikacja działa prawidłowo (nie licząc sypania się przy niektórych eventach, o czym napisałem w wątku exe). Jeżeli nadal pojawiają się problemy z ustawianiem przebiegów, podaj więcej szczegółów (które przebiegi, log).

11
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 04 Marca 2017, 13:35:45 »
edit: ok, poprawione.

Na starym komputerze problem nie ustąpił, nadal crash na tym dll. Może faktycznie problem sprzętowy, a przez przypadek przy sprawdzaniu wylazło coś innego.

Sprawdzałem na drugim, i komunikacja WM_COPYDATA działa jak należy. Urządzenia się nastawiają, zajętości działają, można nastawiać przebiegi i jeździć. Jednak po wyświetleniu sygnałów zezwalających na jazdę pociągową na niektórych semaforach EU07 się wysypuje - konkretnie C_E, D_E, D_F w anp_test, prawdopodobnie inne z tymi samymi incami też. To są zdaje się semafory które miały być powiązane z sbl, z uwagi na umieszczenie logiki sbl w SCS ja ich używam trochę inaczej, może coś trzeba poprawić w inc ale chyba nie powinno to skutkować sypaniem się. Manewrowe, Sz na tych semaforach działają poprawnie, inne semafory i obiekty innych typów również. Po próbie wyświetlenia problematycznego sygnału EU07 jeszcze odsyła potwierdzenie przyjęcia eventu, po czym się przewraca, w oknie EU07 nie widać już wyświetlenia sygnału. W załączniku log i dmp, najpierw nastawiłem przebieg od B_F, po chwili była próba od C_E.

12
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 04 Marca 2017, 00:48:57 »
Crash na 170304. Wywala się po zakończeniu wczytywania, zanim cokolwiek się wyświetli. Na 170302 efekt podobny, natomiast 170301 działa. Sugerowana przyczyna w starym sprzęcie prawdopodobna - uruchamiane na HP 550. Jutro sprawdzę na czymś nowszym. Przy okazji, log.txt twierdzi że "Compilation 2017-01-10". Można by zaktualizować lub to usunąć.

Podpis problemu:
  Nazwa zdarzenia problemu: APPCRASH
  Nazwa aplikacji: eu07++170304.exe
  Wersja aplikacji: 17.0.1175.483
  Sygnatura czasowa aplikacji: 58b9ee55
  Nazwa modułu z błędem: ig4icd32.dll
  Wersja modułu z błędem: 8.14.10.1930
  Sygnatura czasowa modułu z błędem: 4aba6fc2
  Kod wyjątku: c0000005
  Przesunięcie wyjątku: 00066b66
  Wersja systemu operacyjnego: 6.1.7601.2.1.0.256.48
  Identyfikator ustawień regionalnych: 1045
  Dodatkowe informacje 1: 0a9e
  Dodatkowe informacje 2: 0a9e372d3b4ad19135b953a78882e789
  Dodatkowe informacje 3: 0a9e
  Dodatkowe informacje 4: 0a9e372d3b4ad19135b953a78882e789

13
Odczytywanie zajętości i sterowanie poszczególnymi obiektami wskazuje że sama komunikacja jest ok. "Nie można ustawić przebiegu" oznacza raczej jakiś problem po stronie SCS, a nie w komunikacji, chyba że np. któreś odcinki błędnie wykazują zajętość.

Ale na razie chyba nie sprawdzę, załączone exe eu07++170304 wysypuje się po zakończeniu ładowania scenerii - "Nazwa modułu z błędem: ig4icd32.dll". Przesłać .dmp w wątku exe, czy to jakiś znany problem i coś pominąłem? Wersja eu07++170301.exe mi się uruchamiała.

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

15
Sprawdziłem i faktycznie, SCS szuka nazwy klasy EU07, nie nazwy okna, natomiast w drugą stronę było szukanie nazwy okna - TEU07SRK. Mogę zmienić z EU07 na GLFW30, ale i tak SCS nie dostaje komunikatów od EU07.

16
nie działa bo nazwa klasy jest chyba zła. mógłbyś sprawdzić czy działa przy klasie GLFW30?

To było oparte o opisy okien, a nie nazwy klas - dlatego SCS po ustawieniu trybu WM_COPYDATA ustawia sobie opis TEU07SRK, i wyszukuje okna EU07. Niezbyt elegancko, ale przez buga w środowisku nie mogę zmienić deklarowanej nazwy klasy okna.

widzę to tak: SCS tworzy serwer tcp, eu07 łączy się pod adres wskazany w ini
przesyłane komunikaty są jak obecne DaneRozkaz, tylko po iSygn jeszcze dodać uint32 z długością payloadu (czyli bez iSygn, długości i iComm).

Może lepiej serwer w EU07, a SCS jako klient - żeby można było połączyć więcej niż jedną aplikację z EU07, np. dwa stanowiska SCS, różne systemy sterowania dla różnych stacji itp. Ogólnie dobrze byłoby wpasować to do jakiejś przyszłościowej koncepcji symulacji sieciowej z wieloma maszynistami.

wszystkie inty i floaty w big endian, inaczej niż obecnie. (we wszystkich protokołach jest raczej big endian)

Ja mam wszystko w little endian, razem ze standardowymi funkcjami zapisu/odczytu ze strumieni, EU07 ma jakoś inaczej? Musiałbym je odwracać (co w ostateczności nie jest skomplikowane, ale może się coś pomieszać).

PS: ten SCS ma być szansę otwartoźródłowy czy nie?

Nie za bardzo, a co byś potrzebował podejrzeć?

17
Sprawdziłem eu07++170301, SCS nie dostaje od niego komunikatów. Stare exe (sprzed konwersji) przy identycznej konfiguracji współpracuje prawidłowo.

18
Cytuj
Czyli tak: ustawianie się semaforów powinno być w MaSzynie, przebiegi i uzależnienia też.

Główną ideą SCS jest przeniesienie logiki sterowania na zewnątrz, z uwagi na to że implementacja przebiegów i uzależnień w eventach jest bardzo utrudniona - życzę powodzenia w odwzorowaniu sterowania dużą stacją zgodnie z tablicą zależności, z wszystkimi wykluczeniami i ciągłą kontrolą stanu elementów. To co było dotychczas na eventach to raczej prowizorka dla wybranych przebiegów, choć z punktu widzenia maszynisty działała - przynajmniej dopóki dwa pociągi nie trafiły z jakiegoś bzdurnego powodu na jeden tor, uniemożliwiając kontynuację scenariusza.

Oczywiście wszystko zależy od twórcy scenerii, SCS nie jest "jedynym słusznym" rozwiązaniem - można też zrobić tak, że eventy wykonawcze będą dostosowane do SCS, ale wariantowo można będzie włączyć scenerię z dołączonym plikiem eventów realizujących logikę, i w takim wariancie SCS nie będzie używany.

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

Nie tylko do sygnalizowania zajętości, przy wyświetlaniu sygnału kontrolowana jest niezajętość całej drogi przebiegu, nie tylko odcinka za semaforem. Ponadto zajętość jest konieczna do śledzenia przemieszczania się pociągów (przesuwanie numerów), bez którego nie zadziała pełna automatyka. Event wygaszający może się przydać jako zabezpieczenie na wypadek niespodziewanego rozłączenia, kiedy SCS semafora nie wygasi (ale przy rozłączeniu już cała symulacja zacznie się sypać z powodu utraty części informacji).

Cytuj
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

Interfejs wymiany danych używający WM_COPYDATA i eventów jest już opracowany i działa. Nie jest to interfejs specyficzny dla SCS, może być wykorzystany w innych aplikacjach sterujących, testowałem to wstępnie z urządzeniami E i pulpitem kostkowym, nie było problemów. Pytanie czy zostanie taki interfejs sterowania (przynajmniej "prowizorycznie"), czy zmienione zostanie medium transmisyjne (np. na TCP/IP, co było omawiane - można dostosować SCS), czy w ogóle wszystko zostanie zmienione, łącznie z zakresem i formatem przesyłanych danych (o ile ma to jakiś sens, skoro zostało już zrobione; jak na razie uwag do mojego rozwiązania nie ma). W roboczych exe++ zdaje się WM_COPYDATA aktualnie nie chodzi.

Pozostaje jeszcze kwestia interfejsu (głównie blokady liniowe) pomiędzy dwoma procesami SCS, lub ogólnie między aplikacjami sterującymi. Mam na to pewne pomysły, choć w Maszynie chyba nie będzie to w najbliższym czasie potrzebne.

Cytuj
W SCS-ie trzeba od razu mieć wszystkie stacje?

SCS będzie mógł obsługiwać wybrane stacje, reszta może działać po staremu na eventach lub może jej nie być - np. uruchamiamy scenerię w wariancie tylko z jednym odcinkiem, pomijając wczytywanie drugiego odcinka, który nie będzie potrzebny w danym scenariuszu. W przypadku sterowania częściowo z SCS i częściowo po staremu może być problem z powiązaniem i przekazywaniem informacji (np. numery pociągów, wykluczenia jazd na szlakach) między jednym i drugim rozwiązaniem - nie jest to jednak dużym problemem jeżeli podział jest tymczasowy, z uwagi na stopniowe dostosowywanie scenerii do sterowania z zewnątrz.

Cytuj
Jeśli taki SCS miałby możliwość odczytu i zapisu komórek pamięci, to zajętości można zostawić na eventach, tam gdzie są, zamieniając je tylko na ustawienie arbitralnej wartości dla true (tor wolny) lub false (tor zajęty), albowiem fachowo mówi się o niezajętości toru.

Chyba jednak prościej przypisać odcinki izolowane niż kombinować z eventami. Pierwsze prototypy SCS powstały przed wprowadzeniem odcinków izolowanych, wykrywały zajętości właśnie eventami torów, działało to kiepsko (niby działało, do czasu aż na torze nie znalazły się dwa pociągi, albo jakiś skład się nie rozłączył, po czym zostawiona część znikała z toru). Odcinki izolowane zostały wprowadzone dla eliminacji problemów z eventami torów.

19
Na warsztacie / Odp: Sterowanie ruchem przez zewnętrzną aplikację
« 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.

20
Na warsztacie / Odp: Sterowanie ruchem przez zewnętrzną aplikację
« 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.

21
Na warsztacie / Odp: Sterowanie ruchem przez zewnętrzną aplikację
« 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.

22
Na warsztacie / Odp: Sterowanie ruchem przez zewnętrzną aplikację
« 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.

23
Na warsztacie / Odp: Sterowanie ruchem przez zewnętrzną aplikację
« 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.

24
Na warsztacie / Odp: Sterowanie ruchem przez zewnętrzną aplikację
« 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.

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

26
Infrastruktura kolejowa / Odp: Zamykanie SSP na przejeździe kat. B
« dnia: 12 Stycznia 2017, 13:48:46 »
Skończę tę dyskusję, bo do niczego nie doprowadzi.

Proszę o wskazanie która część moich wypowiedzi była niejasna, postaram się doprecyzować.

nie da się zdalnie uruchamiać ostrzegania/zamykania rogatek.

Od tego też są wyjątki. Jeżeli przejazd z ssp jest blisko stacji i normalnie przy wyjeździe z niej ostrzeganie włączane jest przez urządzenia stacyjne (przy nastawieniu przebiegu), dyżurny ruchu ma możliwość ręcznego włączenia ostrzegania na wypadek wyjazdu na Sz/rozkaz pisemny.

27
Infrastruktura kolejowa / Odp: Zamykanie SSP na przejeździe kat. B
« dnia: 10 Stycznia 2017, 00:09:44 »
Jakie to są wytyczne?

Wytyczne techniczne budowy urządzeń sterowania ruchem kolejowym Ie-4 (dawne WTB-E10).

§6. Sygnały nadawane przez tarcze ostrzegawcze przejazdowe
4. W stanie zasadniczym, gdy do przejazdu, do którego tarcza się odnosi, nie zbliża się pociąg, tarcza ostrzegawcza przejazdowa pozostaje nieoświetlona.

Zgadza się. Wyłączenie czujników ssp przez dyżurnego ruchu nie jest stanem zasadniczym.

28
EU07 Foro de Simulador en español / Odp: Señal We8a: pasar sin cargar
« dnia: 09 Stycznia 2017, 15:56:18 »
¡Hola! La señal de polaco We8(a,b,c) significa poner el regulador a cero, sin necesidad de apagar el circuito.

29
Infrastruktura kolejowa / Odp: Zamykanie SSP na przejeździe kat. B
« dnia: 09 Stycznia 2017, 15:44:31 »
Nie ma napisane z jakiej Top powinna być widoczna.

Odległość widoczności określają wytyczne Ie-4.

Trzeba dodać, jak do przejazdu nie zbliża się pociąg, to tarcza jest ciemna. Nie wyświetla żadnego sygnału.

Chyba że czujniki zostaną wyłączone, wtedy tarcze danego toru stale wyświetlają Osp2 Osp1.

Albo przypadek ToP wyświetla sygnał Osp2, ale ktoś podniósł rogatki, czujnik zadział i sygnał zmienił się na Osp1.

Zmiany sygnału maszynista już raczej nie zobaczy, bo minie tarczę zanim przejazd zdąży się zamknąć - brakuje dodatkowego sygnalizatora bezpośrednio przy przejeździe, który ostrzegałby przed takimi sytuacjami.

30
Infrastruktura kolejowa / Odp: Zamykanie SSP na przejeździe kat. B
« dnia: 06 Stycznia 2017, 15:26:27 »
Pytanie było o odległość czujnika od TOP - zależy to od prędkości jazdy i opóźnienia wyświetlenia Osp2, które wynosi nie więcej niż kilka sekund od najechania na czujnik, zależnie od rodzaju urządzeń (po uruchomieniu i sprawdzeniu poprawności działania urządzeń, jednak przed zamknięciem rogatek) - maszynista musi mieć przynajmniej kilka sekund na zauważenie sygnału, jednak nie jest to chyba nigdzie dokładnie określone, może chodzi o wyświetlenie sygnału gdy pociąg znajdzie się w odległości widoczności sygnału na TOP (która jest już zdefiniowana - 10*v/4 [m], v w [km/h], jednak nie mniej niż 200 [m])?

Podane wyżej wzory określają minimalny czas ostrzegania z którego wynika odległość czujnika od przejazdu, przy czym dla przejazdu kat. B z czterema rogatkami minimalny czas ostrzegania jest dłuższy i wynosi 46 s (wytyczne Ie-4).

Strony: [1] 2 3 ... 17