このHブリッジでMOSFETドライバーが溶断したのはなぜですか?


9

私はディスクリートHブリッジ回路を構築して、かなり頑丈な12Vウィンドスクリーンワイパーモーターを実行しました。回路は以下のとおりです(編集:大きいPDFについてはこちらをご覧ください。StackExchangeでは画像を拡大できないようです):
RM:ここに大きい画像の画像が表示されます -これらはシステムによって保存されますが、小さいサイズでのみ表示されます。「新しいタブで画像を開く」からもアクセスできます

概略図

ボードを立ち上げて、100%デューティサイクル(非PWM)モードから始めて、機能していることを確認したので、ローサイドNチャネルMOSFETの1つにPWMを開始しました。これも問題ないように見えましたが、誘導スパイクからブリッジのPWMされた側のハイサイドショットキーで顕著な加熱が発生しました。

次に、誘導スパイクをより効率的に散逸させるために、ハイサイドMOSFETとローサイドMOSFETのPWMを開始しました。これも(おそらくデッドタイムが多すぎるため)、正常に機能しているように見え、トップサイドのダイオードは冷えたままです。

しかし、スイッチをしばらく使用して、デューティサイクルをライブで変化させた後、速度を約1から下げました。95%から25%へのデューティサイクル。しかし、このとき、ポップと突然の高電流が流れ、TC4428A MOSFETドライバが溶断していました。

これらは吹き飛んだ唯一のコンポーネントでした。MOSFET自体は問題ないので、私は自分の側のシュートスルーマペトリーを除外しています。これまでの私の最高の説明は、過剰な量の誘導性キックバック、または(可能性が高い)モーターからの過度の回生電力が減速して電源が処理できないことです。TC4428Aはブリッジ内で最も低い電圧定格(18V、絶対最大22V)を持っています。私は電圧の上昇が速すぎると考えています。

私はこのボードの12V側を旧式のリニアベンチトップ電源で実行しており、ボードとの間に比較的長いリード線がありました。これは、電圧上昇を実際に散逸させることができなかったと思います。

TC4428AsがMOSFETの動的負荷に関して過負荷になったとは思いません。私は比較的低速(約2.2kHz)でPWMを実行しており、MOSFET自体には特に高い総ゲート電荷はありません。ドライバーBのみがPWM制御されているにもかかわらず、動作中はクールなままで、AドライバーとBドライバーが故障したようです。

私の仮説は妥当なように思えますか?他に探している場所はありますか?もしそうなら、ボードの周り(電源入力とブリッジ出力端子の間)にいくつかの波状のTVSダイオードを自由にまき散らすことは、過電圧状態に対処するための合理的な方法ですか?スイッチドブレーキレジスタータイプのセットアップに移行する必要があるかどうかはわかりません(これは、「わずかな」2.5Aまたはそれなりの12Vギアモーターだけです...)。

更新:

12V電源端子(SMCJ16A)に1500W TVSを配置しました。これは、ブレーキ時の過電圧を20V未満にクランプしているようです(これは電源電圧を示しています。MOSFETゲートと0Vの間に同じ波形が見られます)。

ここに画像の説明を入力してください

それはきれいではなく、おそらくまだ高すぎます(SMCJ16Aのクランプ電圧は最大電流で26Vです-57A、TC4428Aの絶対最大値は22Vです)。私はいくつかのSMCJ13CAを注文し、電源とモーター端子の両方に配置します。1.5kWの大きなTVSがあったとしても、それが持続しないことを私はむしろ恐れています。TVSにとっては長い期間である80ms程度はクランプしているように見えます。とはいえ、涼しさを維持しているようです。もちろん、シャフトに実際の負荷がかかっている場合は、おそらく、結局、スイッチドブレーキレジスタソリューションを実装している可能性があります。


MOSFETとドライバに別々の電源ラインを使用していますか?
Ignacio Vazquez-Abrams

@ IgnacioVazquez-Abrams:ドライバーは(入力で)5Vで制御されていますが、MOSFET自体と同じ電源から同じ12Vをスイッチングしています。
xwhatsit 14

1
この時点では、減速中にシステムが吸収しなければならない回生エネルギーの量を知る方法がありません。そのため、モーターの減速中に入力電圧が絶対最大22 Vに近づくかどうかを確認するために、それを実際に特性化する必要があります。その場合、余分なエネルギーを吸収する方法が必要です。大きなTVS、コンパレーターとスイッチを備えた抵抗、大量の追加容量など。それが問題でない場合は、他の場所を探し始めることができます。回路を再構築した後、ドライバー周辺のすべてのノードを調べて、過剰な正または負のスパイクがないか調べ、再生エネルギーのテストを開始します。
John D

