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

Wirth · « **am:** 15. März 2004, 18:27:19 »

Hallo,

ich möchte mit meinem Beitrag ein bereits angesprochenes Problem erneut zur Diskussion stellen. Ich hoffe also auf rege Beteiligung, da ich auch bei anderen Modellbahnkollegen derartige Probleme beobachten konnte.

1. Im Fahrplanbetrieb werden Fahrstrassen geschaltet, aber die Lokomotive bekommt keine Sollgeschwindigkeit. Sie bleibt stehen und nur durch einen manuellen Eingriff kann man die Situation bewältigen. Die betreffende FS wird nach manuellem Eingriff nur zum Teil abgearbeitet. Alle FS wurden bereits überprüft. Speziell wenn der Fahrplan einige Zeit läuft oder der Puffer genutzt wird (<5) tritt das Verhalten auf. Zum Teil fährt die Lok an und hält nach ca.30 cm wieder an.

2. Bei der Erstellung von Fahrplänen scheint es Probleme mit der Datenbasis Access zu geben. Teilweise kann man Datensätze nicht kopieren, ersetzen. Danach werden neue Befehlsstrukturen vom System ignoriert.

Sicherlich lassen sich noch weitere Verhaltensweisen beschreiben, aber ich will mich zunächst auf diese beiden Hauptprobleme beschränken. Ich habe diese Probleme unter Win98 sowie unter WinNT auf einen P2 366Mhz der an eine IB angeschlossen ist. Die C-Gleisanlage hat ca. 20 Züge von denen bis zu 6 Lokomotiven gleichzeitig fahren können. Es werden 77 Rückmeldekontakte S88 genutzt. Alle Decoder sind von Littfinski. Es wird kein HSI eingesetzt. Beim Fahren meiner FS (ca. 350 Stück) treten keine Probleme auf.

Ich habe gleiche Probleme auch an anderen Anlagen beobachten können. Bei einem Kollegen waren 3 Züge im Fahrplan. Rechner war ein P3 800Mhz mit WinXP.

Lösungen der Probleme sollten nicht aus "work arounds" bestehen. Ich möchte auch weiterhin alle Funktionen des Programms nutzen, inklusive des Puffers. Über die Anzahl noch austehender Fahrbefehle im Puffer können wir reden.

Gruß
Stefan Wirth

einer vom HAMST

Olivier De Bastiani · « **Antwort #1 am:** 15. März 2004, 19:16:02 »

Hallo Herr Wirth,

aus der Ferne ist das Problem nur schwer greifbar. Allerdings habe ich persönlich ihre PC-Hardware in Verdacht.

Ein sicheres Indiz hierfür ist die funktionierende Einzelabarbeitung der FS.

(Ein P2/366 MHz ist für NT auf jeden Fall zu wenig und bei WIN 98 für größere Anlagen unterste Grenze.)

In Antwort auf:
"... Teilweise kann man Datensätze nicht kopieren, ersetzen. Danach werden neue Befehlsstrukturen vom System ignoriert ..."

Haben Sie nach den Änderungen den Fahrplan neu abgespeichert?
Bisher waren diesbezüglich keine "Klagen" zu hören.

Wenn es bereits bei der Eingabe zu Problemen kam, deutet dies auch wieder auf einen zu "schwachen" Rechner hin. Habne Sie schon mal folgendes probiert: Die Auflösung der Bildschirmanzeige auf 640x480 und die Farbtiefe auf 256 einstellen.

Wie läuft das System jetzt?

Falls keine Besserung, senden Sie mir bitte einmal ihre Projektdaten (bitte ohne Lok-Datenbank) in gezippter Form an meine e-Mail-Adresse.

Wirth · « **Antwort #2 am:** 15. März 2004, 19:19:59 »

Kurze Frage zu Ihrer Antwort:

Ist ein P3 /800Mhz 256 MB Ram unter WinXP ausreichend?

Dank und Gruß
Stefan Wirth

Gian Bott · « **Antwort #3 am:** 15. März 2004, 19:44:32 »

Hallo Herr Wirth,

In Antwort auf:
Ist ein P3 /800Mhz 256 MB Ram unter WinXP ausreichend?

