500W-Bürstenmotoren: Entwicklung einer H-Brücke 30V / 75A.

    • Offizieller Beitrag
    Zitat

    Ahhh, ein Thema habe ich jetzt doch noch: ich plane anstatt des (Halbbrückentreibers) IR2184 ggf. den Vollbrückentreiber HIP4081A einzusetzen. Dieser hat höhere Treiberströme (2,5A statt 1,5A des IR2184) und eine interne Überwachung des Bootstrap-Kondensators.


    Der HIP4081 ist auch mein Lieblingsgerät für kleine Spannungen. ABER, die Busvoltage darf bei dem maximal 80V betragen. Ich bin mir nicht sicher ob das nicht zu knapp ist. Ausserdem sind die HIPs etwas zickiger und weniger robust.

    Meine Empfehlung aus Erfahrung:
    bis 24V, kleiner Motor => HIP4081 (max. 80V)
    ab 24V, dickerer Motor => IR2110 (max. 600V)

    Einen HIP hab ich schon kaputt bekommen, einen IR2110 nicht. Vom IR2110 benötigt man halt immer 2 weil es nur ein Halbbrückentreiber ist. Dafür sind die aber auch günstiger und besser erhältlich als die HIPs...

  • Zitat

    Original von Gizmo
    Meine Empfehlung aus Erfahrung:
    bis 24V, kleiner Motor => HIP4081 (max. 80V)
    ab 24V, dickerer Motor => IR2110 (max. 600V)

    Einen HIP hab ich schon kaputt bekommen, einen IR2110 nicht. Vom IR2110 benötigt man halt immer 2 weil es nur ein Halbbrückentreiber ist. Dafür sind die aber auch günstiger und besser erhältlich als die HIPs...

    Danke für den Tipp.
    Ich möchte nicht mehr als 60V im System, meine FETs können nur 75V ab, da ist ohnehin kaum Spielraum.

    Ist setze bislang IR2184 ein und habe damit etwas Erfahrung. Habe mir das mal kurz angesehen: der IR2110 kann ggü. dem IR2184 bis zu 40% mehr Strom (= Vorteil), jedoch gefällt mir die Ansteuerung mit HIN u. LIN überhaupt nicht. Wie stellst Du z.B. die Deadtime zw. HO/LO ein? Per SW? Dann würde doch der Vorteil der Onchip-PWM entfallen, wo der aktuelle PWM-Wert einfach in das entsprechende Reg. geschrieben wird.
    Der IR2184 hat das mit der DT intern gelöst (feste Vorgabe von 0,5µs) u. beim IR21844 ist die DT mittels ext. R sogar einstellbar.

    • Offizieller Beitrag
    Zitat

    Ich möchte nicht mehr als 60V im System, meine FETs können nur 75V ab, da ist ohnehin kaum Spielraum.


    Nun, wir haben uns damals an etwas versucht das einen Bosch GPA750 bei 24V vernünftig antreiben sollte. Das hat etwas lang gedauert, aber zum Schluss ging das einigermaßen vernünftig. Da waren 2x IR2110 und 4x 4 IRF3205 drin und das konnten wir gut verantworten. Beim 36V Test (doppelte Leistung) gabs aber schon seltsame Effekte. Wie sich später herausgestellt hat waren die Oszi Bilder reichlich mit Merkwürdigkeiten verseucht. Wir haben dann die dicken Transildioden parallel zu jedem Zweig eingebaut und damit wurds dann auch deutlich besser. Allerdings wurden die Transildioden mächtig heiß und das hätte ich so nicht mehr für den stabilen produktiven Einsatz vorgesehen weils einfach unsauber ist. In deinem Fall sehe ich 75V als unterste Grenze, besser 100V FETs und nen unempfindlichen Treiber wenn du keinen Ärger haben willst.. :]

    Zitat

    Ist setze bislang IR2184 ein und habe damit etwas Erfahrung. Habe mir das mal kurz angesehen: der IR2110 kann ggü. dem IR2184 bis zu 40% mehr Strom (= Vorteil), jedoch gefällt mir die Ansteuerung mit HIN u. LIN überhaupt nicht. Wie stellst Du z.B. die Deadtime zw. HO/LO ein? Per SW? Dann würde doch der Vorteil der Onchip-PWM entfallen, wo der aktuelle PWM-Wert einfach in das entsprechende Reg. geschrieben wird.


    Deswegen sagte ich u.a. mit Pfiff... :]

    Zitat

    Auch ich tendiere zur Strommessung mittels Shunt im Massezweig der FETs, dies ist potentialmässig in Verb. mit nachgeschaltetem Op-Amp die m.E. übliche (und einfachere) Variante.


    Das ja, ist die Standardlösung. Eine bessere Lösung wäre mit Stromfühler berührungslos und potentialfrei wie eine Stromzange. Ich geb mal noch ne andere Idee in den Raum die wir versucht hatten. Wird sind zwar daran gescheitert, aber vielleicht gelingt es dir:
    Anstatt den dicken Shunt mit seiner Verlustwärme der eh nur den Gesamtstrom erfassen kann, mess doch einfach den Spannungsabfall über den LowSide FETs. Die hast du eh drin und dein Strom läuft zwangsläufig über mindestens einen der beiden. Du bräuchtest allerdings auch einen Temperaturfühler mit dem du eine LookUpTable fütterst die dir dann aus dem Datenblatt des FETs den jeweils gültigen RDSon für die aktuelle Temperatur abschätzt. Nur so bekommst du einigermaßen akkurate Stromwerte. Die Schwierigkeit ist je nach Ansteuerungsmethode die Messsensorik anzusteuern und/oder Messwerte zu ignorieren die auf jeden Fall falsch sind. Wenn du das geschickt über beide FETs unten machst, dann kannst du auch den Bremsstrom erfassen. Und damit komme ich wieder auf die Software mit Pfiff zurück... :]

    Zitat

    Die Bremsenergie an den FETs zu verheizen ist die primitive Variante denn pfiffiger wäre es, die Bremsenergie in die Batterie zu rekupieren. Dies setzt widerum eine dahingehend optimierte H-Brücke voraus, usw., usf...


    Rekuperation ist aber extrem komplex. Du darfst je nach Akkutyp in den Akku keinesfalls mit zu hoher Spannung zurückspeisen. Andere wiederum nehmen dir kurze Pulse krumm usw. Ob sich der Aufwand lohnt für die 10% Energiezurückgewinnung? Wenn ja, dann ist das wie du schon sagtest der größte Pfiff an der Software... :]

  • Zitat

    Original von Gizmo
    Nun, wir haben uns damals an etwas versucht das einen Bosch GPA750 bei 24V vernünftig antreiben sollte. Das hat etwas lang gedauert, aber zum Schluss ging das einigermaßen vernünftig. Da waren 2x IR2110 und 4x 4 IRF3205 drin und das konnten wir gut verantworten. Beim 36V Test (doppelte Leistung) gabs aber schon seltsame Effekte. Wie sich später herausgestellt hat waren die Oszi Bilder reichlich mit Merkwürdigkeiten verseucht. Wir haben dann die dicken Transildioden parallel zu jedem Zweig eingebaut und damit wurds dann auch deutlich besser. Allerdings wurden die Transildioden mächtig heiß und das hätte ich so nicht mehr für den stabilen produktiven Einsatz vorgesehen weils einfach unsauber ist. In deinem Fall sehe ich 75V als unterste Grenze, besser 100V FETs und nen unempfindlichen Treiber wenn du keinen Ärger haben willst..

    Ist schwierig für mich das jetzt zu bewerten, da ich eure Schaltung und die SW im Detail nicht kenne. Motoren mit ihren Induktivitäten sind eine Sache für sich mit vielen wunderschönen "Effekten"... Ich habe daher vor, mir einen kleinen Prüfstand mit 2 Motoren aufzubauen (= doppelte Induktivität), um möglichst früh auf derartige Fehlerwirkung mit dem Schaltungsdesign (und SW) reagieren zu können. Der unbelatete Motor ist meist unproblematisch, da benötigen die FETs nichtmal einen KK.

    Zitat

    Ist setze bislang IR2184 ein und habe damit etwas Erfahrung. Habe mir das mal kurz angesehen: der IR2110 kann ggü. dem IR2184 bis zu 40% mehr Strom (= Vorteil), jedoch gefällt mir die Ansteuerung mit HIN u. LIN überhaupt nicht. Wie stellst Du z.B. die Deadtime zw. HO/LO ein? Per SW? Dann würde doch der Vorteil der Onchip-PWM entfallen, wo der aktuelle PWM-Wert einfach in das entsprechende Reg. geschrieben wird.

    Zitat

    Deswegen sagte ich u.a. mit Pfiff...

    Ist schon klar was Du meinst. Bei den IR-Halbbrückentreibern gibt es viele Arten der Beschaltung, entsprechend dem jeweiligen Einsatzzweck. Ich finde die Beschaltung mit HIN/LIN halt aufwändiger da ich mal in einer AN von IR gelesen habe, dass der Anwender für die zeitliche Verschiebung dieser beiden Eingangssignal zu sorgen hat (zusätzlich zu den 400ns Propagation-Delay), damit sich die Ströme der schaltenden FETs innerhalb des Halbbrückenstranges nicht überschneiden. Das heißt für mich, dass ein einfaches Invertieren des PWM-Signals zw. diesen Eingängen nicht zu empfehlen ist. Ich sagte ja nicht, dass es von der SW aus nicht geht. Gehen wird das wohl, aber m.E. ist der Aufwand höher und damit auch die Möglichkeit, sich hier in diesem sensiblen Bereich hübsche Fehler einzubauen...

    Zitat

    Das ja, ist die Standardlösung. Eine bessere Lösung wäre mit Stromfühler berührungslos und potentialfrei wie eine Stromzange. Ich geb mal noch ne andere Idee in den Raum die wir versucht hatten. Wird sind zwar daran gescheitert, aber vielleicht gelingt es dir: Anstatt den dicken Shunt mit seiner Verlustwärme der eh nur den Gesamtstrom erfassen kann, mess doch einfach den Spannungsabfall über den LowSide FETs. Die hast du eh drin und dein Strom läuft zwangsläufig über mindestens einen der beiden. Du bräuchtest allerdings auch einen Temperaturfühler mit dem du eine LookUpTable fütterst die dir dann aus dem Datenblatt des FETs den jeweils gültigen RDSon für die aktuelle Temperatur abschätzt. Nur so bekommst du einigermaßen akkurate Stromwerte. Die Schwierigkeit ist je nach Ansteuerungsmethode die Messsensorik anzusteuern und/oder Messwerte zu ignorieren die auf jeden Fall falsch sind. Wenn du das geschickt über beide FETs unten machst, dann kannst du auch den Bremsstrom erfassen. Und damit komme ich wieder auf die Software mit Pfiff zurück...

    Also jeder nach seinem Geschmack... Ich hatte das was Du vorschlägst am L-FET mal versucht, aber das Potenzial schwebt wie irre. Um hier einen belastbaren Messwert hinzubekommen muß die Messung mit dem aktiven LETZTEN Drittel der PWM synchronisiert und der Rest ausgetastet werden.
    No Sir, der Aufwand ist m.E. nicht gerechtfertigt.

    Hier macht sich ein weiterer Unterschied in der Herangehensweise versch. Entwickler aus, gerade weil Du gern auf die "SW mit Pfiff" abstellst: ich habe nichts gg. eine korrekte u. möglichst fehlerfreie SW, dennoch darf m.E. die wirksame Strombegrenzung nicht ALLEIN der SW überlassen werden! Vielmehr muß ext. HW, welche der Stromsensorik nachgeordnet ist, die FET-Treiber unverzüglich abschalten. Dafür würde ich 5µs zugestehen. Gern darf noch ein IRQ ausgelöst werden, z.B. um mittels pfiffiger SW dann die PWM erneut zu synchronisieren...
    Ist aber alles eine Frage der Philosophie, wobei ich klar sage, dass Unterspannung bzw. Überstrom direkt den/die Treiber abschalten sollte, unabhängig davon, womit die SW gerade beschäftigt ist; womit auch ersichtlich wird, wie groß der Aufwand bei der L-FET-Strommessung wird.

    Zitat

    Rekuperation ist aber extrem komplex. Du darfst je nach Akkutyp in den Akku keinesfalls mit zu hoher Spannung zurückspeisen. Andere wiederum nehmen dir kurze Pulse krumm usw. Ob sich der Aufwand lohnt für die 10% Energiezurückgewinnung? Wenn ja, dann ist das wie du schon sagtest der größte Pfiff an der Software... :]

    Ich dachte jetzt etwas weiter, z.B. an einem E-Smart, um die persönliche CO2-Bilanz zu verbessern.
    Bei einem Bot macht es wohl tatsächlich keinen Sinn, würde ich auch nicht mit in meine H-Brücke einbauen wollen. Die Rekuperation muß der Geschw. bzw. dem max. zulässigen Ladestrom der Batterie angepaßt werden, ist tatsächlich sicher nicht einfach...

    • Offizieller Beitrag
    Zitat

    dass der Anwender für die zeitliche Verschiebung dieser beiden Eingangssignal zu sorgen hat (zusätzlich zu den 400ns Propagation-Delay), damit sich die Ströme der schaltenden FETs innerhalb des Halbbrückenstranges nicht überschneiden.


    Dies würde ich auch auf alle Fälle befürworten.
    Wie die ersten Tests gezeigt haben, sind Überlagerungen im Schaltverhalten (gerade beim Wechsel zwischen "Run", "Stop" und "Bremsen") etwas kritisch. Der erste Wurf der SW funktionierte im Entwicklungsmuster bestens. Beim "Nachbau" (gleiche Bauteiltypen, nur eben die "Bauteilstreuung" dabei) ging aber dann sporadisch der Prozessor durch den Reset. Ursache: Kurzzeitige Überlagerung vom durchgeschalteten Zustand des H- und L-FETs. => Kurzschluss => Betriebsspannung bricht zusammen. ... und solche Fehler suchst Du mal, wenn bei jedem Reset der Debugger abgehängt wird... :rolleyes:

    Zitat

    dennoch darf m.E. die wirksame Strombegrenzung nicht ALLEIN der SW überlassen werden! Vielmehr muß ext. HW, welche der Stromsensorik nachgeordnet ist, die FET-Treiber unverzüglich abschalten.


    So hatte ich das auch in der Fahrtregler-Serie "3" realisiert. Aber dann musst Du auch die Hardware von der Stromerfassung genau auf das gewünschte Verhalten per "Hardware" (=SMD-Vogelfutter) abstimmen. Das ist dann wesentlich aufwändiger, als in der Software einfach einen Parameter zu ändern, und schon ist der I-Anteil höhergesetzt...

  • Zitat

    Original von Gizmo
    Nun, wir haben uns damals an etwas versucht das einen Bosch GPA750 bei 24V vernünftig antreiben sollte. Das hat etwas lang gedauert, aber zum Schluss ging das einigermaßen vernünftig.


    Heißt das, ihr habt eine Vollbrücke aufgebaut? Wieviel Amp. habt ihr dafür als Dauer-I/Spitzen-I kalkuliert? Ich glaube der GPA750 hat um die 40A Nennstrom. Hattet ihr da eine funktionierende Strombegrenzung und falls ja, auf welchen Wert war diese ausgelegt?

    Ich weiß nicht wie "vernünftig antreiben" geht, kläre mich bitte mal auf. Ich halte es jedenfalls - so wie es gelegentlich zu lesen ist - nicht für sinnvoll Motor u. Steuerung mit > 200A zu quälen (GPA750). Der Wirkungsgrad ist dabei dann sowas von lausig, dass kann eigentlich nicht Sinn der Übung sein, oder?

    Was mich dann aber doch noch interessiert: wenn Du schreibst "aber zum Schluss ging das einigermaßen vernünftig" heißt das doch, ihr habt eine funktionstüchtige H-Brücke...??? :]
    Gibt es ein Layout? Wird diese irgendwo angeboten (Kauf, DIY-Nachbau, o.ä.)?

  • Zitat

    Original von bat_boy
    es gibt da ein schönes selbstbauprojekt "osmc"

    http://www.robotpower.com/osmc_info/

    damit wäre eine Antriebsauslegung sicher möglich. Die Relais-Lösung würde ich nicht empfehlen.

    Je nach dem, ob du dir einen Antrieb selber bauen willst, würde da ein Antrieb über Rollstuhlmotoren (mit schneckengetriebe) sicherlich gute Dienste leisten.

    So, nun habe ich mir auch dieses OSMC-Projekt zwischenzeitlich mal angesehen. Vorteil: leicht nachbaubar, da die schematics u. eagle-files öffentlich verfügbar sind. Der fertige Kauf ist aber wohl zu teuer und nachteilig ist, dass die Schaltung keine eigene Strombegrenzung hat. Ich bin auch erstaunt, dass bei einem Dauerstrom von 160A die FETs ganz ohne KK auskommen. Es ist wohl ein Fan oberhalb der FETs angeordnet, dennoch muß dieser an die 6...9W (bei angenommenen 4mOhm RSon) vom Case runterpusten... Hmmm., riskant und keine Kleinigkeit da der Fan auf Ausfall überwacht werden muß und sich der Dauerstrom ohne Fan bzw. bei Überschreiten von 100°C KK-Temperatur auf min. 50...60A reduzieren würde. Zudem können Motor-Anlaufströme die Steuerung sofort thermisch überlasten, da die Wärmesenke (Verzögerung) durch den KK fehlt. Wobei es dann widerum vorteilhaft ist, dass sich die freistehenden FETs relativ schnell nach einem Ausfall austauschen lassen...

    Dennoch finde ich dieses OSMC-Projekt lobenswert (zumal der von mir favorisierte HIP4081 eingesetzt wird).

    Ich möchte jedoch einen Schritt weiter gehen. Die OSMC-Technik ist nun auch schon in die Jahre gekommen und einiges würde ich heute anders machen. Als Entwickler liegt es mir auch etwas fern, fremde Schaltungen einfach 1:1 zu übernehmen. Meistens hat man doch eigene Erfahrungen u. Vorstellungen und findet auf Anhieb Dinge, die sich nach heutigen Maßstäben weiter verbessern lassen. Somit wird bei mir wohl doch alles auf eine eigenentwickelte Vollbrücke hinaus laufen.

    Zu den erwähnten Rollstuhlmotoren: diese hatte ich bereits 2006/2007 für ein von mir entwickeltes Segway-Clone-Projekt ausgewählt. Bedauerlicherweise stellte ich einen großen Schwachpunkt fest: im Segway-Clone sind die beiden Rollstuhlmotoren üblicherweise um 180° versetzt angeordnet. Einer läuft vorwärts während der andere rückwärts bestromt wird. Solange Strom fließt ist das auch alles kein Problem. Aber bei einer Motor-Notabschaltung oder in dem Fall, wo das Fahrzeug stromlos geschoben/gezogen werden soll (= Schubbetrieb) kann es passieren, dass eines der beiden Schneckengetriebe blockiert, was u.U. eine sofortige Beschädigung zur Folge hat, da es bei vielen Schneckengetrieben oftmals nur eine Vorzugrichtung gibt, in die sich der (stromlose) Antrieb ohne mech. Widerstand drehen läßt. Vermutlich trifft das nicht auf alle Rollstuhlantriebe zu aber zumindest auf die, welche ich mal getestet habe.
    Zwar tauchen entspr. Motoren immer wieder mal bei ebäh auf, jedoch muß man min. 2 baugleiche finden u. diese sind dann oftmals sehr schwer (8kg bei 500W ist durchaus möglich) oder sind stark untersetzt (nämlich auf die zulässigen 6 km/h).

    Nee, da finde ich es wesentlich interessanter mal bei Gelegenheit den GPA750 anzutesten...

    • Offizieller Beitrag
    Zitat

    Also jeder nach seinem Geschmack... Ich hatte das was Du vorschlägst am L-FET mal versucht, aber das Potenzial schwebt wie irre. Um hier einen belastbaren Messwert hinzubekommen muß die Messung mit dem aktiven LETZTEN Drittel der PWM synchronisiert und der Rest ausgetastet werden.
    No Sir, der Aufwand ist m.E. nicht gerechtfertigt.


    Du liegst richtig, bei beidem. Die Schaltung/Software wäre genial aber der Aufwand zu hoch.

    Zitat

    Hier macht sich ein weiterer Unterschied in der Herangehensweise versch. Entwickler aus, gerade weil Du gern auf die "SW mit Pfiff" abstellst: ich habe nichts gg. eine korrekte u. möglichst fehlerfreie SW, dennoch darf m.E. die wirksame Strombegrenzung nicht ALLEIN der SW überlassen werden! Vielmehr muß ext. HW, welche der Stromsensorik nachgeordnet ist, die FET-Treiber unverzüglich abschalten. Dafür würde ich 5µs zugestehen. Gern darf noch ein IRQ ausgelöst werden, z.B. um mittels pfiffiger SW dann die PWM erneut zu synchronisieren...
    Ist aber alles eine Frage der Philosophie, wobei ich klar sage, dass Unterspannung bzw. Überstrom direkt den/die Treiber abschalten sollte, unabhängig davon, womit die SW gerade beschäftigt ist; womit auch ersichtlich wird, wie groß der Aufwand bei der L-FET-Strommessung wird.


    Auch hier ein ACK und das sollte keine Kritik sein... :]
    Problem bei der harten Strombegrenzung: Das wird ruckeln. Bei Software geht das etwas eleganter und einfacher, z.B. jedesmal PWM halbieren wenn ein Impuls von der Strombegrenzung kommt. Da es schnell gehen muss am besten beim AVR interruptbasiert den eingebauten Komperator nutzen. Bei SW Lösung darf die CPU halt NIE aus dem Tritt kommen, sonst ist evtl. Rauchentwicklung die Folge.

    Zitat

    Heißt das, ihr habt eine Vollbrücke aufgebaut? Wieviel Amp. habt ihr dafür als Dauer-I/Spitzen-I kalkuliert? Ich glaube der GPA750 hat um die 40A Nennstrom. Hattet ihr da eine funktionierende Strombegrenzung und falls ja, auf welchen Wert war diese ausgelegt?


    Haben wir... 200A max bei 36V hätten es sein sollen bei aktiver Lüftung. Auf Dauer wollten wir glaube ich 100A bei 36V erreichen...
    Wir hatten eine einstellbare über die Shuntmethode am Massezweig mit sofortiger Abschaltung der Treiber. Das hat uns aber nicht gefallen...

    Zitat

    Ich weiß nicht wie "vernünftig antreiben" geht, kläre mich bitte mal auf. Ich halte es jedenfalls - so wie es gelegentlich zu lesen ist - nicht für sinnvoll Motor u. Steuerung mit > 200A zu quälen (GPA750). Der Wirkungsgrad ist dabei dann sowas von lausig, dass kann eigentlich nicht Sinn der Übung sein, oder?


    "Vernünftig antreiben" ist immer relativ. Bei dem Hobby hier ist die maximale Zeit 5min in der Arena, also kein "Dauerbetrieb". Deswegen machen fast alle in der 100kg Klasse ein Doping Ihrer Motoren indem sie die Spannung um 50% erhöhen und damit die Leistung verdoppeln. Das wollten wir auch machen und so wurde der Regler auch angegangen. Ob das vernünftig ist ist eine andere Frage, für das Hobby hier scheint es ideal wenn man den Wirkungsgrad nicht ernst nimmt. Fakt ist die meisten E-Maschinen sind kurzfristig überlastbar und davon macht man öfters mal Gebrauch... :]

    Zitat

    Was mich dann aber doch noch interessiert: wenn Du schreibst "aber zum Schluss ging das einigermaßen vernünftig" heißt das doch, ihr habt eine funktionstüchtige H-Brücke...???


    Das war zwischen 2002 und 2004, also schon recht lang her. Unser Laboraufbau ist ziemlich sicher auf der Schrotthalde, aber der letzte Prototyp dürfte noch mitsamt dem Layout und Schaltplänen existieren. Da müsste ich mal meinen Kollegen fragen. Das Ding war aber nicht fertig, denn wir hatten uns das ehrgeizige Ziel gesteckt die oben von mir skizzierte Variante der Strombegrenzung zur Reife zu entwickeln und sind daran gescheitert. Irgendwann haben wir dann resigniert und das Leben hat neue Prios gesetzt... :]

    Zitat

    So, nun habe ich mir auch dieses OSMC-Projekt zwischenzeitlich mal angesehen


    Der OSMC ist eigentlich brauchbar, trotzdem würde ich beim heutigen Wissen für eine Nennspannung von 36V keine 55V FETs und keinen HIP4081 mit max. 80V Busvoltage einsetzen, aber das hatten wir schon das Thema. Am meisten in der Richtung wurde mir durch UnskilledWorker hier aus dem Forum klar. Kurzum, den OSMC kann man machen, aber NIEMALS ohne KK und schon gar nicht ohne Strombegrenzung!

    Zitat

    Schneckengetriebe blockiert, was u.U. eine sofortige Beschädigung zur Folge hat


    Schneckengetriebe sind fast immer böse. Blockieren und schlechter Wirkungsgrad. Beim Botbau ist man IMHO etwas davon abgekommen...

    Zitat

    Es zeigt aber auch eines bei dem "Mythos Strombegrenzung": ohne geht nicht!


    Definitv! Und deswegen sind fast alle käuflich erwerbbaren Modellbauregler scheiße, weil die sowas gar nicht erst haben...

  • Zitat

    Original von Gizmo
    Problem bei der harten Strombegrenzung: Das wird ruckeln. Bei Software geht das etwas eleganter und einfacher, z.B. jedesmal PWM halbieren wenn ein Impuls von der Strombegrenzung kommt. Da es schnell gehen muss am besten beim AVR interruptbasiert den eingebauten Komperator nutzen. Bei SW Lösung darf die CPU halt NIE aus dem Tritt kommen, sonst ist evtl. Rauchentwicklung die Folge.


    Das "Ruckelproblem" kann ich jetzt nicht wirklich gut einschätzen, klingt aber so als ob etwas in dem Regelzweig in Resonanz gekommen ist. Auch das mit der PWM halbieren habe ich bei meinem eQuad versucht und als nicht praktikabel abgehakt, weil die Fahrergebnisse letztlich zu unbefriedigend waren...

    Was hälst Du denn von folgenden Vorschlag: ich realisiere die Strombegrenzung mittels HW (Shunt im Massezweig -> OpAmp m. einstellbare Schaltschwelle -> Logikgatter -> /SD vom Treiber) wie folgt: mit Erreichen der Überstromgrenze werden innerhalb von 5µs alle FETs abgeschaltet (/SD = L), egal welche PWM-Ansteuerung vom µC gegenwärtig anliegt. Vermutlich wird der H-aktive Teil der PWM gerade anliegen, welcher den Motor bestromt. Die PWM vom µC läuft weiter, die FETs bleiben aber nur bis zum Ende des aktuellen PWM-Zyklus gesperrt (max. 125µs bei 8kHz, eher weniger da laufender Zyklus). Mit Beginn des neuen PWM-Zyklus werden die FETs wieder wie gewohnt angesteuert.

    Was passiert jetzt wohl? Ich hatte das mal in dieser Art und früherer Zeit per SW an meiner eQuad-Steuerung getestet und folgenden Ablauf beobachten können: am Punkt der Strombegrenzung (im Test bei 9A) überschwang der Zeiger des Amperemeters noch etwas um gleich darauf etwas unterhalb von 9A zu verharren, während die Drehzahl des Motors immer weiter zunahm. Erst als die gewünschte Drehzahl erreicht war und der Strom vom Anlauf- auf Nennstrom zurückging war gelegentlich ein kleines Pendeln (oszilieren) um den Regelpunkt herum zu beobachten, was sich aber m.E. noch mit einer Hsyterese in den Griff kriegen läßt und wohl nur dann auftritt, wenn der Nennstrom zufälligerweise der Überstromgrenze entspricht. Dies wird wohl nur in meinem Prüfaufbau so gewesen sein und nicht der Realität entsprechen, wo die Steuerung min. 2...5-fache Nennströme liefern sollte.

    Ein "Ruckeln" am Begrenzungspunkt war bei diesen Tests nicht zu beobachten (wäre für den Fahrer des eQuad auch nicht so prickelnd).

    Möglicherweise hängt Dein Ruckeln mit einer zu großen zeitlichen Pause (= FET-Abschaltung) und/oder mit zu großen Sprüngen in der PWM-Absenkung zusammen (eine plötzlich zu kleine PWM bremst den Motor). Dies würde dann auch ein Ruckeln erklären, da der Motor am Begrenzungspunkt kurz (möglicherweise zu viel) abtourt, um nach der Stromzugabe sofort wieder aufzutouren. Geht es dann gleich wieder in die Begrenzung wiederholt sich diese Vorgang solange, bis die gewünschte Drehzahl erreicht wird, wobei die zeitlichen Pausen zw. dem Ruckeln immer kleiner werden dürften, bis es schlußendlich in einen gleichmäßigen Lauf übergeht.

    Was hälst Du von meiner Idee einer HW-Strombegrenzung? Ich glaube das es funktioniert. Die Steuerung muß halt in der Lage sein diesen Strom auch zu liefern, ohne dabei in die Knie zu gehen. Solange das so ist gehe ich davon aus, das ein (anlaufender) Motor, welcher permanent in der Strombegrenzung hängt, kontinuierlich Drehzahl aufbaut - nur eben zeitlich verzögert. Dies sollte auch ohne Ruckeln zu realisieren sein.
    .

    Einmal editiert, zuletzt von Lars (3. Februar 2012 um 02:25)

    • Offizieller Beitrag
    Zitat

    (Shunt im Massezweig -> OpAmp m. einstellbare Schaltschwelle -> Logikgatter -> /SD vom Treiber)


    Kleine Anmerkung dazu: Ich würde es so machen dass ich die Schwelle mit dem Controller vorgeben kann, denn manchmal kann es gewünscht sein die Strombegrenzung programmtechnisch kurzfristig z.B. auf 150% zu setzen um beim Anfahren an steilen Hängen mit großer Last einen Drehmomentüberschuss zu haben...

    Zitat

    Was hälst Du von meiner Idee einer HW-Strombegrenzung? Ich glaube das es funktioniert. Die Steuerung muß halt in der Lage sein diesen Strom auch zu liefern, ohne dabei in die Knie zu gehen. Solange das so ist gehe ich davon aus, das ein (anlaufender) Motor, welcher permanent in der Strombegrenzung hängt, kontinuierlich Drehzahl aufbaut - nur eben zeitlich verzögert. Dies sollte auch ohne Ruckeln zu realisieren sein.


    Nun, ich würde sagen das könnte klappen, sprich sogar gut funktionieren. Bei Strombegrenzern habe ich aber gelernt vorsichtig zu sein. Du solltest deine Idee einfach mal anhand eines Labortests aufbauen und überprüfen ob sich in der Realität so verhält wie gedacht. Ein kleiner Motor reicht da schon...

    Zitat

    Möglicherweise hängt Dein Ruckeln mit einer zu großen zeitlichen Pause (= FET-Abschaltung) und/oder mit zu großen Sprüngen in der PWM-Absenkung zusammen (eine plötzlich zu kleine PWM bremst den Motor). Dies würde dann auch ein Ruckeln erklären, da der Motor am Begrenzungspunkt kurz (möglicherweise zu viel) abtourt, um nach der Stromzugabe sofort wieder aufzutouren. Geht es dann gleich wieder in die Begrenzung wiederholt sich diese Vorgang solange, bis die gewünschte Drehzahl erreicht wird, wobei die zeitlichen Pausen zw. dem Ruckeln immer kleiner werden dürften, bis es schlußendlich in einen gleichmäßigen Lauf übergeht.


    Das Problem von unserem ersten und auch IBFs Begrenzer direkt am DISABLE des Treibers war eine Mischung aus Resonanzeffekt und vor allem hartes Abschalten ALLER 4 Zweige und zwar egal wie die PWM gerade anliegt. Meine Folgerung daraus: Eine Strombegrenzung die direkt auf den DIS des Treibers wirkt sollte entweder auch die PWM per Hardware kontrollieren können oder ein Feedback an den Controller zurückliefern damit dessen Software zusätzlich die PWM herunterfahren kann...

    • Offizieller Beitrag
    Zitat

    Das Problem von unserem ersten und auch IBFs Begrenzer direkt am DISABLE des Treibers war eine Mischung aus Resonanzeffekt und vor allem hartes Abschalten ALLER 4 Zweige und zwar egal wie die PWM gerade anliegt. Meine Folgerung daraus: Eine Strombegrenzung die direkt auf den DIS des Treibers wirkt sollte entweder auch die PWM per Hardware kontrollieren können oder ein Feedback an den Controller zurückliefern damit dessen Software zusätzlich die PWM herunterfahren kann...


    War durch ein Logikgatter gelöst, das die Ansteuerung des Treibers unterband, sobald die Strombegrenzung eingesetzt hatte. Also eiskalt das PWM-Signal weggeklappt. (UND-Gatter mit NOT am Eingang von der Strombegrenzung). Ging also einzeln pro Motorzweig, aber die Unterbrechung bzw. Zuschaltung fand auch während des Pulses statt. Also u.U. auch kürzere Pulse.
    Merkt man, dass beim aktiven Motorbetrieb und nach dem längeren Einsatz der Strombegrenzung die MOSFETs mit der thermischen weißen Fahne protestieren.

    Einstellbar war die Strombegrenzung über ein Trimmpoti. Über Software die Komparatorschwelle einstellen wollte ich vermeiden, damit man beim Turnier auch kurzfristig mal mit einem Uhrmacher-Schraubendreher den Motor "richtig" einstellen kann. Wie o.g. schon erwähnt, ist der Absolutwert von der Strombegrenzung relativ egal. Hauptsache beim Anfahren oder im Blockadebetrieb erfolgt eine "Schonung".

    In den neuen Fahrtreglern bin ich von der harten Hardwareabschaltung bei Überstrom abgekommen. Das Abgleichen des I-Anteils nach dem Komparatorteil war immer ein gefuchse und hatte nie so sauber funktioniert, dass ich damit zufrieden gewesen wäre. (Überschwinger sollten gedämpft werden; Von der eigentlichen Pulshöhe, unabhängig von der Länge, sollte eine Art "True DC-Anteil" herauskommen; Sobald der Puls aus ist, sollte der Integrator sofort wieder auf Null sein.) => Das wird jetzt über die Software erledigt. Nachteil: Ich muss in der Main-Schleife halt rechtzeitig die Sub aufrufen, die den Porteingang von der Stromüberwachung abfragt. U.U. bin ich da ein paar 100us zu spät dran. Aber wenn das die Hardware nicht aushält, dann hätte es kein Made-in-Germany-Regler werden dürfen. ;)

    • Offizieller Beitrag

    nur um die Bemerkungen zum Thema Schneckengetriebe nicht unkommentiert zu lassen. Gerade bei einem Fahrzeug, welches im steilen Gelände operieren soll kann ein selbsthemmendes Schneckengetriebe die richtige Wahl sein. Ansonsten wird es schwer die Postion am Hang zu halten, wenn man nicht die strombefeuerte Kurzschlussbremse mit einbaut. Verhindert auch, das die Kiste mit zunehmender Geschwindigkeit den Hang hinunter donnern will obwohl man lieber langsame schleichfahrt braucht..... Immer mal überlegen, wofür die Sache sein soll.

  • Zitat

    Original von Gizmo
    Das Problem von unserem ersten und auch IBFs Begrenzer direkt am DISABLE des Treibers war eine Mischung aus Resonanzeffekt und vor allem hartes Abschalten ALLER 4 Zweige und zwar egal wie die PWM gerade anliegt. Meine Folgerung daraus: Eine Strombegrenzung die direkt auf den DIS des Treibers wirkt sollte entweder auch die PWM per Hardware kontrollieren können oder ein Feedback an den Controller zurückliefern damit dessen Software zusätzlich die PWM herunterfahren kann...


    Ich hatte in der ersten Variante bei meinem Elektro-Quad (welches von der E-Traktion etwa einem Bot mit ca. 270kg entspricht) anfänglich eine ziemlich rabiate Strombegrenzung vorgesehen, ganz auf SW-Basis: bei Überstrom ging der Controller in den (per SW erzwungenen) Reset und als erstes wurde dann auf das Schließen des eGasgriff gewartet, sekundiert mit einem Pfeiffton. Der Fall trat aber nur selten auf dem ersten m auf, speziell wenn die Vorderräder nicht gerade standen (Lenkung eingeschlagen). Dies war von der Ansteuerung (PWM) natürlich absolut sicher aber etwas unkomfortabel.
    Aktuell werden beim eQuad per HW alle Treiber abgeschaltet, solange die Überstromsituation anliegt. Gleichzeitig wird ein Interrupt ausgelöst, welcher die gegenwärtige PWM "einfriert" und es wird ein Timer gestartet. Nach 100ms wird - ohne erneuter Überstromsituation - die Erhöhung der PWM wieder zugelassen, usw. Alternativ kann ich bei erneutem Überstrom auch die PWM um 1% verringern, verschiedene Optionen kann ich hier unterwegs ganz bequem am Bordcomputer einstellen und so direkt in der Praxis austesten.
    Problematisch wird es m.E. wenn bei dieser Regelung zu große "Lücken" entstehen, der Motor also zu viel RPM abbaut, und dann wieder mit der nun zu großen PWM beaufschlagt wird. Hier kann es zu einem Stromstoß kommen und den Motor mech. überlasten. Besser ist es dann, die PWM der RPM anzupassen BEVOR die Treiber wieder voll aktiviert werden. Das Ganze dann noch lastabhängig und unter Berücksichtigung der sich entladenen Batterie...

    Für meine H-Brücke (Bot) werde ich daher versuchen im Labor einen Prüfplatz aufzubauen, mit 2kW-Quelle und -Last! Damit sollten sich die Tests dann durchführen lassen, welche zur Findung und Abstimmung einer wirksamen Strombegrenzung nötig sind...
    Momentan arbeite ich an der Mechanik, da ich die Elektronik an der (möglichst) fertigen Mechanik in Betrieb nehmen möchte.
    .

    Einmal editiert, zuletzt von Lars (6. Februar 2012 um 18:54)

    • Offizieller Beitrag
    Zitat

    nur um die Bemerkungen zum Thema Schneckengetriebe nicht unkommentiert zu lassen. Gerade bei einem Fahrzeug, welches im steilen Gelände operieren soll kann ein selbsthemmendes Schneckengetriebe die richtige Wahl sein. Ansonsten wird es schwer die Postion am Hang zu halten, wenn man nicht die strombefeuerte Kurzschlussbremse mit einbaut. Verhindert auch, das die Kiste mit zunehmender Geschwindigkeit den Hang hinunter donnern will obwohl man lieber langsame schleichfahrt braucht..... Immer mal überlegen, wofür die Sache sein soll.


    Aus der Perspektive noch gar nicht bedacht. Der Mann ist gut, denn das könnte Sinn machen... :]

    Zitat

    Ich hatte in der ersten Variante bei meinem Elektro-Quad (welches von der E-Traktion her einem Bot mit ca. 270kg entspricht) anfänglich eine ganz brutale Strombegrenzung vorgesehen, voll aus SW-Basis: bei Überstrom ging der Controller in den (per SW erzwungenen) Reset und als erstes wurde auf das Schließen des eGasgriff gewartet, sekundiert mit einem Pfeiffton. Der Fall trat aber nur auf dem ersten m auf, speziell wenn die Vorderräder nicht gerade standen (Lenkung eingeschlagen). Dies war von der Ansteuerung (PWM) natürlich absolut sicher aber etwas unkomfortabel.
    Aktuell werden beim eQuad per HW alle Treiber abgeschaltet, solange die Überstromsituation anliegt. Gleichzeitig wird ein Interrupt ausgelöst, welcher die gegenwärtige PWM "einfriert" und es wird ein Timer gestartet. Nach 100ms wird - ohne erneuter Überstromsituation - die Erhöhung der PWM wieder zugelassen, usw. Alternativ hatte ich bei erneutem Überstrom auch die PWM um 1% verringert, was auch gut lief. Problematisch wird es m.E. wenn bei dieser Regelung zu große "Lücken" entstehen, der Motor also zu viel RPM abbaut, und dann wieder mit der nun zu großen PWM beaufschlagt wird. Hier kann es zu einem Stromstoß kommen und den Motor mech. überlasten. Besser ist es dann, die PWM der RPM anzupassen BEVOR die Treiber wieder voll aktiviert werden. Das Ganze dann noch lastabhängig und unter Berücksichtigung der sich entladenen Batterie...


    Ich seh schon das wird großes Kino was du da machst. Das würde sich fast sicher auch als gute Heavy Regler Alternative im Robotwars Einsatz machen. Da müssten wir mit dir wohl noch etwas verhandeln dass du das evtl. modular, sprich an andere Zwecke anpassbar aufbaust... :]

  • Zitat

    Original von Gizmo
    Ich seh schon das wird großes Kino was du da machst. Das würde sich fast sicher auch als gute Heavy Regler Alternative im Robotwars Einsatz machen. Da müssten wir mit dir wohl noch etwas verhandeln dass du das evtl. modular, sprich an andere Zwecke anpassbar aufbaust... :]


    Erstmal langsam. Sooo weit bin ich nun lange noch nicht. Außerdem gehe ich erstmal von "nur" 75A Dauerstrom aus, was eine ganze Menge ist. Natürlich wäre es schön bei 75A Dauer dann Anfahrströme von 150A zu können, usw. Da wird es aber noch einige Arbeit geben. Erstmal 75A dauerhaft und dann darauf aufbauen...

    Ich stelle mir den Ablauf zunächst mal so vor:

    1) Ich werde zunächst EINE Vollbrücke mit einem Controller auf einer Doppel-Eurokarte labormäßig aufbauen und durchmessen. Hierzu werde ich versuchen, möglichst viel davon mittels Video zu dokumentieren und in meinen YT-Kanal (BerlinTec) zur Diskussion zu stellen.

    2) Wenn dies soweit läuft werde ich mit den gewonnenen Erkenntnissen auf der Doppel-Eurokarte die zweite Vollbrücke aufbauen und austesten.

    3) Wenn alles läuft kann ich jetzt die Laborplatine in meinen (hoffentlich dann soweit fertigen) Bot einbauen und in Betrieb nehmen. Jetzt muß die SW erstellt werden, um mit dem Bot vernünftig fahren zu können. Insbesondere müssen Gleichlaufschwankungen der Motoren untereinander kompensiert werden, usw.

    Wie ich bereits schrieb kann ich mit der Standard-RC-Steuerung nichts direkt anfangen, habe im Modellbau damit auch bislang nichts gemacht. Dies erfordert spezielle Erfahrungen und ist recht aufwändig, wie IBF hier mal schrieb. Ich werde mir also eine Steuerung bauen, wo ich die Leistung der Motoren in % einzustellen gedenke, evtl. mit einem Bit für Vor-/Zurück...

    4) Wenn bis hier das Leben nicht andere Prioritäten setzt habe ich dann eine Doppel-H-Brücke auf Doppel-Euroformat (etwa 160x230mm) mit Controller, div. Schnittstellen und der Spezifikation: 32V / 2x 75A.

    An dieser Stelle würde ich natürlich gern alles auf meinen Bot optimieren, auch um in mehr od. weniger harten Fahrtests die Steuerung diversen Belastungstest zu unterziehen, zumal ich im Labor immer nur eine Brücke unter Volllast prüfen kann.

    5) Für meine Zwecke bräuchte ich bis zu diesem Zeitpunkt erstmal kein Layout. Allerdings könnte man später darüber nachdenken, z.B. für die H-Brücke ein Layout zu erstellen. Die Ansteuerung könnte dann dergestalt erfolgen, dass die Signale der Treiber über einen Steckverbinder geführt werden und sich jeder Anwender einen Controller mit Verbindung zur RC-Welt dort anschließt.

    Fazit: noch viel Arbeit. Und es läuft bei mir je nach Zeit nebenbei, weil eben Hobby.
    .

    Einmal editiert, zuletzt von Lars (7. Februar 2012 um 13:43)

  • Nun sind wieder einige Monate vergangen und ich arbeite nahezu unter Hochdruck an meinem Bot (Erprobungsträger). Leider kann ich hier meine Bilder nicht hochladen, da diese für eine volle Bilddarstellung um 500 KB haben, die Uploadfunktion aber offenbar nur eine Dateigröße von max. 200 KB zulässt, was aber für tech. Details - so wie diese in einem Technikforum eher typisch sind - m.E. zuwenig ist...!
    Die Bot-Mechanik ist jetzt soweit fertig - Motoren, Achsen, Ketten, Sensoren und Akkus verbaut (zunächst 2x 12V/20Ah); es kann jetzt an den Aufbau der 2x 70A-Leistungselektronik gehen...

    Und schon stehe ich vor dem Problem mit der / den Leiterplatte(n), da es aus meiner Sicht jetzt min. 2 Varianten gibt. Bevor ich jetzt mit meinem Laboraufbau loslege möchte ich diese hier mal vorstellen und eure Meinung dazu erfahren, z.B. wo ihr Vor- und Nachteile seht, mögliche Erfahrungswerte dazu, usw...:

    --> 1. Variante:

    Nur EINE Leiterplatte (Größe ca. 150x230mm) bestückt mit den beiden H-Vollbrücken, KK, etc. UND einem ATmega16 als Controller für die Treiberansteuerung / Funk-Interface, etc. Dies bedeutet, dass ich die LP auf die Chassis-Abdeckung des Bot setzen muß, da diese von der Größe her unmöglich im Innern Platz hat.

    Vorteil: nur EIN Controller (nebst Programmierschnitstelle) nötig um die gesamte Steuerung und das Interfacing zu realisieren und 2 Motoren zu überwachen (Temperatur, Strom) und zu synchronisieren (Gleichlauf, Drehmoment)...

    Nachteil: optisch finde ich das nicht so prickelnd, da das zur LP benötigte ABS-Gehäuse (Höhe wegen KK) eine Größe von 250x160x90mm hat. Nachteilig ist m.E. außerdem, dass ALLES auf einer LP drauf ist. Sollte später tatsächlich ein Layout erstellt werden, müßte man wenn man nur eine H-Brücke braucht dennoch die ganze LP nehmen (volle Größe), selbst wenn man einige Bereiche unbestückt läßt.

    --> 2. Variante:

    Aufbau vom Funktionsumfang wie oben jedoch im Innern des Bot und aufgeteilt auf DREI Leiterplatten (je Größe ca. 90x150mm).

    Vorteil: jede H-Brücke kann verlustreduzierend direkt am Motor montiert werden. Eine LP mit H-Brücke könnte ohne Interface-Controller betrieben werden, z.B. für nur einen Motor im Selbstbau, was dann kostengünstiger wäre.

    Nachteil: die 3 LP müßen miteinander zum Austausch der Sensor- und Steuerdaten vernetzt werden (z.B. via I²C-Bus oder RS232). Zudem steigt der Bauteile- und Verdrahtungsaufwand, da jetzt JEDE LP eine eigene Spannungsversorgung benötigt (Logik= 5V, Treiber= 15V). Außerdem braucht JEDE LP einen Controller, es sind also 3 Controller nebst Programmieranschluß nötig. Dies erhöht den Programmier- und Bauteileaufwand und ist damit eine potentielle Fehlerquelle, speziell bei späteren Programmänderungen. Würde man dagegen bei der H-Brücken-LP auf einen eigenen Controller verzichten, müßten die Treiber-Steuerleitungen der MOSFETs durch den gesamten Bot bis hin zum Interface-Controller gezogen werden, was ich für sehr riskant halte (eine Leitungsstörung schaltet ggf. MOSFET durch!) und wodurch die H-Brücke unflexibel würde, da ohne µC nichtmal einfachste rc-Funksignale ohne zusätzlichen LP-Aufwand umgesetzt werden könnten...

    Was also tun?

    Auch wenn es nicht so schön aussieht und im Falle eines Schaukampfbot auch garnicht ginge: ich tendiere dazu alles auf eine Karte zu setzen und in einem IP67-ABS-Gehäuse oben auf dem Bot zu montieren.
    Überwiegender Vorteil liegt m.E. im geringeren Verdrahtungs-/Bauteileaufwand und in der Tatsache, dass ein Controller für die gesamte Steuerelektronik zuständigt ist.

    • Offizieller Beitrag

    Meine Empfehlung:

    --> Variante 3:

    Auf drei Karten aufteilen. Aber nicht mit drei getrennten Spannungsversorgungen und keine Vernetzung über I2C, sondern "konventionell" verdrahtet.

    Heißt:
    Controller-Baugruppe mit allem, was irgendwie mit Sensor-Signalaufbereitung zu tun hat.
    Zwei identische Endstufen, die eigentlich nur dafür da sind, die PWM in Power umzusetzen und ein paar Sensorsignale zu liefern.

    Auf der Controllerplatine befinden sich dann auch die 5V und (offensichtlich brauchst Du die auch?) 15V-Stabilisierungen.
    An der Controllerbaugruppe sind zwei Wannenstecker aufgelötet. Über zwei Flachbandkabel werden damit die Endstufen angesteuert bzw. abgefragt.

    Die fetten Klemmen für die Powerversorgung brauchst Du also nur an den Endstufenplatinen vorsehen. Von dort dann einmalig eine schwache Leitung zum Controller, damit dort dann die 5V/15V generiert werden können.

    Vorteile:
    Du hast garantiert irgendwo einen Layoutfehler im Controllerteil. Bei einem Redesign können die Endstufen beibehalten werden.
    Für die Inbetriebnahme kann es manchmal von Vorteil sein, wenn die Endstufen noch nicht mit den "Amperes" laufen, sondern dass man die Signale noch so ansteuern bzw. messen kann. Das Abziehen des Flachbandverbinders hilft da ungemein.
    Falls mal ein Motor läuft und der andere nicht: Mit dem Tauschen der Flachbandstecker kann der Fehler relativ flott eingegrenzt werden, ob er im Controllerteil oder auf der Endstufe ist.
    Bei der Endstufe entsteht Verlustleistung. Also mit Kühlkörper hantieren, etc. Es ist wesentlich einfacher, eine Kühlkörper an eine kleinere Einheit anzupassen, als da auch noch die ganze Peripherie (z.B. SK-Kühlkörper für die 5V/15V-Stabilisierungen) berücksichtigen zu müssen.
    Die Controllereinheit mit der Signalaufbereitung hat einen "Abstand" zu den Power-Leitungen. Du kriegst also wesentlich weniger Störsignale über induktive/kapazitive Kopplung an die Mess-/Prozessoreinheit ran. Kann zu deutlichen Verbesserungen bei der EMV führen (=> weniger Programmabstürze im Debug-Modus)

    Sekundärer Nachteil kann sein: Störeinstrahlung über die Flachbandkabel (wirken als "Antennen"). Hier muss dann nachträglich u.U. mit einer Kupferfolie eine Abschirmung "gebaut" werden. Alternativ kann man auch ein geschirmtes Kabel an den Flachstecker anlöten, kostet halt ein paar Minuten an Arbeitszeit.

    Zitat

    (Logik= 5V, Treiber= 15V).


    Bist Du sicher, dass der Treiber-IC eine 15V-Konstantspannung braucht? Wird der nicht über die Betriebsspannung der MOSFETs gefüttert?

    Zitat

    Leider kann ich hier meine Bilder nicht hochladen, da diese für eine volle Bilddarstellung um 500 KB haben, die Uploadfunktion aber offenbar nur eine Dateigröße von max. 200 KB zulässt, was aber für tech. Details - so wie diese in einem Technikforum eher typisch sind - m.E. zuwenig ist...!


    Die Größe bzw. Auflösung reicht eigentlich schon. Man will ja normalerweise nicht unbedingt jedes Bild einzeln öffnen und dann detailiert durchzoomen. Wenn besondere Sachen zu beachten sind, dann müßte der Autor einen Zoom-Ausschnitt generieren und den dann einzeln präsentieren. :D;)
    Alternative: Die Bilder auf einem separaten Server hinterlegen und dann hier verlinken. :D
    Unsere Jugend hat hier an anderer Stelle ein paar interessante Dienstleister gefunden, wo man Bilder kostenlos hinterlegen kann. (einfach mal die Bilder in anderen Threats anklicken, dann kriegst Du die Quelle mit. ... Sorry, kann mich jetzt aus dem Stegreif heraus nicht an diese Domainnamen erinnern)

    Ein Foto in der Gesamtansicht mit 200kB tät's für den Anfang aber schon mal. :D:D:D

  • Zitat

    Original von IBF
    Ein Foto in der Gesamtansicht mit 200kB tät's für den Anfang aber schon mal. :D:D:D

    So. Ich versuche es mal über directupload...

    Hier mein Bot, wahre Schwerstarbeit der letzten Monate:

    Bot im (noch) unverschraubtem Alugehäuse:

    Mein Bot im Juli 2012:

    Hier die Details zum Kettenlauf:

    Details zur Umlenkrolle MIT KETTENSPANNER und 18 Zähne, montiert auf (abgedrehtem) M16-Bolzen:

    Ein OMRON-Initiator "sieht" die 19 Zähne des Kettenrades:

    Kraftübertragung Kettenrad -> Achse mit 3 Stahlstifte:

    Die letzten Monate waren für mich z.T. der mechanische Horror, so habe ich z.B. zum ersten Mal im Leben GESCHWEIßT...!!! Natürlich habe ich zuvor an 20mm-Vollmaterial "geübt". Dabei stellte sich heraus, dass mein Schutzgas-Schweißgerät mit 3000W zu schwach war! Die Schweißnähte waren z.T. oberflächlich und ließen sich mit einer Rohrzange abscheren. Dies sollte ja nicht sein und so habe ich Entlastungsbohrungen auf der Bot-Achse quer zur Schweißnaht eingebracht und die Achse VOR dem Schweißvorgang mit einem 700°-Heißluftgebläse ca. 5 Min. "vorgeglüht"...

    Hier die ersten Schweißnähte meines Lebens:

    Fortsetzung folgt...
    .

    3 Mal editiert, zuletzt von Lars (19. September 2012 um 18:31)