Hallo Ulli,
danke fürs Bereitstellen der Entflechtung. Da bin ich eigentlich immer zu bequem zu - ich fädle meine Schaltungen einfach ops:

Zitat von garti62

---

So, jetzt muß ich mir erst mal Deine Neuerungen ansehen und schauen, ob ich alles verstehe .

---

Na so viel Neues ist es ja auch wieder nicht

Hallo Stummis,

ich hab die Platine (Beitrag #247) nochmal etwas geändert (Beschaltung von Pin A6 und Drehencoder mit Schalter). Außerdem hab ich noch einen Sketch mit drangehängt, passend zur Platine.

Schöne Grüße
Ulli

Hallo Ulli,
danke für deine Unterstützung und die Arbeit . Das erleichtert sicher Vielen den Einsatz

@all:
Nachdem ich noch etwas getestet habe, ist die V0.7 nun als neue release freigegeben.

Nächstes Vorhaben ist es, das weiche Auf- und Abblenden der Led's auf allen Ausgängen zu ermöglichen - nicht nur an den PWM-Pins (da gibt's ja auf dem Nano nicht viel). Damit könnte man dann auch schön Lichtsignale ansteuern.

Hallo Franz-Peter,

[quote=MicroBahner]Nächstes Vorhaben ist es, das weiche Auf- und Abblenden der Led's auf allen Ausgängen zu ermöglichen - nicht nur an den PWM-Pins (da gibt's ja auf dem Nano nicht viel). Damit könnte man dann auch schön Lichtsignale ansteuern.[/quote]
das wäre natürlich super ... dann würde ich meine eigenen Pläne mit separatem PWM-Treiberbaustein (ELV oder Adafruit) erstmal zurückstellen.

Viele Grüße, Bodo

Hallo Bodo und alle MobaTools Interessierten,
super wenn es dafür schon einen Interessenten gibt .

Eine Vorabversion habe ich auf GitHub hochgeladen. unter diesem Link gibts immer den aktuellen Stand der V0.8 Beta.

Es sind jetzt maximal 12 SoftLeds einrichtbar. Das sollte für den Nano reichen. Ausserdem gibt es für die Softleds 2 neue Methoden:
Softled::write( ON|OFF ) schaltet die Led per Parameterübergabe an oder aus.
Softled::toggle() schaltet den aktuellen Zustand um.

Für die Charakteristk des Auf- und Abblendens habe ich mal versuchsweise 2 Varianten integriert: LINEAR und BULB. Mit BULB soll das Verhalten einer Glühbirne angenähert werden - groß ist der Unterschied nicht . Umschalten kann man das auch mit dem write-Befehl (default ist LINEAR):
Softled::write( ON|OFF, LINEAR|BULB);
Die eingestellte Charakteristik bleibt aktiv, bis sie wieder mit dem write-Befehl umgestellt wird.

Das gleichzeitige Auf- oder Abblenden aller Led's belastet den Nano aber schon ganz ordentlich. Wenn man da gleichzeitig auch noch 4 Stepper und einige Servo's ansteuern möchte wird's sicher eng . Gut, beim Nano begrenzt das ja schon die Zahl der Pins, aber beim Mega könnte man ja auf die Idee kommen. Der hat zwar viel mehr IO's, aber der Prozessorkern beim Mega ist auch nicht schneller als der vom Nano.

Zusammen mit der NmraDCC-Lib muss ich das auch noch testen.

Hallo Franz-Peter,

ich bin auf den Thread zu den MobaTools gestoßen und habe nach einem Überfliegen der Beiträge meine ersten Versuchs-Servo-Ansteuerungen hinbekommen. Zunächst mal vielen Dank für das wunderbare Tool. Es ist toll, wenn die, die es können, andere teilhaben lassen!
Ich hoffe, es ist nicht anmaßend, wenn ich frage, ob vielleicht auch eine Implementierung von Verlaufskurven, wie sie etwa Herr Kufer auf seiner
Seite http://www.opendcc.de/elektronik/opendec...r_sw_servo.html anführt, eine zukünftige Erweiterung sein könnte. Im Rahmen meiner Möglichkeiten würde ich auch gerne etwas beisteuern.

