alternatives Treiberkonzept für DRSSTC

[Netzpfuscher]

Ich habe die Software vom UD3 und den Schaltplan Das läuft auf einem Psoc5. Ich sage nur so viel, da steckt ne menge Voodoo drin *g*

https://docs.google.com/document/d/1Bm- ... 02qUsA/pub

[zeeman]

Wow danke Netzpfuscher fürs zeigen. Ein wahrlich kompliziertes Biest. Bin mal gespannt ob die Profis hier die ein oder andere Anregung darin finden...
Das Pulseskipping ist doch etwas andees als ich mir das vorgestellt habe

Hast du eigentl. pläne mit dem Ding oder nur aus Interesse mal besorgt??
Grüsse Zeeman

[Netzpfuscher]

Das Feedback ist pfiffig, da braucht man nurnoch einen CT. Das sollte auch mit nem konventionellem Treiber gehen.

[Physikus74]

Hallo Zusammen,
hoch interessant, das Teil. Wir sehen, dass viel Funktion in der Software steckt. Der Schaltungsaufwand ist deutlich geringer geworden.
Aus dem CT wird das eigentliche, klassische Feedbacksignal "CTout" abgeleitet, aber auch noch die Signale "ZCDA" und ZCDB". Damit wird erkannt, in welcher Halbwelle, der positiven, oder negativen sich das System gerade befindet.
Dazu passt auch die separate Ansteuerung der beiden GDT's. Wenn ich das richtig verstanden habe, kann so bei erreichen des maximalen Stromes durch entsprechendes Schalten einer Halbbrücke ein "Freilaufen" diesen abbauen und die überschüssige Energie zurück in den Elko pumpen. Da dürften aber noch eine Menge anderer rafinierter Sachen drinstecken... Jedenfalls: Hut ab!
Ich bin auch schwer beeindruckt, dass das Teil unmittelbar an der Spule mit verschiedenen galvanischen Verbindungen, z.B. zum Messen der verschiedenen Spannungen funktioniert. (Ich denke, das können wir als Tatsache zur Kenntnis nehmen...) Bei Max ist der Arduino durch Eigen-EMV im Treiber ausgestiegen. Gut, der "nicht-takt-synchrone Teil in dem SoC wird dadurch vielleicht nur vorübergehend gestört, das ARM wird aber empfindlicher sein. Das kann nur bedeuten, dass da jemand beim Layout der Platine viel richtig gemacht haben muss.
Jedenfalls bekomme ich richtig Lust, das weiter oben beschriebene Projekt anzugehen und meine Programmierversuche, bei denen ich vor einem guten Jahr "abgestorben" bin wieder auszugraben.
Hier kommt ein kleiner Eindruck von der damals erreichten Oberfläche:

Teslaoberflaeche.JPG (89.11 KiB) 2502 mal betrachtet

Mit dem Wissen von heute wird sich das aber sicher noch einmal ganz und gar verändern. ...und vor allem wird es eine Weile dauern, bis ich da wieder durchsteige...
Viele Grüße,
Physikus

[ferrum]

Es gibt einen sehr guten grund warum in einer DRSSTC bis jetzt kaum UC's verbaut wurden. Ich hab jetzt schon einige Versuche beobachtet wo das schief gegangen ist. Der EMV neben der endstufe ist schon extrem aber nicht nur die macht Probleme auch zum Beispiel der Treiber selbst kann enorm auf die Versorgung einstreuen. Die meisten aktuell verfügbaren uC sind nicht dagegen gehärtet was dazu führt dass auf z.T. nicht Messbare(wg. Bandbreite oder Amplitude) Einstreuungen Stören. Das rustikale CMOS was hier meistens in den Treibern verwendet wird kann solche Störungen dagegen meistens getrost ab. Die Idee mit Toslink Leitungen zu Steuern wird auch nicht funktionieren da in größeren Abständen zwar nicht das B-Feld aber dafür das E-Feld Stört. Von Betriebssicherheit bei solchen extrem Zeitkritischen Vorgängen will ich gar nichts sagen.
lg Flo

[Physikus74]

