Opis logiczny scenerii - VD prace koncepcyjne

[firleju]

Cześć wszystkim,

Od 8 lat mam na dysku działającą betę czegoś co można nazwać VirtualDispatcherem. Niestety ten kawałek kodu, który wtedy napisałem ma pewne braki, którymi jest nieprzystosowanie do potrzeb maszyny oraz nieprzenaszalność na inne platformy (obecnie .NET 2.0 ale napisane w VisualC++ w związku z czym niekompilowalne pod Mono). Stwierdziłem więc, że przepiszę to na C# (pracę z innymi frameworkami skończyłem na etapie zabaw, jednak pisanie w C++ wykracza poza moje umiejętności i dostępny czas - pewnie mógłbym napisać, że poświęcam go dla rodziny aczkolwiek bardziej chodzi o pewną dwulatkę ;) ). W tej chwili najbardziej zawieszam się na etapie przeniesienia tego co jest w scn na coś co jest trawialne dla VD w temacie sterowania. Powstał więc w mojej głowie pomysł rozdzielenia struktury "twardej" scenerii od jej części logicznej. Wyglądałoby to mniej więcej tak:

1. Wydzielenie przypisania eventów do torów do osobnych wpisów - w tej chwili cała praca AI jeśli chodzi o interakcję ze sterowaniem odbywa się poprzez eventy. Mają one jednak tą wadę, że praktycznie każdy scenariusz musi mieć własny układ torowy nawet jeśli wszystkie tory są identyczne w swoich właściwościach fizycznych. Żeby takie coś zastosować trzeba niestety zmodewrnizować parser na poziomie exe. Plusem jest zunifikowanie scenariuiszy do jednego układu torowego z różniącymi się tylko plikami sterującymi. W dalszej kolejności być może uda się w ten sposób doprowadzić też do tego, że AI będzie jeździło zgodnie z ograniczeniami przypisanymi przez te eventy (szczególnie wskaźniki w27).
2. Wydzielenie opisów odcinków izolowanych dla osobnych wpisów z możliwością przypisania toru do więcej niż jednego odcinka - praca VD odbywa się głównie na odcinkach izolowanych, choć tworzenie przebiegów działa u mnie na elementach fizycznych.
3. Ze względu na coś takiego jak blokada liniowa potrzebny jest rozdział na stacje, co można zrobić na poziomie odcinków izolowanych. Jednak taki opis jest potrzebny lecz nie ma konieczności trzymania go w plikach scenerii.
4. Aby VD działał poprawnie na podstawie otrzymanego rozkładu jazdy potrzebny jest opis połączeń pomiędzy kolejnymi posterunkami ruchu, w tym także typ blokady liniowej (to akurat na potrzeby części do prowadzenia ruchu) oraz typ urządzeń zamontowanych na danej stacji (sposób generacji przebiegów, opóźnienia w tworzeniu przebiegu i takie tam). Tą część i tak będzie trzeba tworzyć osobno, prawdopodobnie będzie trzeba napisać dedykowany edytor chyba, że Paul zechce dostosować swój własny.

To co tworzę jest w architekturze klient-serwer także na potrzeby przyszłego multiplayera. W tym miejscu proszę gości od exe i twórców scenariuszy i scenerii o informację czy to co proponuję ma ręce i nogi i czy w ogóle chcieliby stosować/zaimplementować takie narzędzie.

Jeśli ktoś chce napisać, że trzeba będzie znowu przerabiać wszystkie scenerie to informuję, że nie mam zamiaru zrywać wstecznej kompatybilności z obecnymi rozwiązaniami. To co jest i tak będzie działać.

Pozdrawiam

[Ra]

1. Wydzielenie przypisania eventów do torów do osobnych wpisów

Bez sensu.

Mają one jednak tą wadę, że praktycznie każdy scenariusz musi mieć własny układ torowy

Mit.

W dalszej kolejności być może uda się w ten sposób doprowadzić też do tego, że AI będzie jeździło zgodnie z ograniczeniami przypisanymi przez te eventy (szczególnie wskaźniki w27).

AI jeździ zgodnie z ograniczeniami i nie ma z tym większych problemów. Oczywiście jeśli sceneria jest zrobiona z sensem, bo trudno żeby AI wykorzystywało informacje, które nigdy nie zostały podane.

