RE: Arduino MobaTools: V2.3.1 released

#76 von MicroBahner , 04.01.2016 18:06

Hallo Michel,
interessant, dass Du gerade jetzt mit diesen Fragen kommst. Die Platine mit dem Baustein PCA9685 kannte ich bisher nicht, und bin erst vor ganz kurzem durch die Mail eines anderen Stummis darauf aufmerksam geworden . Hat aber den Vorteil, dass ich das Datenblatt schon gelesen hatte, wie dein Beitrag reinkam

Zitat von Doomsday
Stimmt meine Annahme, daß bei einer prescaler-Frequenz von 50 Hz der counter 50-Mal in der Sekunde durchläuft? Meine bisherigen Berechnungen und Versuche scheinen das zu bestätigen.

'Prescaler-Frequenz' ist da vielleicht nicht der richtige Ausdruck, aber ich denke Du meinst das richtige: Der Prescaler muss so eingestellt sein, dass mit seiner Ausgangsfrequenz der folgende Zähler alle 20ms einmal komplett durchläuft. Dann bekommst Du eine PWM-Frequenz von 50Hz. Beim PCA9685 mit seinem 12-Bitzähler bedeutet das eine Frequenz am Ausgang des Prescalers von 50 x 4096 = 204,8kHz.

Zitat von Doomsday
Wenn ich die errechneten Werte benutze, ergibt das mit meinem Servo einen nutzbaren Kreisbogen von etwa 90 bis 100 Grad - doch deutlich weniger als die angegebenen 180 Grad. Wenn ich aber die Pulswerte entsprechend modifiziere, komme ich auf einen Kreisbogen von mehr als 180 Grad!

Nach meinen Erfahrungen ist die Toleranz bei den Servos - insbesondere bei den analogen - da recht groß. Aus dem Grund kann man z.B. bei der arduino Servo-Lib ( und auch bei den MobaTools ) die Pulslänge für 0Grad und für 180 Grad vorgeben.
Nominell entsprechen 1..2ms aber schon den von dir beobachteten ca. 0..100Grad. Bei digitalen Servos wird das auch wesentlich genauer eingehalten. Die reagieren auf Pulslängen die deutlich drüber oder drunter liegen gar nicht. Da erreicht man dann auch die 180 Grad nicht.

Zitat von Doomsday
Um den Servo in eine Position zu fahren, wird ein Ganzzahlwert angegeben, der dieser Position entspricht. Dieser Wert entspricht der Anzahl von counter "ticks", für die der Puls auf logisch 1 gesetzt sein soll. Dieser Wert aber hängt von zwei Faktoren ab, nämlich (a) der Generator-Frequenz, und (b) der counter "Auflösung". Ihr Zusammenspiel bestimmt, wie lang ein Puls von "2000" tatsächlich ist: Je höher Auflösung und Frequenz, desto kürzer dauert ein counter-"tick", und desto kürzer dauert der 2000 Puls in Realität. Umgekehrt muß die Pulszahl entsprechend erhöht werden, wenn Frequenz und Auflösung steigen, um die tatsächliche Pulsdauer konstant zu halten

Das ist so richtig. Da die Eingangsfrequenz und die Auflösung des Zählers in der Regel konstant sind (sein sollten ), lässt sich der Zählwert für die gewünschte Impulslänge eindeutig bestimmen und man ändert nur noch den Zählwert um die Pulslänge zu verändern. Bei dem verwendeten Baustein geht es auch gar nicht anders: Die Auflösung ist fest, da der Zähler immer bis zum Ende durchzählt, und die Eingangsfrequenz lässt sich auch nicht individuell, sondern nur für alle Zähler gemeinsam einstellen.

Zitat von Doomsday
Die tatsächliche Pulsdauer von "2000" errechnet sich also wie folgt: Dauer = 2000 / (4096 * 50) = 0,009765 s = 9,765 ms. Bei einer Frequenz von 100 Hz verkürzt sich diese auf ca. 4,88 ms, und bei einer Frequenz von 200 Hz - voreingestellt bei meinem Generator - entspricht dies lediglich 2,44 ms.

Auch das ist im Prinzip richtig. Um die Pulslänge zu ändern sollte man aber nun die '2000' ändern, und nicht die Taktfrequenz des Zählers. Die sollte schon fest so eingestellt sein, dass sich die 50Hz ergeben. Die Wiederholrate der Impulse ist für den Servo zwar nicht so relevant wie die Pulslänge, aber gerade bei einfachen Analogservos haben größere Abweichungen dann doch auch Auswirkungen auf die Position.

Zitat von Doomsday
Finale Frage: Bin ich hier komplett auf dem Holzweg, oder macht mein (sehr langer) Beitrag vielleicht doch Sinn?

Auf dem Holzweg bist Du gar nicht. Im Wesentlichen stimmt ja alles was Du schreibst.

P.S.

Zitat von Doomsday
Dem bei mir eingebauten Oszillator/prescaler System wurde bei einigen (wenigen) Quellen eine Abweichung von bis zu 15% angelastet

der interne 25MHz Oszillators des PCA9685 ist ja kein Quarzoszillator sondern ein einfacher RC-Oszillator. Da kann man sicher keine große Genauigkeit verlangen. Ist ja auch bezeichnend, dass im Datenblatt kein Wort über Toleranz und Stabilität des Oszillators verloren wird. Ok, wenn's nur darum geht Led's zu dimmen ist's auch weitgehend egal. Bei Servos könnte es anders sein - muss man testen.


viele Grüße
Franz-Peter
Ein 'elektromechanisches' Stellwerk
Der (ehemalige) 'Eisberg'


 
MicroBahner
Metropolitan (MET)
Beiträge: 2.833
Registriert am: 28.11.2012
Ort: Mittelfranken
Gleise Tillig Elite
Steuerung Eigenbau
Stromart Analog


RE: Arduino MobaTools: V2.3.1 released

#77 von Doomsday ( gelöscht ) , 05.01.2016 01:32

Hallo Franz-Peter,

Grrr, ich sitze hier, an meinen Fingernägeln beißend, auf heißen Kohlen sitzend, und warte auf die Benachrichtigung von Deiner Antwort - und die ist um Mitternacht London-Zeit immer noch nicht eingetroffen... Nur durch Zufall bin ich auf Deine Antwort gestoßen... GRRR

Genug Frust abgeladen, weiter zur Antwort auf die Antwort.

Zunächst mal vielen Dank, daß ich nun doch wieder Vertrauen in meinen Verstand gefaßt habe...

Im EInzelnen:

Zitat von MicroBahner
Hallo Michel,
interessant, dass Du gerade jetzt mit diesen Fragen kommst. Die Platine mit dem Baustein PCA9685 kannte ich bisher nicht, und bin erst vor ganz kurzem durch die Mail eines anderen Stummis darauf aufmerksam geworden . Hat aber den Vorteil, dass ich das Datenblatt schon gelesen hatte, wie dein Beitrag reinkam

Ja, der PCA9685 ist schon ein interessanter kleiner Sandhaufen - leider haben weder die China-Kopie als auch das Original-breakout von adafruit.com den Pin für einen externen Oszillator herausgeführt... Aber mit ein wenig Programmieren kann man das ja ganz gut hinbiegen.

Zitat von MicroBahner

Zitat von Doomsday
Stimmt meine Annahme, daß bei einer prescaler-Frequenz von 50 Hz der counter 50-Mal in der Sekunde durchläuft? Meine bisherigen Berechnungen und Versuche scheinen das zu bestätigen.

'Prescaler-Frequenz' ist da vielleicht nicht der richtige Ausdruck, aber ich denke Du meinst das richtige: Der Prescaler muss so eingestellt sein, dass mit seiner Ausgangsfrequenz der folgende Zähler alle 20ms einmal komplett durchläuft. Dann bekommst Du eine PWM-Frequenz von 50Hz. Beim PCA9685 mit seinem 12-Bitzähler bedeutet das eine Frequenz am Ausgang des Prescalers von 50 x 4096 = 204,8kHz.


Stimmt - die Formel dazu geben sie ja auch im Datenblatt an - nur sind die Werte weder eineindeutig, noch in sich genau, wenn man Excel o.å. zu Hilfe nimmt und mal die Zahlenreihen darstellt - eine mathematisch exakte (und damit vorhersagbare) Abbildung von prescaler-Wert auf Ausgangsfrequenz (am PWM pin, nicht am Prescaler) sieht anders aus.

Zitat von MicroBahner

