Forum: Mikrocontroller und Digitale Elektronik H-Brücke Software-seitig Schützen


von Martin K. (dschadu)


Angehängte Dateien:

Lesenswert?

Hi,

ich bin aktuell eine H-Brücke für die Ansteuerung eines 600W, 24VDC 
Bürstenmotors am entwickeln. Der Motor soll am Ende einen Linearantrieb 
positionieren. Zum testen läuft das aktuell über ein 900W Labornetzteil, 
nachher wird das System mit Auto-Batterien betrieben.

Die Hardware funktioniert (Links, Rechts, Bremsen). Die Drehzahl wird 
über einen Drehencoder mit 2400p/u eingelesen.

Nach der Implementierung eines PID-Reglers wollte ich testen wie gut der 
Motor die Position hält - und es wohl etwas übertrieben.
Folge ist ein gestorbener Mosfet und zwei Dioden. Klar, der arme Mosfet 
musste 900W aushalten.

Meine Frage ist jetzt: Wie schütze ich die Schaltung vor dem Scenario: 
Motor steht  blockiert  dreht sehr langsam unter Last?
Ich messe den Strom (mit einem INA240) der durch den Motor geht (R0) und 
habe die Drehzahl durch den Encoder. Mein gedankliches Problem ist jetzt 
allerdings, dass der Motor ja im Anlauf durchaus >150A ziehen kann und 
darf und im Betrieb 30A unter Last benötigt, was ja vollkommen in 
Ordnung ist. Aber 30A im Stillstand sind ungünstig. Meine Befürchtung 
ist dass ich durch eine Strombegrenzung massiv an Drehmoment einbüßen 
muss im Anlaufmoment.
Welcher Ansatz ist hier der beste? Gibt es eine AppNote die dieses Thema 
behandelt? Oder ein Stichwort für Google?

Danke im voraus! Und sollten Infos fehlen, liefere ich die gerne nach.

von Erich L. (loktarogar)


Lesenswert?

Hallo,

du könntest dir das Anfahren einfach als boolsche Zustandsvariable im 
Mikrocontroller speichern?

Wobei dann wiederum das Problem auftritt, dass wenn der Motor gerade 
anläuft und er dabei bereits blockiert wird, müsstest du neben dem 
Zustand auch die Zeit messen die der Motor normalerweise zum anlaufen 
benötigt und dagegen abwegen, um diesen Fall auch ausschließen zu 
könnnen.

von Simatic (Gast)


Lesenswert?

Hallo,

Dein Problem schreit fast schon nach I²t-Schutz.
https://de.wikipedia.org/wiki/Grenzlastintegral

Gruss Micha

von MiWi (Gast)


Lesenswert?

Martin K. schrieb:
> Hi,
>
> ich bin aktuell eine H-Brücke für die Ansteuerung eines 600W, 24VDC
> Bürstenmotors am entwickeln. Der Motor soll am Ende einen Linearantrieb
> positionieren. Zum testen läuft das aktuell über ein 900W Labornetzteil,
> nachher wird das System mit Auto-Batterien betrieben.
>
> Die Hardware funktioniert (Links, Rechts, Bremsen). Die Drehzahl wird
> über einen Drehencoder mit 2400p/u eingelesen.
>
> Nach der Implementierung eines PID-Reglers wollte ich testen wie gut der
> Motor die Position hält - und es wohl etwas übertrieben.
> Folge ist ein gestorbener Mosfet und zwei Dioden. Klar, der arme Mosfet
> musste 900W aushalten.
>
> Meine Frage ist jetzt: Wie schütze ich die Schaltung vor dem Scenario:
> Motor steht  blockiert  dreht sehr langsam unter Last?
> Ich messe den Strom (mit einem INA240) der durch den Motor geht (R0) und
> habe die Drehzahl durch den Encoder. Mein gedankliches Problem ist jetzt
> allerdings, dass der Motor ja im Anlauf durchaus >150A ziehen kann und
> darf und im Betrieb 30A unter Last benötigt, was ja vollkommen in
> Ordnung ist. Aber 30A im Stillstand sind ungünstig. Meine Befürchtung
> ist dass ich durch eine Strombegrenzung massiv an Drehmoment einbüßen
> muss im Anlaufmoment.
> Welcher Ansatz ist hier der beste? Gibt es eine AppNote die dieses Thema
> behandelt? Oder ein Stichwort für Google?
>
> Danke im voraus! Und sollten Infos fehlen, liefere ich die gerne nach.

