Autor Thema: Probleme mit Windigipet 8.5 (Gelesen 10840 mal)

Gian Bott · « **Antwort #30 am:** 17. März 2004, 11:20:20 »

Hallo Bernd,

In Antwort auf:
(der Schreiber teilt dann auch noch mit, er "fahre sozusagen mit dem Mercedes zum Zigarettenautomaten ").

Solltest Du mit obiger Aussage mich meinen, ich habe kein Auto und bin Nichtraucher

, habe aber gute Schuhsohlen und ein Abo des ÖV's.
Ich habe an der MOBA einen kräftigen PC, aber ich brauche ihn auch nicht nur für die MOBA, gleichzeitig macht es aber Freude, diesen auch für die MOBA einsetzen zu können. Ich denke dass heute bei den immer noch sinkenden PC-Preisen für die MOBA ein PIV mit genügend RAM drinliegen sollte (ALDI hat ja manchmal sehr interessante und gute Angebote von MEDION). Wenn ich an die Kosten der MOBA denke, ist der PC nicht der grösste Posten, wenn ich alles zusammenzähle, dann ............... Im übrigen konnte ich mir die MOBA erst leisten, seit ich kein Auto mehr habe (seit 27 Jahren). Auch in der vermeintlich reichen Schweiz wächst das Geld nicht in den Bäumen (leider)

, darum baue ich meine PC's selber zusammen, mit gelegentlichen Ergänzungen.

Ich glaube, das PC-Thema sollte nun abgeschlossen werden, da ja jeder (mindestens zwischen den Zeilen) nun wissen sollte, was an Leistung nötig ist bzw. wünschbar wäre.

Thorsten Haller · « **Antwort #31 am:** 17. März 2004, 11:38:23 »

Hallo,

da ich auch vom Fach bin (Wirtschafsinformatik, bis zum Ende durchgehalten

) muß ich auch mal meinen Senf dazu geben.
Über Echtzeitbetriebssysteme und die dazugehörige Hardware zu diskutieren, ist ja wohl eher theoretischer Natur.
Vielmehr sollten wir uns die gegebenen Rahmenbedingungen anschauen:
Um eine breite Masse mit WDP ansprechen zu können, ist Windows als Betriebssystem notwendig. Der hohe Verbreitungsgrad spricht für sich. Ob das dem einzelnen gefällt oder nicht, sei dahin gestellt.
Der nächste limitierende Faktor ist das Digitalsystem der Moba. Über verschiedene Alternativen wurde im Forum an anderer Stelle diskutiert. Man kann wohl festhalten, daß es möglich ist ein System zu konfigurieren, daß Steuer- und Stell-Befehle hinreichend schnell abarbeiten kann bzw. die Rückmeldung quasi ohne Verzögerung an den PC liefert.
Das vor allem die RMKs in Länge und Anordnung den Vorschlägen entsprechen, sezte ich voraus.
Ich unterstelle Hernn Dr. Peterlin mal, daß er WDP nicht absichtlich "langsam" programmiert hat