Zitat von Doomsday
Wenn ich die errechneten Werte benutze, ergibt das mit meinem Servo einen nutzbaren Kreisbogen von etwa 90 bis 100 Grad - doch deutlich weniger als die angegebenen 180 Grad. Wenn ich aber die Pulswerte entsprechend modifiziere, komme ich auf einen Kreisbogen von mehr als 180 Grad!

Nach meinen Erfahrungen ist die Toleranz bei den Servos - insbesondere bei den analogen - da recht groß. Aus dem Grund kann man z.B. bei der arduino Servo-Lib ( und auch bei den MobaTools ) die Pulslänge für 0Grad und für 180 Grad vorgeben.
Nominell entsprechen 1..2ms aber schon den von dir beobachteten ca. 0..100Grad. Bei digitalen Servos wird das auch wesentlich genauer eingehalten. Die reagieren auf Pulslängen die deutlich drüber oder drunter liegen gar nicht. Da erreicht man dann auch die 180 Grad nicht.


Danke, danke, danke! Damit muß ich wohl die Angaben auf diversen Webseiten mit 'ner dicken Schaufel Salz zu mir nehmen, denn de reden meistens von saloppen 180 Grad... Dummerweise sind diese Werte bei meinen Servos innerhalb der Charge auch nicht konstant - aber Top-Qualität bei ca. 50 Pence pro Servo kann ich ja nicht wirklich erwarten

Zitat von MicroBahner
Das ist so richtig. Da die Eingangsfrequenz und die Auflösung des Zählers in der Regel konstant sind (sein sollten ), lässt sich der Zählwert für die gewünschte Impulslänge eindeutig bestimmen und man ändert nur noch den Zählwert um die Pulslänge zu verändern. Bei dem verwendeten Baustein geht es auch gar nicht anders: Die Auflösung ist fest, da der Zähler immer bis zum Ende durchzählt, und die Eingangsfrequenz lässt sich auch nicht individuell, sondern nur für alle Zähler gemeinsam einstellen.

Das ist mir schon klar - nur was, wenn ich mich irgendwann mal entscheide, einen Gemischtwarenladen an PWM-Geräten an dasselbe breakout zu hängen, die alle eher unterschiedliche Pulsperioden benötigen? Mag theoretisch klingen, aber LEDs mit 20 Hz Pulsperiode zu dimmen kommt bestimmt nur dann gut, wenn man Schweißlichter simulieren will In solchen Fällen muß ich den prescaler umstellen, um z.B. 200 Hz Pulsperioden zu erzeugen - und damit ändern sich ja die LED_ON- bzw. LED_OFF-Werte ganz gewaltig, um bei den geforderten 1 - 2 ms zu bleiben. Darauf, und den zugrunde liegenden Zusammenhang wollte ich hinaus.

Zitat von MicroBahner

Zitat von Doomsday
Die tatsächliche Pulsdauer von "2000" errechnet sich also wie folgt: Dauer = 2000 / (4096 * 50) = 0,009765 s = 9,765 ms. Bei einer Frequenz von 100 Hz verkürzt sich diese auf ca. 4,88 ms, und bei einer Frequenz von 200 Hz - voreingestellt bei meinem Generator - entspricht dies lediglich 2,44 ms.

Auch das ist im Prinzip richtig. Um die Pulslänge zu ändern sollte man aber nun die '2000' ändern, und nicht die Taktfrequenz des Zählers. Die sollte schon fest so eingestellt sein, dass sich die 50Hz ergeben. Die Wiederholrate der Impulse ist für den Servo zwar nicht so relevant wie die Pulslänge, aber gerade bei einfachen Analogservos haben größere Abweichungen dann doch auch Auswirkungen auf die Position.


Siehe oben. Das weißt Du bestimmt besser als ich, jedoch habe ich des öfteren gelesen, daß die Pulsperiode recht unerheblich ist, solange die Pulslänge in der ungefähren Bandbreite von 1 - 2 ms inklusive der Totzeit (bei meinen Servos: 10 usec) bleibt. Mit anderen Worten sollten Pulsperioden von 200 Hz auch für Billigservos kein Problem darstellen.

Zitat von MicroBahner
P.S.

Zitat von Doomsday
Dem bei mir eingebauten Oszillator/prescaler System wurde bei einigen (wenigen) Quellen eine Abweichung von bis zu 15% angelastet

der interne 25MHz Oszillators des PCA9685 ist ja kein Quarzoszillator sondern ein einfacher RC-Oszillator. Da kann man sicher keine große Genauigkeit verlangen. Ist ja auch bezeichnend, dass im Datenblatt kein Wort über Toleranz und Stabilität des Oszillators verloren wird. Ok, wenn's nur darum geht Led's zu dimmen ist's auch weitgehend egal. Bei Servos könnte es anders sein - muss man testen.


Schau' Dir mal den Quellcode der adafruit lib auf github an - die rechnen pauschal 10% der übergebenen Zielfrequenz heraus - d.h. aus 50 Hz Zielfrequenz machen die mal eben locker 45 Hz - und das über den gesamten Frequenzbereich von 24 Hz bus gut 1,5 kHz...

Aber wie gesagt, vielen Dank für Deine Bestätigung. Ein schönes Neujahrsgeschenk!

Übrigens, man glaubt es kaum, aber ich hantiere mit Java 8 auf dem Raspberry Pi 'rum - das geht sehr gut, und mit den Java 8 embedded Profilen bekomme ich auch erstaunlich kleine VMs hin, die auch sehr stabil und schnell laufen. Als nächstes - wenn wieder verfügbar - will ich mal Java auf Raspberry Pi Zeros loslassen - für 4 GBP das Stück ist der Preis absolut unschlagbar!

LG,
Michel


Doomsday

RE: Arduino MobaTools: V2.3.1 released

#78 von MicroBahner , 05.01.2016 11:16

Hallo Michel,

Zitat von Doomsday
Stimmt - die Formel dazu geben sie ja auch im Datenblatt an - nur sind die Werte weder eineindeutig, noch in sich genau, wenn man Excel o.å. zu Hilfe nimmt und mal die Zahlenreihen darstellt - eine mathematisch exakte (und damit vorhersagbare) Abbildung von prescaler-Wert auf Ausgangsfrequenz (am PWM pin, nicht am Prescaler) sieht anders aus.

Hmm - Die Formel im Datenblatt sieht ja so aus: Wo hast Du da denn ein Problem? Meiner Meinung nach ist das doch ok. Natürlich gibt die Formel nicht die Ausgangsfrequenz des Prescalers an, sondern das Teilerverhältnis. Das ist ja auch der für die Programmierung des Prescalers entscheidende Wert.

Zitat von Doomsday
nur was, wenn ich mich irgendwann mal entscheide, einen Gemischtwarenladen an PWM-Geräten an dasselbe breakout zu hängen, die alle eher unterschiedliche Pulsperioden benötigen?

Dafür ist der PC9685 schlichtweg nicht geeignet, da der Prescaler grundsätzlich für alle Ausgänge gilt. Man muss sich schon klarmachen, dass dieser Baustein nicht für solche Anwendungen konzipiert wurde, sondern ursprünglich nur für das Dimmen von Led's gedacht ist.

Zitat von Doomsday
..jedoch habe ich des öfteren gelesen, daß die Pulsperiode recht unerheblich ist, solange die Pulslänge in der ungefähren Bandbreite von 1 - 2 ms inklusive der Totzeit (bei meinen Servos: 10 usec) bleibt. Mit anderen Worten sollten Pulsperioden von 200 Hz auch für Billigservos kein Problem darstellen.

Hast Du das ausprobiert? Mit meinen analogen Servos geht das definitiv nicht. Die haben schon bei 100Hz Probleme. Da funktioniert einfach die interne Regelung nicht mehr ordentlich. Bei 200Hz positionieren sie gar nicht mehr reproduzierbar.
Bei digitalen Servos ist das anders. Die haben auch bei 200Hz keine Probleme (zumindest die die ich habe nicht).


viele Grüße
Franz-Peter
Ein 'elektromechanisches' Stellwerk
Der (ehemalige) 'Eisberg'


 
MicroBahner
Metropolitan (MET)
Beiträge: 2.833
Registriert am: 28.11.2012
Ort: Mittelfranken
Gleise Tillig Elite
Steuerung Eigenbau
Stromart Analog


RE: Arduino MobaTools: V2.3.1 released

#79 von MicroBahner , 05.01.2016 11:33

Hallo, ich hab' mal im Eingangspost ein Inhaltsverzeichnis der bisher vorgestellten Beispiel gemacht.


