[spurxfan]

Hallo Bodo,

vielleicht wird aus der Diskussion eine "gescheite" Drehscheibensteuerung mit einem Schrittmotor für die MobaTools. Aus dem Grunde hatte ich meine Fragen unter diesen bekannten Titel gesetzt. Denn unter dem Thema Arduino MobaTools: Vx.x.x released schreiben einige Experten.

Freundlich grüßt
Michael

[MoBa_Alfred]

gelöscht, da Bezug auch gelöscht wurde

[silv1971]

- Beitrag gelöscht weil im falschen Thema -

[Bodo]

Hallo zusammen,

könnte man Probleme mit DIY-Dekoder in dessen Thread diskutieren ? 🙄.

Ist nur ein Vorschlag ... ich werde diesen Thread jetzt jedenfalls solange ignorieren, wie hier alles mögliche diskutiert wird, was mit dem Thema eigentlich nichts zu tun hat.

MfG Bodo

[MicroBahner]

Hallo,
es freut mich natürlich, wenn die MobaTools auf soviel Interesse stoßen. Aber ich muss Bodo doch Recht geben. Es macht wenig Sinn, jedes Projekt mit MobaTools in diesen Thread stopfen zu wollen. Das wird doch extrem unübersichtlich.

Wer konkrete Probleme bei der Anwendung hat, Vorschläge für Erweiterungen macht oder Fehler findet, darf dies gerne hier posten.
Aber Projekte, bei denen die MobaTools nur Mittel zum Zweck sind, sollten schon in eigenen Threads behandelt werden. Da lässt sich dann auch ein aussagekräftiger Titel vergeben, so dass Andere, die sich für das gleiche Thema interessieren - z.B. eine Drehscheibensteuerung - dieses Thema auch finden. Ist dabei geplant, die MobaTools einzusetzen, kann natürlich gern ein Link auf diesen Thread gesetzt werden

Und für meinen DIY-Decoder gibt es ja schon einen Faden. Wer also damit Probleme hat, ist dort bestens aufgehoben .

[MoBa_Alfred]

Hallo Franz-Peter,

in deinen MobaTools hast Du ja tolle Funktionen zum Einlesen von Tasterzuständen und deren Entprellung.
Ist es möglich mit den MobaTools auch einzelne Taster so abzufragen und zu entprellen?

Was ich vor habe ist mehrere (4) Zustände von Belegtmeldern einzulesen. Diese sind pro Melder mittels je 2 antiparallelen Dioden (1n4004) Vorwiderstand und Optokoppler aufgebaut. Das Signal bereite ich mittels 10K und 100nF für die Logik auf.

Bei kleinen H0e Loks gibt es immer einmal kurze Kontaktproblemchen Schiene/Räder die auf dem Scope ähnlich wie das Prellen bei Tastern aussehen. Ich denke die bekommt man mittels einer Entprellfunktion in Griff.

Viele Grüße
Alfred

[MicroBahner]

Hallo Alfred,

Zitat

---

Ist es möglich mit den MobaTools auch einzelne Taster so abzufragen und zu entprellen?

Was ich vor habe ist mehrere (4) Zustände von Belegtmeldern einzulesen.

---

Dann hättest Du doch schon 4 'Taster'. Oder was meinst Du mit dem 'einzelne Taster'? ( Wobei die Zahl der verwalteten Taster von 1...32 möglich ist )

[MoBa_Alfred]

Hallo Franz-Peter,

genau, das wären 4 Taster, aber alle an verschiedenen Eingängen des Arduino.

Gruß
Alfred

[MicroBahner]

Naja, das gilt eigentlich immer für mehrere Taster. Wenn die Taster einfach an verschiedenen Eingängen hängen, brauchst Du auch keine Callback Funktion zum Einlesen. Da schreibst Du einfach die Pins in eine Array, und übergibst das beim Einrichten der MotoButtons. Z.B. so:

1
2
3
4
5
6
 

// Taster einrichten ( die Taster müssen gegen Gnd schalten, keine Widerstände notwendig )
enum { Taster1, Taster2, Taster3, Taster4 } ; // Den Tasternamen die Indizes 0...3 zuordnen
const byte tasterPins[] = {A1, A2, A3, A4 }; // muss als byte definiert sein, damit ein enfaches sizeof funktioniert
const byte tasterZahl = sizeof(tasterPins);
MoToButtons taster( tasterPins, tasterZahl, 20, 500 );
 
 

[MoBa_Alfred]

Hallo Franz-Peter,

