PWM-Problem

[Hightech]

Den Kühlkörper auf Powerground zu legen ist keine schlechte Idee, die Isolationen müssen das bloß aushalten.

Die Glimmerscheiben sollten das doch wohl mitmachen ?

Was ist diese DGH301600 für eine komische Diode?

Das ist eine Dwhd-Diode.
Die war halt da, von denen hab ich noch ein paar über.

[Hightech]

Hi,
ist jetzt die Schaltung von oben, in "grün" aktuell? Wenn ja, stimmt das dass der Opto nun ein 6N135 ist?
Wenn ja solltest du dem In-Pin vom IR2117 auf jeden Fall noch einen Pulldown und einen kleinen Filter-Kondensator verpassen. Dann verschwinden vielleicht auch die ungewollten Einschaltvorgänge jedes mal wenn der Drosselstrom umdreht. (Edit: Oh, und ich glaube du hast die Kathode der Fotodiode auf den falschen Ground gelegt? Oder täusche ich mich?)

Nein, ich hab die Optokoppler-Bastelbruderlösung eingebaut.

Zu den -10V - Hast du die Kanäle vielleicht AC-Gekoppelt? Sind deine Tastköpfe sauber abgeglichen und zusammen mit dem Oszi tauglich für die Frequenz? Wo ist da die 0-Linie, ich kanns nicht entdecken...
(Noch ein Edit: Wo klemmst du GND von den Tastköpfen an, wenn du die -10V misst?)

Nein, DC gekoppelt. Der Masse-Messpunkt ist GNDA.
GNDA habe ich jetzt auf der Platine in 1,5mm² ausgeführt, also auch da kein Spannungsabfall.
Ich hatte auch geschaut, das die Spannung richtig angezeigt wird.
Die Nulllinie ist im ersten Bild zu sehen, die "Null-Linie" sinkt mit zunehmendem Strom noch unten, bei ca. 5A hab ich da -10V.

[Bastelbruder]

Die Nulllinie läßt sich auch mit einer schnellen Diode UF4007 Kathode nach oben, einem RC-Glied 100n |100k und einem daran angeschlossenen DC-Voltmeter testen. Da kommt dann bloß minus ein halbes Volt zu wenig raus. Wenn die Diode tatsächlich so hochohmig wäre, müßte man die Schräge vom abnehmenden Spulenstrom sehen können. Da ist mit Sicherheit der Tastkopf nicht ganz korrekt.

[inse]

Beruflich hatte ich mit einem ähnliche Design zu tun, da haben wir auch Probleme an dieser Stelle untersucht.
Vermutlich verreisst es das Potential am Punkt VS im Freilauf soweit ins negative, daß der Gate-Driver ge- bzw zerstört wird.
Schau mal im Datenblatt, da findet sich eine Fußnote "Logic state held for VS of -5V to -VBS"
In unserem Design wurde der VS Pin zum Source hin mittels 4,7 Ohm entkoppelt und eine ultraschnelle Klemmdiode direkt am Gate Driver nach Masse plaziert.
Leitungsführung ist bei so einem Design mehr als kritisch.
Die Gatespannungs Messung erscheint mir unplausibel, man sieht gar kein Miller Plateau - wie ist da genau die Anbindung des Tastkopfes gemacht?
Der Masseclips am Tastopf ist bei solchen Messungen ungeeignet, besser ist mit einer Massefeder (so kurz wie möglich, also) eine lokale Masse zu kontaktieren.
Es scheint Gatestrom während des ganzen Pulses zu fließen, entweder ist die Messung Sche***, oder der Gate-Widerstand passt evtl. nicht zur Gate-Kapazität.

[Hightech]

Kann ich den GNDA mit einem MKS4 0,22µF an den Kühlkörper koppeln, welcher am Potentialausgleich hängt oder komme ich dann in die HF-Hölle?
Der GNDA geht auch in das 12V Schaltnetzteil, dort ist GND ja sicher auch mit einem Kondensator auf Masse gekoppelt.
Des Weiteren geht der GNDA auch in den PV-Wechselrichter, dort wird er über eine Sicherung auf Masse gezogen.
Ich hoffe das geht gut.
Ich werde wohl den Oszillografen mit in den Keller nehmen um zu schauen, wie es in der Wirklichkeit aussieht.

