Timba

Hallo @wopitir, habe mir deine Versuchsstrecke runtergeladen und kann deine Beobachtung nicht nachvollziehen. Strecke 1670 oder 1680 mit jeweils 50 kmh, in beiden Fällen bleibt die Lok bei mir am selben Punkt stehen. Und zwar genau (im Fall 1680) nach 1713,49 mm. Das ist der Punkt, den mir meine Exceltabelle für die gegebenen Daten anzeigt. Deine Formel ist meiner Meinung nach fehlerbehaftet, aber da sie immer exakt denselben Fehler produziert, nämlich einen ca. 2% längeren Bremsweg, kann man damit auch gut leben. Übrigens habe ich auch noch ein paar Versuche gemacht gestern. Neos Aussage, dass die Verzögerung intern mit Fließkommazahl arbeitet, fand ich bestätigt. Allerdings habe ich dieselbe Beobachtung gemacht wie du, nämlich dass bei extrem niedrigen Geschwindigkeiten es sehr ungenau wird und nicht mehr mit den Berechnungen in Einklang zu bringen ist. Das wird vielleicht an der Verarbeitung der Frames liegen, so wie er es erklärt hat. Die Logik dahinter offenbart sich mir zwar noch nicht, denn ich meine, je langsamer die Lok fährt, desto genauer müsste es eigentlich werden, aber egal, inzwischen habe ich diesen Weg ohnehin verlassen, wie du vielleicht gelesen hast. Die Berechnung einer zeitlichen Verzögerung des Bremsvorgangs sieht irgendwie besser aus und ist effizienter, weil präziser.

Hi Tom, das mag der Realität näher kommen, keine Frage, aber es wird für die Modellanlage dabei auch zunehmend weniger praktikabel. Das darf man nicht aus den Augen verlieren. Denn es werden nicht nur die Bremsstrecken entsprechend länger, sondern auch die Sicherheitsabstände zwischen den Zügen müssen entsprechend angepasst werden. Bei der letzten Anlage bremste ich mit einer Verzögerung von 2,0 und brauchte da bereits einen Mindestabstand von über 3.000 mm, damit bei der Einfahrt in den Bahnhof nicht der nachfolgende Zug hinten drauf fährt. Ich fürchte, bei 1,0 kann das schnell das Doppelte werden. Habe ich noch nicht berechnet. Schlimmstenfalls kann dann immer nur ein Zug über die Platte fahren. Mich würde das nicht so sehr befriedigen.

Also, ich nehme ja am liebsten das Brückensystem Content-ID 3F21D82A-E147-4D16-8B32-B3FAB361E018 Dann habe ich zwar alles dieselben Brücken, aber das Ding kann man wenigstens in Länge und Radien verändern, weil es als Spline daherkommt. Für zweigleisige Strecken kommen dann zwei Brückenteile nebeneinander.

Das sollte doch mit Skalieren zu bewerkstelligen sein. Die Proportionen bleiben dabei erhalten. Es wird nur alles gleichmäßig größer oder kleiner.

War dem Wikipedia-Artikel eigentlich zu entnehmen, ob die DB für die Reinigung des Anzugs aufkommt? Aber mal ganz ohne Quatsch: Die durchschnittliche negative Beschleunigung des ICE mit den angegebenen Werten ist ca. 1,27 m/s^2. Ein Auto hat bei einer Vollbremsung eine negative Beschleunigung von 7,5-8,0 m/s^2. Das kann sich jeder von uns Autofahrern gut vorstellen, denn fast jeder musste schon mal irgendwann eine Vollbremsung machen. Aufgrund dieses Vergleichs denke ich, dass das Hacksteak weitergegessen werden kann, während der ICE bremst. Das Ding hat trotz bester Bremsen einfach zu viel Masse, um mehr oder weniger abrupt zum Stehen zu kommen und überdies ist Metall auf Metall nicht unbedingt die beste Kombi zum Bremsen. Bei Straßenbahnen wird für eine Vollbremsung daher automatisch Sand gestreut, habe ich mal gehört, ob das auch für Eisenbahnen gilt weiß ich nicht.