da dies aber in Wirklichkeit keine Taster sind, sondern Ausgänge eines Optokopplers, kann ich den Widerstand am Ausgang des Optokopplers nach +5V auch weglassen? Du scheinst ja die internen PullUp zu nutzen. Der 100nF Kondensator nach GND, der auch am Ausgang des OK hängt sollte auch nicht stören, der macht mir ein sauberes HIGH oder LOW aus dem noch merkbaren DCC-Signal des Belegtmelders, wie im Post vorher beschrieben.

Grüße
Alfred

[MicroBahner]

Ja, im Prinzip kannst Du die externen Pullup weglassen. Hängt aber letztendlich auch von der Leitungslänge ab. Die internen Pullups sind ja rel hochohmig, und bei längeren Leitungen könnten dann leichter Störungen einstreuen. Das musst Du ausprobieren. Du solltest dir also auf jeden Fall die Möglichkeit offen halten, da noch etwas niederohmigere Pullups parallel zu schalten.

[MoBa_Alfred]

Hallo Franz-Peter,

vielen Dank! Genial, das spart viel coding.

Viele Grüße
Alfred

[MicroBahner]

Hallo Alfred,
noch was: Das Einlesen der Tasterzustände ohne ein Callback ( so wie oben gezeigt ) funktioniert erst ab der V2.2, die ich hier noch garnicht vorgestellt habe. Es ist aber schon seit einiger Zeit die aktuelle Version im Bibliotheksverwalter. Evtl. hast Du die ja auch schon.

[Claus60]

Hallo.
Nachdem in meinem Drehscheiben- Thread das Getriebespiel ins Gespräch kam, habe ich mir meine Scheibe im Betrieb daraufhin mal ganz genau angeschaut. Dabei ist mir eine Idee gekommen, wie man die MoBaTools vielleicht noch besser machen kann, als sie schon sind. Es gibt ja die Beschleunigungsrampe, die man mit einem Parameter aktivieren kann. Das funktioniert auch soweit sehr gut. Allerdings ist mir aufgefallen, das meine Scheibe erst verzögert anfängt zu drehen, obwohl der Stepper schon angefangen hat zu arbeiten. Kann man am Blinken der LED auf der Treiber- Platine schön erkennen. Dabei wird wohl zunächst das Getriebespiel durchfahren, bevor die Bühne tatsächlich anfängt, sich zu bewegen. In der Zeit hat der Stepper aber schon seine Geschwindigkeit erhöht. Die Bühne läuft also nicht so sanft an, wie sie anhält. Das ist, wenn man genau hin schaut, tatsächlich sichtbar, zumindest bei meiner Drehscheibe.

Um das auch noch zu perfektionieren, wäre ein Delay für die Beschleunigungsrampe nützlich. Also MyStepper.rampDelay(15) (oder so ähnlich). Damit würde bewirkt, das die ersten (in diesem Fall 15) Steps ohne einsetzten der Rampe durchfahren werden. Erst danach beginnt dann die Beschleunigung. Damit könnte man erreichen, das die Bühne mit Minimalgeschwindigkeit startet und nicht mit bereits erhöhter Geschwindigkeit los läuft. Entweder wirkt dieser Parameter nur beim Beschleunigen, nicht beim Abbremsen oder man macht das sogar getrennt einstellbar. Ich würde es nur bei der Beschleunigung benötigen aber vielleicht können Andere das auch beim Bremsen gebrauchen.

Dieser Parameter wäre sowohl bei Steppern als auch bei Servos denkbar. Auch hier könnte es ja Spiel z.B. im Gestänge geben, das man so besser kompensieren kann. Der/die Parameter müssten aber wohl optional sein, damit bisherige Sketche kompatibel bleiben.
Was haltet ihr davon? Speziell an Franz-Peter die Frage, ist das überhaupt machbar?

[MicroBahner]

Zitat

---

Speziell an Franz-Peter die Frage, ist das überhaupt machbar?

---

Mhmm ... auf jeden Fall mal nicht so ganz einfach. Alle Berechnungen, die während der Bewegung notwendig sind, müssen in der ISR gemacht werden. Und die ist - für eine ISR - eh schon recht lang und aufwändig. Deshalb würde ich da sowas ungern noch reinbauen. Dann hast Du ja auch noch das Problem, das das Getriebespiel ja nur bei einem Richtungwechsel auftritt. Wenn Du die Bühne stoppst, und danach in der gleichen Richtung weiterfährst, dürfte der Delay nicht greifen.
Grundsätzlich könntest Du das auch im Sketch lösen: Wenn Du die Richtung wechselst, erstmal ein paar Schritte in die neue Richtung, und danach erst zur Zielposition.
Bei Servos sehe ich das Problem eigentlich nicht, da es dort keine Beschleunigungsrampen gibt.

