• Ten serwis używa "ciasteczek" (cookies). Korzystając z niego, wyrażasz zgodę na użycie plików cookies. Learn more.
  • Szanowny Użytkowniku, serwisy w domenie modelarstwo.info wykorzystują pliki cookie by ułatwić korzystanie z naszych serwisów. Jeśli nie chcesz, by pliki cookies były zapisywane na Twoim dysku zmień ustawienia swojej przeglądarki.

światła "stopu" w tramwaju

CoCu

Znany użytkownik
#1
Nurtuje mnie już od dawna pewne zagadnienie.
Mam model tramwaju i pragnę wyposażyć go we wszelkie możliwe światła, jakie ma oryginał. Z częścią z nich powiedzmy że nie ma problemów, z drugą częścią są pewne, zaś jedna rzecz jest zupełnie poza moją wiedzą.

Otóż chodzi o tylne czerwone światła "stopu". To coś nietypowego jak na modele kolejowe, bo lokomotywy tego naturalnie nie mają. Ale tramwaj pojazdem szynowym jest, jednak bardziej drogowym niż kolejowym, więc i oświetlenie ma typowo drogowe.
I teraz tak. Kiedy działają światła "stopu"? Jazda na rozruchu - nie świecą. Jazda na wybiegu - nie świecą. Hamowanie - zapalają się. I jak to zrobić w modelu z DCC? Tak by model przy zwiększaniu prędkości (kroków prędkości) lub jeździe z niezmienną prędkością (wciąż ten sam krok prędkości) miał zgaszone te światała, ale przy zmniejszającej się prędkości (kroki prędkości w kierunku zera), się zapalały? Czyli każde przejście z kroku wyższego na niższy powoduje zapalenie się świateł, tak samo jak naciśnięcie pedału hamowania, co powoduje zwalnianie. Na postoju albo by świeciły, albo nie. To już w sumie zależy od typu samego tramwaju.

Czy ktoś ze speców DCC z tego forum potrafi takie coś rozgryźć?
 
#3
Kiedyś odbyliśmy dyskusję nt. rozgryzania. Wyszło na to, że trzeba by było inaczej zdefiniować interpretację stopni prędkości w dekoderze, tak, żeby nie odpowiadały one prędkości, a z grubsza mocy silnka i sile hamulca. Wtedy dekoder wiedziałby, że pojazd hamuje i mógłby np. zapalać stop w tramwaju.
Póki co nie mogę się wygrzebać z projektów komercyjnych, więc dekoder praktycznie leży. Wczoraj skończyłem pisanie obsługi 12 świateł i CV z nimi związanych, teraz jeszcze muszę znaleźć czas na uruchomienie tego.
 
#4
Mnie się wydaje, że światła stopu to raczej powinny się zapalać tylko przy nagłym hamowaniu. To tak jak w samochodzie, jeżeli chcesz wytracić szybkość to najpierw noga z gazu, potem na luz i w końcówce ewentualnie hamulec (jeżeli zachodzi potrzeba), co innego przy nagłym hamowaniu.
 

karol_mar

Znany użytkownik
#5
W takim razie, dekoder mógłby zapalać je, jeśli silnik jeszcze się kręci, a regulator jest ustawiony na 0 lub na przeciwny kierunek. Podobnie jest z odgłosem hamowania w dekoderach dźwiękowych.
Przy małej redukcji prędkości (kilka kroków) następowało by tzw. hamowanie silnikiem lub przy pomocy innych sił niż hamulec.
 

karol_mar

Znany użytkownik
#6
Poczytałem instrukcję od dekodera Zimo i tam jest takie coś jak "Automatic stop lights for street
cars, afterglow at stop", więc chyba problem sam się rozwiązuje :)
 
OP
OP
CoCu

CoCu

Znany użytkownik
#7
A czy ktoś mógłby sprawdzić to w działaniu w dekoderze Zimo? Znaczy się, jak to faktycznie wygląda?

Trzeba też zauważyć, że w modelu z DCC nie da się skutecznie symulować jazdy na wybiegu, a co za tym idzie także powolnego zwalniania spowodowanego siłą tarcia i oporów powietrza. Prawdziwy tramwaj puszczony w ruch, po odłączeniu napędu przejedzie jeszcze bardzo, bardzo dużo siłą bezwładności. Zaś model tramwaju tyle, ile mu na to pozwoli napęd i koło zamachowe. Czyli pewnie prawie w miejscu stanie. Dlatego też pisałem, że jazda na wybiegu będzie symulowana w taki sposób, że wciąż będzie ustawiony ten sam krok prędkości. Zaś przy krokach zmniejszających się w kierunku 0, mogłyby się zapalać te światła. W prawdziwym tramwaju też zresztą nie zapalają się tylko przy nagłym hamowaniu, ale przy każdym wciśnięciu pedału hamowania, czy zadaniu hamowania dżojstikiem (zadajnikiem).
Jak za bardzo to wszystko zostanie przekombinowane, to wtedy żadko kiedy w ogóle te światło się zapali, nawet mimo iż model będzie zmniejszał swoją prędkość.
 