viele Grüße
Franz-Peter
Ein 'elektromechanisches' Stellwerk
Der (ehemalige) 'Eisberg'


 
MicroBahner
Metropolitan (MET)
Beiträge: 2.833
Registriert am: 28.11.2012
Ort: Mittelfranken
Gleise Tillig Elite
Steuerung Eigenbau
Stromart Analog


RE: Arduino MobaTools: V2.3.1 released

#80 von Doomsday ( gelöscht ) , 05.01.2016 11:47

Hallo Franz-Peter,

Zitat von MicroBahner

Zitat von Doomsday
Stimmt - die Formel dazu geben sie ja auch im Datenblatt an - nur sind die Werte weder eineindeutig, noch in sich genau, wenn man Excel o.å. zu Hilfe nimmt und mal die Zahlenreihen darstellt - eine mathematisch exakte (und damit vorhersagbare) Abbildung von prescaler-Wert auf Ausgangsfrequenz (am PWM pin, nicht am Prescaler) sieht anders aus.

Hmm - Die Formel im Datenblatt sieht ja so aus: Wo hast Du da denn ein Problem? Meiner Meinung nach ist das doch ok. Natürlich gibt die Formel nicht die Ausgangsfrequenz des Prescalers an, sondern das Teilerverhältnis. Das ist ja auch der für die Programmierung des Prescalers entscheidende Wert.


Das Problem liegt in der Rundung der Deimalzahlen zu Ganzzahlen. Im Mittelbereich der Funktion ist das noch in Ordnung, aber sobald man davon etwas abrückt, wird's recht uneindeutig - siehe Angehängter Excel-Export: [attachment=0]PWM Duty cycle calculations.pdf[/attachment] Wenn ich z.B. einen prescaler Wert von "30" setze, kann das nach Formel Frequenzen von 194 - 200 Hz erzeugen - und bei kleineren Prescalerwerten wird das noch extremer. Vieleicht bin ich aber auch zu mathematisch vorbelastet, und zuwenig Elektrotechniker

Zitat von MicroBahner

Zitat von Doomsday
nur was, wenn ich mich irgendwann mal entscheide, einen Gemischtwarenladen an PWM-Geräten an dasselbe breakout zu hängen, die alle eher unterschiedliche Pulsperioden benötigen?

Dafür ist der PC9685 schlichtweg nicht geeignet, da der Prescaler grundsätzlich für alle Ausgänge gilt. Man muss sich schon klarmachen, dass dieser Baustein nicht für solche Anwendungen konzipiert wurde, sondern ursprünglich nur für das Dimmen von Led's gedacht ist.


Das war auch ein rhetorisches Extrembeispiel Ein durchaus realistischeres Beispiel sind Servos unterschiedlicher Hersteller, deren Datenblätter unterschiedliche Pulsperioden spezifizieren. Da muß ich einen Mittelwert für den prescaler finden, und die Werte entsprechend anpassen.

Zitat von MicroBahner

Zitat von Doomsday
..jedoch habe ich des öfteren gelesen, daß die Pulsperiode recht unerheblich ist, solange die Pulslänge in der ungefähren Bandbreite von 1 - 2 ms inklusive der Totzeit (bei meinen Servos: 10 usec) bleibt. Mit anderen Worten sollten Pulsperioden von 200 Hz auch für Billigservos kein Problem darstellen.

Hast Du das ausprobiert? Mit meinen analogen Servos geht das definitiv nicht. Die haben schon bei 100Hz Probleme. Da funktioniert einfach die interne Regelung nicht mehr ordentlich. Bei 200Hz positionieren sie gar nicht mehr reproduzierbar.
Bei digitalen Servos ist das anders. Die haben auch bei 200Hz keine Probleme (zumindest die die ich habe nicht).


Nein, habe ich (natürlich) nicht - jedenfalls noch nicht. Aber dank Dir komme ich ja jetzt viel weiter - und werde es hoffentlich heute abend mal umsetzen. Vielleicht mache ich davon auch ein kleines Video

LG,
Michel

Dateianlage:
Sie haben nicht die nötigen Rechte, um die angehängten Dateien zu sehen

Doomsday

RE: Arduino MobaTools: V2.3.1 released

#81 von MicroBahner , 05.01.2016 15:07

Hallo Michel,

Zitat von Doomsday
Wenn ich z.B. einen prescaler Wert von "30" setze, kann das nach Formel Frequenzen von 194 - 200 Hz erzeugen - und bei kleineren Prescalerwerten wird das noch extremer. Vieleicht bin ich aber auch zu mathematisch vorbelastet, und zuwenig Elektrotechniker

Ja, das ist die Crux mit den digitalen Schaltungen, die verhalten sich nunmal nicht kontinuierlich . Mit so einer einfache Prescaler Schaltung kann man schlichtweg nicht alle gewünschten Frequenzen erzeugen. Die Formel gibt für den Prescaler einen Wert aus, bei dem die erzeugte Frequenz möglichst nahe am gewünschten Wert liegt. Das ist dann nicht eindeutig, weil mehrere Vorgabefrequenzen zum gleichen Ergebnis führen können. Eine Tabelle macht eigentlich nur umgekehrt Sinn: Die Formel so umstellen, dass für einen vorgegeben Prescaler-Wert die erzeugte Frequenz berechnet wird. [attachment=0]PCA9685-Prescaler.pdf[/attachment]
Die Tabelle ist dann eindeutig und zeigt alle erzeugbaren Frequenzen - andere gehen einfach nicht. Wobei in der Praxis die tatsächlichen Frequenzen - jedenfalls mit dem internen Oszillator - eh nicht so genau sind.


viele Grüße
Franz-Peter
Ein 'elektromechanisches' Stellwerk
Der (ehemalige) 'Eisberg'

Dateianlage:
Sie haben nicht die nötigen Rechte, um die angehängten Dateien zu sehen

 
MicroBahner
Metropolitan (MET)
Beiträge: 2.833
Registriert am: 28.11.2012
Ort: Mittelfranken
Gleise Tillig Elite
Steuerung Eigenbau
Stromart Analog


RE: Arduino MobaTools: V2.3.1 released

#82 von Doomsday ( gelöscht ) , 05.01.2016 16:03

Hallo Franz-Peter,

Zitat von MicroBahner
Die Tabelle ist dann eindeutig und zeigt alle erzeugbaren Frequenzen - andere gehen einfach nicht. Wobei in der Praxis die tatsächlichen Frequenzen - jedenfalls mit dem internen Oszillator - eh nicht so genau sind.


Ich hatte - wohl zu simplifizierend - angenommen, daß der Chip lediglich ganzzahlige PWM-Frequenzen erzeugen kann. Bin halt in der Tat kein Elektrotechniker

LG,
Michel


Doomsday

RE: Arduino MobaTools: V2.3.1 released

#83 von Doomsday ( gelöscht ) , 05.01.2016 22:55

Sooooo liebe Leute, Franz-Peter,

Ich habe mal auf die Schnelle ein Video gedreht (das muß ich noch ein klitzekleinwenig schneiden), und dann wird das hoffentlich hier bald online stehen.

Soviel steht aber fest: Meinen kleinen Billigst-Servos ist die Pulsperiode vollkommen egal, jedenfalls im bereich zwischen 50 und 200 Hz.



LG,
Michel

EDITH sagt: Wieso sehe ich hier keine Vorschau!?

EDITH's Zwilling sagt: Jetzt auch mit Vorschau


Doomsday

RE: Arduino MobaTools: V2.3.1 released

#84 von Doomsday ( gelöscht ) , 06.01.2016 00:22

Kleiner Nachtrag:

Ich habe den Servo spaßeshalber mal mit einem deutlich erweitertem Spektrum "bombardiert"

Mit 25 Hz am unteren Ende hat er keinerlei Probleme. Am anderen Ende des Spektrums...

300 Hz - da lacht das Herz bzw. die Servogabel

400 Hz - immer noch kein Murren an der Servo-Front

450 Hz - der arbeitet ja immer noch gut vor sich hin!

500 Hz - da steigt er aus, was aber auch zu erwarten war, weil bei dieser Frequenz ein kompletter counter-Durchlauf von 4096 ticks fast exakt 2 ms entspricht

ich werde jetzt aber nicht die Grenzen der Unendlichkeit diese Servos austesten - ich habe meine Antworten.

LG,
Michel


Doomsday

RE: Arduino MobaTools: V2.3.1 released

#85 von MicroBahner , 06.01.2016 09:41

Hallo Michel,
da hast Du ja ausgesprochen perfekte Exemplare erwischt .