2. Wydzielenie opisów odcinków izolowanych dla osobnych wpisów z możliwością przypisania toru do więcej niż jednego odcinka

Bez sensu. Sprowadzasz w ten sposób kwestię istnienia odcinków izolowanych do obecnych eventów "obsługi misji". W efekcie bałagan zostaje, tylko nieco inaczej działa.

3. Ze względu na coś takiego jak blokada liniowa potrzebny jest rozdział na stacje, co można zrobić na poziomie odcinków izolowanych.

Na Quarku to działa od 2 lat.

[firleju]

1. Wydzielenie przypisania eventów do torów do osobnych wpisów

Bez sensu.

VD nie jest w stanie pracować jednocześnie z eventami sterującymi przebiegiem misji. Jeśli jeszcze eventy wpływające na odczyt danych przez AI pociągu są jak najbardziej ok to już takie typu rozłącz, podłącz nie. A już zupełnie odpadają takie sterujące jakimikolwiek urządzeniami srk. Jeśli exe zacznie współpracować z VD to wolisz filtrować na poziomie exe te eventy czy po prostu nie wczytać pliku z nimi?

Mają one jednak tą wadę, że praktycznie każdy scenariusz musi mieć własny układ torowy

Mit.

Ja się bardzo cieszę, że obalasz moje mity. Owszem da się to zrobić wszystko na jednym układzie torowym. Do czasu w którym nie chcesz postawić ograniczenia prędkości w innym miejscu niż zaplanował to sobie autor scenerii.

W dalszej kolejności być może uda się w ten sposób doprowadzić też do tego, że AI będzie jeździło zgodnie z ograniczeniami przypisanymi przez te eventy (szczególnie wskaźniki w27).

AI jeździ zgodnie z ograniczeniami i nie ma z tym większych problemów. Oczywiście jeśli sceneria jest zrobiona z sensem, bo trudno żeby AI wykorzystywało informacje, które nigdy nie zostały podane.

To w takim razie po co jest wpisywanie ograniczeń w tory?

2. Wydzielenie opisów odcinków izolowanych dla osobnych wpisów z możliwością przypisania toru do więcej niż jednego odcinka

Bez sensu. Sprowadzasz w ten sposób kwestię istnienia odcinków izolowanych do obecnych eventów "obsługi misji". W efekcie bałagan zostaje, tylko nieco inaczej działa.

Nie, nie sprowadzam. Ja wiem, że na OI można zrobić wiele fajnych rzeczy. Nawet zaprogramować całą obsługę głowicy stacyjnej za pomocą dostępnych narzędzi. Tylko to jest ręczne rzeźbienie każdej stacji osobno. VD jest po to, żeby nie musieć tego robić.

3. Ze względu na coś takiego jak blokada liniowa potrzebny jest rozdział na stacje, co można zrobić na poziomie odcinków izolowanych.

Na Quarku to działa od 2 lat.

Czy to oznacza, że na poziomie wpisów jestem w stanie stworzyć sobie obiekt "stacja"? Bo to co chcę zrobić nie jest symulowaniem istnienia blokady liniowej tylko symulowaniem jej działania (z podziałem na różne typy).

[Ra]

VD nie jest w stanie pracować jednocześnie z eventami sterującymi przebiegiem misji. Jeśli jeszcze eventy wpływające na odczyt danych przez AI pociągu są jak najbardziej ok to już takie typu rozłącz, podłącz nie. A już zupełnie odpadają takie sterujące jakimikolwiek urządzeniami srk. Jeśli exe zacznie współpracować z VD to wolisz filtrować na poziomie exe te eventy czy po prostu nie wczytać pliku z nimi?

Sceneria (w sensie bazowej infrastruktury) nie powinna mieć żadnych eventów do obsługi przebiegu misji. Powinny być tylko eventy odczytu semaforów, ewentualnie wygaszanie (najlepiej zajętością odcinka izolowanego, a nie toru). Komendy typu rozłącz/podłącz można wpisywać w komórki sygnalizatorów, a w zasadzie AI powinno mieć jakiś ("uzgodniony") plan manewrów. Po prostu sceneria powinna mieć osobne pliki na infrastrukturę i osobne na sterowanie misją, tak aby można było modyfikować misje bez jakiejkolwiek ingerencji w tory, ewentualnie zastąpić plik obsługujący misje oddzielnym programem.