. Sowie anerkannte Algorithmen und Techniken der Softwareentwicklung anwendet.
Also kommen wir zum letzten Punkt: Die Hardwareausstattung des PCs. Dies ist die einzige verbleibende Stellschraube, wenn man die vorgenannten Punkte als Konstanten ansieht.
Die Datenlieferung von und zur seriellen Schnittstelle stellt für alle heute verfügbaren Rechner kein Problem dar. Also ist dafür zu sorgen, daß der Programmablauf nicht ins Stocken gerät. D.h. im Falle WDP: Möglichst keine anderen Programme (Virenscanner, Firewall etc.) laufen lassen. Jeder Prozesswechsel kostet Rechenzeit. Speicherauslagerung auf die Festplatte verhindert. Daraus folgt ein die Forderung nach einem entsprechende dimensionierten Hauptspeicher. Und schließlich die CPU. In WDP laufen während des Betriebs umfangreiche Prüfungen ab, z.B. ob eine Fahrstraße gestellt werden kann oder nicht.
Das Betriebssystem benötigt heute minimal ca. 128 (Win 98 / NT) bis 256 MB (Win 2000/XP) Hauptspeicher, um alleine schonmal in einer brauchbaren Geschwindigkeit arbeiten zu können. Als Prozessor empfehle ich mindestens einen PIII mit 500 MHz oder ein äquivalentes AMD-Produkt.
So und nun zu WDP: Bei mir belegt die Bürversion 8.5 ca. 18 MB Hauptspeicher (ohne Fahrstraßen, Fahrpläne etc.). Bei einer richtigen Anlage ergo entsprechend mehr.
Also kann ich die Aussage "Die Hardware packt das, also muß der Fehler im Programm liegen" nicht nachvollziehen. Das Programm hat bestimmte Aufgaben zu erfüllen. Dazu ist eine endliche Anzahl Rechenschritte (=CPU-Zyklen) notwendig. Je mehr Aufgaben (=Züge auf der Anlage, RMKs usw.) zu behandeln sind, desto mehr (auch konkurrierende) Rechenschritte sind durchzuführen. Also entsteht ein Flaschenhals, den ich nur weiten kann, indem ich die Ausführungszeit der Rechenoperationen möglichst kurz halte. Und dies ist nur mit einer schnellen CPU möglich. Und ein großer Hauptspeicher hilft, die Datenbereitstellung für die CPU nicht unnötig zu verzögern.

Zur Problematik der Fehleridentifikation: Ich war selber in einem Softwareentwicklungsprojekt für die Testkonzeption und -durchführung zuständig. Eine genauer Fehlersuche ist nur möglich, wenn Tests reproduzierbar sind. Denn wie schon gesagt wurde, entweder ist ein Bug in der SW oder eben nicht. Das setzt aber voraus, daß auf einem genau definierten Systemzustand (Hardware, Software und Daten) getestet wird. Dann kann man über die Veränderung einzelner Parameter und das daraus resultierende Testergebnis Rückschlüsse auf mögliche Fehlerquellen schließen.
Für Fahrplantests heißt dies z.B. auch für mich Züge, die nicht am FPL beteiligt sind, haben eine genau definierte Position auf der Anlage und ein paralleler AK-Betrieb ist tabu. Alles andere ist stochern im Nebel und keinesfalls zielgerichtet.
Und wie schreibt Hr. Schneider von WinTrack so schön in seiner Signatur. "Geht nicht ist keine Fehlermeldung."

Wirth · « **Antwort #32 am:** 17. März 2004, 12:49:58 »

Hallo,

ich bin von dieser Diskussion sehr angetan. Habe mit großem Interesse gelesen und möchte nun weitere Test durchführen, damit ich Rückmeldung liefern und so zu Antworten beitragen kann.
Hierfür habe ich einen neuen Fahrplan geschrieben. Ich vermeiden zunächst Pufferbetrieb. Noch heute werde ich hoffentlich erste Ergebnisse weitergeben können. Da ich aber im Service arbeite weiß ich nie, ob es nicht doch einen Tag länger dauern kann. Ich bleibe aber am Ball. Wie bereits erwähnt habe ich gestern einen neuen Fahrplan erstellt und habe auch schon ein kleines Problem beobachten können.

Wenn ich dieses Forum so betrachte, ist es allein schon Grund genug dieses Produkt zu kaufen. Meinen Dank an alle Beteiligten. Im Gegensatz zu anderen Foren dürfen sich hier Themen auch wiederholen ohne das der Verfasser Angriffen oder Maßregelungen ausgesetzt ist.

Gruß
Stefan Wirth einer vom HAMST

Wirth · « **Antwort #33 am:** 17. März 2004, 20:46:42 »

Hallo, da bin ich wieder.

Habe also einen neuen Fahrplan geschrieben. Dieser hat 58 Zeilen, bedient 10 Loks, Zeitfaktor 10, Dauer ca.23 Minuten und es fahren maximal 4 Lokomotiven gleichzeitig. Maximal 1 FS ist kurzzeitig im Puffer.
Rechner ist P2 366Mhz Laptop (das dürfte die Taktfrequenz erklären). Windigipet in der Version 8.5.134.