Hi Flo,
wie wir schon von Zeeman und Max erfahren haben, kommt das meiste "EMV-Unheil" über das Massesystem im Treiber, und sicher haben wir es in der Gegend, kurz unter der Primärspule, die auch ganz gut als Induktionskochplatte funktioniert mit einem anständigen H-Feld zu tun. (Siehe das Brutzeln, was Max bei Versuchen am Aluminiumrahmen seiner Spule beobachtet hat...)
Wegen dem E-Feld mache ich mir keine so großen Sorgen: Meine besagte "kleine Spule" produziert immerhin auch Schlagweiten von etwa 1m. Mein Interrupter funktioniert mit einem 16bit Renesas-Controller, der sogar über ein Kupferkabel angebunden ist. Die Schaltung ist in eine Keksdose aus Blech eingebaut und macht keine Zicken.

Viele grüße,
Physikus

[Thunderbolt]

Hier mal mein vorschlag für Synchronisiertes wiedereinschalten nach pulse-skip
ohne gewähr

[Mastermuffel]

Eignen sich eigentlich solche für sowas?:
http://www.analog.com/library/analogDia ... river.html
http://www.analog.com/en/products/inter ... m3223.html
http://www.analog.com/en/products/inter ... m4223.html

[Physikus74]

Hallo Zusammen,
ich habe eben erst nach einer größeren Pause wieder einen Blick ins Forum geworfen. Hier ist ja kräftig diskutiert worden!

Also,
@Thunderbolt: Ich habe eben versucht hinter Deine Schaltung zu steigen. Dazu liegt ausgedruckt der Plan vom UD2.7 neben mir.
Wenn ich Dich richtig verstehe ist in Deiner Skizze der untere Pfad, der bereits vorhandene.
Der Darüberliegende soll im Falle einer Unterbrechung durch "Pulseskipping" einen ungewollten "Ping" unterbinden, richtig?
Beide Flipp-Flopps verhalten sich invertiert, da SET und RESET in ihrer Ansteuerung vertauscht sind. (Anschluss vor, bzw. nach Schmitt Trigger)
Durch den weiteren invertierten Trigger erhalten wir eine weitere Negation. Wenn ich das richtig verstehe, soll das Signal so um etwa eine Periode verzögert werden.
Dazu werden zum Schluss mit IC5D beide Flipp-Flopp-Ausgänge "verundet". Haut das inetwa hin?
Unklar ist mir noch, wo die "Stellschraube" um die Dauer des "Aussetzers" einzustellen sein soll.
Ach ja, die ganze Geschichte ist ja flankengetriggert. Das Schalten der Flipp-Flopps ist damit nahezu gleichzeitig, nur die Gatterlaufzeit des einen Schmitt Trigger bringt einen kurzen zeitlichen Versatz...

Noch was zur Controller-Variante:
Ein Arduino-DUE (...weil pfeil-schnell mit ARM-MCU...) liegt schon hier. LWL-Komponenten sind bestellt. Auch wenn es sich zeitlich sicher etwas hinziehen wird, werde ich versuchen damit nach dem schon beschriebenen Konzept etwas aufzubauen. Die Sicherheitsrelevanten Sachen wie OCD und Schaltpunkt im 0-Durchgang sollen dabei in LOGIK-Hardware an Ort und Stelle unverändert bleiben.

Sorry, fast vergessen:
@Mastermuffel:
Rein theoretisch würden die Treiberlinge funktionieren, Du müsstest ihnen an der "high-side" jeweils nur eine galvanisch getrennte Spannungsversorgung spendieren. So etwas ähnliches habe ich diskret aufgebaut vor 6 Jahren bei meiner MIDI-DRSSTC gemacht.Dabei sind die Ansteuerseite und die Treiber inklusive der IGBTs räumlich auch voneinander getrennt und per LWL verbunden.
Ich bin mir nicht sicher, ob es bei diesen Bausteinen, wo beide seiten nur eun paar µm voneinander auf einem Chip getrennt sind zur ungewollten Effekten kommt...


In dem Sinne einen schönen Abend,
Physikus74

[Thunderbolt]

Hallo Zusammen,
ich habe eben erst nach einer größeren Pause wieder einen Blick ins Forum geworfen. Hier ist ja kräftig diskutiert worden!