Zitat von Doomsday
EDITH sagt: Wieso sehe ich hier keine Vorschau!?


Ich mach es immer so:

1
 
[youtube]https://youtube.com/watch?v=z7sjRSobqMw[/youtube]
 



Edit: Das jetzt oben geht, schmeiss ich's hier raus


viele Grüße
Franz-Peter
Ein 'elektromechanisches' Stellwerk
Der (ehemalige) 'Eisberg'


 
MicroBahner
Metropolitan (MET)
Beiträge: 2.833
Registriert am: 28.11.2012
Ort: Mittelfranken
Gleise Tillig Elite
Steuerung Eigenbau
Stromart Analog


RE: Arduino MobaTools: V2.3.1 released

#86 von Doomsday ( gelöscht ) , 06.01.2016 15:06

Hallo Franz-Peter,

Ich dachte, das sei normal bei Servos...

Und jetzt weiß ich auch, warum das mit dem Youtube-Link nicht funktioniert - der BB-Code [youtube] triggert auf "youtube.com" und eben nicht auf "youtu.be"... Wieder 'was gelernt

LG,
Michel

P.S.: Nachstes Ziel: Servogeschwindigkeit einstellen...


Doomsday

RE: Arduino MobaTools: V2.3.1 released

#87 von MicroBahner , 06.01.2016 20:21

Zitat von Doomsday
Ich dachte, das sei normal bei Servos...

Vielleicht habe ich ja die 'Ausreisser' :

Zitat von Doomsday
Nachstes Ziel: Servogeschwindigkeit einstellen...

Tja, in deiner Konstellation helfen dir die MobaTools da leider nicht...


viele Grüße
Franz-Peter
Ein 'elektromechanisches' Stellwerk
Der (ehemalige) 'Eisberg'


 
MicroBahner
Metropolitan (MET)
Beiträge: 2.833
Registriert am: 28.11.2012
Ort: Mittelfranken
Gleise Tillig Elite
Steuerung Eigenbau
Stromart Analog


RE: Arduino MobaTools: V2.3.1 released

#88 von Doomsday ( gelöscht ) , 06.01.2016 21:05

Hallo Franz-Peter,

Zitat von MicroBahner

Zitat von Doomsday
Nachstes Ziel: Servogeschwindigkeit einstellen...

Tja, in deiner Konstellation helfen dir die MobaTools da leider nicht...


Doch, das tun sie - wenn auch nicht als Bibliothek, sondern im Quellcode!

Also, mach' bitte weiter mot den MobaTools

LG,
Michel


Doomsday

RE: Arduino MobaTools: V2.3.1 released

#89 von MicroBahner , 19.02.2016 11:26

Hallo liebe Stummis und Arduino-Interessierte,
in meinem Thread zur Bahnschranke kam der Wunsch auf, auch einen reinen Zubehör-decoder zu haben, der über CV's konfigurierbar ist. Ich habe mich deshalb mal daran gemacht sowas zu erstellen. Der hier weiter oben vorgestellte Servodecoder ist ja seeeehr einfach und war eher als Demo, denn als praktisch einsetzbarer Decoder gedacht. Der nun entstehende Decoder geht über eine Demo doch deutlich hinaus, und soll auch 'einsatztauglich' werden. In der hier vorgestellten Stufe ist er allerdings noch ein reiner Servodecoder. Die Software ist aber schon so vorgesehen, dass daraus ein unverseller konfigurierbarer Schaltartikeldecoder entstehen kann. Sollte daran Interesse bestehen, werde ich die weiteren Entwicklungsschritte aber wohl in einem eigenen Thread vorstellen - ist ja nicht mehr wirklich eine 'demo' für die MoBa Tools.
Folgende Eigenschaften habe ich jetzt mal vorgesehen:

  • Zubehördecoder für bis zu 8 Zubehör(Weiche) Adressen. Der Decoder belegt einen aufeinanderfolgenden Block von 8 Weichenadressen.
  • Die Startadresse ist über einen Programmierschalter einstellbar. Bei aktivem Programmiermodus bestimmt das erste empfangene Weichentelegramm die Basisadresse
  • Die Eigenschaften der Zubehörausgänge sind per CV konfigurierbar. Pro Zubehöradresse sind 4 CV's vorgesehen (ab CV50)
  • Im eingebauten Zustand ist eine Programmierung über PoM möglich. Voreingestellte PoM-Adresse ist 50. Auch bei mehreren Decodern muss diese nicht angepasst werden, da die PoM-Programmierung nur im Programmiermodus (Schalter) aktiv ist. Die Service-Mode Programmierung am Programmiergleis ist immer möglich.
  • Für jede Weichenadresse sind 2 Ausgänge vorgesehen. Bei Servo's wird der 2. Ausgang für die Ansteuerung eines Polarisierungsrelais verwendet (das schaltet in der Mitte der Servobewegung)
  • Beim Servo-Ausgang werden die Endlagen ( als Winkel 0...180 ) und die Geschwindigkeit in CV's gespeichert. Wird die CV der gerade aktiven Endlage verändert, so wird das Servo sofort entsprechend nachgeführt. Das erleichtert die Einstellung der Endlage.
  • Folgende Funktionalitäten habe ich mal angedacht (individuell per CV für jede Subadresse einstellbar):
    [list]
  • Servo mit dauerhafter Ausgabe der Impulse
  • Servo mit automatischer Impulsabschaltung bei erreichen der Endlage
  • Doppelspulenantrieb - Impulsabschaltung durch DCC-Kommando
  • Doppelspulenantrieb - automatische Impulsabschaltung
  • Statischer Ausgang (Ein/Aus)
  • Blink-Ausgang - auch mit Soft On/Off (nur bei PWM-fähigen Pins)
[/list]