Mir gefällt Deine Fehleranalyse nicht. Denn wenn die FETs 150A im 
Anfahren aushalten sind die 30A Normalbetrieb PillePalle, die zucken 
nicht einmal mit der Schulter bei dem Strom, das sind heiße 20% des 
Nennstroms (150A@100°C), egal ob sich der Motor dreht oder nicht. Daher 
- warum ist nur einer gestorben? Und welcher? Ich nehme an einen der 
Highside-Fets hat es erwischt. Sind da beide parallelgeschalteten Fets 
ausgefallen oder nur einer der beiden?

Denn die Schaltung hat ein paar Details, die voraussetzen das die 
Ansteuerung zu 100% zuverlässig ist und immer arbeitet:

1. Totzeiten um keinen Brückenkurzschluß zu verursachen.
2. ebenso zwingend muß die Lowside ebenso regelmäßig geschalten werden 
damit die Highside-Treiber den Puffer-C nachladen können.

Ist das garantiert auch dann wenn der Motor blockiert und die Regelung 
daher am liebsten Dauerplus liefert?

von oszi40 (Gast)


Angehängte Dateien:

Lesenswert?

Martin K. schrieb:
> nachher wird das System mit Auto-Batterien betrieben

1.Diese haben gewöhnlich keinen Strombegrenzer im Gegensatz zu manchem 
Labornetzteil. SW-seitig kannst Du ja ein paar übliche Impulse pro 
Umdrehung auswerten bevor Du die Notbremse ziehst, weil sonst der 
Schlitten auf den Prellbock knallt? Das bringt aber KEINE Sicherheit, 
daß ein durchlegierter Transistor den Motor dauernd unter Strooom setzt. 
In meinen Maschinen hat ein simpler Mikrotaster kurz vor dem Anschlag 
den Strom weggeschaltet und das Schlimmste verhindert. Bei 100A ist das 
nicht ganz so schön zu lösen.
2.Silizium schmilzt oft schneller als eine übliche Sicherung.

von Claudio F. (zunge)


Lesenswert?

PWM mit Cycle by Cycle Strommessung und Begrenzer. Dann kannste auch die 
900W mit Stillstand im Motor Verheizen gehen ohne dass die Fets rauchen 
...

falls du keine Strommessung vorgesehen hast (was schlecht wäre ...)kanns 
du vieleicht mit einer kurzen Handrechnung (Innenwiderstand und 
Induktivität des Motors) die Sinnvolle PWM-Frequenz ermitteln und danach 
die maximale PWM in SW Begrenzen (Ausgang PID-Regler oder Ausgang 
Stellglied)

von oszi40 (Gast)


Lesenswert?

Claudio F. schrieb:
> PWM mit Cycle by Cycle Strommessung

... funktioniert nur solange kein Transistor/MOSFET schon durchlegiert 
ist z.B. durch böse Spannungsspitze oder Hitzetod.

von Martin K. (dschadu)


Lesenswert?

Erst mal danke für die Antworten!

MiWi schrieb:
> Mir gefällt Deine Fehleranalyse nicht. Denn wenn die FETs 150A im
> Anfahren aushalten sind die 30A Normalbetrieb PillePalle, die zucken
> nicht einmal mit der Schulter bei dem Strom, das sind heiße 20% des
> Nennstroms (150A@100°C), egal ob sich der Motor dreht oder nicht. Daher
> - warum ist nur einer gestorben? Und welcher? Ich nehme an einen der
> Highside-Fets hat es erwischt. Sind da beide parallelgeschalteten Fets
> ausgefallen oder nur einer der beiden?

Es ist der Q1 ausgefallen - Q11 scheint zumindest Messtechnisch noch 
i.O. zu sein. Hatte noch keine Gelegenheit die neuen Mosfets einzulöten 
und zu testen.
Das Warum kann ich mir nur erklären, dass eben bei blockierendem Motor 
die 30A und 24V komplett an den Mosfets anlagen, und 360W pro FET sind 
dann doch etwas viel. Oder habe ich hier einen Denkfehler?

MiWi schrieb:
> Denn die Schaltung hat ein paar Details, die voraussetzen das die
> Ansteuerung zu 100% zuverlässig ist und immer arbeitet:
>
> 1. Totzeiten um keinen Brückenkurzschluß zu verursachen.
> 2. ebenso zwingend muß die Lowside ebenso regelmäßig geschalten werden
> damit die Highside-Treiber den Puffer-C nachladen können.