[md95129]

Zitat

---

Hallo.
Nachdem in meinem Drehscheiben- Thread das Getriebespiel ins Gespräch kam, habe ich mir meine Scheibe im Betrieb daraufhin mal ganz genau angeschaut. ...

---

Ich habe das bei einer Schiebebuehne mit merklichem Spiel so geloest, dass ich immer von einer Seite anfahre. Von der einen direkt, von der anderen mit einem kleinen Ueberschwinger, d.h. ich fahre etwas zu weit und dann wieder zurueck. Das Zurueckfahren geschieht langsam und fast unmerklich. Du koenntest beim Anfahren das gleiche Spielchen wiederholen.
Das war damals noch mit einm 8048 Prozessor.
Oups: Franz-Peter hat das ja schon beantwortet.

[MicroBahner]

Hallo
es gibt eine neue Version der MobaTools ( die 2.2. hatte ich hier übersprungen, ist im Eingangspost jetzt aber auch nachgetragen )

Die wesentlichen Erweiterungen ( seit 2.1.1 ):

• Neue Klasse 'MoToTimebase' mit der Ereignisse in regelmäßigen Abständen ausgelöst werden können. Dies ist genauer, als wenn man dies mit MoToTimer selbst macht.
• MoToButtons: Ein 'longPress' wird jetzt sofort ausgelöst, wenn die Taste entsprechend lang gedrückt wird, nicht erst beim Loslassen. Damit erkennt man sofort, wenn man lang genug gedrückt hat.
• MoToStepper: Wenn der Nullpunkt gesetzt wird, kann jetzt auch die Zahl der Steps/Umdrehung neu gesetzt werden.
• In der Klasse MoToButtens gibt es eine neue Methode 'clicked' mit der einfache und Doppelklickes erkannt werden können.
• Sind alle Taster/Schalter einfach jeweils an einen eigenen Pin angeschlossen ( und schalten gegen Gnd ), so ist keine Callbackfunktion mehr notwendig. Die Taster-Pins werden als ein Array übergeben.
• Es gibt ein paar zusätzliche Beispiele.

Und ein paar Fehler wurden auch beseitigt . Kann einfach im Bibliotheksmanager 'geupdated' werden.

[fischi01]

Hallo!

Ich benötige nochmal Hilfe.
Der Decoder funktioniert aber bei dem Ausgang Pin 6 scheint die Epromspeicherung nicht zu funktionieren.
Beim ersten Betätigen fährt der Servo da über das Ziel hinaus. Alle anderen Ausgänge funktionieren.

Gruß RENÈ

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
 

#include <NmraDcc.h>
#include <MobaTools.h>
#include <EEPROM.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[] =   { 235, 235, 252, 252, 251, 251, 234, 234};  // DCC-Weichenadressen 
const byte servoPins[]  =   {  3,  4,   5,   6,   7,   8,   9,  10};  // output-pin der Servos
const int geradePulse[] =   {1320,1300,1320,1300,1380,1120,1300,1250};  // Pulslänge geradeaus
const int abzweigPulse[]=   {1580,1680,1580,1600,1650,1550,1600,1660};  // Pulslänge abzweigend
 
const int speed = 8;
const byte autoOff = 1;
const byte ServoZahl = sizeof(weichenAdr);
Servo8 weicheS[ServoZahl];
NmraDcc Dcc;
///////////////////////////////////////////////////////////////
void setup() {
    Dcc.pin(digitalPinToInterrupt(2), 2, 1); // Dcc-Signal an Pin2 ( = Int0 );
    Dcc.init( MAN_ID_DIY, 15, FLAGS_OUTPUT_ADDRESS_MODE | FLAGS_DCC_ACCESSORY_DECODER, 0 );
 
    for ( byte i=0; i<ServoZahl; i++ ) {
        int inipos;
        // Weichenservos initiieren
        weicheS[i].attach( servoPins[i], autoOff );
        weicheS[i].setSpeed( speed );
        EEPROM.get(i*2, inipos );                   // letzten gespeicherten Wert aus dem EEPROM lesen
        inipos = constrain( inipos, 600, 2500 );    // auf gültige Werte begrenzen
        weicheS[i].write( inipos );                 // Servo dorthin fahren ( sollte bereits da stehen )
    }
}
////////////////////////////////////////////////////////////////
void loop() {
    Dcc.process(); // Hier werden die empfangenen Telegramme analysiert
  const byte isROCO = 4  ;    // wegen unterschiedlicher Weichenadressberechnung bei Roco (sonst = 0)  
}
//////////////////////////////////////////////////////////////
// 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 ){
void notifyDccAccTurnoutOutput( uint16_t Addr, uint8_t OutputAddr, uint8_t OutputPower ) {
    // 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] );
                EEPROM.put(i*2,geradePulse[i]);
            } else {
                weicheS[i].write( abzweigPulse[i] );
                EEPROM.put(i*2,abzweigPulse[i]);
            }
            //break; // Schleifendurchlauf abbrechen, es kann nur eine Weiche sein
        }
    }
}
 
 

