Drucken

Bericht 104

Vor wenigen Tagen sandte mir Andreas dies Foto eines kleinen Schaustücks mit Drehscheibe. Er will noch bewegliche Tore in den Lokschuppen einbauen, ein weiteres Gebäude und noch ganz viel Licht. Seine Frage war, ob wir das auf der Messe zeigen sollen.



Eine Superidee! Aber wohin damit? Und weil ich gerade nichts zu tun hatte und weil ich den Elan der Erbauer nicht bremsen wollte, habe ich natürlich noch einen schönen Platz gefunden. An einer kleinen senkrechten Traverse wird auch gleich ein kleiner PC montiert. Da wird man dann die Drehscheibe sowie Light@Night in Aktion sehen können. Damit dies nicht zu einer Belagerung führt und den Standbetrieb lahmlegt, hier ein kleiner Hinweis: wir arbeiten selbst nach der Anleitung auf dieser Seite: [ Drehscheibe ]

Der Teufel steckt bekanntlich im Detail. So ist es auch mit der dynamischen Fahrstraßenauflösung. Jetzt sind alle Ankerpunkte und Trigger im System festgelegt und überprüft. Bei der praktischen Erprobung zeigen sich aber Dinge, die in der Theorie nicht vorgesehen waren. Was passiert eigentlich, wenn man einen Zug aus einem Zuganzeiger entfernt oder in einen anderen verschiebt? Heute bleibt die Fahrstraße stehen und muss dann manuell entfernt werden. Das ist sinnvoll, denn voraussichtlich soll der ganze Zug entfernt werden. Nicht so praktisch, wenn der Fahrweg vorzeitig freigegeben würde. Aber die neue dynamische Fahrstraßenauflösung kann damit noch nicht umgehen. Wird ein Zug verschoben, wird folgerichtig der eigenen Logik entsprechend die Fahrstraße entfernt. Na gut - ich hatte eh' gerade nichts zu tun.

Ein weiterer Punkt ist ein Problem das auftritt, wenn ein Kurzschluss an den PC gemeldet wird. Alle Züge (oder beim Railware Power Management nur ein Teil davon) stehen jetzt. Auch jetzt dürfen keine Fahrstraßen aufgelöst werden. Dieser Punkt ist auch in den bisherigen Versionen noch ungelöst, sollte aber künftig besser arbeiten.

Wie schon mal erwähnt, wird der Auflösezeitpunkt eines reservierten Abschnittes errechnet und dann ein Zeitstempel gesetzt. Intern verwendet man dazu in der Regel absolute Zeitangaben. Also: "in 8300 Millisekunden gehts los". Bei einem Kurzschluss sollte aber nicht nur die Zeit anhalten. Nach der erneuten Betriebsbereitschaft ist ja eine Wiederanfahrt einiger Züge nötig. Und damit eine Rekalkulation der Fahrzeiten und Strecken - eine einfache Zeitverlängerung reicht da nicht. Das ist mit den Zeitstempeln nicht zu realisieren. Darum müssen die absoluten Zeitangaben auf ein relatives Zeitsystem umgestellt werden. Jetzt gilt nur das ohnehin im verantwortlichen Hintergrundprozess vorhandene interne Zeitsystem. Der Prozess benötigt pro Lauf eine Zeit von 0,2 bis 2 Sekunden und macht dann je nach Status eine Pause von 1 Sekunde. Also misst man diese variierende Laufzeit des Prozesses und zieht ihn dann Wert von den Zeitstempeln ab. Das klappt seit gestern schon malehr gut. Und wenn man den Prozess testweise einfach anhält, dann bleiben auch alle Fahrstraßen bestehen. Super!

Was aber, wenn ein Kunde die Digitalzentrale nicht einschaltet und trotzdem mit Railware Zugfahrten simulieren will? Das Interface kennt natürlich den Unterschied. Das Gleisbild kennt bisher aber nur gut oder schlecht; also grün oder rot. Es fehlt so etwas wie "kann niemals mit Digitalzentrale kommunizieren, also trotzdem grün". Ok, schon wieder ein neuer Punkt für die Arbeitsliste. Das Leben wäre wirklich einfacher, wenn man nicht so hohe Ansprüche an sich stellen würde. Aber sicherlich auch sehr viel langweiliger. Und wie heißt es so schön: Wer aufhört besser zu werden, hat aufgehört gut zu sein! Da gibt es nichts hinzuzufügen.

Wer in den letzten Tagen in der Gattungsverwaltung war, dem ist vielleicht am unteren Rand eine Neuerung aufgefallen. Dort befinden sich die künftigen Einstellungen zur Anzeige der Zuggattungen. Sie werden demnächst überall eingesetzt.

Für das neue Light@Night Handbuch müssen alle Screenshots ausgewechselt werden. Die haben noch XP Fenster. Das geht natürlich gar nicht. Windows 7 Rechner gibt es momentan nur bei uns zu Hause. Aber eine VM (virtuelle Maschine) mit Windows 7 steht zur Nutzung bereit. Die wird in der Regel für automatisierte Tests mit Railware verwendet. Schnell gestartet und dann ein Bildbearbeitungsprogramm und Light@Night installiert. Nach einer Stunde ist der Job erledigt. Virtuelle Maschinen sind eine wirklich feine Sache. Sie verhalten sich wie ein normaler PC, werden gestartet, benutzt und heruntergefahren. Sie existieren jedoch nur als Fenster im normalen PC, laufen parallel mit dem Wirts- Betriebssystem und werden darum als Gast bezeichnet. Und das beste: nach Benutzung kann sie der Snapshot Manager in den vorherigen Zustand zurückbringen. Die VM befindet sich wieder in ihrem Ursprungszustand: als hätte es die vor kurzem noch installierten Programme nie gegeben. Auch aus anderen Gründen sind VMs für die Softwareentwicklung heute nicht mehr zu entbehren.



Eine sehr wichtige VM befindet sich auf dieser USB-Platte. Sie beherbergt noch das alte Entwicklungsystem bis zur Railware Version 6.22. Damit könnte man im größten Notfall immer noch mal mit dem alten System arbeiten. Es ist momentan auch noch ein wichtiger Reisebegleiter.

Viel Spaß mit der Modellbahn wünscht
das Railware Team

Zu dieser Seite haben beigesteuert: Railware Team5973 Punkte  und admin .
Page last modified on Samstag 13 März, 2010 15:27CET by Railware Team5973 Punkte .
Der Inhalt dieser Seite unterliegt folgenden Lizenzbestimmungen: Copyright.

Suche

in: