Automatyczna obsługa sygnalizatorów powtarzających

[MW]

Od czasu do czasu na forum poruszana bywa sprawa obsługi sygnalizatorów powtarzających na sceneriach.
Chciałbym tu przedstawić swoje rozwiązanie, które stosuję z powodzeniem od 10 lat.

A. Założenia i działanie:
1. Automatyczna obsługa kolejnych powtarzaczy odbywa się kaskadowo – na zasadzie domina – przez powiązane nazwy. Nie trzeba też przesyłać jawnie żadnych nazw w parametrach „inców” (jak to np. ma miejsce w przypadku tarcz ostrzegawczych). Opisywana metoda jest niezależna od obsługi tarcz ostrzegawczych.
2. Semafor wywołuje event ustawiający sygnał na pierwszym powtarzaczu, który następnie ustawia drugi powtarzacz, a ten z kolei trzeci.
3. Nazwy powtarzaczy muszą być utworzone przez odpowiednie rozszerzenie nazwy semafora. Tu przyjęto następującą konwencję z przyrostkami (przykład dla semafora o nazwie „Zc_B”). Kolejne powtarzacze (maksymalnie 3) powinny  mieć nazwy: „Zc_B_pi”, „Zc_B_pii”, „Zc_B_piii”.
4. Odpowiednie eventy znajdują się w plikach .inc semaforów z przyrostkiem –ps (np. ss5zpcpby-ps.inc) oraz „incach” powtarzaczy z przyrostkiem –d (np. ps3pzbyy-d.inc). W .inc semaforów jest „(p1)_pi_ sygnałpowtarzający”.  We wszystkich „incach” z przyrostkiem -d wywołanie sygnału na następnym powtarzaczu to „(p1)i_sygnałpowtarzający”.
5. Ostatni powtarzacz w kolejności powinien mieć „zwyczajny” .inc (bo nic dalej nie przekazuje) – i tak jest np. przy tylko jednym powtarzaczu.

Jednorazowe, prawidłowe wstawienie na scenerii semaforów i powiązanych powtarzaczy z właściwymi nazwami i „incami” pozwala zapomnieć na zawsze o obsłudze powtarzaczy – odbywa się ona automatycznie.

B. Uwagi do nazw sygnalizatorów powtarzających.
Przyjęta konwencja z przyrostkami nie odpowiada oznaczeniom występującym na planach schematycznych posterunków (gdzie np. jest ISpB, IISpB, IIISpB do semafora B). Tam nazwy są lokalne dla posterunku. Symulator wymaga nazw unikalnych dla całej scenerii. Czyli dla naszego przykładu to mogłoby być np. ISp-Zc_B albo prościej ip_Zc_B itd. Oczywiście taki wariant z przedrostkami można przyjąć i to by działało tak samo jak z przyrostkami (wywołanie w ss*-sp.inc semaforów „ip_(p1)_ sygnałpowtarzający” i w incach –d: „i(p1)_sygnałpowtarzający”).

Wersję z przyrostkami przyjęto głównie dlatego, że na listach sygnałów w edytorze, sortowanych alfabetycznie, nazwy powtarzaczy znajdują się w grupie obok nazwy semafora, co ułatwia ich szukanie i ewentualne dokonywanie zmian/poprawek i w ogóle panowanie nad nimi wśród tysięcy nazw dla całej większej scenerii. Poza tym automatyczna obsługa powtarzaczy powoduje, że formy ich nazw są nieistotne np. dla scenarzystów. Natomiast dla użytkowników symulatora powtarzacze mają widoczne na tabliczkach właściwe „rzeczywiste” oznaczenia ustawione w czasie tworzenia scenerii.
Poza wszystkim okazało się też , że od wersji exe 171023 dodawanie przedrostków do parametru przestało działać.