Der hier vorgestellte Code ist eine erste Version, die die beiden ersten Punkte (Servo's) implementiert hat. Es ist auch noch nicht in allen Details ausgetest. Wäre schön, wenn sich hier Tester finden. Unabhängige Tests sind immer gut .

Wie gesagt, bei Interesse würde ich die Software entsprechend weiterentwickeln. Ihr könnt auch Ideen einbringen und wir hätten nicht nur 'Stummi-Wagen' und 'Stummi-Lok', sondern auch einen 'Stummi-Decoder' .
Dann könnten auch die sich einen Zubehördecoder basteln, die zwar gern ein bisschen mit Elektronik und Lötkolben umgehen, aber nicht so firm im Programmieren sind. Vielleicht findet sich ja auch irgendwann mal jemand der eine dazu passende Leiterplatte entwickelt...
Aber das ist noch arge Zukunftsmusik . Vielleicht besteht ja auch nicht so das Interesse am x-ten Decoder, und das hier ist für die Tonne - dann lassen wir's eben , macht auch nix .

Aber jetzt erstmal der Schaltplan:
[attachment=0]Zubehoerdecoder_universal.pdf[/attachment]
und der Code:

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
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
 
#include <NmraDcc.h>
#include <MobaTools.h>
 
/* Demo: ein universeller Dcc-Zubehördecoder
* Version 0.1 - erstmal nur Servos
* ----------------------------------------
* Eigenschaften:
* Bis zu 8 (aufeinaderfolgende) Zubehöradressen ansteuerbar
* 1. Adresse per Programmierung einstellbar
*
* 2 Ausgänge / Zubehöradresse
* Einstellbare Funktionalität:
* - Servo mit Umschaltrelais zur Weichenpolarisierung
* - Doppelspulenantriebe
* - statische Ausgänge
* - blinkende Ausgänge
*
* Die Funnktionalität wird über CV-Programmierung festgelegt. Bei Servoausgängen
* sind die Endlagen per CV-Wert einstellbar
*/
//------------------------------------------ //
// die NmraDcc - Library gibt es unter https://github.com/mrrwa/NmraDcc/archive/master.zip
// oder, ohne Benutzung des Timer0 (PWM an Pin 5 und 6 funktioniert):
// https://github.com/MicroBahner/NmraDcc/archive/Without-use-of-HW-timers.zip
 
// --------- gegebenenfalls anzupassende Konstante ( nicht über CV änderbar) --------------------
#define DCC_DECODER_VERSION_ID 01
//#define DEBUG ; // Wenn dieser Wert gesetzt ist, werden Debug ausgaben auf dem ser. Monitor ausgegeben
// Pin-Festlegungen
const byte progPin = 0 ; // CV-Programmierung nur möglich, wenn auf 0
const byte isROCO = 0 ; // wegen unterschiedlicher Weichenadressberechnung bei Roco (sonst = 0)
const byte servoPins[] = { 3, 5, 9, 7, 12, A0, A2, A4}; // output-pin der Servos
const byte relaisPins[] = { 11, 6, 10, 8, 13, A1, A3, A5};
const byte WeichenZahl = sizeof(servoPins);
const byte dccPin = 2;
const byte ackPin = 4;
const byte modePin = 1; // leuchtet im Programier(Pom) Modus. Da dies auch der serielle
// Ausgang ist, funktinoert die Led nicht im Debug-Modus
 
//-------------------------------Definition der CV-Adressen ---------------------------------------
// Initiierungswerte ( zunächst nur Servo möglich) :
// Mögliche Funktionstypen je Ausgang. Derzeit sind nur die Servofunktionen implementiert
#define FOFF 0 // Funktionsausgang abgeschaltet
#define FSERVO 1 // Standardservoausgang (Impulse liegen dauerhaft an)
#define FSERVOAUTO 2 // automatische abschaltung der Servoimpulse nach erreichen der Zielposition
#define FDOPPELSPULE 3 // Magnetartikel, Ausgang wird nicht automatisch abgeschaltet
#define FDSAUTO 4 // Magnetartikel, Ausgang ist Momentimpuls
#define FSTATISCH 5 // Der Ausgang wird statisch ein bzw ausgeschaltet
#define FBLINKEN 6 // Der Ausgang Blinkt
#define FMAX 6
 
const byte DccAddr = 1; // DCC-Decoderadresse
const byte PomAddr = 50; // Adresse für die Pom-Programmierung
const byte iniTyp[] = { FSERVOAUTO, FSERVOAUTO, FSERVOAUTO, FSERVOAUTO, FSERVOAUTO, FSERVOAUTO, FSERVOAUTO, FSERVOAUTO };
const byte iniServoGerade = 0; // = Par1;
const byte iniServoAbzw = 180; // = Par2;
const byte speed = 8; // = Par3;
 

#define CV_START 47 // Startadresse des Decoderspezifischen CV-Blocks
typedef struct { // Definition der Struktur des decoderspezifischen CV-Blocks
byte initVal; // =0x55 wenn die CV-Werte initiiert sind.
byte PomAddrLow; // Adresse für die POM-Programmierung
byte PomAddrHigh;
struct {
byte Typ; // Funktionalität des Ausgangs
byte Par1; // Servo: Position AUS ( 0...180 Grad )
// DoppelspuleAuto: Einschaltzeit ( 10ms-Schritte )
// FBlinken: Einschaltphase des Blinkens ( 10ms Schritte )
byte Par2; // Servo: Position EIN ( 0...180 Grad )
// DoppelspuleAuto: Einschaltzeit Ausgang 2 ( 10ms-Schritte )
// FBlinken: Ausschaltphase des Blinkens ( 10ms Schritte )
byte Par3; // Servo: Speed
} Fkt [WeichenZahl];
} CvVar_t;
 
const CvVar_t *CV = (CvVar_t *) CV_START; //Pointer auf die decoderspezifischen CV-Werte im EEProm
 
// CV Default-Werte der Standardadressen:
struct CVPair {
uint16_t CV;
uint8_t Value;
};
CVPair FactoryDefaultCVs [] =
{
{CV_ACCESSORY_DECODER_ADDRESS_LSB, DccAddr%256},
{CV_ACCESSORY_DECODER_ADDRESS_MSB, DccAddr/256},
{CV_VERSION_ID, DCC_DECODER_VERSION_ID},
{CV_MANUFACTURER_ID, MAN_ID_DIY},
{CV_29_CONFIG, 0b11000000},
};
 
// ----------------------- Variable ---------------------------------------------------
word weichenAddr; // Addresse der 1. Weiche (des 8er Blocks)
byte weicheSoll[WeichenZahl]; // Solllage der Weichen
byte weicheIst[WeichenZahl]; // Istlagen der Weichen
#define GERADE 0x0
#define ABZW 0x1
#define MOVING 0x2 // nur für Ist-Zustand, Bit 1 gesetzt während Umlauf
 
//int geradePulse[WeichenZahl] ; // Pulslänge geradeaus
//int abzweigPulse[WeichenZahl]; // Pulslänge abzweigend
 
byte relaisOut[WeichenZahl]; // Ausgabewerte für die Relais ( 0/1, entspricht Sollwert )
 
byte progMode; // Merker ob Decoder im Programmiermodus
#define NORMALMODE 0
#define ADDRMODE 1 // Warte auf 1. Telgramm zur Bestimmung der ersten Weichenadresse
#define PROGMODE 2 // Adresse empfangen, POM-Programmierung möglich
 
Servo8 weicheS[WeichenZahl];
EggTimer AckImpuls;
EggTimer ledTimer; // zum Blinken der Programmierled
NmraDcc Dcc;
 

// für debugging
#ifdef DEBUG
#define DB_PRINT( ... ) { sprintf( dbgbuf,"Dbg: " __VA_ARGS__ ) ; Serial.println( dbgbuf ); }
byte debug;
char dbgbuf[80];
#define SET_PROGLED
#define CLR_PROGLED
#else
#define DB_PRINT ;
#define SET_PROGLED digitalWrite( modePin, HIGH )
#define CLR_PROGLED digitalWrite( modePin, LOW )
#endif
 
//###################### Ende der Definitionen ##############################
//###########################################################################
void setup() {
pinMode( modePin, OUTPUT );
digitalWrite( modePin, LOW );
// Auf Programmmiermodus prüfen
pinMode ( progPin, INPUT_PULLUP);
if ( digitalRead( progPin) == LOW )
progMode = ADDRMODE;
else
progMode = NORMALMODE;

delay( 1000 );

#ifdef DEBUG
pinMode( modePin, INPUT );
Serial.begin(115200); //Debugging
if ( progMode == NORMALMODE )
Serial.println( "Normal Start of Program" );
else
Serial.println( "PoM Start of Program" );
#endif

pinMode( ackPin, OUTPUT );
Dcc.pin( digitalPinToInterrupt(dccPin), dccPin, 1);
if ( progMode == NORMALMODE ) {
Dcc.init( MAN_ID_DIY, 15, FLAGS_DCC_ACCESSORY_DECODER, (uint8_t)((uint16_t) 0) );
CLR_PROGLED;
} else {
Dcc.init( MAN_ID_DIY, 15, FLAGS_DCC_ACCESSORY_DECODER, (uint8_t)((uint16_t) &CV->PomAddrLow) );
SET_PROGLED;
}

// Wenn in initVal kein sinnvoller Wert steht wird alles initiiert.
// Wird über DCC ein 'factory-Reset' empfangen wird dieser Wert zurückgesetzt, was beim nächsten
// Start ebenfalls zum initiieren führt.
if ( Dcc.getCV( (int) &CV->initVal) != 0x55 ) {
// alles initiieren mit den Defaultwerten
// Standard-CV's
for ( byte i=0; i<(sizeof(FactoryDefaultCVs) / sizeof(CVPair)); i++ ) {
Dcc.setCV( FactoryDefaultCVs[i].CV, FactoryDefaultCVs[i].Value);
}
// Decoderspezifische CV's
Dcc.setCV( (int) &CV->PomAddrLow, PomAddr%256 );
Dcc.setCV( (int) &CV->PomAddrHigh, PomAddr/256 );
for ( byte i = 0; i<WeichenZahl; i++ ) {
Dcc.setCV( (int) &CV->Fkt[i].Typ, iniTyp[i] );
Dcc.setCV( (int) &CV->Fkt[i].Par1, iniServoGerade );
Dcc.setCV( (int) &CV->Fkt[i].Par2, iniServoAbzw );
Dcc.setCV( (int) &CV->Fkt[i].Par3, speed );
}
Dcc.setCV( (int) &CV->initVal, 0x55 );
} //--- Ende Grundinitiierung ---------------------------------
 
// Adresse der 1. Weiche aus Decoderaddresse berechnen
weichenAddr = (Dcc.getAddr( )-1)*4 +1 +isROCO;
DB_PRINT( "BoardAdr: %d, weichenAddr: %d" ,Dcc.getAddr( ), weichenAddr );
for ( byte i=0; i<WeichenZahl; i++ ) {
// Funktionen initiieren
byte autoOff = 0;
switch ( Dcc.getCV( (int) &CV->Fkt[i].Typ ) ) {
case FSERVOAUTO:
autoOff = 1;
case FSERVO:
weicheS[i].attach( servoPins[i], autoOff );
weicheS[i].setSpeed( Dcc.getCV( (int) &CV->Fkt[i].Par3 ) );
pinMode( relaisPins[i], OUTPUT );
break;
}
}
}
////////////////////////////////////////////////////////////////
void loop() {
Dcc.process(); // Hier werden die empfangenen Telegramme analysiert und der Sollwert gesetzt
 
// Servos und Relais ansteuern
for ( byte i=0; i<WeichenZahl; i++ ) {
switch ( Dcc.getCV( (int) &CV->Fkt[i].Typ ) ) {
case FSERVO:
case FSERVOAUTO: // Servoausgänge ansteuern
if ( weicheIst[i] & MOVING ) {
// Weiche wird gerade ungestellt, Schaltpunkt Relais und Bewegungsende überwachen
if ( weicheS[i].moving() < 50 ) relaisOut[i] = weicheIst[i]& 0x1;
if ( weicheS[i].moving() == 0 ) weicheIst[i] &= 0x1; // Bewegung abgeschlossen, 'MOVING'-Bit löschen
} else if ( weicheSoll[i] != weicheIst[i] ) {
// Weiche muss umgestellt werden
DB_PRINT( "WeicheIx=%d stellen, Ist=%d,Soll=%d", i, weicheIst[i], weicheSoll[i] );
weicheIst[i] = weicheSoll[i] | MOVING; // Istwert auf Sollwert und MOVING-Bit setzen.
if ( weicheSoll[i] == GERADE ) {
weicheS[i].write( Dcc.getCV( (int) &CV->Fkt[i].Par1 ) );
} else {
weicheS[i].write( Dcc.getCV( (int) &CV->Fkt[i].Par2 ) );
}
}
}
}
 
// Relaisausgänge setzen
for ( byte i=0; i<WeichenZahl; i++ ) {
digitalWrite( relaisPins[i], relaisOut[i] );
}
 
if ( !AckImpuls.running() ) digitalWrite( ackPin, LOW );
 
// Programmierled blinkt im Programmiermode nach dem Empfang einer Adresse
if ( ! ledTimer.running() && progMode == PROGMODE) {
ledTimer.setTime( 500 );
if ( digitalRead( modePin ) )
CLR_PROGLED;
else
SET_PROGLED;
}
}
//////////////////////////////////////////////////////////////
// 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
// Im Programmiermodus bestimmt das erste empfangen Programm die erste Weichenadresse
if ( progMode == ADDRMODE ) {
// Adresse berechnen und speichern
Dcc.setCV( CV_ACCESSORY_DECODER_ADDRESS_LSB, BoardAddr%64 );
Dcc.setCV( CV_ACCESSORY_DECODER_ADDRESS_MSB, BoardAddr/64 );
weichenAddr = (Dcc.getAddr( )-1)*4 +1 +isROCO;
progMode = PROGMODE;
DB_PRINT( "Neu: Boardaddr: %d, 1.Weichenaddr: %d", BoardAddr, weichenAddr );
}
// Testen ob eigene Weichenadresse
DB_PRINT( "DecAddr=%d, Weichenadresse: %d , Ausgang: %d, State: %d", BoardAddr, wAddr, OutputAddr, State );
for ( byte i = 0; i < WeichenZahl; i++ ) {
if ( wAddr == weichenAddr+i ) {
// ist eigene Adresse, Sollwert setzen
weicheSoll[i] = OutputAddr & 0x1;
DB_PRINT( "Weiche %d, Index %d, Status %d", wAddr, i, weicheSoll[i] );
break; // Schleifendurchlauf abbrechen, es kann nur eine Weiche sein
}
}
}
//---------------------------------------------------
// wird aufgerufen, wenn die Zentrale ein CV ausliest. Es wird ein 60mA Stromimpuls erzeugt
void notifyCVAck ( void ) {
// Ack-Impuls starten
//DB_PRINT( "Ack-Pulse" );
AckImpuls.setTime( 6 );
digitalWrite( ackPin, HIGH );
}
//-----------------------------------------------------
// Wird aufgerufen, nachdem ein CV-Wert verändert wurde
void notifyCVChange( uint16_t CvAddr, uint8_t Value ) {
// Es wurde ein CV verändert. Ist dies eine aktive Servoposition, dann die Servoposition
// entsprechend anpassen
DB_PRINT( "neu: CV%d=%d", CvAddr, Value );
for ( byte i=0; i<WeichenZahl; i++ ) {
// prüfen ob Ausgang einen Servo ansteuert:
switch ( Dcc.getCV( (uint16_t) &CV->Fkt[i].Typ ) ) {
case FSERVO:
case FSERVOAUTO:
// gehört der veränderte CV zu diesem Servo?
if ( (CvAddr == (uint16_t) &CV->Fkt[i].Par1 && weicheSoll[i] == GERADE) ||
(CvAddr == (uint16_t) &CV->Fkt[i].Par2 && weicheSoll[i] == ABZW ) ){
// Es handelt sich um die aktuelle Position des Servos,
// Servo neu positionieren
DB_PRINT( "Ausg.%d , Pos. %d neu einstellen", i, weicheSoll[i] );
weicheS[i].write( Value );
} else if ( CvAddr == (uint16_t) &CV->Fkt[i].Par3 ) {
// die Geschwindigkeit des Servo wurde verändert
weicheS[i].setSpeed( Value );
}
}
}
}
//-----------------------------------------------------
void notifyCVResetFactoryDefault(void) {
// Auf Standardwerte zurücksetzen. Hier wird nur ein Merker gesetzt, das eigentliche Rücksetzen findet
// beim nächsten Neustart statt.
Dcc.setCV( (int) &CV->initVal, 255 );
}
//------------------------------------------------------
#ifdef DEBUG
void notifyDccReset( uint8_t hardReset ) {
DB_PRINT("Reset empfangen");
}
#endif
//--------------------------------------------------------
void softReset(void){
;asm volatile (" jmp 0");
}
 


