[vR] LZB-Diskussion

LZB funktionierend und dazu fähige Fahrzeuge gibts nur in M-A, das ist eine eigene Welt. Da ist alles anders programmiert als was es sonst gibt. Auch das PZB ist anders programmiert. Deshalb funktioniert nicht für diese Strecke gebautes Rollmaterial extrem eingeschränkt.
Egal was in der restlichen Fahrzeugen drin ist, evtl sogar Reaktion auf PZB_Magnete, wenn keine verlegt sind, kannste da, wenn überhaupt, schalten was Du willst, da passiert nichts.
Und wenn welche verlegt sind, kommt es drauf an ob RSC- Magnete ober Vr-Magnete verlegt sind, Vr Fahrzeuge verstehen beides, andere nicht immer.
Ich hab den Eindruck, jeder redet von PZB, aber was da wo passiert und warum, interessiert (fast) keinen.
StS

Was er meint ist eher das Einschalten der LZB auf Strecken ohne LZB. Das ging/geht im ICE3 mal. Da konnte man auch auf Hagen-Siegen mit LZB Fahren. Das macht aber einfach keinen Sinn. Warum ist hier schon deutlichst ausgeführt worden. Einfach nochmal von vorn beginnen zu lesen und zu verstehen.

Das Problem ist: Man kann es nicht nochmal von vorne lesen, da Trainklipp seine Beiträge dazu gelöscht hat, auch wenn man die noch vorhandenen lesen könnte....Wenn da ein Teil fehlt, glaub mir, wird das KEINER von vorne lesen (wollen) ;D

Die wesentlichen Informationen stehen auch in den anderen Beiträgen. Die von Trainklipp waren da eher inhaltslos was die LZB angeht. Hier ist also nichts verloren gegangen

Ich sagte ja auch "was die LZB angeht" und nicht "deine Beiträge sind komplett inhaltslos". Ich bezog es nur auf die hier geführte LZB Diskussion um die Funktion derer, nicht auf die Fragestellung nach dem Einbau in bereits vermarktete Fahrzeuge.

ich würde mir wünschen, dass RSC die devdocs genauer und tiefschürfender schreiben würde. aber man muss sich auch vor augen führen, dass RSC immer einen schritt voraus sein will, da ja drittanbieter auch potentielle mitbewerber sind.
aus meiner sicht ist das marktpolitik.

das beispiel von Maik im april mit dem zerlegen eines autos ist ein gutes beispiel.
wenn man sich allerdings jetzt mal vorstellt vw baut seine fahrzeuge so, dass es nicht wirklich möglich ist ohne insiderwissen die hütte 1:1 so zusammen zu bekommen, wie es vor der demontage war, dann kann man nachvollziehen warum RSC nicht alle informationen preis gibt.
gut möglich, dass deutsche entwickler noch nicht den guten ruf haben, den ihnen zustehen würde.
gute oder sehr gute entwickler gibt es hier und dort, da sind wir uns alle einig.
Kann ja möglich sein, dass RSC erst dann reagiert mit mehr informationen aufzuwarten, wenn ihre umsatzzahlen zurückgehen und drittabieter quasi die karre retten. meine betrachtung ist eine hypothetische annahme. noch macht ja RSC umsätze und kann sich zurücklehnen. aber wer weiss wie es in 5 jahren ausschaut.

bestes beispiel ist ein anderer australischer hersteller, der seine devdocs auf einen stand hält wo die devdoc schon vom gilb befallen sind.

möglich dass RSC in der zukunft alle devs mit allen informationen versorgt, die sie brauchen, um gute oder gar sehr gute produkte zu liefern.

schön wäre es wenn der weg nicht so steinig wäre, wenn sie zusätzliche tools schreiben würden, die es den entwicklern gestattet neuerscheinungen schneller und qualitativ hochwertiger zu entwickeln.

andere hersteller, nehmen wir mal wieder die autoindustrie, begreifen es endlich, dass zulieferfirmen mit knowhow versorgt werden müssen.denn wo wäre denn vw jetzt wenn zulieferfirmen im dunkeln tappen müssten.

ohne jetzt zu wissen wie railworks/railsimulator etc wirklich unter der haube tickt, kann man als anwender ganz gut sehen, dass RW/RS viel mehr potential hat.

wenn ich den begriff expert lese, erwarte ich als anwender, dass es in diesem modus so funktioniert wie man es gelernt hat.

ja und da beisst sich die katze in den schwanz. wieviel fachwissen haben denn die entwickler wirklich. ich meine jetzt den betriebsablauf bei der bahn.