Es scheinen folgende Maßnahmen zum jetzt erst mal stabilen Zustand geführt haben, der Kühlkörper wird auch lange nicht mehr so warm wie vorher:
PWM macht ein Atmel statt der Raspi, den kann man dafür vergessen.
Frequenz auf 100kHz.
Ordentliche Drossel
Leiterbahnführung den Design-Rules angepasst, Leiterbahnquerschnitt maximiert.
Optokoppler beschleunigt.
Spannungsquellen-Kondensator eingebaut.
Kühlkörper an GNDA angekoppelt.
Glimmerscheiben statt Silikon-Pads verwendet.


Vielen Dank an Euch alle!

[Sir_Death]

...
PWM macht ein Atmel statt der Raspi, den kann man dafür vergessen.
...

nur nicht wieder vergessen für die nächsten Projekte
Raspi ist meiner Meinung nach zu 99% nur für Software-spielerein geeignet. Wenn Hardware, dann Arduino. Den kannst du dann per USB an den RASPI hängen, und der RASPI macht dir den Webserver.

[Fritzler]

Die dümmste Lösung, die ich je gelesen habe!

Der SPI, I2C und UART des RasPI sind wunderbar nutzbar zur Kommunikation.
Wenn man auf den Registern selber klimpert, dann geht auch der Hardware PWM super.
Die Libs nutzen das nur nicht, weil da der Audioausgang drauf liegt.

Genau an diesen SPI oder I2C hängt man dann ein FPGA/ARM/AVR, der die Lowlevel/Realtime Funktionen ausführt auf Befehl vom RasPI.

Das ist dann schön kompakt ohne Kabelgeraffel ala USB und extra Strom, die 3,3V/5V kannste dir nämlich auch über den GPIO Header klauen (wenn mans mitm Strom nicht übertreibt). Oder den RasPI auch direkt darüber speisen (nur über die 5V!).
Sieht dann so aus:
http://fritzler-avr.de/gallery/main.php ... _3618k.jpg

--> Hightech machts genau richtig!

[Sir_Death]

Egal wie du die beiden zusammenhängst - einig sind wir uns wohl, dass es keinen Sinn macht, den RASPI die Lowlevel Dinge direkt machen zu lassen, sondern dass dort ein AVR/ARM und Konsorten besser geeignet sind.

[E_Tobi]

Die Nulllinie ist im ersten Bild zu sehen, die "Null-Linie" sinkt mit zunehmendem Strom noch unten, bei ca. 5A hab ich da -10V.

Ich glaube dabei an auch einen Messfehler, -10V würde der IR nicht mitmachen. Wie gesagt, prüfe mal den Tastkopf-Abgleich mit einem "bekannten" Rechteck. Gerade bei ein paar hundert Volt fehlts da schnell um 10V.
So lange der IR nicht in die Luft fliegt ist an der Stelle auch kein massives Problem, würde ich sagen. Die IR-Treiber sind da eh recht robust, meiner Erfahrung nach. Von denen hab ich noch keinen kaputt bekommen, ohne dass vorher die FETs kaputt gewesen wären.
Bei manch anderen Herstellern ist das anders.

Kann ich den GNDA mit einem MKS4 0,22µF an den Kühlkörper koppeln, welcher am Potentialausgleich hängt oder komme ich dann in die HF-Hölle?

MKS würde ich da nicht nehmen, da sollte wenn dann ein entsprechender Kondensator hin.
Auch die Halbleiter musst du gut isolieren, vor allem wegen der Kriechstrecken um die Beine und die Schrauben...und auch die Abstände von der Kühlkörperbefestigung zum Kupfer der Platine müssen ausreichend sein.
Da wird ja dann im Endeffekt der PV-String gegen PE isoliert, wenn alles beisammen ist, oder? Ich weiß nicht welche Anforderungen es da genau gibt, im Solarbereich...

Frequenz auf 100kHz.
Ordentliche Drossel

Du könntest mal die Drossel auslöten und messen bei welchem Strom sie sättigt wenn sie heiß ist. Dementsprechend würde ich dann die Schaltfrequenz lieber wieder etwas niedriger wählen.
Der Treiber ist für den Mosfet ein wenig schwächlich auf der Brust...Wenn das stimmt was Bastelbruder vermutet, und die Oszillationen wirklich nur Ausschwingen sind, läuft die Drossel noch ziemlich verlustarm im Betriebspunkt.
Die könnte man evtl noch weiter aussteuern, und sich so Verluste sparen.
Dazu kommt noch, im Endeffekt wirst du nach deiner Beschreibung ohnehin immer bei sehr hohen Dutycycles umheroperieren, weil du ja nicht viel Luft zur unteren Schwelle des WR hast, das heißt der Ripplestrom wird ohnehin recht klein sein.