Der Prozessor ist im Durchschnitt zu 45% ausgelastet. Während des Fahrplans gibt es zwei Nadel bis 75% und eine Nadel mit 85% Auslastung. Auf die Auslagerungsdatei wird nicht zugegriffen. Weitere Anwendung laufen nicht im Hintergrund. Vor dem Start des Fahrplans habe ich jedes Mal alle eventuell vorhandenen FS mit F7 gelöscht.

Fahrplan läuft gut, aber mit einem Fehler. Br 38 fährt bei 55 Minuten nicht die gewünschte FS. Onlinetracing (beide Brillen) sind aktiviert. FS ist OK wird geschaltet, Befehl wird abgearbeitet aber die BR 38 hat Sollgeschwindigkeit 0 (Lokcontrol war geöffnet). Loksymbol wird auf neue Position übertragen. Lok wird also von Hand gestartet. Am Ende der FS wird zwar der Stopbefehl aus dem Tracing genommen aber Lok fährt trotzdem weiter. Also schnell von Hand angehalten. Fahrplan läuft danach ordnungsgemäß zu Ende. Auch die BR38 fährt weiter. Zwischenzeitlich fahren noch weitere Loks diese Strecke ohne Probleme.

Nach Fahrplanende habe ich dann RMK's, Schaltzeiten und etc. überprüft. Scheint alles in Ordnung. Habe dann den Fahrbefehl der betreffenden Zeile um 1 Sekunde verzögert. Folge: keine Veränderung. Lok bleibt immernoch stehen.

Danach die Startzeit der Zeile von 55 Minuten auf 56 Minuten geändert. Folge: Fahrplan läuft ohne Probleme! Super!

Jetzt wieder die Startzeit auf 55 Minuten zurück gesetzt und Fahrplan erneut gestartet. Folge: BR 38 bleibt wieder stehen!! Sche...!!

Beim Fehlverhalten ist der Prozessor zu ca. 50% ausgelastet. Tracing zeigt keine Fehler an. Die FS hat zwei RMK's. Einen zum Starten, einen zum Anhalten. FS führt vom unteren Schattenbahnhof auf die Hälfte meiner Gleiswendel (Zwischenstop). Es wird nur eine Geschwindigkeit 70% mit Rampe 3 vorgegeben. Am ende erfolgt ein Stopbefehl.

Ich hoffe, meine Beschreibung ist verständlich.

Gruß
Stefan Wirth

Olivier De Bastiani · « **Antwort #34 am:** 17. März 2004, 22:39:55 »

Hallo Herr Wirth,

na das ist doch schon mal was - wenn jetzt noch ihre Projektdaten greifbar wären, wäre die ganze Sache einfacher.

Jetzt meine Fragen:
1. Was ist anders innerhalb der einen Minute (also zwischen Abfahrtszeit 55 Minuten und Abfahrtzeit 56 Minuten)?

2. Was meinen Sie mit "... Loksymbol wird auf neue Position übertragen ..."? (Bitte die Lokadresse während der Fahrstrassenabarbeitung nicht neu setzen)

3. Haben Sie schon mal einen Loktausch in FPL durchgeführt?
(Nur um es zur gleichen Zeit mit einer anderen Lok zu probieren)

Norbert Burkert · « **Antwort #37 am:** 18. März 2004, 09:39:58 »

Hallo zusammen,
der unter Punkt 2 beschriebene Sprung der Loknummer ist ja korrekt, da dies in der Systemeinstellung bestimmt eingestellt ist.

Mit welcher Geschwindigkeit sollte die BR 38 am ersten Kontaktereignis losfahren?

Wirth · « **Antwort #38 am:** 18. März 2004, 10:26:58 »

Die BR 38 soll mit 70% Geschwindigkeit losfahren. Es ist eine Rampe von 3 eingestellt. Da ich parallel das Fenster des Lokcontrols geöffnet habe, kann ich sehen, daß der Lok keine Geschwindigkeit vorgegeben wird, obwohl die Brille sagt FS Ok und wird gestellt. Der Inspektior löscht den abgearbeitet Startbefehl. Nur der Stopbefehl wird noch angezeigt.