C. Pliki do testowania/użycia dla zainteresowanych
W załączeniu poniżej jest link do archiwum z dostosowanymi plikami .inc semaforów (ss*-ps.inc) i powtarzaczy (ps*-d.inc). Znajdują się tam pliki, które stosuję na swojej scenerii. Inne semafory łatwo dostosować przez analogię. Uwaga:  w/w „inci” odwołują się do starszych modeli .t3d (takie nadal wykorzystowuję i są one ciągle dostępne w nowej paczce). Dołączony jest też podobny zestaw dla nowych modeli semaforów i powtarzaczy – dla odróżnienia do nazw „inców” dodano na końcu „n” (ss*-psn.inc i ps*-dn.inc, można je sobie przemianować). Pliki należy rozpakować do katalogu „scenery”.

W archiwum jest też mikroscenka do testowania obsługi powtarzaczy. Blisko siebie ustawione semafor, trzy sygnalizatory powtarzające i tarcza ostrzegawcza pozwalają obserwować zmianę sygnałów. Sygnały na semaforze można ustawiać ręcznie kombinacjami klawiszy shift1, shift2,....shift0. W pliku .scn można dla testów samemu wstawiać  różne .inc semaforów i powtarzaczy. Oczywiście obsługa niektórych sygnałów oraz tarczy ostrzegawczej zależy od rodzaju semafora.

https://eu07.pl/userfiles/24693/_SP-obsluga_automat.7z

[Balaclava]

Super koncepcja, sam coś podobnego rozkminiłem pod kątem budowy infrastruktury rozjazdowej (rozjazdy wielonapędowe, wskaźniki rozjazdowe przy napędach elektrycznych) i działa to praktycznie tak samo jak twój system - wywołuje kaskadowo eventy plus i minus z kolejnych inców, co pozwala na nieograniczone możliwości komponowania osprzętu rozjazdowego. Można na przykład wstawić do rozjazdu napęd elektryczny, stabilizator i wskaźnik położenia rozjazdu i wszystko będzie się animować synchronicznie, a przy tym jest kompatybilne pod kątem sterowania z dotychczas stosowanymi metodami.

Wyrażam zatem poparcie dla niniejszej koncepcji i uważam że taka kaskadowość to duży krok w stronę lepszej modularyzacji i standaryzacji.

[Marconi]

Na początek kubeł zimnej wody. W tym rozwiązaniu nie ma niczego innowacyjnego. Różnica jest taka, że polecenie sterujące powtarzaczem zostało przeniesione z tarczy do semafora. Metoda spowodowała to, że trzeba dopisać kilkanaście nowych sterowników semaforów (tak to wynika z zawartości paczki). Ponadto system narzuca rygory w kwestii nazewnictwa. W starym systemie wystarczyłoby stworzyć 2 - 3 sterowniki tarcz, w których znajdzie się polecenie sterowania pierwszym powtarzaczem.  Ponadto stare rozwiązanie nazewnictwa daje pełną swobodę w nadawaniu nazw, co znacznie zmniejsza ryzyko popełnienia błędów.
Moją opinię proszę potraktować jako głos w dyskusji.

[JAN21]

Tak jak kolega wyżej napisał. Obecny system jest dobry. Problem leży w syfie w plikach i nieprzestrzeganiu standardów. Aktualnie dysponujemy paromaset includami, których połowa jest dublami drugiej połowy, przy czym co rusz trzeba dorabiać jakiegoś includa bo wiecznie czegoś brakuje.

Nie ma potrzeby wynajdować koła na nowo, wystarczy uporządkować obecne pliki, usunąć duble, dorobić brakujące warianty i schować to w końcu do jakiegoś folderu, bo jaki jest sens trzymania tego całego burdelu w /scenery...

[MW]