Also,
@Thunderbolt: Ich habe eben versucht hinter Deine Schaltung zu steigen. Dazu liegt ausgedruckt der Plan vom UD2.7 neben mir.
Wenn ich Dich richtig verstehe ist in Deiner Skizze der untere Pfad, der bereits vorhandene.
Der Darüberliegende soll im Falle einer Unterbrechung durch "Pulseskipping" einen ungewollten "Ping" unterbinden, richtig?
Beide Flipp-Flopps verhalten sich invertiert, da SET und RESET in ihrer Ansteuerung vertauscht sind. (Anschluss vor, bzw. nach Schmitt Trigger)
Durch den weiteren invertierten Trigger erhalten wir eine weitere Negation. Wenn ich das richtig verstehe, soll das Signal so um etwa eine Periode verzögert werden.
Dazu werden zum Schluss mit IC5D beide Flipp-Flopp-Ausgänge "verundet". Haut das inetwa hin?
Unklar ist mir noch, wo die "Stellschraube" um die Dauer des "Aussetzers" einzustellen sein soll.
Ach ja, die ganze Geschichte ist ja flankengetriggert. Das Schalten der Flipp-Flopps ist damit nahezu gleichzeitig, nur die Gatterlaufzeit des einen Schmitt Trigger bringt einen kurzen zeitlichen Versatz...

die "Stellschraube" für die verzögerung sind die RC-Glieder.

das obere flipflop synchronisiert den ausschaltvorgang, das obere den einschaltvorgang auf das taktsignal um zu vermeiden, dass im strommaximum geschaltet wird.
in der ursprunglichen schaltung ist die synchronisation nur für den ausschaltvorgang, der ja auch wesentlich kritischer ist da der strom hier maximal ist

Das ganze funktioniert so (beispiel einschaltvorgang), dass das flipflop zunächst über die preseteingänge (/SET: 1, /RESET: 0) ausgschaltet ist, wenn das einschaltsignal kommt wechsen die preset eingänge auf (/SET:1, /RESET: 1) -> Flipflop behält den aktuellen zustand. wenn jetzt ein taktimpuls reinkommt wird das flipflo gesetzt (an D liegt permanent high-pegel an), wenn nicht wechseln die eingänge nach abluft des RC-Gliedes zu (/SET: 0, /RESET: 1) und das flipflop wird gesetzt, wenn es davor schon durch einen taktimpuls gesetzt wurde passiert halt nix.

[Physikus74]

Hallo Thunderbolt,
ich hoffe, ich habe Dich jetzt richtig verstanden:
Deine Schaltung ergänzt die alte um die Funktion des synchronen Einschaltens.
Für das Unterbrechen, auch wärend der "On-Time" wäre damit als Zusatzaufgabe der Interrupter zuständig. Soweit richtig?
Das würde so lange prima funktioneren, wie Energie im Schwingkreis ist und damit auch Feedback-Impulse kommen.
Wie steht es aber um den Anlauf nach einer regulären "Off-Time"? Jetzt müsste man doch wieder den initalen "Ping" zum Anschieben der Schwingung erzeugen.
Vielleicht hast Du das ja auch schon in Deiner Schaltung bedacht und ich hab's übersehen...


Viele Grüße,
Physikus74

[Thunderbolt]

Hallo Thunderbolt,
ich hoffe, ich habe Dich jetzt richtig verstanden:
Deine Schaltung ergänzt die alte um die Funktion des synchronen Einschaltens.
Für das Unterbrechen, auch wärend der "On-Time" wäre damit als Zusatzaufgabe der Interrupter zuständig. Soweit richtig?
Das würde so lange prima funktioneren, wie Energie im Schwingkreis ist und damit auch Feedback-Impulse kommen.
Wie steht es aber um den Anlauf nach einer regulären "Off-Time"? Jetzt müsste man doch wieder den initalen "Ping" zum Anschieben der Schwingung erzeugen.
Vielleicht hast Du das ja auch schon in Deiner Schaltung bedacht und ich hab's übersehen...


Viele Grüße,
Physikus74

Moin,

Für den part mit dem initialen "ping" sind die beiden RC-Glieder zuständig. für den fall, dass nach x us kein impuls vom feedback kommt weil keine energie im system ist wird einfach auf gut glück ein oder ausgeschaltet
Sinnvollerweise legt man die zeit auf etwas mehr als eine periodendauer fest

[Physikus74]