Viele Grüße

Klaus

Hallo Klaus,
es freut mich natürlich immer, wenn jemand mit meiner Lib etwas anfangen kann. Dafür ist sie ja gemacht

Zitat

---

Ich hoffe, es ist nicht anmaßend, wenn ich frage, ob vielleicht auch eine Implementierung von Verlaufskurven, wie sie etwa Herr Kufer auf seiner
Seite http://www.opendcc.de/elektronik/opende ... servo.html anführt, eine zukünftige Erweiterung sein könnte.

---

Vorschläge für Erweiterungen sind nie anmaßend - sie zeigen doch nur, dass sich jemand mit der Lib beschäftigt. Ob's dann was wird ist was anderes . So eine Verlaufskurve ist aber sicher ein interessantes Feature. Auch wenn das in einer allgemein gehaltenen Lib vermutlich etwas schwieriger ist als wie bei H. Kufer in einem kompletten Decoder. So eine Lib soll ja auch nicht unnötig groß werden, und nicht jeder benötigt das. Das gilt aber ganz allgemein auch jetzt schon für die MobaTools - da benötigt ja auch nicht jeder alles was jetzt schon drinsteckt.
Ich könnte mir vorstellen so etwas in einer übergeordneten Softwareschicht zu machen, die die einzelnen Eckpunkte anfährt. Das Interpolieren dazwischen macht dann die derzeitige Lib. Ob man das voll integriert oder als eigenständige Software realisiert müsste man dann noch sehen. Ich könnte mir vorstellen, dass das dann auch für die Schrittmotoransteuerung funktionieren sollte. Ist da erstmal ein Referenzpunkt gesetzt, kann die Lib den ja auch praktisch genauso ansteuern wie ein Servo.
Die nächste Erweiterung, die ich vorgesehen habe, ist allerdings die MobaTools auch auf der STM32 Platform zum laufen zu bringen. Die nmraDcc-Lib ist schon entsprechend erweitert, und für die MobaTools sehe ich das auch als interessant. Mit dem STM32 gibt es Platinchen, die kaum teurer und größer sind als ein Arduino Nano. Man bekommt aber mehr IO's und einen wesentlich leistungsfähigeren (32bit) Prozessor.
Die ToDo-Liste der MobaTools wird also nicht kürzer

Hallo Franz-Peter,

vielen Dank für die wohlwollende Aufnahme des Vorschlags.

Zitat

---

Das Interpolieren dazwischen macht dann die derzeitige Lib.

---

Wie würde man konkret zwischen (t1,x1) und (t2,x2) fahren? t und x nehme ich als vom Typ 'byte' an. t mit der Auflösung 0,02s.

Viele Grüße

Klaus

Hallo Klaus,
da ist dann erstmal etwas Rechnerei nötig . Wenn wir davon ausgehen, dass x1 die aktuelle Position ist, wäre als Ziel für den Servo.write-Befehl dann einfach x2 anzugeben. Jetzt muss aber noch die Geschwindigkeit gesetzt werden, damit das mit der Zeit passt. Dazu brauchen wir die Differenz bei den Pulslängen. Wenn x1 und x2 byte sind, sind das also die Grad-Werte. Die müssten erstmal in Impulszeiten umgerechnet werden. Aus der Differenz der beiden Impulszeiten, und der gewünschten Verfahrzeit (t2-t1) kann man dann den Wert errechnen, der bei Servo.speed gesetzt werden muss.
Sowas würde ich aber nicht zur Laufzeit, schon gar nicht in den Interruptroutinen machen. Die Tabelle, so wie sie bei H. Kufer vorgegeben wird, müsste für die MoBa Tools vorab entsprechend umgerechnet werden in Position und Speed. Die kann dann beim Ablauf rel. einfach abgearbeitet werden. Immer wenn der Servo seinen Zielpunkt erreicht hat, wird das nächste Position/Speed-Pärchen aufgerufen. Wenn man das erreichen des Zielpunktes nicht pollen will, muss da in der Lib noch was getan werden, denn die weis ja wann der Zielpunkt erreicht ist. Allerdings erkennt sie auch das nur im Interrupt - und der soll ja immer möglichst kurz sein. Ohne Pollen beim Umschalten auf den nächsten Zielpunkt müsste man das Ganze wohl doch fest in die Lib integrieren.
Allerdings sollte Pollen im loop eigentlich ausreichend sein - dazu muss die Schleifenzeit nur < 20ms sein, was eh häufig gefordert ist, z.B. auch bei der nmraDcc-Library. Die fordert sogar noch deutlich kürzere Schleifenzeiten ( oder mehrfachen Aufruf des Dcc.Process() ).