ciekma

Znany użytkownik
FREMO Polska
KKMK
#11
Ale tu chodzi o to, aby zrealizować to sprzętowo na poziomie dekodera,
aby "wiedział" że przyspiesza, jedzie ze stałą prędkością ciągnąc, jedzie na wybiegu lub hamuje - gdy dekoder to "wie", to odpowiednio steruje dźwiękami, a przy okazji też światłami stopu w przypadku tramwaju.
Oczywiście to taki bonus w przypadku rozwiązania sprzętowego,
łatwiej to zrobić na poziomie przeprogramowania centralki,
ale wtedy plusem jest jedynie łatwiejsze, wygodniejsze i realistyczniejsze sterowanie.
 
#12
Przecież już odbyliśmy bicie piany na ten temat. Dopóki kroki prędkości będą przez dekoder interpretowane jako kroki prędkości, a nie nastawienie mocy silnika i siły hamowania, nie da się ani świateł stopu ani dźwięku zrobić dobrze. Dekoder może się tylko silić na inteligencję na zasadzie "jeśli nowo zadana prędkość różni się od dotychczasowej o więcej niż ileś to właśnie zarzynamy silnik przyspieszając albo piłujemy hamulce". Taka inteligencja zawsze będzie zawodna, bo musi uwzględniać odrobinę historii i coś spekulować. Co ma zrobić biedny dekoder, kiedy po prędkości np. 20 dostanie 8, a następnie 10? Skąd ma zgadnąć, czy to 10 to jest słabsze hamowanie, czy przyspieszanie po hamowaniu? Zawsze będzie jakaś niejednoznaczność.
 

gbbsoft

Aktywny użytkownik
#13
"jeśli nowo zadana prędkość różni się od dotychczasowej o więcej niż ileś to właśnie zarzynamy silnik przyspieszając albo piłujemy hamulce". Taka inteligencja zawsze będzie zawodna, bo musi uwzględniać odrobinę historii i coś spekulować. Co ma zrobić biedny dekoder, kiedy po prędkości np. 20 dostanie 8, a następnie 10? Skąd ma zgadnąć, czy to 10 to jest słabsze hamowanie, czy przyspieszanie po hamowaniu? Zawsze będzie jakaś niejednoznaczność.
No ale to da się zrobić prawie natychmiast...
:D

Dorzucasz parametr, który mówi, o ile ma się różnić "żądany" poziom kroków prędkości od "aktualnej" i jeżeli jest przekroczony ten moment, to włączasz światła aż do (a) dojścia do "żądanej" ilości kroków prędkości lub (b) zmiany "żądanego" poziomu kroków prędkości na wyższą lub równą niż bieżący (koniec hamowania)

Przecież już odbyliśmy bicie piany na ten temat.
Ja tam piany nie biję... Co powiedziałem, to zrobiłem... A WY? 8)
 

ciekma

Znany użytkownik
FREMO Polska
KKMK
#14
No właśnie Blue - stąd mój pomysł aby dekoder interpretował nie prędkość ale moc.
Dopóki dekodery interpretują kroki jako prędkość, dopóty mnożą się różne sztuczności,
co producent to inne triki, które raz działają raz nie, itp.
Patrz, nawet samoczynne hamowanie pociągów lepiej by działało, gdyby opóźnienie można było regulować na bieżąco a nie wpisane w CV.
 

Załączniki

martinezo

Znany użytkownik
#15
Masę też określimy w CV ?
Wykrywanie trybu "z górki", "pod górkę" oraz "równiny" sprzęgniemy z żyroskopem w loku lub po dodaniu dodatkowego procesora analizującego obciążenie na przestrzeni ostatniej minuty... i zmieniającego wartości CV2 i CV3.

Pełnego realizmu charakterystycznego dla pracy prawdziwych silników, realnych przyspieszeń czy hamowań, mas i oporów związanych z daną chwilą NIGDY się nie osiągnie. Modelarstwo i sterowanie modelami to kompromis. Gdyby tak nie było to nie miałbym nawet jednego modelu w domu bowiem jestem przekonany, że strop nie wytrzyma nawet najmniejszej lokomotywy...
 