1
@xwhatsitはい、追加の容量は電源を横切って再生エネルギーを吸収するのに役立ちます。そして、はい、私はドライバーのすべてのピンを調べて、データシートの絶対最大定格の外にスパイクまたはエクスカーションがないかどうかを確認します。ドライバーが故障してもFETが故障しなかった場合は、電気的ストレスが原因である可能性が高いです。あなたはそれがどこから来ているのかを知る必要があります。
John D

1
回生電力+電力を吸収できない電源が問題だと思います。TVSはそれを解決するために依存しません。TVSは持続的なパワーではなく、エネルギーピークを吸収するように作られています。あなたは、その回生力を消散させることができる何かを得なければならないでしょう。アキュバッテリーはいいですし、永続的な負荷(大量の電力を浪費しますが、ラボのテストには良いかもしれません)、または散逸する可能性があるいくつかの電圧クランプ(パワートランジスタ+ TL431?)です。静電容量は役立つかもしれませんが、小さなピークの場合にのみ、何も散逸しません。
Wouter van Ooijen 14

回答:


4

FDD6637 MOSFETデータシートはこちら
TC4428Aデータシートはこちら

これまでのところ、MOSFETの存続に関係なく、私はゲートにソースツェナーをFETに追加して、誘導性負荷からのミラー結合電圧をクランプします。

これにより、観察された問題が解決する場合もあります。論理分析は、それができないことを示唆しています:-(-しかし、MurphyとMillarの容量は強力な魔法を働かせることができます。定格と、出力に「強制」された最大500 mAの逆電流を吸収する能力は、MOSFETゲートを介して誘導フィードバックをクランプすると予想されます。ただし、ゲートツェナーのコストはほとんどなく、このような状況で確実にMOSFETを保護するのに役立ちます。物事を悪化させる可能性は低いです。


一部の電源装置では逆電流がまったく流れません。
サプライ品の動作を確認しましたか?ブレーキ中に電源のメーター(オシロスコープの方が良い)が手掛かりになる場合があります。非常に大きなコンデンサが役立つ場合がありますが、これは、電力を散逸させることはできるが十分に速くない場合に電源を助けますが、電源が本質的に電力を吸収できない場合にのみ問題をマスクします。

負荷としてツェナー(または電気的等価物)と直列に接続された抵抗は、電力損失の制動に役立ちます(ただし、ツェナーはNボルトの上昇に対して電力の12 / Nthを消費します。

たとえば、TLV431が大きな負荷でV +が12.5Vを超えるとすぐにスイッチングし、注文が回復するとすぐにそれをドロップすると、ブレーキエネルギーを吸収するシンプルで低コストのソリューションのように聞こえます。


私は2 x 300ワットの「ワイパーモーター」(インド、トラック、使用用)を持っていますが、近い将来、プロトタイプで使用する予定です。楽しいはずです:-)。


NチャネルMOFSETで最大±20Vのゲートからソース、Pチャネルで±25Vの場合、MOSFET自体は、トーストされる前に12V電源のスパイクとショットキーに対処する必要があります。最初にドレインをソースにまっすぐに結合し、最大で1ボルト程度降下させる必要がありますか?ショットキーを使用して2Vの電圧降下があり、それがゲートに結合されてTC4428Aを介して戻る場合でも、約300mA程度しかヒットしないはずです(データシートによると7オームのスイッチ抵抗があります)。電源レールとモーター出力端子にまたがるTVSは同じ問題を解決しますか?
xwhatsit 14

スコープで実行すると、スパイクがボルトなどでかなりうまく切り取られるのがわかりました。そのため、電源はPWMからの誘導フライバックに対処できました。ただし、減速時の回生電力に対応できなかった可能性があります。それは単純な古い線形電源なので、あなたはそこにいるかもしれません。はい、それは問題を修正するかどうかに関係なく、牛肉のツェナーまたはTVSまたは3つが良い考えかもしれないと思います(ゲートツェナーと同様に、ゲート電荷のカップリングは私がまったく考慮していなかった領域です!)。300Wは面白そうです

@xwhatsit-次のことを知っています。大声で考えてください-エネルギーの戻りが問題であると仮定すると、TVSが機能するかどうかは、TVSの連続的な損失定格と、連続的な長期の損失経路があるかどうかに依存します。電源が実際にそして合法的に(同じことではなく)回生電力を吸収できることを確認する必要があります。| 最悪の場合の散逸が中程度の範囲で発生することが多いため、吸収される回生電力は最大で約~~~ 7ワット(50%の電力で約50%のエネルギー)であると推測されます。場合によっては、これをはるかに超える可能性があります。
ラッセルマクマホン

@xwhatsit-ゲートツェナー:ずっと前に、約200ワットの抵抗力と約20 kHzのPWMを備えた非常に誘導性の負荷がありました。ゲートツェナーと比較して非常に安定したMOSFETは、数秒から数分続きました。gs zenersを追加することで問題は完全に修正され、完全に不要であると断定されない限り(場合によってはそれでも:-))、現時点で設計にそれらを追加しています。FETの近くに取り付けます。もう1つの「トリック」(ここではあまり適用されない可能性があります)は、ゲートスプリアス発振をクランプするためにFETの近くに取り付けられた逆gsショットキーです。負の半サイクルは、正当なドライブに影響を与えることなく大規模なクランプを取得します。
ラッセルマクマホン