Ja się bardzo cieszę, że obalasz moje mity. Owszem da się to zrobić wszystko na jednym układzie torowym. Do czasu w którym nie chcesz postawić ograniczenia prędkości w innym miejscu niż zaplanował to sobie autor scenerii.

W przestrzeni kolejowej istnieje coś takiego jak znajomość szlaku. Dlatego ja jestem przeciwny wprowadzaniem modyfikacji scenerii pod scenariusz, typu przesuwanie ograniczenia prędkości. Jeśli gdzieś mają być ograniczenia, to powinny być wpisane "na stałe" i ewentualnie "ukrywane". Jeśli obecne rozwiązanie z wpisaniem ograniczenia w tory się nie sprawdza, trzeba zrobić inne. Ewentualnie można np. chować poszczególne wskaźniki symulując kradzież, ale nie może to wymagać klonowania plików infrastruktury.

To w takim razie po co jest wpisywanie ograniczeń w tory?

W wielu miejscach nie jest to zrobione. Oprócz scenerii dostępnych publicznie testujemy też symulację na scenerii obejmującej okolice Wrocławia, gdzie składy jeżdżą z rzeczywistymi rozkładami. Jest to dla mnie bardziej miarodajne niż scenerie, co do których nie wiadomo, czy mają przypisane semafory, wskaźniki, prędkości oraz czy w torach nie są porobione jakieś cudactwa (typu odczyt semafora znajdującego się na innej stacji).

Nie, nie sprowadzam. Ja wiem, że na OI można zrobić wiele fajnych rzeczy. Nawet zaprogramować całą obsługę głowicy stacyjnej za pomocą dostępnych narzędzi. Tylko to jest ręczne rzeźbienie każdej stacji osobno. VD jest po to, żeby nie musieć tego robić.

Jakoś to trzeba zrobić. Ja jestem na etapie szukania rozwiązania. Jakieś w miarę działające znalazłem, ale nie jestem z niego zadowolony. Sceneria (w sensie infrastruktury) powinna być jedna. Jak się zmienia rozkłady pociągów w rzeczywistości, to nie powoduje to przerabiania odcinków izolowanych na stacjach.

Czy to oznacza, że na poziomie wpisów jestem w stanie stworzyć sobie obiekt "stacja"? Bo to co chcę zrobić nie jest symulowaniem istnienia blokady liniowej tylko symulowaniem jej działania (z podziałem na różne typy).

Mam wrażenie (może mylne), że proponujesz rozwiązanie dla sytuacji, jaka była w zakresie sterowania ruchem w 2006 roku. Większość scenariuszy nadal jest w ten sposób zorganizowanych. Natomiast obecnie da się sterowanie ruchem zrobić zupełnie inaczej. Moim zdaniem scenerie powinny mieć dobrze zorganizowaną "infrastrukturę" oraz opis techniczny. Wtedy generowanie scenariusza sprowadzi się do określenia początkowej i końcowej stacji oraz ustawienia prawdopodobieństwa nietypowych zdarzeń i pozostałego ruchu.

[firleju]

Dlatego ja jestem przeciwny wprowadzaniem modyfikacji scenerii pod scenariusz, typu przesuwanie ograniczenia prędkości. Jeśli gdzieś mają być ograniczenia, to powinny być wpisane "na stałe" i ewentualnie "ukrywane".

Tutaj bardziej chodzi mi o elementy scenariusza jak ograniczenia czasowe, zamknięcia szlaków czy wychlapy (najczęściej ograniczenia stałe). Niestety keśli zamknięcie torowe można zrobić na etapie tworzenia przebiegu misji to już pozostałe niespecjalnie.

Sceneria (w sensie bazowej infrastruktury) nie powinna mieć żadnych eventów do obsługi przebiegu misji.

Tutaj się zgadzam bardzo. Problemem jest to, że w każdym przypadku korzystamy z mechaniki, która nie została przewidziana do tak zaawansowanego sterowania przebiegiem scenariusza jaki twórcy chcą implementować nie mówiąc już o jakiejkolwiek próbie wprowadzenia multiplayera.