Zwecks Projektdaten: welche Dateien soll ich zur Verfügung stellen?

Gruß
Stefan Wirth

Dietloff · « **Antwort #39 am:** 18. März 2004, 10:43:18 »

Hallo Herr Wirth,

mailen Sie mir folgende Dateien aus Ihrem WDigipet-Verzeichnis (z.B. c:\Wdigipet):

- GBild.dat
- WDRoutes.mdb
- xxx.FPL (der besagte Fahrplan)

Zusätzlich klicken Sie bitte in der Menüleiste auf den Projektnamen und speichern Ihre Projektkonfiguration ab. Dieses RTF-File (beinhaltet Ihre WDP-System-Einstellungen) und eine kurze Beschreibung WANN, WO (FPL-Zeile oder FPL-Uhrzeit, welche FS, etc.) bei der die von Ihnen geschilderte Problematik auftritt, mailen Sie mir bitte ebenfalls zu.

Grüsse

Rüdiger Dietloff

Wirth · « **Antwort #40 am:** 18. März 2004, 19:51:22 »

Hallo,

so, die Daten sind übermittelt.

Ich habe heute die Lok gegen eine andere getauscht. Leider habe ich dennoch das gleiche Problem.

Gruß
Stefan Wirth

Rudi Klein · « **Antwort #41 am:** 19. März 2004, 07:49:27 »

Hallo Stefan,

ich spreche mal für die - nur - Leser des Forums.
Oft wird eine Rückmeldung über das Ergebnis der Hilfestellung vergessen.
Deshalb meine bitte, informiere uns über das Ergebnis der Analyse deiner Projektdaten von Rüdiger.

Besten Dank
Gruss
Rudi

Wirth · « **Antwort #42 am:** 19. März 2004, 08:32:13 »

Guten Morgen,

selbstverständlich informiere ich das Forum über gemachte Erfahrungen und Rückmeldungen seitens der Betatester bzw. Rüdigers. Obwohl ich glaube, daß alle Programmierer und Betatester sowieso sehr engagiert sind, um uns Endverbrauchern zu helfen und zu informieren.

Ich begrüsse es aber ebenfalls, wenn die -nur- Leser ähnliche oder gleiche Probleme bestätigen könnten. Wenn ausser Bernd, Peter und mir (alle aus Hamburg) keiner diese Probleme hat, kann ja eigentlich auch kein "öffentliches Interesse" bestehen. Sollte außer uns jemand vergleichbare Probleme haben und von diesen hier berichten, könnte das einer Problemlösung sehr dienlich sein.

Gruß
Stefan Wirth

Wirth · « **Antwort #43 am:** 19. März 2004, 19:47:42 »

Hallo liebe "Leidensgenossen" :-)

Es ist soweit. Endlich kann ich die gewünschte Rückmeldung einer Problemlösung geben.

Problem ist eine Fahrplanzeile, in der ich ein Zeitglied eingesetzt habe. D.h. nach Belegen eines RMK's soll der eigentliche Befehl erst nach x Sekunden ausgeführt werden. Folgendes Beispiel soll den Sachverhalt erläutern:

A1------------B-------------C
A2-|

FS1 soll von A1 über B nach C fahren. Dabei soll beim Überfahren von B nach 14 Sekunden die Geschwindigkeit reduzieren. Die FS1 hat eine definierte Teilstrecke 1 von A1 bis B.

FS2 soll von A2 nach B fahren. Dieses geschieht nach Freigabe von Teilstrecke 1 bei FS1. Wenn FS2 sich in Bewegung setzen soll, ist die programmierte Zeit aus FS1 zur Geschwindigkeitsreduzierung noch nicht abgelaufen. D.h. der Befehl liegt noch im Speicher. Wenn die Zeit abgelaufen ist, wird die Geschwindigkeit wie gewünscht reduziert. Gleichzeitig erhält FS2 den Stopbefehl, da ja ein Schaltereignis von RMK an B vorausgesetzt ist. Lok FS2 bleibt also stehen ohne den Endkontakt erreicht zu haben. Zeitlich lagen diese Ereignisse so nah beieinander, daß für mich der Eindruck entstand, die Lok BR38 fährt nicht los. Tatsächlich bekam sie den Fahrbefehl und sofort danach einen Stopbefehl. Das erklärt auch, daß die Lok, nachdem ich sie von Hand gestartet habe, am Endkontakt nicht gestopt wurde. Je nach Zeitverhalten, hätte BR38 auch ihre Fahrt beginnen können und wäre dann auf freier Strecke stehengeblieben.