Edit: So auf die Schnelle mal ein Lösungsansatz: Man legt eine Klasse an mit 2 Methoden: Die erste initiiert das Ganze und startet die Bewegung. Dort würde ich auch gegebenenfalls die Umrechnung einer 'normierten' Tabelle auf die konkreten Position/Speed-Pärchen machen. Als Info bekommt sie einen Pointer auf die abzufahrende Tabelle, und welcher Servo das Ganze abfahren soll. Die 2. Methode wird im loop zyklisch aufgerufen, und arbeitet das Abfahren dann ab: Prüfen ob Zwischenpunkt erreicht, wenn ja auf nächsten Zielpunkt wechseln. Eine 3 Methode könnte noch sein, den Gesamtstatus abzufragen um so erkennen zu können, wenn der Servo das Ende der Kurve erreicht hat.

Hallo Franz-Peter,

vielen Dank für die ausführliche Erläuterung. Auch ohne jedes Detail verstanden zu haben, entnehme ich deiner Antwort, dass das Anfahren von Zeit-Winkel-Punkten nicht trivial ist und wohlüberlegt sein will.

Viele Grüße

Klaus

Hallo Klaus,
ja ganz trivial ist es sicher nicht, aber mit einer Zwischenschicht wie ich es oben als 'Edit' skizziert habe, sollte es relativ einfach möglich sein. Aber der Teufel steckt sicher - wie immer - im Detail.

@all: Ich habe jetzt die V0.8 freigegeben. Ich hoffe gründlich genug getestet zu haben . Aber wenn einer Fehler findet, immer her damit.

Im wesentlich ist nur neu, dass die SoftLeds jetzt an allen digitalen Ausgängen funktionieren, nicht nur an PWM-fähigen. Die Links im Startbeitrag sind auch aktualisiert.

Hallo,
es gibt eine neue Version V0.9. Im Rahmen des Zubehördecoders war der Wunsch aufgekommen, die Softled-Ausgänge invertieren zu können, damit auch Lichtsignale mit gemeinsamer Anode einfach angesteuert werden können. Die Zahl der Softledausgänge ist auch nicht mehr fest begrenzt. Die Grenze liegt nur noch in der Zahl der Ausgänge und der Leistungsfähigkeit des Arduino.

Ausserdem unterstützen die MobaTools die STM32F1 Plattform. Meiner Meinung nach die günstigste Möglichkeit für eine 32-Bit CPU. Die kleinen Platinchen sind kaum größer und teurer als ein Arduino Nano.

Hallo Franz-Peter,

erstmal Danke für das Bereitstellen der MobaTools und die tolle Arbeit.

Zu den MobaTools habe ich zwei Fragen:

1. Darf ich nur den EggTimer aus den MobaTools für mein eigenes Projekt, Loconet RM und Signalsteuerung einsetzen?
2. Beim Kompilieren für den Nano mit der loconet.h erhalte ich einen Fehler. Hier kollidieren wohl die Loconet.h und die MobaTools.h
miteinander:

Arduino: 1.8.3 (Windows 10), Board: "Arduino Nano, ATmega328P"

