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
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 ?Zitat von Pali64
Ciao sagt der JoeamBerg
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
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.
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.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 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.
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.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.
MfG Klebwax
Strom fließt auch durch krumme Drähte !
Hallo Klebwax,
Danke für dein Ausführlicher Post.
aber...
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
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.
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.(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)
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.
Nochmal: aus Sicht der Datenübertragung ist I2C ein synchroner Bus.Im Asynchronem Betrieb ..
MfG Klebwax
Strom fließt auch durch krumme Drähte !
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
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. 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 komplexen Bewegung (leider ein schrecklich schlechtes Video) 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.
Ciao sagt der JoeamBerg
Berechtigungen
Zitieren
Lesezeichen