...das klingt nach der Lösung, die sich Max gewünscht hat!
Bleibt noch die Frage, wie man die neue Funktion Seitens Interrupter "dosiert". Ich schätze, das läuft auf direktes Probieren hinaus:
Eine "Lücke in die "On-Time" einbauen und dies dann schritt für Schritt größer werden lassen...

[Physikus74]

Hallo Zusammen,
heute möchte ich die angekündigte Idee mal etwas konkreter werden lassen:
Das Ganze beruht zu weiten Stücken auf dem UD2.7. Die meisten sicherheitsrelevanten Funktionen sollen unverändert in Hardware bleiben. Die Besonderheit ist, dass das Feedbacksignal abgegriffen und optisch zur Steuerung übertragen wird. Das verarbeitete Feedback kommt nachher ebenfalls auf optischen Wege wieder zurück. Das Interruptersignal wird nach wie vor per LWL geliefert.

Der Interrupter wird dabei zur Steuerung und bekommt einen Microcontroller, z.B. in Form eines ARDUINO DUE spendiert. Die Bedenken in Bezug auf Störungen möchte ich mit 10m LWL und geschirmten Gehäuse zerstreuen.

Bedient wird die Steuerung per Oberfläche auf einem PC, bzw. Laptop.

Mit der Anordnung kann nun gezielt aus der Ferne mit den Verzögerungswerten "gespielt" werden, die im UD2.7 von der Spule "L1" bestimmt werden. (Phase lead)

Ebenfalls wäre das "Pulse skipping" recht bequem per Software zu konfigurieren.

Wenn man dann noch etwas mehr in die Software einsteigt, sollte auch eine Audiomodulation direkt auf dem Weg realisierbar sein.

Die beiden angefügten Dateien zeigen schematisch die angedachten Eingriffe am UD2.7 und das Gegenüber, den "erweiterten Interrupter".

Was meint Ihr dazu?


Viele Grüße,
Physikus

[MaxZ]

Morgen!


Hab lange nicht hier reingeschaut.

@Thunderbolt: da ich keine Bastelgelegenheit habe im Moment, wollte ich es simulieren, bin aber kläglich gescheitert...Kurz: ich weiß noch nicht, ob deine Schaltung tut, was sie soll.

@Physikus74: Die Idee mit dem Arduino verfolgte ich ja auch, nur ganz leicht anders. Das Problem ist die Zeit - zumindest bei den AVRs; beim Due mag das Problem geringer sein. Nehmen wir ein 100kHz Signal, dann haben wir eine Periode von 10us und müssen alle 5us schalten. Nimmt man die Interruptbibliothek, die mit der Arduino IDE mitkommt, so dauert es bereits locker 40 Taktzyklen von der Signalflanke bis zum Starten der Interruptroutine. Das sind bei 16MHz schon 2,5us. Selbst wenn man in AVR Interrupts programmiert, braucht es noch locker 10 Taktzyklen, was 0,6us entspricht. Beides ist zu langsam für ein "sofortiges" reagieren. Der Arduino muss also aufgrund der jetztigen Flanke seine Aktion für die nächste Flanke entscheiden, wofür ihm bestenfalls 4,4us bleiben. Möchte man dann auch noch MIDI o.ä. einbauen, wird's noch enger in der Zeit, da dafür ebenfalls Interrupts gebraucht werden.
Auch wenn nicht alle DRSSTCs auf 100kHz laufen, so sind es doch genügend. Und von QCWs, die gerne auch Frequenzen von 400kHz erreichen reden wir gar nicht.

Nachdem die im 4hv-Forum sich auch mehr und mehr mit der gleichen Frage beschäftigen, hat man dort inzwischen eine Modifikation für den UD2.x veröffentlicht: http://4hv.org/e107_plugins/forum/forum ... php?178230

Interessant ist ja, dass Freewheeling/Freilaufen/Pulseskipping nicht wie ich dachte auf eine Stromrampe abzielt, sondern auf einen konstanten Primärstrom. Die Frage die sich mir nun aufdrängt ist: warum muss man dann noch was am UD2.x modifizieren? Die OCD reicht doch dafür?
Auf jeden Fall werde ich wohl sobald nicht mehr an meiner Arduinosoftware arbeiten, wenn es scheinbar eine so einfache Lösung gibt.


Liebe Grüße,
Max