Mam wrażenie (może mylne), że proponujesz rozwiązanie dla sytuacji, jaka była w zakresie sterowania ruchem w 2006 roku. Większość scenariuszy nadal jest w ten sposób zorganizowanych. Natomiast obecnie da się sterowanie ruchem zrobić zupełnie inaczej. Moim zdaniem scenerie powinny mieć dobrze zorganizowaną "infrastrukturę" oraz opis techniczny. Wtedy generowanie scenariusza sprowadzi się do określenia początkowej i końcowej stacji oraz ustawienia prawdopodobieństwa nietypowych zdarzeń i pozostałego ruchu.

Narzędzie, które chciałbym stworzyć służyłoby także do prowadzenia misji, a więc zawierałoby także wszelkie narzędzia, które teraz realizuje się za pomocą eventów tylko w prostszy sposób. Nie da się zrobić w zasadzie VD bez posiadania rozkładu jazdy, a jak już i tak to trzeba zrobić to samą mechanikę można zdecydowanie rozbudować. Do tego byłoby to przygotowanie do zrobienia multiplayera z prawdziwego zdarzenia, który obsługiwałby nie tylko samą kwestię prowadzenia pociągu przez poszczególne osoby ale także może być połączony z symulacją sterowania ruchem.

[Paul]

Możesz dokładniej opisać, na jakich zasadach miałby działać Twój VD? Ja tu sobie wyobrażam system o następującej strukturze (odpowiadającej generalnie rzeczywistym systemom automatycznego sterowania, np. działających w centrach sterowania IECC):

infrastruktura przytorowa (zwrotnice, sygnalizatory, odcinki izolowane)
|
zależności wraz z przebiegowym nastawianiem, najlepiej o logice geograficznej
|
automatyka nastawiania przebiegów (ARS), działająca na podstawie śledzenia ruchu (przesuwania numerów wraz z przebiegami - PIP), rozkładu jazdy i poleceń dyspozytorskich z wyższych warstw ("dyżurny ruchu")
|
warstwa optymalizacji ("dyspozytor"), która na bieżąco sprawdza możliwość realizacji rozkładu jazdy poprzez prognozowanie rozwoju sytuacji ruchowej na uproszczonym modelu (np. CPN) i w razie potrzeby modyfikuje rozkład, np. przez zmianę kolejności jazdy lub torów ("polecenia dyspozytorskie")

Ogólnie widzę to jako oddzielną aplikację, może w serwerze, a może jako klient tego serwera (do serwera podłączamy klientów maszynistów i klientów sterujących ruchem). W ten sposób po stronie Maszyny do zrobienia jest dostosowanie scenerii i zapewnienie interfejsu (a ten już w zasadzie jest - WM_COPYDATA), ładowanie tego do exe symulatora jest niepotrzebne i niewskazane (jeżeli już, to jako zewnętrzny, dynamicznie linkowany moduł). Sceneria jest jedynie warstwą wykonawczą (eventy podające sygnały, przestawiające zwrotnice, zamykające przejazdy itp.), potrzebne dane o sieci i rozkładzie jazdy wprowadzane i przetwarzane są niezależnie. Jeżeli sceneria ma także działać bez tego systemu, trzeba przewidzieć opcjonalnie włączany plik, a najlepiej dwa pliki: z eventami sterującymi ruchem (zależności przebiegowe) i eventami kierującymi ruchem (konkretny scenariusz/rozkład jazdy). Eventy te muszą być jednak odseparowane od eventów wykonawczych, tak żeby można było je wyłączyć gdy nie są potrzebne (sterowanie ruchem przez opisany system).

Do prostej automatyki sterowania ruchem w symulatorze wystarczą w zasadzie pierwsze trzy warstwy (sceneria, zależności, ARS), pod warunkiem że zapewnimy unikanie zakleszczeń (deadlock) na odcinkach jednotorowych. Coś takiego już testowałem z niezłymi efektami. Może będę jeszcze rozwijał ten temat, jako że wszystkie warstwy nad infrastrukturą przytorową pokrywają się z tym, co robię i testuję we własnym symulatorze srk, i mogą znaleźć zastosowanie i tu, i tu.

