Sterowanie EN57 i interfejs programu

[zderzak]

Witam wszystkich,
Symulator jest naprawdę fajny, ale:

-charakterystyki hamulca w EN57 są oględnie mówiąc złe. Hamulec EP działa za wolno, a także za słabo. W praktyce powinno dać się wyhamować na odcinku <200m bez przekraczania 2atm w cylindrach (żeby to zobaczyć, wystarczy się przejechać po warszawskiej średnicy). Osobiście dla własnego użytku poprawiłem prędkości luzowania i napełniania na odpowiednio 8 i 7, a przekładnię na 6 - wtedy hamowanie jest akceptowalne, choć nadal niezbyt ostre. Wiem, że prawdopodobnie ktoś pisał o tym wcześniej, jednak sprawa powraca w kolejnych wydaniach.

-kręcenie kranem klawiszami w trybie EP jest wyjątkowo nieintuicyjne. W prawdziwej jednostce kran trzeba trzymać, żeby hamował/luzował (i dlatego tak było w "Mechaniku"). Da się to co prawda obejść zewnętrznym programem, ale myślę, że nie byłoby złe włączenie do kolejnej poprawki obsługi którychś dwóch niewykorzystanych dotychczas klawiszy, których make odpowiadałby naciśnięciu "2" i ".", a break - "4". To by uprzyjemniło jazdę EZT, a nie przeszkadzało przy innych lokomotywach, i (jak mniemam) nie wymagało zbyt grubych zmian.

-w EN57 (i innych polskich EZT z wałem kułakowym) cofnięcie nastawnika na pozycję inną niż zero nie daje żadnego efektu, tutaj jest inaczej. Ale to już drobiazg. Opóźnienie przy rozłączaniu OG po zjechaniu nastawnikiem na zero nie wiem jak zakwalifikować. Chyba też drobiazg.

Sprawa druga: Jak wiadomo, "cały kraj buduje" domowe pulpity sterownicze. Również zamierzam sobie taki zrobić, ale tu znów pojawia się sięganie lewą ręką do prawego ucha, czyli komunikowanie się przez interfejs klawiatury (oczywiście tylko programowo - sprzętowo będzie RS232, bo protokół PS/2 jest tak powolny, że obawiam się albo zatkania jego obsługą uC, albo tygodniowego kombinowania z przerwaniami timerów).
Czy w związku z faktem, że program trzyma cały czas otwartą konsolę, nie warto by dorobić opcjonalnego interfejsu konsolowego (komendy czytane z stdin)? Warto też rozważyć taką samą komunikację w drugą stronę (przekierowanie "taśmy" na stdout, zamiast do fizycznego pliku) - niesamowicie rozszerzyłoby to możliwości programu, np. o elegancki sprzętowy szybkościomierz.

[AtapiCl]

Powiedz jeszcze na jakiej wersji jeździsz, to będziemy mogli Ci odpowiedzieć. Co do hamulca (nie tylko w EN57) - tak, wiemy - hamulec będzie śmigał w SPKS [kiedyś], co do kranu - masz stare informacje/wersje exe, co do wału - też stare informacje/wersje exe.

[zderzak]

Wersja wszystkiego (nie licząc drobiazgów) to PC2009 SP1.1. Sprawdziłem przed chwilą, amperomierz reaguje na cofanie nastawnika, kran działa tak, jak zwykły kran (zatrzymuje się na wszystkich pozycjach). Chyba, że są jakieś inne klawisze nie opisane w instrukcji.

Co do samego hamulca, to miałem na myśli, że da się to już w .chk poprawić.

PS. 3. sprawa - dźwięki 44kHz 16b stereo. Zauważyłem, że program je normalnie odtwarza (i nie obciąża przy tym niczego), a ZTCW zalecenia dla twórców są inne.

[AtapiCl]

PS. 3. sprawa - dźwięki 44kHz 16b stereo. Zauważyłem, że program je normalnie odtwarza (i nie obciąża przy tym niczego), a ZTCW zalecenia dla twórców są inne.

Cytując wytyczne:

Standardem formatu dźwięków używanych w symulatorze jest wav PCM 22kHz, 8 bit, mono. Wyjątkiem od tej reguły są dźwięki modulowane (szybkość odtwarzania takich dźwięków jest zależna od prędkości pojazdu).

