"Echter" Digitalservo

[oberallgeier]

Hallo Pali64,
danke für Deine ausführliche Antwort. JETZT verstehe ich erst Deine Synchronisierung. Ich war immer auf dem Dampfer "Regelung" und Du machst es eben über eine Steuerung. Ja, so wird ein Schuh draus. Interessant für mich, wirklich, weil ich ja etliche Servos "an der Leine" habe.

Im Prinzip läuft meine Kommandoleine ähnlich. Die Servos bekommen bei mir - so synchron wie mit 20 Mhz möglich - Fahrbefehle mit Ziel und Geschwindigkeit

//  Fahre Arm in Stellung "Mitbürger"  =  Ober- und Unterarm nach oben
  LN2 ("  Mitbuerger - - ");    //
  uputs0  ("\r\tMitbürger");    // <<<<<<<<<<<<<<<

  SrvZa0[ 1]    =  S1gvor;      // Schulterschwenk "gerade"
  SrvIc0[ 1]    =      50;      // Fortschritts-Increment !0
  SrvZa0[ 2]    =   S2min;      // Schulter-aufab maximal hoch          l
  SrvIc0[ 2]    =     120;      // Fortschritts-Increment !0
  SrvZa0[ 3]    =   S3gst;      // Unterarm gerade ziemlich gestreckt   -.-
  SrvIc0[ 3]    =      50;      // Fortschritts-Increment !0
                                
  tmrAN01       =      20;      // 0,1sec-Timer setzen
  tANnk         = Izeit_1;      // Nachkommaanteil in 50µs
  SrvFg0[1] = SrvFg0[2] = SrvFg0[3]  =  1;      // Befehlsflag: Nur EINE Fahrt
  SrvFu0[1] = SrvFu0[2] = SrvFu0[3]  =  6;      // case: Direktfahrt SloMo starten

fahren aber eben mit der modellbauüblichen Servotechnologie: Winkel über Poti messen, Regeln mit teils nicht sehr optimalen Regelungen. Die unterschiedlichen Fortschrittsincremente bekommt bei mir jeder Servo bei jedem neuen Servopuls aufgedrückt - leider ebenso üblich ohne Rückmeldung.

Auf die Schnelle wäre Deine Technik keine Lösung für mich. Ich muss mich beim I²C ziemlich kurz fassen, um nicht zu viel CPU-Zeit zu verbrauchen, damit die andern Interrupts nicht so aus dem Tritt kommen; soweit meine Messungen und Rechnungen reichen und die Realität zeigt, gehts völlig konfliktlos. Da ich mich auf die 8Bitter von Atmel versteift habe, bin ich zeitlich aber etwas gekniffen. An den Umstieg auf einen ARM (STM32F4) bin ich noch immer nicht rangegangen. Meine Synchronisierung mit den üblichen Servos wird dann einfach gelöst, indem auch längere Sequenzen (z.B. die Deklamation der Antoniusrede) auf kleinere Abschnitte aufgeteilt werden die mit hoher Genaugikeit synchron gestartet und mit einem Timer auf Tempo kontrolliert werden.

Danke auch für die Aufklärung zur Zertifizierung. Ich bin beruflich viel mit validierten Anlagen beschäftigt gewesen, FDA-zertifiziert etc, in Pharma, Grob- und Feinchemie und dort bis in die Hochsicherheitstrakte *gg*.

[Pali64]

Hallo oberallgeier,

Ja und ich versteh wie du das Löst ......
Aber du kontrollierst nicht die Stromaufnahme der Servos?, und hast somit auch keine Rückmeldung was der Servo gerade macht?. sondern du schickst einfach Timergenau neue PWM Längen und gibst damit auch die Fahrgeschwindigkeit vor hmmmm.... Ja das geht sicher aber was passiert wenn ein servo plötzlich "Hängt"? dan hast du keine Rückmeldung, oder prüfst du das woanders im Programm?

Na ja auch egal es funst ja bei dir

I²C vs I2C: Hmm ah ja dann verstehe ich natürlich dein Timingproblem, da kommt dein Prozi ja ganz schön ins Schwitzen
Ich arbeite eben mit dem MSP430 von TI und bin in der Beziehung Steuerung-seitig, klar im Vorteil.

Der hat interne DMA Logic,

Womit ich grad für das Fahren über den I²C Bus klar im Vorteil bin. Ich lege eine Tabelle mit den Koordinaten und Fahrgeschwindigkeiten an, setze den DMA Tackt für das I²C-UART die Start und Endadresse der Tabelle im DMA des MSP430.... und schick theoretisch die eigentliche CPU Schlafen (oder lass sie was anderes machen) bis die Servos ihre Arbeiten erledigt haben.
Ich habe so natürlich den Vorteil durch die Bidirektionale Kommunikation, zwischen der I²C-UART und den I²C-Device das dies völlig selbstständig abläuft (na ja zumindest fast) und die CPU immer erst wenn Alle ihre Fahrt abgeschlossen haben von der DMA wieder geweckt wird.

Gruß Pali64