[ferdimh]

Egal wie du die beiden zusammenhängst - einig sind wir uns wohl, dass es keinen Sinn macht, den RASPI die Lowlevel Dinge direkt machen zu lassen, sondern dass dort ein AVR/ARM und Konsorten besser geeignet sind.

Ich bin mir da garnicht so einig... wenn man bereit ist, Kernelmodule zu bauen kann man mit einem *Pi (bisher nur mit Bananen getestet) einen Haufen Kram zaubern, der mit nem externen Controller erheblicher Mehraufwand wäre.
Ein bombensicherer Kommunikationskanal zwischen zwei Controllern (Pi und Nichtpi) ist garnicht mal so einfach. Und wenn man tiefer in die Trickkiste greift, baut man sich schnell die gleichen Probleme, die der Pi auch so gehabt hätte (Kommunikation bindet Rechenzeit, die man nicht für Echtzeitgedöhns hat).
Bei den Mehrkernern kann man sich sogar einen Kern vollständig für seine Spezialaufgaben krallen (das geht übrigens auch auf x86).

[Hightech]

Schande, Schande, Schande, Klingeling!

Ich hab am Gate gemessen, daher die -10V! *Schäm*

Heute ordentlich zweimal einen geballert bekommen, 400V zecken gewaltig!
Wieso in aller Welt zwei mal?
Tja, der erste Schocker kam total unvermutet, ich wollte was anlöten, hatte den Regel-Trenn auch runter gestellt.
Ich nahm das Lötzinn in die Hand und den Lötkolben und es wird schmerzhaft, ich konnte nicht herleiten wo das her kam.
Also nochmal genau geschaut ob noch was drinsteckt. Nix war an.
Sehr seltsam, also nochmal Lötkolben zur Hand und das Lötzinn hochgenommen, oben dann wieder volle Kanne Spannung.

Oh, man! Das schmerzt.

Was war geschehen?
Der Kühlkörper hatte 400V und der Lötdraht ist beim Hochnehmen an den Kühlkörper gekommen und anscheinend ist der Weller am Griff leicht leitfähig.

Aber wo kommen die 400V gegen Erde her am Kühlkörper? Es ist doch am Trenntrafo!

Beim festziehen des FET hat es wohl Alu-Abrieb von der Befestigungsschraube durch die Glimmerscheibe gedrückt. Also standen die 400V vom Eingangskondensator am Kühlkörper.
Das Oszi hat den GNDA auf Erde gezogen und somit hatte ich dann wohl -400V am Kühlkörper.
Das habe ich herausgefunden als ich den Kühlkörper geerdet hatte und des unter dem FET geknallt hat.

Ein kleines Problem habe ich, wie schon erwähnt wurde startet die Schaltung ohne Last nicht, ich habe schon einen Widerstand 92kOhm von VS nach Masse gezogen, aber das
funktioniert nicht.
Wie kann ich das lösen ?

[Bastelbruder]

Das ist das Manko der Highside- "Selbstversorger". Entweder ein zusätzlicher Schalter (FET) parallel zur Diode der den Ausgang auf null zieht und damit den bootstrap-kondensator füllt - das geht vermutlich nicht weil das die Ausgangsspannung kurzschließen würde. Oder die Anlaufspannung (8V) zum Anlauf per 1:1 Mini-Trafo, zwei Kondensatörchen primär und sekundär in Reihe zur Wicklung und zwei Dioden beispielsweise aus einem 5V-Rechteck vom Kleinhirn erzeugen. Da wird prinzipiell bloß der Standbystrom des Treiberchips benötigt, nach dem ersten Impuls geht das Teil wieder normal.

[E_Tobi]

Wie gesagt, wenn du wirklich beim Buck bleiben willst würde ich auf einen isolierten DC/DC zur Versorgung setzen.
Kostet ein paar Kröten, dürfte aber mit Abstand am stressfreisten ablaufen. Die paar pF Koppelkapazität die hier mitgebracht werden fallen meist nicht ins Gewicht.
Dafür kannst du dann alle Grenzen ignorieren, sowohl 100% Duty als auch Leerlauf.