jedes land hat andere vorschriften. was ist der gemeinsame nenner aller eisenbahngesellschaften, was macht die unterschiede aus. kann eine softwärebasis dies alles abdecken? die frage muss man sich stellen und dann begreift man evtl auch wo die grenzen sind.
ich als anwender erwarte, wenn ich auf deutschen strecken fahre, dass dort im expertmodus der betriebsablauf auch so funktioniert wie es zu erwarten ist. den deutschen entwicklern sollten möglichkeiten in die hand gegeben werden, niucht darüber lange grübeln zu müssen ob dies oder das funktioniert.
es ist völlig legitim, dass der anwender von einer eisenbahnsimulation mit expertenmodus erwartet, dass es wie beim vorbild funktioniert. schliesslich geht man doch davon aus, das wir hier keine modellbahn simulieren wollen.

jetzt könnte jemand fragen wieviel ich dafür bezahlen würde. mit den erwartungen die ich an eine expertversion stelle liegt im dreistelligen bereich. für eine lok würde ich auch 100 euro bezahlen. quasi den preis den man für ein gutes plugin bezahlen würde.
aber wie hoch ist der bedarf, wie genau ist es erwünscht und welchen gegenwert kann man für den preis erwarten.
all diese überlegungen muss man einbeziehen.
ein gutes beispiel für konkurrenzdenken ist wohl das jüngste produkt on RSC (BR232)
warum werden uv-koordinaten so angelegt, dass es repainter schwer haben dafür sehr gute ergebnisse zu liefern.
wohl deswegen um sich selbst eine tür offen zulassen, wenn die umsatzzahlen sinken und man mit eigenen repaints noch absatz produzieren kann.

fazit ist, dass man nicht zu blauäugig an ein projekt herangehen sollte. sich sehr genau im vorfeld klar werden muss was wirklich geht und was nicht.
ich würde gar nicht erst mit vorankündigungen kommunizieren wenn ich nicht in absehbarer zeit das auch erfüllen kann. wenn man sich bei Vr mal die vorankündigungen anschaut die sie sich als Ziel gesetzt haben muss ich schon sehr staunen.
ankündigungen würde ich nur veröffentlichen, wenn dies alles schon betastatus hat. der erwartungsdruck der anwender wird irgendwann so hoch sein, dass man die erwartungen nicht mehr mit den eigenen qualitätsvorgaben abdecken kann.
wenn ich schon sowas tue dann sollte ich auch wirklich wissen ob der bedarf da ist.

ich als anwender kann schnell mal eine liste von baureihen aufzählen die ich mir wünsche. ist damit schon mein bedarf hinreichend dargelegt? ich persönlich bin bescheiden. ich habe nur eine baureihe die ich mir wünschen würde. wenn ich aber resonanzen lese wie hoch der bedarf nach dieser baureihe ist, komme ich schnell zu dem schluss, dass ich noch lange träumen darf.

um fragen dazu vorweg zu beantworten:

die baureihe 250 001-5 und die serienloks.

baupläne dazu habe ich bereits aber bis dato hat sich keiner der entwickler gefunden, die diese baureihe auch bauen würde.

warum gerade diese? nun ich mag deutsche und amerikanische loks. und die 250 ist eine lok die liebhaber beider lager bedient.

nur schade, dass diese lok so wenig abnehmer gefunden hat auf dem deutschen markt.

was die realität wiederspiegelt wird wohl auch hier nicht anders sein.

ich könnte hier noch stunden lang schreiben, werde hier aber mal einen cut machen.

gruss dean

Ich häng das mal hier rein weil ich keinen neuen Thread aufmachen will.

Ich brauche eine Berechnungsmethode für den Bremseinsatzpunkt der LZB. Da ich kein hochkarätiger Mathematiker bin, steh ich aufn Schlauf und brauche schnell eine Idee. Bisher ist der Bremseinsatzpunkt nur in 3 Entfernungen geteilt die schlicht von der VZiel abhängen (<100=4000m, <160=3000m, >=160=2000m). Das ist nett, aber unpraktisch wenn man eine VZiel von 80 bekommt und nur 100 fährt. Hier muss eine variable Berechung ran. Aber ich komm nicht zum guten Ergebnis.

Was haben wir:
- Bremskurvenformel statisch (muss so bleiben fürs erste) ... VSollAmZug = wurzel( ((VZiel * 0.28) ^2 ) + (0.8 * (VZielEntfernung - 20)) ) * 3.6;
- VIst km/h
- VZiel km/h
- VZielEntfernung in Meter

Was habe ich bisher:
Ich subtrahiere VZiel von VIst wenn VZiel < VIst ... dann habe ich eine Differenz
Aus der Differenz interpoliere ich einen Wert --> Lerp(0,200,1000,4000,Differenz)
..Das ergibt also bei diff=0 einen Bremseinsatzpunkt von 1000m und bei diff=200 einen bei 4000m
...Die interpolierte Entfernung wird als Vergleichswert für die VZielEntfernung genommen
-----> wenn(VZielEntfernung <= interpolierte Entfernung) dann {LZB Beeinflussung}