Edit: Hinweis von Thomas in den Sketch eingebaut


viele Grüße
Franz-Peter
Ein 'elektromechanisches' Stellwerk
Der (ehemalige) 'Eisberg'

Dateianlage:
Sie haben nicht die nötigen Rechte, um die angehängten Dateien zu sehen

 
MicroBahner
Metropolitan (MET)
Beiträge: 2.833
Registriert am: 28.11.2012
Ort: Mittelfranken
Gleise Tillig Elite
Steuerung Eigenbau
Stromart Analog


RE: Arduino MobaTools: V2.3.1 released

#90 von Mape71 ( gelöscht ) , 19.02.2016 12:06

Hallo Franz-Peter,

das ist ja super, vielen Dank schon einmal. Ich werde in der nächsten Woche mal anfangen zu basteln und dann Rückmeldung geben. Bei Deiner Beschreibung der über CV zu konfigurierenden Parameter wäre sicher die Servodrehgeschwindigkeit noch spannend, da dies ja final erst nach dem Einbau eingestellt wird. Das aber nur schon mal für den weiteren Verlauf.

1000 Dank und Grüße

Marko


Mape71

RE: Arduino MobaTools: V2.3.1 released

#91 von MicroBahner , 19.02.2016 12:15

Hallo Marko,

Zitat von Mape71
Bei Deiner Beschreibung der über CV zu konfigurierenden Parameter wäre sicher die Servodrehgeschwindigkeit noch spannend

Das geht schon. Der 4er Block der CV's ist derzeit so belegt (Beispiel für die 1. Subadresse):
CV50 Funktionstyp (1= Servo ohne Impusabschaltung, 2= Servo mit Impusabschaltung)
CV51 Endlage 'AUS' ( 0...180)
CV52 Endlage 'EIN' ( 0...180)
CV53 Drehgeschwindigkeit ( 0...255 )

CV54 Funktionstyp 2. Adresse
.. usw ...


viele Grüße
Franz-Peter
Ein 'elektromechanisches' Stellwerk
Der (ehemalige) 'Eisberg'


 
MicroBahner
Metropolitan (MET)
Beiträge: 2.833
Registriert am: 28.11.2012
Ort: Mittelfranken
Gleise Tillig Elite
Steuerung Eigenbau
Stromart Analog


RE: Arduino MobaTools: V2.3.1 released

#92 von Mape71 ( gelöscht ) , 19.02.2016 12:48

...OK, Perfekt, ich freue mich schon auf das Ausprobieren[emoji3]

Viele Grüße

Marko


Mape71

RE: Arduino MobaTools: V2.3.1 released

#93 von digi_thomas2003 , 19.02.2016 13:23

Hallo Franz-Peter,

danke für Deine Weiterentwicklung des Zubehör-Decoders!