Fazit: Das Problem kann man vermeiden, indem man:
- ein virtuelles Signal an B programiert (eleganteste Lösung).
- kurze oder keine Zeitglieder programmieren
- Zeitglieder bei aufeinander folgenden Fahrstrassen, die auch die gleiche Strecke nutzen vermeiden

Interessant ist dieses Verhalten des Systems auch beim Verwenden des Puffers. Die Pufferbetrieb macht in bestimmten Situationen durchaus Sinn. Werden aber zu lange Zeitglieder in anderen Fahrstrasse eingesetzt, kann das absolute Chaos auf der Anlage entstehen. Einen solchen Fahrplan zu entwirren wünsche ich keinem von uns.

Bei der Planung der Anlage ist auch auf zukünftiges Fahrverhalten der Lokomotiven zu achten. Z.B. Geschwindigkeitsänderungen kann man ohne Zeitglieder programmieren, indem man genügend RMK's an den richtigen Stellen hat. Ist die Anlage bereits fertig und nachträgliche Änderungen nur unter extremsten Aufwand möglich, so muß man eine hohe Disziplin beim Programmieren an den Tag legen und genau abwegen, wo man Zeitschleifen startet.

Zum Schluß meinen herzlichen Dank an Rüdiger Dietloff. Nicht nur das er fast die gesamten Telefonkosten übernommen hat, er hat auch mit viel Engagement den Fehler für mich gefunden und mir dann erklärt. Ich hoffe, meine Ausführungen besagen, daß ich Ihn auch richtig verstanden habe. Nebenbei hat er dann auch noch meine Systemeinstellungen optimiert.

So jetzt habe ich aber keine Zeit mehr! Ich muß in Keller zurück.

Hamsterliche Grüße
Stefan Wirth

Dietloff · « **Antwort #44 am:** 20. März 2004, 17:29:23 »

...zur ausführlichen Beschreibung von Herrn Wirth.
Das "Problem" wäre auch nicht aufgetreten, wäre der RMK, der für den ERSTEN Zug mit 14 Sek. Verzögerung noch einen Befehl schicken sollte, nicht gleichzeitig der Zielkontakt des ZWEITEN Zuges.
Da beide Fahrstrassen nicht gegenseitig durch einen MA "verriegelt" waren, konnte sich der ZWEITE Zug ja die FS stellen (vor ihm war alles frei).
Dann kam es zu beschriebenen Reaktion. Die 14 Sek. waren um, der RMK übermittelte den gewünschten zeitverzögerten Befehl zum ERSTEN Zug und gleichzeitig "kollidierte" er natürlich somit mit dem Zielkontakt des ZWEITEN Zuges.

Mit einem "virtuellen" (oder echten) Signal (wäre ja eigentlich auch vorbildgerecht) zwischen beiden Zügen, wäre die zweite FS nicht gestellt worden und somit in den Puffer gelaufen.

Dies war einer der ganz seltenen Problembeschreibungen, die man aus der Ferne (im Test-Modus) nur mutmassen kann, aber so richtig reproduzieren lässt sich diese Erscheinung nur mit Anlagenverbindung, da man im Test-Modus die zeitlichen Komponenten nicht 1:1 berücksichtigen kann.

Mir hat´s ebenfalls Spass gemacht, gemeinsam mit Herrn Wirth das Problem zu isolieren und dann zu beseitigen.

Grüsse

Rüdiger Dietloff

Wirth

Re: Probleme mit Windigipet 8.5

Dietloff

Re: Probleme mit Windigipet 8.5