Also Danke an Ulf und Maik erst mal für die Erklärung.
Aber vielleicht könnte ja man das Signalteam mit ins Boot hollen und sowas für ihre Signale Entwikeln. Ihr könnt euch um die Fahrzeugtechnische Seite und das Signalteam um die Signaltechnische Seite kümmern.
Nur so als Anmerkung.
Viele Hände schnelles Ende.
Maik und Ulf müsst jetzt nichts dazu schreiben nur mal so als Kleinen Tipp gedacht.
Das Signalteam, besser gesagt der Mathias ist schon eingebunden. Aber er kann da nicht viel tun ausser einer Kleinigkeit die aber schon mal sehr viel hilft. Das kann er natürlich nicht für München-Augburg machen, das müsste dort aber gemacht werden.
Weitere Tests ergeben aber weitere Problematiken, die sich vorwiegend aus dem Streckenbau ergeben. Das heist nicht dass die Strecke fehlerhaft gebaut ist, sondern dass sie nicht LZB tauglich gebaut. So darf ein Einfahrsignal möglichst nicht direkt hinter einem LF7 stehen. Da kommt es dann zu der Situation dass das LF7 zB. 160 Signalisiert, aber das Signal das 10m weiter steht meint ein Hp0 zeigen zu müssen weil der Block belegt ist. Die LZB bekommt das erst mit wenn man an dem LF7 vorbei ist. Da hat man also genau 10m Weg um von 160 auf 0 zu bremsen.
Desweiteren gibt es ein Problem solange man sich zwischen Link0 und LinkX eines Signales befindet. In der Zeit kann die LZB nur bis zum LinkX schauen und sagt verschiedene merkwürdige Dinge voraus. RSC hat die Problematik mit den als Blockstellen fungierenden Zwergen umgangen, welche aber wiederum andere Fehlfunktionen bei normalen Zügen aufweisen (Head to Head Situationen die sich nicht auflösen lassen).
Es wird also alles andere als einfach daraus eine wirklich funktionierende LZB zu bauen. Es bedarf zumindest woh noch einiger Tage an Tests nur um überhaupt erst einmal rauszufinden wie sie wann und wo reagiert. RSC Strecken können wir nicht anpassen, aber Berlin-Wittenberg sicher schon. Viel wäre nicht zu tun ausser ein paar LF zu verschieben und einige Gleisgeschwindigkeiten zu korrigieren, bzw. überflüssige LF zu entfernen, oder fehlende aufzusetllen.
Was definitiv wohl nicht geht, ist flankierende Züge wissen zu lassen, dass da jemand mit 200 langmachen will. Die fahren einem einfach in den Weg rein, da der Block aus derem Sicht frei ist. Da sind dann also die Szenariobauer gefragt darauf zu achten, dass die LZB, durch solche Zugbewegungen in bis zu 10km Entfernung (weiter kann die Funktion nicht schauen), nicht beeinflusst wird. Man muss also die Strecke frei halten, es sei denn es ist gewollt dass ein Zug die Schnellfahrt aufhält. Das funktioniert dann sogar recht gut wenn man die LZB vernünftig parametrisiert und scriptet.
Weitere Tests ergeben aber weitere Problematiken, die sich vorwiegend aus dem Streckenbau ergeben. Das heist nicht dass die Strecke fehlerhaft gebaut ist, sondern dass sie nicht LZB tauglich gebaut. So darf ein Einfahrsignal möglichst nicht direkt hinter einem LF7 stehen. Da kommt es dann zu der Situation dass das LF7 zB. 160 Signalisiert, aber das Signal das 10m weiter steht meint ein Hp0 zeigen zu müssen weil der Block belegt ist. Die LZB bekommt das erst mit wenn man an dem LF7 vorbei ist. Da hat man also genau 10m Weg um von 160 auf 0 zu bremsen.
Das Lf 7 dürfte aber die LZB normalerweise doch garnicht interessieren, denn auch auf Schnellfahrstrecken stehen Lf 7 mit Kennziffer 16, auch wenn da 300 gefahren werden darf 
Das ist mir klar. Aber es geht ja darum was man im TS machen kann. Dass es im echten Leben funktioniert wissen wir ja. Wenn im TS ein LF da steht dann wird es erkannt und gemeldet. Nochmal zur Erinnerung, es gibt keine LZB Blöcke im TS. Man fragt lediglich Signale und LF ab.
Edit: hmm ok, möglicherweise gar kein Problem diese Situation. Im Bild sieht man oben rechste die zur Verfügung stehenden Informationen über den Streckenzustand vor einem. Da hier die LZB scheinbar auch endet (keine Ahnung ob das wirklich so ist auf der echten Strecke), müsste sogar ein LZB ENDE Verfahren eingeleitet werden. Die Situation ist also schon Streckebau technisch falsch denn LZB ENDE müsste direkt am Signal stattfinden und auch dort müsste das LF stehen, bzw braucht da gar kein LF stehen denn LZB ENDE bedeutet maxial 160 ab dem Signal. Sowas hat RSC aber auch fabriziert. Das müsste alles umgebaut werden um eine einwandfreie LZB zu garantieren. Diese Situation hier liese sich rechnerisch natürlich aufdröseln, aber es gibt noch kompliziertere Stellen wo man schlecht entscheiden lassen kann was nun wichtiger ist (LF oder Signal). Mistig kompliziert der ganze Kram. Kennt jeman die Formel (möglichst total vereinfacht) für die Berechnung der LZB Bremskurve? BrH's haben wir ja nicht zur Verfügung, nur Zuglänge und Zugmasse.
ps: die Informationen die das Bild über den Streckenzustand vermittelt sind als nichtig zu betrachten, das ist aus einer Beta und nicht aus dem aktuellen Stand.
Dass die LZB nicht richtig funktioniert, merkt man erst, wenn man mal richtige Szenarien baut für München-Augsburg, wo dir eben auch mal Zügen in den Weg kommen. Da hat der Dispatcher ein Problem mit, da dieser nicht wissen kann dass das Fahrzeug LZB benötigt und viel weitere Vorausschau. Da kommt es dann ständig zu plötzlichen VZiel Absenkungen auf 0. Das Ganze natürlich dann bei 200km/h und der Zug bremst bei AFB Betrieb sofort runter und das völlig sinnlos, weil nach dem passieren des nächsten Link0 eines normalen Signales, die VZiel wieder auf 200 zurückspringt und meint da ist nichts. Der Zug der im Weg fährt ist aber noch da. Und so kommt es dann dass 1-2km, je nach Signalabstand, plötzlich wieder VZiel 0 ist und auch da bleibt weil die Strecke eben tatsächlich blockiert ist. Und schon rauschst du über das Hp0 drüber und womöglich in den Zug rein, weil du in 2000m nicht zum stehen kommst ohne Notbremsung, und selbst die wird es kaum schaffen weil der Bremsweg mit mindestens 2000m bemessen ist. Wenn man auf einer leeren Strecke fährt mag die Täuschung funktionieren. Aber nict mit üppigem Betrieb. Und das verhindert eben auch Mischbetrieb. Damit meine ich Züge die nicht 200 fahren sondern nur 160 oder sogar nur 80.
Sorry Maik. Ich habe es schon wieder nicht geschafft im Fahrdienst IC 2082 Königssee mit 200 Km/h diesen mal richtig aufzumüschen sprich drauffahren. Es ist ein RB bestehend aus BR 111 und Doppelstockwagen. Vmax 160 und ich mit 200 Km/h hinterher. Das ist die zweite Aufgabe von mir, die deine Geschichte einfach wiederlegt. Demnächst auf meiner Hp zum Download verfügbar. Solltest du mit der Digitalen Geschwindigkeitsanzeige der 101 nicht umgehen können, ist das dein Problem aber nicht das von RSC. Ein Jumping zwischen 0 und irgend einen anderen Wert, ist ganz Normal, denn wenn das Signal nicht mehr Hp0 hat, kannst du musst du nach 
Geschwindigkeitsangabe und Entfernungsanzeige fahren.
Die nicht vorhandene Unterstützung der Entwickler in Sachen LZB durch RSC, ist selbst mir bekannt. Erstmal schaue ich mir die Schnittstelle und die Doku dazu an bzw. die Unterstützung durch Entwickler (Anbieter X). Stelle ich fest, dass es keine gibt, fange ich keine Bastelstunden an. Wer will mir und kann mir das bezahlen? Ich denke das es bei dir nicht anders ist. Solltest du keine LZB implementieren können, dann geht es eben leider nicht Maik. Niemand erwartet von VR auf eine undokumentierte Basis etwas zu entwichkeln. Wer von uns will und kann euch dass bezahlen.
Das die LZB von RSC für Augsburg-München ausgelegt ist, sollte nicht neu sein. Infolge dessen, kann ich diese nicht in einer Lok implementieren, die auf irgend einer Strecke mit LZB unterwegs ist. Das RSC als kommerzieller Anbieter dir nicht mitteilt, wie es in deren Lokomotiven aussieht, versteht sich von selbst.
Gruß Norbert
Sorry dass ich deine Beiträge gelsen habe aber ich muss der Allgemeinheit wegen doch interagieren.
Es ist ein RB bestehend aus BR 111 und Doppelstockwagen. Vmax 160 und ich mit 200 Km/h hinterher. Das ist die zweite Aufgabe von mir, die deine Geschichte einfach wiederlegt.
Falsche Situation. Das meinte ich nicht. Nochmal nachlesen und verstehen und dann mir unterstellen ich würde Falsches behaupten.
Solltest du mit der Digitalen Geschwindigkeitsanzeige der 101 nicht umgehen können, ist das dein Problem aber nicht das von RSC. Ein Jumping zwischen 0 und irgend einen anderen Wert, ist ganz Normal, denn wenn das Signal nicht mehr Hp0 hat, kannst du musst du nach
Ich bin durchaus in der Lage die Informationen die ich erhalte korrekt aufzusaugen. Das Jumping bei vorausfahrenden Zügen ist eben nicht normal weil es eigentlich dann auf 0 bleibt und nur die Entfernungsangabe variiert, aber eben nicht die VZiel. Es gibt lediglich die Schnarre wenn sich der Block nach vorne schiebt der besezt ist. Wenn man über die Sichtnetfernung der LZB dem Zug hinterherhinkt dann hat man auch keine 0 mehr sondern die Streckengeschwindigkeit. Es gibt keine Situation die dabei ein Springen der Anzeige verursacht, schon gar nicht so wie da. Also ist das was ich sage schon mehr oder weniger korrekt. Man möge mich aber gern mit fachkundigen Beweisen berichtigen.
Stelle ich fest, dass es keine gibt, fange ich keine Bastelstunden an.
Tja, DU, wir sind aber daran interessiert den Kunden etwas zu bieten was sie teilweise auch verlangen. Wenn du nicht gewillt bist deiner Kundschaft eine Leistung zu erbringen die dir auch neue Kundschaft zustellen kann, dann bist du im Geschäftswesen falsch angesiedelt. VR ist nun mal nicht ein Nachmacher sondern bereits mit der Br143 ein Voreiter gewesen. Nun muss nachgelegt werden da wir hinterherhinken. Aber ich baue nicht einfach was nach wie das manch andere gern tun sondern ergründe neue Möglichkeiten und binde damit wieder Kundschaft. Lern das mal zu verstehen. Das hat alles seinen Sinn und ist keine reine Zeitverschwendung wie du immer meinst.
Das die LZB von RSC für Augsburg-München ausgelegt ist, sollte nicht neu sein. Infolge dessen, kann ich diese nicht in einer Lok implementieren, die auf irgend einer Strecke mit LZB unterwegs ist.
Ist sie rein technisch nicht. Die Funktionen sind weder neu noch auf die Strecke begrenzt. Sie sind einfach nur nicht dokumentiert. Ich komme schon noch dahinter wie das geht. Es wäre aber deutlich einfacher wenn RSC eine Dokumentation bereitstellen würde. Müssen tun sie das natürlich nicht. Und den Beweis dass es auf anderen Strecken auch funktioniert werde ich dir schon noch erbringen. Da mach dir mal keine Sorgen.
Nach etwas Buddelei und Selbstversuchen mit unorthodoxen Methoden muss ich meine Aussage zur Sichtweite revidieren. Wenn man lustig ist kann man kaskadierend jedes Signal und jede Geschwindigkeitsbeschränkung auch 500km vorausschauend abfragen. Das wird nicht mal RSC wissen 
Bedeutet aber einigen Mehraufwand bei der Programmierung. Und sowas, lieber Norbert, findet man eben nur dann heraus, wenn man am Ball bleibt und nicht gleich behauptet die Software wäre doof und man wäre nicht zuständig die Doofheit zu korrigieren. That's vR EL ...mööp
Hehehe...
Der Maik wieder! 
Klasse... bin gespannt auf genauere Infos, wie du das hingebogen hast.
Das MFA...die wohlgeformte Führerstandsfront...das kann doch nur eins sein 
Ganz schön mutig, das schon zu verraten. Aber Du wirst, wie meisten, schon wissen was Du tust.
Hut ab! 
Ich weis nie was ich tu. Ich drück einfach hier auf den komischen schwarzen Tasten tum. Die leuchten so schön. Und wieso mutig? Ein Geheimnis war es ja nun nicht. Ausserdem ist das nur ein Übungscab 
Extra gebaut um den TS aus der Fassung zu bringen. Hätt auch ne Draisine sein können. Hauptsache die Lummies blinken.
Super, Maik!
Ich freu mich schon auf eine AUSGEREIFTE LZB, Maik findet immer einen Weg 
:vR:
Und ich freue mich schon auf die BR auch wenn es nur ein "Übungscab" 
ist .
Die ist schon so gut wie gekauft und eine gute LZB dazu ist natürlich ein Schmankerl, das sicher alle hier sehr freut. Hat sich die Pionierarbeit von dir, Maik, also doch ausgezahlt
Jetzt wartet doch erstmal ab wie sich das ganze überhaupt entwickelt 
Bis zum Status " Kaufen " ist es bestimmt noch ein langer Weg wo noch viele Probleme gelöst werden müssen.
Es war eher so gemeint, dass ich die Br 120 schon bei mir zum kauf vorgemerkt habe und mich daher dieser Durchbruch bei der LZB-Forschung sehr freut.
Ich weiß natürlich, dass die Entwicklung noch andauert, aber ein wichtiger Schritt ist es allemal und auch für Maik hoffentlich ein Erfolgserlebnis
Hmmm ich glaube das ist was anderes als die 120.
Aus dem TS2013 Development Alltag:
Ohne Dokumentation:
12:00 Uhr - Wert 1-4 einstellen | TS starten | Testen -> passt nicht
12:05 Uhr - Wert 2 ändern | TS starten | Testen -> passt nicht
12:10 Uhr - Wert 1 ändern | TS starten | Testen -> passt nicht
12:15 Uhr - Wert 2 ändern | TS starten | Testen -> passt nicht
12:20 Uhr - Wert 3 ändern | TS starten | Testen -> passt nicht
12:25 Uhr - Wert 1 ändern | TS starten | Testen -> passt nicht
12:30 Uhr - Wert 4 ändern | TS starten | Testen -> passt nicht
12:35 Uhr - Wert 1 ändern | TS starten | Testen -> passt nicht
12:40 Uhr - Wert 3 ändern | TS starten | Testen -> passt nicht
12:45 Uhr - Wert 2 ändern | TS starten | Testen -> passt nicht
12:50 Uhr - Wert 1 ändern | TS starten | Testen -> passt nicht
12:55 Uhr - Wert 4 ändern | TS starten | Testen -> passt nicht
12:05 Uhr - Wert 4 ändern | TS starten | Testen -> passt nicht
....
16:00 Uhr - Wert 2 ändern | TS starten | Testen -> passt nicht
16:05 Uhr - Wert 2 ändern | TS starten | Testen -> passt nicht
16:10 Uhr - Wert 3 ändern | TS starten | Testen -> passt nicht
16:15 Uhr - Wert 3 ändern | TS starten | Testen -> passt nicht
16:20 Uhr - Wert 2 ändern | TS starten | Testen -> passt nicht
16:25 Uhr - Wert 4 ändern | TS starten | Testen -> passt nicht
.....
22:25 Uhr - Wert ? ändern | TS starten | Testen -> passt nicht
22:30 Uhr - Wert ? ändern | TS starten | Testen -> passt nicht
22:35 Uhr - Wert ? ändern | TS starten | Testen -> passt nicht
22:40 Uhr - Lust verloren Werte zu suchen - scheiss drauf, bleibts eben wie es ist
Mit Dokumentation (Wunschtraum):
12:00 Uhr - Wert 1-4 einstellen | TS starten | Testen -> passt
12:05 Uhr Mittagspause
12:30 Uhr nächstes Vorhaben angehen
ZitatAus dem TS2013 Development Alltag:
Ohne Dokumentation:
So sieht das korrekt aus:
.....
.....
22:25 Uhr - Wert ? ändern | TS starten | Testen -> passt nicht
22:30 Uhr - Wert ? ändern | TS starten | Testen -> passt nicht
22:35 Uhr - Wert ? ändern | TS starten | Testen -> passt nicht
22:40 Uhr - Lust verloren Werte zu suchen - scheiss drauf, bleibts eben wie es ist
Eingeschlafen
Mit Dokumentation (Wunschtraum):
12:00 Uhr - Wert 1-4 einstellen | TS starten | Testen -> passt
12:05 Uhr Mittagspause
12:30 Uhr nächstes Vorhaben angehen
Aufwachen, sch€1$$€, war nur n Traum 
Die Dokumentation alleine machte es nicht, es müsste ja dann auch noch nen Änderungsdienst für all die schönen Updates geben... (an Wunder glaubend)
Winke
Jan
@ Bahnjan und Maik.
Ich bewundere immer wieder den heldenhaften Mut der Entwickler, die ohne Dokumentation an Software arbeiten, die sie nicht selbst erstellt haben.
Aus dem TS2013 Development Alltag.
1. Was will ich?
2. Welche Plattform und welche Programmiersprache?
3. Gibt es Schnittstellen und eignen diese sich für mein Vorhaben?
4.Gibt es eine Doku?
5.Zeitaufwand (Kosten Nutzen)
6.Umsetzung?
Man kann aber auch so arbeiten wie ihr "Scheiße Lust verloren. Anderes Projekt".
Gruß Norbert