[xoexlepox]

...den RASPI die Lowlevel Dinge direkt machen zu lassen, sondern dass dort ein AVR/ARM und Konsorten besser geeignet sind.

Ich bin mir da garnicht so einig...

Solange die "Steuerung" läuft, sollte das der Hardware ziemlich egal sein. Aber was ist bei/nach "Powerfail"? Ein µC ist meist recht schnell bei der Initialisierung der Ausgangsports. Wie sieht das beim RasPi mit den GPIOs beim Bootvorgang (der ja durchaus ein paar Sekunden dauern kann) aus? Ich habe es noch nicht ausprobiert, aber ein "ON" auf einem GPIO für ein paar Sekunden könnte m.E. so manche Schaltung abbrennen lassen Dabei hilft dann auch kein trickreiches Kernelmodul mehr Gibt es Spezifikationen, wie sich die GPIOs eines RasPi's beim Powerup/Bootvorgang (oder auch Shutdown) verhalten?

[Hightech]

Wie gesagt, wenn du wirklich beim Buck bleiben willst würde ich auf einen isolierten DC/DC zur Versorgung setzen.
Kostet ein paar Kröten, dürfte aber mit Abstand am stressfreisten ablaufen. Die paar pF Koppelkapazität die hier mitgebracht werden fallen meist nicht ins Gewicht.
Dafür kannst du dann alle Grenzen ignorieren, sowohl 100% Duty als auch Leerlauf.

Ach sowas hab ich in der Schublade.
Hier hab ich einen TMA 1212S der passt doch perfekt.

Ich hatte angenommen, das diese High-Side Treiber einen Wandler an Bord haben, das die nur mit dem billigen Kondensator-Aufladetrick arbeiten war mir nicht klar.

So, ist eingebaut und es geht!
Danke für den Tipp.

[E_Tobi]

Ich hatte angenommen, das diese High-Side Treiber einen Wandler an Bord haben

Das ist der nächste Schritt, kommt schon noch.

[Fritzler]

Natürlich gibts da Vorschriften.
Die GPIO haben Pullups und Pulldowns beim Bootup:
https://elinux.org/RPi_BCM2835_GPIOs

Und wenn dus rchtig derb willst, dann kannste im Devicetree die Initzustände der Pins ändern.
Dann werden die recht früh beim Linux Bootup gesetzt:
https://www.raspberrypi.org/documentati ... uration.md

Ich hatte angenommen, das diese High-Side Treiber einen Wandler an Bord haben, das die nur mit dem billigen Kondensator-Aufladetrick arbeiten war mir nicht klar.

? Das Datenblatt zeigt den IC doch ziemlich nackig.
Da ist keine Ladungspumpe reininterpretierbar.

[xoexlepox]

Natürlich gibts da Vorschriften.

Danke! Diese "Kniffe" kannte ich bisher noch nicht, und habe daher immer "Hardware" verwendet, um evtl. auftretende "seltsame Zustände" der GPIOs zu verhindern.

[E_Tobi]

Entscheidend ist der Zustand der Pins beim anlegen der Spannungsversorgung.
Ich hatte einige Schaltungen auf dem Tisch bei denen das einfach ignoriert wurde...mit mehr oder weniger fatalen Auswirkungen.

Die meisten MCUs die ich kenne machen im Init-Moment "High Z" an allen Ports. Einige Ports sind aber anders als andere, weil JTAG oder sonst was intern drauf hängt...und das ist so bis die Anwendersoftware den internen MUX umgestellt hat.
Das muss die Schaltung definieren und abkönnen, bis die Software die richtige Config hergestellt hat.
Man darf nicht vergessen dass unter all den schönen abstrahierten Layer immer irgendwo ein Hardware-Kern hängt der erst mal das macht was das Silizium sagt, bevor das Programm losläuft...

[Hightech]

Es ist nicht explodiert!
Jetzt muss es noch geregelt werden.
Urg, das wird noch lustich.
Ein raspi sammelt die Verbrauchs und Erzeugungsdaten. Diese müssen jetzt vom pwmpi gelesen werden. Der pwmpi muss dann das Tastverhältniss so anpassen dass der Verbrauch bei ca. 0W ist.
Durch die fallende Batteriespannung muss immer nachgesteuert werden. Das Mpp vom PV-WR muss ich auch noch raus rechnen.

[E_Tobi]