[firleju]

Architektura wygląda mniej więcej tak:

Opis scenerii (tory, W5, W4, semafory, odcinki)
|
Opis zależności których nie da się opisać w scenerii (niektore zalezności potrzebne dla srk oraz wyizolowanie stacji, szlaków, itp.) plus ewentualne odcinki pokrywające się z tymi już zdefiniowanymi (chyba, że będzie się dało przypisać więcej niż jeden odcinek)
|
automatyka przebiegów bazująca na opisie urządzeń pb wraz z zakodowaniem wszystkich elementarnych urządzeń bez blokad liniowych, gdyż to można zrobić na zasadzie rezerwacji w warstwie wyższej
|
dyspozytor ustalający skąd-dokąd i w jakiej kolejności. Modeli teoretycznych do ewentualnych optymalizacji nie znam więc tu jest wielkie pole do popoisu dla wszystkich chętnych.

Aplikacja w wersji klient serwer, gdyż nie ma sensu bawić się we wkompilowywanie tego do exe. Jeśli chodzi o przesylanie danych to z tego co wiem wtedy musisz oprócz exe uruchomić osobny maly "serwer", który bierze schowek i wyrzuca go do sieci. Tutaj wolałbym bezpośrednio zlinkować bibliotekę do komunikacji (np ZeroMQ) do exe. Nie wiem tylko czy się da, ale to nie jest ten etap na którym należy się przejmować sposobem komunikacji.

Sterowanie urządzeniami bezpośrednio, tzn ewentualne wywoływanie eventów takich jak przestaw zwrotnicę czy wyświetl sygnał. w tej chwili widzę taki problem, że sygnalizatory są sterowane eventami z nazwami sygnałów takimi jak w Polsce i wtedy serwer jest niemożliwy do zastosowania z innymi systemami sygnalizacyjnymi. Jakiś pomysł na bardziej uniwersalne rozwiązanie?

Tak w zasadzie nie ma sensu mieszać scenerii sterowanych za pomocą VD z tymi sterowanymi za pomocą eventów, gdyż rozkład jazdy przygotowany dla tej pierwszej musi mieć zupełnie inną formę, tj. rozkład musi zawierać także wszelkiego typu manewry oraz jeśli dobrze to myślę to także zdefiniowane nazwy torów na których ma się znaleźć (z ewentualnymi alternatywami). Zakładam, że tak jest łatwiej zorganizować VD niż bawić się w szukanie poszczególnych elementów na podstawie tego co dany pociąg ma robić. No i rozkład musi być pisany odrębnie dla każdego pojazdu poruszającego się od początku do końca działania symulacji.

W tej chwili ruszam warstwę 1 i 2, tzn przenoszę kod z pracy magisterskiej (nie mogę go bezpośrednio użyć) na C# zmieniając niektóre rzeczy (np aby ewentualnie dało się symulować także działanie urządzeń innych typów w przypadku sterowania ręcznego)

[Paul]

w tej chwili widzę taki problem, że sygnalizatory są sterowane eventami z nazwami sygnałów takimi jak w Polsce i wtedy serwer jest niemożliwy do zastosowania z innymi systemami sygnalizacyjnymi. Jakiś pomysł na bardziej uniwersalne rozwiązanie?

Na obcych sieciach mogą być inne zasady sygnalizacji i logika zależnościowa (np. w sygnalizacji szwedzkiej występują różne sygnały manewrowe, informujące czy droga przebiegu jest zorganizowana oraz czy jazda odbywa się na tor wolny), nazwy sygnałów to chyba mniejszy problem, można je ewentualnie definiować w konfiguracji systemu sterowania ruchem (jakieś ogólne ustawienia dla danej scenerii). Dochodzą tu jeszcze lokalne specyfiki posterunków, np. semafory ze starymi sygnałami.

Tak w zasadzie nie ma sensu mieszać scenerii sterowanych za pomocą VD z tymi sterowanymi za pomocą eventów, gdyż rozkład jazdy przygotowany dla tej pierwszej musi mieć zupełnie inną formę, tj. rozkład musi zawierać także wszelkiego typu manewry oraz jeśli dobrze to myślę to także zdefiniowane nazwy torów na których ma się znaleźć (z ewentualnymi alternatywami).