Zu 1: Der IR2183 hat eine integrierte Deadtime & Shoot-Through 
prevention.
Zu 2: Der IR2183 hat eine integrierte UV-Detection. Bricht die Spannung 
des Bootstrap Kondensators zu weit ein, schaltet er ab und nach ein paar 
Sekunden erst wieder zu. Was ich nicht verstehe, warum muss ich die 
Lowside abschalten? Aktuell ist es in der SW so, dass LowSide immer 100% 
an bleibt und die Highside geschaltet wird (max PWM 95%).

MiWi schrieb:
> Ist das garantiert auch dann wenn der Motor blockiert und die Regelung
> daher am liebsten Dauerplus liefert?
Die PWM zum Zeitpunkt des Tests war bei etwa 60% (extra begrenzt im PID 
zum testen).


oszi40 schrieb:
> Das bringt aber KEINE Sicherheit,
> daß ein durchlegierter Transistor den Motor dauernd unter Strooom setzt.
> In meinen Maschinen hat ein simpler Mikrotaster kurz vor dem Anschlag
> den Strom weggeschaltet und das Schlimmste verhindert. Bei 100A ist das
> nicht ganz so schön zu lösen.

Die Motorsteuerung spricht über CAN mit einem übergeordnetem Controller. 
Gibt es Kommunikationsprobleme oder außergewöhnliche Parameter (wie das 
z.b. der Motor läuft obwohl er aus sein sollte) wird ein Not-Aus 
ausgelöst und die Spannungsversorgung gekappt.

Claudio F. schrieb:
> PWM mit Cycle by Cycle Strommessung und Begrenzer. Dann kannste auch die
> 900W mit Stillstand im Motor Verheizen gehen ohne dass die Fets rauchen
> ...

Danke für das Stichwort, danach such ich mal!
Aber ist der Motor im Stillstand nicht ähnlich einem Kurzschluss? Müsste 
die Leistung dann nicht komplett auf den FETs liegen?

Claudio F. schrieb:
> falls du keine Strommessung vorgesehen hast (was schlecht wäre ...)

Doch, ist drin, R0! Funktioniert auch sehr gut.


Mein Ansatz wäre jetzt noch die Spannung an X6 und X7 zu messen, damit 
ich die Leistung über den Mosfets ausrechnen kann. Wäre das ein 
plausibler Ansatz?

von Martin K. (dschadu)


Lesenswert?

MiWi schrieb:
> Mir gefällt Deine Fehleranalyse nicht. Denn wenn die FETs 150A im
> Anfahren aushalten sind die 30A Normalbetrieb PillePalle, die zucken
> nicht einmal mit der Schulter bei dem Strom, das sind heiße 20% des
> Nennstroms (150A@100°C), egal ob sich der Motor dreht oder nicht. Daher
> - warum ist nur einer gestorben?

Jetzt verstehe ich was du meinst. Ich hatte da nen dicken Denkfehler. 
Und jetzt frage ich mich noch mehr, warum ist er kaputt gegangen und 
warum nur einer.
Gehe ich von 0,1 Ohm Innenwiderstand des Motors aus und rechne R0 und Ri 
dazu, komme ich auf 0,109 Ohm. Da das Netzteil bei 30A die Spannung 
reduziert, lieferte das nur noch 3,3V. Macht keine 2 W an dem Mosfet. 
Selbst ohne Kühlkörper sind das nur 65°C.

Die einzige Idee die ich habe, ist dass der Mosfet nicht richtig 
verlötet war oder von Anfang an einen weg hatte.

(konnte leider nicht mehr editieren)

von MiWi (Gast)


Lesenswert?

Martin K. schrieb:

>
> MiWi schrieb:
>> Denn die Schaltung hat ein paar Details, die voraussetzen das die
>> Ansteuerung zu 100% zuverlässig ist und immer arbeitet:
>>
>> 1. Totzeiten um keinen Brückenkurzschluß zu verursachen.
>> 2. ebenso zwingend muß die Lowside ebenso regelmäßig geschalten werden
>> damit die Highside-Treiber den Puffer-C nachladen können.
>
> Zu 1: Der IR2183 hat eine integrierte Deadtime & Shoot-Through
> prevention.

ok.


