Archiv verlassen und diese Seite im Standarddesign anzeigen : "Echter" Digitalservo
Durch unzählige "Niederschläge" mit käuflichen Servo's, die einfach nie 100% die gleiche Position erreichen, aber auch angelehnt an meine Tätigkeit in der Industrie,
habe ich nun ein Projekt angefangen mit Servo's, die 100% Digital sind.
Ich habe zu diesem Zweck ein kleiner Servo Zerlegt, und den Gleichstrommotor gegen einen Mehrphasen Drehstrom-minimotor ersetzt.
Die Analog-servosteuerung entfernt und komplett ersetzt.
Ein großer Vorteil ist natürlich nur noch 1 4-Poliges Kabel, das alle Servos (1~F pro Leitung) also jeweils 15 Stück anzusprechen.
Das Poti habe ich im Servo belassen um eine Ungefähre Position des Servos beim einschalten Festzustellen.
Wen man nun die "0" Punkte erst Abfährt "So wie bei den Großen Industrievorbilder" kann nun ein absolut exaktes und wiederholbares Anfahren jedes Punktes realisiert werden.
Ich verwende hiezu hoch Präzise Pulscoder die sich auf den Mikrodrehstrom Motoren befinden.
Im weiteren regle ich die Kommunikation nicht mehr über PWM wie bis an-hin, sondern habe ein Bidirektionales I²C Protokoll welches die Möglichkeit gibt, die Position so wie die gesetzten Parameter im Servo abzufragen. Dazu gehören Parameter die sich Setzen und lesen lassen wie:
1.) Momentane Stromaufnahme.
2.) Position.
3.) Anfahrrampe Parameter.
4.) Bremsrampe Parameter.
5.) Fahrgeschwindigkeit.
6.) Fahrdistanz.
7.) Motortemperatur
8.) Seine derzeitige I²C Adresse (Ist per I²C Änderbar)
usw.
Dazu verwende ich im Servo neben Powerfet den MSP430 Mikrocontroller.
Er erschien mir ideal dazu, weil:
* Interne A/D und PWM so wie D/A Wandler.
* Interner Temperatursensor.
* Braucht kaum Strom.
* Internes I²C Fähiges UART.
und das Wichtigste Argument überhaupt:
Ich kenne diesen Prozessor seit es ihn gibt.
Habe alle Tools die ich brauche, und Jahrzehnte lange Erfahrung mit dem Umgang.
Warum Poste ich das Hier?
Es Interessiert mich ob ein Bedarf besteht, und ob Anregungen zum Projekt da sind,
denn wenn ja überlege ich mir diese eventuell in unserer Firma fertigen zu lassen, bzw als Produkt herzustellen.
Wenn Interesse Besteht werde ich das Protokoll hier mal Posten. damit ihr seht was zur zeit alles an Befehlen möglich ist.
Das hat den Vorteil wenn euch was fehlt oder als Überflüssig erscheint, kann ich dies noch vor dem Produktstart anpassen.
Gruss Pali64
ARetobor
21.02.2016, 15:08
Hallo Pali64,
interessanter Ansatz.
Bedarf gibt es dann, wenn es gegenüber anderen Lösungen Wertevorteile gibt, zB. - Preis -Gewicht - Haltbarkeit - Leisung ect.
Meine Frage ist, wie schnell soll der I2C Takt sein.
Gruß
Relbmessa
PS einen noch -leiser
Hallo ARetobor,
Der I²C Takt ist 400kHz.
Ich verwende das Protokoll schon seit Jahren für Sensoren und anderes. Es ist sehr Zuverlässig und ist auch durch seine kurzen Befehlen sehr schnell (in der Regel 2 ~ 6 Byte befehle mit Quittungsantwort)
Gruß Pali64
ARetobor
21.02.2016, 17:15
Hallo Pali64,
danke für die schnelle Antwort.
Ich kenne mich mit I2C nicht gut aus,heist dass, ca. 25µSekunden Reaktionszeit?
Ich habe gelesen, dass es auch noch schneller geht.
Kannst du schon etwas zu deinem Motor sagen?
ist es ein Brushless,oder ist es noch ein Enwicklungsgeheimnis?
Würde ich verstehen!
Hast du schon Vorstellungen über den zu erwartenen Endpreis?
Gruß
Relbmessa
oberallgeier
21.02.2016, 18:05
.. Der I²C Takt ist 400kHz .. ist sehr Zuverlässig und ist auch durch seine kurzen Befehlen sehr schnell ..Das klingt vielversprechend schnell? Nur mal so - wie lange sind Deine Leitungen zwischen Controller und Sensor - nur mal so ungefähr? Sind die 400 kHz gemessen, z.B. am Oszilloskop, oder sonstwie verifiziert oder ist das die Vorgabe im Quelltext ?
Hallo Relbmessa, Hallo oberallgeier,
Ich arbeite hier in der Industrie an Geräten, allerdings nicht mit 3.3V, oder 5V Pegeln,
sondern mit 12V Pegeln auf Leitungen mit bis zu 100M Länge ohne Probleme.
Eigentlich würde ich auch gerne die Servo's lieber mit 12V Betreiben,
aber denke da würde mancher MC Anwender nicht glücklich darüber sein.
Wäre allerdings sehr Vorteilhaft für den Kabeldurchmesser,
wenn da mal wirklich 15 Servo's daufhängen würden.....
So werde ich mich aber wahrscheinlich für 5V entscheiden,
es sei den es kämen andere Wünsche.
Im übrigen sind die 400kHz sogar mit speziellen Analyser geprüft worden,
(Industrie ISO Normen) sind da Vorschriften......
Also denke ich dass gerade Umgesetzte G0 0 (Homebefehl mit maximaler Geschwindigkeit) in sehr kurzer Zeit übertragen werden können.
Da es aber eventuell Anwendungen gibt in denen die 400kHz Problematisch für den Anwender
(Nicht alle MC's unterstützen 400kHz I²C) werde ich eventuell ein Umschalten auf 100kHz möglich machen.
Was aber nun als Wünsche und Anregungen kommt wird Bestimmen was der Servo kann und danach auch den Preis bestimmen.....
Gruß Pali64
Ich arbeite hier in der Industrie an Geräten, allerdings nicht mit 3.3V, oder 5V Pegeln,
sondern mit 12V Pegeln auf Leitungen mit bis zu 100M Länge ohne Probleme.
So beschreibt das auch NXP in seinen App. Notes. Aber auch in jedem HDMI-Kabel ist ein I2C Bus enthalten und funktioniert zuverlässig mit 5V bei 5m Kabellänge.
Eigentlich würde ich auch gerne die Servo's lieber mit 12V Betreiben,
aber denke da würde mancher MC Anwender nicht glücklich darüber sein.
Wäre allerdings sehr Vorteilhaft für den Kabeldurchmesser,
wenn da mal wirklich 15 Servo's daufhängen würden.....
So werde ich mich aber wahrscheinlich für 5V entscheiden,
es sei den es kämen andere Wünsche.
Die 12V wären auf jeden Fall besser. Es geht dabei nicht nur um den Kabeldurchmesser sondern um die ohmschen Verluste generell. Das Problem ist die Kompatibilität mit einem 30 Jahre alten Konzept. Da wurde die RC-Anlage mit 4 NiCad-Zellen betrieben. TTL ICs funktionierten damit gerade auch. Wenn man die oberen Toleranzen von ICs aus dem TTL Umfeld großzügig auslegt, kommt man zu den heute üblichen Spannungen. Da keine Servo-ICs mehr neu entwickelt werden, hat sich da nichts geändert, außer daß RC-Servos nicht mehr nur zum Bewegen von Steuerrudern sondern als vollwertige Servoantriebe eingesetzt werden. Ein weiteres Problem ist, daß zwei voll geladene LiPos mit ihrer Spannungslage dann doch die Maximalspannung der gängigen Servo-ICs übersteigen. Das führt dann zu aufwändigen, schweren und verlustbehafteten Spannungsreglern mit ihren eigenen (eigentlich vermeidbaren) Problemen.
Die Dynamixel Servos bzw. eigentlich Servoantriebe haben mit diesem Erbe gebrochen, sowohl was die zu geringe Versorgungsspannung als auch das uralte RC-Protokol, das sich an den damals gängigen Bandbreiten der RC-Funkanäle orientierte, betrift. Das einzige Problem der Dynamixel Servos ist vordergründig der Preis. Die Anwender rechnen sich aber gern ihr Projekt schön, obwohl sie nach einigen zusätzlichen Reglern und einigen abgebrannten Servos mit den teureren Dynamixels ähnlich preiswert gefahren wären, bei technisch wesentlich besseren Ergebnissen.
Da es aber eventuell Anwendungen gibt in denen die 400kHz Problematisch für den Anwender
(Nicht alle MC's unterstützen 400kHz I²C) werde ich eventuell ein Umschalten auf 100kHz möglich machen.
Solange das Servo der I2C-Slave ist, muß man da garnichts tun. Der I2C-Master gibt den Takt vor und kann so langsam arbeiten, wie er will. Selbst wenn alle Slaves 400k können, kann der Master mit 40k arbeiten.
MfG Klebwax
Hallo Klebwax,
Danke für dein Ausführlicher Post.
aber...
.....Solange das Servo der I2C-Slave ist, muß man da garnichts tun. Der I2C-Master gibt den Takt vor und kann so langsam arbeiten, wie er will. Selbst wenn alle Slaves 400k können, kann der Master mit 40k arbeiten.....
Ist nur richtig bei Asynchronem Betrieb.
Werden die Servos in Synchronbetrieb geschaltet, Verwenden sie den Stabilen I²C Clock (so ähnlich wie beim Pal-signal) als Synchronisation (Das heißt der I²C Clock muss während der Fahrt Aktiv bleiben, bis der Servo seine Endposition Quittiert) Dies ist bei Verwendung von Mehreren Servo's, grad in einem Roboterarm wichtig,
den nur so kann der Arm auch beim zeichnen z.B. eines Kreises, 100% immer exakt die gleiche "Fahrt" Garantieren (auch Ohne teurem und Platz fressendem Quarz im Servo)
Im Asynchronem Betrieb ist es dem Servo wirklich Egal wie der Clock daher kommt, Hauptsache das I²C Protokoll wird eingehalten (Vor allem in Bezug von Start und Stopbit)
Gruss Pali64
Ist nur richtig bei Asynchronem Betrieb.
Werden die Servos in Synchronbetrieb geschaltet, Verwenden sie den Stabilen I²C Clock...
Erst mal etwas zu den Begriffen, in der Datenkommunikation wird eine Übertragung als synchron bezeichnet, wenn sie sowohl Daten als auch Takt überträgt. Nach diese Kriterien ist ein UART asynchron, SPI und I2C sind synchron. Der Begriff "Asynchronem Betrieb" bei I2C ist verwirrend.
Bei einer synchronen Übertragung gibt es eigentlich keine wirkliche Übertragungsfrequenz, jedes Bit hat sein eigenes Timing. Das einzige, was man angeben kann, ist eine maximale Bitrate indem man die minimale Low-Zeit und die minimale High-Zeit der Spezifikation aufaddiert. Das Timing der Bits bei I2C funktioniert so: Der Master setzt SCL auf Low und wartet die minimale Low-Zeit ab. Dann läßt er das Signal los (open Collector) und wartet, das das Signal High wird. Wie lange es dauert, bis das Signal High wird, hängt zum Mindesten mal davon ab, wie groß die Lastkapazität des Busses im Verhältnis zu den Pullups ist. Ab dann wartet er auf jeden Fall die minimale High-Zeit ab, bevor er wieder ein Low ausgibt. Aus dieser Beschreibung ist ersichtlich, daß es eigentlich keine feste Frequenz bei I2C gibt. Das kann man auch leicht nachvollziehen: man betreibt I2C mal mit einem kurzen Kabel und mal mit einem längeren Kabel, und damit einer größeren Kapazität. Die Frequenz, eigentlich die Datenrate, die man dabei messen kann, unterscheidet sich.
(Das heißt der I²C Clock muss während der Fahrt Aktiv bleiben, bis der Servo seine Endposition Quittiert) Dies ist bei Verwendung von Mehreren Servo's, grad in einem Roboterarm wichtig, den nur so kann der Arm auch beim zeichnen z.B. eines Kreises, 100% immer exakt die gleiche "Fahrt" Garantieren (auch Ohne teurem und Platz fressendem Quarz im Servo)
Du willst also aus dem I2C Takt eine Königswelle machen. Nun sieht aber die I2C Spec nicht vor, daß der Takt anliegt, wenn keine Daten übertragen werden. Und selbst wenn man mehrere Frames hintereinander startet, garantiert niemand, daß das Timing von Start und Stop Conditions sich nahtlos in das Timing der anderen Bits einfügt. Die I2C Hardware in den Prozessoren, die ich so kenne, bieten da keine Unterstützung.
Den I2C Takt als Königswelle zu nutzen, halte ich für entweder nicht machbar oder es kommt etwas heraus, das man nicht I2C nennen sollte. Mindestens um die Anwender, die I2C kennen und die Spec gelesen haben, nicht zu verwirren.
Im Asynchronem Betrieb ..
Nochmal: aus Sicht der Datenübertragung ist I2C ein synchroner Bus.
MfG Klebwax
Hallo Klebwax,
Das Synchron bzw Asynchron, beziht sich auch nicht auf den Bus selbst, sondern auf das die Servo Synchron oder Asynchron zu einander verhalten.
Das I²C Bussprotokol ist so vom Hersteller (Vormals Phillips nacher NXP) spezifisziert, das wenn KEIN Startbit erkannt wurde das Klocksignal machen darf was es will das heist es wird von den I²C standarddevices Ignoriert. Nun habe ich mir dies zu Nutze gemacht, (Wird übrigens vom MSP430 I²C UART Unterstützt) das der Clock so lange stabile pulse ausgibt, bis das Stopbit erkannt wird.
So fährt der Servo Los und Synchronisiert seine Fahrt mit dem SCL bis er seine Endposition erreicht hat. Hat er sie erreich senddet er ein Bitmuster das seine Adresse als Bit wiederspiegelt
Als Beispiel:
[Start Bit][Adress][Command][SCL]----------[SCL][Bitmuster auf SDA 10111111 11111111] für servo No 1
So quitiert der Servo 1 dass er sein "Ziel" erreicht hat
{wie oben}----[SCL][Bitmuster auf SDA 11011111 11111111] für servo No 2
{wie oben}----[SCL][Bitmuster auf SDA 11100111 11111111] für servo No 3 und 4 Zeitgleich angekommen
Das heißt der Controller liest so lange "FF" vom I2C Bus bis alle Servos sich gemeldet haben und ihre Fahrt Quitiert haben
Es gibt auch die Möglichkeit dass sich die Servos Sequenziell mit Ihrem Stromverbrauch melden bis die Fahrt beendet ist, dies ist aber der Geschwindigkeit wegen nur im 400kHz Modus möglich.
Auf diese weise fahren die Servos, absolut Synchron und der MC ist permanent auf dem Stand des Stromverbrauchs und über die Situation der Servos.
Dies verhindert auch das ev. bereits ein Neuer Fahrbefehl gesendet werden kann bevor alle Servo ihr Ziel erreicht haben.
Dadurch lassen sich aufwendige Fahrkontrollen mit Zusatzkabel o.ä. aufwand vermeiden.
Ich arbeite mit diesem Prinzip schon Jahre für Chemiewerke um so Schlauchpumpen per I²C Bus zu Kontrollieren und exakt Chemie zu mischen.
Es hat sich bewährt und ist auch keineswegs Fehleranfällig. Aber ein Problem mit verklemmten Servos(Hier halt Pumpen) wird vom System sofort erkannt.
Hoffe die Erklärung wird Verstanden und sonnst fragt halt wieder, für das habe ich ja diesen Thread eröffnet.......
Gruß Pali64
oberallgeier
23.02.2016, 08:37
.. Den I2C Takt als Königswelle zu nutzen, halte ich für entweder nicht machbar oder es kommt etwas heraus, das man .. I2C nennen sollte ..In meinem Archie geht ne ganze Menge über I²C - aktuell elf (11) Controllerplatinen, d.h. zehn Satelliten und ein Zentralrechner. Da war ich längere Zeit perplex über die hohe Datenrate (400 kHz, auch 800kHz - als Vorgaben von mir :-/ ) und wiederholte Störungen, bis ich mir die Signalflanken angesehen hatte. Die entsprachen dann meinen Vorstellungen/Befürchtungen; immerhin ist das Kabel knapp zwei Meter lang. Seit ich mit 74 k am Master fahre, gibts keine Störungen.
Im Kopfkontroller von Archie laufen zehn Servos - die sollen auch synchron laufen (https://www.youtube.com/watch?v=Kt4UiEaTicc). Das funktioniert bei mir durch entsprechend abgestimmte Startzeiten und zeitliche Kontrolle der Ansteuerung der einzelnen Servos; billige, analoge Dinger.
Die Synchronisation "über alle Controller" erfolgt im Prinzip über I²C - durch präzise getimte Befehle - aber eben nacheinander an die einzelnen Satelliten - und in besonderen Fällen durch Rücklesen der aktuellen Stände - bei dieser (https://www.youtube.com/watch?v=zaw8vZNWs6M)komplexen Bewegung (leider ein schrecklich schlechtes Video (https://www.youtube.com/watch?v=zaw8vZNWs6M)) klappt das dann ganz gut.
Eine Synchronisation über eine digitale Königswelle (Klebwax: ein klasse Ausdruck!!, Kompliment!) wollte ich auch machen. Auf fast allen meinen Platinen (Ausnahme 2 Sonderfälle für andere Lösungen) habe ich einen Heartbeat von 50 µs, der nach 1 sek eine LED toggelt. Ursprünglich sollte der Master auf diesem Weg die Satelliten synchronisieren; es ist ja nix einfacher als das LED-Signal über das ganze System zu schicken. Diese Absicht hatte ich fallen gelassen als ich sah, dass die "übliche" I²C-Kommuniktion zu so genauen Ergebnissen führt, dass für das menschliche Auge in der Feinmotorik so gut wie keine Störungen zu erkennen sind.
Hut ab oberallgeier,
Eine reife Leistung dein Archie 8).....
Da wären natürlich solche Synchron über I²C programmierbare Servos ein Segen ;)
PS: Da wir fast zeitgleich gepostet haben hast du vielleicht mein Post mit der Synchronerklärung übersehen?
Fazit: .....ist ES GEHT! und ist eine Feine Sache.....
@Klebwax Finde ich eine Niedliche Bezeichnung (Königswelle) wenn ich darf nehme ich das gerne in die Beschreibung der Servos so auf :)
Gruß Pali64
oberallgeier
23.02.2016, 09:17
Danke für das Lob.
Dein Posting hatte ich bemerkt (wenn man Post 9 beantwortet und mit Hausnummer 11 "rauskommt" - das fällt auf).
.. Auf diese weise fahren die Servos, absolut Synchron und der MC ist permanent auf dem Stand des Stromverbrauchs und über die Situation der Servos ..Hier erlaube ich mir vorsichtigen Protest. JEDE Maschine, jedes Konglomerat von wenigen Tausend Molekülen hat Eigenheiten, selbst extrem genau geferteigte Quarze weichen voneinander ab. Und gerade Elektromotoren bzw. die von ihnen bewegten (Modellbau-)Servos werden nie absolsut synchron laufen - was wir alle leider immer wieder feststellen. Aber das ist marginal. Ich bin ja zufrieden, wenn meine Servos "sozusagen" synchron - mit wenigen Mikrosekunden Abstand - starten. Und meistens trägt meine quarzgenaue Taktung der SloMo-Servos zum synchronen Ablauf bei. Durch entsprechender Kürze der Abläufe kommt dann mein Lösungsweg zum Tragen.
Andererseits - wenn Du als Ziel hast, die Momentangeschwindigkeit mehrerer Servos im Bereich von Mikro-/Millisekunden bzw. Motorumdrehungen exakt gleich zu halten - dann wäre das für einzelne Aufgaben sicher von Mordsinteresse - und Klebwax´ Königswelle wäre Realität. Wieweit sich dagegen die servointerne Regelungstechnik aufregt will ich jetzt lieber nicht ventilieren.
Hallo oberallgeier
........ Wieweit sich dagegen die servointerne Regelungstechnik aufregt will ich jetzt lieber nicht ventilieren.
Deshalb landet die ja auch im Müll :)
Ne spass beiseite, Klar ist es nicht auf die Femtosekunde genau machbar....... aber im bereich von 200nS bei 25Mhz Systemtackt locker!
Wobei ich denke dass ich aus Stromspargründen die MSP's bei 8 oder 16 Mhz "zwitschern" lasse bei 100kHz I²C würden sogar 4Mhz reichen.
Die Ursprüngliche Servoelektronik muss ich eh in die Tonne hauen, da sie nicht für Syncromotoren geeignet ist. das Heist der MSP steuert über Powerfet die 3 Phasen des Motors direkt an.
Über den Magnetischen Pulscoder bekommt er dan die Informationsdaten über die Genaue Position.
Habe mir Magnetische Winkelcodierer IC angesehen (Bsw AMS AS5045-ASSU) aber das würde den Preisramen für kleine Servo sprengen, die dinger sind ja schweine teuer......
Deshalb verwende ich standard Hallsensoren die als Pulscoder fungieren und so, solange der Servo bestromt ist immer genau die Positionsinfo- ermöglichen.
Nachteilig ist halt das der Servo zuerst den "0" Punkt anfahren muss.
Ich meine sollte hier laut werden das ein Aufpreis von rund 20€ pro Servo belanglos ist werde ich natürlich die erwähnten Winkelcodierer einsetzen.
Das erspart dann das "0" Punkt anfahren.
Und weiter geht's mit Infosammeln...Gruß Pali64
Hoffe die Erklärung wird Verstanden und sonnst fragt halt wieder, für das habe ich ja diesen Thread eröffnet.......
Ich schon verstanden, was du machst. Nur sollte man Begriffe wie asynchron bei einem Bus der synchron ist vermeiden. Das führt zu Missverständnissen. Außerdem sollte man I2C vermeiden, wenn man nicht I2C macht. Die I2C Spec sieht einen durchlaufenden Takt nicht vor und, was dein Konzept kippt, erlaubt jedem Slave bei jedem Bit SCL auf low zu halten, solange es ihm beliebt (im Hs-Mode nur beim 9. Bit). Dein Bus arbeitet also nur mit deinem Master und deinen Slaves. Ein Master, der kein durchlaufendes SCL erzeugt, der eher I2C Frames als kurze Bursts erzeugt, kann deine Servos nicht betreiben. Ebenso bringt ein beliebiger I2C Slave, der z.B das ACK nach einem Readrequest solange stetched, bis er die die zu lesenden Werte bereitstellen kann (so haben sich die I2C Erfinder das mal gedacht und deswegen ist ja nicht nur SDA ein wired-or sondern auch SCL), deinen Bus komplett aus dem Tritt.
Im Prinzip hast du einen 1-Wire-Bus mit einer zusätzlichen Taktleitung. Man kann aber erkennen, wie flexible das Konzept eines wired-or Busses so ist.
MfG Klebwax
P.S. Die Bezeichnung Königswelle stammt nicht von mir. Ich kenne den Begriff aus dem Maschinenbau, und da es heutzutage meist keinen Zentralen Antrieb mehr gibt (z.B. mehrere Antriebe statt Zug und Leitspindel) ist mir die digitale Königswelle auch schon untergekommen.
- - - Aktualisiert - - -
Habe mir Magnetische Winkelcodierer IC angesehen (Bsw AMS AS5045-ASSU) aber das würde den Preisramen für kleine Servo sprengen, die dinger sind ja schweine teuer......
Ich meine schon Servos gesehen zu haben, die solche Bausteine oder auch einen Resolver einsetzen, hier mal ein Link (http://www.hobbyking.com/hobbyking/store/__22613__HobbyKing_8482_Mi_Digital_Brushless_Magne tic_Induction_HV_MG_Servo_10_8kg_0_10sec_56g.html)
MfG Klebwax
Hallo Klebwax,
Ja was den nu I²C oder nicht??? .... OK ......
bei den von uns Hergestellten Steuerungen, wird der Bus auch "RJC-I²C" genannt aber im Asynchronbetrieb (Nochmals nicht der Bus gemeint sondern die Device) ist der Bus bis auf die 12V Pegel (welcher ja zwar in den NXP Applikationen auch gezeigt wird) 100% I2C Protokoll konform (Wurde Norm-geprüft da es in der Industrie eingesetzt wird).
Ich weiß das es Devices gibt die den SCL Strecken bis sie Ihre Arbeit erledigt haben.... Wird von uns übrigens auch verwendet für gewisse Devices die so ihr Abwarten auf Ende, oder Bereitschaft mitteilen.
Trotzdem ist es ein I²C Protokoll (wäre ja rein theoretisch schon bei nicht TTL Pegel der Fall weil der klar im I2C Protokoll definiert ist).
Ich denke auch nicht das User den Servo I²C Bus rein schon wegen den 12V Pegeln nicht für Standard I2C Bus teile brauchen werden, obwohl wir für unsere RJC I²C Module auch applikationsbeispiele dem Kunden vorschlagen für bsw PCF 8574 parallel als Taster und Anzeigerückmelder im Bussystem zu verwenden......
Also langer Schreiber Kurzer Sinn, Es entspricht dem I²C außer das halt im Device-Synchronbetrieb permanent FF$ eingelesen werden muss bis die Device's (Hier halt Servo) ihre Arbeit erledigt haben.
Im Device-Asynchronbetrieb ist es 100% I2C Protokoll konform.
Gruß Pali64
Hallo Klebwax,
Ja was den nu I²C oder nicht??? .... OK ......
bei den von uns Hergestellten Steuerungen, wird der Bus auch "RJC-I²C"
Du kannst den Bus nennen wie du willst. Ich vergebe keine I2C Lizenzen mit der Erlaubniss, das Logo zu führen noch mache ich Konformitätstests.
Aber mein Rat wäre, nenn das anders. Wenn du ein Gerät in die freie Wildbahn entlässt, mußt du damit rechnen, daß die Anwender locker mit der Doku umgehen und insbesondere nur den Anfang lesen. Steht da I2C, würde ich mir vorstellen: ich nehm einen Raspi und steuere das mit dem Kernelmode I2C Treiber und einem Python Script. Wie ich auf die 12V komme, find ich schnell raus, ist ja allgemein bekannt. Und da ich schon mal einen getriebenen Bus habe, klemm ich noch nen SRF08, eine IMU oder sonstwas daran. Jetzt mußt du anfangen zu erklären, daß bestimmte Dinge so nicht funktionieren, daß der Raspi oder der Arduinio so ohne weiteres keine dauerhafte Clock erzeugt, daß mit den üblichen Treibern ein Warten auf 0xFF nicht möglich ist. Du wirst irgendwann die Lust daran verlieren. Ist aber nur ein Rat aus Erfahrung, ich geb ihn für 2¢.
MfG Klebwax
oberallgeier
23.02.2016, 16:19
.. 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 (https://www.youtube.com/watch?v=jgm9DhS7vS4) 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.
.. 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?
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
25.02.2016, 22:34
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 startenfahren 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*.
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 :D
Ich arbeite eben mit dem MSP430 von TI und bin in der Beziehung Steuerung-seitig, klar im Vorteil. ;)
31359
Der hat interne DMA Logic,
3136031361
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
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.