Der Zufall will es dass ich im Geschäft genau einen solchen PC habe, aber unter Windows 98. Wir haben damit grosse Probleme wenn zum Beispiel Word97 zusammen mit einem anderen Programm gestartet wird. Paint-Shop Pro 8.0 wird wohl gestartet aber umfangreichere Bildbearbeitungen sind unmöglich. Ich würde diesen PC nicht für die Modellbahnsteuerung einsetzen! Zum Glück bekommen wir im Mai 2004 neue PC's mit Win XP und Pentium IV, 3Ghz.

Zuhause setzte ich an der MoBa vorerst ein Pentium IV Celeron Laptop ein, mit 512 RAM und Windows XP Prof. Dies funktionierte recht gut, aber etwas langsam. Erst der neue Desktop PC (Shuttle Barbecue mit 2 seriellen Schnittstellen!) mit Pentium IV 3GHz und 1028MB-RAM macht zum arbeiten und für die MOBA erst richtig Spass. Dies ist aber schon eine deLuxe Lösung.

WindowsXP belegt bereits selber ca. 200MB RAM, darum wäre mindestens 512 MB RAM anzustreben. Mehr RAM bringt übrigens mehr als ein schnellerer Prozessor. Als Prozessor würde ich bei den heutigen Preisen nicht unter 2,5GHz gehen.

Leider ist eine PC-gesteuerte Anlage etwas teurer als eine Analoganlage und gerade an der PC-Leistung für die MOBA sollte man nicht sparen. Es darf aber durchaus eine günstige, nicht hochgetaktete Grafikkarte im PC stecken, wenn möglich Passiv gekühlt. Dann wird der PC viel ruhiger und man spart etwas Geld. Für die MOBA reicht auch die heute vielfach auf dem Motherboard eingebaute Grafikkarte vollkommen.

Olivier De Bastiani · « **Antwort #4 am:** 15. März 2004, 19:52:37 »

Hallo Herr Wirth,

das hängt auch von der Anlage, welche gesteuert werden soll, ab (z.B. Anlagengröße, Anzahl der gleichzeitig fahrenden Züge, Anzahl der überwachten RMKs).

Dies kann man aber einfach testen:
- Setzen Sie die Anlage in betrieb mit nur einem Zug.
- Erhöhen Sie die Anzahl der gleichzeitig fahrenden Züge.
-> Sobald es zu ungewollten Geschwindigkeitsänderungen oder nicht mehr erkannten RMKs bzw. nicht mehr bearbeitete Kontaktereignissen kommt, ist die Rechnerleistung zu schwach (vorausgesetzt, vorher mit nur einem Zug lief alles einwandfrei).

Ein P3/800 MHz mit 256 MB RAM ist vom Speicher her OK. Allerdings erscheint mir die Taktfrequenz niedrig. Solange aber die Anlage läuft, ist alles in Ordnung.

Norbert Burkert · « **Antwort #5 am:** 15. März 2004, 22:29:41 »

Hallo Herr Wirth,
was möchten Sie denn gerne lesen?
Ja die Fehler sind bekannt und liegen an Win-Digipet? Damit kann ich leider nicht dienen!

Entweder ist an Ihrer Hardware etwas faul, oder im Laufe der Zeit hat sich, durch was auch immer, die Datenstruktur Ihres Projektes verändert.

Wenn man nur mal das Problem mit der stehenbleibenden Lok analysiert bleibt nicht viel übrig.
Eine Lok bleibt in einem Fahrplan nur stehen wenn durch eine Belegtmeldung eines RMK in ein Stop Befehl oder die FS 0 ausgelöst wird. Diese Befehle müssen natürlich in den Kontaktereigniszeilen stehen. Auch muß hier auf die chronologische Abfolge der Kontaktereignisse geachtet werden. Das heißt, die Zeilen werden streng von oben nach unten abgearbeitet.

Wenn Ihr Fahrplan von mehren Usern überprüft und für richtig befunden wurde, dann tippe ich auf falsche Rückmeldungen. Haben Sie im S88 Monitor schon mal beobachten können ob die RMK die einen Stoppbefehl auslösen kurzeitig besetzt melden?

peter martens · « **Antwort #6 am:** 15. März 2004, 23:46:43 »