「正当に」対「実際に」—良い点。実際には、これは、はるかに優れたレギュレーションと散逸が可能であるはずの、はるかに能力の高い産業用3相-> 12VDC電源から実行されます。しかし、これを当たり前のことと考えるべきではありません。ゲートツェナーは間違いなくこれからを含めて価値のあるもののように聞こえ、このような状況ではツールボックス全体を投げる可能性もあります(少量、長年必要)。
xwhatsit 14

1

私はあなたの結論に同意します、それは電源を過電圧にする回生ブレーキです。

補足として、電源にさらにコンデンサを追加する必要があります。HFスイッチングリップル電流はこれらのコンデンサによって処理されるため、これらのコンデンサはこのリップル電流に対して定格にする必要があります。2つの220µFは...

さて、ドライバーを爆破するのを避ける方法は?

12Vが鉛蓄電池から来ている場合、回生ブレーキは単に電池を充電します。あなたはそれが電流を取ることができることを確認する必要がありますが、これがモーターを停止するだけの場合(そして車両が下り坂に行くのではない場合)、エネルギーは小さくなり、それはOKになります。

バッテリがなければ、電源を監視するコンパレータが簡単な解決策になります。たとえば17Vを超えると、コンパレータがMOSFETをオンにして、高電力抵抗を介して電流を引き出します。そして、電圧が例えば15Vを下回ると、MOSFETをオフにします。これは、レール容量とヒステリシスに依存する周波数で、それ自体でPWMするため、ヒステリシスが必要です。大きな抵抗を使用すると、シリコンの電力を消費するよりも安価になります。

ただし、無料で行うこともできます。

マイクロコントローラは供給電圧を監視します。高すぎると、両方のローサイドFETがオンに設定され、モーターが短絡します。電源の充電を停止し、代わりに内部の抵抗で電力を消費します。

この場合、モーターのブレーキ速度は遅くなります。これは、ブレーキが強くかかる原因となる極性を持つ12Vではなく0Vであるためです。しかし、このソリューションは何の費用もかかりません。シンプルで完全なものです。


1.または両方のハイサイドをオンにします。2.完全な短絡からのブレーキングは、12Vに再充電するときよりも高くする必要があります。12Vの逆極性で駆動する場合、I =(Vgenerated-Vsupply)/ R_motor、およびpower = I ^ 2.R =(Vg-Vp)/ Rmは予想どおりです。完全に短絡した場合(すべての場合にVdson〜= 0と想定)P = Vgenerated ^ 2 / Rmこれは常に高いです。| 番号?
ラッセルマクマホン

1.ハイサイドオンも両方とも機能します。誰かが電源を切らずにワイヤーをいじる場合に備えて、両方のモーターワイヤーが0Vになっている停止状態が望ましいです。 )よくわかりませんが、(Vg-Vp)ではなく(Vg + Vp)にする必要がありますか?
peufeu

ハードショートは12Vにダンプするときよりも速く停止することに同意しますか?(上記参照)
ラッセルマクマホン

まあ、私は少しジレンマを抱えています:モーターは逆方向に電圧をかけるとより多くのブレーキトルクを生成すると思いますが、トルクは電流に依存し、モーターを短絡すると最も電流が生成されるので、はい、私は間違っていたと思います、あなたに同意します(私は現在、数学をチェックするのが
面倒
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.