Hallo Miteinander, Ich brauche wieder einmal eure Hilfe.
Ich habe ein Roco-Triebfahrzeug VT628/VB628 von analog auf digital umgerüstet. Zur Anwendung kommt im Motorwagen ein ESU V4.0 DCC Plux22-Dekoder in Verbindung mit einer Adapterplatine sowie im Beiwagen ein Funktionsdekoder Tams FD-R Basic 2. programmiert habe ich eine lange Adresse (1628) sowie die Zuordnung der Funktionstaten F1/F2 zu den jeweiligen LED-Innenbeleuchtungen. Die Stirnbeleuchtungen erhielten ebenfalls LEDs und werden über F0 fahrtrichtungsabhängig geschaltet. Der Motor ist der alte Roco-Motor. Im Dekoder wurde der Analogbetrieb deaktiviert. Die Bestandsdrosseln habe ich nicht modifiziert.
Jetzt zu meinem eigentlichen Problem`chen: Auf der Gleisanlage reagiert der ESU V4.0-Dekoder sehr verzögert auf Kommandos. Es vergeht in der Regel zwischen 5 Sekunden und bis zu 30 Sekunden bis z.B. ein neuer Befehl übernommen und ausgeführt wird (Licht an/aus, Stopp oder Geschwindigkeitsänderung). Bei niedriger Fahrtgeschwindigkeit ist die Ausführungsverzögerung geringer.
Wenn ich das Triebfahrzeug auf den Rollenprüfstand stelle werden Kommandos sofort ausgeführt. Übrigens der TAMS-Funktionsdekoder arbeitet ohne Verzögerung.
Die Spannungsversorgung des Gleisboosters ist sowohl auf der Gleisanlage als auch auf dem Prüfstand identisch. Der Unterschied ist eigentlich nur, dass auf dem Prüfstand der Schleifer fest platziert ist.
Kann das von den beiden vorhandenen Original Motor-Entstördrosseln kommen, die in die beiden Motorleitungen des Dekoders angelötet sind, so dass der Dekoder mit der Entstörmaßnahme nicht klar kommt. Oder was könnte sonst noch die Ursache sein?
Ich habe das gleiche Modell vor länger Zeit auch umgebaut, ebenso auf LED und Sound ( D&H SD22 ). Ich habe die Drosseln entfernt ( mache ich übrigens immer ). Es gibt Decoder die empfindlich auf die Drosseln reagieren. Entferne sie und schaue wie der ESU reagiert.
Gruß Götz
Lenz DCC Version 3.6, Lenz USB/Ethernet-Interface, Traincontroller Gold 9.0 G3, Railcom mit Lenz LRC120 und Tams RCA-24/RCD-1 Rollmaterial: Roco, Fleischmann, Lima
dieses Verhalten habe ich schon öfter auf Modultreffen gehabt, mit verschiedenen Decodern. Meines Erachtens liegt es an der Qualität des DCC-Signals, diese wird durch Übergangswiderstände und die ganzen Modulverbindungskabel immer schlechter. Insofern würde ich vorschlagen, die Stromabnahme des Modells zu untersuchen, Radschleifer und Räder säubern, Verbindungen kontrollieren. Da kommen beim 628 insbesondere die Kontaktbleche vom Chassis zu den Drehgestellen in Frage. Diese nicht nur chemisch reinigen, sondern z.B. mit Politur Nagelfeilen wieder blank polieren, das Ganze beidseitig, also auch am Drehgestell machen. Das sind alles Verbindungen, die auf dem Prüfstand nicht bewegt werden, im Betrieb aber schon.
Edit: Zum weiteren Verbessern der Stromabnahme habe ich an meinem noch eine Achse ohne Haftreifen montiert. Bzw. später habe ich alles auf RP25 9mm Räder von Thomschke umgebaut. Vielleicht kommt ja das Entfernen der Haftreifen für dich auch in Frage.
die Frage wäre eigentlich besser im Unterforum Digital aufgehoben. Im September letzten Jahres hatte ich mich mit dem 628 eines Bekannten beschäftigt: VT628 Roco "Läuft nicht mehr richtig" Vielleicht kannst Du ja einiges von den Wartungsarbeiten und Reparaturen der Stromabnahmeschleifer verwenden.
Hallo Miteinander, erst einmal vielen Dank für Eure Antworten.
@Götz: Die Original-Drosseln habe ich mittlerweile entfernt. Ein erneuter Probelauf steht noch aus, weil ich das Triebfahrzeug noch einmal zerlegen musste.
@Björn: Die Stromaufnahme der Radschleifer habe ich im Vorfeld gereinigt und gerichtet, jedoch nicht blankpoliert. Der Schleifer ist neu. Da ja mein Beiwagen auch eine eigene Stromversorgung besitzt, werde ich provisorisch beide Baugruppen miteinander verbinden. Das geht ganz einfach, weil ich die Stromversorgung beider Fahrzeuge auf die ehemaligen Messingblechstangen der Beleuchtung im Dachbereich, zur besseren Stromversorgung vorzuhalten. Wenn das das Problem löst werde ich die Drähte zwischen den beiden Wagenverbindungensimitationen lösbar durchschleifen.
@Bernhard @Björn: Meine restlichen Triebfahrzeuge haben die beschriebene Datensignal-Thematik nicht und arbeiten alle Zuverlässig. Das gilt auch für die wenigen V4.0-Dekoder die ich besitze. Der Plux22 ist aber der Einzige den ich einsetze. Deshalb schließe ich erst einmal aus, dass es an der Qualität der Datensignale liegt. Da ich ja auf meiner Anlage Multikulti (DCC, m3, mm2) fahre, möchte ich jedoch Protokollkollisionen auf der Anlage nicht Vollständig, die ich bisher überhaupt nicht feststellen konnte, ausschließen.
@Ludwig: Den von Dir verlinkten Beitrag kenne ich. Dieser war auch der Grund warum ich die Drehgestelle ausgebaut, gereinigt und die Schleiferbleche neu justiert habe. Da ich keine leitenden Kupplungen nachrüsten wollte, habe ich Ersatzweise zur Stromversorgung über den Beiwagen die Dachverdrahtung an beiden Triebwagen eingebaut.
Ich werde mich melden sobald ich das Triebfahrzeug modifiziert und getestet habe. Gruß Michael
Ich habe am Fahrzeug folgende Punkte geändert: - Beide Bestandsdrosseln entfernt - Spannungsversorgung (Schleifer + Radkontakte) zwischen den beiden Fahrzeugen jeweils parallel verbunden - die Bestands-Klemmverbindung des Motors entfernt und den Motor direkt an den zugehörigen Polen angeschlossen.
Ergebnis: Solange die beiden Schleifer verbunden sind, reagiert der Motorwagen wesentlich schneller auf Befehle der Zentrale. Wenn ich testweise die Radmassenverbindung bei einem Betrieb mit zwei Schleifern auftrenne, kann ist keine Verschlechterung feststellbar. . Bei getrennten Schleifern und gemeinsamen Radmasseverbindung bleibt alles wie schon im Anfangsbeitrag #! beschrieben. Somit kann ich die Radkontakte wohl als Fehlerquelle ausschließen.
Weitere Vorgehensweise: Da auch bei doppelter Schleifer- und Masseverbindung Verzögerungen von 3-5 Sekunden habe bis eine Reaktion am Dekoder erfolgt, bin ich fasst der Meinung dass der Dekoder eine Macke hat. Ich werde diesen in den nächsten einmal testweise gegen ein anderes Fabrikat tauschen, der auf die verbaute Zubehörplatine gesteckt werden kann.
Besoners Problematisch ist die Spannungsversorgung im Einschleifermodus da werde ich noch Versuche mit anderen Schleifertypen durchführen, warte aber erst einmal ab, was der Dekodertausch bringt.
mal eine ganz dumme Frage: Sind bei Deinem 628 beide Motoranschlüsse isoliert? Machmal war bei Roco eine Büstenführung über die Messing U-Scheibe mit der Masse verbunden. Diese muß bei Umstellung auf Digital durch eine selbstgefertige aus isolierenden Material ersetzt werden.
Klemm mal den Decoder direkt ans Gleis mit Kroko-Klemmenkabel an. Der Mittelschleifer kann manchmal auch so seine Macken haben... Da Du auf K-Gleis unterwegs bist... . Ich habe mir für einen Freund neulich "den Wolf" gesucht, bis ich die Oxid-Schicht "unten drunter" gefunden hatte.
mal eine ganz dumme Frage: Sind bei Deinem 628 beide Motoranschlüsse isoliert? Machmal war bei Roco eine Büstenführung über die Messing U-Scheibe mit der Masse verbunden. Diese muß bei Umstellung auf Digital durch eine selbstgefertige aus isolierenden Material ersetzt werden.
Hallo Ludwig, Mein Motor hat bereits auf beiden Motorseiten werksseitig ein rotes Kunstoffteil aufgeklipst. Somit kann keine Masseverbindung bestehen. Gruß Michael
Hallo Miteinander, Mittlerweile habe ich folgendes ausprobiert:
1. den ESU V4.0DCC gehen einen Plux16-Uhlenbrock (76150) getauscht: identisches Verhalten wie schon in vorherigen Beiträgen geschrieben wie beim ESU V4.0DCC.
2. Uhlenbrockdekoder + neue Motordrosseln + Kondensator verbaut. Das Reaktionsverhalten des Decoders auf Befehle hat sich etwas verbessert. Nur minimale Verzögerung bei niedriger Geschwindigkeitseinstellung.
3. LED-Innenbeleuchtung (12V LED-Strips) am Dekoder abgeklemmt. Das Zeitverhalten bei hoher Geschwindigkeitseinstellung hat sich dadurch nicht verbessert. Bei Tams im Katalog habe ich gelesen, dass LED-Stipps die Übertragung von Digitalsignalen stören würde. Da ich ja diese nicht direkt von die Gleisspannung gespeist werden, sondern über die Decoderausgänge (blau/grün) dürfte das bei meiner Anschlussvariant nicht relevant sein.
4. Im Einschleiferbetrieb waren die Verzögerungen wesentlich größer (bis zu 15 Sekunden)
Leider kann ich keinen der beiden Dekoder in einer mit einer Plux22-Schnittstelle ausgerüsteten Lok einbauen um zu testen, ob das Fehlverhalten mitwandert. Ich bin mit meinem Latein am Ende. Mittlerweile glaube ich fast, dass es doch am ankommenden Digitalsignal liegen kann. Gibt es eine Möglichkeit das ohne viel Aufwand zu analysieren.
Einen letzten Versuch unternehme ich noch. Ich werde den aktuellen Multikultibetrieb, der bisher problemlos funktioniert hat, testweise auf reines DCC-Protokoll umstellen, da ich mittlerweile meine meisten Fahrzeuge auf DCC umgerüstet habe. Die wenigen mm/M3-Varianten nehme ich vom Gleis. Mal sehen ob es hilft.
die Einschränkung der Zentrale auf ein Protokoll kann helfen.
Mir ist erst später aufgefallen, dass du K-Gleis benutzt und da denkt man bei Schleifer natürlich erstmal an den zwischen den Rädern.
Ich weiß nicht ob das richtig angekommen ist, denn mir ging es um die Kontakte der Radschleifer, also des Massekontakts über die Räder selbst. Da gibt es einmal das Achslager, das sollte nicht zu ölig sein, denn das isoliert sonst. Weiterhin ging es mir um die Verbindung des Drehgestells zur restlichen Elektrik im Fahrzeug. Oben auf dem Drehgestell ist der Kontakt der Achslager zu sehen, der von einem Kontaktblech aus dem Fahrzeug berührt wird. Dort mal beide Seiten etwas polieren, das könnte helfen. Das Antriebsdrehgestell hat normale Radschleifer, die auf die Spurkränze wirken, auch diese reinigen und nachbiegen. Der kritische Punkt bei AC ist natürlich der Schleifer für die Punktkontakte, für diese Stelle gibt es nur einen Kontaktpunkt anstatt mehrerer Räder bei DC. Das kann ich mangels Erfahrung in dieser Richtung aber nicht so gut einschätzen.
Ich bin sehr gespannt wie das hier ausgeht, denn ich kenne das Problem wie gesagt von den äußeren Enden von Modulanlagen wo der nächste Booster eine ganze Ecke entfernt ist. Wir haben uns auf einem Treffen mal das DCC-Signal auf einem Oszilloskop angeschaut, dort kann man anhand der Flanken des Signals relativ gut sehen, wie gut die Übertragung ist. Ein Oszilloskop kostet heute auch nicht mehr die Welt, zumindest wenn es um so niedrige Frequenzen wie bei DCC geht. Hier beispielhaft ein günstiger Bausatz: https://www.amazon.de/DSO-Shell-Speicher...K/dp/B076HD5862 So ein Gerät nutze ich zu Hause für sowas, dafür ist es ausreichend. Natürlich kann es sich nicht mit einem Tektronix messen.
Hallo Bernhard, kein "Funkenflug" am Kollektor sichtbar. Auch die Kollektorkohlen sind nur minimal verbraucht und ordentlich eingeschliffen. Der Schleifer selbst ist fasst neu und die Pukos werden regelmäßig gereinigt und sind nicht oxidiert. So wie ich schon geschrieben habe, würde ich die Radkontakte inkl. Achslager als Fehlerquelle ausschließen. Die sind absolut sauber Diese habe ich im Zuge des Fahrzeugumbaus gereinigt. Auch habe ich keinerlei Unterschiede festgestellt wenn ich die Fahrzeugmassen einzeln oder als Parallelanschluss mit dem Beiwagen betrieben habe.
Danke für deine Unterstützung bei der Fehlersuche. Gruß Michael
ich glaube, Du solltest hier einmal aufräumen: Systemdaten: WDP 2018.2c; TAMS-MC, mehrere Booster BMBT-B3,0 zum Fahren, Central Unit 6021, Interface 6051 und Magnetartikeldecoder (LDT) zum schalten, Rückmelden S88-Module (LDT) über HSI-88USB (exDiCo). Zusätzliche S88-Module (Märklin) über 6051. Dekodermischbetrieb DCC, MM, mfx wird entsorgt Leitstand: Intel(R) CORE (TM)2, CPU 2,67GHz, 8GB RAM, WIN10Pro/64bit, 2-Bildschirme (22"/19"). Ethernet-Netzwerk für Videokamera und Laptop. Gleismaterial: K-Gleis Es ist durchaus im Beerich des Möglichen, daß da zu viel an Signalen in Deinem DCC Netz herumschwirren, es überfrachtet ist und es dadurch zu Verzögerungen kommt. Wie reagiert der Decoder des Fahrzeugs denn wenn er separat auf einem von der Anlage unabhängigen Testgleis von nur einer einzigen DCC Zentrale nur mit Fahrbefehlen gefüttert wird?
Hallo Miteinander, Vielen Dank für eure ausführlichen Beiträge.
@Ludwig, Mit Multikulti hatte ich bisher, seit mehr als 10 Jahren, als ich auf eine TamsMC umgestiegen bin, noch nie ein Problem. Auch an der Fahrstromversorgung hat sich seit 2009 nichts mehr geändert. Das einzige das sich verändert hat ist die Anzahl der Triebfahrzeuge zu Ungunsten MM bzw. M3. Über die TamsMC habe ich zurzeit „19x DCC-, 2x MM2-, 3 M3-Loks“ im Einsatz. Wobei die mm-Fahrzeuge im Schattenbahnhof auf abgeschalteten Stopp-Gleisen abgestellt sind. Das heisst aber nicht dass sich das nicht doch irgendwann auch auf die Kommunikation auswirkt. Im Beitrag #12 habe ich ja schon angedeutet, dass ich den Betrieb ausschließlich mit dem DCC-Protokoll testen will.
@Björn, Sorry, dass ich deine Antwort schlicht und einfach nicht bemerkt habe. Ein Problem einer schlechten Radmasseverbindung habe ich zuerst auch in der Verbindung des Drehgestelles zu den Kontaktblechen des Chassis gesehen. Die Radachsen habe ich in diesem Zuge ebenfalls gereinigt, die Radschleifer entsprechend neu ausgerichtet. Beim Mittelleiterschleifer des Motorwagens habe ich mittlerweile doch noch einen Fehler gefunden. Der angelötete Draht zum Schleifer war im Schleiferanschlusspunkt „kalt aufgelötet“. Nach Reparatur bekommt der Dekoder seinen Saft nur über den Schleifer des Motorwagens. Ich noch einmal alle Radachsen, Radschleifer, Drehgestelle und Kontaktbleche nachgeprüft und mit einem Silberschwamm nochmals poliert. Auch habe ich an beiden Wagenteilen den Masseanschluss parallel fest verdrahtet.
Die Ausführung der Kommandos, auch bei Höchstgeschwindigkeit ist jedenfalls so dass das überwiegend mit geringer Verzögerung erfolgt. Dann gibt es immer wieder Ausreiser, die bis 5 Sekunden verzögert ausgeführt werden.
H0-Modellbahnforum.de - das Forum mit der Forumbahn!
»
Technik und Steuerung von Fahrzeugen und Anlage
»
Fahrzeugumbauten und Eigenbauten
»
ESU-V4.0 DCC-Fahrzeugdekoder reagiert sehr verzögert auf Kommandobefehle
02.02.2020 16:59 (zuletzt bearbeitet: 02.02.2020 17:22)
Thema drucken
Antworten
outatime hat heute Geburtstag!