Hallo, liebe Eisenbahnfreunde, ich melde mich heute mal zu Wort und möchte den Ausführungen von Stefan Wirth anschließen. Ich habe selbst bei ihm das Ereignis gesehen, daß ein Zug nicht los , die FS jedoch gestellt wurde und die Lok keinen Befehl zum Abfahren bekam. Gestern Abend habe ich einen ähnlichen Fall gehabt. Den FPL hatte ich in den vergangenen Tagen mehrmals ohne Probleme abgefahren. Die vorletzte Zeile wurde nicht ausgeführt. Die FS ist gestellt, der Zug fährt nicht los. Ein Abbruch des FPL, Zeile getestet, ab der Zeile erneut abgefahren, dann gibt es kein Problem. Heute habe ich denselben FPL von Anfang bis Ende ohne Probleme abgefahren. Ich schreibe für jeden Tag ein Protokoll und über die Tätigkeit an der Anlage und Vorkomnisse.
Diese "ungewollten Stop" sind bei mit einige Male passiert, oftmals waren es auch eigene Fehler, sodaß die Züge nicht fahren konnten. Genauer gesagt, seit V8.4 + 8.5
Es wäre an der Zeit, daß hier mal etwas geändert wird, ich meine nicht erst in V9....
Viele Grüße aus Hamburg
Peter Martens

B.Michaelsen · « **Antwort #7 am:** 16. März 2004, 00:56:26 »

Hallo Stefan, hallo Peter ! Hallo, Ihr anderen WinDigipetler!

So einfach ist die Sache leider nicht, dass der PC von Stefan zu klein ist. Ich setze einen Pentium IV ein, der mit 2,4 GHz getaktet wird. Und trotzdem kann ich ebenfalls solche Sachen feststellen, von denen ich immer wieder höre, dass sie "niemand anderes" erlebt.

Also z.B. ein Fahrplan wird geschrieben, jede einzelne Zeile wird natürlich getestet mit der dafür vorgesehenen Taste und funktioniert. Nach Ende der Editorphase läuft der Plan oft erwartungsgemäß durch. Dann wird eine weitere Lok mit wenigen (z.B. 3 Zeilen) zugefügt und Zeile für Zeile getestet. Der Fahrplan wird natürlich gesichert und dann gestartet. Und nun passiert es! Der Fahrplan, der eben noch lief, zeigt die tollsten Sachen. Eine Lok (die vorher prima gelaufen ist) wird zwar gestartet, die Loknummer springt aber auf ein falsches Loksymbol in der Mitte der Fahrstrasse. Die Lok fährt aber unverdrossen über diesen Kontakt hinaus weiter. (!!!!!)