Co do bałaganu w /scenery - pełna zgoda.  Swój sposób obsługi wdrożyłem u siebie dlatego, że istniejący ok. 2012/13 r. stan był niewystarczający dla potrzeb które się pojawiły przy tworzeniu scenerii. Jak porównuję teraz pliki mające związek z obsługą powtarzaczy w 2013 r. i w nowej paczce to nie widzę istotnych różnic – chyba, że coś przeoczyłem. Jasne, że przy takim systemie plików .inc jaki istnieje w /scenery bez jego przebudowy, nowa funkcjonalność może niestety wymagać dodania nowych plików.
(Uwaga: daty dołączonych plików są nowe ze wzgl. na edycje komentarzy wewnątrz, elementy sterujące zostały dodane w 2013 r.)

Oczywiście, każdy może używać takiego systemu jaki uważa za najlepszy i który spełnia wszystkie jego oczekiwania.

W ramach dyskusji chciałbym się odnieść do uwag Kolegi @Marconi.

1. Odnośnie przeniesienia polecenia sterującego z TO do semafora.
To właśnie m.in. sterowanie powtarzaczami z tarczy było tym, co skłoniło mnie do opracowania swojego sposobu.
Nie bardzo rozumiem, dlaczego obsługa powtarzaczy ma być przywiązana do obsługi tarcz ostrzegawczych. Na realnych stacjach istnieje wiele semaforów wyjazdowych z powtarzaczami – i tam zwykle nie może być mowy o tarczach.

Kilka przykładów z odcinka Pilawa – Dęblin LK 7 (stan przed modernizacją), kolejne stacje:
Pilawa: powtarzacze do sem. wjazdowego B bez TO, powiązanego z sem. B na podg. Jaźwiny; wjazdowego W z TO.
Garwolin: powtarzacze do wyjazdowych sem. L, M, N, O (brak do wjazdowych)
Ruda Talubska: powtarzacz do wyjazdowego sem. N (kiedyś był też do L, brak do wjazdowych)
Łaskarzew:  powtarzacze do wjazdowych P, R
Sobolew: powtarzacze do wjazdowych P, R
Życzyn: powtarzacze do wyjazdowych sem. C, D, E, F (2 szt. do E), (brak do wjazdowych)
Dęblin: powtarzacze do wyjazdowego H, wjazdowych X, Y

Istniejący obecnie stan w /scenery to sterowanie z ponad 10 includów TO dla jednego oraz dla dwóch powtarzaczy przez jawne podanie ich nazw (parametry p7, p8), a także osobno kilka incl. dla semaforów wyjazdowych (jeśli się nie mylę tylko  4-komorowych)  z poleceniem sterowania jednym powtarzaczem (parametr p7). Może czegoś nie zauważyłem, ale nie widzę istniejącego mechanizmu przesyłania sterowania do następnych powtarzaczy.

Na realnych posterunkach może być od 1 do 3 sygnalizatorów powtarzających do semafora z TO i bez TO i to skłoniło mnie do stworzenia ujednoliconego i spójnego sposobu sterowania SP z uniknięciem  przesyłania ich nazw jako parametrów.

Co do innowacyjności, to jakoś nie widzę, żeby w istniejącym stanie nowe nazwy w inc generowane były przez rozszerzenie przesłanego parametru?

2. Odnośnie rygorów w kwestii nazewnictwa.
Oczywiście można mieć różne zdania, ale wydaję mi się, że pełna swoboda w nadawaniu nazw powtarzaczy właśnie zwiększa ryzyko popełnienia błędu, zwłaszcza przy konieczności jawnego przesyłania ich jako parametrów.
Wydaje się też, że jakaś standaryzacja znacznie ułatwia opracowanie mechanizmów automatyzacji. Oczywiście jest do dyskusji przyjęcie konkretnych form. Zresztą częściowo wyraziłem swoje stanowisko w tej sprawie w pierwszym poście.

Jeszcze raz podkreślę, że nie jest moim zamiarem narzucanie swojego rozwiązanie - chciałem się podzielić. Kto chce może korzystać. Być może kiedyś /scenery zostanie uporządkowane. W końcu obecny stan jest wynikiem 2 dekad spontanicznych działań sympatyków symulatora.