Czyli dla tych wyjątków mogą być inne parametry. W pozostałych przypadkach nie.

[MArt]

W praktyce powinno dać się wyhamować na odcinku <200m bez przekraczania 2atm w cylindrach (żeby to zobaczyć, wystarczy się przejechać po warszawskiej średnicy).

Nie zawsze tak jest. W niektórych trzeba dać trochę więcej, ażeby w ogóle zaczęła hamować. Wszystko zależy od paru czynników na przykład: mieszanki z jakiej zrobione są klocki hamulcowe.

[zderzak]

Takie jest ograniczenie w dokumentacji, ale nie w programie. Również dźwięki np. haslera i styczników da się bez problemu zapuścić w stereo.

Odnośnie klocków - przy żeliwnych spokojnie daje się wjechać 60km/h w 200m perony, zacząć hamować, i jeszcze wyluzować pod koniec. Takie są moje obserwacje, potwierdzone wywiadem, i nie zauważyłem żadnych grubszych odchyłek od czasu wycofania kompozytów. Co do progu zadziałania - symulator nie obsługuje sprężyn...

[Mariusz1970]

(oczywiście tylko programowo - sprzętowo będzie RS232, bo protokół PS/2 jest tak powolny, że obawiam się albo zatkania jego obsługą uC, albo tygodniowego kombinowania z przerwaniami timerów).

PS to też transmisja szeregowa. Wg mnie jest wystarczająco szybka, bo:
1)Teraz, gdy sterowanie jest klawiaturowo czyli klawiatura-komputer, symek nie gubi inforamcji, to również uC-komputer nie będzie gubił, pod warunkiem prawidłowego zaprojektowania programu w uC.
2)Jeśli nawet byłaby taka sytuacja, iż z powodu wolnej transmisji, ilość wchodzących informacji do uC będzie większa od ilośći informacji wysyałnej przez uC do komputera, to w uC masz pamieć RAM, rejestry, gdzie możesz inkrementować i zapamiętywać ilość dochodzących informacji, a dekrementować je, gdy informacja zstała wysłana do komputera. Wtedy nawet jeśli są opóźnienia, niczego nie zgubi,a dla oka będzie to mało widoczne w normalnej sytuacji.
3)Z tego co orientuje się, transmisja PS jest po dwóch żyłach: 1-sygnał CLK (synchornizacja), 2-dane. Kluczową rolę odgrywa nie prędkość*, tylko ten sygnał CLK, aby komputer prowidłowo interpertował dane.

*oczywiście w rozsądnych granicach. Nie robiłem eksperymentów, do jakiej prędkości wyrażonej w bodach na sekundę, scalak w kompie jest w stanie łyknąć. Robiłem, iż przyspieszałem i łykał komputer informacje, ale granicznej nie mierzyłem.
Nie wiem też jaka prędkość minimalna Cię zadowoli i na czym opierasz ewentualne swoje obliczenia.

   

[MichałŁ]

W exe krusa była jednokierunkowość wału kułakowego. Sprężynowania kranu nie było w żadnym exe.

[zderzak]

@Mariusz
uC: Ja wiem, że PS/2 da się obsłużyć, problem w tym, że ten CLK według specyfikacji naprawdę musi mieć <16kHz. W tej sytuacji wysłanie np. 43x "minus" po szybkim zjechaniu nastawnikiem na zero poważnie zamuli odczyt danych z nastawników*, i będzie potrzebna zabawa z timerami i przerwaniami. Poza tym jeden klawisz to zwykle 2 bajty, po takim pokręceniu trzeba ich wygenerować 86, wepchnąć do zaimplementowanego FIFO, po czym powolutku wysyłać. A ramu jest łącznie 1kB. Lepiej, żeby się tym PC zajął. Nie mówię, że się nie da, mi się po prostu nie chce, bo prościej na PC dopisać skrypt w AutoIt v3, który przechwyci (przez zwykłą konsolę) wyjście z programu obsługującego nastawnik i wyśle "klawisze" do symka. Wtedy w ogóle prędkość PS/2 nas nie obchodzi, można wysłać niemal dowolnie dużo klawiszy na sekundę. Obsługa RS232 w mikrokontrolerze jest sprzętowa, więc nie trzeba pisać żadnych kombinacji, ani blokować sobie klawiatury (tak, wiem, można się podpiąć równolegle do istniejącej, bo to linia OC, ale wtedy z kolei trzeba pilnować kolizji), poza tym interfejs robi się hmm... bardziej uniwersalny. Np. dźwignię bocznikowania można bezboleśnie zamienić w nastawnik od kibla, albo ograniczyć liczbę pozycji nastawnika i pobawić się w EP09. I przy tym nie ładować dwóch dip-switchów na płytkę.
Testy sterowania tym symulowanym naciskaniem klawiszy robiłem, i działa bezbłędnie, a tak szybko, że nawet w symku nie zdąży "puknąć" wał nastawnika przy przejechaniu wszystkich pozycji. Da się to też oczywiście napisać w C/C++, wykorzystując normalnie widnowsowe API, kwestia pogrzebania w dokumentacji.

