Hallo Marko,
ich nehme mal an, dass Du dich auf dem Schaltplan beziehst, den ich oben zusammen mit dem Sketch eingestellt habe.
Wie Thomas ja schon geschrieben hat, gibt es bei der PoM Programmierung keine Rückmeldung. Damit kannst Du eigentlich alles, was an D4 ( Pin 7 ) hängt weglassen.
Der Sketch ist derzeit so ausgelegt, dass zur PoM Programmierung der Schalter beim Hochlauf geschlossen sein muss. Wie Thomas schon schrieb, ist das aber reine Softwaresache. Ich habe das gemacht, damit alle Decoder die gleich PoM-Adresse zur Programmierung verwenden können, da ja nur der mit dem geschlossenen Schalter auf die Programmierbefehle reagiert. Ohne den Schalter ( und entsprechende Softwareänderung ) bräuchte jeder Decoder eine eigene Adresse.

Hallo zusammen,

vielen Dank für die Rückmeldungen. Zum Schaltplan - es ist der in Franz-Peter's Post eingefügte Plan, wo die komplette Beschallung des Arduino mit beiden Optokopplern und besagtem Programmierschalter zu sehen ist.
Ich persönlich benötige den Programmierschalter nicht, da ich jedem Decoder eine eigene POM Adresse verpassen möchte (jeder Gang unter die Anlage, der vermieden werden kann, ist gut.
Dennoch glaube ich, dass dieser Schalter für viele Andere sinnvoll sein kann - von daher sollte der Sketch den Schalter auch weiter abfragen. Da hier aber kein "normaler" Eingang des Arduino belegt ist, fehlt mir noch ein wenig Verständnis, wo im Sketch sich diese Abfrage deaktivieren lässt - hier wäre ein entsprechender Hinweis super.
Dann noch vielen Dank für die POM-Details - dann sollte das so alles gut funktionieren und ich mache mal weiter mit dem Basteln und testen.

Vielen Dank und Grüße

Marko

Hallo Marko,

die Emtscheidung ob mit oder ohne PoM fällt ganz am Anfang des Setup-Programms:

    if ( digitalRead( progPin) == LOW ) 
        progMode = ADDRMODE;
    else
        progMode = NORMALMODE;
 

Wenn Du die ganze Abfrage weglässt, und stattdessen nur

      progMode = ADDRMODE;
 

stehen lässt, ist der PoM Mode immer aktiviert.

Da ich jetzt erst auf diesen tollen Thread gestoßen bin, sei erstmal ein großes Danke für die bisher getane Arbeit ausgesprochen. Deine Sourcen lassen sich wunderbar nachvollziehen. Wenn ich mal wieder etwas Luft habe, werde ich das Ganze mal selber ausprobieren.

Eine Idee hätte ich diesbezüglich noch, eventuell weiß da ja schon einer von euch bescheid: Lässt sich eine Rückmeldung der Weichenlage für zum Beispiel Computergesteuerte Anlagen geben? Dies wäre meiner Meinung nach ein interessantes Feature. Realisierbar zB über Endlagenschalter am Servo und um genügend Pins zu haben wären nur 4 Weichen pro Arduino Nano anzuschließen.

Hallo zusammen,

Heute konnte ich endlich mal ein Setup aufbauen, welches Hardwareseitig funktionieren sollte. Ich habe es mit der Urversion des DCC Servodecoders erfolgreich getestet. Nun wollte ich mich an die Programmierung per CV setzen, was aber noch nicht so erfolgreich funktionierte, da ich schon vorher gestrandet bin.
Ich habe im Sketch erst einmal nur in Zeile 52 die DCC Adresse und in Zeile 53 die POM Adresse auf 20 gesetzt. Was ich aber noch nicht verstanden habe - welche Adresse gebe ich nun den einzelnen Schaltartikel in meiner Zentrale, wenn ich an D7 und D9 des Arduinos jeweils einen Servo angeschlossen habe? Hättet Ihr dort bitte noch einmal einen kleinen Hinweis?

Danke und Grüße

Marko

Hallo Marko,
Die 1. Zubehör(Weichen-)adresse des Decoders berechnet sich entsprechend der NMRA nach folgender Formel:
WeichenAdresse = (Decoderaddresse-1) * 4 + 1
Auf dieser Seite findest Du im Abschnitt "CV-Variablen für Zubehör Decoder" eine kleine aktive Tabelle, mit der Du die Zubehöradresse aus der Weichenadresse berechnen kannst. Decoderadresse eingeben, auf 'Calculate' klicken, und du erhältst die CV-Werte für die Decoderadresse und die zugehörigen Weichenadressen. Bei unserem Decoder sind es allerdings nicht 4, sondern 8 Weichenadressen, also da einfach weiterzählen.
In deinem Beispiel mit Decoderaddresse 20 kommst Du damit auf die Weichenaddressen ab 77.
Da Pin 9 und 7 der 3. und 4. Weiche des Decoders zugeordnet sind, sind das also die Addressen 79 und 80.

Übrigens noch eine Korrektur zu meinem letzten Post. Ich hatte nicht daran gedacht, dass der Programmierschalter nicht nur die PoM-Addressierung aktiviert, sondern damit auch die Decoderaddresse durch das erste empfangene Weichentelegramm festgelegt wird. Wenn Du diesen Modus also fest einschaltest, würde sich nach jedem Programmstart die Decoderadresse an das erste Weichentelegramm anpassen - was Du ja sicher nicht willst.
Um das zu verhindern, must Du die oben angegebene Zeile progMode = ADDRMODE; ändern in

progMode = PROGMODE;
 

Dann gibt es keine Addressauswertung.

P.S. Die Zubehördecoderaddresse und die PoM Adresse haben nicht direkt etwas miteinander zu tun, und müssten auch nicht gleich sein. Die PoM-Adresse ist ja eine Lok-Addresse. Du must auch darauf achten, dass nicht eine Lok mit der gleichen Addresse existiert und parallel von der Zentrale angesprochen wird - die ändert ihre CV's dann nämlich auch.

Hallo Phillip,
danke für's Lob

Zu deiner Idee mit der Rückmeldung: Eingänge für solche Endschalter liessen sich sicher leicht einbauen und abfragen. Aber wie stellst Du dir die Rückmeldung an die Zentrale vor?

Hallo Franz-Peter,

sehr gerne, denn Ehre, wem Ehre gebührt

Die Realisierung der Rückmeldung ist leider genau die Frage, die sich stellt. Es ist gut möglich, dass mir mein Gedächtnis da auch einfach einen Streich gespielt hat, weil schon einige Zeit seit dem letzten Lesen vergangen ist. Kurzes nachschauen hat mich zum Beispiel auf die Lösung von OpenDCC gebracht. Dort wird von der Zentrale ein Schaltbefehl und ein Ausschaltbefehl gesendet. Nach diesem erwartet die Zentrale ein Ack Signal und meldet dies an die Software per S88 Bus. Vermutlich ist dies aber eine proprietäre Lösung und nicht vom DCC Standard abgedeckt. So erscheint es einfacher, zusätzlich zum Weichendekoder noch einen S88 Melder einzusetzen, der die entsprechenden Schaltsignale erhält.

Hallo Franz-Peter,

Vielen Dank für die Hinweise. Irgendwo passt das bei mir aber trotzdem noch nicht. Ich habe den Sketch noch einmal komplett unverändert gelassen und bei meiner Zentrale die Schaltartikel mit Adresse 3 und 4 programmiert, da die DCC Adresse im Sketch ja ursprünglich auf 1 steht.
Allerdings bewegen sich die Servos nicht. Wenn ich auf den Arduino den Ursketch des DCC Servodecoders übertrage und dort dann den Schaltartikel im Sketch ebenfalls die Adressen 3 und 4 zuordnen, funktionieren die Servus beim Schalten über die Zentrale.
Wie beschrieben, der Sketch ist 1:1 ohne Änderungen übernommen und die Signale werden einwandfrei empfangen und über den UrSketch auch korrekt verarbeitet.
Da ich schon so nah am Anfang scheiterte fällt es mir auch schwer einen möglichen Fehler weiter einzukreisen, daher weitere Hinweise jederzeit gerne
Viele Grüße

Marko

Hallo Marko,
könnte es sein, dass deine Zentrale die Weichenadressen nach Roco-Standard berechnet? Das ist nämlich der Unterschied zwischen dem Ur-Weichendecoder und dem neuen Zubehördecoder. Bei Roco sind die Weichenadressen jeweils um 4 höher als im Standard.
Im Sketch umschaltbar ist das mit der Konstante 'isROCO'. Für die Roco-Adressierung muss diese Variable auf '4' gesetzt werden.

Hallo Phillip,
eine Rückmeldung über S88-Bus dürfte vermutlich die einfachste und 'standardkonforme' Lösung sein.

Hallo Franz-Peter,

Die ECOS verwendet nicht das ROCO Format, habe es aber dennoch einmal ausprobiert. Leider bleibt der Erfolg noch aus. Ich werde zum WE noch einmal einen Aufbau auf dem Steckbrett versuchen, da kann ich dann auch noch etwas mehr rumexperimentieren als bei meinem festen Aufbau. Wenn es bis dahin weitere Ansatzpunkte gibt - immer gerne her damit

Viele Grüße

Marko

Hallo Marko,
hast Du schonmal die Debug-Funktion eingeschaltet? Dann bekommst Du auf dem Arduino-Terminal u.A. Informationen über die empfangenen Telegramme.

Noch ein paar Zusatzinfo's: Die CV-Werte werden nicht zurückgesetzt, wenn eine neue Programmvariante auf den Arduino geladen wird. D.h. es reicht NICHT, im Programm die Konstante DccAddr bzw. PomAddr zu ändern und das Programm neu zu laden. Wenn bereits gültige CV-Werte vorhanden sind, bewirkt das nichts.
Um die CV-Werte wieder auf die im Programmcode hinterlegten Werte zu setzen, muss ein Reset-Telegramm empfangen werden, oder der CV47 muss auf 'ungültig' - z.B. auf 0 - gesetzt werden. Dann werden beim nächsten Programmstart wieder die Init-Werte aus dem Programmcode übernommen.

Ist der Debug-Mode aktiv, wird beim Programmstart auch die Adresse ausgegeben, auf die der Decoder reagiert. (Terminal in der IDE auf 115200 Baud setzen)

Hallo Franz-Peter,

vielen Dank für die Hinweise. Bin jetzt 2 Tage beruflich unterwegs, aber zum WE werde ich dann mal in die Debug-Welten eintauchen[emoji1]

Viele Grüße

Marko

Hallo zusammen,

so, Fortschritte sind in Sicht. Die generelle Funktionslosigkeit beruhte auf nicht korrekten Adressen im Decoder. Der Hinweis, dass bei Neuprogrammierung besehende CV Werte erhalten und gültig bleiben, war Gold wert.
Da ich die Schaltung ja nur mit dem für das DCC-Signal verantwortlichen Optokoppler betreibe und auch auf den Programmierschalter verzichte, habe ich durch eine Veränderung im Sketch, wie von Franz-Peter beschrieben (progMode = ADDRMODE) eine neue Adresse schreiben können und konnte somit auch die angeschlossen Servos von der Zentrale aus steuern.
Der nächste Schritt sollte dann die Veränderung von Drehwinkel und Drehgeschwindigkeit über das Setzen der entsprechenden CVs über POM werden. Da ich mir nicht sicher war, wie ich außer im Sketch die POM Adresse verändern kann, habe ich einen komplett neuen Arduino beschrieben und dabei im Sketch die Adresse 20 (also dann bei meinem Aufbau Schaltartikeladressen 79 & 80 in der Zentrale), sowie die POM Adresse 50 verwendet.
Die Servos ließen sich dann auch sofort entsprechend ansteuern, nur die Programmierung über POM funktioniert nicht. Da ich die Schaltartikeladressen 79 & 80 verwende müssten ja die entsprechend zu verändernden CVs 58-61 für Adresse 79, sowie 62-65 für Adresse 80 sein. Im Sketch hatte ich dann auch noch das o.g progMODE = PROGMODE gesetzt und den Arduino damit neu beschrieben.
Also - generell funktionieren tut es, nur für Hinweise zum Schrein der CVs im POM Mode, sowie das Verändern der POM Adresse wäre ich sehr dankbar.

Danke vorab und viele Grüße

Marko

Hallo an alle hier, vor allem Franz-Peter,

ich bin sehr begeistert von den Mobatools, diesem Thema und den vorgestellten Arbeiten. Deshalb eine Frage an alle, die sich mit der Beschaltung des DCC Einganges beschäftigt haben: Ich sehe, dass der Enable-Eingang des 6N137 in verschiedenen Schaltungsvarianten immer mit einem 10k-Widerstand an VCC geschaltet wird. Lt. Datenblatt hat dieser Eingang einen internen Pull-up, könnte also auch freigelassen werden. OK, sicherer ist ihn auf High zu legen, aber warum nicht direkt? OK, ein Widerstand frisst kein Brot, aber wenn mans nicht braucht?

Vielen Dank für alles gezeigte,

Hallo noch einmal,

Eines ist mir beim Probieren noch aufgefallen: Beim Einschalten bewegen sich die Servos sehr stark und unkontrolliert. Lässt sich das noch unterdrücken?

Viele Grüße

Marko

Hallo Franz,
willkommen bei den MobaTools . Das freut mich, wenn dir das Thema gefällt, und Du damit etwas anfangen kannst - dafür ist es gemacht.

Was die Beschaltung des Enable-Eingangs angeht hast Du eigentlich recht. Offen lassen oder direkt an Vcc wäre vollkommen ok. Das ist sicher einfach ein kopier-Problem: Irgendwann hat einer mal den Widerstand eingebaut und alle haben es so kopiert - funktioniert hat es ja und so hat das bisher keiner hinterfragt

Hallo Marko,
hast Du den schon mal die Debug-Funktion aktiviert? Du bekommst dann ja auch bei der PoM-Programmmierung Ausgaben, welche CV-Werte verändert werden und Du siehst, ob der Decoder überhaupt auf den PoM-Befehl reagiert. Ist es ein CV-Wert für die Servo-Endlagen wird auch ausgegeben welche Position verändert wurde. Das sieht dann z.B. so aus:

Dbg: neu: CV60=161
Dbg: Ausg.2 , Pos. 1 neu einstellen
Dbg: neu: CV68=161
Dbg: neu: CV61=170
Dbg: neu: CV61=29
Dbg: neu: CV60=68
Dbg: Ausg.2 , Pos. 1 neu einstellen
Dbg: neu: CV60=102
Dbg: Ausg.2 , Pos. 1 neu einstellen
Dbg: neu: CV64=148
Dbg: neu: CV63=56
Dbg: Ausg.3 , Pos. 0 neu einstellen
 
 

Deine Berechnungen der CV-Werte sind in Ordnung.
Die PoM-Adresse selbst steht in CV 48 (lowByte) und CV49 (highByte). Die kann man aber eigentlich sinnvoll nur im Programmiergleis-Modus verändern - der ist auch immer aktiv. Nur weis ich nicht, ob deine Zentrale das kann, wenn es keine Rückmeldung gibt ( da Du ja die Rückmelde-HW nicht eingebaut hast ).

Zu den Bewegungen der Servo's beim EInschalten:

Da ist zum einen das 'Zucken' der Servo's bei Einschalten der Versorgungsspannung. Da verhalten sich die Servos sehr unterschiedlich - am geringsten oder sogar nicht vorhanden ist es bei digitalen Servos. Je nach Servo ist es wohl auch besser, ob zum Einschaltzeitpunkt der Versorgung bereits ein Impulssignal anliegt oder nicht. Im Sketch ist da bisher nichts vorgesehen - man müsste dann u.U. auch die Versorgungsspannung der Servo's über den Sketch einschalten.

Des weiteren gibt es normalerweise auch noch eine schnelle Bewegung beim ersten Umschalten. Da wüsste ich aber jetzt noch nicht, wie man das unterbinden kann. Es liegt daran, dass das Programm beim ersten Ansteuern des Servos nicht weis, wo der Servo steht. Programmintern stehen alle Servos nach dem einschalten erstmal in der 'Ruhelage'. Wenn das aber nicht mit der tatsächlichen Position des Servos übereinstimmt, kommt es bei der ersten Ansteuerung zu einer schnellen Bewegung des Servos in eben diese Ruhelage bevor dann die langsame Bewegung beginnt.

Hallo Marko, noch ein paar Gedanken zu deiner Version:
Da Du weder den Programmierschalter, noch die Programmiergleis-Programmierung haben möchtest, hast Du eigentlich beide Wege, über die die Decoderaddresse eingestellt werden kann, abgeschaltet. Die PoM-Programmierung ist ja genau NICHT dafür geeignet, die Decoderaddresse zu verändern.
Deshalb wäre es in deinem Fall wohl besser, zumindest die Werte DccAddr und PomAddr bei jedem Programmstart in die entsprechenden CV's zu schreiben. Du müsstest zwar dann für jeden Decoder vor dem Laden des Programms den Sketch anpassen, aber einen Tod muss man halt sterben

Marko, hast Du eigentlich am Sketch was geändert? Ich hatte nämlich das gleiche Problem, hatte die Teile mit dem Programmierschalter rausgemacht, was aber zu viel war. Keine DCC-Nachrichten im Debug Monitor, nix, während der erste Servo-Sketch ging. Du benutzt ja auch die Sockelplatine von bodo.

Ich habe dann den sketch einfach so gelassen wie er ist und siehe da - es ging. Ohne POM dann aber, weil ich ja den Taster nicht habe. Allerdings hatte ich dann als DCC Adresse die POM Adresse, was irgendwie merkwürdig ist, zumal etwas anderes eingestellt war Ich gebe aber zu, dass mir das logische Verständnis fehlt, den sketch einzeln in seinen Abläufen durchzugehen und die Zeit, um mir das langsam zu erarbeiten.

Claudio

Hallo zusammen,

die Version, die bei mir dann lief, war auch die unveränderte originale Version. Lediglich die DCC Adresse und die POM Adresse habe ich verändert.
Im Debug Modus sehe ich zwar schon, dass etwas passiert (Adresse und welcher Servo an welchem Ausgang mit welcher Schaltartikeladresse angesteuert wird), die im Rahmen der POM Programmierung beschriebenen Ausgaben zu neuem CV-Wert werden jedoch nicht im Debug Modus gezeigt.
Die Veränderung des Sketches für die Adressvergabe individuell für jeden Arduino sehe ich als nicht problematisch - das ist ja nur ein einmaliger Vorgang, wenn die anderen Parameter (Endlagen, Drehgeschwindigkeit,etc.) dann über POM eingestellt werden können.
Aktuell probiere ich noch mit verschiedenen Servos zum Thema willkürliche Bewegung beim Einschalten, ich konnte aber noch keinen finden, bei dem das so richtig gut ist. Das Problem ist bei mir in diesem Zusammenhang, dass ich direkt an den Servos die Steuergestänge für meine Spur N Signale angeschlossen habe und aufgrund der kleinen Ausschläge der Servos, die zum Bewegen der Signalflügel notwendig sind, führt das Bewegen während des Einschaltens mittelfristig zur Zerstörung der Signalmechanik.

Viele Grüße

Marko

Wenn Du nur die Adressen geändert hat, ist ja der Normalmodus eingeschaltet und es werden keine POM Eingaben angenommen. Wenn man den POM Modus manuell einschaltet, ist bei mur, wie gesagt POM gleich DCC Adresse. Das kann aber daran liegen, dass ich zuviel auskommentiert habe

Hallo Franz-Peter,

Zitat von MicroBahner

---

Des weiteren gibt es normalerweise auch noch eine schnelle Bewegung beim ersten Umschalten. Da wüsste ich aber jetzt noch nicht, wie man das unterbinden kann. Es liegt daran, dass das Programm beim ersten Ansteuern des Servos nicht weis, wo der Servo steht. Programmintern stehen alle Servos nach dem einschalten erstmal in der 'Ruhelage'. Wenn das aber nicht mit der tatsächlichen Position des Servos übereinstimmt, kommt es bei der ersten Ansteuerung zu einer schnellen Bewegung des Servos in eben diese Ruhelage bevor dann die langsame Bewegung beginnt.

---

Wenn man die letzte Servoposition ins EEprom schreibt, und im Setup wieder in den Servo, dann könnte man das doch zumindest nach normalen Betriebspausen verhindern? Wahrscheinlich muss man vorsichtig sein, dass man das nur macht, wenn sich die Position wirklich ändert, um die Lebensdauer des Eeproms nicht zu verkürzen.

Ist es ein Problem, dass NMRADCC das EEprom schon in Beschlag nimmt? Dann müsste man den Umweg über eine CV gehen? Ah, jetzt wirds kompliziert...

EDIT:

Ich merke gerade, dass die Servos direkt beim Einschalten bei mir auch einen kleinen aber potentiell unerwünschten Ruckler machen. Unerwünscht, da meine Einfachsthalterungen keine mechanische Begrenzung haben. Eine Idee wäre, die Versorgungsspannung der Servos mittels eines Relais zu schalten, und zwar erst, nachdem die erste Servoposition geschrieben ist.


PS: Ich habe den Pullup am Optokoppler weggelassen, funktioniert auch.

Hallo zusammen,

bezüglich des Servo-Zuckens beim Einschalten - wenn es an nicht vorhandenen Werten liegt, dann könnte man doch auch bei jedem Start einfach am Servoausgang einen Puls von 1500ms ausgeben, was nach meinem Verständnis der Servo-Mittenposition entspricht. Üblicherweise werden ja um diesen Wert die beiden Endlagen definiert, so dass dann beim Einschalten der Servo zwar irgendwo zwischen den Endlagen steht, aber eben nicht darüber hinaus fährt. Zwischen den Endlagen ist die Mechanik ja unproblematisch - erst beim Überschreiten können Beschädigungen resultieren. Für alle, die nicht um die Mittelstellung des Servos herum die Endlagen definieren, könnten die 1500 auch noch variabel, oder aber auch als über CV konfigurierbare Wert angelegt sein (den Wert könnte man dann auch gleich einem der Endlagenwerte machen, so dass der Servo immer beim Start eine Endposition anfährt). Damit sollte das Problem dann doch zu lösen sein - wenn es tatsächlich nur der fehlende Startwert ist, oder?

Bezüglich der POM Programmierung: Ich habe im weiteren Verlauf, was dann an der Funktionsfähigkeit nichts geändert hat, im Sketch den Programmiermodus aktiviert (progMode = PROGMODE). Wenn ich dann versuche zu programmieren, erhalte ich im Debug Modus nicht die von Franz-Peter geschilderten Informationen (CV xx = Wert xx).

Viele Grüße

Marko

Hallo Marko, Franz und Claudio,
vielleicht könnt ihr auch mal zeigen, wo ihr was verändert habt? Dann könnte man leichter erkennen wo es hakt.

Da ihr ja auch ohne den Programmierschalter arbeiten wollt, werde ich jetzt mal schauen dass ich eine entsprechende Version baue. Adressen kann man dann aber nur über den Sketch einstellen (wenn auch der Programmiergleismodus nicht genutzt werden soll). Ich werd's auch noch erweitern, dass im Debugmodus noch beim Hochlauf die aktive PoM-Adresse ausgegeben wird - dann erkennt man leichter, was mit dem nicht funktionierenden PoM_mode los ist.

Zitat von franz_H0m

---

Wenn man die letzte Servoposition ins EEprom schreibt, und im Setup wieder in den Servo, dann könnte man das doch zumindest nach normalen Betriebspausen verhindern? Wahrscheinlich muss man vorsichtig sein, dass man das nur macht, wenn sich die Position wirklich ändert, um die Lebensdauer des Eeproms nicht zu verkürzen.

Ist es ein Problem, dass NMRADCC das EEprom schon in Beschlag nimmt? Dann müsste man den Umweg über eine CV gehen? Ah, jetzt wirds kompliziert...

---

Ja, das wäre eine Möglichkeit. Dass man das in einem CV hinterlegen muss, da die DCC-Lib das ganze EEProm belegt, sehe ich nicht als Problem, da fällt mir schon was ein. Die Geschichte mit der EEProm Lebensdauer muss man sicher beachten, aber wenn man es nur schreibt, wenn sich das Servo wirklich bewegt, stellt sich die Frage was schneller den Geist aufgibt - Servo oder EEPROM

Zitat von franz_H0m

---

Ich merke gerade, dass die Servos direkt beim Einschalten bei mir auch einen kleinen aber potentiell unerwünschten Ruckler machen. Unerwünscht, da meine Einfachsthalterungen keine mechanische Begrenzung haben. Eine Idee wäre, die Versorgungsspannung der Servos mittels eines Relais zu schalten, und zwar erst, nachdem die erste Servoposition geschrieben ist.

---

Wobei auch das nach meinen Erfahrungen keine Garantie dafür ist, dass es keinen Ruckler gibt. Beim Einschalten der Versorgungsspannung verhalten sich die Servos alle etwas unterschiedlich. Das Thema 'Einschaltruckler' wurde ja auch in anderen Threads schon lebhaft dikutiert. Wenn ich nochmal anfangen würde, würde ich nur noch Digitalservos einsetzen. Selbst die billigen, die ich mir jetzt mal besorgt habe, haben keinerlei Einschaltruckler.
Man muss auch unterscheiden zwischen dem unkontrollierten Einschaltruckler beim Anlegen der Versorgungsspannung, und der schnellen (aber kontrollierten) Bewegung, wenn die Servoposition nicht mit der Initialposition im Sketch übereinstimmt. Nur das 2. Problem lässt sich mit dem Abspeichern der Servoposition im EEProm lösen.

Zitat von Mape71

---

Das Problem ist bei mir in diesem Zusammenhang, dass ich direkt an den Servos die Steuergestänge für meine Spur N Signale angeschlossen habe und aufgrund der kleinen Ausschläge der Servos, die zum Bewegen der Signalflügel notwendig sind, führt das Bewegen während des Einschaltens mittelfristig zur Zerstörung der Signalmechanik.

---

Da liegt meiner Meinung nach ein grundsätzliches Problem der Mechanik (wurde im Forum auch schon öfter diskutiert). Die Mechanik sollte eigentlich immer so ausgelegt sein, dass der Servo für die Betätigung seinen Stellweg möglichst weitgehend ausnutzt und der komplette Stellweg zumindest nicht zu einer Beschädigung führt ( Übersetzungen, Federwege und Anschläge ). Alles andere ist immer gefährlich für die angeschlossenen Elemente. Außerdem lassen sich die Endpositionen und die Bewegung viel besser einstellen, wenn der Servo einen möglichst großen Drehwinkel zurücklegen muss.

Zitat von franz_H0m

---

PS: Ich habe den Pullup am Optokoppler weggelassen, funktioniert auch.

---

War nach dem Studium des Datenblatts auch nicht anders zu erwarten