> Zu 2: Der IR2183 hat eine integrierte UV-Detection. Bricht die Spannung
> des Bootstrap Kondensators zu weit ein, schaltet er ab und nach ein paar
> Sekunden erst wieder zu. Was ich nicht verstehe, warum muss ich die
> Lowside abschalten?

Denk mal gut und gründlich darüber nach wie C26 oder C29 aufgeladen 
werden...

> Aktuell ist es in der SW so, dass LowSide immer 100%
> an bleibt und die Highside geschaltet wird (max PWM 95%).

Nun... da hast Du schon die Ursache zu dem Ausfall - und es 
funktionierte nur eher zufällig. Der ausgefallene FET (wie angenommen 
Highside) ist halt als erster unter der sinkenden Gatespannung 
gelitten.. und das wars. der andere ist vermutlich angeknackst.

Wackle mit der Lowside auch entsprechend herum und das Werkl sollte 
funktionieren.

Oder suche Dir eine aktive Ladungspumpe bzw. Wandler, die die beiden Cs 
der Highside-Ansteuerung konstant lädt so das DC-Betrieb der Lowside 
möglich ist.

von Martin K. (dschadu)


Angehängte Dateien:

Lesenswert?

Also ich habe das jetzt mal in LTSpice Simuliert und versucht deine 
Aussage nachzuvollziehen.
Mit "Wackle mit der Lowside auch entsprechend herum" meinst du Q2 und 
Q21, in dem Fall dass Q1/11, Q4/41 'arbeiten'?
Anders wüsste ich nicht wie der Kondensator laden sollte, außer über die 
Last und Q4/41, die aber ja immer high sind in dem Betriebsfall. Q4/41 
auszuschalten im Takt mit Q1/11 würde ja keinen Sinn machen, dann kapp 
ich ja den Strompfad.

Ich habe auch eine AppNote dazu gefunden (an-978 von IR) und die 
Schaltung im Anhang. Das habe ich auch mal simuliert und das 
funktioniert soweit, werde ich also wohl so in meine Schaltung 
integrieren.
Parallel werde ich testen Q1/11 und Q2/21 entsprechen invertiert 
anzusteuern.

von MiWi (Gast)


Lesenswert?

Martin K. schrieb:
> Also ich habe das jetzt mal in LTSpice Simuliert und versucht deine
> Aussage nachzuvollziehen.
> Mit "Wackle mit der Lowside auch entsprechend herum" meinst du Q2 und
> Q21, in dem Fall dass Q1/11, Q4/41 'arbeiten'?
> Anders wüsste ich nicht wie der Kondensator laden sollte, außer über die
> Last und Q4/41, die aber ja immer high sind in dem Betriebsfall. Q4/41
> auszuschalten im Takt mit Q1/11 würde ja keinen Sinn machen, dann kapp
> ich ja den Strompfad.
>
> Ich habe auch eine AppNote dazu gefunden (an-978 von IR) und die
> Schaltung im Anhang. Das habe ich auch mal simuliert und das
> funktioniert soweit, werde ich also wohl so in meine Schaltung
> integrieren.
> Parallel werde ich testen Q1/11 und Q2/21 entsprechen invertiert
> anzusteuern.

Lowside sind die FETs, die gegen GND schalten, Highside sind die, die 
von VCC kommend schalten.

Die Ladungspumpe.... nun, die funktionert auch nur dann wenn diese Seite 
der Brücke angesteuert wird, denn sonst steht da keine Versorgung an. 
iaW: die Startzeit der Ladungspumpe muß schneller sein als der Puffer-C 
seine über die 11DF6 erhaltene Ladung verliert. Also C groß machen (2-4u 
sollten reichen, 100n sind IMHO zu wenig, ohne das nun nachgerechnet zu 
haben)

Und - ich denke Du solltest sehr genau nachdenken und Dir einmal ohne 
Simulation versuchen klarzumachen was die Ströme in dem System machen 
wenn Fets zu und weggeschalten werden. So gaaaaanz trivial ist das von 
außen nicht, vor allem wenn 30 oder mehr A im Spiel sind...

Was macht der Strom in der Totzeit der Brücke? Auch dann wenn kein FET 
leitet will der Strom nämlich weiter strömen. Und  die Freilaufdioden 
der FETs brauchen eine gewissen Einschaltzeit...

Wie gesagt, das ist alles kein Hexenwerk und wenn man einmal alle States 
durchgeht auch gut verständlich - doch mußt Du wissen was passiert 
bevor Du an der Modulation herumspielst...

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
Noch kein Account? Hier anmelden.