Beim #define DB_PRINT ist meiner Meinung nach noch ein kleiner Bug drin (über dem ich schonmal gestolpert bin): Es fehlen die geschweiften Klammern, ich habe sie nachfolgend mal ergänzt:

1
2
3
4
5
 
// für debugging
#ifdef DEBUG
#define DB_PRINT( ... ) { sprintf( dbgbuf,"Dbg: " __VA_ARGS__ ) ; Serial.println( dbgbuf ) ;}
byte debug;
char dbgbuf[80];
 



Ich habe am Wochenende ein TrainController-Seminar, ich hoffe, dass ich dann nächste Woche zum Testen komme.

Herzliche Grüße
Thomas


Thomas
------------------
Anlage H0: U-Form, im kreativen Bau
Fahren: Tams MC
Schalten: IB
Melden: HSI 88
Steuern: TrainController 9.0 Gold
Denken: Brain 4.1


 
digi_thomas2003
InterRegioExpress (IRE)
Beiträge: 305
Registriert am: 03.05.2005
Gleise sind vorhanden
Spurweite H0
Steuerung TrainController
Stromart AC, Digital


RE: Arduino MobaTools: V2.3.1 released

#94 von UweS , 19.02.2016 13:28

Hallo Franz-Peter,

super das Du Dich wieder meldest, hatte schon gedacht die Luft ist raus aus dem Projekt.

Zitat
sondern auch einen 'Stummi-Decoder' .


Das ist auch eine gute Idee.

Zitat
Vielleicht besteht ja auch nicht so das Interesse am x-ten Decoder, und das hier ist für die Tonne - dann lassen wir's eben , macht auch nix .


Ja natürlich besteht Interesse, zumindest von meiner Seite. Auf keinen Fall für die Tonne.
Das Problem, dass sich doch relativ wenige melden, liegt wohl eher am Umsetzten der Ideen.
Aber je einfacher das wird, könnte ich mir vorstellen, dass sich dann mehr Interessenten melden.

Eine Platine für dieses Projekt wäre sinnvoll.

Ein extra Thread ist sinnvoll und vielleicht Deinen Beitrag mit dem Schaltplan als Start.

Ich werde auch gern mit testen, geht erst ab nächste Woche am WE hat unser Verein Ausstellung.


Uwe

Lenz Digital seit 1993, seit 2020 Roco z21 und steuern mit der Z21 App, Traincontroller Gold, Mikromodellbau, Car Motion


 
UweS
InterRegioExpress (IRE)
Beiträge: 340
Registriert am: 02.02.2012
Spurweite H0, 1
Stromart Digital


RE: Arduino MobaTools: V2.3.1 released

#95 von MicroBahner , 19.02.2016 14:05

Hallo Thomas,
danke für den Hinweis. Stimmt, das hatten wir schonmal. Kommt davon wenn man einfach aus den alten Sketches wieder kopiert ops: . Das tückische an den fehlenden Klammern ist ja das es nicht generell, sondern nur unter bestimmten Randbedingungen zum Problem wird - und dann sucht man wieder....
Ich werde das gleich auch in meinem Orignal ausbessern.

Hallo Uwe,

Zitat von UweS
Aber je einfacher das wird, könnte ich mir vorstellen, dass sich dann mehr Interessenten melden.

Schaun mer mal . Die 'üblichen Verdächtigen' sind ja schon wieder beieinander .
Ziel ist es diesmal auf jeden Fall einen Decoder zu erstellen, der nicht (nur) Basis für eigene Weiterentwicklungen ist, sondern der 'as is' ohne Softwareänderungen einsetzbar ist.
Wenn ich einen neuen Thread aufmache, ist es wahrscheinlich sinnvoll, den unter 'digital' zu erstellen :


viele Grüße
Franz-Peter
Ein 'elektromechanisches' Stellwerk
Der (ehemalige) 'Eisberg'


 
MicroBahner
Metropolitan (MET)
Beiträge: 2.833
Registriert am: 28.11.2012
Ort: Mittelfranken
Gleise Tillig Elite
Steuerung Eigenbau
Stromart Analog


RE: Arduino MobaTools: V2.3.1 released

#96 von Bodo , 19.02.2016 14:10

Hallo Franz-Peter,

Interesse ist auf jeden Fall weiter vorhanden ! ... Leider reicht die Zeit mal wieder nicht für alles. Für mich persönlich ist halt die CV-Programmierung eher unwichtig. Nachdem ich das mit dem Zubehördekoder ungefähr verstanden habe, wird der nächste Schritt sein, das Prinzip beim Funktionsdekoder zu verstehen (also den DCC-Teil). Ich habe nämlich festgestellt, dass man von Hand 8 Funktionen oder mehr eventuell viel leichter/sinnvoller mit einer Lokadresse schalten kann, als dafür jeweils eine Weichenadresse zu nehmen. Im Idealfall stelle ich mir das so vor, dass z.B. F1 die Hausbeleuchtung an Schieberegister A, F2 die Leuchtreklame an Schieberegister B, F3 das Garagentor (Servo) usw. schaltet - dann hätte ein größeres Gebäude eine Lokadresse statt mehrerer Weichenadressen. Eine gute Vorlage für den Funktionsdekoder gibt´s ja hier schon.

Bei der Universal-Platine wird sich das Problem stellen, dass da entweder zu viel drauf muss und sie damit recht teuer wird, oder aber doch wieder Einschränkungen hingenommen werden müssen. Während meine Platine ja nur das DCC-Signal empfängt und daher fest programmierte Werte (Adresse, Endlagen, usw.) voraussetzt, hatte Thomas hatte ja schon mal eine Platine (viewtopic.php?f=21&t=131043) vorgestellt, die beide Optokoppler (also auch für CV-Programmierung) enthält und zum Testen der CV-programmierbaren Dekoder ideal wäre ... vielleicht könnte er die ja auch als Platine/Bausatz im Rahmen einer Sammelbestellung anbieten ? (Frag´ ich jetzt hier einfach mal öffentlich ...)
Nach meinem bisherigen Verständnis müsste es sogar möglich sein, dann mit Thomas´ Platine und einem Universal-Sockel den Nano einzurichten und ihn dann auf meine kleine Platine "umzutopfen" ?
Und im Verlauf der weiteren Entwicklung zeichnet sich dann vielleicht noch besser ab, was auf einem Universal-Dekoder tatsächlich neben Sockel, Spannungsversorgung und Optokopplern benötigt wird ...

Viele Grüße, Bodo


Die Freiheit des Menschen liegt nicht darin, dass er tun kann, was er will, sondern dass er nicht tun muss, was er nicht will. (Jean-Jacques Rousseau)

Meine Anlage - Meine Dauerbaustelle
Platinen für Modellbahn- und Arduino-Anwendungen


 
Bodo
InterCityExpress (ICE)
Beiträge: 2.471
Registriert am: 28.04.2005
Homepage: Link
Gleise C-Gleis, Lenz 0
Spurweite H0, 0
Steuerung MS2 & CS2
Stromart Digital


RE: Arduino MobaTools: V2.3.1 released

#97 von digi_thomas2003 , 19.02.2016 16:28

Hallo Bodo, Franz-Peter und alle anderen Arduino-DCC-Interessierten,

Zitat von Bodo
...
Bei der Universal-Platine wird sich das Problem stellen, dass da entweder zu viel drauf muss und sie damit recht teuer wird, oder aber doch wieder Einschränkungen hingenommen werden müssen. Während meine Platine ja nur das DCC-Signal empfängt und daher fest programmierte Werte (Adresse, Endlagen, usw.) voraussetzt, hatte Thomas hatte ja schon mal eine Platine (viewtopic.php?f=21&t=131043) vorgestellt, die beide Optokoppler (also auch für CV-Programmierung) enthält und zum Testen der CV-programmierbaren Dekoder ideal wäre ... vielleicht könnte er die ja auch als Platine/Bausatz im Rahmen einer Sammelbestellung anbieten ? (Frag´ ich jetzt hier einfach mal öffentlich ...)
...


Das lässt sich durchaus organisieren. Ich habe meine erste Auflage bei einem chinesischen Dienstleister erstellen lassen, das Problem war dabei nur die lange Versanddauer aus China. Die Qualität ist in meinen Augen einwandfrei.
Der Auftrag für eine weitere Auflage ist rasch erteilt, nur eben der Versand erfordert Geduld...

Zitat von Bodo
...
Nach meinem bisherigen Verständnis müsste es sogar möglich sein, dann mit Thomas´ Platine und einem Universal-Sockel den Nano einzurichten und ihn dann auf meine kleine Platine "umzutopfen" ?
...