@metallix, @Andy nun habe ich das Experiment mal modifiziert und statt flexibler Bremswirkung den Weg über die Zeitverzögerung probiert. Sieht wirklich besser aus und bremst meiner Meinung nach auch präziser. Bei der Demo habe ich bloß eine 1980 mm lange Strecke, das funktioniert noch bis 150 kmh bei einer Bremsverzögerung von 5,1. Bei anderen Werten muss man halt die Strecke ggf. verlängern (oder verkürzen, je nachdem). Ein ICE mit 330 Klamotten und der Bremsstrecke, die @Goetz weiter oben rausgesucht hat, braucht dann halt im Maßstab H0 knapp 38 Meter Modellbahnschiene, wenn man's realistisch haben will. Ist ne Herausforderung . Ansonsten muss man mit den Werten agieren, die einem gefallen. Persönlich finde ich eine Bremswirkung von ca. 2 bis 4 m/s ganz ansprechend, wohl wissend, dass das noch weit über der Realität liegt. DemoBremse.mbp

Du musst immer mit allem rechnen. Das Leben ist hart und grausam.

Ach, noch was, Tom. Man kann in diese Berechnungen ja auch unterschiedliche Verzögerungswerte einfließen lassen. Das heißt, dass man dem Güterzug einen kleineren Verzögerungswert zuweist, da er ja aufgrund der Masse langsamer bremst, und dem ICE mit hochmodernen Formel 1-Bremsen einen höheren Verzögerungswert. Diese lassen sich ja genau wie currentSpeed auslesen und verarbeiten und in der Formel zur Berechnung des Bremswegs ist der Verzögerungswert sowieso nötig. Dann wäre das Ganze noch viel realitätsnaher.

Hi Tom, mit der Realitätsnähe muss man es ja auch nicht übertreiben. Dass ein langer, schwerer Güterzug einen längeren Bremsweg hat als ein kleiner Personenzug mit vielleicht nur 3 Waggons liegt ja auf der Hand, doch spielt es für die Simulation meines Erachtens nicht die ganz große Rolle. Da kommt es (mir) nur darauf an, dass der Brems-/Haltevorgang wenigstens einigermaßen die Realitätsvorstellung abbildet. Andere mögen das anders sehen. Mit den hier angebotenen Möglichkeiten sollte jeder seine Glückseligkeit finden können. Die Berechnung des Verzögerungswerts dürfte ziemlich easy sein. Man muss einen Gleiskontakt am Beginn des längstmöglichen Bremswegs positionieren. Mit der gegebenen Geschwindigkeit des auslösenden Zugs lässt sich der Bremsweg berechnen, zieht diesen von der Gesamtstrecke ab und berechnet dann die Zeit, die der Zug braucht bis zum Bremspunkt. Diese Berechnungen nutzte ich bereits in V4, dort zwar nicht zur Steuerung, sondern in erster Linie zur Positionierung der Auslösepunkte. Die hätte ich zwar auch durch Ausprobieren finden können , aber ich rechne doch so gerne.

Also, zuerst eine Flasche vorzüglichen Single Malt reinschütten, dann eine knappe Stunde warten, bevor man sich ans MBS begibt. Dann wird aus der blanken Platte mit Holzstruktur blühende Landschaften (Zitat Kohl).

Ach ja (Hand vor Stirn klatsch), diese neue hervorragende Möglichkeit vergesse ich immer wieder. Danke für die Erinnerung.

Ich suche eine Möglichkeit, einen Zug um 8:00, 10:00, 12:00, usw. (jeweils Anlagenzeit) abfahren zu lassen. Etwas um Punkt xx:xx auszulösen hilft mir da nicht, außer ich würde für jeden Zeitpunkt ein eigenes Ereignis definieren. Ist mir zu redundant. Als ich bemerkte, dass die Bedingung der grafischen EV meinen Bedürfnissen nicht gerecht wird, habe ich sie kurzerhand in Lua umwandeln lassen und > durch == ersetzt, dann geht's, auch mit Mehrfachbedingungen.

