Forum Główne > Urządzenia srk

Symulator małej stacji z mechanicznymi USRK

<< < (7/31) > >>

jageer:

--- Cytat: Paweł Piotr w 25 Maj 2015, 16:14:19 ---Dąży się do optymalizacji liczby drążków przebiegowych tak, by zamykać przebiegi jak najmniejszą liczbą drążków przebiegowych.

--- Koniec cytatu ---

Ogólnie, w przypadku prostej stacji i szlaku 2 torowego (blokada 1 kierunkowa), może się zdarzyć jeden drążek, dla wyjazdu z wszystkich torów :)

marcinw:
[ciach beziery]
W takim razie zaimplementuję :)


--- Cytat: Paweł w 25 Maj 2015, 15:31:17 ---Czy równolegle do symulatora rozwijasz jakiś edytor scenerii?

--- Koniec cytatu ---
Tak, z tym, że jeszcze nie jestem pewny, w jakim dokładnie kierunku powinienem iść.

Aktualnie wszystko edytowane jest w samym edytorze unity. Na bieżąco piszę do niego skrypty, które ułatwiają tworzenie typowo kolejowych rzeczy, np. tory czy zwrotnice podczas edycji przyciągają się (snap) końcówkami (pozycja i orientacja), jest narzędzie do wstawiania trakcji, które automatycznie wstawia odpowiedni słup/wieszak (naprzemiennie długi/krótki lub seria takich samych) i łączy z poprzednim drutami odpowiedniego typu, semafory z automatu 'podłączają' się do najbliższego toru, czy też skrypt, który napisałem wczoraj, który wyznacza i odpowiednio nazywa wszystkie potencjalnie możliwe przebiegi spod zadanych semaforów.

Przykładowy screen:
https://www.dropbox.com/s/smyk8t0q90wb33z/editing.png?dl=0

Zaletą edycji w edytorze unity jest to, że można zrobić praktycznie wszystko, bo to bardziej podchodzi pod tworzenie 'moda', niż prostej scenerii (masz nawet normalny debugger dostępny do skryptów). Kolejna zaleta to otwartość, tzn. jak choć trochę znasz c# albo nawet javascripta, to możesz samemu pisać rozszerzenia, łącznie np. z eksportem do innego formatu, chociażby MaSzynowego. Wadą znowu jest ogrom opcji zupełnie zbędnych, jeśli jedyne, co chcemy zrobić, to stworzyć nową stacyjkę, no i możliwość popsucia czegoś przez przypadek, jak np. wstawimy semafor i przypadkowo wywalimy z niego skrypt, który go obsługuje. Musiałbym pogadać i poeksperymentować z ludźmi, którzy zajmują się tworzeniem poważnych scenerii, czego tak na prawdę potrzebują.

Unity ma tę fajną właściwość, że skrypty, które działają w jego edytorze, mogą również działać w programie wynikowym, więc te wszystkie rzeczy będę mógł również wykorzystać w edytorze dedykowanym, jeśli będzie na coś takiego realne zapotrzebowanie.

Myślę nad opcją, która mogłaby zadowolić zarówno laików jak i 'power userów', że wypasione scenerie robiłoby się za pomocą edytora unity, zaś prostsze stacyjki czy posterunki (jak np. ta aktualna) robiłoby się w prostym, dedykowanym edytorku wbudowanym w grę, który może nie pozwoli na odwzorowanie jakiś skomplikowanych węzłów, za to przypilnuje, aby to, co robimy, było zgodne z przepisami.

Ale to ewentualna przyszłość :)



--- Cytat: Paweł w 25 Maj 2015, 15:31:17 ---Komunikat może być potwierdzony, ale czy to oznacza, że zwrotnica/sygnalizator się przestawił? Jeżeli tak, nie ma problemu. Ale tak jak pisałem, wystarczy że ktoś pomyli nazwę obiektu edytując dane dla nastawni i mimo że komunikat zostanie odebrany, to założenie że rozkaz został wykonany będzie błędne, a efektem będzie katastrofa w symulatorze. Ja bym projektował interfejsy czy komunikację tak, żeby była odporna na takie błędy, bez sterowania na ślepo.

--- Koniec cytatu ---
Zgadzam się, niemniej jeśli klient dostanie rozkaz, którego wykonać nie może, to to oznacza fatalny błąd na który i tak nic nie poradzimy, więc taki klient powinien się chyba rozłączyć z odpowiednim komunikatem?


A jeszcze co do aparatu blokowego, jaka jest procedura zwalniania przebiegu? Dyżurny sam zwalnia kiedy wie, że można to zrobić bezpiecznie, czy też jest to od czegoś uzależnione?