Ich hatte auch schon mal angefangen, so eine "Universal-Platine" zu entwickeln, einen ersten Entwurf für einen Schaltplan habe ich, aber mit dem Platinenlayout muß ich mich erst noch befassen.

Zitat von Bodo
...
Und im Verlauf der weiteren Entwicklung zeichnet sich dann vielleicht noch besser ab, was auf einem Universal-Dekoder tatsächlich neben Sockel, Spannungsversorgung und Optokopplern benötigt wird ...
...


Stimmt, wer weiß, auf was für geniale Ideen wir hier im Verlauf noch so alles kommen!

Freundliche Grüße
Thomas


Thomas
------------------
Anlage H0: U-Form, im kreativen Bau
Fahren: Tams MC
Schalten: IB
Melden: HSI 88
Steuern: TrainController 9.0 Gold
Denken: Brain 4.1


 
digi_thomas2003
InterRegioExpress (IRE)
Beiträge: 305
Registriert am: 03.05.2005
Gleise sind vorhanden
Spurweite H0
Steuerung TrainController
Stromart AC, Digital


RE: Arduino MobaTools: V2.3.1 released

#98 von MicroBahner , 20.02.2016 14:31

Hallo Bodo, Hallo Thomas,

Zitat von Bodo
Ich habe nämlich festgestellt, dass man von Hand 8 Funktionen oder mehr eventuell viel leichter/sinnvoller mit einer Lokadresse schalten kann, als dafür jeweils eine Weichenadresse zu nehmen.

Ja, es ist sicher richtig, dass für manche Aufgaben ein Multifunktionsdecoder einfacher zu handhaben ist, als ein Weichendecoder. Die oben eingestellte Software des Decoders trennt eigentlich schon recht gut zwischen dem DCC-Teil (Erkennen des gemeldeten Status) und dem Verarbeitungsteil, bei dem dann entschieden wird, wie die Ausgänge anzusteuern sind. Da werde ich bei der Weiterentwicklung drauf achten, dass das so bleibt. Dann kann man einfach durch Austauschen der DCC Empfangsfunktion ( hier das 'notifyDccAccState') und ein paar kleinen weiteren Änderungen bei der DCC-Initiierung aus dem Zubehördecoder einen Multifunktionsdecoder machen (idealerweise bei unveränderter HW...).

Zitat von Bodo
Bei der Universal-Platine wird sich das Problem stellen, dass da entweder zu viel drauf muss und sie damit recht teuer wird, oder aber doch wieder Einschränkungen hingenommen werden müssen.

Da ist sicher was dran. Eine Lösung könnte sein, dass in zusammensteckbare Module aufzuteilen. Du und Thomas, ihr habt da ja schon gute Vorarbeit geleistet.

Zitat von Bodo
Und im Verlauf der weiteren Entwicklung zeichnet sich dann vielleicht noch besser ab, was auf einem Universal-Dekoder tatsächlich neben Sockel, Spannungsversorgung und Optokopplern benötigt wird ...

So sehe ich das auch

Zitat von digi_thomas2003
Ich hatte auch schon mal angefangen, so eine "Universal-Platine" zu entwickeln, einen ersten Entwurf für einen Schaltplan habe ich, aber mit dem Platinenlayout muß ich mich erst noch befassen.

Das ist doch schonmal ein guter Ausgangspunkt

Zitat von digi_thomas2003
Stimmt, wer weiß, auf was für geniale Ideen wir hier im Verlauf noch so alles kommen!

Da bin ich ja mal gespannt, wo der 'Stummi-Decoder' hindriftet...


viele Grüße
Franz-Peter
Ein 'elektromechanisches' Stellwerk
Der (ehemalige) 'Eisberg'


 
MicroBahner
Metropolitan (MET)
Beiträge: 2.833
Registriert am: 28.11.2012
Ort: Mittelfranken
Gleise Tillig Elite
Steuerung Eigenbau
Stromart Analog


RE: Arduino MobaTools: V2.3.1 released

#99 von Mape71 ( gelöscht ) , 26.02.2016 23:16

Hallo zusammen,

auf meinem Weg des Basteln habe ich mich erst einmal auf eine Servo- und Arduinohalterung für mein 2-flügeliges Signal gestürzt. Nach dem die nun fertig ist habe ich begonnen mich mit dem Arduino zu beschäftigen. Bezüglich des Schaltplans ist dabei eine Frage aufgekommen, die hier sicher beantwortet werden kann.
Ich werde den Decoder ausschließlich im POM-Modus programmieren. D.h. ich baue an PIN2 des Arduino einen Schalter und den beschriebenen 100Ohm Widerstand und verbinde dies mit Pin4. Auf die LED würde ich aus Platzgründen gerne verzichten, ebenso auf den zweiten Optokoppler (CNY17) und dessen Beschaltung.
Gehe ich recht in der Annahme, dass ich dann bei geschlossenem Prog-Schalter im POM-Modus die CVs programmieren kann?

Vielen Dank vorab für eine kurze Rückmeldung

Grüße

Marko

PS: Hier schon einmal ein paar Bilder von besagtem Servohalter, die auch erklären, warum ich auf die benannten Bauteile verzichten möchte. Es ist halt einfach wenig Platz und ich würde gerne die schon auf dem Servohalter montierte Platine für Wandlung des DCC-Signals, auf die dann der Arduino einfach aufgesteckt wird, verwenden - und dort passt leider schon der Schalter nicht mehr vernünftig drauf, was sich aber improvisieren lässt. Nur für den zweiten Optokoppler und die Dioden reicht es nicht mehr.








Mape71

RE: Arduino MobaTools: V2.3.1 released

#100 von digi_thomas2003 , 27.02.2016 11:12

Hallo Marko,

Zitat von Mape71
...
Ich werde den Decoder ausschließlich im POM-Modus programmieren. D.h. ich baue an PIN2 des Arduino einen Schalter und den beschriebenen 100Ohm Widerstand und verbinde dies mit Pin4. Auf die LED würde ich aus Platzgründen gerne verzichten, ebenso auf den zweiten Optokoppler (CNY17) und dessen Beschaltung.
Gehe ich recht in der Annahme, dass ich dann bei geschlossenem Prog-Schalter im POM-Modus die CVs programmieren kann?
...



zuvor noch eine Rückfrage: Auf welchen Schaltplan beziehst Du Dich mit Deinen Angaben Pin2 über Schalter und Widerstand mit Pin 4 verbinden?

Grundsätzlich gilt bei DCC:
PoM (=Programming on the Main, also auf dem Hauptgleis, nicht auf einem separatem Programmiergleis) ist seitens der Spec so ausgelegt, dass der Decoder bei dieser Art der Programmierung keine Bestätigung an die Zentrale (= ACK, Acknowledge) zurückschickt. Daher kann - wenn auf die Programmierung auf dem Programmiergleis verzichtet werden kann/soll/muß - der zweite Optokoppler entfallen.
Und ob Du zum Einleiten des Programmiervorganges auf dem Hauptgleis (PoM) zuvor einen Schalter/Taster betätigen musst, ist eigentlich "nur" eine Frage der Software auf dem Decoder. Seitens der DCC-Spec ist das nicht erforderlich, die Decoder-SW muss vielmehr die DCC-Befehle der Zentrale richtig "verstehen" und umsetzen - und das ist wie gesagt eine Sache der Decoder-Software.

Die von Franz-Peter und mir verwendete NMRA-DCC-Lib für den Arduino bietet die entsprechenden Funktionen, auch die DCC-Befehle für die Programmierung auszuwerten und entsprechend darauf zu reagieren.

Ich hoffe, das hilft Dir fürs erste schon mal weiter?
Bitte auch weiterhin von Deinen Ergebnissen berichten!

Herzliche Grüße
Thomas


Thomas
------------------
Anlage H0: U-Form, im kreativen Bau
Fahren: Tams MC
Schalten: IB
Melden: HSI 88
Steuern: TrainController 9.0 Gold
Denken: Brain 4.1


 
digi_thomas2003
InterRegioExpress (IRE)
Beiträge: 305
Registriert am: 03.05.2005
Gleise sind vorhanden
Spurweite H0
Steuerung TrainController
Stromart AC, Digital


   

Innenbeleuchtung für Fleischmann 742080 BR 642
Alte Märklin Transformator ersetzen

  • Ähnliche Themen
    Antworten
    Zugriffe
    Letzter Beitrag
Xobor Einfach ein eigenes Forum erstellen
Datenschutz