librariesLocoNetutilityln_sw_uart.cpp.o (symbol from plugin): In function `setTxPortAndPin(unsigned char volatile*, unsigned char)':

(.text+0x0): multiple definition of `__vector_11'

librariesMobaTools-masterMobaTools.cpp.o (symbol from plugin):(.text+0x0): first defined here

collect2.exe: error: ld returned 1 exit status

exit status 1
Fehler beim Kompilieren für das Board Arduino Nano.

Fällt Dir dazu eine Lösung ein?

Ich nutze delayTimeFade für das Ein- und Ausblenden der Signalbilder.

Hallo Andreas,

Zitat

---

1. Darf ich nur den EggTimer aus den MobaTools für mein eigenes Projekt, Loconet RM und Signalsteuerung einsetzen?

---

Na klar - ist ja nun wirklich nur eine kleine handliche Klasse

Zitat

---

2. Beim Kompilieren für den Nano mit der loconet.h erhalte ich einen Fehler. Hier kollidieren wohl die Loconet.h und die MobaTools.h
miteinander:

---

Ja, das ist leider so . Die Loconet-Lib verwendet auch den Timer 1 - genauso wie die MobaTools.

Hallo Franz-Peter,

Danke für die Antwort. Gibt es eine Lösung?

Edit: Habs hinbekommen, habe, wenn ok, die Klasse in eine eigene Library reingepackt. Darf ich das?

Hallo Andreas,

Zitat

---

Danke für die Antwort. Gibt es eine Lösung?

---

Ich nehme mal an, die Frage bezieht sich auf den Konflikt MobaTools<->LocoNet. Da ist mir derzeit keine Lösung bekannt. Der Standard-Arduino mit AtMega328P hat ja nun mal nur einen 16-Bit Timer.
Mit einem Arduino Mega müsste es grundsätzlich gehen, aber da müsste ein der beiden Libs auf einen anderen Timer umgeschrieben werden.

Zitat

---

Edit: Habs hinbekommen, habe, wenn ok, die Klasse in eine eigene Library reingepackt. Darf ich das?

---

Die Frage bezieht sich jetzt auf den EggTimer? Den kannst Du für dich natürlich in eine eigene Lib packen. Nur wenn Du die dann als deine Lib weitergeben würdest, wäre es etwas unfair (und entspräche nicht der GPL ) .

Hallo Franz-Peter,

bezieht sich ausschließlich auf den EggTimer. Die Lib setze ich nur für mich ein.

Hallo an alle MobaTools-Interessierten
es gibt eine neue Version der MobaTools. Die ist vielleicht vor allem für diejenigen interessant, die die MobaTools gern mit der LocoNet-Library zusammen einsetzten würden. Dies war ja bisher nicht möglich. Auf den 'Standard-Arduinos' Nano und Uno geht das zwar immer noch nicht, da die ja nunmal nur einen 16-Bit Timer haben. Aber auf bestimmten Arduinos, die mehrere 16-Bit-Timer haben sollte es nun möglich sein. Speziell die 'Pro Micro' sind auch recht günstig zu bekommen. Selbst testen kann ich es aufgrund mangelnden Equipments leider nicht .

die wesentlichen Änderungen:

• Auf AVR-Platformen mit mehr als einem 16-bit-Timer verwenden die MoBa-Tools nun automatisch den Timer 3. Dies ermöglicht die parallele Verwendung von anderen Libs, die auch den TImer 1 verwenden auf diesem Plattformen. Dies gilt z.B. für Arduino Leonardo, Micro, Pro Micro und Mega.
• Servo's: ist 'AUTOOFF' aktiv und es wird ein servo.write-Befehl auf die aktuelle Position ausgegeben, so werden nun für ca 1sec Servoimpuls ausgegeben. Die Vorgängerversionen haben in diesem Fall keine Impulse ausgegeben.