Aha, Tom, und wer ist der MBS-Teufel, vor dem die Zeit halt macht? Du hoffentlich nicht, oder was?

Hab's schon rausgefunden. Ist wirklich dauerhaft erfüllt und löst jede Minute aus. Hm ...

Hallo, mal ein Definitionsfrage. In der grafischen EV gibt es die Bedingung "Zeitpunkt überschritten" mit der Möglichkeit, eine bestimmte Anlagenzeit einzugeben. Nehmen wir an, es ist 12:00 eingestellt. Da es wie gesagt eine Bedingung und kein Auslöser ist, muss ein anderes Ereignis auslösen. Nehmen wir also weiterhin an, Auslöser ist ein Gleiskontakt. Und wir nehmen auch noch an, dass dieser Gleiskontakt um 12:10 Anlagenzeit ausgelöst wird. Rein dem Wortsinn nach ist auch um 12:10 der Zeitpunkt (12:00) überschritten. Heißt das also, dass diese Bedingung permanent erfüllt ist bis ... ja, wie lange eigentlich? Bis zum neuen Tag? Oder ist nur in der Zeit von 12:00 bis 12:01 die Bedingung erfüllt, was ich vermute - und hoffe.

Sehe gerade, wir hatten denselben Gedanken.

@fzonk, was mir dazu gerade noch durch den Kopf ging: Man kann in ähnlicher Weise auch den Weg über eine Verzögerung beschreiten, indem man am GK über den Speed eine angemessene Verzögerung errechnet wird und nach Ablauf dieser mit konstanter Verzögerung gebremst wird. Da Verzögerungen mit sogar drei Nachkommastellen arbeiten wäre das sehr viel präziser und insgesamt sehr anschaulich. Auch dein 330 kmh ICE käme dann mit ziviler Verzögerung zum Stehen.

Nur Fliegen ist schöner, Andy.

Hi Frank, danke für den Hinweis. Mit vierfacher Geschwindigkeit habe ich nicht getestet. Ich glaube aber auch nicht, dass es daran liegt. Meiner bisherigen Erfahrung nach beeinflusst die hohe Simulationsgeschwindigkeit so etwas nicht. Wohl aber weiß ich, dass bei extrem niedrigen Geschwindigkeiten der präzise Haltepunkt nicht erwischt wird. Das liegt daran, dass die Beschleunigung und Verzögerung auf eine Dezimalstelle auf- oder abgerundet wird. Bei 20 kmh müsste die Verzögerung exakt 0,12318086 sein. Da MBS diesen Wert auf 0,1 abrundet ist die Bremswirkung 23% zu schwach und schon gibt es frische Steaks. Ist klar. Bei höheren Speeds ist diese Rundungsabweichung zunehmend irrelevant. Sagen wir mal so, für den "Normalbetrieb", also bei Geschwindigkeiten zwischen 50 und 200, funktioniert es gut genug. In einer Situation mit extrem unterschiedlichen Geschwindigkeiten könnte man die Berechnung sicher noch verfeinern.

