Hallo Florian,
Danke für die Lorbeeren für C-Digital. Schön, dass es dich interessiert und begeistert . Die nächste Zeit (halbes Jahr?) habe ich leider wenig Zeit zum Entwickeln und damit auch für die Dokus.
Zitat
Allerdings bin ich schon der Meinung, dass man auch auf halbwegs aktuellen Betriebssystemen einigermassen effizienten "Bare-Metal" Code schreiben kann, trotz allem Scheduling und Ressource-Management seitens OS.
Der Meinung bin ich auch. Es ist nur die Frage, ob die verschiedenen Steuerungssoftwares auch so geschrieben werden? Das glaube ich leider weniger, da man sonst auch alles andere "zu Fuß" programmieren müsste. Wenn ich mir die Layouts mancher Mobasoftware anschaue, so meine ich deutlich zu sehen, dass da vieles aus nem "Baukasten" stammt. Wer sollte da dann schon jedes Fenster, Button, Schieber, Dropdown-List usw. von Hand programmieren?
Eine andere Möglichkeit ist "Bare-Metal" Code einzuflechten, der eben nicht von einem OS abhängig ist, sondern mehr oder weniger direkt auf der Maschine läuft. Da bin ich mir auch nicht sicher, ob das jemand macht. Aber klar ginge das.
Zitat
Dass dabei ab und zu mal höheren Latenzen entstehen weil sich das OS entschieden hat, grade einem anderen Thread CPU Zeit zu geben ist klar. Und die gängige Lösung dazu ist eben nun mal low-level real-time embedded OS.
Ganz genau. Die OS auf dieser "hohen" Ebene, erlauben einem keine wirklich zeitkritischen Tasks. Mit einem embedded OS oder ganz ohne sieht es da schon anders aus.
Ich wollte mal auf einem embedded PC (ARM A mit Windows CE als OS einen Port in 100us getacktet schalten. Es ist mir nicht geglückt, da es immer wieder zu Latenzen kam. Das schnellste, was möglich war, war 1ms, obwohl schnelleres physisch locker leicht möglich ist. Ohne OS ist das alles kein Problem. Jeder kleine uC kann die Sys.Clock auf einen Port geben, - und da ist man dann ja im ns-Bereich.
Je komplexer diese Systeme sind, desto schwieriger/unmöglicher wird es Realtime-Tasks ablaufen zu lassen.
Übrigens, werden häufig zeitkritische Tasks, wie z.B. das Encodieren von Audio-Streams (ac3, dts,...) wegen der zeitkritischen Thematik, auf eigenen hardwareimplementierten Chips vollzogen. Danach kann die CPU dann einen gepufferten Packet-Stream abfragen und die Info weiterverwenden. Gerade im Bereich Audio können sich bereits Latenzen im ms-Bereich deutlich auswirken. (Audio und Video Encoding ist auch immer gepuffert)
Zitat
Ich denke das ist aber ein generelles Problem und hat nichts mit der Komplexität von Bremskurven zu tun.
Ja. Und ich glaube, dass das Erich auch nicht so gemeint hat, auch wenn man das aus seinem Text lesen kann, zumal er ja auch von der Verzögerung bei der Übertragung geschrieben hat.
Die Berechnung mehrerer Bremskurven stellt für keinen Rechner ein wirkliches Problem dar, solange die Software über eine konkrete Ausgangssituation bescheid weis. Da ein Rechner über massig Speicher verfügt, könnte man diese sogar abspeichern und für ein passendes Szenario immer wieder verwenden, anstatt jedes Mal neu berechenen zu müssen.
Zitat
Ich habe es nicht ausgerechnet, wage aber mal zu behaupten, dass folgendes Szenario mit halbwegs aktuellen Rechnern und sauberer Implementierung problemlos machbar ist:
1) Sammle alle Adressen, die im nächsten Digitalbus-Refresh-Zyklus ein Update benötigen
2) Frage CPU Zeit an
3) Rechne alle Fahrstufen aus
4) Schicke diese zur Digitalzentrale
Ich wage mal kühn zu behaupten, dass der obige Vorgang auch mit vielen vielen Adressen hinreichend schnell zwischen zwei Refresh-Zyklen ausgeführt werden kann. Sollte das mal nicht klappen, da wir wahrscheinlich bei 2) etwas warten müssen, klappt es beim nächsten mal und zumindest für den Betrachter der Anlage sollte es unbeachtet bleiben (da Refresh-Zyklus Grössenordnung ms).
Das meine ich auch. Aber auch hier muss ich sagen, dass das Problem des Refresh ab einer größeren Anzahl an Loks, wohl zu einem Versatz beim Haltepunkt führt. Da hilft es einem dann natürlich nicht viel, wenn die Daten zum Bremsen zwar berechnet vorliegen, jedoch nicht rechtzeitig zur Lok gelangen. Also haben wir wieder den BUS als Flaschenhals.
Zitat
Und mal ehrlich, die eigentliche Berechnung in Punkt 3) ist nun wirklich - bei jeder einigermassen realistischen Zahl an Adressen - für die CPU Pillepalle.
Ja, va. wenn man hier und da auch mal etwas speichert und linear bremst...
Das ganze wird etwas schwieriger, wenn die Bremskurve nicht linear verläuft (sigmodial) und man ausgehend von der Anfangsgeschwindigkeit so eine Kurve aufstellen muss, dann die Umkehrfunktion benötigt und die Ableitung, damit man auf den Zeitverlauf beim Bremsen kommt.
Aber auch so eine Berechnung, würde ich für jede FS einmal machen und das Ergebnis speichern. Dann braucht man nur noch einen Faktor zum Skalieren, um einen betrieblichen Versatz zu berücksichtigen.
Zitat
Gehen wir mal von einer extremen Anlage mit 1000 gleichzeitig aktiven Fahr-Adressen aus. Ich glaube kaum, dass das irgendwo erreicht wird, nicht mal im MiWuLa. Dann ist doch in jedem Digital-System der Refresh-Zyklus bereits so lang (Grössenordnung Sekunden), dass eine feinfühlige, reaktive Steuerung auf welche Art auch immer gar nicht mehr möglich ist. Klar, das Decoder-lokale Anhalten ist immer noch flüssig, aber das System als Ganzes ist nicht mehr reaktiv und damit schwer benutzbar - eine Unterteilung in mehrere Untersysteme mit Adress-Handover beim Überfahren von Grenzen ist dann wohl angebracht.
Wahrscheinlich ist das so, da habe ich zu wenig Detailwissen. Aber genau das, dass die Systeme wegen der Aus- bzw. Überlastung des BUS, dann nicht mehr reaktiv sind ist ja das Problem.
Ich umgehe das einwenig, indem ich so eine Struktur verwende, wie ich es dir mit der Baum-Metapher geschildert habe.
So kann es halt noch zu Latenzen (400 bis 800ms) bei der händischen Steuerung bei Funktionsbetätigung kommen. Das denke ich ist aber ein sehr geringes Übel. Viel wichtiger sind eben Fahr- und v.a. Halt-Befehle, weil es da oft auf einen bestimmten Punkt beim Halten ankommt. Man darf ja auch nicht vergessen, dass es mit der Sendung der Information an die Lok noch nicht vorbei ist, diese muss die Sendung auch noch korrekt empfangen. Setzt man hier eine schlechte Quote von 50% bis 75% an, verzögert sich das ganze noch deutlicher.
Zitat
Und das war eigentlich meine ursprüngliche Aussage, dass in so einem System wohl kaum der Desktop-Rechner der limitierende Faktor ist.
Ja, natürlich nicht. Die zugrundeliegende Topologie ist das größte Problem. Das ist es ja auch, was ich hier schon mehr mals klar machen wollte. Eine zentrale "Intelligenz" = Rechner mit Software, die alles handeln soll, - an der dann über virtual serial oder W-Lan ein Protokollumsetzter hängt und fertig - , ist in der mir bekannten Form nicht sehr leistungsfähig.
Entweder man setzt dann auf ein mehr "dezentrales" Netz, wo best. Informationen nur in bestimmten Ebenen verfügbar sind, oder man benützt einen viel schnelleren BUS, was zu den Problemen führt die ich dir in meinem vorigen Post schon geschrieben habe.
Außerdem kann man auch Sendungen priorisiert erfolgen lassen. Damit kann ich z.B. sicherstellen, dass bei 100 Loks die alle gleichzeitig eine Sache aktualisiert brauchen, es max. ~700ms dauert, bis die Lok diese Info hat. Damit liege ich noch relativ weit unter 1s und die Wahrscheinlichkeit, dass das bei 100 Loks gleichzeitig auftritt ist sehr sehr gering.
Eine andere mögliche Methode, wenn man schon den Rechner als zentrale Instanz haben möchte, wäre eine PCI-Karte als "Digitalzentrale", die einem einen rel. schnellen BUS zur Anlage zur verfügung stellt. Hier wäre allerdings das Programmieren von Treibern unabdingbar und ich glaube kaum, dass das eine Mobafirma zahlt.
Grüße,
Martin