Guten Abend zusammen,
Ich heisse Marcus und war bisher stiller Mitleser.
Ich fahre digital zm größeren Teil mit Märklin Material auf C und K Gleisen.
Ich lese mit Begeisterung über die Möglichkeiten des Arduino diesen Thread.
Ich bin jetzt endlich dazugekommen einen Testaufbau für einen Servo-Weichendekoder zu machen.
Ich fahre mzur zeit mit einer MS2 mit mfx,Motorola und DCC.
Das Protokoll für dei Magnetartikel ist auf DCC eingerstellt.
ich habe an den Arduino Uno einen Servo an Pin 3 und die Optokopplerschaltung an Pin 2 angeschlossen.
Ich habe den Sketch von Bodo aus
viewtopic.php?p=1448001#p1448001
verwendet.
Leider bewegt sich nichts.
Habe ich etwas übersehnen oder muss ich den Sketch noch anpassen?
Der Optokoppler scheint zu funktionieren, da er bei eingeschaltetem Bahnsignal eine direkt angeschlossene LED leuchten lässt.
Kann ich am Arduino irgenwie feststellen ob das Signal richtig erkannt wird?
Es wäre toll, wenn Ihrm mir helfen könt.

Liebe Grüße Marcus

Hallo Marcus,
ich nehme an, Du hast den Sketch von Bodo entsprechend angepasst? Er verwendet ja andere Pins für die Servos. Vielleicht stellst Du mal deinen Sketch hier ein.
Zum Testen kann man den seriellen Monitor verwenden und an den entsprechenden Stellen mit 'Serial.println' Testausgaben machen.

Hallo,

[quote="BR 1970-09-12" post_id=1754658 time=1511720933 user_id=29053]
Der Optokoppler scheint zu funktionieren, da er bei eingeschaltetem Bahnsignal eine direkt angeschlossene LED leuchten lässt.[/quote]
wie hast Du die LED denn angeschlossen ? Die einzig mir sinnvoll erscheinende Möglichkeit besteht darin, die LED antiparallel am Optokoppler-Eingang (anstelle der Schutzdiode) einzusetzen ... und das zeigt dann nur eine anliegende Spannung, lässt aber keine Rückschlüsse auf die Funktion des Optokoppler zu.
Alle anderen Anschlussmöglichkeiten (parallel zum Eingang oder gar am "Ausgang" bzw. Eingangspin des Arduino) dürften die Signalübertragung zuverlässig stören.

Ansonsten: Wie Franz-Peter schon geschrieben hat - ohne den Sketch und den Anschlussplan ist das jetzt alles nur ein Ratespiel.

Viele Grüße, Bodo

Hallo Franz-Peter, hallo Bodo,

Die LED hatte ich nur zwischenzeitlich am Ausgang des Optokoppler angeschlossen um zu sehen ob ein Signal durchkommt.
Die LED habe ich wieder entfernt und es funktioniert nichts.

Testaufbau:


hier ist mein Sketch:
Ich benutze
Pin 2 als DCC-Eingang,
Pin 3 als Servo-Anschluss mit Adresse 1.

#include <NmraDcc.h>
#include <MobaTools.h>

// Demo: ein ganz einfacher Dcc-Servodecoder //
//------------------------------------------ //
// die NmraDcc - Library gibt es unter https://github.com/mrrwa/NmraDcc/archive/master.zip

// anzupassende Konstante:
const byte isROCO = 0 ; // wegen unterschiedlicher Weichenadressberechnung bei Roco (sonst = 0)
const byte weichenAdr[] = { 1, 7, 3, 123, 8, 34, 77, 88}; // DCC-Weichenadressen
const byte servoPins[] = { 3, 4, 5, 6, 7, 8, 9, 10}; // output-pin der Servos
const int geradePulse[] = {1200,1200,1200,1200,1200,1200,1200,1200}; // Pulslänge geradeaus
const int abzweigPulse[]= {1800,1800,1800,1800,1800,1800,1800,1800}; // Pulslänge abzweigend