Es mag vielleicht etwas befremdlich wirken, wenn der Lehrling den Meistern widerspricht, aber ich halte die Variante mit verschiedenen Verzögerungen zur Lösung von Achims Problem immer noch für eleganter. Ich kann das auch begründen. Selbstverständlich führt der von Goetz vorgeschlagene Weg auch zum Ziel und in V4 habe ich das mangels anderer Möglichkeiten genau so gemacht. Aber jetzt in V5 mit den Möglichkeiten von Lua ist das für mich nur zweite Wahl. In dem o.a. Beispiel funktioniert das mit den 2 Gleiskontakten ja noch ganz ansprechend, aber wie sieht es aus, wenn ein dritter Zug mit sagen wir mal 120 kmh hinzukommt? Dann muss der erste GK vorverlegt werden, der 120er und der 40er Zug bremsen noch ganz anschaulich, aber der 80er bremst zunächst auf 40 runter, fährt dann eine Strecke konstant und bremst dann weiter runter auf 0. Sieht nicht wirklich elegant aus, finde ich. Bei mir wird am Gleiskontakt eine kleine Berechnung angestellt. Die gefahrene Geschwindigkeit des herannahenden Zugs wird ermittelt, daraus mittels einer Formel die angemessene Verzögerung errechnet und eingestellt und sodann wird das Bremsen eingeleitet. V = $("BR 103").currentSpeed Z = (V/math.sqrt(2.25504*1440))^2 -- 1440 ist die Länge der Bremsstrecke (GK - Haltepunkt) und muss ggf. angepasst werden. $("BR 103").deceleration = Z $("BR 103").targetSpeed = 0 So bleibt jeder Zug genau vor dem Hindernis "Bulle" stehen, völlig egal mit welcher Geschwindigkeit er ankommt. Zumindest in der Ebene. Bei Gefälle oder Steigung muss die Position des GK etwas verschoben werden, ohne dabei die Streckenangabe der Berechnung zu ändern. Benötigt wird lediglich ein einziger Gleiskontakt und nur ein einziges Ereignis. Wer Spaß daran hat, probiere es aus: DemoBremse.mbp Letztendlich obliegt es aber dem Geschmack jedes Einzelnen, wie er seine Anlage steuert. Es führen meistens mehrere Wege zum Ziel.

Hallo Achim, kann man, aber ich würde es anders lösen, wenn es für mich wäre. Ich würde die Verzögerung anpassen, also in dem Fall verringern. Dann bremst der Zug langsamer und stoppt an derselben Stelle wie der 80km-Zug. Bleibt aber dir überlassen, welche Lösung du favorisierst.

Ach so. Ok, aber dann ist es trotzdem case-senstive, weil sonst hätte es ja funzen müssen. Unix ist (oder war, gibt's Unix überhaupt noch?) ebenfalls case-sensitive, soweit ich mich erinnere. Bei MS Visual Basic ist es hingegen völlig wurscht ob man groß oder klein schreibt, in beiden Fällen passiert dasselbe. Ok, das nur am Rande. Wenn man's weiß, passt man halt auf. Darum danke für die Info.

Oh ja, hatte ich bereits bemerkt, dass das case-sensitive ist. Mit kleinem t wollte die Kiste einfach nicht das tun was ich wollte. Nennt man wohl "learning by doing".

Danke, Goetz. Immerhin geht es ja, die Zeit mit tostring() in einen String zu verwanden und dann kann ich mir mit Stringoperationen ja daraus die benötigten Werte ziehen, falls ich es mir gar nicht verkneifen kann. Übrigens denke ich inzwischen, dass es nicht nur den "speziellen Zeitwert des MBS" betrifft, sondern aufgrund meiner umfangreichen Recherchen geht das wohl auch nicht mit der Systemzeit, also ich meine mit tonumber(Zeit) eine Konvertierung durchführen. Wohl kann man mit speziellen Parametern Jahr, Monat, Tag, Wochentag und diverse andere Werte aus der Systemzeit extrahieren, aber eine direkte Konvertierung ist offenbar nicht vorgesehen. Ok. Für heute genug gelernt. Gut's Nächtle!

Ach Andy, ich kann alles gebrauchen. Was ich gerade merkwürdig finde (weil unüblich), ist, dass ich problemlos einen Zahlenwert in einen Zeitwert konvertieren kann, z.B.: $("Ereignisse").variables["Abfahrt"] = toTime(0.75) jedoch umgekehrt funktioniert es nicht: $("Ereignisse").variables["Versuch"] = tonumber($("Ereignisse").variables["Ankunft"]) Da wird sogar die Variable gelöscht. Ich nehme an, weil das Ergebnis des Konvertierungsversuchs "nil" war. Mit dem Zeug, mit dem ich bisher programmiert hatte, gings auch in die entgegengesetzte Richtung, wenn's in die eine Richtung ging. Naja, man kann nicht alles haben.