Lockstop

[Kurt Breetzmann]

Hallo alle Miteinander,
mitunter kommt es vor, das die Zügen nicht am Signal stehenbleiben, sondern in kaum sichtbarer Zeitlupe weiterfahren. Eine zweite Stopzeile ins Profil eintragen bringt kein Erfolg => Was mache ich falsch?  

[Dirk Streuber]

Hallo Kurt,

herzlich Willommen hier im Forum.

Welche WDP-Version verwendest Du? Ist das Problem nur, wenn mit Profilen gefahren wird, oder auch bei den Standardfahrten (ohne Profil) ? Der Stopp braucht in einen Profil nur einmal eingetragen werden. Werden denn alle Profilzeilen korrekt abgearbeitet? Dies ist im Profilablauf Inspektor zu sehen.  

[Kurt Breetzmann]

Hallo Dirk,

diesen Effekt hatte ich schon mit der Version 9.1 und jetzt mit der 9.2. Auf die Idee mit der zweiten Stopzeile im Profil kam ich, da ein Klick auf den Stop-Button in der Lockleiste den zug zum Stehen bringt. Ich fahre nur mit Anforderungskontaktautomatik.

Gruss Kurt  

[Dirk Streuber]

Hallo Kurt,

betrifft es immer die gleichen Fahrstraßen und die selben Züge. Wenn ja, ist bei den betreffenden Fahrstraße bei der Ziel-Freigabebedingung ein zweiter RM (K2) eingetragen? Dann stoppt der Zug erst, wenn diese Zielfreigabebedingung erfüllt ist. Wenn es dies nicht ist, dann schicke mir mal bitte eine Datensicherung ohne Lokbilder und Symbole als Zip. Dann kann ich es mal ansehen.  

[Dieter Trudel]