const int speed = 8;
const byte autoOff = 1;
const byte ServoZahl = sizeof(weichenAdr);
Servo8 weicheS[ServoZahl];
NmraDcc Dcc;
///////////////////////////////////////////////////////////////
void setup() {
Dcc.init( MAN_ID_DIY, 15, FLAGS_OUTPUT_ADDRESS_MODE | FLAGS_DCC_ACCESSORY_DECODER, 0 );
Dcc.pin(0, 2, 1); // Dcc-Signal an Pin2 ( = Int0 );

for ( byte i=0; i<ServoZahl; i++ ) {
// Weichenservos initiieren
weicheS[i].attach( servoPins[i], autoOff );
weicheS[i].setSpeed( speed );
}
}
////////////////////////////////////////////////////////////////
void loop() {
Dcc.process(); // Hier werden die empfangenen Telegramme analysiert

}
//////////////////////////////////////////////////////////////
// Unterprogramme, die von der DCC Library aufgerufen werden:
// Die folgende Funktion wird von Dcc.process() aufgerufen, wenn ein Weichentelegramm empfangen wurde
void notifyDccAccState( uint16_t Addr, uint16_t BoardAddr, uint8_t OutputAddr, uint8_t State ){
// Weichenadresse berechnen
word wAddr = Addr+isROCO; // Roco zählt ab 0, alle anderen lassen die ersten 4 Weichenadressen frei
// Testen ob eigene Weichenadresse
for ( byte i = 0; i < ServoZahl; i++ ) {
if ( wAddr == weichenAdr[i] ) {
// ist eigene Adresse, Servo ansteuern
if ( OutputAddr & 0x1 ) {
weicheS[i].write( geradePulse[i] );
} else {
weicheS[i].write( abzweigPulse[i] );
}
break; // Schleifendurchlauf abbrechen, es kann nur eine Weiche sein
}
}
}

Danke für Eure Mühe

Gruß
Marcus

Nachtrag zm letzen Beitrag von mir:



Gruß
Marcus

Hallo Marcus,

sieht jetzt spontan erstmal nichts falsch aus. Ist der Optokoppler wirklich ein 6N137 ? Das kann ich auf dem Bild nicht erkennen. Der 6N137 ist ein "Highspeed"-Optokoppler, ein normaler wird´s wahrscheinlich nicht machen. Auch ob die Anschlüsse kontaktsicher sind, lässt sich bei der "fliegenden" Verdrahtung nicht erkennen, da wären durchgängig verwendete "Dupont"-Kabel übersichtlicher (aber auch die können Wackelkontakte haben).

Hast Du aus den Beispielen mal ein Demo-Programm für das Servo laufen lassen ? Damit wäre dann sichergestellt, dass sich das grundsätzlich bewegt. Ansonsten würde ich (klappt aber frühestens Donnerstag Abend) den Sketch mit aktueller NmraDcc.h und MobaTools.h mal auf meiner Testhardware laufen lassen - sollte zwar keinen Unterschied zum damaligen Software-Stand machen, aber man weiß ja nie ...

Viele Grüße, Bodo

PS: Für Coding solltest Du die Code-Tags verwenden - ich dachte jetzt, ich hätte noch einen Fehler gefunden, aber

[i]
 

wird einfach als "Kursiv" interpretiert, wenn´s nicht innerhalb der Code-Tags steht ...

Hallo Bodo,

Vielen Dank für Deine Anwort.
Deine Überlegung mit dem Optokoppler hatte ich auch schon und mir auf Verdacht ein paar neue bestellt.
Und siehe da, es funktioniert auf Anhieb.
Dabei musste ich feststellen, dass der Pin 3 vom meinem Arduino defekt ist.
Ich hatte das Beispiel Servo_01 aus den Mobatools vorher gestestet- das lief auch mit besagtem Pin 3.
Mit zwei Fehlerquellen kann sich natürlich nichts bewegen.
Ich bin jetz erstmal glücklich das es funktioniert und werde das ganze auf einen Nano-Klon zu übertragen.
Liebe Grüße,

Marcus