Guten Abend an Alle
Ich habe seit einiger Zeit ein Problem und - zufällig oder nicht - etwa seit der Umstellung auf die neueste WDP-Version 2015-2:
Es passiert sehr oft, dass Loks über ein iZNF hinausfahren in den nächsten Blockstreckenabschnitt.
Und weil ich ein umfangreiches Unfall-Vermeidungssystem habe, kriege ich eben dauernd Fehlermeldungen.
Ich kann jetzt die Bremskorrektur überall verändern. Aber das war doch vorher nicht notwendig!
Natürlich habe ich schon einiges versucht:
Ich habe einen recht schnellen Rechner mit SSD-Platte.
Die Belastung im Task-Manager ist unerheblich.
Das Abschalten eines Viren-Schutzprogramms (Avira) änderte nichts.
Das Rückmeldesystem funktioniert mit der Tams-MC anscheinend einwandfrei.
Der Fehler passiert bei unterschiedlichen Decodern (DCC, MFX etc.)
Frage mal jetzt weniger an die Experten als an Alle:
Hat jemand ein ähnliches Phänomen beobachtet???
Dann könnte man daran denken, dass es an unserem Programm liegt - anderenfalls kann ich ja nur einen Wurm in meiner Hardware haben und muss weiter suchen.
Hat jemand eine Idee?
Hallo Friedel,
wurde vielleicht ein Booster getauscht, der jetzt eine andere Spannung hat?
Hast Du mal eine Lok nachgemessen, ob zu sehen, ob die Messkurve noch stimmt?
Hallo Friedel,
mit welchem Rückmeldesystem arbeitest Du?
Nicht das sich bei Dir das Windows-Update Problem so auswirkt. Zeigen die RMK´s die korrekte Belegung an?
Hallo Friedel,
du bist nicht alleine. Habe gleiches Problem sowohl bei Mittelleiter wie auch bei Bemo Anlage.
Meine Versuche:
Loks neu eingemessen. Abschnitte seeehr genau vermessen. Signalabstand radikal verändert - hat alles nichts gebracht.
Beide Rechner gleich. Einmal win 7 und einmal win 10.
Als wenn die Rechenformel verändert wurde. Ursprünglich verlangsamten die Loks am Anfang der Strecke, jetzt passiert das erheblich später.
Gruss
Michael
@Helmut / @Willi:
kein Booster getauscht
Phänomen passiert bei ganz verschiedenen Loks
RM-System S-88 von G. Boll - funktioniert einwandfrei
@Michael:
Das ist ja interessant. Ich wagte gar nicht, diese Vermutung zu äußern.
Vielleicht liest ja Markus mit: Kann da irgendetwas - evt. versehentlich - geändert worden sein?
@Alle:
Gibt es noch mehr Erfahrungen in der gleichen Richtung?
Hallo Friedel,
Antwort auf Deine Frage - ja - allerdings ist es bei mir so seit mehr als 2 Jahren (da war noch kein iZNF) und ich bin mittlerweile überzgut dass es die CS2 ist die das verursacht. Mir sind deswegen auch schon ca 16 Weichenantriebe abgeraucht.
Leider wird Dir dies nicht weiterhelfen, da Du sagst es begann bei Dir unlängst. Wollte trotzdem eine Rückmeldung geben.
Viele Grüße,
Dieter
Hallo Dieter,
wo soll jetzt der Zusammenhang sein, dass Weichenantriebe abrauchen, wenn die Loks zu weit fahren?
Hallo Michael und Friedel,
Was soll ich dazu sagen....
Ich kann nur sagen, dass an dem Programmteil nichts geändert wurde, weder Formeln noch sonst etwas. Bin auch selber in letzter Zeit einige Male gefahren mit der Anlage und ich habe da teilweise auch sehr knapp gebaute Stellen drin wo ich aber keine Veränderung bemerkt habe.
Grüße
Markus
Hallo Markus
Danke für die Klarstellung.
Dann gäbe es höchstens noch eine andere Möglichkeit:
Ist es denkbar, dass bei starkem Betrieb WDP plötzlich so sehr mit was anderem beschäftigt ist, dass die Auswertung der Rückmelder blockiert wird?
Aber ich weiß ja selbst: Wie soll man das testen?
Jedenfalls ist eines klar:
Das von mir beschriebene Phänomen fällt mir seit etwa 3 Monaten auf, ist deutlich und häufig festzustellen und gab es so vorher noch nicht.
Was mag das sein?
Hallo Miteinander,
ich bin zwar kein Märklin Fahrer, hatte aber ähnliche Probleme.
Das heißt einige Loks hielten auf einmal nicht mehr da wo sie sollten und nahmen auch keinen Stop oder Bremsbefehl an.
Kurz gesagt, es lag bei mir an den Lenz Silver Decodern die nach und nach alle diesen Fehler zeigten.
Nach Austausch gegen Lopi 4.0 DCC von ESU und erneutem einmessen habe ich bis jetzt keine Probleme mehr.
Könnte es auch bei Euch ein Lok Decoder Problem sein ?
Herbert
Liebe WDPler,
ich hatte (?) auch dieses Problem !
Z.Zt. nur auf einer Fahrstraße in einem 7-gleisigen Schattenbahnhof.
Meine Märklin-Anlage hat ihren Ursprung Anfang der 1960er Jahre und besteht aus M-Gleisen. Digitalisiert habe ich sie im Jahre 2001. Die Loks rüstete ich mit Märklin-fx-Decodern und Uhlenbrock 76200-Decodern aus. Zentrale ist die Uhlenbrock Intellibox.
Nach einigen fehlgeschlagenen Versuchen mit verschiedenen Steuerungs-Systemen benutze ich seit November 2011 Windigipet 2009 Premium Edition.
Die Märklin-Zentrale 6021 benutze ich lediglich zur Bedienung des umschaltbaren Fahrbetriebes eines (ansonsten von der IB bedienten) Anlagenteils für einen "Mitspieler" und zur Programmierung von Märklin-Decodern ohne DIP-Schalter.
Das Rückmelde-System ist S88 mit Viessmann-Modulen. Nach den Empfehlungen von Karlheinz Battermann habe ich sie in unmittelbarer Nähe der IB auf ein Brett montiert und fest verdrahtet. Die von den Kontaktgleisen kommenden Leitungen sind (teilweise bis zu 15 m lang) angelötet.
Alle Schalt-Aufgaben und der Fahrbetrieb werden über die IB ausgeführt.
Und nun zu meinem Problem:
Die bewusste Fahrstraße endet in einem nicht einsehbaren Bereich des Schattenbahnhofs. Durch Sicht-Luken kontrollierte ich bislang, ob die Loks noch vor den Ausfahrweichen angehalten hatten.
Am 19.03.2017 kam es zu einem "Unfall", der mich veranlasste, einen Teil des Schattenbahnhofs freizulegen.
Eine Lok mit fx-Decoder reagierte nicht mehr auf Verzögerungs- und Stop-Befehle und fuhr ohne Halt weiter. Eine gleiche Lok, jedoch mit 76200-Decoder, bremste und hielt auf der Weichenstraße an.
Ursache:
Die Leitung vom Brems-Kontakt zum S88-Modul hatte eine Unterbrechung. Hierdurch konnte der Brems-Befehl nicht ausgeführt werden. Warum der Stop-Befehl bei einer Lok nicht ausgeführt wurde, habe ich nicht ergründen können.
Problem-Behebung:
Im Gleisbild-Editor in dem betreffenden Gleis den RMK gelöscht.
Im Fahrstraßen-Editor den Kontakt-Eintrag gelöscht und die Ereignisse der anderen Kontakte angepasst.
Profile für einige Loks für das betreffende Gleis gelöscht.
Ergebnis:
Alle Loks halten wieder an der richtigen Stelle !!!
Hallo Herbert
Hallo Paul-Adolf
Da bei mir das Phänomen
- erst seit etwa drei Monaten besteht,
- verschiedene Loks und Decoder betrifft
- und verschiedene Fahrstraßen betrifft,
- aber doch alle paar Minuten auftritt,
muss die Ursache eine andere sein, die ich noch nicht gefunden habe.
Hallo Friedel,
Halte uns bitte auf dem Laufenden.
Danke.
Hallo zusammen,
ich stelle dieses Phänomen auch sporadisch fest in jüngster Zeit. Zum einen bei einer neuen V160 die auf einen Faulhaber Motor umgebaut wurde und einen ESU Decoder hat. Die Lok wurde erst zuletzt eingemessen, fährt aber dennoch weiter über den Stoppunkt hinaus wie andere Loks (ca. 5-10 cm!)
Aber auch andere Loks halten nicht mehr immer so reproduzierbar wie früher.
Leider haben sich bei mir in letzter Zeit mehrere Parameter geändert, sodass ich alle Verdachtsmomente die hier in den Beiträgen geäußert wurden auch schon angestellt hatte.
Ich habe einen älteren Mofa-Rechner "geerbt" damit ich nicht immer mein Laptop an die Anlage karren muss. Dieser kann mit der Leistung des MAC-Book nicht mithalten, sollte aber auch nur für WDP bestimmt sein. Hat einen 1,3GHz-Zweikern Prozessor und 4 GB RAM.
Zeitgleich habe ich meinen CAN-Bus nicht unwesentlich erweitert und jetzt denke ich ebenfalls ob irgendwas nicht mehr mitkommt.
WDP Software ist auf aktuellstem Stand (WDP2015.2 Premium).
Gruß aus Wassenberg
Frank
Hallo Friedel,
ich bin nicht so der Computerfreak. Aber ich könnte mir vorstellen, daß ein PC nach längerem Betrieb durch etwa verbliebene Programmreste oder so, langsamer wird. Das wirkt sich dann auch bestimmt auf das Programm aus. Und was Windows mit den automatischen Updates soll alles anstellt, bleibt ja auch völlig im Dunkeln. Mir ist es jetzt passiert, daß durch das letzte Update mein PC (nicht der MoBa-Rechner) "struppelisch" wurde. Lt. PC-Händler sind wohl ältere Hardwareteile/Programme verändert worden, die sich nachteilig ausgewirkt haben. Kannst Du Dein Problem evtl. mit einem "jungfräulicheren" PC testen? Ich benutze z.Zt. meinen MoBa-Rechner als Büro-Rechner und habe keine Probleme mehr.
Hallo Peter
Ja, es ist manchmal schon nervig, wenn ein Rechner so ganz langsam aber anscheinend unvermeidlich in die Knie geht.
Das kann aber hier wirklich nicht der Grund sein, denn das Teil war vorher mein Hauptrechner im home-office und ist nach wie vor "rattenschnell". Andere Programme laufen wie geölt, dabei ist aber standardmäßig nur noch Bahnsoftware drauf.
Also - das kann sicher nicht der Grund sein, weshalb seit etwa 3-4 Monaten die Haltepunkte nicht mehr stimmen.
Hallo Zusammen - besonders die DCC Experten
Offensichtlich hat das Phänomen mehrere Ursachen wie ganz ordinär:
Mit zu hoher Geschwindigkeit ein kurzes iZNF anfahren - sowas in der Art. Und das betraf dann z. Bsp. MFX-Decoder, wodurch ich meinte, das Problem sei Decoder-unabhängig.
Jetzt habe ich aber offensichtlich den Haupt-Schuldigen gefunden, und der betrifft DCC-Decoder und evt. nur den von mir oft verbauten Uhlenbrock 76200:
Diese bin ich jahrelang mit 28 Fahrstufen gefahren.
Vor einigen Monaten habe ich sie alle auf 128 Fahrstufen umgestellt, nachdem Peter Ploch eine Möglichkeit zeigte, ganz schnell an der Tams MC die gewünschte Fahrstufe einstellen zu können ohne lange "Kurbelei".
Meine Überlegung war, dass WDP doch sowieso intern mit 128 Stufen rechnet und so eben nur genauer die gewünschte Geschwindigkeit einstellen können müsste.
Das scheint aber nicht der Fall zu sein.
Vielmehr scheint es notwendig zu sein, die betroffenen Loks neu einzumessen, denn plötzlich fahren sie signifikant schneller als vorher.
Frage an die Experten:
Warum ist das so? Wenn im Programm wie in der Mastercontrol auf 128 Fahrstufen umgestellt wird, müsste doch alles wieder gleich sein, oder nicht?
Aber damit nicht genug:
Wenn ich neu einmesse, entstehen ganz merkwürdige Messkurven:
Zuerst steigt die Kurve steil an und geht dann ab etwa Messpunkt 5 in eine Waagerechte über. Was soll denn das?
Vermutung:
Ich kann bei dem Decoder mit CV29 14 oder 28 Fahrstufen einstellen. Der Wert steht auf 28.
Die Beschreibung gibt an, dass der Decoder 14,27,28 und128 Fahrstufen können soll. Aber die 128 lassen sich nirgendwo programmieren. Woher weiß denn dann der Decoder, dass das Signal, das ihm die Tams sendet, 128 Fahrstufen betreffen soll statt 28?
Wer von Euch ist DCC-Experte, um so etwas zu beantworten.
Zusammengefasst also:
Die Loks fahren zu weit, weil ich einige DCC Decoder auf 128 Fahrstufen umgestellt hatte.
Aber warum wirkt sich das überhaupt aus?
Und wie kann man diese Auswirkungen in den Griff und eine vernünftige Messkurve bekommen?
Wer kann mir - und allen anderen! - da einen Rat geben?
Hallo Friedel,
ist in CV29 da Bit 4 auf 0 gesetzt, so dass die Geschwindigkeit durch CV2, CV5 und CV6 ermittelt wird?
Wurde der Decoder mit CV5 auf vmax eingestellt?
CV6 wird dann so eingestellt, dass man entweder eine Gerade Geschwindigkeitskurve bekommt, oder eine Kurve nach eigenen Wünschen. Ich bevorzuge die Gerade. Kann aber bei reinen Rangierloks mit einer Kurve, die im unteren Bereich feinfühliger verläuft optimiert werden.
Hallo Helmut
Alles: "Ja"
Hallo Friedel,
WDP rechnet intern mit 1.000 Fahrstufen! Mein Tipp: stelle es wieder um, wie es war.
Hallo Friedel,
Zitat von: Friedel Weber in 06. April 2017, 11:29:23
Frage an die Experten:
Warum ist das so? Wenn im Programm wie in der Mastercontrol auf 128 Fahrstufen umgestellt wird, müsste doch alles wieder gleich sein, oder nicht?
Win-Digipet spricht mit der Tams eh nur in 128 Fahrstufen. Die Runterskalierung auf 28 Fahrstufen macht die Tams intern. Die Einstellung in WDP ist für diese Zentrale nur relevant für das Übertragen der Fahrstufen-Konfig von WDP -> Tams um dort die Fahrstufen einzustellen.
In der DCC-Norm steht für die Umrechnung 128<->28 Fahrstufen: "In 128 speed step mode, the maximum restricted speed is scaled from 28 speed mode." Zu deutsch: die Höchstgeschwindigkeit muss bei 128 und 28 Fahrstufen gleich sein. Ich wäre davon ausgegangen, dass die Umrechnung für die Fahrstufen darunter auch linear erfolgt. Aber wenn ich mal so schaue in die Interface-Doku der diversen Hersteller, dann gibt es da schon unterschiedliche Formeln....
Wie sich das auswirkt habe ich selber aber keine Erfahrung, denn ich fahre in DCC immer schon mit 128 Fahrstufen und habe damit halt auch eingemessen.
Zitat von: Friedel Weber in 06. April 2017, 11:29:23
Aber damit nicht genug:
Wenn ich neu einmesse, entstehen ganz merkwürdige Messkurven:
Zuerst steigt die Kurve steil an und geht dann ab etwa Messpunkt 5 in eine Waagerechte über. Was soll denn das?
Schau mal hier (ich habe das auch schonmal anderswo gelesen meine ich):
http://www.railroad24.de/modelleisenbahn/forum.php?id=9990
und zwar in den zweiten Beitrag. Da behauptet ein User
Zitatdass bei den Uhlenbrock Decodern bei DCC 128 die Einstellungen von CV 5,6 nicht mehr greifen.Man müssteeine eigene Kennlinie über die CVs programmieren und die CV, die die max. Geschwindigkeit bestimmt, so einstellen, dass die Lok auch tatsächlich die gewünschte Geschwindigkeit erreicht.
Ob das stimmt? Keine Ahnung, hatte ich aber wie gesagt schonmal anderswo auch gehört. Wäre halt eine Erklärung.
Vielleicht probiert du einfach mal. In CV 29 fest auf die Kennlinien-Nutzung umschalten und dann schauen ob es bei DCC28 und 128 beim Einmessen gleich mies ist. Oder ändere mal die Kennlinie in CV67-94 ohne diese aber in CV29 einzuschalten und schaue mal ob die Messkurve bei DCC 128 sich ändert.
Zitat von: Friedel Weber in 06. April 2017, 11:29:23
Vermutung:
Ich kann bei dem Decoder mit CV29 14 oder 28 Fahrstufen einstellen. Der Wert steht auf 28.
Die Beschreibung gibt an, dass der Decoder 14,27,28 und128 Fahrstufen können soll. Aber die 128 lassen sich nirgendwo programmieren. Woher weiß denn dann der Decoder, dass das Signal, das ihm die Tams sendet, 128 Fahrstufen betreffen soll statt 28?
Wer von Euch ist DCC-Experte, um so etwas zu beantworten.
Die Umschaltung ist eigentlich nur wichtig zwischen DCC 14 und 28, denn die benutzen beide dasselbe DCC-Paket am Gleis und bei DCC 14 wird eines der Bits genutzt für F0 und bei DCC 28 um doppelt so viele Fahrstufen zu erhalten. Deswegen heißt bei der NMRA für das Bit auch eigentlich: "Bit 1 = FL location: "0" = bit 4 in Speed and Direction instructions control FL, "1" = bit 4 in function group one instruction controls FL. See RP-9.2.1 for more information." Die Umschaltung DCC14 Bit = 0 und DCC28 Bit =1 ist nur die verkürzte Darstellung.
Für DCC 128 braucht es so eine Umstellung nicht, denn da kommen andere DCC-Pakete an und der Dekoder erkennt schon am Befehlskenner, dass es 128 Fahrstufen sind.
Grüße
Markus
Hallo Friedel,
noch weiter gesucht:
http://www.tt-board.de/forum/archive/index.php/t-50762.html
Hier beschreiben Leute ähnliches.
Habe auch mal schnell mit einem Uhlenbrock-Dekoder aus einer Lok probiert. CV5 hatte da einen Einfluss auf die VMax bei DCC 28 und 128. CV 6 änderte die Mitten-Geschwindigkeit nur bei DCC28. Bei 128 hatte die CV 6 keinen Einfluss nach meinem Gefühl....
Grüße
Markus
Hallo Markus
Ich hatte ja gehofft, dass Du antworten würdest, denn danach ist meist alles klar.
Hier auch:
Es scheint also ein Fehler oder zumindest ein Problem bei den Uhlenbrock Decodern bei 128 Fahrstufen zu geben.
Wenn man das weiß, kann man sich ja darauf einstellen. Schließlich sind die 76200 bei mir alle 10-12 Jahre alt - da will ich mal nicht zu kritisch sein.
Ich habe daraufhin bei der Lok, wo mir das Problem deutlich auffiel, auf 28 Fahrstufen zurückgestellt, neu eingemessen und erhielt ein fast perfekte gerade Linie bis zur gewünschten Höchstgeschwindigkeit.
Fazit:
Ich werde jetzt alle Uhlenbrock Decoder wieder auf 28 Fahrstufen zurückstellen und die neueren Tams LD-G-32 auf 128 Stufen lassen.
Mal sehen, was dann passiert!
Es scheint mir aber fast, als sei mein Problem mit dem Zu-weit-fahren damit gelöst.
Danke an Alle, die sich Gedanken gemacht haben.
Hallo Friedel,
dass "Problem" habe ich ab und an. Warum auch immer.
Fahre ausschließlich mit ESU M4 Decoder der Generation 3 und 4.
Egal ob mit oder ohne Sound, es passiert.
Es gibt Tage, da fahren einige Loks 40 - 50 mm zu weit und an anderen
Tagen läuft wieder alles normal.
Es ist auch keine bestimmte Lok bzw. Decoder auszumachen die dies verursachen.
Ebenso, wechseln sich die Maschinen ab.
Nur bestimmte Gleishalteabschnitte gibt es auch keine, wo dieses Phänomen auftritt.
Der Rechner steuert unverändert seit über 5 Jahren die kleine Anlage.
Auch eine Rücksicherung bringt dabei keine Änderung ins Spiel.
Da ich auch nicht den Sonnenstand oder den Mond als Fehlerquelle ausmachen kann
bzw. konnte, bleibt mir das Ganze sehr rätselhaft.
Tante Edit:
Heute läuft z. B. alles normal, so wie es sein soll.
Hallo Zusammen
So, ich habe wohl Dank Markus' Hilfe die Ursache gefunden:
Es ist tatsächlich so, dass die bei mir noch verbliebenen Uhlenbrock Decoder vom Typ 76200 und 76420 einen Fehler aufweisen: Wenn man sie auf DCC128 einstellt, kennen sie keine Mittel-Geschwindigkeit mehr. Die Messkurve steigt steil an bis zum Messpunkt 7, der Höchstgeschwindigkeit und knickt dann waagerecht ab bis zum Messpunkt 14.
Das liegt offensichtlich nicht daran, dass der Mittelwert CV6 auf den Höchstwert CV5 gesetzt wird, denn das Phänomen passiert genauso, wenn man die "alternative Kennlinie" mit CV29 und den CV67-94 verwendet. Auch dann entsteht diese geknickte "Kurve".
Ich kann nicht sagen, ob in heutigen Versionen dieser Decoder der Fehler auch drin steckt. Auf jeden Fall findet so ein Abbremsen vor einem iZNF nicht mehr statt, die Loks rauschen mit hoher Fahrt dort hinein und kommen nicht mehr rechtzeitig zum Stehen.
Für mich gibt es jetzt zwei Lösungen:
1. Ich kann die Decoder rauswerfen und durch einen moderneren ersetzen. Sie sind bei mir ja auch schon alle recht alt. Nach meiner Kenntnis ist der 76200 aber der einzige Deoder, der die alten Märklin Allstrom-Motoren mit Lastregelung steuert. Ich müsste also auch gleich den Motor umbauen mit einem Magneten usw. Geht alles, kostet aber Zeit und Geld und verbessert nicht signifikant die Fahrleistungen.
Die 2. Möglichkeit ist einfach, den Decoder auf 28 Fahrstufen zurück zu setzen; damit ist er ja jahrelang ordentlich gelaufen.
Bei der Gelegenheit habe ich auch einige Loks neu eingemessen und festgestellt, dass sich die Messkurve in 5 Jahren praktisch nicht verändert hat.
So, und jetzt bin ich gespannt, ob der Fehler des Zu-weit-fahrens auch wirklich weg ist.
Guten Abend,
vielleicht kann ich zum Thema Uhlenbrock-Decoder noch etwas Erhellung beitragen.
Als ich vor zwei Jahren mit WDP anfing zu experimentieren, war ich von der Funktion, die Geschwindigkeit der Loks einzumessen total begeistert.
Zu diesem Zeitpunkt hatte ich nur zwei Loks mit Uhlenbrock-Decoder 76425.
Nach dem Aufnehmen der Messkurve war ich verwundert, dass die Messkurve nur bis zur Hälfte des 1. Quadranten anstieg und in der zweiten Hälfte konstant blieb. Das heisst, die Geschwindigkeit ist ab der 64. Fahrstufe konstant und somit die höchste Geschwindigkeit. Das Ergebnis widersprach aber Euren Darstellungen im Forum.
Auch die Programmierung mit einer eigenen Geschwindigkeitskurve brachte kein anderes Ergebnis.
Also meine Erkenntnis: ich zu blöd und das Ganze wiederholen. Es war immer Dasselbe.
Irgendwann habe ich den Support von Uhlenbrock angerufen und ihm versucht das Verhalten der Decoder zu erklären. Es hat eine Weile gedauert aber irgendwann hat er mir gebeichtet, dass die Decoder keine 128 Fahrstufen abarbeiten können.
Also habe ich im Lok-Control unter Fahreigenschaften den Regler für Höchstfahrstufe vor- und rückwärts von 128 auf 64 gestellt.
Jetzt bekommt man beim Einmessen der Loks den Anstieg der Geschwindigkeitskurve über den gesamten 1. Quadranten bis zur Höstgeschwindigkeit (Messpunkt 15).
Mit der Einstellung halten die Loks auch da wo sie sollen (jedenfalls bei mir).
Mit den neuen ESU-Decodern sieht die Kurve auch bei 128 Fahrstufen prima aus.
Es liegt also wirklich an den Decodern.
Grüße
Steffen