[MicroBahner]

Hallo RENÈ,
ich weis jetzt nicht, ob das mit deinem Problem des Pin 6 zusammenhängt, aber das funktioniert nicht:

1
2
3
4
5
6
 

void loop() {
    Dcc.process(); // Hier werden die empfangenen Telegramme analysiert
  const byte isROCO = 4  ;    // wegen unterschiedlicher Weichenadressberechnung bei Roco (sonst = 0)   <<<< geht so nicht !!!!
}
 
 

Du musst das 'isRoco' schon oben bei den 'anzupassenden Konstante' entsprechend setzen. Im loop hat das nichts zu suchen.

[fischi01]

Hallo Franz-Peter!

Ich habe die Zeile aus dem Loop gelöscht, aber geändert hat sich nichts.
Das Problem haben alle 3 Decoder die ich bis jetzt gebaut habe.

Gruß RENÈ

[MicroBahner]

Ok, hatte jetzt auch nicht erwartet, dass das dein Problem löst. Muss mal schauen, ob ich das hier nachvollziehen kann.
Ist das nur ein Problem beim Einschalten? Funktioniert das danach normal?

[fischi01]

Hallo Franz-Peter

Der Servo fährt schon beim Einschalten der Spannung weit über das Ziel hinaus.
Beim ersten Betätigen fährt er auf den eingestellten Winkel und ab da funktioniert alles.

Gruß RENÈ.

[Bodo]

Hallo,

falls ich jetzt nicht irgendwie nachtblind bin kommen durch die Doppelbelegung der Adressen die Servos an Pin 4,6,8,10 doch nie zum Zug, d.h. es wird auch nie was neues ins EEPROM geschrieben?
Wenn da für Pin6 mal irgendwann was falsches abgelegt wurde, wird das bei jedem Programmstart wieder ausgelesen.
Ich frag‘ mich eher, warum das überhaupt so funktioniert.

VG Bodo

Edit: OK, Auskommentierung des break übersehen ...

[MicroBahner]

Nun ja, da das break in der for-Schleife auskommentiert ist, vergleicht er immer alle Einträge mit der Solladresse. Damit sollte das eigentlich schon funktionieren.

[Zugsepp1012]

Hallo liebe Modellbahnfreunde,

ich bin unlängst auf diese Seite gestoßen und habe mich sofort verliebt. Eine wirkliche coole Bastellösung, bei der für jeden etwas dabei ist! Ein großes Lob und auch ein großer Dank an alle die hier gebastelt, entwickelt und mitgewirkt haben (und es werden). Eine wirkliche tolle Sache!

Ich habe mir natürlich auch gleich Bauteile bestellt und angefangen einen Dekoder für Weichenservos zu basteln. Auf Seite 1 gleich das Multitasking-Beispiel ausprobiert und der Servo läuft. Anschließend habe ich die DCC-Schaltung aufgebaut und den entsprechenden Code geladen und es hat nichts funktioniert - voller Einfahrer. Nach ein paar Stunden bin ich drauf gekommen, dass der Code offenbar nicht mit der aktuellen DCC-Bib zusammenpasst. Der Code auf Seite 20 funktioniert einwandfrei. Da muss man halt auch einmal drauf kommen. Und es zeigt sich wieder einmal - wer lesen kann ist klar im Vorteil

Deswegen würde ich gerne anmerken, dass man beim "Demo-Code" auf Seite 1 ergänzt, dass der aktuelle "Demo-Code"auf Seite 20 gefunden wird. Dann sparen sich die nächsten die Fehlersuche oder habe ich den Hinweis überlesen?

ABER - und das ist das wichtige - es funktioniert jetzt auch bei mir und ich kann nur noch einmal sagen, dass ihr (und vor allem Du Franz-Peter) tolle Arbeit geleistet habt! Ich werde dabei bleiben und vielleicht auch das ein oder andere Mal meinen Senf dazugeben