Andere Loks, die in den Puffer geraten (und vor der Änderung richtig wieder gestartet wurden, wenn die Konditionen stimmen, wird aus dem Puffer nicht mehr gestartet und bleibt trotz freier Strecke (alle Kontakte ok!) im Puffer. Wenn sie manuell gestartet wird, (Fahrplan auf rot, manuell starten, dann FP wieder auf grün) läuft sie fehlerfrei ab und der FP läuft auch weiter...

Das zweitschärfste aber ist, dass die zugefügte Lok, mit der alles begann, eine Fahrstrasse geschaltet bekommt, losfährt, und dann am Bremskontakt vor dem Zielbahnhof einfach auf der Strecke stehen bleibt (Das Fahrpult zeigt Geschwindigkeit 0 an), obwohl sie einfach nur herunterbremsen sollte, um langsam in den Bahnhof zu fahren.. (im Test lief natürlich auch diese Zeile ausgezeichnet!)

Also mein laienhafter Eindruck ist folgender: Die Accessdatenbänke spielen mir hier üble Streiche. Auch die Tatsache, dass 15 mal nacheinander WD gestartet werden kann und die Loks in der Richtung stimmen und dann wieder plötzlich (ohne dass die Datenbank von mir angefasst wurde) beim nächsten Start fahren einige Loks rückwärts an, obwohl sie nie in dieser Richtung benutzt wurden.....

Hier ist doch eine Instabilität festzustellen, die die Freude am Hobby schmälert.

Bei dem oben erwähnten Fahrplan wurde dann einfach aufgegeben und die zugefügte Lok wieder gelöscht (Lok isolieren, aus dem Fahrplan löschen) und siehe da, der Fahrplan läuft wieder.... Zwar nicht ganz fehlerfrei, aber fast !!!

Auch ich kann feststellen, dass das Fahren mit den Fahrstrassen (Start->Ziel) völlig problemlos und fehlerfrei abläuft. Also sind doch die zumindest in Ordnung. AK-Betrieb mache ich nicht, weil ich mich nicht traue ein System so einzusetzen, in dem Fahrpläne ständig Überraschungen bereiten.

Ich habe sogar schon darüber nachgedacht, die Festplatte platt zu machen, XP zu installieren und dann WD 8.0 mit Update 8.5 und alles neu einzugeben. Da ich aber alleine weit über 300 Fahrstrassen neu erfassen müsste, scheue ich davor zurück...

So, nun habt ihr schon das dritte Sorgenkind.

Zum Schluss noch mal kurz die Beschreibung meiner Anlage: C-Gleis , 4 Schattenbahnhöfe, 3 Bahnhöfe , ca. 35 Züge einsatzfähig. Im Moment sind 5 S88 - Module über HSI-Interface angeschlossen. Intellibox als Interface mit 4 Boostern Power3 von Uhlenbrock an Titan Trafos 208....

Technisch läufts alles gut, sw-mässig bescheiden...

mit sorgenvollen Grüssen

Bernd (Michaelsen)

Norbert Burkert · « **Antwort #8 am:** 16. März 2004, 06:40:03 »

Moin Bernd,
das liest sich doch schon ganz anders.

Wenn ich dich richtig verstehe sind die von Herrn Wirth beschriebenen Probleme ein Problem.

Und zwar kommen laut eurer Aussage die Fahrpläne durcheinander wenn neue Loks eingebunden werden.

Wie werden die neuen Loks denn genau eingebunden?

1. Möglichkeit
Wird ein kleiner Extrafahrplan für die neue Lok geschrieben und dieser dann eingemischt?
2. Möglichkeit
Werden einfach am Ende des Fahrplans neue FPl-Zeilen geschrieben und diese dann über die Abfahrtszeitsortierung an die richtigen Stellen verschoben.
3.Möglichkeit
Werden die neuen Zeilen direkt an "Ort und Stelle" durch spreizen eingefügt? Also dort wo diese später auch im Fahrplan stehen sollen.

Wenn Ihr drei dazu noch eine Aussage machen könntet werden wir Betatester direkt mal nach der möglichen Ursache suchen, wie der Hund die Blutwurst.

Wirth · « **Antwort #9 am:** 16. März 2004, 08:09:13 »

Guten Morgen,

meinen Fahrplan (über 100 Zeilen) habe ich in einem Stück geschrieben. Es fällt auf, das meistens die selbe Lok an der selben Stelle ohne Sollgeschwindigkeit stehen bleibt. Nur gelegentlich startet diese wie gewünscht. Es streikt dann aber eine andere.

Als zusätzlichen Test habe ich einen sehr kleinen Fahrplan geschrieben (1 Zug auf Bergbahnhof / 2. Zug auf Bergbahnhof / und beide wieder zurück). Kein Befehl landet im Puffer. Alles Läuft wie erwartet gut. Jetzt bewege ich eine 4 Lok manuell und belege die Strecke. Ordnungsgemäß landet jetzt eine Fahrstrasse im Puffer. Nachdem ich die Lok wieder entfernt habe bleibt auch hier eine Lok ohne Sollgeschwindigkeit stehen. Und zwar mit in einer FS, die ich durch die 4. Lok nicht blockiert habe. Dabei ist die FS geschaltet alle RM-Kontakte zeigen richtige Belegung.

Ein Rechnerproblem ist mir ansonsten nicht aufgefallen. Alle Züge fahren (wenn sie fahren) wie gewünscht mit richtige Geschwindigkeit und werden auch ordnungsgemäß abgebremst. Der Rechner läuft nur mit Windigipet. Officeanwendungen und andere NichtMobaProgramme laufen auf der 2. Partition mit Win98.

Gruß
Stefan Wirth

Dietloff · « **Antwort #10 am:** 16. März 2004, 08:35:07 »

Hallo, die Herren Michaelsen, Martens und Wirth,

in Ergänzung zu den Beiträgen von Norbert und Olli noch ein paar Anmerkungen bzgl. Fahrplanablauf.

1. Fahrpläne berühren/verändern KEINE Datenbank von WDP.
2. Fahrpläne werden auch nicht in einer Datenbank erstellt.

Die von Ihnen beschriebenen Erscheinungen lassen sehr stark vermuten, dass entweder eine (oder mehrere) Fahrstrassen nicht ordnungsgemäss konfiguriert sind oder eine (oder mehrere) Kontaktereignisse innerhalb des Fahrplans.
Alternativ: Es werden nicht ALLE Kontaktereignisse des FPLs zu 100% abgearbeitet.
Dies können Sie einfach beobachten, indem Sie in der geöffneten FPL-Auotmatik den Button für die Kontaktereignisse öffnen (Brillensymbol). Sollte im Laufe eines FPLs dort noch ein (oder mehrere) Kontaktereignisse NICHT abgearbeitet werden, dann erfolgt die von Ihnen beschriebene "Kettenreaktion"; denn wenn eine Lok ein eingetragenes Kontaktereignis NICHT abgearbeitet hat, erhält sie z.B. keine neuen Befehle.

In Ergänzung können Sie auch den FPL-Inspektor mitlaufen lassen; denn auch dieser wird Ihnen mitteilen, warum eine Lok z.B. keine weiteren FSsen erhält.

Die o.g. "Erscheinungen" müssen nicht unbedingt im Einzeltest auffallen; denn wenn Sie z.B. in einer FPL-Zeile einen falschen RMK eingetragen haben (von einer anderen FS) werden Sie dies erst merken, wenn z.B. ein anderer Zug über eine andere FS diesen RMK überfährt und schon wird ein falscher Befehl ausgegeben.
Weitere "Risiken und Nebenwirkungen" erhalten Sie, wenn z.B. FSsen nicht ordnungsgemäss abgearbeitet werden, dann kann es auch zu einem späteren Zeitpunkt zu solchen Effekten kommen. Aber auch diese sind (beim FPL) über das Fenster der abzuarbeitenden Kontaktereignisse und mit Hilfe des Inspektor eigentlich IMMER zu erkennen.

Vorausgesetzt, Sie haben keinen Fehler (z.B. Verdrahtung) an der Anlage, dann empfehle ich folgende Vorgehensweise.

1. WDP neu starten (dies stellt sicher, dass keine offenen Befehle mehr im Speicher sind).

2. Überprüfen, ob alle Loknummern des FPLs auf der richtigen Position stehen. Ggf. (bei fehlerhaften FSsen) die Loknummern des FPL manuell auf das Loknummernfeld ziehen.

3. FPL öffnen.

4. Inspektor öffnen

5. Brillensymbol für Kontaktereignisse öffnen.

6. FPL starten und die Kontaktereignisse und den FPL-Inspektor genau beobachten.

Mit dieser Vorgehensweise stellen Sie sicher, dass keine Beeinflussung durch inkorrekte FS-Abarbeitung gegeben ist.
Wenn dann eine Lok falsch reagiert, können Sie sofort überprüfen, ob die betreffende FS oder FPL-Zeile korrekt/inkorrekt konfiguriert ist.

Noch eine Alternative: Um alle Eventualitäten der Zentraleinheit/Anlage auszuschalten können Sie auf gleiche Weise den FPL auch im Test-Modus "abfahren".
Sollte es ein Konfigurationsfehler sein, wird er sich auch dort zu erkennen geben. Tritt im Test-Modus NIE ein Fehler auf, dann haben Sie ein Problem an der Anlage (vermutlich RMK).

Alternativ können Sie mir auch gerne Ihre Daten mailen (ohne Lok-DB), inkl. einer Beschreibung wann der Fehler wo auftritt.

Grüsse

Rüdiger Dietloff

Wirth · « **Antwort #12 am:** 16. März 2004, 13:22:14 »

Nun ich habe meine RMK's mit Hilfe von Windigipet überprüft. Da sollte der Fehler nicht liegen. Zumal in anderen Situationen des Fahrplans die Probleme in dem Anlagenbereich nicht auftreten.

Ich werde aber meinen Fahrplan nach Ihrer Vorgehensweise überprüfen.

Könnten Sie mir vielleicht noch etwas zum Pufferbetrieb sagen? Speziell wenn ich diesen genutzt habe, treten Probleme auf. Wie sieht es mit der Speicherverwaltung (RAM und IB) von Windigipet aus?

Gruß
Stefan Wirth

Dietloff · « **Antwort #13 am:** 16. März 2004, 13:51:44 »

Hallo Herr Wirth,

wenn Sie die RMK-Überprüfung über WDP so meinen, dass Sie z.B. über einen Zug alle RMKs abgefahren haben und diese dann korrekt im WDP-Gleisbild oder im RMK-Monitor angezeigt wurden, dann scheint ihre Anlage an dieser Stelle ordnungsgemäss angeschlossen zu sein.

Wenn in anderen Situationen in diesem Anlagenbereich KEINE Fehler auftreten hat dies nur bedingt etwas zu sagen; denn die Frage ist, ob DIESELBEN FSsen benutzt wurden. Denn dort könnte bereits ein Fehler liegen, bzw. ein Kontaktereignis in einer FPL-Zeile ist inkorrekt.
Eine Software (WDP) kann an dieser Stelle auch nicht "temporär" einen Fehler zeigen, sondern entweder ist ein Fehler vorhanden oder eben nicht.

Der Pufferbetrieb ist eigentlich nichts anderes, als ein "Auffangbecken" für FPL-Zeilen, die nicht fristgerecht abgearbeitet werden konnten und erst bei der nächsten Möglichkeit (FS kann gestellt werden) abgearbeitet werden, bzw. manuell ausgelöst oder gelöscht werden können.

Ob FPL-Zeilen im Puffer liegen hat eigentlich (aus der Ferne betrachtet) nichts mit den von Ihnen beschriebenen Erscheinungen zu tun; es sei denn, dass die FPL-Zeilen in den Puffer geraten sind, weil die Fahrstrassen aus anderen Gründen (siehe meinen vorherigen Eintrag) nicht gestellt werden konnten. Diese Ursache lässt sich aber über den FPL-Inspektor, respektive den abzuarbeitenden Kontaktereignissen (Brillensymbol) relativ schnell herausfinden.

Eingangs erwähnen Sie, dass Sie einen 366MHz-Rechner (ich persönlich kenne nur 266MHz-Rechner, mit einer "66" am Ende) für 20 Loks einsetzen. Dieser Rechner ist erfahrungsgemäss ein wenig zu schwach. Beobachten Sie doch im Fahrbetrieb einfach mal den Windows-eigenen TASK-Manager. Wenn die CPU-Last permanent über 80-90% liegt sind Verzögerungen oder Unregelmässigkeiten vorprogrammiert. Bei der grossen Anzahl von Loks und gleichzeitig fahrenden Loks, sollten Sie auf jeden Fall einen aktuelleren PC in Betracht ziehen. In Ihrem Falle würde ich Ihnen >1.500MHz vorschlagen und zumindest 256MB-RAM.

Über die Speicherverwaltung von WDP und der IB kann ich Ihnen nichts sagen. Eigentlich übernimmt Windows die Speicherverwaltung und je nach System-Einstellung (und installierter Software im Hintergrund) kann dort einiges "verbogen" werden. Wenn Sie im FPL z.B. auch viel mit Sounds arbeiten kommen weitere Aspekte (und Anforderungen) an den Rechner und das Betriebssystem hinzu, d.h. auch hier kann ein System wieder ausgebremst werden - vor allen Dingen, wenn z.B. der Sound-Treiber nicht ordnungsgemäss arbeitet.

Am ehesten empfehle ich die Vorgehensweise des Ausschlussverfahrens, d.h. wie im vorherigen Eintrag erwähnt, würde ich den FPL über den Test-Modus abarbeiten und die beiden Kontrollfenster genauestens beobachten. Auch spielt hier die Rechnerleistung nur eine untergeordnete Rolle. So können Sie zumindest den Fehler eingrenzen und in 99,x% aller Fälle auch das Problem isolieren und beseitigen.

Grüsse

Rüdiger Dietloff

B.Michaelsen

Re: Probleme mit Windigipet 8.5

B.Michaelsen

Re: Probleme mit Windigipet 8.5