Titel: Probleme mit Windigipet 8.5
Beitrag von: Wirth in 15. März 2004, 18:27:19
Beitrag von: Wirth in 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
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
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Olivier De Bastiani in 15. März 2004, 19:16:02
Beitrag von: Olivier De Bastiani in 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.
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.
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Wirth in 15. März 2004, 19:19:59
Beitrag von: Wirth in 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
Ist ein P3 /800Mhz 256 MB Ram unter WinXP ausreichend?
Dank und Gruß
Stefan Wirth
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Gian Bott in 15. März 2004, 19:44:32
Beitrag von: Gian Bott in 15. März 2004, 19:44:32
Hallo Herr Wirth,
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.
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.
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Olivier De Bastiani in 15. März 2004, 19:52:37
Beitrag von: Olivier De Bastiani in 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.
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.
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Norbert Burkert in 15. März 2004, 22:29:41
Beitrag von: Norbert Burkert in 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?
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?
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: peter martens in 15. März 2004, 23:46:43
Beitrag von: peter martens in 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
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
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: B.Michaelsen in 16. März 2004, 00:56:26
Beitrag von: B.Michaelsen in 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)
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)
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Norbert Burkert in 16. März 2004, 06:40:03
Beitrag von: Norbert Burkert in 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.
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.
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Wirth in 16. März 2004, 08:09:13
Beitrag von: Wirth in 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
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
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Dietloff in 16. März 2004, 08:35:07
Beitrag von: Dietloff in 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
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
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: B.Michaelsen in 16. März 2004, 10:24:07
Beitrag von: B.Michaelsen in 16. März 2004, 10:24:07
Hallo Norbert !
Erst einmal möchte ich sagen, dass ich die Möglichkeiten von WinDigipet hervorragend finde. Sonst hätte ich das Programm nicht mehr im Einsatz. Darum ärgern mich diese unerklärlichen Fehler auch so !!
Genau diese Möglichkeit wurde bei mir genutzt. Zeilen einfügen. Zeilen editieren, Fahrplan speichern, Blaues Wunder erleben.... Was ist da mit der fpl-Datei passiert ?
Ach war das schön, wenn früher mit Dbase-Dateien (oder Derivaten davon) gearbeitet wurde. Da konnte man sofort feststellen, was passiert ist. Aber es passierte garnichts, was das Programm nicht veranlasste !!! Sowas gibt´s erst bei Microsoft.....
Aber auch die plötzliche Umkehr der Fahrtrichtung ärgert mich masslos ! Gestern abend ist gerade wieder rollendes Material von der Platte gefegt worden und dabei nicht unerheblich beschädigt worden. Sowas ist wirklich nicht tolerabel !
Herzlichen Gruss
Bernd
PS.: Oder liegt es daran, dass ich an meiner Anlage ändere und erweitere und dann natürlich Gleisplan und Fahrstrassen auch ändere ? das aber muss doch nun wirklich durch das Pgm. geleistet werden können.
Erst einmal möchte ich sagen, dass ich die Möglichkeiten von WinDigipet hervorragend finde. Sonst hätte ich das Programm nicht mehr im Einsatz. Darum ärgern mich diese unerklärlichen Fehler auch so !!
In Antwort auf:
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.
Genau diese Möglichkeit wurde bei mir genutzt. Zeilen einfügen. Zeilen editieren, Fahrplan speichern, Blaues Wunder erleben.... Was ist da mit der fpl-Datei passiert ?
Ach war das schön, wenn früher mit Dbase-Dateien (oder Derivaten davon) gearbeitet wurde. Da konnte man sofort feststellen, was passiert ist. Aber es passierte garnichts, was das Programm nicht veranlasste !!! Sowas gibt´s erst bei Microsoft.....
Aber auch die plötzliche Umkehr der Fahrtrichtung ärgert mich masslos ! Gestern abend ist gerade wieder rollendes Material von der Platte gefegt worden und dabei nicht unerheblich beschädigt worden. Sowas ist wirklich nicht tolerabel !
Herzlichen Gruss
Bernd
PS.: Oder liegt es daran, dass ich an meiner Anlage ändere und erweitere und dann natürlich Gleisplan und Fahrstrassen auch ändere ? das aber muss doch nun wirklich durch das Pgm. geleistet werden können.
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Wirth in 16. März 2004, 13:22:14
Beitrag von: Wirth in 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
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
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Dietloff in 16. März 2004, 13:51:44
Beitrag von: Dietloff in 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
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
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: B.Michaelsen in 16. März 2004, 14:44:55
Beitrag von: B.Michaelsen in 16. März 2004, 14:44:55
Hallo, Herr Dietloff !
Schönen Dank, dass Sie sich mit unseren Problemen befassen. Ich bin gerade dabei, die erwähnten Fahrpläne in der von Ihnen vorgeschlagenen Weise mit den geöffneten Inspektorenfenstern ablaufen zu lassen. Bisher läuft mal wieder alles !
Zu dieser Feststellung hätte ich nun doch mal eine Frage...
Der Fahrplan wird in einer .fpl-Datei gespeichert. Zusätzlich dazu gibt´s eine .dat-Datei gleichen Namens. Was ist denn das anderes als eine Datenbank, die mit Sätzen (Zeilen) und Feldern (einzelne Aufträge)organisiert ist (wenn´s auch nicht unbedingt eine Access-Datenbank ist....)? Und ist es nicht so, dass wenn eine Lok zuletzt in einer Richtung gefahren ist, sie beim nächsten WinDigipet-Start wieder in die gleiche Richtung gesetzt wird? Wenn ja, muss die Fahrtrichtung doch am Schluss des Spielens mit der Modellbahn gespeichert worden sein. Ich könnte mir gut vorstellen, dass dies in der Lok-Datenbank geschieht, damit beim Starten, wenn die Loks initialisiert werden (mit den Daten aus dieser Datenbank ???!!) alles gleich wieder korrekt läuft.
Liege ich mit dieser Vorstellung völlig falsch ?
Mit den besten Grüssen
Bernd (Michaelsen)
Schönen Dank, dass Sie sich mit unseren Problemen befassen. Ich bin gerade dabei, die erwähnten Fahrpläne in der von Ihnen vorgeschlagenen Weise mit den geöffneten Inspektorenfenstern ablaufen zu lassen. Bisher läuft mal wieder alles !
In Antwort auf:
1. Fahrpläne berühren/verändern KEINE Datenbank von WDP.
2. Fahrpläne werden auch nicht in einer Datenbank erstellt.
Zu dieser Feststellung hätte ich nun doch mal eine Frage...
Der Fahrplan wird in einer .fpl-Datei gespeichert. Zusätzlich dazu gibt´s eine .dat-Datei gleichen Namens. Was ist denn das anderes als eine Datenbank, die mit Sätzen (Zeilen) und Feldern (einzelne Aufträge)organisiert ist (wenn´s auch nicht unbedingt eine Access-Datenbank ist....)? Und ist es nicht so, dass wenn eine Lok zuletzt in einer Richtung gefahren ist, sie beim nächsten WinDigipet-Start wieder in die gleiche Richtung gesetzt wird? Wenn ja, muss die Fahrtrichtung doch am Schluss des Spielens mit der Modellbahn gespeichert worden sein. Ich könnte mir gut vorstellen, dass dies in der Lok-Datenbank geschieht, damit beim Starten, wenn die Loks initialisiert werden (mit den Daten aus dieser Datenbank ???!!) alles gleich wieder korrekt läuft.
Liege ich mit dieser Vorstellung völlig falsch ?
Mit den besten Grüssen
Bernd (Michaelsen)
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Dietloff in 16. März 2004, 15:18:23
Beitrag von: Dietloff in 16. März 2004, 15:18:23
Hallo Herr Michaelsen,
ein Fahrplan (Endung FPL) wird heute als Textdatei gespeichert, d.h. er hat keine (typischen) Felder, Spalten, Indizes, etc., wie eine "echte" Datenbank (Access). Die zweite Datei, mit der Endung <Fahrplanname>.DAT beinhaltet lediglich die zuletzt verwendete FPL-Zeile, wenn dieser z.B. mittendrin angehalten wurde. So ist sichergestellt, dass Sie einen FPL nicht immer von Anfang an laufen lassen müssen. In Ihrem ersten Eintrag äußerten Sie den Verdacht, dass der FPL Ihre WDP-Access-Dateien "angreift". Dem ist nicht so.
Bzgl.:
Ja, grundsätzlich ist dem so. Allerdings ist hier z.B. eine typische Ausnahme, Loks mit älteren Decodern, die einfach vergessen, dass sie zuletzt auf "Rückwärts" standen und beim nächsten Einschalten plötzlich auf "Vorwärts" stehen und somit WDP keine "Chance" geben, die korrekte Fahrtrichtung zu initialisieren.
Bezogen auf einen FPL sollten Sie sicherstellen, dass wenn ein Zug als erster FPL-Eintrag mit Fahrtrichtung "Vorwärts" startet, den FPL auch mit gleicher Fahrtrichtung beendet; denn sonst gibt´s Probleme, wenn Sie den FPL 1:1 wieder neu starten.
Bzgl.
Und das ist, was ich in meinem ersten Eintrag meinte: Wenn ein Software-Bug vorliegt, dann kann er nicht temporär da sein, sondern er ist da oder eben nicht.
Andererseits gibt´s aber viele Möglichkeiten, dass durch z.B. unsachgemässe Konfiguration der Fahrstrassen, nicht abgearbeitete Kontaktereignisse, etc. noch einiges im WDP-"Hinterkopf" bleibt, weil WDP diese Ereignisse noch erwartet und schon kommt´s z.B. beim nächsten Überfahren der "übrig gebliebenen" RMKs zu Fehlinterpretationen.
Diese sind aber zu >99% durch das Brillensymbol, bzw. den jeweiligen Inspektor identifizierbar.
Wenn also im Test-Modus der Ablauf zu 100% funktioniert, dann würde ich erneut WDP beenden und neu starten und das Ganze auf gleiche Weise mit Anlagenbetrieb testen.
Bin mal auf Ihr Ergebnis gespannt.
Grüsse
Rüdiger Dietloff
ein Fahrplan (Endung FPL) wird heute als Textdatei gespeichert, d.h. er hat keine (typischen) Felder, Spalten, Indizes, etc., wie eine "echte" Datenbank (Access). Die zweite Datei, mit der Endung <Fahrplanname>.DAT beinhaltet lediglich die zuletzt verwendete FPL-Zeile, wenn dieser z.B. mittendrin angehalten wurde. So ist sichergestellt, dass Sie einen FPL nicht immer von Anfang an laufen lassen müssen. In Ihrem ersten Eintrag äußerten Sie den Verdacht, dass der FPL Ihre WDP-Access-Dateien "angreift". Dem ist nicht so.
Bzgl.:
In Antwort auf:
wenn eine Lok zuletzt in einer Richtung gefahren ist, sie beim nächsten WinDigipet-Start wieder in die gleiche Richtung gesetzt wird?
Ja, grundsätzlich ist dem so. Allerdings ist hier z.B. eine typische Ausnahme, Loks mit älteren Decodern, die einfach vergessen, dass sie zuletzt auf "Rückwärts" standen und beim nächsten Einschalten plötzlich auf "Vorwärts" stehen und somit WDP keine "Chance" geben, die korrekte Fahrtrichtung zu initialisieren.
Bezogen auf einen FPL sollten Sie sicherstellen, dass wenn ein Zug als erster FPL-Eintrag mit Fahrtrichtung "Vorwärts" startet, den FPL auch mit gleicher Fahrtrichtung beendet; denn sonst gibt´s Probleme, wenn Sie den FPL 1:1 wieder neu starten.
Bzgl.
In Antwort auf:
Bisher läuft mal wieder alles !
Und das ist, was ich in meinem ersten Eintrag meinte: Wenn ein Software-Bug vorliegt, dann kann er nicht temporär da sein, sondern er ist da oder eben nicht.
Andererseits gibt´s aber viele Möglichkeiten, dass durch z.B. unsachgemässe Konfiguration der Fahrstrassen, nicht abgearbeitete Kontaktereignisse, etc. noch einiges im WDP-"Hinterkopf" bleibt, weil WDP diese Ereignisse noch erwartet und schon kommt´s z.B. beim nächsten Überfahren der "übrig gebliebenen" RMKs zu Fehlinterpretationen.
Diese sind aber zu >99% durch das Brillensymbol, bzw. den jeweiligen Inspektor identifizierbar.
Wenn also im Test-Modus der Ablauf zu 100% funktioniert, dann würde ich erneut WDP beenden und neu starten und das Ganze auf gleiche Weise mit Anlagenbetrieb testen.
Bin mal auf Ihr Ergebnis gespannt.
Grüsse
Rüdiger Dietloff
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Nils Fuhrmann in 16. März 2004, 15:44:24
Beitrag von: Nils Fuhrmann in 16. März 2004, 15:44:24
Hallo,
prinzipiell bin ich von der hier geführten Art der Diskussionen begeistert. Im Regelfall findet man so sehr schnell Lösungen für seine Probleme.
Allerdings gibt es immer mal wieder den einen oder anderen Hinweis, der so nich richtig ist.
So ist es bei einem funktionierenden System mit WDP in der Tat überhaupt kein Problem z.B. mit einme PII 266MHz 128MB und WinNT eine Anlage mit ca. 10 gleichzeitig fahrenden Zügen zu Steuern. Das einzige was passiert ist, das einige Befehle verzögert gesendet werden. Bei entprechender Gestaltung der Anlage (Länge der Rückmeldestrecken etc.) ist das aber gar kein Problem. Da s88 Rückmelder auch erst den Belegtstatus verliehren, nachdem sie abgefragt wurden, ist auch hier das Timing bei vernünftiger Anlagengestalltung unkritisch.
Wenn die hier beschriebenen Probleme etwas mit der Rechenleistung zu tun haben, dann ist das in der Tat auf Bugs in der Software zurückzuführen (Synchronisation, Event-Handling, Semaphoren, Mutexe, was auch immer).
Das dem nicht so ist, wir jeder Software-Entwickler gern bestätigen. Grade bei complexen Systemen (Windows, WDP, Moba) treten oft Bugs nicht reproduzierbar auf.
Was soll dieser Beitrag von mir?
Die Kompetenz der Foren-Mitglieder ist bei Win-Digipet wirklich extrem hoch. Das empfinde ich als sehr positiv und bin hier gerne unterwegs. Ein wenig stört da aber ab und zu die schützende Hand vor WDP (keine Bugs, die Performance der Maschine ist schuld, ...). Grade in der Softwaretechnik sollte man sehr intensiv potentielle Bugs analysieren. Da sollte man sie natürlich auch als solche erkennen.
Gruß,
Nils
prinzipiell bin ich von der hier geführten Art der Diskussionen begeistert. Im Regelfall findet man so sehr schnell Lösungen für seine Probleme.
Allerdings gibt es immer mal wieder den einen oder anderen Hinweis, der so nich richtig ist.
So ist es bei einem funktionierenden System mit WDP in der Tat überhaupt kein Problem z.B. mit einme PII 266MHz 128MB und WinNT eine Anlage mit ca. 10 gleichzeitig fahrenden Zügen zu Steuern. Das einzige was passiert ist, das einige Befehle verzögert gesendet werden. Bei entprechender Gestaltung der Anlage (Länge der Rückmeldestrecken etc.) ist das aber gar kein Problem. Da s88 Rückmelder auch erst den Belegtstatus verliehren, nachdem sie abgefragt wurden, ist auch hier das Timing bei vernünftiger Anlagengestalltung unkritisch.
Wenn die hier beschriebenen Probleme etwas mit der Rechenleistung zu tun haben, dann ist das in der Tat auf Bugs in der Software zurückzuführen (Synchronisation, Event-Handling, Semaphoren, Mutexe, was auch immer).
In Antwort auf:
Und das ist, was ich in meinem ersten Eintrag meinte: Wenn ein Software-Bug vorliegt, dann kann er nicht temporär da sein, sondern er ist da oder eben nicht.
Das dem nicht so ist, wir jeder Software-Entwickler gern bestätigen. Grade bei complexen Systemen (Windows, WDP, Moba) treten oft Bugs nicht reproduzierbar auf.
Was soll dieser Beitrag von mir?
Die Kompetenz der Foren-Mitglieder ist bei Win-Digipet wirklich extrem hoch. Das empfinde ich als sehr positiv und bin hier gerne unterwegs. Ein wenig stört da aber ab und zu die schützende Hand vor WDP (keine Bugs, die Performance der Maschine ist schuld, ...). Grade in der Softwaretechnik sollte man sehr intensiv potentielle Bugs analysieren. Da sollte man sie natürlich auch als solche erkennen.
Gruß,
Nils
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Dietloff in 16. März 2004, 16:11:25
Beitrag von: Dietloff in 16. März 2004, 16:11:25
Hallo Nils,
Gebe ich Dir vollkommen recht, aber bei vielen Anlagen führt das verzögerte Senden von Befehlen z.B. zum Crash, da der Haltepunkt weit überfahren wurde.
Grundsätzlich würde ich somit einen Rechner empfehlen, der auch den Anforderungen gerecht wird.
Die am häufigsten gemeldeten Fehlermeldungen in Bezug auf den PC resultierten aus falschen/fehlerhaften Treibern, zusätzliche Software, die im Hintergrund aktiv war oder fehlerhaften COM-ports, nebst "seltsamen" Seriell<> USB-Konvertern.
Bzgl. "temporäre" Softwarefehler:
Bezogen auf die FPL-Probleme muss die Ursache reproduzierbar sein; denn sonst gäbe es diese Art von Fehlermeldung mehrmals täglich. Um dieses zumindest einzukreisen, habe ich in meinem ersten Eintrag eine Prozedur geschildert, wie man zumindest über das Ausschlussverfahren die Thematik einkreisen kann.
Aber noch einmal: Die hier diskutierten Probleme sehe ich nicht in der Rechnerleistung, sondern in der Konfiguration.
Daher auch der Hinweis mit dem Test-Modus, um die Sache einzukreisen und die Zentraleinheit, Anlage - nebst Elektronik und die Rechnerleistung von vorneherein auszuschliessen.
Grüsse
Rüdiger
In Antwort auf:
So ist es bei einem funktionierenden System mit WDP in der Tat überhaupt kein Problem z.B. mit einme PII 266MHz 128MB und WinNT eine Anlage mit ca. 10 gleichzeitig fahrenden Zügen zu Steuern. Das einzige was passiert ist, das einige Befehle verzögert gesendet werden.
Gebe ich Dir vollkommen recht, aber bei vielen Anlagen führt das verzögerte Senden von Befehlen z.B. zum Crash, da der Haltepunkt weit überfahren wurde.
Grundsätzlich würde ich somit einen Rechner empfehlen, der auch den Anforderungen gerecht wird.
In Antwort auf:Gebe ich Dir nur bedingt recht; denn zum einen vermute ich den Fehler in fehlerhaften FS-oder FPL-Konfigurationen oder in nicht abgefahrenen Kontaktereignissen, so dass noch Reste in WDP verbleiben, auf deren "Erfüllung" WDP auch weiterhin wartet.
Wenn die hier beschriebenen Probleme etwas mit der Rechenleistung zu tun haben, dann ist das in der Tat auf Bugs in der Software zurückzuführen (Synchronisation, Event-Handling, Semaphoren, Mutexe, was auch immer).
Die am häufigsten gemeldeten Fehlermeldungen in Bezug auf den PC resultierten aus falschen/fehlerhaften Treibern, zusätzliche Software, die im Hintergrund aktiv war oder fehlerhaften COM-ports, nebst "seltsamen" Seriell<> USB-Konvertern.
Bzgl. "temporäre" Softwarefehler:
In Antwort auf:...wird Dir kein SW-Hersteller bestätigen, weil es reproduzierbar sein muss, wenn die gleichen Umstände eintreffen und das ist zumeist das Problem.
Das dem nicht so ist, wir jeder Software-Entwickler gern bestätigen. Grade bei complexen Systemen (Windows, WDP, Moba) treten oft Bugs nicht reproduzierbar auf.
Bezogen auf die FPL-Probleme muss die Ursache reproduzierbar sein; denn sonst gäbe es diese Art von Fehlermeldung mehrmals täglich. Um dieses zumindest einzukreisen, habe ich in meinem ersten Eintrag eine Prozedur geschildert, wie man zumindest über das Ausschlussverfahren die Thematik einkreisen kann.
In Antwort auf:Und deswegen geht WDP sehr offen mit Bugs um. Trotz intensivster Tests der Beta-Tester kann immer mal etwas durchrutschen oder tritt erst bei individuellen Konstellationen auf - was dann vom Anwender gemeldet wird. Daher gibt´s ja z.B. auch seit heute ein Bugfix, in dem die bisher gemeldeten Fehler von V8.5 beseitigt sind. Objektiv betrachtet, ist WDP bei den Fehlermeldungen am absolut seltensten die Ursache - selbst, wenn eine neue Version frisch freigegeben wird. Aber ich kenne auch keine Software, die 100% fehlerfrei ist...
Ein wenig stört da aber ab und zu die schützende Hand vor WDP (keine Bugs, die Performance der Maschine ist schuld, ...). Grade in der Softwaretechnik sollte man sehr intensiv potentielle Bugs analysieren. Da sollte man sie natürlich auch als solche erkennen.
Aber noch einmal: Die hier diskutierten Probleme sehe ich nicht in der Rechnerleistung, sondern in der Konfiguration.
Daher auch der Hinweis mit dem Test-Modus, um die Sache einzukreisen und die Zentraleinheit, Anlage - nebst Elektronik und die Rechnerleistung von vorneherein auszuschliessen.
Grüsse
Rüdiger
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Nils Fuhrmann in 16. März 2004, 16:50:18
Beitrag von: Nils Fuhrmann in 16. März 2004, 16:50:18
Hallo Rüdiger,
Das Problem bei dieser Art von Bugs ist ja grade, das die Rehmenbedingungen selber oft nicht definierbar bzw. reproduzierbar sind. Wer kann schon interne Zustände von Windows, der Peripherie etc. tracken und reproduzieren?
Eine WDP Umgebungen ist der klassische Kandidat für diese Form von Issues...
Das WDP sehr offen und aktiv mit Bugs umgeht, weiss ich. Und das es schon wieder 'n update gibt, ist super!!!
Gruß,
Nils
In Antwort auf:
Bzgl. "temporäre" Softwarefehler:In Antwort auf:...wird Dir kein SW-Hersteller bestätigen, weil es reproduzierbar sein muss, wenn die gleichen Umstände eintreffen und das ist zumeist das Problem.
Das dem nicht so ist, wir jeder Software-Entwickler gern bestätigen. Grade bei complexen Systemen (Windows, WDP, Moba) treten oft Bugs nicht reproduzierbar auf.
Das Problem bei dieser Art von Bugs ist ja grade, das die Rehmenbedingungen selber oft nicht definierbar bzw. reproduzierbar sind. Wer kann schon interne Zustände von Windows, der Peripherie etc. tracken und reproduzieren?
Eine WDP Umgebungen ist der klassische Kandidat für diese Form von Issues...
Das WDP sehr offen und aktiv mit Bugs umgeht, weiss ich. Und das es schon wieder 'n update gibt, ist super!!!
Gruß,
Nils
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Urs Länzlinger in 16. März 2004, 16:50:30
Beitrag von: Urs Länzlinger in 16. März 2004, 16:50:30
Hallo zusammen, ist vielleicht eine freche Frage, aber sind alle Fahrstrassen am Anfang und am Ende mit einem Magnetartikel versehen? Hatte das gleiche Problem im AK Betrieb, nachher aber keinerlei Probleme mehr.
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Dietloff in 16. März 2004, 17:07:08
Beitrag von: Dietloff in 16. März 2004, 17:07:08
Hallo Nils,
bzgl.
Genau aus diesem Grund habe ich ja empfohlen, nach der Prozedur vorzugehen; denn nur so kann man zumindest einen definierten Zustand hervorrufen, ohne sich durch die Peripherie oder etwaige Anlagenfehler in die Irre führen zu lassen.
Zur Zeit steht (stehen) ja erst einmal ein (oder mehrere) Probleme im Raum. Ergo versuche ich lediglich, definiert eine Eingrenzung anzustreben; denn sonst verrennt man sich und sieht vor lauter Bäumen den Wald nicht und...das Problem wird nicht gelöst.
Wenn auf die von mir beschriebene Vorgehensweise getestet ist, weiss man zumindest, ob die FSsen oder der FPL bereits einen Fehler haben (durch den Inspektor und/oder das Brillensymbol) und der Rest sind dann die (von mir vermuteten) Folgeerscheinungen, die erst später auftreten.
Wichtig ist daher VOR dem Test, WDP neu zu starten, damit nicht bereits eine Unregelmässigkeit noch im Speicher von WDP ist.
Um hier nicht über Theorien zu "stolpern" muss man eben so definiert und reproduzierbar wie möglich das Ganze testen und dann kriegt man eigentlich IMMER die Ursache - ausser wenn wirklich mal die Hardware temporäre Fehler aufzeigt - aber die treten dann nicht nur in Verbindung mit WDP oder gar dem FPL auf!
Wichtig ist natürlich auch, dass keine weitere Software oder seltsame Treiber im Hintergrund laufen - man erinnere sich an den "berühmten" Logitech-Treiber für drahtlose Mäuse...
Alternativ habe ich ja auch angeboten mir die Daten zu mailen; denn oft entdecken "Fremde" mögliche Fehler eher als man selbst.
Ich bin mir sicher, dass wir den Fehler auf diese Art finden; denn ein grundsätzlicher FPL-Fehler würde sicherlich mehrfach täglich gemeldet werden...dafür sind die WDP-User viel zu gut, als das so etwas übersehen würde...
Grüsse
Rüdiger
bzgl.
In Antwort auf:
Das Problem bei dieser Art von Bugs ist ja grade, das die Rehmenbedingungen selber oft nicht definierbar bzw. reproduzierbar sind. Wer kann schon interne Zustände von Windows, der Peripherie etc. tracken und reproduzieren?
Genau aus diesem Grund habe ich ja empfohlen, nach der Prozedur vorzugehen; denn nur so kann man zumindest einen definierten Zustand hervorrufen, ohne sich durch die Peripherie oder etwaige Anlagenfehler in die Irre führen zu lassen.
Zur Zeit steht (stehen) ja erst einmal ein (oder mehrere) Probleme im Raum. Ergo versuche ich lediglich, definiert eine Eingrenzung anzustreben; denn sonst verrennt man sich und sieht vor lauter Bäumen den Wald nicht und...das Problem wird nicht gelöst.
Wenn auf die von mir beschriebene Vorgehensweise getestet ist, weiss man zumindest, ob die FSsen oder der FPL bereits einen Fehler haben (durch den Inspektor und/oder das Brillensymbol) und der Rest sind dann die (von mir vermuteten) Folgeerscheinungen, die erst später auftreten.
Wichtig ist daher VOR dem Test, WDP neu zu starten, damit nicht bereits eine Unregelmässigkeit noch im Speicher von WDP ist.
Um hier nicht über Theorien zu "stolpern" muss man eben so definiert und reproduzierbar wie möglich das Ganze testen und dann kriegt man eigentlich IMMER die Ursache - ausser wenn wirklich mal die Hardware temporäre Fehler aufzeigt - aber die treten dann nicht nur in Verbindung mit WDP oder gar dem FPL auf!
Wichtig ist natürlich auch, dass keine weitere Software oder seltsame Treiber im Hintergrund laufen - man erinnere sich an den "berühmten" Logitech-Treiber für drahtlose Mäuse...
Alternativ habe ich ja auch angeboten mir die Daten zu mailen; denn oft entdecken "Fremde" mögliche Fehler eher als man selbst.
Ich bin mir sicher, dass wir den Fehler auf diese Art finden; denn ein grundsätzlicher FPL-Fehler würde sicherlich mehrfach täglich gemeldet werden...dafür sind die WDP-User viel zu gut, als das so etwas übersehen würde...
Grüsse
Rüdiger
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: B.Michaelsen in 16. März 2004, 17:10:19
Beitrag von: B.Michaelsen in 16. März 2004, 17:10:19
Hallo Urs !
Das ist keine freche Frage. Aber es muss ja nicht unbedingt ein Magnetartikel sein. Es könnte doch auch ein virtuelles Signal sein.... (oder ein Schaltdecoder, der den Fahrstrom abschaltet)
In diesem Sinne fahre ich von Signal zu Signal.... (
sicher aber von S88-Kontakt zu S88-Kontakt )
nur nicht im AK-Betrieb, sondern ausschliesslich im FP-Betrieb oder im Start-Ziel-Betrieb....
Herzlichen Gruss
Bernd (Michaelsen)
In Antwort auf:
freche Frage, aber sind alle Fahrstrassen am Anfang und am Ende mit einem Magnetartikel versehen?
Das ist keine freche Frage. Aber es muss ja nicht unbedingt ein Magnetartikel sein. Es könnte doch auch ein virtuelles Signal sein.... (oder ein Schaltdecoder, der den Fahrstrom abschaltet)
In diesem Sinne fahre ich von Signal zu Signal.... (
sicher aber von S88-Kontakt zu S88-Kontakt )nur nicht im AK-Betrieb, sondern ausschliesslich im FP-Betrieb oder im Start-Ziel-Betrieb....
Herzlichen Gruss
Bernd (Michaelsen)
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Urs Länzlinger in 16. März 2004, 17:18:54
Beitrag von: Urs Länzlinger in 16. März 2004, 17:18:54
Hallo Bernd,
ich habe mir gedacht, für alte Hasen sei das sicher selbstverständlich, darum das " frech". Bei mir löste sich das Problem über die virtuellen Signale. Weiter viel Glück bei der Suche nach der Lösung des Problems.
ich habe mir gedacht, für alte Hasen sei das sicher selbstverständlich, darum das " frech". Bei mir löste sich das Problem über die virtuellen Signale. Weiter viel Glück bei der Suche nach der Lösung des Problems.
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Olivier De Bastiani in 17. März 2004, 08:54:58
Beitrag von: Olivier De Bastiani in 17. März 2004, 08:54:58
Hallo Nils,
Den Satz hast du mit der folgenden Beschreibung
selbst revidiert.
Wenn Befehle in einer Echtzeitsteuerung verspätet gesendet werden, dann ist das System unterdimensioniert!
Ich hatte zwar nur 2 Semester "Softwareentwicklung" belegt, aber dort war der 1. Grundsatz, dass die Hardware stimmen muss. Andernfalls können Fehler auftreten, die einfach nicht nachvollziehbar sind, da man nicht erkennen kann wann und wo ein Bit verloren geht.
Natürlich wird erst einmal WDP "geschützt"
Ich für meinen Teil mache das nicht etwa weil ich ehrenamtlicher Betatester bin, sondern weil ich von der Software als Anwender absolut überzeugt bin!
Das eine Software nie zu 100% korrekt ist braucht man nicht zu diskutieren; ja ne, is' klar!
Aber bevor man mit Kanonen auf Spatzen schiesst, muss man erstmal heruasbekommen, ob ein Bug vorliegt. Wenn ein Fehler vorliegt, bin ich einer der Ersten, die soetwas zugeben (was mir einmal hier im Forum auch schon zum Verhängnis wurde, da ich die falsche Logik des Anwenders übersehen hatte!)
Um zu erkennen, ob es sich um einen Fehler vor dem Bildschirm oder im Computer handelt, muss man der Sache auf den Grund gehen.
Also, dann "man Futter bei den Fischen" und her mit euren Ergebnissen (oder Projektdaten).
In Antwort auf:
Allerdings gibt es immer mal wieder den einen oder anderen Hinweis, der so nich richtig ist
Den Satz hast du mit der folgenden Beschreibung
In Antwort auf:
So ist es bei einem funktionierenden System mit WDP in der Tat überhaupt kein Problem z.B. mit einme PII 266MHz 128MB und WinNT eine Anlage mit ca. 10 gleichzeitig fahrenden Zügen zu Steuern. Das einzige was passiert ist, das einige Befehle verzögert gesendet werden.
selbst revidiert.
Wenn Befehle in einer Echtzeitsteuerung verspätet gesendet werden, dann ist das System unterdimensioniert!
In Antwort auf:
Wenn die hier beschriebenen Probleme etwas mit der Rechenleistung zu tun haben, dann ist das in der Tat auf Bugs in der Software zurückzuführen (Synchronisation, Event-Handling, Semaphoren, Mutexe, was auch immer).
Ich hatte zwar nur 2 Semester "Softwareentwicklung" belegt, aber dort war der 1. Grundsatz, dass die Hardware stimmen muss. Andernfalls können Fehler auftreten, die einfach nicht nachvollziehbar sind, da man nicht erkennen kann wann und wo ein Bit verloren geht.
In Antwort auf:
Ein wenig stört da aber ab und zu die schützende Hand vor WDP (keine Bugs, die Performance der Maschine ist schuld, ...).
Natürlich wird erst einmal WDP "geschützt"
Ich für meinen Teil mache das nicht etwa weil ich ehrenamtlicher Betatester bin, sondern weil ich von der Software als Anwender absolut überzeugt bin!
Das eine Software nie zu 100% korrekt ist braucht man nicht zu diskutieren; ja ne, is' klar!
Aber bevor man mit Kanonen auf Spatzen schiesst, muss man erstmal heruasbekommen, ob ein Bug vorliegt. Wenn ein Fehler vorliegt, bin ich einer der Ersten, die soetwas zugeben (was mir einmal hier im Forum auch schon zum Verhängnis wurde, da ich die falsche Logik des Anwenders übersehen hatte!)
Um zu erkennen, ob es sich um einen Fehler vor dem Bildschirm oder im Computer handelt, muss man der Sache auf den Grund gehen.
Also, dann "man Futter bei den Fischen" und her mit euren Ergebnissen (oder Projektdaten).
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Nils Fuhrmann in 17. März 2004, 10:00:54
Beitrag von: Nils Fuhrmann in 17. März 2004, 10:00:54
Hallo Olivier,
eigentlich wollte ich eine solche Diskussion gar nicht aufkommen lassen, sorry. Dennoch: eine Windows Software ist nie echtzeitfähig weil Windows ein nicht echtzeitfähiges Betriebssystem ist (echtzeit=garantierte Antwortzeiten). Da kann die Maschine noch so flott sein.
Ich habe bis zum Ende durchgehalten
(technische Informatik). Siehe oben: Kein echtzeitfähiges System, daher Probleme auf schwachbrüstigen Maschinen immer auch im Worst case Probleme auf schnellen Maschinen, weil auch hier die Antwortzeiten nicht garantiert sind.
Ich bin doch bei euch
WDP ist für mich erste Wahl und wirds auch bleiben.
Gruß Nils (der sich bereits Ärgert, seine erste Mail geschrieben zu haben...)
In Antwort auf:
Den Satz hast du mit der folgenden BeschreibungIn Antwort auf:
So ist es bei einem funktionierenden System mit WDP in der Tat überhaupt kein Problem z.B. mit einme PII 266MHz 128MB und WinNT eine Anlage mit ca. 10 gleichzeitig fahrenden Zügen zu Steuern. Das einzige was passiert ist, das einige Befehle verzögert gesendet werden.
selbst revidiert.
Wenn Befehle in einer Echtzeitsteuerung verspätet gesendet werden, dann ist das System unterdimensioniert!
eigentlich wollte ich eine solche Diskussion gar nicht aufkommen lassen, sorry. Dennoch: eine Windows Software ist nie echtzeitfähig weil Windows ein nicht echtzeitfähiges Betriebssystem ist (echtzeit=garantierte Antwortzeiten). Da kann die Maschine noch so flott sein.
In Antwort auf:In Antwort auf:
Wenn die hier beschriebenen Probleme etwas mit der Rechenleistung zu tun haben, dann ist das in der Tat auf Bugs in der Software zurückzuführen (Synchronisation, Event-Handling, Semaphoren, Mutexe, was auch immer).
Ich hatte zwar nur 2 Semester "Softwareentwicklung" belegt, aber dort war der 1. Grundsatz, dass die Hardware stimmen muss. Andernfalls können Fehler auftreten, die einfach nicht nachvollziehbar sind, da man nicht erkennen kann wann und wo ein Bit verloren geht.
Ich habe bis zum Ende durchgehalten
(technische Informatik). Siehe oben: Kein echtzeitfähiges System, daher Probleme auf schwachbrüstigen Maschinen immer auch im Worst case Probleme auf schnellen Maschinen, weil auch hier die Antwortzeiten nicht garantiert sind.In Antwort auf:
Natürlich wird erst einmal WDP "geschützt"
Ich für meinen Teil mache das nicht etwa weil ich ehrenamtlicher Betatester bin, sondern weil ich von der Software als Anwender absolut überzeugt bin!
Ich bin doch bei euch
WDP ist für mich erste Wahl und wirds auch bleiben.
Gruß Nils (der sich bereits Ärgert, seine erste Mail geschrieben zu haben...)
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Gian Bott in 17. März 2004, 10:27:35
Beitrag von: Gian Bott in 17. März 2004, 10:27:35
Hallo Nils,
Mit einem PII/266 mit 128MB RAM möchte ich nicht mit Win NT und WDP arbeiten. Da wird das System ja schon nur durch das Betriebssystem stark ausgelastet!
Mein Geschäfts-PC, Dell mit Pentium III/450Mhz und 128 MB RAM, beginnt relativ schnell mit der Auslagerung auf die Festplatte, weil 128MB bereits unter Win98 zu knapp sind. Bei Lotus-Notes geht er dann vollends in die Knie, wenn paralell noch ein anderes Programm gestartet wird. Für einen reinen ModellbahnPC (nur Win98 und WDP, ohne Zusatzprogramme) könnte ich mir diesen PC mit 256-512MB RAM vorstellen, für kleinere Anlagen. Will man aber den PC auch noch für die Anlagenplanung, Excel, Word usw. nutzen, reicht dieses System leider nicht bzw. es macht einfach keine Freude.
Deshalb bin ich der Meinung,dass wenn man die MOBA per PC steuern will,auch ein entsprechend ausgestatteter PC nötig ist und der kostet schnell einmal den Gegenwert von 4-5 guten Loks. Dann macht es auch richtig Freude und viele Probleme entfallen dann (es gibt noch genug andere). Mein MOBA-PC dient auch noch als "Notnagel" falls mein Arbeits-PC in der Wohnung einmal ausfallen sollte, darum sind auf diesem alle meine üblichen Programme ebenfalls installiert (inkl. Grafikprogramme usw.). Deshalb die üppige Ausstattung mit P4/3Ghz, 1024MBRAM, DVD-Brenner usw, und wenn sich auf der Anlage nichts tut könnte ich auch mit dem MS-Simulator und dem Heidi-Express der RhB das Prättigau befahren 
.
Im weiteren hat Olivier de Bastiani alles gesagt was wichtig ist.
In Antwort auf:
So ist es bei einem funktionierenden System mit WDP in der Tat überhaupt kein Problem z.B. mit einme PII 266MHz 128MB und WinNT eine Anlage mit ca. 10 gleichzeitig fahrenden Zügen zu Steuern.
Mit einem PII/266 mit 128MB RAM möchte ich nicht mit Win NT und WDP arbeiten. Da wird das System ja schon nur durch das Betriebssystem stark ausgelastet!
Mein Geschäfts-PC, Dell mit Pentium III/450Mhz und 128 MB RAM, beginnt relativ schnell mit der Auslagerung auf die Festplatte, weil 128MB bereits unter Win98 zu knapp sind. Bei Lotus-Notes geht er dann vollends in die Knie, wenn paralell noch ein anderes Programm gestartet wird. Für einen reinen ModellbahnPC (nur Win98 und WDP, ohne Zusatzprogramme) könnte ich mir diesen PC mit 256-512MB RAM vorstellen, für kleinere Anlagen. Will man aber den PC auch noch für die Anlagenplanung, Excel, Word usw. nutzen, reicht dieses System leider nicht bzw. es macht einfach keine Freude.
Deshalb bin ich der Meinung,dass wenn man die MOBA per PC steuern will,auch ein entsprechend ausgestatteter PC nötig ist und der kostet schnell einmal den Gegenwert von 4-5 guten Loks
. Dann macht es auch richtig Freude und viele Probleme entfallen dann (es gibt noch genug andere). Mein MOBA-PC dient auch noch als "Notnagel" falls mein Arbeits-PC in der Wohnung einmal ausfallen sollte, darum sind auf diesem alle meine üblichen Programme ebenfalls installiert (inkl. Grafikprogramme usw.). Deshalb die üppige Ausstattung mit P4/3Ghz, 1024MBRAM, DVD-Brenner usw, und wenn sich auf der Anlage nichts tut könnte ich auch mit dem MS-Simulator und dem Heidi-Express der RhB das Prättigau befahren .Im weiteren hat Olivier de Bastiani alles gesagt was wichtig ist.
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: B.Michaelsen in 17. März 2004, 10:32:18
Beitrag von: B.Michaelsen in 17. März 2004, 10:32:18
Hallo Nils !
Das kann doch nicht wahr sein ! Ich halte diese Diskussion hier für eine der hochwertigsten, die ich in einem Modellbahnforum bisher miterleben durfte.
Gerade die Auseinandersetzung, die Du hier angestossen hast, ist für mich ebenfalls sehr wichtig ! Wenn ich hier an andere Beiträge in diesem Themenbereich denke....
Wenn da einem Mitglied der WinDigipet-Gemeinde gesagt wird, Deine Hardware ist zu schwachbrüstig (der Schreiber teilt dann auch noch mit, er "fahre sozusagen mit dem Mercedes zum Zigarettenautomaten ").
Es gibt durchaus Leute, die ihr knappes Modellbahnbudget sehr genau einteilen müssen. Da die "digitale Welt der Modellbahn" einen unglaublichen (wenn nicht sogar unverschämten) Preissprung nach oben gemacht hat, ist es durchaus erlaubt, an den Stellen zu sparen, an denen es möglich ist.
Daher meine Bitte: Diskutiert solche Dinge weiter frei von "ich habe mehr Recht als Du" und von "diese Software hat keine Fehler". Diskussion ist Auseinandersetzung mit Argumenten.....
Weiter so.
Und hier noch was an alle Verantwortlichen für WinDigipet: Solange nirgens nachzulesen ist, was eine gute (ausreichende) Rechnerausstattung ist, werden immer wieder zu kleine Rechner eingesetzt werden. Bitte macht mal Vorschläge !
In diesem Sinne !
Herzlichen Gruss
Bernd, einer der sich hier und beim HAMST sehr wohl fühlt....
In Antwort auf:
(der sich bereits Ärgert, seine erste Mail geschrieben zu haben...)
Das kann doch nicht wahr sein ! Ich halte diese Diskussion hier für eine der hochwertigsten, die ich in einem Modellbahnforum bisher miterleben durfte.
Gerade die Auseinandersetzung, die Du hier angestossen hast, ist für mich ebenfalls sehr wichtig ! Wenn ich hier an andere Beiträge in diesem Themenbereich denke....
Wenn da einem Mitglied der WinDigipet-Gemeinde gesagt wird, Deine Hardware ist zu schwachbrüstig (der Schreiber teilt dann auch noch mit, er "fahre sozusagen mit dem Mercedes zum Zigarettenautomaten ").
Es gibt durchaus Leute, die ihr knappes Modellbahnbudget sehr genau einteilen müssen. Da die "digitale Welt der Modellbahn" einen unglaublichen (wenn nicht sogar unverschämten) Preissprung nach oben gemacht hat, ist es durchaus erlaubt, an den Stellen zu sparen, an denen es möglich ist.
Daher meine Bitte: Diskutiert solche Dinge weiter frei von "ich habe mehr Recht als Du" und von "diese Software hat keine Fehler". Diskussion ist Auseinandersetzung mit Argumenten.....
Weiter so.
Und hier noch was an alle Verantwortlichen für WinDigipet: Solange nirgens nachzulesen ist, was eine gute (ausreichende) Rechnerausstattung ist, werden immer wieder zu kleine Rechner eingesetzt werden. Bitte macht mal Vorschläge !
In diesem Sinne !
Herzlichen Gruss
Bernd, einer der sich hier und beim HAMST sehr wohl fühlt....
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Gian Bott in 17. März 2004, 10:43:09
Beitrag von: Gian Bott in 17. März 2004, 10:43:09
Hallo Nils,
Warum auch? , das macht doch das Forum sooo interessant!
In Antwort auf:
(der sich bereits Ärgert, seine erste Mail geschrieben zu haben...)
Warum auch?
, das macht doch das Forum sooo interessant!
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Dietloff in 17. März 2004, 10:58:11
Beitrag von: Dietloff in 17. März 2004, 10:58:11
Hallo Zusammen,
jetzt wird´s ja immer breitbandiger.
Wenn ich mich recht erinnere, fing dieser Thread mit Problembeschreibungen bzgl. FPL-Ablauf an.
Diesbzgl. wurden dann Tipps gegeben, diesen einzukreisen und zu analysieren. Auch wurde die Sorge ausgeräumt, dass der FPL die WDP-eigenen Access-Datenbanken verändern könnte.
Das Feedback zu den FPL-Tests, um den Fehler zu finden steht seitens der User noch aus. Die PC-Hardware und Performance wurde dabei explizit in Bezug auf die Problembeschreibung ausgeschlossen.
Hinzu kamen dann Kommentare zum PC. In den letzten Monaten sind bereits viele Einträge bzgl. PC-Dimension geschrieben worden, nebst Faustformel.
Grundsätzlich sollte man einfach bedenken, dass wenn das MoBa-Budget vielleicht "klein" ist (was immer das in Euro bedeutet), dann ist es dennoch wichtig im Auge zu behalten, dass mit Anzahl von Loks und dem Wachstum der Bahn immer grössere Anforderungen an JEDE Software gestellt wird, d.h. der PC sollte entsprechend linear mitwachsen.
Da aber sehr viele Faktoren eine Rolle spielen, dazu gehört auch das Betriebssystem, die Konfiguration dazu, RAM, Soundkarte, vernünftige Treiber UND vor allen Dingen auch, WIE der User WDP nutzt (viel Sound, viel FPL oder AK und FPL, etc.) - wird die Rechnerkapazität auch entsprechend gefordert.
Als (einfache) Faustformel:
1. Während des WDP-Anlagenbetriebs sollte die CPU-Auslastung ("gemessen" über den Task-Manager) im Schnitt UNTER 75% liegen. Gelegentliche Spitzen darüber sind vernachlässigbar. Ist die CPU-Last nahezu permanent über 80-90% (und mehr) dann sind Unregelmässigkeiten unvermeidbar.
2. Über den dicken Daumen geschätzt benötigt man pro 3-5 zusätzliche Loks ca. 100MHz mehr an CPU-Speed.
Bei mir persönlich fahren bis zu 10 Loks GLEICHZEITIG und mein PIII-1GHz mit 256MB-RAM steuert dies klaglos.
Vielleicht sollten wir dann einen Extra-Thread bzgl. PC-Systeme eröffnen.
Dennoch interessiert mich der Ausgang des eigentlichen Ursprungs DIESES Threads bzgl. der FPL-Erscheinungen.
Grüsse
Rüdiger Dietloff
jetzt wird´s ja immer breitbandiger.
Wenn ich mich recht erinnere, fing dieser Thread mit Problembeschreibungen bzgl. FPL-Ablauf an.
Diesbzgl. wurden dann Tipps gegeben, diesen einzukreisen und zu analysieren. Auch wurde die Sorge ausgeräumt, dass der FPL die WDP-eigenen Access-Datenbanken verändern könnte.
Das Feedback zu den FPL-Tests, um den Fehler zu finden steht seitens der User noch aus. Die PC-Hardware und Performance wurde dabei explizit in Bezug auf die Problembeschreibung ausgeschlossen.
Hinzu kamen dann Kommentare zum PC. In den letzten Monaten sind bereits viele Einträge bzgl. PC-Dimension geschrieben worden, nebst Faustformel.
Grundsätzlich sollte man einfach bedenken, dass wenn das MoBa-Budget vielleicht "klein" ist (was immer das in Euro bedeutet), dann ist es dennoch wichtig im Auge zu behalten, dass mit Anzahl von Loks und dem Wachstum der Bahn immer grössere Anforderungen an JEDE Software gestellt wird, d.h. der PC sollte entsprechend linear mitwachsen.
Da aber sehr viele Faktoren eine Rolle spielen, dazu gehört auch das Betriebssystem, die Konfiguration dazu, RAM, Soundkarte, vernünftige Treiber UND vor allen Dingen auch, WIE der User WDP nutzt (viel Sound, viel FPL oder AK und FPL, etc.) - wird die Rechnerkapazität auch entsprechend gefordert.
Als (einfache) Faustformel:
1. Während des WDP-Anlagenbetriebs sollte die CPU-Auslastung ("gemessen" über den Task-Manager) im Schnitt UNTER 75% liegen. Gelegentliche Spitzen darüber sind vernachlässigbar. Ist die CPU-Last nahezu permanent über 80-90% (und mehr) dann sind Unregelmässigkeiten unvermeidbar.
2. Über den dicken Daumen geschätzt benötigt man pro 3-5 zusätzliche Loks ca. 100MHz mehr an CPU-Speed.
Bei mir persönlich fahren bis zu 10 Loks GLEICHZEITIG und mein PIII-1GHz mit 256MB-RAM steuert dies klaglos.
Vielleicht sollten wir dann einen Extra-Thread bzgl. PC-Systeme eröffnen.
Dennoch interessiert mich der Ausgang des eigentlichen Ursprungs DIESES Threads bzgl. der FPL-Erscheinungen.
Grüsse
Rüdiger Dietloff
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Olivier De Bastiani in 17. März 2004, 11:01:01
Beitrag von: Olivier De Bastiani in 17. März 2004, 11:01:01
Hallo Bernd,
das mit der genrellen Aussage ist nicht so einfach. Jede Anlage ist anders und verlangt eine andere Rechnerleistung. Auch ein stetig wachsende Anlage (wie bei dir und bei mir) verlangt irgendwann nach einer schnelleren Hardware.
(Hast du's gemerkt: ich schreibe "schnellere" nicht "bessere")
Ich habe mit einem Pentium/200 MHz und 64 MB RAM im AK-Betrieb angefangen. Mittlerweilen (nach 3-1/2 Jahren) bin ich bei einem PIII/750 MHz und 128 MB RAM (alles WIN 98).
Um mein Budget nicht zu überziehen, erweitere ich den PC nur bei Bedarf. So kann man auch eine schöne Stange Geld sparen, da die Hardwarepreise sich fast monatlich ändern.
Die Frage lautet aber immer noch: Woran hängt es denn?
Hierzu mal ein ganz trivialer Lösungsansatz:
Vor dem erneuten Start eines FPLs bitte mal die Taste "F7" drücken.
Wie siehts aus: hat sich eine Besserung eingestellt?
das mit der genrellen Aussage ist nicht so einfach. Jede Anlage ist anders und verlangt eine andere Rechnerleistung. Auch ein stetig wachsende Anlage (wie bei dir und bei mir) verlangt irgendwann nach einer schnelleren Hardware.
(Hast du's gemerkt: ich schreibe "schnellere" nicht "bessere"
)Ich habe mit einem Pentium/200 MHz und 64 MB RAM im AK-Betrieb angefangen. Mittlerweilen (nach 3-1/2 Jahren) bin ich bei einem PIII/750 MHz und 128 MB RAM (alles WIN 98).
Um mein Budget nicht zu überziehen, erweitere ich den PC nur bei Bedarf. So kann man auch eine schöne Stange Geld sparen, da die Hardwarepreise sich fast monatlich ändern.
Die Frage lautet aber immer noch: Woran hängt es denn?
Hierzu mal ein ganz trivialer Lösungsansatz:
Vor dem erneuten Start eines FPLs bitte mal die Taste "F7" drücken.
Wie siehts aus: hat sich eine Besserung eingestellt?
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Gian Bott in 17. März 2004, 11:20:20
Beitrag von: Gian Bott in 17. März 2004, 11:20:20
Hallo Bernd,
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.
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.
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Thorsten Haller in 17. März 2004, 11:38:23
Beitrag von: Thorsten Haller in 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."
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."
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Wirth in 17. März 2004, 12:49:58
Beitrag von: Wirth in 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
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
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Wirth in 17. März 2004, 20:46:42
Beitrag von: Wirth in 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
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
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Olivier De Bastiani in 17. März 2004, 22:39:55
Beitrag von: Olivier De Bastiani in 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)
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)
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Wirth in 18. März 2004, 07:43:27
Beitrag von: Wirth in 18. März 2004, 07:43:27
In Antwort auf:
Jetzt meine Fragen:
1. Was ist anders innerhalb der einen Minute (also zwischen Abfahrtszeit 55 Minuten und Abfahrtzeit 56 Minuten)?
Eigentlich nichts. Zu diesem Zeitpunkt fährt nur eine weitere Lok ihre KS ab.
2. Was meinen Sie mit "... Loksymbol wird auf neue Position übertragen ..."? (Bitte die Lokadresse während der Fahrstrassenabarbeitung nicht neu setzen)
Ich meinte, daß die Loknummer auf das neue Lokfeld übertragen wird.
3. Haben Sie schon mal einen Loktausch in FPL durchgeführt?
(Nur um es zur gleichen Zeit mit einer anderen Lok zu probieren)
Werde hoffentlich heute bei diesem Fahrplan mal ausprobieren.
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Dietloff in 18. März 2004, 08:10:33
Beitrag von: Dietloff in 18. März 2004, 08:10:33
Hallo Herr Wirth,
Das ist für mich das Indiz, dass hier ein klitzekleiner Konfigurationsfehler vorliegt, der sicherlich zu finden ist.
Ich gebe Olli recht, mit den Projektdaten wäre dies einfacher, aber Sie haben es schon sehr ausführlich und nachvollziehbar geschildert.
Was sagt denn der Inspektor, wenn die Lok (V=0) nicht losfährt?
Grüsse
Rüdiger Dietloff
In Antwort auf:
Danach die Startzeit der Zeile von 55 Minuten auf 56 Minuten geändert. Folge: Fahrplan läuft ohne Probleme! Super!
Das ist für mich das Indiz, dass hier ein klitzekleiner Konfigurationsfehler vorliegt, der sicherlich zu finden ist.
Ich gebe Olli recht, mit den Projektdaten wäre dies einfacher, aber Sie haben es schon sehr ausführlich und nachvollziehbar geschildert.
Was sagt denn der Inspektor, wenn die Lok (V=0) nicht losfährt?
Grüsse
Rüdiger Dietloff
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Norbert Burkert in 18. März 2004, 09:39:58
Beitrag von: Norbert Burkert in 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?
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?
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Wirth in 18. März 2004, 10:26:58
Beitrag von: Wirth in 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
Zwecks Projektdaten: welche Dateien soll ich zur Verfügung stellen?
Gruß
Stefan Wirth
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Dietloff in 18. März 2004, 10:43:18
Beitrag von: Dietloff in 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
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
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Wirth in 18. März 2004, 19:51:22
Beitrag von: Wirth in 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
so, die Daten sind übermittelt.
Ich habe heute die Lok gegen eine andere getauscht. Leider habe ich dennoch das gleiche Problem.
Gruß
Stefan Wirth
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Rudi Klein in 19. März 2004, 07:49:27
Beitrag von: Rudi Klein in 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
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
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Wirth in 19. März 2004, 08:32:13
Beitrag von: Wirth in 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
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
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Wirth in 19. März 2004, 19:47:42
Beitrag von: Wirth in 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
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
Titel: kleine Ergänzung
Beitrag von: Dietloff in 20. März 2004, 17:29:23
Beitrag von: Dietloff in 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
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
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Armin in 22. März 2004, 22:12:18
Beitrag von: Armin in 22. März 2004, 22:12:18
Hallo Betatester,
"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."
Als Nicht-Informatiker stehe ich diesem Problem noch viel hilfloser gegenüber als Sie alle. In einem meiner früheren Beiträge (inzwischen gelöscht?) habe ich auf Access-Probleme hingewiesen; nämlich, daß sich bei mir keine Fahrstraßen mehr ver- und einschieben lassen. Access reagiert ganz einfach nicht mehr darauf.
Diesbezüglich stehe ich leider
noch immer im Regen.
"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."
Als Nicht-Informatiker stehe ich diesem Problem noch viel hilfloser gegenüber als Sie alle. In einem meiner früheren Beiträge (inzwischen gelöscht?) habe ich auf Access-Probleme hingewiesen; nämlich, daß sich bei mir keine Fahrstraßen mehr ver- und einschieben lassen. Access reagiert ganz einfach nicht mehr darauf.
Diesbezüglich stehe ich leider
noch immer im Regen.
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Heller in 22. März 2004, 23:02:23
Beitrag von: Heller in 22. März 2004, 23:02:23
Hallo Armin,
in solchen Fällen gibt es ein probates Gegenmittel:
- WDP verlassen
- Datenpflege aufrufen
- Fahrstraßen-Datenbank reparieren
Dann neu versuchen.
in solchen Fällen gibt es ein probates Gegenmittel:
- WDP verlassen
- Datenpflege aufrufen
- Fahrstraßen-Datenbank reparieren
Dann neu versuchen.
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: Dietloff in 23. März 2004, 12:53:36
Beitrag von: Dietloff in 23. März 2004, 12:53:36
Hallo Armin,
wenn man im Fahrplan (FPL) editiert, dann hat dies nichts mit einer Access-Datenbank zu tun!
Lediglich die Fahrstrassen und Loks stehen in einer Access-Datenbank und werde im FPL in einer TEXT-Datei (!) zusammengeführt.
Somit kann man durch blossen Editieren im FPL keine WDP-Datenbank zerstören.
Bevor direkt Mutmassungen oder Vorab-"Feststellungen" genannt werden, ist es sicherlich dienlicher, wenn Sie exakt beschreiben, WANN WAS WIE nicht nach Ihren Wünschen funktioniert. D.h. eine Fehlerbeschreibung nebst Anlagen- und PC-Konfiguration ist dann hilfreich.
Ich gehe zumindest davon aus, dass Sie den aktuellsten WDP-Release (V8.5) haben, auch wenn in Ihren Einstellungen noch die V8.41 steht.
Sollten Sie zu diesem Thema bereits schon einmal einen Eintrag gemacht haben, dann ist er sicherlich noch da; denn in diesem Forum wird nicht "zensiert" in Form von Löschen, wenn einer Fragen zum Thema hat.
Je genauer Sie Ihre Problemstellung beschreiben, je eher und besser können wir Ihnen aus der Ferne helfen; denn einige Beta-Kollegen sind absolute FPL-"Profis" und da bleibt eigentlich nichts unbeantwortet.
Grüsse
Rüdiger
wenn man im Fahrplan (FPL) editiert, dann hat dies nichts mit einer Access-Datenbank zu tun!
Lediglich die Fahrstrassen und Loks stehen in einer Access-Datenbank und werde im FPL in einer TEXT-Datei (!) zusammengeführt.
Somit kann man durch blossen Editieren im FPL keine WDP-Datenbank zerstören.
Bevor direkt Mutmassungen oder Vorab-"Feststellungen" genannt werden, ist es sicherlich dienlicher, wenn Sie exakt beschreiben, WANN WAS WIE nicht nach Ihren Wünschen funktioniert. D.h. eine Fehlerbeschreibung nebst Anlagen- und PC-Konfiguration ist dann hilfreich.
Ich gehe zumindest davon aus, dass Sie den aktuellsten WDP-Release (V8.5) haben, auch wenn in Ihren Einstellungen noch die V8.41 steht.
Sollten Sie zu diesem Thema bereits schon einmal einen Eintrag gemacht haben, dann ist er sicherlich noch da; denn in diesem Forum wird nicht "zensiert" in Form von Löschen, wenn einer Fragen zum Thema hat.
Je genauer Sie Ihre Problemstellung beschreiben, je eher und besser können wir Ihnen aus der Ferne helfen; denn einige Beta-Kollegen sind absolute FPL-"Profis" und da bleibt eigentlich nichts unbeantwortet.
Grüsse
Rüdiger
Titel: Re: Probleme mit Windigipet 8.5
Beitrag von: B.Michaelsen in 09. April 2004, 16:35:52
Beitrag von: B.Michaelsen in 09. April 2004, 16:35:52
Hallo Norbert !
Lange habe ich nichts mehr von mir hören lassen.
Nun halte ich es nicht für richtig, wenn man mit Problemen in das Forum geht und anschliessend abtaucht, wenn die Fehler eben doch nicht vom WinDigipet zu verantworten sind..... 
Dass ich mich erst jetzt melde, hängt damit zusammen, dass ich meine Anlage fleissig erweitert habe (35 qm wollen ja auch gefüllt werden). Dies hatte natürlich auch Konsequenzen, was mein Gleisbild betrifft. Also Zeichnung geändert, und wirklich auch praktisch alle Fahrstrassen überprüft, was bei einigen Hundert schon nerven kann.
Das hast Du dem Stefan geantwortet. Na gut, hab ich mir gesagt, wenn das so ist, liegt der Fehler mal wieder zwischen Stuhl und Tastatur.....
Tatsächlich habe ich einige Problemchen in den FS finden können, die sich offensichtlich aus 7.0/7.2/7.6 er Zeiten bis heute verbergen konnten. Ich fand z.B. RMK´s die garnicht in die FS gehörten. Sowas kommt wahrscheinlich zustande, wenn das Gleisbild ständig verändert wird. FS neu mit der Kamera abgefahren und Ruhe im Karton.
Und nun zu meinem Problem. Fahrplan läuft und läuft und läuft. Ist halt doch ´ne gute, ausgereifte Software. Wie Du oben bereits meintest.
Die Inspektoren haben mir eigentlich nichts übles gezeigt, ausser dem Fehlen von Stopkontakten in 2 FS (da die in stromlosen Abschnitten endeten, fiel das nie auf ).....
Na ja, lange Rede kurzer Sinn. WD ist und läuft stabil !!!
Herzlichen Dank auch an die anderen Betatester, die sich unserer norddeutschen Probleme angenommen haben. Das ist eben das Problem, dass ihr die Spezialisten seid und der User aus der Nachbarschaft nicht !
Herzlichen Gruss
Bernd Michaelsen
Lange habe ich nichts mehr von mir hören lassen.
Nun halte ich es nicht für richtig, wenn man mit Problemen in das Forum geht und anschliessend abtaucht, wenn die Fehler eben doch nicht vom WinDigipet zu verantworten sind..... Dass ich mich erst jetzt melde, hängt damit zusammen, dass ich meine Anlage fleissig erweitert habe (35 qm wollen ja auch gefüllt werden).
Dies hatte natürlich auch Konsequenzen, was mein Gleisbild betrifft. Also Zeichnung geändert, und wirklich auch praktisch alle Fahrstrassen überprüft, was bei einigen Hundert schon nerven kann.In Antwort auf:
was möchten Sie denn gerne lesen?
Ja die Fehler sind bekannt und liegen an Win-Digipet? Damit kann ich leider nicht dienen!
Das hast Du dem Stefan geantwortet. Na gut, hab ich mir gesagt, wenn das so ist, liegt der Fehler mal wieder zwischen Stuhl und Tastatur.....
Tatsächlich habe ich einige Problemchen in den FS finden können, die sich offensichtlich aus 7.0/7.2/7.6 er Zeiten bis heute verbergen konnten. Ich fand z.B. RMK´s die garnicht in die FS gehörten. Sowas kommt wahrscheinlich zustande, wenn das Gleisbild ständig verändert wird. FS neu mit der Kamera abgefahren und Ruhe im Karton.
Und nun zu meinem Problem. Fahrplan läuft und läuft und läuft. Ist halt doch ´ne gute, ausgereifte Software. Wie Du oben bereits meintest.
Die Inspektoren haben mir eigentlich nichts übles gezeigt, ausser dem Fehlen von Stopkontakten in 2 FS (da die in stromlosen Abschnitten endeten, fiel das nie auf ).....
Na ja, lange Rede kurzer Sinn. WD ist und läuft stabil !!!
Herzlichen Dank auch an die anderen Betatester, die sich unserer norddeutschen Probleme angenommen haben. Das ist eben das Problem, dass ihr die Spezialisten seid und der User aus der Nachbarschaft nicht !
Herzlichen Gruss
Bernd Michaelsen