Miałem na myśli raczej wykorzystanie samej infrastruktury przez VD i scenariusze programowane eventami. Jeżeli eventy wykonawcze zostaną umiejętnie rozdzielone od sterujących, to powinno to być możliwe (jak pisałeś na początku, trzeba np. przenieść eventy uruchamiające jakieś procedury scenariusza z wpisów torów do oddzielnego pliku).

Tak w ogóle, żeby takie koncepcje mogły być kiedyś wprowadzone do życia, trzeba by z wyprzedzeniem określić jakieś standardy nazewnictwa urządzeń, torów, eventów, rozmieszczenia odcinków w sceneriach itp.

[firleju]

Na obcych sieciach mogą być inne zasady sygnalizacji i logika zależnościowa (np. w sygnalizacji szwedzkiej występują różne sygnały manewrowe, informujące czy droga przebiegu jest zorganizowana oraz czy jazda odbywa się na tor wolny), nazwy sygnałów to chyba mniejszy problem, można je ewentualnie definiować w konfiguracji systemu sterowania ruchem (jakieś ogólne ustawienia dla danej scenerii). Dochodzą tu jeszcze lokalne specyfiki posterunków, np. semafory ze starymi sygnałami.

Tutaj bardziej mi chodzi o to, że nazwy sygnałów są konkretnym wzorem na sygnalizatorze a nie muszą być. Można to zrobić w ten sposób, że w zależności od przyjętego schematu sygnalizowania (np. polski, niemiecki, itp.) wysyłamy odpowiednią komendę do wybranego sygnalizatora, ale nie w postaci wyświetl taki wzór, a raczej wyświetl prędkość na tym taką, a na następnym jest  taka (czy jakie tam parametry jeszcze będą potrzebne). A sam sygnalizator dobiera sobie już informację jaką wyświetli.

Pojawia się kwestia jak dobierać prędkość przebiegu (zapewne z torów). To mogłoby działać w taki sposób, że wysyłasz mu, że ma maksymalną prędkość przebiegu 60 km/h a sygnalizator stwierdza, że nie ma takiej opcji i wyświetla tylko 40. W tej chwili jest ten nowy wskaźnik do podania prędkości i on tu dużo zmienia sygnał chyba ciągle nazywa się tak samo, a sam wskaźnik może wyświetlać rożne prędkości. Myślę, że łatwiej by było stworzyć API (a raczej zestaw danych obligatoryjnych oraz dodatkowych) przesyłanych do sygnalizatorów danego systemu niż bawić się w mapowania. Im więcej można objąć przypadków bez wyjątków tym lepiej.

Miałem na myśli raczej wykorzystanie samej infrastruktury przez VD i scenariusze programowane eventami. Jeżeli eventy wykonawcze zostaną umiejętnie rozdzielone od sterujących, to powinno to być możliwe (jak pisałeś na początku, trzeba np. przenieść eventy uruchamiające jakieś procedury scenariusza z wpisów torów do oddzielnego pliku).

Im dłużej o tym myślę tym bardziej widzę, że prawdopodobnie infrastruktura zrobiona pod vd (to co wyżej) będzie wymagała na tyle dużych zmian w plikach scenerii, że usunięcie eventów sterujących scenariuszem to będzie przy tym nie problem. Mogę się mylić, zobaczymy co wyjdzie.

Tak w ogóle, żeby takie koncepcje mogły być kiedyś wprowadzone do życia, trzeba by z wyprzedzeniem określić jakieś standardy nazewnictwa urządzeń, torów, eventów, rozmieszczenia odcinków w sceneriach itp.

Wydaje mi się, że będą potrzebne tylko zmiany w urządzeniach sterujących. Całą resztę można można w pewien sposób wyciągnąć jeśli np. kozioł oporowy dostanie swój przypisany typ co raczej nie będzie problemem. Nazewnictwo sterujące zwrotnicami jest juz usystematyzowane, sygnalizacje opisałem wyżej, wykolejnice tez, przejazdy z tego co wiem to też mają pewien schemat. Nie ma rozróżnienia na tory główne i boczne - jazda pociągowa czy manewrowa - (rozróżnianie po typie semafora na końcu albo jego braku?), te z peronami można rozróżnić po przypisaniu W4.