ciekma

Znany użytkownik
FREMO Polska
KKMK
#16
Martinezo - daruj sobie te złośliwości bo żałośnie to wygląda.
Mnie tylko chodzi o to, aby mieć kontrolę nad przyspieszeniem/opóźnieniem lokomotywy.
Weź kiedyś Freda i pojeździj na imprezie modułowej, to zrozumiesz o co chodzi :->
 

martinezo

Znany użytkownik
#17
Jestem daleki od złośliwości - po prostu po raz kolejny daję znaki, że przy napędach dostępnym w modelach, masie modeli i całkowicie innych niż w 1:1 oporach jest to nie do osiągnięcia. To jest mrzonka. Wszystko co ewentualnie mogłoby lub powstanie będzie jedynie namiastką. Namiastką która spotka się z kolejnymi wskazaniami błędów zachowań, nowymi tezami, sposobami rozwiązań itd...
Choćby "luzu" nie zasymulujesz... moce ? jak określisz moce ? na hamowni będziesz testował silniki aby sprawdzić ich charakterystyki ? Czy moc 20% to to samo co 1/5 skali prędkości ? nie. Sama lokomotywa pojedzie inaczej, z wagonami (i różnymi ilościami i wagą) pojedzie inaczej - inteligentny BEMF ?
Jedyne co jest "realne" to mieszanie CV3 i CV4 a w konsekwencji i CV5 bo od mocy zależy tak przyspieszenie jak i maksymalna prędkość (nie wspominam już nawet o CV6 czy tabeli bo to wszystko w tym wypadku byłoby całą masą zmiennych innych dla każdej zadanej wartości i niewątpliwie w nowo stworzonej grupie CV) a i tak pozostanie to mieszaniem bo realne nie będzie.

PS.
Używam Fredków ;)
Być może nie mam problemów z manewrami ponieważ nie mam przyzwyczajeń czy skojarzeń z kabiną prawdziwej lokomotywy.
 

ciekma

Znany użytkownik
FREMO Polska
KKMK
#19
OMG, ja o kozie, a on o wozie.
A jakiej masie, luzach itp mówisz, o modelu czy o rzeczywistym pierwowzorze?
Co to w ogóle ma do rzeczy?

Mając na myśli" sterowanie mocą" nie chodzi mi przecież o moc silniczka w lokomotywie,
może tak to odebrałeś?
To byłoby bez sensu - za duże opory ruchu, efekt przekładni ślimakowej itp.
Nie chodzi też o zrobienie superhiperrealistycznego symulatora.

Po prostu chodzi o to, aby dany krok nie określał dochodzenia do danej prędkości ze stałym przyspieszeniem określonym w CV,
tylko dochodzenie do danej prędkości z przyspieszeniem zależnym od wybranego kroku i różnicy między aktualną prędkością a zadaną.
 

martinezo

Znany użytkownik
#20
Dedykowane sterowniki manualne też sobie chwalą ?
Z dedykowaną możliwością ustawienia tylko takiej ilości "kroków" jaka ma dana lokomotywa bez pośrednich kroków (tak aby można to było wykorzystać w istniejących rozwiązaniach centralowych DCC).

PS.
20% mocy jest "stałą" czy dla każdej lokomotywy dowolnie ustalana ?
Bo to rodzi kolejny problem całego szeregu zmiennych - każdy typ lokomotywy ma "inne te 20%" a idąc dalej to nawet i... 100% ;)
Chyba, że jeden dla wszystkich i basta...
ciekma napisał(a):
OMG, ja o kozie, a on o wozie.
....
Po prostu chodzi o to, aby dany krok nie określał dochodzenia do danej prędkości ze stałym przyspieszeniem określonym w CV,
tylko dochodzenie do danej prędkości z przyspieszeniem zależnym od wybranego kroku i różnicy między aktualną prędkością a zadaną.
MC...
Z tą kozą to przesadzasz - DOKŁADNIE ROZUMIEM O CO CI CHODZI:
martinezo ciut wcześniej napisał(a):
Jedyne co jest "realne" to mieszanie CV3 i CV4 a w konsekwencji i CV5 bo od mocy zależy tak przyspieszenie jak i maksymalna prędkość (nie wspominam już nawet o CV6 czy tabeli bo to wszystko w tym wypadku byłoby całą masą zmiennych innych dla każdej zadanej wartości i niewątpliwie w nowo stworzonej grupie CV) a i tak pozostanie to mieszaniem bo realne nie będzie.