Ich suche für verschiedene Projekte (Heizung, Hydraulik, Getreideanlage) Servo-Stellantriebe (für Klappen, Schieber, Ventile, Dosierräder...). Meine Idee war eine klassische analoge Servoschaltung: vom µC (vermutlich RasPi) per ADC ein Signal ausgeben, mit einem Positionsrückmeldepoti vergleichen und nach Signalaufbereitung (vermutlich PWM) per H-Brücke damit einen Motor zu treiben. Vom Prinzip wie hier beschrieben: Beitrag "Steuerung/Regelung Stellmotor" Meine Wunschmotoren sind aber etwas heftiger: Pollin 310554 (12V, 3 A Leerlauf / 27 A max) Pollin 310477 (12V, 0,5 A Leerlauf / 12 A max) Leider finde ich keine fertigen Servoregler als Modul für diese Leistung. Ich habe mir jezt von den TLE4206G ein paar bestellt. Der TLE4206G beinhaltet die Komparatoren, PWM-Generator, den H-Treiber und eine H-Brücke, die aber nur mit 0,8 A max angegeben ist. Gibt es eine halbwegs einfache Möglichkeit, die Brücke mit externen MOSFET zu verstärken, so ähnlich wie man das mit der Darlington-Schaltung oder Emitterfolgern bei bipolaren Transistoren macht? Ohne daß im Umschaltpunkt ein Shoot-Through erfolgt? Oder sollte ich dafür nochmal einen externen H-Brückentreiber zwischen schalten? Ich hoffe mal, der Brücke ist das egal, wenn sie nur ein kleines IC treibt. Wenn ja, was? IR2110 (aus einer IR AN-978)? IR2184? Welche MOSFET passen dann? Oder gleich die ganze Komparatormimik mit OP-Amps halbdiskret aufbauen?
:
Bearbeitet durch User
Wolfgang R. schrieb: > Gibt es eine halbwegs einfache Möglichkeit, die Brücke mit externen > MOSFET zu verstärken, so ähnlich wie man das mit der > Darlington-Schaltung oder Emitterfolgern bei bipolaren Transistoren > macht? Sowas hatten wir gerade hier: Beitrag "Re: Störimpulse bei PWM" Und es sollte möglich sein, die H-Brücke aus meinem Servoelektronik Projekt mit dem TLE4206 anzusteuern: Beitrag "Re: RC-Servoelektronik für DC-Motor" Shoot-Throughs sind nur dann problematisch, wenn du Halbbrücken simultan ansteuern würdest, der Trick bei den H-Brücken ist aber, die diagonal gegenüberliegenden Endstufen anzusteuern. Soweit ich das bei dem TLE4206 sehe, macht er das auch so, das er auch nie beide Endstufen gleichzeitig aktiviert - dafür scheint der 'Protection & Logic' Block da zu sein. Kannst du ja nochmal checken, wenn die Bausteine da sind und du sie ansteuerst - vllt. testweise mit einem kleinen Motor.
:
Bearbeitet durch User
Ich denke jetzt mal laut weiter und protokolliere meine Recherchen. Eine Beitrag "Diskrete H-Brücke" aufzubauen ist offensichtlich kein Kinderspiel und nichts für Quereinsteiger, die nur nach einen schnellen Lösung suchen. Ich finde hier http://www.homofaciens.de/technics-base-circuits-h-bridge_ge.htm eine verständliche Diskussion der Problematik. In Abb 17 gibt's auch einen Schaltungsvorschlag für ein RCD-Netzwerk , das eine Totzeit gegen den shoot-through produziert. Wenn ich richtig sehe, geht das auf Kosten der Schaltgeschwindigkeit und produziert damit unnötige Verlustleistung. Weitere Verfeinerung kostet viel Hühnerfutter aka Fehlerquellen. Weitere Recherche hier im Forum nach dem IR2184 bringt mich auf diese Musterschaltung https://www.mikrocontroller.net/articles/Motoransteuerung_mit_PWM#2-Quadrantensteller_mit_Halbbr.C3.BCcken_Mosfettreiber mit 2 IRFZ44. Das sieht übersichtlich aus, die Bauteile sind günstig und verfügbar. Fein :-) Ein Problem sehe ich in der Bootstrapschaltung (D1, C2) für die VB (10 V über Betriebsspannung, korrekt?). Ich vermute mal, daß der TLE4206G den Motor voll durchschaltet, wenn Ist- und Sollposition weit auseinander liegen. Damit habe ich keine PWM-Taktung mehr, die mir C2 lädt, richtig? Was spricht dagengen, die "einige Millisekunden" durch einen größeren Kondensator C2 zu strecken? Sauberer wäre wohl, einen getrennten Stepup-Wandler mit unabhängiger Taktung für VB vorzusehen. Die gibts in China (z. B. http://www.ebay.de/itm/Neu-DC-DC-SX1308-Converter-Step-up-Power-Module-Booster-Board-Adjustable-/272266585362 ) als Module für 1 Euro. Würde es zur Not auch ein NE555 o. dgl. tun? Gibt es Brückentreiber für P-N-Brücken, um dieses Problem zu vermeiden? Die IRFZ44 sind mit 41 A angegeben, sollten also den Maximalstrom meines großen Motors grade noch so ertragen. Ein IRFB7430 / IRFB7434 (z.B.) ist mit Ic25 von 195A angegeben. Kann diese Sicherheitsmarge das Leben einfacher machen? Kann ich den auch noch so einfach mit einem IR2184 als Brückentreiber ansteuern? In den Datenblättern finde ich "input capacitance" von 1470 pF für den IRFZ44N, vs. 10820 pF für den IRFB7434. Ist das der "casus knacki"? Der IR2184 ist mit 1,4 / 1,8 A Ausgangsstrom angegeben, was bei 12 V gut zu den 10-Ohm-Gate-Widerständen in der Beispielschaltung passt. Das ergibt Zeitkonstanten von 1,5 ns vs 11 ns. Wenn (nur mal angenommen, ich warte noch auf das Bauteil) der TLE4206G eine PWM von 100 kHz produziert, dann dauert ein Zyklus 10 µs, also tausend mal so lang. Täuscht mich mein Gefühl, daß ich da im Brückentreiber thermisch noch auf der sicheren Seite bin? Andererseits dauert das Umschalten im Transistor 7x so lange, d.h ich habe bei gleichem Laststrom die 7-fache Erwärmung am Transistor, korrekt? Also weg vom Extrem. IRFZ44 55V 1470 pF / 0,0175 Ohm IRFZ48 55V 64A 1970 pF / 0,014 Ohm IRF1018 60V 79 A 2290 pF / 0,0084 Ohm IRF3205 55V 110 A 3247 pF / 0,008 Ohm, IRF1405 55V / 169 A / 5480 pF / 0,0053 Ohm IRFB7434 40 V 190 A 10820 pF / 0,00125 Ohm (Alle bei Reichelt, TO-220AB) Es wäre aber wohl an eine Strombegrenzung zu denken. In einer 220V-Umgebung würde ich jetzt für jeden Motor ein getrenntes Schaltnetzteil vorsehen. z.B. so was hier http://www.ebay.de/itm/Schaltnetzteil-5V-12V-24V-AC-To-DC-Switch-Power-Supply-Netzteil-Trafo-LED-Strip-/282219467007 in feiner Abstufung bis 50 A. 12 V / 10 A z.B. für 12€ Für KFZ-Umgebungen finde ich z. B. hier http://www.ebay.de/itm/150W-10-32V-to-12-35V-6A-Step-Up-Voltage-Charger-Power-DC-DC-Boost-Converter-/172463040247 einen 6A DC-DC-Konverter für 1 €. Könnte der (oder ggf ein etwas größerer Bruder) auch die Rolle der Strombegrenzung übernehmen? Vielleicht reicht ja auch eine einfache Sicherung, die nur dann fliegt, wenn bei einer mechanischen Störung der Motor längere Zeit blockiert und damit Maximalstrom zieht? Oder wäre es besser/einfacher, eine Strombegrenzung in die Brücke einzubauen? Aber wie?? Shunt, OP-Amp, Hysterese/Totzeit? So daß im Überlastfall der Motor mit Maximalstrom getaktet wird? Gibt es sowas ähnliches wie den LTC1154 (High-side-MOSFET-Treiber mir Stromsensor) auch für eine H-Brücke?
:
Bearbeitet durch User
Wolfgang R. schrieb: > Vielleicht reicht ja auch eine einfache Sicherung, die nur dann > fliegt, wenn bei einer mechanischen Störung der Motor längere Zeit > blockiert und damit Maximalstrom zieht? Klar kann man da ne Schmelzsicherung nehmen. Die muss dann getauscht werden. Also erstmal Anforderung definieren: Ist ein blockierender Motor ein unerlaubter Fehlerfall oder darf der Motor kurzzeitig blockieren? Wenn 1: Sicherung, ggf. selbstrückstellend, wenn 2: Temperaturmessung, Abschalten bei Übertemperatur Weiterhin: Ist ein blockierender Motor der einzige Fehlerfall, oder gibt es auch dauerhafte Überlastung? Wenn ja, was soll dann geschehen? > Oder wäre es besser/einfacher, eine Strombegrenzung in die Brücke > einzubauen? Aber wie?? Shunt, OP-Amp, Hysterese/Totzeit? So daß im > Überlastfall der Motor mit Maximalstrom getaktet wird? Da gibt es viele Möglichkeiten. Ein Shunt müsste sehr niederohmig sein, denn 27² ist eine große Zahl. Ist aber eine einfache und verlässliche Methode. Gibt natürlich auch Hallsensoren für sowas. Allgemeiner Bausatz für Ebay/Google-Suchbegriffe: "Arduino + englischer Begriff". In dem Fall also: "Arduino Current Sense". > Gibt es sowas ähnliches wie den LTC1154 (High-side-MOSFET-Treiber mir > Stromsensor) auch für eine H-Brücke? Es gibt integrierte Brückentreiber, ja. Den Stromsensor musst du selbst dazusetzen, ich kenne keinen wo der schon mit drin ist. Bei all den Funktionen die du willst, sollte man ggf. nen µC in Betracht ziehen. - 2 PWM Kanäle für die Brückenansteuerung, Tiny26 (und bestimmt weitere) haben dazu noch ne Totzeit eingebaut) - diverse GPIO-Pins für Status-LEDs usw. - Einfache Möglichkeit eine Statemachine zu implementieren (Standby, Betrieb, Störung z.B.) - Drehzahlerkennung durch Messung der Brückenspannung und entsprechende Signalformung (DSV), wäre eine einfache Möglichkeit einen blockierenden Motor zu erkennen Die H-Brücke selbst baut man dann mit 2 Halbbrücken auf. IR2110 ist so mein Standardtreiber. Wenn du sehr hohen Wirkungsgrad willst, solltest du dich vielleicht nach anderen Möglichkeiten umsehen, 10nF Gatekapazität umzuladen. "quasi resonant gate switching" ist so ne Möglichkeit. Das löst dein Bootstrap-Problem allerdings noch nicht. 1. Ja, man kann Cbst größer machen. Elkos verbieten sich aber. Du musst rechnen: Gate-Leckstrom, Schottky-Leckstrom, Cbst. Da können sich auch Zeitkonstanten von diversen Sekunden ergeben bevor der FET hochohmig wird. 2. Externe Boost-Spannung geht auch, ja. Und ja, du kannst auch nen 555 als Schaltwandler benutzen. 3. Quasi Resonant Gate Switching befördert normal Überspannung zurück nach Vcc per Diode. Die kannst du natürlich auch auffangen und in nen Elko befördern. Musst nur aufpassen, dass Ugsmax nicht überschritten wird. Vorteil gegenüber normalem Bootstrap: Cbst sieht nur Gleichspannung mit etwas Ripple, kann daher ein Elko sein. Beim klassischen Boostrap (z.B. laut IR2110 DB) fließt ein sehr hoher Strom durch den Kondensator hindurch. Elko verbietet sich dann.
Matthias S. schrieb: > Trick bei den H-Brücken ist aber, die diagonal > gegenüberliegenden Endstufen anzusteuern. Soweit ich das bei dem TLE4206 > sehe, macht er das auch so, das er auch nie beide Endstufen gleichzeitig > aktiviert - dafür scheint der 'Protection & Logic' Block da zu sein. > Kannst du ja nochmal checken, Ja, Dein Schaltungsvorschlag sieht genau so einfach aus, wie ich mir das erhoffft habe. Das Problem ist, daß ich an das Signal zwischen "Protection Logic" und "Half Bridge" im TLE4206 nicht ran komme. Ich habe nur das Ausgangssignal der Brücken, bräuchte aber deren Eingangssignale. Es könnte also durchaus sein, daß beide Brücken High bzw beide Low sind, wenn der Motor bremst. Dann habe ich verloren. Wie kann ich das "nochmal checken"? Oszi ran und kucken und hoffen? Einfach ausprobieren und wenn's raucht, neue Teile ordern? Ich werd mich erst noch mal ins Handbuch vergraben.
Ist die Lösung vielleicht schon in einem Päckchen auf dem Weg zu mir? http://www.ebay.de/itm/272283879122 "Double BTS7960B DC 43A Stepper Motor Driver H-Bridge PWM For Arduino smart Car" für fantastische EUR 9,35. Der BTS7960B beinhaltet Brückentreiber + P-N-Halbbrücke und ist nach Doku für Hochstrom-DC-Motoren im Automotive-Bereich entwickelt - perfekt. Auf dem Foto sieht man neben etwas Hühnerfutter noch einen 74HC244. Das ist ein "ordinärer" 8-fach-Treiber mit Tri-state outputs. Anschlüsse auf dem Foto erkennbar: VCC, GND, R_IS, R_EN, RPWM L_IS, L_EN, LPWM Dürfte wohl identisch damit sein: http://artofcircuits.com/product/btn7960b-43a-h-bridge-motor-driver-module Da gibt es näheren Text zu den Anschlussbelegungen. Der Link zum Modul-Schaltplan verlangt einen Dropbox-Account. Doch es gibt eine "truth table". Wenn ich danach die *_EN auf Hi lege und die *PWM an den TLE4206 (ggf. Pegelanpassung über Spannungsteiler), dann sollte das gehen? Aus dem Handbuch des BTS7960B: "Overvoltage, overtemperature and overcurrent are indicated by a fault current ... at the IS pin". Damit könnte man evtl. eine Strombegrenzung realisieren, aber wenn ich das richtig lese, macht er das intern eh' schon selber. "In combination with a typical inductive load, such as a motor, this results in a switched mode current limitation." Ah, und am *_IS kann ich sogar per Widerstand und ADC den Strom und Störungsstatus auslesen. Das klingt doch fast schon idiotensicher :-) Herz, was willst Du mehr? Kleiner Wermutstropfen: Lt Mouser ist der BTS7960B abgekündigt. Könnte also sein, daß es diese Module nicht mehr allzu lange geben wird :-(
THOR schrieb: > Bei all den Funktionen die du willst, sollte man ggf. nen µC in Betracht > ziehen. Das ist mir durchaus bewußt. Aber da steht eine steile Lernkurve davor :-( Bei Atmegas & Co habe ich es nicht über "Hallo Welt" / blinkende LEDs hinaus gebracht. Ja, ich habe vor 35 Jahren meinen ersten "PC" selber gelötet, Graphikkarten adaptiert und Treiber selber geschrieben. Ich weiß was das an Zeit kosten kann... Ich fühle mich auf dem RasPi wohl. Da kann ich über ssh zugreifen und in Hochsprachen problemlos live im System entwickeln, debuggen, modifizieren. Aber ich kann halt nicht wirklich zeitkritische Aufgaben parallel machen. Ist "DC-Servo 12V mit Scheibenwischermotoren" wirklich so eine ungewöhnliche Aufgabe, daß man das Rad jedes Mal neu erfinden muß? Trotzdem natürlich vielen Dank für Deine umfangreichen Detailantworten!
Wolfgang R. schrieb: > Das Problem ist, daß ich an das Signal zwischen > "Protection Logic" und "Half Bridge" im TLE4206 nicht ran komme. Ich > habe nur das Ausgangssignal der Brücken, bräuchte aber deren > Eingangssignale. Nö, du brauchst nur die Ausgangssignale der Brücken: Ausgang 1 sei high und Ausgang 2 sei low - Motor läuft in eine Richtung Ausgang 2 sei high und Ausgang 1 sei low - Motor läuft in die andere Richtung Ausgang 1 sei low und Ausgang 2 auch - Motor stoppt. Ausgang 1 high und Ausgang 2 auch - Motor stoppt. Genauso wird die H-Brücke im RC-Servoelektronik Projekt auch angesteuert, wenn auch vom Mikrocontroller. Aber ob das ein MC oder der TLE ist, ist wurscht. Das sollte also ohne extra Treiber klappen. Sowas wie der IR2110/2112 ist eine schöne Sache, hat aber einen Haken. Die Ladungspumpe wird nur geladen, wenn der Treiber regelmässig getaktet wird. Für deine Zwecke ist es also günstiger, auf kräftige P- und N-Kanal MOSFet zurückzugreifen und es diskret aufzubauen. Als P-Kanal ist z.B. der IRF4905 geeignet und als N-Kanal entweder der IRLZ44, wenn du nur Logiklevel hast, oder IRFZ44 für höheres Ugs. Dickere gehen natürlich auch, einen IRFB3207 oder IRL3803 kriegst du vermutlich nicht kaputt, eher raucht das Netzteil ab. Wolfgang R. schrieb: > Ist "DC-Servo 12V mit Scheibenwischermotoren" wirklich so eine > ungewöhnliche Aufgabe, daß man das Rad jedes Mal neu erfinden muß? Hatte mich auch gewundert, deswegen habe ich die RC-Servoelektronik gebaut. Denkbar wäre es natürlich, diese noch mit einem Poti zu versehen, dann hat man ein Power Servo mit RC Kontrollsignal. Angedacht war es immer, aber dazu gekommen bin ich noch nicht.
:
Bearbeitet durch User
1 | VCC |
2 | + |
3 | | |
4 | .--------o----------. |
5 | | | |
6 | | | |
7 | | | |
8 | |/ \| |
9 | .-----| |------. |
10 | | |> <| | |
11 | | | | | |
12 | | ___ | .-. | ___ | |
13 | -------o-|___|-o-------( X )-------o-|___|--o--------- |
14 | | | '-' | | |
15 | | | | | |
16 | | |< >| | |
17 | '-----| |------' |
18 | |\ /| |
19 | | | |
20 | | | |
21 | | | |
22 | '--------o----------' |
23 | ' |
24 | GND |
25 | (created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de) |
Vlt. wie früher? Muss man mal sehen, wie warm das wird BD244/245 und die Widerstände 2.2R StromTuner
Matthias S. schrieb: > du brauchst nur die Ausgangssignale der Brücken: > Ausgang 1 sei high und Ausgang 2 sei low - Motor läuft in eine Richtung > Ausgang 2 sei high und Ausgang 1 sei low - Motor läuft in die andere > Richtung > Ausgang 1 sei low und Ausgang 2 auch - Motor stoppt. > Ausgang 1 high und Ausgang 2 auch - Motor stoppt. fehlt da nicht noch "Ausgang X hochohmig - Totzeit zur Rettung der MOSFET vor shooting through" ? Und genau dann hätt' ich meine beiden "Booster" auch gesperrt. Vorzugsweise pro Brücke einzeln betrachtet, denn ich weiß nicht, ob man sich auf Deine Annahme verlassen kann, es wäre eine Diagonalmimik implementiert. Aber wenn es so ist, hast Du recht. Axel R. schrieb: > Vlt. wie früher? So was in der Art war mein erster Gedanke. Und warum kann man sowas ähnliches nicht auch in FET machen? Oder kann man? p-Kanal unten und n-Kanal oben? Wie heißen die Suchbegriffe? Spannungsfolger? Impedanzwandler? Google, Wiki & Co finden da fast nur mehr OpAmps. engl. "unity gain buffer" https://www.google.de/search?q=unity+gain+buffer+mosfet Das hier https://en.wikipedia.org/wiki/Buffer_amplifier#Impedance_transformation_using_the_MOSFET_voltage_follower muß ich mir mal in Ruhe ansehen. > Muss man mal sehen, wie warm das wird > BD244/245 und die Widerstände 2.2R Reichelt sagt: man kann die günstig haben, aber... BD244 -> max 6 A BD245 -> max 10 A Von den Vollast 27 A des "großen" Zielmotors sind wir also noch weit weg. Aber es gibt ja in bipolar bestimmt auch dickere Dinger. Wie kommst Du auf den Wert von R? Zielstrom / Verstärkungsfaktor = Spannungsabfall?
Wolfgang R. schrieb: > Wie kommst Du auf den Wert von R? > Zielstrom / Verstärkungsfaktor = Spannungsabfall? Ja - so pixdaumen. Was der TLE so hergibt und die benötigete U_be. Der BD244 macht nur 6A? Ja - hab ich mich vertan. 245/246 meinte ich. geht aber auch nur bis 15A max. sry StromTuner
http://www.reichelt.de/BD-Transistoren/BD-249C/3/index.html?ACTION=3&LA=446&ARTICLE=5156&GROUPID=2882&artnr=BD+249C&SEARCH=bd249 http://www.reichelt.de/BD-Transistoren/BD-250C/3/index.html?ACTION=3&LA=446&ARTICLE=5159&GROUPID=2882&artnr=BD+250C&SEARCH=bd250 reicht trotzdem nicht. Aber an die dachte ich eigentlich und bin von ausgegangen, das die 245/46 nur weniger Spannung können StromTuner
Wolfgang R. schrieb: > Aber es gibt ja in bipolar bestimmt auch dickere Dinger. just for Reference: https://www.mikrocontroller.net/articles/Transistor-%C3%9Cbersicht MJ2955 = 2N3055 Reichelt kennt: 2N 3055-ST :: Transistor NPN TO-3 60V 15A 115W - 0,92 € 2N 3771 :: Transistor NPN TO-3 50V 30A 150W - 1,60 € größter PNP der 2N-Serie im TO-3 2N 6287 :: Transistor PNP TO-3 100V 20A 160W - 3,35 € ah MJ 11015 :: Transistor PNP-Darl TO-3 120V 30A 200W - 3,15 € MJ 11033 ONS :: Transistor PNP-Darl TO-3 120V 50A - 9,45 € BD 250 :: Transistor PNP TO-3PN 100V 25A 125W https://www.mikrocontroller.net/articles/MOSFET-%C3%9Cbersicht IRF 3205 :: Leistungs-MOSFET N-Ch TO-220AB 55V 110A - 0,69 € IRF 4905 :: Leistungs-MOSFET P-Ch TO-220AB 55V 74A - 1,15 €
Wolfgang R. schrieb: > Und warum kann man sowas ähnliches nicht auch in FET machen? > Oder kann man? p-Kanal unten und n-Kanal oben? Ist das mal ein Anfang? (Quelle http://www.tubecad.com/2009/08/blog0168.htm ) Das ist wohl für Audio o-ä AC gedacht. Ein- und Ausgangskondensatoren müßten also weg gelassen werden. Evtl. bräuchte ich Hilfsspannungen unter GND / über VCC? Einfach ist anders... Irgendwie fehlt mir noch das Gefühl für FETs.
Bei den Bipolaren geht der hfe bestimmt auf 20 runter, da darfste dann 2-3A Basisstrom reinschicken. Das sind allein schon über 2W. Dann kann der in Kollektorschaltung nicht sättigen, sind pro leitendem Transistor nochmal knapp 20W. Und dann die Umschaltverluste noch drauf. Läuft mit FETs besser, die hohen Sperrspannungen braucht man nicht, dafür kann dann der Rdson kleiner werden. Wenn die Ansteuerung nicht ganz ungeschickt ist, reicht TO220 mit kleinen Kühlfahnen. FETs in TO247 gibts natürlich auch, dicke Brummer fürs ganz Grobe. https://www.reichelt.de/IRFP-IRFRC-Transistoren/IRFP-150N/3/index.html?ACTION=3&LA=446&ARTICLE=41676&GROUPID=2893&artnr=IRFP+150N&SEARCH=MOSFET%2BTO-247 Mit 2nF hält sich auch die Gatekapazität in Grenzen.
Wolfgang R. schrieb: > So was in der Art war mein erster Gedanke. > Und warum kann man sowas ähnliches nicht auch in FET machen? > Oder kann man? p-Kanal unten und n-Kanal oben? Kann man. Aber ich glaube, du denkst viel zu kompliziert. Oben P-Kanal, unten N-Kanal und diagonal gegenüberliegende MOSFet gleichzeitig durchsteuern - fertig ist die Laube. Da gibt es auch kein Shoot-Through. Du musst nur darauf achten, das du die MOSFet mit genügend Ugs ansteuerst, also die P-Kanal ruhig mit -12V zwischen Source und Gate und die N-Kanaler, wenn es keine Logikleveltypen sind, mit 12V. Warte doch mal ab, bis die TLE4605 angekommen sind und mess dann das Verhalten der Ausgänge in der Standardschaltung aus dem Datenblatt. Merke: Eine H-Brücke ist keine Halbbrücke.
:
Bearbeitet durch User
Wolfgang R. schrieb: > Wolfgang R. schrieb: >> Und warum kann man sowas ähnliches nicht auch in FET machen? >> Oder kann man? p-Kanal unten und n-Kanal oben? > > Ist das mal ein Anfang? > (Quelle http://www.tubecad.com/2009/08/blog0168.htm ) > Das ist wohl für Audio o-ä AC gedacht. > > Ein- und Ausgangskondensatoren müßten also weg gelassen werden. > Evtl. bräuchte ich Hilfsspannungen unter GND / über VCC? > Einfach ist anders... > > Irgendwie fehlt mir noch das Gefühl für FETs. Das sind Audio-Endstufen mit Ruhestrom. Das was im Datenblatt jedes Gatetreiber ICs steht, das kannste so wie es da ist aufbauen. IR2110 o.Ä. Dann haste ne Halbbrücke. Davon baust du 2, dann isses ne H-Brücke. Dann hast du 4 Logik-Leitungen, die steuerst du dann geeignet an. Shoot-Through verhindern die Gatetreiber-ICs idR. schon selbst. Ergo kannst du im einfachsten Fall hi1+lo2 und hi2+lo1 zusammenschalten und die an deine vorhandene (TLE...) Logik hängen. Pegelwandlung etc. nicht vergessen. Das muss man dann wegen der Bootstrap-Kondensatoren mit PWM ansteuern. Wenn der TLE die nicht liefert: Ein NE555 lässt sich so beschalten, dass ne DutyCycle-variable PWM rauskommt. DC über 50%: Rechtslauf, DC unter 50%: Linkslauf. Was macht dieser TLE Servecontroller eigentlich, schaltet der den Motor hart ein und wieder hart aus, sobald die Sollpositoin erreicht wurde? Oder stetige Regelung?
Es ist nach wie vor nicht sinnvoll, Halbbrücken Treiber zu nehmen, um eine H-Brücke aufzubauen. Abgesehen vom Shoot-Through Problem ist es bei den Bausteinen mit Ladungspumpe unnötig kompliziert, die PWM zu erzeugen. Der einzige Vorteil ist die Verwendung von nur N-Kanal MOSFet, der aber hier nichts bringt, da P-Kanaler mit genügend Strom und Spannungsfestigkeit preiswert und erhältlich sind. Anbei mal die Innenschaltung des NE544 - ein altes RC-Servo IC mit Motorendstufe. Wie man sieht, werden hier die Endstufen diagonal gegenüber angesteuert, verriegelt durch ein Flip-Flop. So ähnlich sieht das mit Sicherheit auch im TLE4605 aus.
Matthias S. schrieb: > Aber ich glaube, du denkst viel zu kompliziert. Wahrscheinlich hast Du recht. Matthias S. schrieb: > Warte doch mal ab, bis die TLE4605 angekommen sind wir sprechen von TLE4206, korrekt? Oder reden wir aneinander vorbei? DIe IC wären da, aber ich hab' nur DSO-Package bekommen, mit 1,27 mm Pinabstand. Die Adapterboards sind auf dem Weg aus China...hoffe ich...
Wolfgang R. schrieb: > wir sprechen von TLE4206, korrekt? Ja, du hast natürlich recht. War irgendwie in einem anderen Film :-P
Ich hab' jetzt die Motoren von Pollin bekommen. Der MY2007U222 (Bestellnummer:310 554) https://www.pollin.de/shop/dt/NTQ0OTg2OTk-/Bauelemente_Bauteile/Motoren/DC_Getriebemotoren/Gleichstrom_Getriebemotor_MY2007U222.html ist für einen Stellmotor viel zu schnell. (Das war das Teil mit den 27A max) Ich könnte den evtl. noch für geregelte Antriebsaufgaben einsetzen, aber da brauch' ich nur eine Drehrichtung. Damit hat sich das "Problem H-Brücken-Boosting" zumindest für die 30A-Klasse für mich etwas gemildert. Nächster Kandidat ist der GMPD/404980-1, 12 V- Bestellnummer:310 477 https://www.pollin.de/shop/dt/MjI1OTg2OTk-/Bauelemente_Bauteile/Motoren/DC_Getriebemotoren/Gleichstrom_Getriebemotor_GMPD_404980_1_12_V_.html Da ist leider kein Maximalstrom angegeben. Testen kann ich das erst, wenn ich eine geeignete Welle finde, um den Motor zu blockieren. Multimeter pendelt zwischen 4 bis 6 Ohm, das wären dann 2 bis 2,5 A Kurzschlußstrom. Vielleicht reicht da ja eine bipolare Spannungsfolgerschaltung, wie von Axel weiter oben Beitrag "Re: Servosteuerung 30 A - H-Brücke verstärken?" vorgeschlagen. Ich hab' noch zwei Linearantriebe mit Rückmeldepoti, die ich für einen Fernsteuerjob einsetzen wollte, die sind mit 3,7 A angegeben. https://www.voelkner.de/products/267953/Elektrozylinder-12-V-DC-Hublaenge-50-mm-1200-N-DLA-12-40-A-050-POT-IP65.html Die passen da perfekt mit ins Schema. Ja, und außerdem hab' ich 5 Euro in meine Ungeduld investiert und DSO/SOP-Adapter für die TLE4206 in Deutschland bestellt. Und ich hab' in der eBucht noch NE544 aufgetan. Der kann aber mit 400 - 500 mA noch weniger Ausgangsstrom als der TLE4206.
:
Bearbeitet durch User
Wolfgang R. schrieb: > Und ich hab' in der eBucht noch NE544 aufgetan. Der kann aber mit 400 - > 500 mA noch weniger Ausgangsstrom als der TLE4206. Ja, das ist ein altes Ic für RC-Servos und auch von der Ansteuerung genau für diesen Aufgabenbereich gedacht. Es wird mit den Standardservo Impulsen (20ms Rahmen mit 1-2ms Pulsen) gefüttert. Gepostet hatte ich das nur als Beispiel für die Ansteuerung einer H-Brücke, da wir die Innenschaltung des TLE ja nicht haben.
:
Bearbeitet durch User
FYI - Hier Beitrag "Vermeiden von Shoot Through in einer H-Bruecke" finde ich einen recht übersichtlichen Thread zur Frage shoot-through, RCD-Netzwerk auslegen, Ersatzweise CMOS-Dead-Time-Schaltung, (Schmitt-Trigger, z.B. 40106 und 4093) pros's, con's .... Die treiben dort aber MOSFET direkt mit 3 parallelen CMOS, was mir etwas dürftig scheint. Die CMOS liefern grad mal 15 mA, oder? Nochmal Daten von weiter oben: IRF 3205 :: Leistungs-MOSFET N-Ch TO-220AB 55V 110A - 0,69 € IRF 4905 :: Leistungs-MOSFET P-Ch TO-220AB 55V 74A - 1,15 € IRFZ44 55V 1470 pF / 0,0175 Ohm IRF3205 55V 110 A 3247 pF / 0,008 Ohm, Zeit = Ladung / Strom , damit komme ich auf 100 ns für den IRFZ44, 215 ns für den IRF3205. Da ist noch keine Miller-Charge und was es da sonst noch gibt dabei. Zum Vergleich: Einzel-Mosfet-Treiber liefern 1,5 A (TC4426 & Co) oder ein MCP 1406 6A Ich bewege mich zwischen 3 Problemecken: - shoot through - Erwärmung bis zur Zerstörung - langsame Schaltzeiten - Erwärmung - lange Totzeiten - Suboptimale Leistung, Belastung der Freilaufdioden Hier könnte man wohl mehr finden, wie man das alles berechnet, allerdings für IGBT http://www.infineon.com/dgdl/Infineon-AN2007_04_Deadtime_calculation_for_IGBT_modules-AN-v1.0-en.pdf Rechnen oder probieren? Die meisten meiner angedachten Anwendungen sollen im Freien laufen (Landmaschinen, Getreidelager...) und deswegen möglichst dicht gekapselt werden (IP68). Wärmeentweicklung / Kühlung gerät da schnell zum Akt.
Ich hab' jetzt meine TLE4206 auf Adapterboards gelötet und die Datenblätter nochmal studiert. Dabei fällt mir auf, daß der gar keine PWM produziert, sondern sich drauf verläßt, daß man sich über eine Totzeit auf das Ziel "einschießt", d.h. der Motor wird einfach ein festes Intervall vor der Übereinstimmung abgeschalten. Das mag ja für konstante Reibungsverhältnisse ganz gut gehen, aber was mach' ich z.B. wenn Wasserventile sich in der Saisonpause festsetzen und nach einigen Bewegungen wieder gangbar werden? Muß ich immer nachjustieren? Ich hatte für den Fall schon mal eine halbdiskrete Servosteuerung mit Op-Amps erstellt, die ich hier zur Diskussion stellen möchte: v50 ist Bezugspunkt = 0,5*vcc U1 ist ein Sägezahnoszillator mit C1 und R3 als Zeitglied. Aus R4 und R3 ergibt sich die Amplitude . Ausgang im grünen Plot. "control" ist die Regelabweichung zwischen Soll und Ist, ggf. aufbereitet über Pegelanpassung, Tiefpass, PID, ... Für die Simulation habe ich einen Sinus (lila) gewählt. U2 ist als Komparator geschaltet und produziert für "mittlere" Regelabweichungen ein PWM, dessen Effektivwert dem control-Signal annähernd proportional ist (rote Kurve). U3 und U4 bilden mit A1 einen Fensterkomparator, der "geringe Abweichungen" ermittelt (blaues Signal im oberen Plot) Dieses blendet über A3 und A4 den PWM bei geringeren Abweichungen aus (hellblau im mittleren Plot) ( Der Rest um A5 bis A8 war der Versuch, eine Totzeit gegen shoot-through über das Zeitglied R2/C2 zu generieren. Aber ich denke, das kann man mit geeigneten Brückentreibern einfacher lösen.) Damit ergibt sich folgendes Verhalten: - Für große Abweichungen fährt der Motor mit voller Spannung zum Sollpunkt - bei Annäherung an das Ziel bremst die PW proportional zur Distanz ab - in der Nähe des Zieles gibt es eine Intervall ohne Regelung (mit kurzgeschlossenem Motor = DC-Bremse) , um ein Flattern um die Ruhelage zu vermeiden. Gibt es sowas nicht als fertiges IC?
THOR schrieb: > Ja, nennt sich Mikrocontroller. Ihr habt ja alle Recht. Ich hatte gehofft, mit der ESP8266 NodeMCU einen Hochsprachenersatz für Echtzeitanwendungen zu finden und damit die Atmega-Generation überspringen zu können. Aber wenn ich mir Nicht-Implementierungen von Zähler, PWM oder den mickrigen ADC ansehe, und die fehlende kabelbasierte Slave-Anbindung (weder I2C noch SPI noch CAN noch Ethernet), dann werd' ich die kleinen Chinesen wohl wieder in die Schachtel packen und das Atmega-Board wieder raus holen. Die halbdiskrete Schaltung war das letzte Aufbäumen vor dieser Entscheidung ;-)
Genug der Theorie - jetzt hab' ich endlich mal Zeit gefunden zu testen. Kurze Antwort : Es geht. Mit - dem Getriebemotor GPMD-404980-1 von Pollin, - einer 30A-Automotive-H-Bridge VNH2SP30 von einem halben Arduino-Monster-Moto-Shield, - 12V von einem 08/15-ATX-Computer-Netzteil, - dem Leuchtweitenregler TLE4206 - und einem Standard-Poti lassen sich spannungsgesteuerte Stellantriebe realiseren mit - ca 220° Schwenkbereich - ca 5 ° Auflösung - 2s Stellzeit - 20 Nm (sic - 2000 Ncm!) Maximalmoment Ressourcen: https://www.pollin.de/shop/dt/MjI1OTg2OTk-/Bauelemente_Bauteile/Motoren/DC_Getriebemotoren/Gleichstrom_Getriebemotor_GMPD_404980_1_12_V_.html https://www.pollin.de/shop/downloads/D310477D.PDF http://www.st.com/resource/en/datasheet/cd00043711.pdf https://www.sparkfun.com/products/10182 http://www.infineon.com/dgdl/Infineon-TLE4206G-DS-v01_02-EN.pdf?fileId=db3a3043163797a6011685bdd91c1672 http://www.infineon.com/dgdl/TLE4206_AppNote_Dec04%5B1%5D%5B1%5D.pdf?fileId=db3a304320d39d590121aa7883711ca1
Als ersten Test des TLE4206G habe ich einen kleineren Motor http://www.pollin.de/shop/dt/Nzc1OTg2OTk-/Bauelemente_Bauteile/Motoren/DC_Getriebemotoren/Gleichstrom_Getriebemotor_CHM_2435_1.html direkt angeschlossen. Dieser Motor hat bei 12 V ca 0,5 A Kurzschlusstrom und 1,5 Nm Drehmoment. Er kann damit ohne Verstärkung am TLE4206G betrieben werden. Ein Datenblatt konnte ich nicht finden. Wie man auf dem Bild sieht, habe ich in die Wellenrückseite ein 5mm-Loch für einen Kerbstift gebohrt, um das Poti (mit Wellenkupplung aus der Rep-Rap-Szene) zu besfestigen. Das funktioniert, aber der Magnet im Motor hat die Bohrspäne gefressen. Auf jeden Fall habe ich seitdem immer wieder Blockaden im Motor gehabt, die auch diese Testserie beendet haben. Die Schaltung gibts im Datenblatt S 10, aber ohne die Dr und Dz am Eingang und CS als 1000 µF Elko statt 470 nF. Dafür habe ich dann den "Pfusch-Elko-Ersatz" C_CBP weggelassen (s. "Current-peak-blanking" im DB). Präzision vor Bauteilkosten. Von 3 Exemplaren des TLE4206G funktioniert nur eines :-( . Das mit dem SMD-Löten muß ich wohl noch üben. Erste Erkenntnisse: In Ruhelage sind beide Motorausgänge auf HI (=12V) durchgeschalten. Wie schon geschrieben, vollzieht der TLE4206G kein geregeltes Einbremsen auf die Zielposition, sondern grob geschätztes "Einschießen" per Schwarz-Weiß-Regelung. Alle Bedenken bzgl. PWM-Tauglichkeit nachgeschalteter Brücken sind für dieses IC also hinfällig. Ein 90°-Winkel des Motors wird mit den Standard-Werten der Widerstände beim langsamen Durchdrehen des Sollwert-Poti in ca 8 bis 12 Schritten abgestottert. Das ergibt eine Auflösung von ca 10°. Der gesamte nutzbare Stellbereich mit dem verwendeten Poti aus der Pollin-Basteltüte beträgt ca 220°. Lt DB nutzt der TLE4206G 92 % des Poti-Spannungs-Intervalls. Ich hatte zunächst einen C_CPB von 100 nF dran und den dann raus genommen. Es war keine Änderung am Regelverhalten zu erkennen. Ersetzen des Sollwert-Poti durch 10k (statt 1k) ergibt keine merklichen Änderungen. Weitere Tests scheiterten an einer nicht mehr lösbaren Blockade des Motors, vermutlich durch Bohrspäne. Das positive daran ist der Nachweis, daß der TLE4206G den Blockadestrom des CHM 2435 von 0,5 A über Minuten unbeschadet übersteht.
Für höhere Drehmomente habe ich den GPMD_404980-1 vorgesehen. Der dreht deutlich langsamer als der ursprünglich vorgesehene Typ MY2007U222, was durchaus Vorteile hat: - das Regeln geht bei niedriger Drehzahl leichter. - etwas mehr Drehmoment (2100 Ncm lt Datenblatt bei Blockade mit 12V) - max 9 A bei 12V vereinfacht die Elektrik Als Brückentreiber reicht ein VNH2SP30. Den gibts im Doppelpack als Arduino Monster-Moto-Shield-CN-Klon für 5,50 in der chinesichen Bucht, z.B. http://www.ebay.de/itm/272442305716 Das Teil ist wesentlich handlicher als der 43A- BTS7960B mit seinem klobigen Kühlkörper. Im mehrminütigen Leerlauf des GPMD erwärmt er sich grad mal um 3K. Ohne Arduino ist das Arduino-Shield-Format etwas unhandlich. Welcher Idiot versetzt für eine Bastler-Komponente Stiftleisten um eine halbe Teileinheit, damit sie nicht mehr auf ein Breadboard passen? Du sollst keine anderen Götter neben mir haben... Unter o.G. Link gibt es zum Glück auch Einzel-Module in kompakterem Format. Nachfüllpack aus CN ist unterwegs. Der VNH2SP30 hat zwar einen PWM-Eingang, der kann aber einfach auf Hi gelegt werden. Das ist ein großer Vorteil gegenüber Bootstrap-Schaltungen für den Hi-Side-Treiber. Ich finde im Datenblatt keine Angabe zum maximalen Logikpegel. Ich habe mich also hasenfüßig auf die 5V des Arduino-Shields begrenzt, obgleich ich vermute, daß der Chip auch 12 V ab kann. An einem ATX-Netzteil sind 5V ja eh' verfügbar. Testen werde ich das erst, wenn meine Bastelkiste nachgefüllt ist. Mit "PWM" auf 5V und einem der beiden "IN"-Eingänge auf Masse dreht der Motor - fein. Rest siehe Datenblatt, S. 14: "truth table" . Damit kann ich den VNH2SP30 über einfache Pegelwandler (22k + 4,7V-Z-diode) an den TLE4206G anschließen. Test - fein :-) Die mechanische Montage des Rückmelde-Potis sieht man auf dem Bild. Ein 6mm-Vierkant-Messing passt in die Verzahnung des Motors. Als Kupplung habe ich ein 8x8x1-Vierkantrohr mit durchgebohrten Schrauben. Der Hersteller des Motors verkauft passende 8-Stern-Wellen, was bei voller Drehmomentausnutzung wohl anzuraten ist. Die haben außen 8 mm. Wird sich irgendwie kuppeln lassen. Test -fein :-))) Das Regelverhalten ist ziemlich identisch mit dem kleinen Motor ohne Verstärkerbrücke.
Kann mir bitte jemand sagen, wie ich die Bildanhänge im Forum prüfen / editieren kann??
Im GPMD habe ich keine Bohrspäne, also kann das Testen weiter gehen. Die Geheimnisse des Feintunings für den TLE4206 finden sich nicht im Datenblatt, sondern in der oben verlinkten AppNote (S 8) R_FB (Widerstand am Feedback-Poti am Motor) von 47k -> 27k : Die Auflösung halbiert sich. Ich habe also jetzt ~ 20 statt vorher ~ 10 Stellruckler für einen 90°-Winkel, d.h. ca 5° pro Einzel-Ruckler. Das nutzbare Intervall reduziert sich auf ca 150° am Motor. Das läßt sich beheben, indem auch R_REF (also der Widerstand am Geberpoti) auf 27k gesetzt wird. Dann sind wir zurück auf 220° mit 5° Auflösung. Das ist bisher das Optimum, welches ich erreichen konnte. Nächster Schritt war R_REF auf 4k7 und R_FB auf 10k Die Auflösung wird jetzt zu fein. Manchmal klappt es, manchmal bleibt das System in oszillierendem Zustand: Der Motor zittert hin und her. Lt Datenblatt ist er mit 10% ED angegeben. Könnte also sein, daß das Zittern ihm den Garaus macht. Oder dem Treiber. Ich vermute mal, daß der Eingang des TLE nach Strom, nicht nach Spannung arbeitet. Auf Seite 10 der AppNote findet sich die Eingangsschaltung, die dunkel Assoziationen an "Stromspiegel" weckt. Mit R_REF << R_FB konnte ich das nutzbare Intervall am Motor über den sinnvollen Bereich hinaus treiben: Der Motor überdreht gnadenlos das Poti :-( Vermutlich ist intern die Verbindung zwischen Achse und Schleifer gebrochen. Ende der heutigen Testreihe.
Damit kommt die Frage nach einem geeigneten Feedback-Poti wieder aufs Tablett, die ich bisher verdrängt habe. Kandidaten: Vishay 357 Drehwinkel elektrisch 340 ° Drehwinkel mechanisch 360 ° Stückpreis 20,- :-(( http://www.mercateo.com/p/615-W51738/Potentiometer_1k_1W_Typ_357.html Polyshine FHS22 Hall Effect Non-Contact Potentiometer, angle Sensor http://www.polyshine . cn/NewsDetail-43.html (sorry, die korrekte Adresse hängt am Spam-Filter des Forums) http://www.makepolo.com/products/FSE22-A-Hall-Effect-Non-Contact-p76805625.html Min Order 1000 Pieces :-((( Letzter Stand der Kommunikation: > so you can contact me in any time,any question please tell me. "Where can I buy lots of 10 .. 50 pieces of FHS22 sensors?" Schau'mer mal.... Die integrierten Hall-pseudo-Potis gibts natürlich auch in D, aber für 50 Euro aufwärts. Eine Überlegung wäre seperater Magnet und Sensor. Es liegen noch diverse I2C-Kompasse in der Bastelkiste und warten auf Test für eine Ersatzlösung. Dort finde ich noch IC-Haus MA DFN10, aber das ist so klein, daß ich es kaum anfassen, geschweige denn löten mag.
:
Bearbeitet durch User
@Wolfgang Rosner (wjr) >Damit kommt die Frage nach einem geeigneten Feedback-Poti wieder aufs >Tablett, die ich bisher verdrängt habe. Für deine Anwendung tut es jeder normale Poti, der nicht gerade extrem billig ist. >Ich habe also jetzt ~ 20 statt vorher ~ 10 Stellruckler für einen >90°-Winkel, d.h. ca 5° pro Einzel-Ruckler. ??? Seit wann ruckeln Servos? Vor allem beim normalen Stellvorgang? Da ist was oberfaul. >Das nutzbare Intervall reduziert sich auf ca 150° am Motor. Reicht doch. >Dann sind wir zurück auf 220° mit 5° Auflösung. So mies? Da ist auch was faul. >Das ist bisher das Optimum, welches ich erreichen konnte. Naja. >Die Auflösung wird jetzt zu fein. Manchmal klappt es, manchmal bleibt >das System in oszillierendem Zustand: Der Motor zittert hin und her. Tja, da muss man mehr Hystere oder ähnliches einbauen bzw. die elektrischen Zeitkonstanten des Zweipunktreglers an die mechanischen anpassen. >Könnte also sein, daß das Zittern ihm den Garaus macht. Kann sein, vor allem wenn da ausreichend Last dranhängt. > Oder dem Treiber. Weniger.
Falk B. schrieb: >>Das nutzbare Intervall reduziert sich auf ca 150° am Motor. > Reicht doch. Manchmal. Einer der geplanten Einsatzorte ist eine ESBE 5MG 5-Wege-Heizungs-Mischer: http://www.esbe.eu/de/de-de/produkte/mischer/5mg Da brauch' ich vom ersten bis zum letzten Abgang 270 °. >>Die Auflösung wird jetzt zu fein. Manchmal klappt es, manchmal bleibt >>das System in oszillierendem Zustand: Der Motor zittert hin und her. > Tja, da muss man mehr Hystere oder ähnliches einbauen > bzw. die elektrischen Zeitkonstanten des Zweipunktreglers > an die mechanischen anpassen. Wo finde ich beim TLE4206 Zeitkonstanten - außer beim Current-Peak-Blanking, aber das wirkt nur beim Anlaufen, nicht beim "Zielschießen"? Bisher konnte ich mich nur mit mehr oder weniger HystereSE zwischen Ruckeln und schlechter Auflösung entscheiden. >> 5° Auflösung. > So mies? Da ist auch was faul. Vielleicht passt der Controller nicht? Bezieht sich Deine Einschätzung auf den TLE4206? Oder einen anderen Servocontroller? NE544N steht noch auf dem Testplan.
> Tja, da muss man mehr Hystere oder ähnliches einbauen
Hab' jetzt mein Poti ersetzt und die Testreihe mit dem TLE4026G
abgeschlossen.
Der Vollständigkeit halber hier die Ergenisse. Ich hab' den Schaltplan
(Quelle: Datenblatt Infineon) als Referenz mit angegeben.
- identische Potis P_REF und P_FB je 10 kOhm
- R_REF und P_REF je 22k
- R_HYH und R_HYL je 100k
Da weiteres Reduzieren der Poti-Widerstände und/oder deren asymetrische
Auslegung schlecht für die Poti-Lebensdauer ist, habe ich die Hysterese
durch einen zusätzlichen Widerstand am Eingang HYST angepasst (nennen
wir ihn R_HYST). R_HYH und R_HYL habe ich als symmetrischen
Spannungsteiler belassen. Effektiv habe ich also gegen V_B/2
0,5*(R_HYH + R_HYL) + R_HYST = 50k + R_HYST
- R_HYST=0 (vgl. oben): , ~ 9° Auflösung, keine Schwingung
- 22k: ~ 6° Auflösung, seltenes Einschwingen 1-2 Perioden um das Ziel
- 47k: ~ 5°, regelmäßig Einschwingen, einmal Dauerzittern
- 100k: ~ 2,5° häufiges Einschwingen, gelegentliches Dauerzittern
- HYST offen: permanentes Dauerzittern
Ich denke, damit ist die Grenze des TLE4026G erreicht.
Die Anpassung wird man sicher in der Applikation noch mal nachjustieren
müssen. Ich vermute, Reibung reduziert die Schwingneigung und läßt
höhere Auflösung zu. Träge Massen werden wohl die Schwingungen erhöhen
und mehr Hysterese verlangen.
Für einen robusten Dauereinsatz würde ich die 22k / 6° als Grenze sehen,
was bei 220° Intervall einer relativen Auflösung von 1:36 entspricht.
Für kurzzeitige, dynamische Einsätze, oder wenn man nach dem Stellen die
Brücke sperrt (z.B. über den PWM-Eingang) kann man evtl. mit engerer
Hysterese arbeiten.
Falk B. schrieb: > Seit wann ruckeln Servos? Vor allem beim normalen Stellvorgang? Als Vorbereitung für den NE544-Test habe ich mir mit einem NE555 einen Servo-Signal-Generator aufgebaut: http://www.helifreak.com/showthread.php?t=275749 (Widerstände gerundet auf Bastelkisteninhalt - 22k / 470k, Poti 47 k) Test mit Servo der Marke China-extra-billig (1,67€/Stück). Und siehe da: auch diese Servos zittern ;-) Fazit: Aus der Falle "Zittern <-> Genauigkeit" raus zu kommen, braucht wohl etwas Aufwand, der über einfaches Klauonen hinausgeht ?
Falk B. schrieb: > Seit wann ruckeln Servos? Vor allem beim normalen Stellvorgang? ... und mit dem NE544 ist das kein Zittern, sondern ein Stoßen, das den ganzen Tisch erbeben läßt. Und der Drehwinkel beträgt keine 90°. Die gute Nachricht dran: es funktioniert auf Anhieb :-) Da ist viel Peripherie um den NE544 rum, an der man schrauben kann. Ich hab' die Werte aus diesem Datenblatt http://www.abcelectronique.com/forum/attachment.php?attachmentid=17276 und Widerstände auf Bastelkiste gerundet. Werd' mir heute Nacht das Datenblatt unters Kissen legen :-)
Das Datenblatt zum NE544 hilt nicht wirklich, weder unter'm Kissen noch bei intensivem Studium. Sieht aus als wäre das Wissen zur Anwendung dieses Chips bei der Digitaliserung verloren gegangen? Lasst uns denn die letzten Reste konservieren: http://www.seattlerobotics.org/encoder/200009/Servos.html -----------quote-------------- Discussion "A positive input signal applied to the input pin (4) sets the input flip-flop and starts the one-shot time period. The directional logic compares the length of the input pulse to that of the internal one shot and stores the result of this comparison (called the error pulse) and also feeds this pulse to a pulse stretcher, deadband, and trigger circuit. These circuits determine three important parameters: DEADBAND – The minimum difference between input pulse and internally generated pulse to turn on the output. MINIMUM OUTPUT PULSE – The smallest output pulse that can be generated from the {Schmitt} trigger circuit. PULSE STRETCHER GAIN – The relationship between error pulse and output pulse Adjustment of these parameters is achieved with external resistors and capacitors at pins 6, 7, and 8. Deadband is controlled by resistor Rdb. Minimum Output Pulse is controlled by Rmp. The Pulse Stretcher Gain is adjusted by capacitor Cs and resistor Rs. The trigger circuit activates the gate for a precise length of time to provide drive to the bridge output circuitry in proportion to the length of the error pulse. Resistor Rf determines the amount of feedback required for good closed loop damping. TA and TB are external PNP transistors for increased motor drive, which make a faster, more powerful servo with better resolution. The amount of servo travel is controlled by resistor Rt and can be varied to change the amount of servo rotation. If you find it necessary to change the amount of servo travel, increase the value of Rt to decrease servo travel or decrease the value of Rtto increase servo travel." -----------/quote-------------- Das bringt doch schon etwas System in meinen Testplan :-)
@ Wolfgang Rosner (wjr) >Test mit Servo der Marke China-extra-billig (1,67€/Stück). >Und siehe da: auch diese Servos zittern ;-) Das ist wohl kaum eine Referenzmarke. >Fazit: Aus der Falle "Zittern <-> Genauigkeit" raus zu kommen, braucht >wohl etwas Aufwand, der über einfaches Klauonen hinausgeht ? Sicher.
> Das bringt doch schon etwas System in meinen Testplan :-) aber keine befriedigende Einstellung mit dem NE544 :-( Ich habe die 5 oben angegebenen Widerstände durch Trimmer ersetzt und deren Werte variiert Der einzige Weg, das Zittern des Motors in der Ruhelage zu vermeiden, ist die Gain über R_S soweit abzusenken, bis das Zittern weg ist. Aber dann kann ich das Geberpoti 10° hin und her drehen, bevor der Motor sich wieder bewegt. Sobald ich die Gain etwas erhöhe, bis er gerade anfängt zu zittern, positioniert er sauber nach - in Auflösung viel feiner als der TLE4026G. Meine Nase signalisiert mir, daß ich den Wert "ED 10%" aus dem Datenblatt des Motors ernst nehmen sollte, auch wenn äußerlich noch keine Erwärmung festzustellen ist. R_MP (Minimum Output) hilft auch nicht, das Zittern weg zu kriegen. Selbst von 0 bis unendlich krieg ich zwar leichte Veränderung in der Frequenz, aber keine stabile Ruhelage. Ähnlich verhält es sich mit dem Feedback R_F. Die Einstellung der Endlage mit R_T ist instabil und schwer reproduzierbar. Offensichtlich wechselwirkt das mit den anderen Parametern. Nur gut, daß ich mein Poti diesmal nur gesteckt und nicht angeschraubt habe - es lebt noch. Mein Ziel war, eine universelle Servotreiberschaltung für verschiedene Einsatzorte zu finden. selbst wenn es gelänge, mit viel Messen und Probieren für jeden Einsatzfall eine stabile Konfiguration mit dem NE544 zu finden - für Losgrößen <<10 denke ich ist das Teil nicht vernünftig zu gebrauchen. --------- Wie also weiter? Das Problem bei großen Motoren sind wohl die hohen Massen, die im Vergleich zum Modellbauservo die Schwingneigung deutlich erhöhen. Ohne PWM-Rampensteuerung in Zielnähe, konfigurierbarem Deadband, vermutlich PI-Regler zum Ausgleich dessen Abweichung wird es wohl nicht gehen. Ich könnte meine OP-Amp-Schaltung aus Beitrag "Re: Servosteuerung 30 A - H-Brücke verstärken?" also weiter verfeinern um Tiefpass, PI-Stufe, Pegelanpasser und vermutlich separatem Endlagenbegrenzer. Dann bin ich wohl bei 2-3 LM324 für die OP-Amps +2 digitale Gatter. Der andere Weg: THOR schrieb: > Ja, nennt sich Mikrocontroller. Ich glaub' ich muß da durch...
@Wolfgang Rosner (wjr) >Der einzige Weg, das Zittern des Motors in der Ruhelage zu vermeiden, >ist die Gain über R_S soweit abzusenken, bis das Zittern weg ist. Aber >dann kann ich das Geberpoti 10° hin und her drehen, bevor der Motor sich >wieder bewegt. Sobald ich die Gain etwas erhöhe, bis er gerade anfängt >zu zittern, positioniert er sauber nach - in Auflösung viel feiner als >der TLE4026G. Du musst die Verstärkung bzw. Anstzeuerspannung für deinen Motor verringern, dann kann der einfache 2-Punkt Regler auch mit deutlich kleinerer Hysterese sauber positionieren. >Meine Nase signalisiert mir, daß ich den Wert "ED 10%" aus dem >Datenblatt des Motors ernst nehmen sollte, auch wenn äußerlich noch >keine Erwärmung festzustellen ist. Jain. Wenn der Motor nicht sonderlich warm wird, passt das schon. Die Einschaltdauer von 10% bezieht sich auf Nennlast. >Mein Ziel war, eine universelle Servotreiberschaltung für verschiedene >Einsatzorte zu finden. Eierlegende Wollmilchschweine sind selten und teuer. Man muss meistens die Reglerparameter auf dem Motor sowie die Reglestrecke (Last) anpassen. >Das Problem bei großen Motoren sind wohl die hohen Massen, die im >Vergleich zum Modellbauservo die Schwingneigung deutlich erhöhen. Ohne >PWM-Rampensteuerung in Zielnähe, konfigurierbarem Deadband, vermutlich >PI-Regler zum Ausgleich dessen Abweichung wird es wohl nicht gehen. so in etwa. >Dann bin ich wohl bei 2-3 LM324 für die OP-Amps +2 digitale Gatter. Sowas macht man heute besser rein digital, ist kleiner, billiger, und deutlich leistungsfähiger. >> Ja, nennt sich Mikrocontroller. >Ich glaub' ich muß da durch... Sieht so aus.
zurück zum TLE4026G Eine einfache Variante, die Dynamik des Motors zu bändigen, ist, "weniger Gas" zu geben. Ein konstantes 50 Hz-50%-Signal aus einem NE555 an den PWM des Brückentreibers reduziert die Geschwindigkeit auf die Hälfte und damit die kinetische Energie auf ein Viertel. Im Vergleich zu den Messungen bei 12V Beitrag "Re: Servosteuerung 30 A - H-Brücke verstärken?" ergibt sich (sonst alles gleich): - R_HYST=100k ca 2,5° Auflösung, stabiler Betrieb - 220k ca 1,5°, stabil - 470k Auflösung nicht mehr wahrnehmbar, häufiges Zittern, Das geht natürlich nur, wenn die Applikation nicht die volle Drehzahl oder Drehmoment benötigt, d.h. der Motor eigentlich überdimensioniert ist. Und es bestätigt meine Überlegung nach einer Bremsrampe bei Annäherung an das Ziel. --------------- Ich nehme auch an, daß bei einer Streckung des Gesamtweges die relative Auflösung steigt. Leider hab' ich keine 10-Gang-Poti in meiner Kiste gefunden. Der Test dazu muß also noch warten.
Falk B. schrieb: > Du musst die Verstärkung bzw. Anstzeuerspannung für deinen Motor > verringern, dann kann der einfache 2-Punkt Regler auch mit deutlich > kleinerer Hysterese sauber positionieren. Ja, das hat mit der PWM ganz gut geklappt. Falk B. schrieb: > Man muss meistens > die Reglerparameter auf dem Motor sowie die Reglestrecke (Last) > anpassen. Ist mir schon klar. Aber ich würd' halt gerne wissen wass ich tu und nicht planlos an 5 Trimmern spielen, wie es mit der NE544-Schaltung lief. Egal. War ein Experiment, und die Erkenntnis "klappt nicht" ist auch eine Erkenntnis. > Eierlegende Wollmilchschweine sind selten und teuer. Na, so langsam komm' ich da schon hin :-) Ich hab jetzt den NE544 wieder vom Steckbrett gerupft. Den NE555 hab ich als variablen Pulsbreitenmodulator geschalten und auf den PWM-Eingang der Brücke gelegt. Als R_HYST aus der TLE4206G-Schaltung habe ich jetzt auch einen Trimmer. Also zwei Parameter: - Tastverhältnis - Hysterese Ich hab' dann einen Transmotec Linearmotor mit Rückmeldepoti https://www.voelkner.de/products/267953/Elektrozylinder-12-V-DC-Hublaenge-50-mm-1200-N-DLA-12-40-A-050-POT-IP65.html aus meiner Kiste "Problem wartet schon lange auf Lösung" gezogen, an die Schaltung angeschlossen, 2 min an diesen beiden Parametern gedreht und ein brauchbares Stellverhalten erreicht :-))) Falk B. schrieb: > Sowas macht man heute besser rein digital, ist kleiner, billiger, und > deutlich leistungsfähiger. >>> Ja, nennt sich Mikrocontroller. >>Ich glaub' ich muß da durch... > Sieht so aus. Jetzt könnt' ich mich da ja wieder drücken. Aber ich hab' vor 35 Jahren 6502 mit Hexcode vom Karopapier programmiert, als meine Kumpels auf dem Atari schom Raumschiffe abgeschossen haben. Symbolische Assembler waren unerreichbarer Luxus. Eigentlich sollt' ich's ja noch können.
Nun denn, voran! Mit ELM-Chan SMC3/A http://www.elm-chan.org/works/smc/report_e.html gibts ja schon eine gute Vorlage für die µC Servosteuerung. Als Rückmelder verwenden die aber einen Encoder, was ich bei meinen Apllikationen gerne vermeiden würde: - bräuchte einen zusätzlichen Endlagengeber zum Kalibrieren - Langzeitsabilität der Position? - Stabilität unter Dreck, Feuchtigkeit und Erschütterung? - Kalibirierungslauf beim Einschalten Es sollte aber wohl nicht so schwer sein, die Encoder-Auswertung durch AD-Auswertung des Potis zu ersetzen. Wie binde ich den/die Servocontroller an den Master-Controller an? Ich denke, als "SCADA" wird in den meisten Fällen ein Raspi stehen. - analog über Spannung Eigentlich eine üble Krücke. Vorteil: wenn's nicht klappt, kann ich den Raspi abklemmen und auf Poti-Hand-Steuerung umstellen. - pseudo-analog über Pulsbreiten-Signal Auch eine Krücke. Not-Hand-Betrieb wird etwas schwieriger, aber den NE555-Servosignalgenerator hab' ich ja schon auf dem Steckbrett. Und die SMC-Vorlage hat schon einen Pulsbreiteneingang implmentiert. Und es gibt billige 12-fach-I2C-Servo-Controller aus CN in meiner Bastelkiste. - seriell? Ist das stabil? wie lange kann ein Kabel in "EMV-dreckiger" Umgebung sein? - mit USB? - mit seriell 5V? - mit seriell +-12V USB-Serial-Adapter gibts in CN für kleines Geld. Für die Christbäume aus Hubs und Adapter gibts Kabelbinder. Persistente Identifizierung auch bei identischen Adaptern ohne Seriennummer sollte per udev über die Bus-ID möglich sein. - I2C war eigentlich mein ursprünglicher Plan. Hat wohl den geringsten Hardware-Aufwand. Viele andere Sensoren, Port-Extender etc kann ich direkt an den Raspi anschließen, wenn keine zeitkritische Vearbeitung erforderlich ist. Kann ich damit mehrere Meter in rauher Umgebung (Schaltschränke, Traktor, ..) überbrücken? - CAN Das wäre wohl die Profi-Lösung. Eine Teststrecke mit 2 Raspis und easyCAN habe ich laufen. Und meinen ersten AT90CAN32 aufs Adapterboard gelötet. Aber wie hoch ist der Lernaufwand bis zu einem stabilen Ergebnis? - IP wäre natürlich am flexibelsten, aber ich denke dafür sind µC nicht ausgelegt. Auch das Timing ist mit IP sehr unsicher. Wenn ich gelegentlich IP brauche, dann kommen halt zwei Raspis an die Enden, oder meintwegen ein ESP8266 dazwischen. ---------- Die Entscheidung hängt davon ab, inwieweit ich es hin kriege, fertige C-Libs für I2C und/oder CAN mit SMC (und anderem Assembler-Zeugs) zu integrieren. Also ist mal wieder Lernen angesagt. Im Assembler-Tutorial https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Assembler_und_Inline-Assembler hab' ich mich jetzt bei der Simulation der Interrupt-Timer festgebissen. Ich hatte für ein paar Minuten erfolgreich AVR-Studio unter Wine am laufen, krieg aber jetzt nur mehr Abstürze. Aber wenn ich Assembler mit C mischen möchte, lande ich wahrscheinlich ohnehin bei der GNU-Toolchain. Also was soll ich mich mit Windows ärgern, nur um festzustellen, daß mit AVR-Studio ein Mischen von Assembler mit C nicht vernünftig geht? Damit lande ich bei simulavr. Die gängige Version 0.1.2.2 kennt keine AT90CANs. Die "neue" 1.1 hat keine fertige Echtzeitanzeige für die I/O-Register. Werd' mal versuchen, mit Perl am ui-Port 7777 zu kitzeln. (Mit ncat krieg' ich nur eine Zeile, vermutlich wartet der simulavr auf eine Quittierung.) Gestern kam der AVRICE-Klon aus CN. Liegt schon nebem dem Pollin-Board mit dem Atmega32 drauf. Damit steht Inline-Debugging als nächsten auf der To-Do-Liste. Nur zu blöd. daß man mit Arbeiten immer so viel Zeit vertrödelt ;-\
Wolfgang R. schrieb: > - I2C > war eigentlich mein ursprünglicher Plan. > Hat wohl den geringsten Hardware-Aufwand. Das ist wahr, allerdings benötigt z.B. RS485 oder CAN auch nur ein Aderpärchen auf der Kabelseite. Nur die Module sind etwas aufwendiger. > Viele andere Sensoren, Port-Extender etc kann ich direkt an den Raspi > anschließen, wenn keine zeitkritische Vearbeitung erforderlich ist. > Kann ich damit mehrere Meter in rauher Umgebung (Schaltschränke, > Traktor, ..) überbrücken? Und das ist das Problem. I²C hat keinerlei Vorkehrungen, um Einstreuungen auf SDA und SCL zu erkennen und produziert dann Fehler und Timeouts. Man sollte also in so einer Umgebung nicht davon ausgehen, das I²C immer vorhersagbar läuft und die Fehlerbehandlung ernst nehmen. Ich tendiere zu Standard RC-Pulsen, die leicht zu erzeugen sind und sehr weit verbreitet. Das ist zwar nicht industriell ernst zu nehmen, aber zum Frickeln sicher am einfachsten.
Der VNH2SP30 hat einen CS-Pin zur Stromrückmeldung. Es ist naheliegend, den auszuwerten - zur Erkennung mechanischer Blockaden - zur Optimierung der Drehmomentregelung vgl. http://www.elm-chan.org/works/smc/report_e.html > Parameter #5: Back-EMF compensation gain > >Normally, the output torque generated by armature winding current is > sensed and fed back to make torque control loop. > However, SMC ommits the current sensor and controls the output torque > with sensorless current control method. > To supply commanded current to the motor, SMC applies compensation > to back-EMF (EG). > This is inaccuracy compared to conventional current feedbacked control. > But I chose it because it is easy to build the circuit board. Mal sehen wie sich das in den Code einfügt. Hat das schon mal jemand gemacht?
So langsam werd' ich wieder warm :-))) Bin zwar noch immer mitten im ASM tutorial bei den Timern, aber ich hab' jetzt die Assembler mit Gnu-toolchain und eigenen Makefile halbwegs im Griff. Ich kann GDB auf simulavr und simulavrxx und per China-Billig-Dongle über avarice mit meinem ATmega32 auf Pollin Board JTAG sprechen. Alle Anwandlungen graphischer Obscurity Layers (Eclipse, ddd, AVRStudio unter Wine ...) liegen in der Tonne. Ein Testzyklus von vi bis make-gesteuertem Flash liegt im niedrigen 2-stelligen Sekundenbereich, wenn der China-Dongle nicht mal wieder muckt. Jetzt steh' ich vor der Frage, mit welchem Chip ich weiter mach. Ich hätte gerne eine halbwegs universelle eierlegende Wollmilchsau, die ich für verschieden Anwendungen anpassen kann. - bis zu 4 Servos mit 4 VNH2SP30-Brücken ansteuern - alle Pins der Brücken am Controller - jeweils ADC für Positionspoti und Stromrückmeldung - variable PWM zum rampenmäßigen Einbremsen aufs Ziel - Host-Controlle über serial, I2C oder CAN (am besten wahlweise) - debug über serial, LCD, CAN Software-PWM halte ich für eine Krücke. Sicher gibt es fertige libs und Vorlagen zum Abkupfern. Aber wenn ich das mit CAN, serial, I2C integrieren möchte, beißt sich das schnell, fürchte ich. Hardware-PWM braucht offensichtlich für jeden Kanal einen OnCompare -Ausgang, richtig? Vor mir liegen die Pin-Belegung von ATmega32 und AT90CAN32 . 8x ADC haben beide. Sehe ich das richtig, daß der "große" Bastel-Mega (aka 40-pin DIL) nur 3 OC-Ausgänge hat? Im DB stehen zwar 4 PWM Channel, aber selbst die sind über alle 3 Timer verstreut. Ich hätte aber mindestens gerne noch einen unabhängigen Timer, um meine Hintergrundaufgaben zu steuern (Servo-Berechnung, Rampen, Kommunikation, ...) Ist damit der Atmega32 zu klein? Beim AT90CAN finde ich 9 OCxy pins mit x=1..3 und y=A..C Das sollte wohl reichen. Aber schön wäre so etwas im DIL... zumindest bis ich das CAN mit einbau. RTFM ist angesagt
@ Wolfgang Rosner (wjr) >jetzt die Assembler mit Gnu-toolchain und eigenen Makefile halbwegs im >Griff. Ich kann GDB auf simulavr und simulavrxx und per >China-Billig-Dongle über avarice mit meinem ATmega32 auf Pollin Board >JTAG sprechen. Alle Anwandlungen graphischer Obscurity Layers (Eclipse, >ddd, AVRStudio unter Wine ...) liegen in der Tonne. Ein Testzyklus von >vi bis make-gesteuertem Flash Und noch ein autistischer Frickler mehr, der meint schlauer als der Rest der Welt zu sein . . . >- bis zu 4 Servos mit 4 VNH2SP30-Brücken ansteuern Dann brauchst du einen AVR mit 4x2 PWM Ausgängen. Da gibt es nur wenige. >Software-PWM halte ich für eine Krücke. Ist es bei den Frequenzen auch. >Hardware-PWM braucht offensichtlich für jeden Kanal einen OnCompare >-Ausgang, richtig? Ja. >Sehe ich das richtig, daß der "große" Bastel-Mega (aka 40-pin DIL) nur 3 >OC-Ausgänge hat? Welcher denn? Es gibt Dutzende im DIL40 Gehäuse! > Im DB stehen zwar 4 PWM Channel, aber selbst die sind >über alle 3 Timer verstreut. Das ist normal, es gibt. max. 2 PWMs/Timer. >Ich hätte aber mindestens gerne noch einen >unabhängigen Timer, um meine Hintergrundaufgaben zu steuern >(Servo-Berechnung, Rampen, Kommunikation, ...) Nimm einen ATmega1280, 2560 oder 640, die haben 4 16 Bit Timer und 2 8 Bit Timer, das sollte reichen. >Ist damit der Atmega32 zu klein? Ja. >Beim AT90CAN finde ich 9 OCxy pins mit x=1..3 und y=A..C >Das sollte wohl reichen. Jain. >zumindest bis ich das CAN mit einbau. Wird eng, denn der Größte im DIL40 ist der ATmega1284P, der hat aber nur 6 PWMs. >RTFM ist angesagt Und nimm C, das Assemblergefrickel bringt dir keinen nennenswerten Vorteil. Die schnell Sachen macht so oder so die Hardware (PWM-Generierung).
Pelz waschen heißt naß machen. Und eierlegende Wollmilchsäue haben wohl Tausedfüßler-Gene eingekreuzt. Aber wenn ich eh' CAN auf dem Radar habe dann muß ich mich wohl mal an das Bändigen der 64-beinigen Monster machen. es gibt in der Bucht http://www.ebay.de/itm/172441289963 schöne Adapterboards mit einem Atmega128, der pinkompatibel zum AT90CAN ist. Wäre natürlich toll, die Platine ohne Atmega128 zu kriegen. Der ist schade zum wegschmeißen und macht Arbeit zum auslöten. Aber ich fürchte, das übersteigt die Flexibilität von Onkel Won. Es gibt eine Nummer auf der Platine K10021J8S 2578-ATM Aber google findet da nichts dazu. Außer Geldautomaten ... ;-)
Falk B. schrieb: > @ Wolfgang Rosner (wjr) > >>jetzt die Assembler mit Gnu-toolchain und eigenen Makefile halbwegs im >>Griff. Ich kann GDB auf simulavr und simulavrxx und per >>China-Billig-Dongle über avarice mit meinem ATmega32 auf Pollin Board >>JTAG sprechen. Alle Anwandlungen graphischer Obscurity Layers (Eclipse, >>ddd, AVRStudio unter Wine ...) liegen in der Tonne. Ein Testzyklus von >>vi bis make-gesteuertem Flash > > Und noch ein autistischer Frickler mehr, der meint schlauer als der Rest > der Welt zu sein . . . Danke ;-\ Gut daß ich so einen breiten Buckel hab :-))) Und ich sicher, ich bin da nicht allein hier :-) > > Und nimm C, das Assemblergefrickel bringt dir keinen nennenswerten > Vorteil. Die schnell Sachen macht so oder so die Hardware > (PWM-Generierung). Jein. Wenn ich Register ansteuere, hab' ich mit Assembler direkten Kontakt zur Hardware. Komplizierte Dinge (CAN, Debug, ....) will ich mir gerne zusammen klauonen. Das ist meist C. Die Vorlage für den Servocontroller von ELM-Chan ist Assembler. Deswegen die Entschdeidung für gcc. Da kann ich (hoffentlich) leichter mischen.
@Wolfgang Rosner (wjr) >Wenn ich Register ansteuere, hab' ich mit Assembler direkten Kontakt zur >Hardware. Das hast du mit C ebenso. >Komplizierte Dinge (CAN, Debug, ....) will ich mir gerne zusammen >klauonen. Das ist meist C. Siehst du. >Die Vorlage für den Servocontroller von ELM-Chan ist Assembler. Und uralt. Die Welt hat sich weiter gedreht. >Deswegen die Entschdeidung für gcc. Da kann ich (hoffentlich) leichter >mischen. Mach mal.
Falk B. schrieb: >>Die Vorlage für den Servocontroller von ELM-Chan ist Assembler. > > Und uralt. Die Welt hat sich weiter gedreht. Weißt Du was besseres? Leider habe ich bei Google die Funktion "Du weißt schon was ich will" noch nicht gefunden.
Falk B. schrieb: > @ Wolfgang Rosner (wjr) >>Beim AT90CAN finde ich 9 OCxy pins mit x=1..3 und y=A..C >>Das sollte wohl reichen. > > Jain. > >>zumindest bis ich das CAN mit einbau. > > Wird eng, denn der Größte im DIL40 ist der ATmega1284P, der hat aber nur > 6 PWMs. > >>RTFM ist angesagt OK, jetzt bin ich mal quer durch die Datenblätter und die Vergleichstabelle https://www.mikrocontroller.net/articles/AVR_Typen#Vergleichstabelle.28n.29_.2F_Ausstattung geflogen. Ergebnis auf die Schnelle: Ich denke der AT90CAN.. hat die gleichen Timer wie Atmega64 und Atmega128 - 8-bit-Timer 0 und 2 ähnlich wie die Atmega 8 etc mit je 1 OC - 2 16-bit-timer 1 und 3 mit je 3 OC Also würde ich meine 4 PWm auf die 16-bit-Timer aufteilen und hätte dann die Timer 0 und 2 zur Softwaresteuerung übrig. Die Registeradressen sind zwar unterschiedlich, aber dafür hat man ja Compiler. Und mit Atmega128 auf den China-Boards kann ich das testen, ohne daß ich CAN-Chips löten muß. Es gäbe noch Atmega64P und Atmega128P, die wären sogar noch im PDIP 40 erhältlich. Die haben aber nur 3 Timer, ähnlich wie der Atmega8 oder 32, nur mit jeweils 2 OC. Kann sein, daß ich damit klar käme, aber die sind dann nicht kompatibel zum AT90CAN.., also müßte ich zwei Softwareversionen halten. Nicht gut.
Wolfgang R. schrieb: > dann muß ich mich wohl mal an > das Bändigen der 64-beinigen Monster machen. So, der Anfang wäre geschafft. Das Timer-Beispiel aus dem Assembler-Tutorial https://www.mikrocontroller.net/articles/AVR-Tutorial:_Timer#Simulation_im_AVR-Studio läuft auf dem AT90CAN32. Welcher Idiot hat eigentlich bei Atmel die ISP-Anschlüsse auf ander Pins als SPI gelegt und nix davon ins Pinout geschrieben #%&§$%!§$%&§$%#$§% ? Kein Mensch liest bis 349, wo die Tabelle 25-13 mit der korrekten Pin-Belegung für ISP steht (heißt natürlich auch nicht ISP, sonst könnte man's ja mit einer Suche im pdf finden). 2 Abende lang habe ich mir sämtliche Sünden vorgeworfen, von kalten Löststellen über verbrannte Chips, von vertauschter Spannungsversorgung bis verfuste Chips aus der Bucht. Doch avrdude behauptet stur "target doesn't answer". Gut, den Ärger mit den chinesischen usbasp-Klonen muß mich meiner eigenen Geil-Geiz-Spielsucht zuschreiben. Die offenen Platinen für 1,50 gehen gut, aber die im Alu-Gehäuse für 2,- muß man erst mal flashen, und trotzdem kommen sie dann nicht mit jungfäulichen Atmegas auf internem RC-Takt klar. Sobald ich den Takt auf extern umgestellt habe, geht es auch mit den alubehausten Dongles. Getestet mit AT90CAN32, Atmega8-8L und Atmega8-16PU
Bei jtag hab' ich wohl weniger Glück mit meinen Chinesen-Dongles :-(
1 | ~/test/AVR/hello/timer$ avarice --jtag /dev/ttyUSB0 -Pat90can32 |
2 | AVaRICE version 2.11, Dec 22 2013 18:22:47 |
3 | |
4 | Defaulting JTAG bitrate to 250 kHz. |
5 | |
6 | JTAG config starting. |
7 | Hardware Version: 0xc0 |
8 | Software Version: 0x80 |
9 | Reported JTAG device ID: 0x9581 |
10 | Device is not supported by JTAG ICE mkI |
Die "Reported JTAG device ID: 0x9581" stimmt mit der Angabe im Datenblatt überein. Ich darf also annehmen, daß die Kommunikation zwischen Programmer und MCU funktioniert.
1 | ~/test/AVR/hello/timer$ man avarice |
2 | .... |
3 | avarice currently has support for the following devices: |
4 | at90can128 |
5 | at90can32 (o) |
6 | at90can64 (o) |
7 | .... |
8 | * - Only supported by the JTAG ICE mkII device. |
9 | o - Only supported by the JTAG ICE mkII and AVR Dragon device. |
Hm. Also braucht es Drachen, um tausendfüßige eierlegende Wollmilchschweine zu bezwingen? Das Teil liegt ja schon seit 2 Wochen in meinem RS-Warenkorb. Muß dann wohl doch auf "Bestellen" drücken. Bei 51,- zzgl hat sich wohl die Frage nach mkII-Klonen für 60 € aufwärts erübrigt. Ich hättb' noch ein mySmartUSB V2.11 hier. Sieht genauso aus wie das neuere "mySmartUSB MK2 " http://shop.myavr.de/index.php?404;http://www.myavr.de:80/shop/artikel.php?artID=42 Aber ich finde da in der Beschreibung nichts von JTAG, und auch keinen Sockel dazu. Die haben sich beim Klonen wohl auf den Namen beschrönkt? Ich könnt' mir natürlich auch 'nen at90can128 nur zum Debuggen besorgen. Aber da wollen'se auch schon 20,- + MwSt.
AT90 ATMEGA8 ich musste erstmal aufs Datum vom Thread sehen, ob der nicht wieder aus 2005 ist, bevor ich schreibe. Nundenn: gibt es da nichts aktuelleres aus der Schiene? Das liest sich wirklich, wie aus dem vergangenen Jahrhundert. StromTuner
Axel R. schrieb: > AT90 > ATMEGA8 ... > > gibt es da nichts aktuelleres aus der Schiene? Das liest sich wirklich, > wie aus dem vergangenen Jahrhundert. Was würdest Du denn vorschlagen? > ATMEGA8 lagen verstaubt in der Kiste, aber zum Testen der isp-Konnektivity taugten sie allemal > AT90 AT90*CAN* Es gibt wohl Gerüchte über "neuere" Atmega mit CAN drauf, aber ich fand kein erreichbares Angebot mit MOQ < 100. Ja, und es liegen noch MCP2151-Module in der Kiste und irgendwo Platinen von Fabian Greif. Aber ist nicht on-chip die eleganteste Lösung? Ich könnte vielleicht nach PIC oder so wechseln, aber ich bin schon froh, wenn ich jetzt die AVR-Toolchain halbwegs in' Griff kriege. > liest sich wirklich wie aus dem vergangenen Jahrhundert. Was ist das Problem daran? Funktioniert das heute etwa nicht mehr? Die Aufgaben haben sich seit dem letzten Jahrhundert nicht wirklich geändert. Ich kam über PC -> Raspberry -> ESP8266-NoceMCU -> AVR Downsizing, quasi. Weg mit overengineerten obscurity-Layern. Jedem Job seinen Chip.
Auch wenn der alte AT90CAN auf dem Steckbrett läuft - für ernsthafte Anwendung brauch ich eine andere mechanische Lösung. Spätestens auf dem Traktor fliegen mit die DuPont-Wire-Zöpfe sonst um die Ohren.... Nur gut daß es Chinesen gibt, die Chips und Boards aus dem letzten Jahrhundert zum Schleuderpreis verticken :-) Und der atmega128 pinkomptaibel ist. Da finde ich nette TQFP64 breakouts : http://www.dhgate.com/product/5x-atmel-atmega128-avr-development-board/387214271.html#sd1-2-1b;rvw|1187532688 $2,50 das Board, Es ist wohl sogar ein USB-serial-Adapter vorgesehen. Es steht sogar "AVR" und "Atmel" drauf (was bei China-Produkten gar nichts heißt, ich weiß) und "2012 Ver1.3", aber mit Google komm' ich nicht auf einen Schaltplan. Wie es aussieht, ist das Board 2-lagig. Reverse Engineering sollte also nicht so schwierig sein. Dieses Teil https://www.aliexpress.com/item/AVR-development-board-minimum-system-PCB-blank-board-ATMEGA128-PCB-empty-board/32755201535.html ist etwas kleiner, kostet aber auch nur 1,11/Stück. Platz für Essentials - Stromversorgung, Reset, ISP, JTAG, Quarz und Induktivität für AVCC ist drauf. Benennung scheint chinesisch zu sein, aber die Bauteilbezeichnung sieht auf den Fotos lesbar aus.
Wolfgang R. schrieb: > ~/test/AVR/hello/timer$ man avarice > .... > avarice currently has support for the following devices: > at90can128 > at90can32 (o) > at90can64 (o) > .... > * - Only supported by the JTAG ICE mkII device. > o - Only supported by the JTAG ICE mkII and AVR Dragon device. > > Hm. > Also braucht es Drachen, um tausendfüßige eierlegende Wollmilchschweine > zu bezwingen? Hm. Jetzt hab' ich zwar einen dragon, aber ich kann noch immer nicht auf meinem AT90CAN32 debuggen. Ich kann flashen - sowohl mit avrdude als auch mit avarice (sowohl 2.11 aus debian jessie als auch 2.13 aus neuesten sourcen) Wenn ich mit dem Debugger aufs device gehe, dauert es schon sehr lang bis ich was sehe. Die LEDs am Dragon blinken. Wenn ich versuche, Code auszuführen, sehe ich nur eine Endlosschleife:
1 | (gdb) ni |
2 | 0x00000000 in __vectors () |
3 | 3: x/i $pc |
4 | => 0x0 <__vectors>: rjmp .-2 ; 0x0 <__vectors> |
5 | 2: /t $SREG = 0 |
6 | 1: /x *$PORTD = 0x4 |
7 | (gdb) ni |
8 | 0x00000000 in __vectors () |
9 | 3: x/i $pc |
10 | .... |
Jeder Versuch, was anderes als Einzelschritt auzuführen, führt zu nicht unterbrechbaren Hängern. Die LEDs am Dragon blinken mit gefühlten 2 Hz (ich vermute, das sind Einzelschritte). Der debugger reagiert nicht mehr auf ctrl-C. Kommt mir vor als wären massig Befehle irgendwo in einem Fifo angestaut. Ich kann nur noch avarice mit ctrl-C abbrechen, dann stirbt auch der debugger mit. Wenn ich danach das Target normal betreiben möchte, muß ich die OCDEN fuse manuell löschen. OK, das kommt wohl vom gewaltsamen Abschuß des avarice. Vergleich ich das mit meinem elf-File, dann steht da was anderes:
1 | :~/test/AVR/hello/timer$ avr-objdump -d timer.elf |
2 | |
3 | timer.elf: file format elf32-avr |
4 | |
5 | |
6 | Disassembly of section .text: |
7 | |
8 | 00000000 <__vectors>: |
9 | 0: 0c 94 4a 00 jmp 0x94 ; 0x94 <__ctors_end> |
10 | 4: 0c 94 54 00 jmp 0xa8 ; 0xa8 <__bad_interrupt> |
11 | 8: 0c 94 54 00 jmp 0xa8 ; 0xa8 <__bad_interrupt> |
12 | c: 0c 94 54 00 jmp 0xa8 ; 0xa8 <__bad_interrupt> |
Ich hab's dann mit meinem ersten Target probiert: atmega32 auf Pollin-Board Da erhalte ich zwar auch "0x00000000 in __vectors ()" beim Start-up von gdb, und das langsame Blinken. Sobald ich aber den ersten Einzelschritt "ni" eingebe, erscheinen Source und Assembler wie konfiguriert und ich kann regulär (wenn auch langsam) debuggen. Da frickel' ich doch lieber autistisch mit 10-fachem Speed und chinesen-Schrott weiter {\Sarkasmus off} Google führt mich auf http://www.avrfreaks.net/comment/241039#comment-241039 "I think there's no debugging option except for the JTAGICE mkII for those units..." Bin ich also in eine AVR-Marketing-Falle getappt? Oder ist das ein Anfängerfehler? Oder ein echtes Problem, das einen eigenen Thread braucht? Oder versuch' ich's lieber gleich auf der avarice-mailing-Liste?
:
Bearbeitet durch User
Wolfgang R. schrieb: > Oder ist das ein Anfängerfehler? womöglich. "load timer.elf" in GDB produziert das Problem. "file timer.elf" reicht aus - dann geht es. dragon mit avarisp und AT90CAN32: SOLVED > Bin ich also in eine AVR-Marketing-Falle getappt? nicht mehr. iwo steht, daß ab AVRstudio 4.16 oder so diverse Beschränkungen (die es früher also gab) aufgegeben wurden. Ich hab' auf mein Laptop 4.19 installiert und den dragon upgraded, aber das änderte nichts. Außer meine Windows-Abneigung bestätigt. > Oder ein echtes Problem, das einen eigenen Thread braucht? jetzt nicht mehr > Oder versuch' ich's lieber gleich auf der avarice-mailing-Liste? Ich habs da mal gepostet - schau'mer mal was rein tröpfelt... Auch wenn es jetzt funzt - verstehen tu' ich's nicht.
Back to track: Servosteuerung mit Host-Anbindung Wolfgang R. schrieb: > Falk B. schrieb: >>>Die Vorlage für den Servocontroller von ELM-Chan ist Assembler. >> >> Und uralt. Die Welt hat sich weiter gedreht. > > Weißt Du was besseres? > > Leider habe ich bei Google die Funktion "Du weißt schon was ich will" > noch nicht gefunden. Also weiter durch tutorials, Datenblätter und Testaufbauten. Message passing Framework https://www.mikrocontroller.net/articles/Multitasking#Message_passing_Framework HEUREKA ?? > Grundprinzip aber für viele Mikrocontroller-Projekte immer wieder > verwenden kann, lohnt es sich und man kann die > Entwicklung für diese Art des Multitasking > in einem Framework zusammenfassen. Das klingt doch schon nach einem geeigenten Rückgrat für eine eierlegende Wollmilchsau :-)
Wolfgang R. schrieb: > Message passing Framework > ... klingt nach einem ... > geeigenten Rückgrat für eine eierlegende Wollmilchsau :-) ... oder Protothreads ?? Beitrag "Wer benutzt Protothreads?"
Wolfgang R. schrieb: > Wolfgang R. schrieb: >> Message passing Framework >> ... klingt nach einem ... >> geeigenten Rückgrat für eine eierlegende Wollmilchsau :-) ... täuscht .... Die Grundidee ist ja ok, aber das verlinkte Programm wurde von einem "Astade CGenerator" produziert. Neuer Obscurity Layer. Tu' ich mir erst mal nicht an.
... oder FreeRTOS?... ich hab' grad die Fleury-LCD-Library am zerpflücken. Wenn ich die auf Protothreads portieren will, bleibt die Hälfte auf der Strecke. Das war nicht, was ich mir von PT erhofft hatte. Aber irgendwie muß ich ja die blockierende Ausgabe von nicht blockierenden Aufrufen entkoppeln. Entweder ich nehm' einen fifo, der muß aber dann auf 9 bit aufgebohrt werden, damit auch Commands übertragen werden können. Oder ich mach' mir einen "Bildschirmpuffer" im RAM, in den ich von der App aus (also quasi jederzeit und von überall und nicht blockierend) direkt rein schreiben kann. Die Schleife kann dann diesen Puffer ans Display senden, wenn's geht. Oder auch nicht. Selbst wenn die LCD in niedriger Prio mal keine Zeit abbekommt, tut das dem Rest der app nicht weh. Im Gegensatz zu einem fifo, der vollaufen kann. Aber vermutlich hab' ich das selbe Problem auch in einem RTOS (außer daß es da für LCD schon libs gibt, aber das verschiebt halt den Lernschritt eine Aufgabe weiter)
Arduino? Könnte es sein, daß ich aus falschem Stolz ("Kinder-Kikikram-Anfängerplatform") die naheliegendste Lösung übersehen habe? Selbstüberschätzung .... vielleicht nicht bezüglich potentiellem Können, aber sicher bezüglich verfügbarer Zeit? Die Beschreibung der Libraries und erste Hallo-Welt-Tests machen einen vielversprechenden Eindruck.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.