Anzeige:
THEMA: Weichenschaltprobleme im Automatikbetrieb - Erklärung
THEMA: Weichenschaltprobleme im Automatikbetrieb - Erklärung
RhönbahNer - 15.07.25 07:45
Guten Morgen,
Gestern habe ich (hoffentlich) die Erklärung/Lösung für ein Problem gefunden, das mich schon recht lange beschäftigt und mich etliche graue Haare gekostet hat. Ich möchte es an dieser Stelle kurz vorstellen; vielleicht kann der eine oder andere Hobbykollege Nutzen daraus ziehen:
Die Konstellation:
Etwas größere Anlage, die über iTrain, ESU ECoS in Kombination mit ESU SwitchPilot 3 Servo und Peco-Weichen mit darin belassenen Weichenfedern mit Servoantrieb automatisch gesteuert werden soll. Die SwitchPiloten wählte ich deshalb aus, weil ich mir von ihnen ein problemloses Zusammenspiel mit der Zentrale versprach. Denkste…
Das Problem:
Bei der Wahl von Fahrstraßen kam es immer vor, daß vereinzelt Weichen nicht schalteten. Hierbei spielte es keine Rolle, ob eine Fahrstraße manuell an der Zentrale oder von iTrain automatisch gestellt wurde. Gemeinerweise gab es auch Fälle, in der die betreffendeFahrstraße korrekt schaltete. Betätigte ich die betreffende Weiche einzeln, funktionierte das Umschalten einwandfrei. Erste Vermutung: Versorgungsspannung am Weichendecoder. Angezeigt wurden am Decoder 13 V - nicht hoch, aber ausreichend: Eine probeweise Erhöhung auf 18 V schaffte keine Abhilfe.
(Meine) wahrscheinliche Erklärung:
Standardmäßig sind an der Zentrale (ESU ECoS) als Schaltzeit für eine Weiche 250 ms eingestellt. Dies ist für in der Regel ausreichend, wenn zwecks schnellen Durchschaltens einer Weichenstraße am Weichendecoder eine hohe Stellgeschwindigkeit eingestellt wird. Bei einzelnen Weichen hatte ich jedoch testweise die Geschwindigkeit reduziert. Dies ist l problemlos, wenn die betreffende Weiche einzeln (!) gestellt wird und geriet deshalb in Vergessenheit.
Beim Stellen mehrerer Weichen hintereinander scheint es nun offenbar so zu sein, daß der Weichendecoder einen Stellbefehl nicht speichert, sondern abbricht und ein Servo in dieser Stellung beläßt, sobald er einen neuen erhält. Dies führte dazu, daß die betreffenden, langsam laufenden Weichen nur bis kurz vor den Umschaltpunkt gestellt wurden und dann je nach Vorspannung der Feder in der Peco-Weiche umsprangen - oder eben nicht.
Nach dem Erhöhen der Umschaltzeit der Weiche in der Zentrale von 250 ms auf 500 ms funktioniert das Stellen der Weichenstraßen sowohl durch die ECoS selbst als auch mittels iTrain nun einwandfrei. Auch scheint iTrain nur eine Liste an Schaltbefehlen an die ECoS zu senden, welche letztere dann nach ihrem eigenen Tempo abarbeitet. (?)
Beim Stellen von Magnetartikeln (herkömmliche Doppelspulenantriebe) ist dieses Problem de facto aufgrund der hohen Stellgeschwindigkeit nicht existent, bei langsamlaufenden Servontrieben ist wohl ein sorgfältiges Abstimmen dieses Parameters mit der realen Geschwindigkeit der Antriebe selber erforderlich.
Was ist Eure Meinung bzw. Erfahrung zu dieser Thematik und speziell zu den ESU-Decodern?
Viele Grüße
Jürgen
Gestern habe ich (hoffentlich) die Erklärung/Lösung für ein Problem gefunden, das mich schon recht lange beschäftigt und mich etliche graue Haare gekostet hat. Ich möchte es an dieser Stelle kurz vorstellen; vielleicht kann der eine oder andere Hobbykollege Nutzen daraus ziehen:
Die Konstellation:
Etwas größere Anlage, die über iTrain, ESU ECoS in Kombination mit ESU SwitchPilot 3 Servo und Peco-Weichen mit darin belassenen Weichenfedern mit Servoantrieb automatisch gesteuert werden soll. Die SwitchPiloten wählte ich deshalb aus, weil ich mir von ihnen ein problemloses Zusammenspiel mit der Zentrale versprach. Denkste…
Das Problem:
Bei der Wahl von Fahrstraßen kam es immer vor, daß vereinzelt Weichen nicht schalteten. Hierbei spielte es keine Rolle, ob eine Fahrstraße manuell an der Zentrale oder von iTrain automatisch gestellt wurde. Gemeinerweise gab es auch Fälle, in der die betreffendeFahrstraße korrekt schaltete. Betätigte ich die betreffende Weiche einzeln, funktionierte das Umschalten einwandfrei. Erste Vermutung: Versorgungsspannung am Weichendecoder. Angezeigt wurden am Decoder 13 V - nicht hoch, aber ausreichend: Eine probeweise Erhöhung auf 18 V schaffte keine Abhilfe.
(Meine) wahrscheinliche Erklärung:
Standardmäßig sind an der Zentrale (ESU ECoS) als Schaltzeit für eine Weiche 250 ms eingestellt. Dies ist für in der Regel ausreichend, wenn zwecks schnellen Durchschaltens einer Weichenstraße am Weichendecoder eine hohe Stellgeschwindigkeit eingestellt wird. Bei einzelnen Weichen hatte ich jedoch testweise die Geschwindigkeit reduziert. Dies ist l problemlos, wenn die betreffende Weiche einzeln (!) gestellt wird und geriet deshalb in Vergessenheit.
Beim Stellen mehrerer Weichen hintereinander scheint es nun offenbar so zu sein, daß der Weichendecoder einen Stellbefehl nicht speichert, sondern abbricht und ein Servo in dieser Stellung beläßt, sobald er einen neuen erhält. Dies führte dazu, daß die betreffenden, langsam laufenden Weichen nur bis kurz vor den Umschaltpunkt gestellt wurden und dann je nach Vorspannung der Feder in der Peco-Weiche umsprangen - oder eben nicht.
Nach dem Erhöhen der Umschaltzeit der Weiche in der Zentrale von 250 ms auf 500 ms funktioniert das Stellen der Weichenstraßen sowohl durch die ECoS selbst als auch mittels iTrain nun einwandfrei. Auch scheint iTrain nur eine Liste an Schaltbefehlen an die ECoS zu senden, welche letztere dann nach ihrem eigenen Tempo abarbeitet. (?)
Beim Stellen von Magnetartikeln (herkömmliche Doppelspulenantriebe) ist dieses Problem de facto aufgrund der hohen Stellgeschwindigkeit nicht existent, bei langsamlaufenden Servontrieben ist wohl ein sorgfältiges Abstimmen dieses Parameters mit der realen Geschwindigkeit der Antriebe selber erforderlich.
Was ist Eure Meinung bzw. Erfahrung zu dieser Thematik und speziell zu den ESU-Decodern?
Viele Grüße
Jürgen
Ich habe dasselbe Problem mit Fahrstrassen in der Z21 App und meinen Kato Weichen. Irgendeine schaltet immer nicht und ich muss sie einzeln nachschalten - was dann auch problemlos geht.
Weder ein extra dickes, separates Netzteil noch die Verdoppelung der Impulszeit haben daran etwas geändert.
Das sind aber jetzt elektromagnetische Weichenantriebe, also etwas am Thema vorbei.
LG Mike
Weder ein extra dickes, separates Netzteil noch die Verdoppelung der Impulszeit haben daran etwas geändert.
Das sind aber jetzt elektromagnetische Weichenantriebe, also etwas am Thema vorbei.
LG Mike
RhönbahNer - 15.07.25 08:17
Hallo Mike,
ich kenne die Z21 (App) nicht. Lassen sich dort evtl. irgendwo Verzögerungszeiten ("Delay") einfügen?
Grüße, Jürgen
ich kenne die Z21 (App) nicht. Lassen sich dort evtl. irgendwo Verzögerungszeiten ("Delay") einfügen?
Grüße, Jürgen
Hallo Mike!
Drei Fahrstraßen, die jeweils aus zwei KATO-Weichen bestehen schalte ich auch mit der Z21-App. Die Weichen haben die gleiche Nummer bei mir!
Absolut problemlos, seit ca 3Jahren.
250mS bei 12 V, 3A Netzteil.
BG, Lutz!
Drei Fahrstraßen, die jeweils aus zwei KATO-Weichen bestehen schalte ich auch mit der Z21-App. Die Weichen haben die gleiche Nummer bei mir!
Absolut problemlos, seit ca 3Jahren.
250mS bei 12 V, 3A Netzteil.
BG, Lutz!
Hallo,
nicht vergessen, auch in iTrain die Schaltzeit erhöhen.
Viele Grüße
nicht vergessen, auch in iTrain die Schaltzeit erhöhen.
Viele Grüße
Hallo Lutz! - ich habe die Weichen mit verschiedenen Nummern programmiert, diese aber als "Fahrstrasse" mit dem entspechenden Symbol zusammengefügt. Wahrscheinlich ist Deine Lösung die bessere!
LG Mike
@ Jürgen: Delay: muss ich nachgucken!
LG Mike
@ Jürgen: Delay: muss ich nachgucken!
Hallo,
ich habe als Analogi jetzt ein kleines Verständnisproblem:
Da werden Servos benutzt zum Umlegen von Weichen, was an sich ja schon eine längere Umstelldauer bewirkt, dann wird aber die Schaltzeit für eine Weiche auf 250 ms (das ist ein Viertelsekunde, um es nochmal zu verdeutlichen!) gesetzt.
Irgendwie sehe ich da einen Widerspruch; ich hätte vermutet, dass die Schaltzeit da eher etwas höher (mindestens 2sec) sein sollte.
Oder ist der Servo in diesem Fall nicht zum langsamen Umlegen der Weiche da, sondern nur für eine kraftvolle (aber schnelle) Bewegung zuständig?
Neugierige Grüße
Michael
ich habe als Analogi jetzt ein kleines Verständnisproblem:
Da werden Servos benutzt zum Umlegen von Weichen, was an sich ja schon eine längere Umstelldauer bewirkt, dann wird aber die Schaltzeit für eine Weiche auf 250 ms (das ist ein Viertelsekunde, um es nochmal zu verdeutlichen!) gesetzt.
Irgendwie sehe ich da einen Widerspruch; ich hätte vermutet, dass die Schaltzeit da eher etwas höher (mindestens 2sec) sein sollte.
Oder ist der Servo in diesem Fall nicht zum langsamen Umlegen der Weiche da, sondern nur für eine kraftvolle (aber schnelle) Bewegung zuständig?
Neugierige Grüße
Michael
RhönbahNer - 15.07.25 10:49
Hallo Michael,
die relativ kurze Schaltzeit von 250 ms trägt dem teilweise historischen Umstand Rechnung, daß die damals fast ausschließlich verwendeten Magnetspulenantriebe sehr schnell schalten und teilweise keine eigene Endabschaltung besitzen. Auf diese Weise soll das Durchbrennen der Spulen verhindert werden; daher scheint dies aus Sicherheitsgründen die Voreinstellung vieler Zentralen zu sein.
Servos hingegen sind relativ langsam und brauchen mehr Zeit, um einen Stellvorgang abzuschließen. Damit gibt die Zentrale den Takt der Schaltbefehle und die theoretische (sic!) Zeitdauer der Fahrstraßenstellung vor. Die physische Stellzeit (also die Drehgeschwindigkeit des Servomotors und daher die reale Stellzeit) der Servos hingegen wird beim genannten ESU-Decoder im Decoder programmiert.
Das Problem scheint jetzt der Weichendecoder selbst zu sein bzw. die Art und Weise, wie er mit empfangenen Schaltbefehlen umgeht: Bei kurzen Schaltzeiten (250 ms) der Zentrale kommen die Schaltbefehle schneller, als der Decoder diese aufgrund seiner vom User programmierten Stellzeitvorgabe ausführen kann. Speichert er die Stellbefehle nun vorübergehend und arbeitet dann einen nach dem anderen nacheinander komplett ab, oder bricht er beim Empfang eines neuen Stellbefehles den vorhergehenden in der Servostellung ab, die es zu diesem Zeitpunkt hatte, also in irgendeiner Zwischenstellung des Servos?
Bei meinem ESU-Decoder habe ich das Gefühl, daß letzteres zutrifft. Ich habe den Fall auch bei ESU direkt als Frage eingespeist und bin neugierig, ob von dort meine Vermutung bestätigt wird.
Grüße, Jürgen
die relativ kurze Schaltzeit von 250 ms trägt dem teilweise historischen Umstand Rechnung, daß die damals fast ausschließlich verwendeten Magnetspulenantriebe sehr schnell schalten und teilweise keine eigene Endabschaltung besitzen. Auf diese Weise soll das Durchbrennen der Spulen verhindert werden; daher scheint dies aus Sicherheitsgründen die Voreinstellung vieler Zentralen zu sein.
Servos hingegen sind relativ langsam und brauchen mehr Zeit, um einen Stellvorgang abzuschließen. Damit gibt die Zentrale den Takt der Schaltbefehle und die theoretische (sic!) Zeitdauer der Fahrstraßenstellung vor. Die physische Stellzeit (also die Drehgeschwindigkeit des Servomotors und daher die reale Stellzeit) der Servos hingegen wird beim genannten ESU-Decoder im Decoder programmiert.
Das Problem scheint jetzt der Weichendecoder selbst zu sein bzw. die Art und Weise, wie er mit empfangenen Schaltbefehlen umgeht: Bei kurzen Schaltzeiten (250 ms) der Zentrale kommen die Schaltbefehle schneller, als der Decoder diese aufgrund seiner vom User programmierten Stellzeitvorgabe ausführen kann. Speichert er die Stellbefehle nun vorübergehend und arbeitet dann einen nach dem anderen nacheinander komplett ab, oder bricht er beim Empfang eines neuen Stellbefehles den vorhergehenden in der Servostellung ab, die es zu diesem Zeitpunkt hatte, also in irgendeiner Zwischenstellung des Servos?
Bei meinem ESU-Decoder habe ich das Gefühl, daß letzteres zutrifft. Ich habe den Fall auch bei ESU direkt als Frage eingespeist und bin neugierig, ob von dort meine Vermutung bestätigt wird.
Grüße, Jürgen
Hallo,
ich kenne das Problem auch, es tritt bei höherer DCC Last (Anzahl aller Befehle) verstärkt auf.
Hintergrund ist, das ein Decoder immer nur eine Aufgabe zur Zeit abwickeln kann, dieses verstärkt sich besonders durch die langsameren Servodecoder.
Ich habe damals DCC Fahren und Schalten getrennt. Auch würde das Aufteilen einer Weichenstrasse auf verschiedene Servodecoder helfen.
je nach Zentrale und PC-SW gibt es hier durchaus verschiedene Fehlerbilder.
gruss Hartmut
ich kenne das Problem auch, es tritt bei höherer DCC Last (Anzahl aller Befehle) verstärkt auf.
Hintergrund ist, das ein Decoder immer nur eine Aufgabe zur Zeit abwickeln kann, dieses verstärkt sich besonders durch die langsameren Servodecoder.
Ich habe damals DCC Fahren und Schalten getrennt. Auch würde das Aufteilen einer Weichenstrasse auf verschiedene Servodecoder helfen.
je nach Zentrale und PC-SW gibt es hier durchaus verschiedene Fehlerbilder.
gruss Hartmut
Hallo und Danke für die Antworten!
Mir ist schon bekannt, dass so eine kurze Schaltzeit für Magnetantriebe sinnvoll ist (auch warum.png)
). Hier geht es aber um prinzipiell langsame Antriebe mit einem Motor. Und da wundert mich eben, warum man so kurze Schaltzeiten verwendet; ein Motor kommt da ja kaum mit.
Zum Dekoder an sich:
Ich hätte jetzt nicht gedacht, dass die Schaltdekoder "so schlecht" sind und die Befehle nicht in einer Pipeline puffern! Ich hätte eher erwartet, dass zumindest so viele Pufferplätze vorhanden sind wie schaltbare Ausgänge, also wenn ein Dekoder 8 Ausgänge (egal welcher Art) verwalten kann, sollte er doch auch mindestens 8 Befehle bis zu deren vollständiger Abarbeitung puffern können. Denn theoretisch könnten ja tatsächlich 8 Schaltbefehle nacheinander für diesen Dekoder (eben einer für jeden Ausgang) über die Leitung kommen. Klar muss dann geprüft werden, ob ein Befehl schon in der Pipeline ist; dann kann der wiederholte Befehl verworfen werden (Pipelinemanagement). Aber einen in der Ausführung begriffenen Befehl abzubrechen, nur weil ein anderer Befehl für einen anderen Ausgang auf diesem Dekoder kommt? Sowas geht ja eigentlich garnicht... Übertragt so ein Verhalten mal auf ein Auto -- huh!
Überspitzt: "Bremsen abbrechen, statt dessen hupen"
Jedenfalls danke für die Erlärung
Michael
Mir ist schon bekannt, dass so eine kurze Schaltzeit für Magnetantriebe sinnvoll ist (auch warum
). Hier geht es aber um prinzipiell langsame Antriebe mit einem Motor. Und da wundert mich eben, warum man so kurze Schaltzeiten verwendet; ein Motor kommt da ja kaum mit.Zum Dekoder an sich:
Ich hätte jetzt nicht gedacht, dass die Schaltdekoder "so schlecht" sind und die Befehle nicht in einer Pipeline puffern! Ich hätte eher erwartet, dass zumindest so viele Pufferplätze vorhanden sind wie schaltbare Ausgänge, also wenn ein Dekoder 8 Ausgänge (egal welcher Art) verwalten kann, sollte er doch auch mindestens 8 Befehle bis zu deren vollständiger Abarbeitung puffern können. Denn theoretisch könnten ja tatsächlich 8 Schaltbefehle nacheinander für diesen Dekoder (eben einer für jeden Ausgang) über die Leitung kommen. Klar muss dann geprüft werden, ob ein Befehl schon in der Pipeline ist; dann kann der wiederholte Befehl verworfen werden (Pipelinemanagement). Aber einen in der Ausführung begriffenen Befehl abzubrechen, nur weil ein anderer Befehl für einen anderen Ausgang auf diesem Dekoder kommt? Sowas geht ja eigentlich garnicht... Übertragt so ein Verhalten mal auf ein Auto -- huh!
Überspitzt: "Bremsen abbrechen, statt dessen hupen" Jedenfalls danke für die Erlärung
Michael
Hi Folks,
interessantes Thema.
Könnte das evtl. auch auf motorische Antriebe, wie von mtb die MP-Reihe, zutreffen?
Noch habe ich die Antriebe und Decoder (Digikeijs DR 4018) nicht in der Amnlage verbaut. Ein Versuchsaufbau mit zwei Weichen und MP1-Antrieben (ja - ist lächerlich) hat bei Fahrstrassenschaltung einwandfrei funktioniert.
Der Vorschlag
könnte ggf. auch hier greifen, um Problemen vorzubeugen. Ein Punkt, den man bei der Planung der Beschaltung viellecht berücksichtigen sollte.
Gruß aus Nordertown
interessantes Thema.
Könnte das evtl. auch auf motorische Antriebe, wie von mtb die MP-Reihe, zutreffen?
Noch habe ich die Antriebe und Decoder (Digikeijs DR 4018) nicht in der Amnlage verbaut. Ein Versuchsaufbau mit zwei Weichen und MP1-Antrieben (ja - ist lächerlich) hat bei Fahrstrassenschaltung einwandfrei funktioniert.
Der Vorschlag
Zitat - Antwort-Nr.: | Name:
Auch würde das Aufteilen einer Weichenstrasse auf verschiedene Servodecoder helfen.
Gruß aus Nordertown
RhönbahNer - 15.07.25 12:09
Zitat - Antwort-Nr.: | Name:
Ich hätte jetzt nicht gedacht, dass die Schaltdekoder "so schlecht" sind und die Befehle nicht in einer Pipeline puffern!
Hallo Michael,
ob das tatsächlich so ist, weiß ich wie gesagt nicht, ich möchte hier nichts unterstellen! Meine Beobachtungen gestern deuten für mich zwar darauf hin, aber es könnte bei einem derart komplexen Fehlerbild durchaus noch andere, hier nicht bedachte Aspekte geben. Mal abwarten, ob bzw. wie ESU sich dazu äußert.
Grüße, Jürgen
RhönbahNer - 15.07.25 12:12
Hallo Exitus,
wenn es sich so verhält wie von mir vermutet, könnten prinzipiell davon auch andere motorische und damit "langsame" Antriebe betroffen sein. Es wäre in diesem Zusammenhang interessant zu erfahren, wie Decoder anderer Anbieter in dieser Situation reagieren. Ich kann diesbezüglich leider nur hinsichtlich ESU mitreden.
Ein Aufteilen einer Fahtrstraße auf verschiedene Decoder ist wohl nur bedingt möglich, da sich die anzusteuernden Weichen je nach Fahrstraße ändern.
Grüße, Jürgen
wenn es sich so verhält wie von mir vermutet, könnten prinzipiell davon auch andere motorische und damit "langsame" Antriebe betroffen sein. Es wäre in diesem Zusammenhang interessant zu erfahren, wie Decoder anderer Anbieter in dieser Situation reagieren. Ich kann diesbezüglich leider nur hinsichtlich ESU mitreden.
Ein Aufteilen einer Fahtrstraße auf verschiedene Decoder ist wohl nur bedingt möglich, da sich die anzusteuernden Weichen je nach Fahrstraße ändern.
Grüße, Jürgen
Zitat - Antwort-Nr.: | Name:
Ein Aufteilen einer Fahtrstraße auf verschiedene Decoder ist wohl nur bedingt möglich, da sich die anzusteuernden Weichen je nach Fahrstraße ändern.
Wenn man darauf achtet, bei der Verdrahtung der Antriebe nicht zu viele in einer möglichen logischen Reihenfolge gemeinsam an einen Decoder zu hängen, sondern auf mehrere Decoder zu verteilen, wäre es schon etwas entschärft.
Ist natürlich auch ein kleines logistisches Puzzle, das man damit auf dem Zettel hat
Gruß aus Nordertown
Hallo,
weil die MTP MP Weichenantriebe oben erwähnt wurden. Von MTP gibt es die DP-Serie mit integrierten Decoder.
Da stellt sich nun die Frage, ob der Einsatz der DP einer Aufteilung in einer Fahrstraße entsrechen würde?
VG
Martin
PS: Von einem tschechischen Händler werden DCC Einzel-Decoder für Servos angeboten
https://www.espb.cz/peli-msd1a03
Ebenso gibt es dort die Möglichkeit MP-Antriebe mit DCC-Einzeldecoder nachzurüsten.
https://www.espb.cz/peli-trd1a02
weil die MTP MP Weichenantriebe oben erwähnt wurden. Von MTP gibt es die DP-Serie mit integrierten Decoder.
Da stellt sich nun die Frage, ob der Einsatz der DP einer Aufteilung in einer Fahrstraße entsrechen würde?
VG
Martin
PS: Von einem tschechischen Händler werden DCC Einzel-Decoder für Servos angeboten
https://www.espb.cz/peli-msd1a03
Ebenso gibt es dort die Möglichkeit MP-Antriebe mit DCC-Einzeldecoder nachzurüsten.
https://www.espb.cz/peli-trd1a02
Beitrag editiert am 15. 07. 2025 13:43.
Ich würde mal behaupten: ja.
Durch die eigene Ansprache ist er nur für sich selbst verantwortlich und kann den Befehl "in aller Ruhe" abarbeiten. Die anderen Befehle der Fahrstraße gehen ihn ja nichts an.
Nach dem Motto " Was schert mich das Geschrei (Befehl) vom Nachbarn".😜
Gruß aus Nordertown
Durch die eigene Ansprache ist er nur für sich selbst verantwortlich und kann den Befehl "in aller Ruhe" abarbeiten. Die anderen Befehle der Fahrstraße gehen ihn ja nichts an.
Nach dem Motto " Was schert mich das Geschrei (Befehl) vom Nachbarn".😜
Gruß aus Nordertown
RhönbahNer - 15.07.25 14:22
Ich werde versuchen, am Wochenende die Zeit zu finden, mir den Servoausgang des Decoders mit dem Oszilloskop bei verschiedenen Schaltzeiten und Servogeschwindigkeiten anzusehen, um die Theorie damit vielleicht erhärten zu können.
Hoffen wir mal, daß Murphy hier nicht mitliest...
Grüße, Jürgen
Edit: Ein anderer Gedanke, der mir gerade durch den Kopf geht: Man kann diesen Decoder so programmieren, daß er nach dem Stellvorgang das Servo abschaltet, um Brummen zu vermeiden. Auch diese Einstellung könnte ggf. dazwischenfunken, wenn der Stellvorgang noch nicht beendet ist... Ich muß darauf mal achten.
Hoffen wir mal, daß Murphy hier nicht mitliest...
Grüße, Jürgen
Edit: Ein anderer Gedanke, der mir gerade durch den Kopf geht: Man kann diesen Decoder so programmieren, daß er nach dem Stellvorgang das Servo abschaltet, um Brummen zu vermeiden. Auch diese Einstellung könnte ggf. dazwischenfunken, wenn der Stellvorgang noch nicht beendet ist... Ich muß darauf mal achten.
Beitrag editiert am 15. 07. 2025 14:29.
Nur registrierte und eingeloggte User können Antworten schreiben.
Einloggen ->
Noch nicht registriert? Hier können Sie Ihren kostenlosen Account anlegen: Neuer N-Liste Account
Zum Seitenanfang
© by 1zu160.net;