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 - Stele

Strony: 1 ... 26 27 [28]
811
Bocznica / Odp: test-calkowo niebezpieczny pociag.7z
« dnia: 20 Lutego 2017, 17:55:39 »
Jakby to byl radiostop to by wszystkie pociągi zatrzymywalo. A więc nie może to być radiostop tylko cos innego, np. autostop.

I ten autostop mnie nie złapał, np. dlatego, że liczy sie położenie lokomotywy albo za krótko była szybkość utrzymywana.

Po przeczytaniu tego straciłem do Ciebie resztki i tak już skąpego szacunku. Po prostu ręce opadają od czytania takich głupot i ślepej wierze we własną Twoją wiedzę.
Ogarniasz ogólnie, że nie ma czegoś takiego w rzeczywistości jak AUTOSTOP? Nie wiem, jakie psychotropy stosujesz ale lepiej je zostaw.
Również nie mam bladego pojęcia skąd czerpiesz inspirację i wiedzę do pisania takich głupot ale mam(y) dla Ciebie rady:
a) ogarnij się wreszcie
b) doucz się wreszcie
c) przestań korzystać z Wikipedii do szerzenia swojej i tak już ograniczonej wiedzy.
Błagam Cię, skończ.

812
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 07 Lutego 2017, 22:00:10 »
Uzupelnilem parser plikow .fiz o brakujace elementy, pozytywny efekty ktore dalo sie zaobserwowac (moga byc tez takie, ktorych nie zauwazylem) to przywrocenie mozliwosci jazdy elektrowozami bez drutu przy zaznaczonej opcji, i dzialajacy znowu woltomierz. Niestety nie pomoglo to z poslizgiem, na co mialem nadzieje, czyli problem jest gdzie indziej.
Poprawiony jest tez blad z rozjezdzajacym sie rozkladem przy braku podanego wyposazenia stacji.

edit: znalazlem ten cholerny poslizg :d  dla zainteresowanych, w Pascalowym oryginale bylo:
    if Max0R(Abs(FTrain),Fb)>TotalMassxg*Adhesive(RunningTrack.friction) then    {poslizg}
     SlippingWheels:=true;
    if SlippingWheels then
      begin
     nrot:=ComputeRotatingWheel ( ... // etc

a w tlumaczeniu:
    if (Max0R(abs(FTrain), Fb) > TotalMassxg * Adhesive(RunningTrack.friction)) // poslizg
    {
      SlippingWheels = true;
      nrot = ComputeRotatingWheel( ... // etc

i w rezultacie w wersji c++ po wpadnieciu w poslizg predkosc obrotowa kol byla przeliczana tylko raz, a potem juz zawsze krecily sie ze stala predkoscia bez szans na zatrzymanie. Teraz jest juz jak trzeba :)

813
Na warsztacie / Odp: Odp: Exe - konwersja na C++
« dnia: 04 Lutego 2017, 15:45:52 »
Przesyłam paczkę, w której jest kilka plików .mmd, które uważam, że są dobrze przerobione, exe, na którym testowałem i przykładowy log i errors.

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

Strony: 1 ... 26 27 [28]