Letztlich ist der Aufwand nur für die Schnarre und das G zur Warnung des Tf da dass die Bremsung eingeleitet werden muss, aber das finde ich schon sehr wichtig. Bei AFB Betrieb gestaltet sich das eh schwieriger. Die AFB hängt an einer seit eben unterlegt berechneten VSoll mit einer Differenz, interpoliert aus 0<->VIst.

---
An wissende Tf gefragt:
Was passiert eigentlich wenn man so dolle bremst dass man unter den Bremseinsatzpunkt gerät? Wird die Beeinflussung dann beendet und das G erlischt, obwohl man VZiel und VZielEntfernung nicht erreicht hat? Oder bleibt die Beeinflussung aktiv bis VZielEntfernung erreicht ist, egal wie langsam man fährt?

Schnell ne Idee ist leider nicht
Ich setzt mich heute mittag mal dran, vielleicht finde ich ne bessere Lösung

Danke, hat sich erledigt. Mal wieder einem Irrtum auferlegen. Der Bremseinsatzpunkt ist stets dann erreicht, wenn die (VIst + 30) < Vsoll wird. Die Entfernung ist dabei nicht maßgebend scheinbar, bzw. wird durch die Bremskurve ja schon berücksichtig. Machts einfacher das umzusetzen. Kommt also doch das G und die Schnarre erst an diesem Punkt und nicht vorher.

Für die Wissenden: VSoll-Steller Quittierung nach LZB Ende im AFB Bterieb ist implementiert (ohne AFB Bteriebszwangsbremsung).

Ist es eigentlich möglich verschiedene Werte für die Zielvorschau der LZB zu implementieren? 9900 m sehen ja nur Züge über 200 km/h und welche mit sehr wenigen BrH. So ein 200 km/h Schnellzug mit ner 120 vorne drauf sollte eingentlich nur 7000 m weit sehen. Bis 160 sieht man normal überhaupt nur 4000 m.

Sollte eigentlich programmierbar sein. Schätze Maik bräuchte ne Quelle, dass es so ist und es ist die Frage, ob es sinnvoll zum Aufwand ist.

Implementieren möglich, aber ansteuern/umschalten nicht wirklich sinvoll machbar. Woran soll ich festmachen wann welche Maximalentfernung eingesellt wird. Man kann ja nichts wirklich configurieren im TS für einen bestimmten Zug. Ich kanns gern auf 7000m fest einstellen. Macht aber wohl merklich im TS auch keinen Unterschied. Signale werden sowieso erst ab 4000m sinnvoll erkennbar.

Ich würd das gut finden für den TS, dann bekommt man nicht so viele nicht relevante Änderungen angezeigt.
Ich schätze mal Maik hat sicher Unterlagen wo das drinnen steht?

Edit: Das mit den 4 km im TS wusste ich nicht.

Maik Goltz: Du hast hier mal nach was mit Bremskurven gefragt. Brauchst du die LZB Beschreibung der ÖBB, da ist eine Tabelle mit Bremskurven und Verzögerungswerten drinnen!

Was sind denn nicht relevante Änderungen?

Frank

Nicht relevant ist eine Änderung von 160 auf 160 km/h!

Änderungen von 160 zu 160 werden von der LZB (meiner LZB Implementation) nicht angezeigt. Die Bremskurve ist statisch eingestellt auf eine bestimmte negative Beschleunigung (0,8m/s²) und das muss auch erst mal so bleiben.

Wenn es nur so funktioniert im TS dann lass ma es lieber so
In echt gibt es 8 verschiedene Bremskurven mit Verzögerungswerten zwischen 0,14 und 0,50 m/s².

Und wenn dann noch ETCS kommt, na das macht Spaß.

Wie isses da gelöst? Du fährst doch bestimmt auch Salzburg-Wien?

Also sind 0,8m/s² ja doch ziemlich viel zu viel. Also ich kann die runterstellen aber eben nur auf einen bestimmten Wert. Werde mal mit 0,5 testen, das wäre für die AFB auch entspannter, aber das könnte wohl Probleme mit den LZB Halten geben. Wenn man aus 200km/h einen Halt angekündigt bekommt ist man bei 0,8 bei etwa 3800m und muss bremsen. Bei 0,5 dürfte das nicht reichen und dann ist das einwandfreie Erkennen von Halt nicht mehr gewährleistet. Wie man sieht, die Dinge sind nicht immer "falsch" weil Wissen fehlt, sondern weil es nicht anders machbar ist im TS.