Paweł Piotr:

--- Cytat: marcinw w 26 Maj 2015, 01:42:13 ---A jeszcze co do aparatu blokowego, jaka jest procedura zwalniania przebiegu? Dyżurny sam zwalnia kiedy wie, że można to zrobić bezpiecznie, czy też jest to od czegoś uzależnione?

--- Koniec cytatu ---
Utwierdzony blokiem przebiegowo-utwierdzającym (Pu) przebieg w warunkach normalnej eksploatacji zostaje zwolniony przez pociąg, po minięciu tzw. przebiegowego miejsca końca pociągu, wskazanego w Regulaminie Technicznym Stacji (RTS), to jest miejsca, gdzie ostatnia oś pociągu opuściła ostatnią zwrotnicę utwierdzonego przebiegu. W tym miejscu w torze znajduje się element, powodujący dostarczenie impulsu prądu stałego do bloku Pu.
W dawnych rozwiązaniach dla przebiegów wjazdowych do stacji były także stosowane zwalniacze kluczowe w terenie: pracownik w terenie sprawdzał, czy pociąg wjechał z sygnałami końcowymi i minął przebiegowe miejsce końca pociągu, po czym przy pomocy klucza w specjalnym zamku powodował zwarcie obwodu elektrycznego prądu stałego do zwolnienia bloku Pu.
Utwierdzenie można także zwolnić doraźnie (w uzasadnionych przepisami przypadkach) przez obsłużenie plombowanego zwalniacza na samym bloku Pu.
Po zwolnieniu utwierdzonego przebiegu (tarczka w okienku bloku Pu zmieniła się z białej na czerwoną) i po nastawieniu na semaforze sygnału "stój" można przełożyć do położenia zasadniczego drążek przebiegowy, który zamykał zwrotnice dla tego przebiegu.

Paweł:

--- Cytat: Paweł w 25 Maj 2015, 15:31:17 ---Komunikat może być potwierdzony, ale czy to oznacza, że zwrotnica/sygnalizator się przestawił? Jeżeli tak, nie ma problemu. Ale tak jak pisałem, wystarczy że ktoś pomyli nazwę obiektu edytując dane dla nastawni i mimo że komunikat zostanie odebrany, to założenie że rozkaz został wykonany będzie błędne, a efektem będzie katastrofa w symulatorze. Ja bym projektował interfejsy czy komunikację tak, żeby była odporna na takie błędy, bez sterowania na ślepo.

--- Koniec cytatu ---

Nastawnia w takiej sytuacji może pracować dalej, tylko dany przebieg się nie ustawi, efekt będzie taki jakby wystąpiła usterka urządzenia (urządzenie "nie odpowiada"). Można zamiast potwierdzeń wykonania przesyłać komunikaty o błędzie i niewykonaniu polecenia. Ale i tak moduł symulujący nastawnię będzie musiał to poodwracać i wygenerować sobie meldunki kontroli stanu urządzeń z odpowiednimi opóźnieniami czasowymi, o ile nie dostanie informacji o niewykonaniu polecenia. Wydaje mi się, że bardziej naturalnie jest po prostu przesyłać potwierdzenia z symulatora ruchu.

marcinw:
Pawle Piotrze:
Super, o to mi chodziło :)


--- Cytat: Paweł w 26 Maj 2015, 10:36:05 ---Nastawnia w takiej sytuacji może pracować dalej, tylko dany przebieg się nie ustawi, efekt będzie taki jakby wystąpiła usterka urządzenia (urządzenie "nie odpowiada"). Można zamiast potwierdzeń wykonania przesyłać komunikaty o błędzie i niewykonaniu polecenia. Ale i tak moduł symulujący nastawnię będzie musiał to poodwracać i wygenerować sobie meldunki kontroli stanu urządzeń z odpowiednimi opóźnieniami czasowymi, o ile nie dostanie informacji o niewykonaniu polecenia. Wydaje mi się, że bardziej naturalnie jest po prostu przesyłać potwierdzenia z symulatora ruchu.

--- Koniec cytatu ---
Hmm, zaraz, teraz to już zupełnie zgłupiałem. Kto wysyła te meldunki? Masz coś jeszcze pomiędzy symulatorem nastawni a symulatorami prowadzenia pociągu? W końcu klienci od pociągów potwierdzeń wysyłać nie mogą, bo każdy mógłby coś innego wysłać i dopiero byłby bajzel :)

Nawigacja

[0] Indeks wiadomości

[#] Następna strona

[*] Poprzednia strona

Idź do wersji pełnej