Nur als Vorschlag:
Ich denke es würde die Regelung stark vereinfachen wenn du, wie im anderen Thread vorgeschlagen, den bisherigen Plan abänderst und einen Boost-Wandler im Current Mode an den Akku-WR (oder direkt an die Batterie, vermutlich besser) hängst. Die PWM-ICs der UCx84x-Serie sind da prädestiniert und sehr schön zu verwenden.

Was du dann hättest wäre eine steuerbare Stromquelle, deren Strom du direkt mit einem DAC steuern kannst.
Die Strombegrenzung durch die implementierte Peak Current Mode Control würde für den WR aussehen wie ein Solarmodul, der MPPT würde sich dementsprechend so einstellen dass der Wechselrichter die Leistung aufnimmt, die du aus den Akkus ziehst.

Das einzige das du dann bräuchtest wären Slope Compensation (einfach einzubauen) und ein analoger Regler außen rum (Ausgangsspannung) falls der WR aufhört Strom aufzunehmen, aus welchem Grund auch immer. Dann muss der DAC überstimmt werden und die Ausgangsspannung kurzfristig direkt geregelt werden.

Oder, als Alternative:
Du machst unten eine Strommessung in deinen Buck rein (Shunt mit Verstärker) und nutzt auch einen UCx84x. Der Buck im Current Mode würde dir auch hier die Drossel in eine Stromquelle verwandeln, und die Regelung vereinfachen (auch wieder Strom per DAC, oder runtergefilterter PWM). Hier bräuchtest du dann ebenfalls eine Slope Compensation auf dem Strommessignal. Ungünstig ist dann der kleine Bereich den du nur zum regeln hast...

Als kleinen "Bonus" hättest du in beiden Versionen den Wandler gegen Überstromereignisse abgesichert. (Edit: Und die PWM-Erzeugung im Raspi würde natürlich komplett wegfallen.)

[Hightech]

Nur als Vorschlag:
Ich denke es würde die Regelung stark vereinfachen wenn du, wie im anderen Thread vorgeschlagen, den bisherigen Plan abänderst und einen Boost-Wandler im Current Mode an den Akku-WR (oder direkt an die Batterie, vermutlich besser) hängst. Die PWM-ICs der UCx84x-Serie sind da prädestiniert und sehr schön zu verwenden. (Edit: Und die PWM-Erzeugung im Raspi würde natürlich komplett wegfallen.)

Ich werde das nächste Projekt sicher mit einem UCx anfangen!
Aber dieses wird vorerst so laufen, es sei denn die Ergebnisse sind nicht akzeptabel.
Ich hoffe trotzdem auf eure Unterstützung, ohne euch lieben Leute wäre ich nicht so weit gekommen!

Die PWM macht ein Attiny 45, der kann das besser .

[Hightech]

Immer noch ohne Explosion, die Regelung auf ca. Null funktioniert relativ gut.




Die 800Ah Blei-Gel werden bis 11,8V entladen und bis 13,8V wieder geladen.
Bevor der Akku nicht wenigstens 12,5V Spannung hat, wird der Wechselrichter nicht wieder zugeschaltet.

Für 250,- habe ich mir ein iBreeze-500-Windrad gebraucht geschossen, das werde ich an den Akku häklen. Mals sehen was das bringt.
Die 296Ah NiCd muss ich jetzt noch integrieren, ein Hochstrom-Lader habe ich für die Teile, leider ist ja die Spannung zu hoch um die NiCd parallel an die BP-Akkus
zu hängen.
Oder ich bau mir nen Buck dafür ...

[Hightech]

Hier der Blick auf den Verhau:

[E_Tobi]

Sehr nice!

Wie hast du die Regelung nun ausgeführt? PWM nachstellen, messen, PWM nachstellen, messen, usw?

[Hightech]

Sehr nice!

Wie hast du die Regelung nun ausgeführt? PWM nachstellen, messen, PWM nachstellen, messen, usw?

Ganz richtig:

Code: Alles auswählen

if power < -50:
                print "zu viel!"
                duty=duty-4
                if duty < 5:
                        duty=5
                        print duty
        if power > 50:
                print "Zu wenig!"
                duty=duty+4
                if duty > 200:
                        duty = 200
        cmd = "i2cset -y 1 0x1a 1 "+str(duty)

"power" ist die Anzeige vom Stromzähler, gemittelt über 10 Werte, nach 10 Sekunden.