Hallo, Dirk,
den wahrscheinlich gleichen Effekt habe ich auch. 3 Blockstrecken, 2 Lok's, Automatik mit Anforderungskontakten (keine Profile).
Eine Weile (unbestimmte Anzahl geht es gut, dann die Langsamfahrt. Und das sind in der EDV ja immer die schönsten Probleme. Im Lokcontrol wird für die betreffende Lok 0 als Geschwindigkeit angezeigt, eine Überprüfung mit dem LH 100 von Lenz zeigt 5 an. Drücken auf Stop im Control bringt die Lok natürlich zum Stehen.
Die Sache ist unabhängig von der Fahrstraße und unabhängig von der Lok.
Deine Hinweise bzgl. Freigabe habe ich geprüft, sie sind nicht die Ursache.
Ich suche schon tagelang, sicher ist die Lösung am Ende trivial.

Freundliche Grüße aus LE
Dieter  

[Christof Z.]

Hallo Dirk,

Den geschilderten Effekt habe ich seit Update auf ProX.1 (heute) auch. Immer die gleiche FS und die gleiche Lok (Roco E10 WS mit Lopi OEM Dekoder). Sowohl in der ZFA als auch Start/Ziel Funktion. Alle anderen Loks stoppen wie gewollt....    

[Markus Herzog]

Hallo Dieter,

hast du gemäß Lenz-Anleitung die Leitungen des X-Bus (ich glaube ich so heißen die d.h.z.B. zwischen Zentrale und Busverteiler etc.) die nicht aus konfektionierten Kabel bestehen paarweise verdrillt? Die mit den konfenktionierten Kabeln würde ich allgemein auch recht kurz halten.
Ich habe leider bei Lenz immer wieder erlebt, dass wenn die Verkabelung nicht hunderprozentig sauber war, Befehle verloren gingen. In allen von mir damals beobachteten Fällen waren die Befehle nachweislich (direkte Schnittstelle-Überwachungen mit Port-Sniffer) an das LEnz-Interface rausgegangen und quittiert worden, aber nicht sauber bei der Zentrale angekommen.

Grüße
Markus

[Markus Herzog]

Hallo Christof,

kannst du mir mal eine Datensicherung deines Projektes senden mit der Angabe welche FS und Lok betroffen sind, dann sehe ich mir dies gerne mal an.
Kann wohl ein bischen dauern, da ich diese Woche noch ne Menge auf dem Plan habe.

Grüße
Markus

[Dieter Trudel]

Hallo, Markus,
vielen Dank für Deinen Hinweis. Manches spricht ja dafür, vor allem die Unregelmäßigkeit und der eintrag im Lokcontrol. Warum aber grundsätzlich beim Stopkontakt? Alle anderen Kommandos werden (zumindest für mich erkennbar) ordnungsgemäß empfangen. Den X-Bus betreffend (bei Lenz also LMAB) ist dieser 15cm lang zwischen LI101F und Zentrale und von dort nochmalca. 1,2m bis zu einer anschlußplatte für Handregeler usw. Die Zentrale ist also nicht Endpunkt, wird aber von Lenz nicht explizit gefordert. Das Kabel ist nicht verdrillt, weil nicht gefordert (welche Leitung soll isch evtl. verdrillen? Lt. Lenz ist dies nur für den RS-Bus und die Boosterleitungen C,D. Letztere habe ich noch nicht. RS ist verdrillt und wegen zentraler Anordnung der Rückmelder auch recht kurz. Die COM-Einstellung ist 38400, das Abfrageintervall 100msec.

Nur der Vollständigkeit halber:
Es gibt noch eine andere merkwürdige Sache bei mir. Die rote Ausleuchtung im Gleisbild bei besetzt erscheint nicht immer bei Belegung trotz richtiger Anzeige am Handregler und im RM-Monitor. Die Meldung kommt also im Programm richtig an. Oder habe ich hier einen Verständnisfehler?

Was hat Dein Ideenfundus noch auf Lager?

Freundliche Grüße aus LE
Dieter
 

[Markus Herzog]

Hallo Dieter,

ich habe gerade die Anleitungen meiner Lenzkomponenten hier gewälzt. Du hast recht, es steht zumindest in der Anleitung des Zentrale LZV 100 nicht drin, aber ich habe hier noch ein LI 100 und ein LV 100 und in deren Anleitungen finde ich entsprechende Bilder. Hier sind vom X-Bus L und M paarweise und als zweites Paar A und B miteinander verdrillt. Also bei Sicht auf die Buchse die beiden linken und die beiden rechten Leitungen. Es wird allerdings davor gewarnt aus Versehen dabei L und M zu vertauschen, da es sonst zu Defekten kommen kann. Wie gesagt, seitdem ich dies auf unserer Testanlage gemacht habe, haben wir wesentlich weniger PRobleme.

Das dies nur den Stopkontakt betrifft liegt vermutlich daran, dass man ja kaum mitbekommt, ob eine Lok mit Fahrstufe 13 oder 14 (bei 28 Fahrstufen) oder noch schlimmer 64 oder 65 (bei 128) fährt, zumal es ja nicht immer auftritt. Zwischen Fahrstufe 0 und 1 da sieht man dann aber den Unterschied...

Zur Rotausleuchtung im Gleisbild:
Dies läuft mit relativ niedriger Priorität d.h. wenn der PC gerade mit anderen Aufgaben wie mit Fahrstraßen schalten, Fahrbefehle sende etc. ausgelastet ist oder Windows gerade mal andere Prioritäten hat, kommt es schon mal vor, dass die Rotausleuchtung nicht richtig nachgeführt wird. Dies habe ich allerdings lange nicht mehr von einem User gehört, da wir da in der Vergangenheit extrem an der Performance geschraubt haben und zumindest ich dies nicht mehr gesehen habe. Mehr fällt mir dazu auch gerade nicht ein. KAnnst du mal beobachten was du gerade vor gemacht hast bzw. gerade machst im Programm wenn dieses Phänomen auftritt.

Grüße
Markus

[Dieter Trudel]

Hallo, Markus,
danke für den Hochgeschwindigkeitsservice! Ich werde die Isolation abtrennen und die Leitungen verdrillen. Im positiven Fall informiere ich Dich, andernfalls muß ich wohl still vor mich hin grollen. Ob die Baudrate was bringt? Ich bin ohnehin der Ansicht, dass >19200 nichts mehr bringt, da die kleinen Bits nicht so schnell verarbeitet werden können, oder?
Das mit der Ausleuchtung beobachte ich weiter. Ich hatte gerade eine Serie Achsen mit SMD-Widerständen beklebt, und da nervte es etwas, weil alle i. O. waren aber kein Rot kam.
Und freundliche Grüße
Dieter  

[Dieter Trudel]

Hallo, Markus,
noch ein Nachtrag. Habe gestern die 2x2 Leitungen verdrillt, kein Erfolg. Anschließend habe ich zwischen den Befehlen eine Pause von 10 ms eingestellt und toi, toi, toi, noch kein verschluckter Befehl. Das bedeutet doch aber, daß ich künstlich das mache, was eigentlich über das busy-Signal vom Interface gemacht werden müßte. Wird das garnicht ausgewertet? Meines Wissens kommt doch von der Zentrale auch eine Quittung, oder liege ich da falsch. Mein COM-Kabel ist vollständig, also mit CTS und RTS.
Was mich auch noch gewundert hat, im Gerätemanager sehe ich nicht (während der Laufzeit von WDP) die aktuellen COM-Einstellungen, aber das ist wohl eine Windowseigenheit.
Freundliche Grüße aus LE
Dieter
 

[Markus Herzog]

Hallo Dieter,

das stimmt in den Windows-System-Einstellungen siehst du nur die Standardeinstellungen für den COM-Port, die wir nicht übernehmen sondern temporär mit eigenen Überschreiben. Habe es gerade zur Sicherheit nochmal kontrolliert auch wenn ich mir sicher war, dass bei Lenz das Hardware-Handshake (RTS/CTS) aktiviert ist. Da kriegen wir im Programm außer dass es einmal eingeschaltet wird aber auch gar nichts mehr von mit. Wir schreiben nur in einen (sehr großen) Ausgangspuffer und lesen aus einem Eingangspuffer, die Handshake-Sache wird vom Treiber auf niedrigerer Ebene abgearbeitet und das funktioniert (habe es mal selber mit einem Testinterface probiert wo ich die Handshake-Leitungen künstlich ändern konnte). Zusätzlich wird aber auch in der Software bei Lenz immer auf die Quittung des Interfaces gewartet, um eventuell missverstandene Befehle zu wiederholen und erst nach einer "OK"-Quittung den nächsten Befehl rauszulassen. Und doch scheint es bei Lenz in den meisten Fällen unerlässlich zu sein eine 10ms Sendepause einzufügen, steht auch glaube ich so im Handbuch, habe zwar nur das ProX-HB vor mir, stand aber im 9er glaube ich genauso drin.
Ich denke die Datenrate zum Interface sollte übrigens keine Unterschiede machen egal ob 19.200, 38.400 etc. Intern setzt das Lenz-Interface die ankommenden Befehle sowieso auf den X-Bus bzw. ExpressNet um und da wird fest mit ca.64.000 bit/s gearbeitet. Bedenkt man aber nun, dass man bei Lenz meistens eine Sendepause braucht von 10ms, dann gehen da sowieso nur noch 100 Befehle pro Sekunde maximal raus und wenn man je Befehl mal im Schnitt 6 Bytes ansetzt, dann käme man auch mit 6*8*100=4800 Bit/s aus.
Daher kann ich mich nur amüsieren über die Leute, die z.B. als einen der Vorteile der ECoS das 10 MBit/s Interface anführen. Vergleicht man diese mit der Tams mit 57,6 KBit/s, dann ist die Tams bei der Initialisierung von z.B. 80 Lokomotiven beim Programmstart circa. doppelt so schnell wie die ECoS. Einfach weil sie vieler schneller die Befehle annimmt und quittiert. Aus meiner Erfahrung sind die einzigen wirklich schnellen Zentralen/Interfaces die Tams und die SX-Produkte (Rautenhaus, Müt).

Grüße
Markus  

[Dieter Trudel]

Hallo, Markus,
vielen Dank für Deine ausführlichen Erläuterungen. Endlich bestätigt mir mal jemand das mit den hohen Taktraten.
Und das mit den 10 msec, ja, da gehöre ich wohl mal wieder zu den 99% zwischen Tastatur und Stuhllehne...
Frohes Schaffen und freundliche Grüße aus LE
Dieter