*Zasadniczo nastawnik czysto statyczny (bez impulsatorów), a odczyt z korekcją tzw. "drgających styków". Testy przez LPT wypadły bardzo obiecująco - można tym kręcić dowolnie szybko, i nic się nie ma prawa zawiesić/zgubić. Krany dla odmiany będą na ADC. Elektryka właściwa zacznie powstawać jutro, jak nakupię tych wszystkich 74xx.

@MichałŁ - w ostatnim zdaniu miałem na myśli sprężynę reakcyjną w cylindrze. Jej w ogóle nie ma w *.chk. A czy jest symulowana nie wiem. Wydaje się, że jeśli tak, to jako bardzo słaba.

[youBy]

Jak już to bardziej powrotną. Zauważ, że w chk nie masz też podanej pojemności zbiornika sterującego, pojemności zbiornika pomocniczego, średnicy przewodu głównego czy (co bardzo ważne) średnicy zaworu sterującego. A jednak działa :)

[Mariusz1970]

<16kHz

No około, to ile to mikrosekund na bajt?
Ile Ci potrzeba? :)

jeden klawisz to zwykle 2 bajty, po takim pokręceniu trzeba ich wygenerować 86, wepchnąć do zaimplementowanego FIFO

Nie zrozumieliśmy się. Możesz użyć dla jednego typu informacji (np. '+') 1 bajtu (256-1) kombinacji i na nim zapamiętywać . Nie potrzeba 86 bajtów, tylko inkrementacja i dekrementacja tego bajtu, który infomować będzie układ wysyłający ile tych plusów jeszcze trzeba wysłać. Jakby Ci było mało, możesz użyć 2 bajtów, to masz już 256x256 kombinacji do zapamiętnia czyli 65536-1 trzymanych informacji w kolejce dla jednego typu informacji. Tych informacji wysyłanych do symka nie ma zbyt dużo. A jeśli nawet coś zacznie Ci brakować, to nie wszystkie trzeba zapamiętywać w kolejce. Newralgicznym jest tutaj nastawnik tylko, reszta np. klawisz 'p' z punktu widzenia praktycznego, to nie będziesz nim kluczował jak 'wariat' przecież :)
Jest tu co prawda pewien haczyk, ale myślę, iż można go pominąć, albo wymyślić coś na ten haczyk :)
RAMu Ci nie zabraknie :), co najwyżej, jeśli skomplikujesz kod, to może flashu :) Musiałbyś tam doliczyć jakieś parę bajtów na start, stop, chyba parzystość w jedynkach (nie pamiętam dokładnie).
Sama sprzętowa obsługa klawiatury w kompie też zdaje się, że zawiera bufor 16 bajtów, jakby za szybko impulsy przychodziły- to fakt trochę mało.

Raczej należy się martwić, aby przy szybkim przekręceniu np. nastawnika, co uznać za stan ustalony.

No co tu dużo gadać, teraz Ci którzy mają tylko klawiaturę, nie narzekają, iż im się coś gubi, czyli jako taka szybkość protokołu PS jest wystarczająca :)


Natomiast zgadzam się, iż byłoby łatwiej, gdyby exe obsługiwało jakiś ustalony format np. po RS, wtedy zamiast szeregowo wysyłać inforamcje, wysłałbyś krótki mesydż 'ustaw się na 43 pozycję nastawnika'. ale myślę, iż w tej wersji symka zapomnij o tym i chyba będziesz zmuszony się do tego co jest dostosować jakoś :)