[El Mecánico]

Generalnie zasady nazewnictwa elementów infrastruktury można przenieść (przynajmniej dla scenerii zlokalizowanych na pl_PL) z instrukcji PLK. Dalej zależności i eventy wykonawcze (czyt. przekaźnikownia) należy zrobić na diagramie drabinkowym. Jakby ktoś miał przykładowy schemat elektryczny prostej nastawni, do mogę łatwo szybko przygotować diagram z plikiem pod LDmicro (oczywiście human readable)

[PiterCC]

Co znaczy "schemat elektryczny prostej nastawni"? Rozszycie kabli i ich podłączenie do nastawnicy? Zresztą, jaka to jest "prosta" nastawnia?
Może chodzi Ci o obwody nastawcze i zależności w nich zaszyte?

[firleju]

To ma być automatyczne prowadzenie ruchu (przynajmniej w pierwszej wersji) a nie symulowanie obwodów nastawczych nastawni. Jak chcesz coś takiego to zgłoś się do Paula ;)
Robimy to jak najprościej, jak najbardziej automatycznie, uwzględnianie sposobu działania srk po stronie układania przebiegów nie jest w tej chwili istotną sprawą.
Dodatkowo to powinno działać na wszystkich sceneriach po lekkim dostosowaniu (głównie odcinki izolowane, przypisanie W4, W5 oraz napisanie rozkładów)

[PiterCC]

Czyli nie potrzeba żadnych schematów elektrycznych, tylko wystarczy zaimplementować kolejność wykonywanych czynności nastawczych.

[Krzysiek626]

Wydaje sie, ze wiekszy pozytek jest z uzyskanego celu (stabilnosc wyniku), niz sposob jego uzyskania. To ma sens, poniewaz obecnie tylko uzyskanie efektu jest racjonalnym celem. Druga sprawa, gdybysmi chcieli "zmalpowac" setki polskich nastawni, to zwyczajnie nie jestesmy tego w stanie zrobic (znaczne roznice ukladowe).

[El Mecánico]

Zasadniczo, w kontekście USRK, LD można potraktować jak swego rodzaju automat logiczny, przyjmujący na wejściu stany/impulsy urządzeń wejściowych (czyt. wszelkiego typu i rodzaju czujniki na gruncie, pulpit nastawniczy) i wypluwający stany do ustawienia na urządzeniach wyjściowych (czyt. położenia rozjazdów, sygnały na sygnalizatorach przytorowych, sygnalizacja na planie świetlnym). Nic nie stoi na przeszkodzie, aby część danych we/wy puścić interfejsem z/do VD.
A co do najprostszej stacji, to miałem na myśli prostą stację mijankową, z semaforami wyjazdowymi na każdym torze, i na przykład przejazdem kat. A między wjazdowym a rozjazdem, z uzależnieniem i utwierdzeniem rogatek w przebiegach. Post. SKP brak.

[firleju]

Patrząc na sposób działania kodu w tej chwili to żeby nie modyfikować za bardzo scenerii trzeba dalej opierać się na eventach. A to narzuca rozwiązania, które działają poziom wyżej. W tej sprawie LD jako sposób sterowania poszczególnymi urządzeniami jest ok, tylko że w tej chwili nie daje jakoś specjalnie dużo większych możliwości niż to co mamy.

Cała automatyka logiki przebiegu i prowadzenia ruchu i tak powinna być zapisana wyżej (vd jako osobny program) i tam trzeba by zacząć się bawić LD i wtedy miałoby to sens.

[El Mecánico]

W zamyśle LD ma być modułem w DLL'ce, więc nic nie stoi na przeszkodzie, żeby wykorzystać go w innym programie.

[Przemekm]

Witam

Czy opisana w tym wątku koncepcja jest jeszcze rozwijana?

[firleju]

No podyskutowaliśmy sobie, ale teraz trzeba by wyciągnąć wnioski z postów wyżej oraz wnioski z dyskusji odnośnie prowadzenia ruchu na scenerii i narysować zgrubny schemat jak by to miało wyglądać.