"Echter" Digitalservo

[oberallgeier]

.. Wieweit sich dagegen die servointerne Regelungstechnik aufregt will ich jetzt lieber nicht ventilieren ..

.. Deshalb landet die ja auch im Müll ..

Dir ist aber schon klar, dass ich hier Dein Servo-Synchronisierkonzept meine? Das willst Du doch NICHT für den Müll entwickeln, sorry dass ich das so schreibe. Hintergrund meiner Anmerkung war, dass ich meine Zweifel daran habe, dass Du (dass man) die servointerne Regelung mit der von Dir geplanten Synchronisation so verknüpfen kannst (kann), dass keine Störungen entstehen. Insbesondere bei mehr als zwei Servos vermute ich da schon Probleme. Klar, meine Kenntnisse auf dem Gebiet sind gering, aber ich hatte bei meinem MiniD0 versucht die beiden Regelkreise von zwei baugleichen Motoren durch VERKNÜPFEN der Laufdifferenz mit der/den REgelung(en) so aufeinander abzustimmen , dass bei Geradlauf ein absoluter Gleichlauf, Synchronizität, beider Räder erzielt wird. Trotz nicht ganz amateurhaften Kenntnissen zur numerischen Mathematik und zu digitaler Regelungstechnik hab ich das nicht geschafft.

.. nicht auf die Femtosekunde genau machbar .. aber im bereich von 200nS bei 25Mhz ..

Hmmm - interessant: fünf Arbeitszyklen für eine Anpassung - das wäre interessant zu lesen, was das genau für ein Codestück ist.

[OT]

.. Ich arbeite mit diesem Prinzip schon Jahre für Chemiewerke um so Schlauchpumpen per I²C Bus zu Kontrollieren ..

Sind das zertifizierte Anlagen (FDA oder ähnlich) oder von sonstigen Validierungsfirmen abgesegnete Anlagenteile?[/OT]

[Pali64]

Hallo oberallgeier,

Zur Frage Zertifikat:
Ja die sind Zertifiziert, da sie auch in der Lebensmittelindustrie (Wasserqualitätskontrolle) und im Sektor "Live Health" eingesetzt werden.

Zum andern, nein ich dachte du meinst die Standard Servoelektronik
Zur synchonisation:
Da die Servo nicht nach "Potiwerte" sondern nach Absolut/Relativ Positionen mittels Pulscoder Fahren, fahren sie immer exakt Timing und Wegbasierend gleich.
Sie arbeiten so wie die Großen Industrievorbilder Servo bei bsw. CNC Fräsen. (Große wie Fanuc, Brother oder wie sie alle heißen, fahren nicht mit Steppermotoren sondern Drehstrom Servomotoren)

So kann ich dein bedenken nicht teilen.
Stell dir vor, eine CNC muss ein Kreis aus fräsen, und die "X" und "Y" Achse würde nicht absolut Synchron fahren? das gäbe ja eine "Zwetschgoloide"oder sonnst was, aber sicher kein Kreis.

Ein Standard Fliegerservo fährt nie 100% Zeitgleich, das ist Last, Spannung, Strom und Temperaturabhängig. also extrem schwierig zu händeln. Aber Pulscoderservo fahren exact wie Steppermotoren.
Der Unterschied ist das Steppermotoren meist keine Überwachung (sprich Puls- oder Winkelcoder) haben. Das kann in extrem-fällen zu Steppverlusten führen, was User von so Boilligoberfräsen schon oft schmerzlich erleben mussten. Ein Industrieservo arbeitet immer mit Puls- oder Winkelcoder, in seltenen Fällen sogar mit EBEDIC Absolutcoder. das heißt, immer exakt gleicher Weg und Geschwindigkeit.

So musst du dir nun vorstellen das du den Servos die ich baue nicht einfach mit einer Spannung oder Pulsweite vorgibst, was sie Fahren sollen, sondern du sendest absolut befehle wie "Fahre 5,023° mit der Geschwindigkeit 0.02° pro 100" Sekunde. und der Servo macht dies unabhängig von der Temperatur und anderen Parameter, immer exact. Sollte er dies nicht können weil es Klemmt oder Last zu groß oder andere Fehler, meldet der Servo dies sofort mit einer Fehlermeldung an die Steuerung zurück.

Soviel zur Praxis und Theorie.

Gruß Pali64

[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