Hallo, habe bei der Simulation von IGBT`s in LTspice öfter das Problem, dass spice unerklärliche Spannungsspitzen produziert. Diese treten willkürlich auf (Bei jedem run anderst). Zudem rechnet LTspice ewig an diesen Spitzen und selbst beim hineinzoomen sind diese nur ein gerader Stich. Gibt es z.B. einen Parameter in LTspice um diese Spitzen während der Simulation zu filtern o.Ä.? Die Toleranzen zu verringern hilft nur sehr bedingt und die Rechenzeit erhöht sich um ein Vielfaches. Vielen Dank im Voraus für eure Hilfe!
Angehängte Dateien:
-
Spikes.JPG
94 KB
Evtl. eine Überschneidung mit anderen Schaltvorgängen? Wenn es sich beispielsweise um eine Brückenschaltung handelt, hast du da an die Totzeiten gedacht? Was wird bei dir geschalten? Zeig mal die Schaltung (Auszug des wesentlichen Teils) und sag, an welchem Punkt du misst.
>hast du an Gate einen Vorwiderstand, so ca. 100 Ohm? Vorwiderstand ja aber "nur" 2 Ohm wie in der realen Anwendung > Evtl. eine Überschneidung mit anderen Schaltvorgängen? > Wenn es sich beispielsweise um eine Brückenschaltung handelt, hast du da > an die Totzeiten gedacht? > Was wird bei dir geschalten? Zeig mal die Schaltung (Auszug des > wesentlichen Teils) und sag, an welchem Punkt du misst. Das Bild ist der Spannungsabfall über einen äußeren IGBT. Es handelt sich um einen 3 Level NPC. Totzeiten, Schaltversatz, Schaltflanken,... wurde alles berücksichtigt und die Schaltung funktioniert wie gewünscht. Es handelt sich hierbei aber definitiv nicht um reale Spikes sondern um Simulationsfehler. Die Spikes sind nur einen Simulationsschritt lang. Lediglich treten ZUFÄLLIG Spikes auf und Spice rechnet eine Ewigkeit an diesen herum bis es aufgibt und einen vertikal Strich zeichnet. Brauche "nur" eine Möglichkeit um Spice daran zu hindern solche Rechenfehler zu plotten..
Es kommt vor dass LTSpice sich an Transienten im FemtoSec-Bereich tot rechnet. Ursache ist meistens der ideale, d.h. wirklichkeitsfremde Schaltplan. Oft hilft es, ein paar parasitäre Elemente einzubauen, z.B. Spannungsquellen mit einen Innenwiderstand Kondensatoren mit einen ESR Dioden, denen ein realer Typ als Modell zugewiesen wurde usw usf
Michael M. schrieb: >>hast du an Gate einen Vorwiderstand, so ca. 100 Ohm? > Vorwiderstand ja aber "nur" 2 Ohm wie in der realen Anwendung Mach ihn doch höher um zu sehen ob die Spitzen immer noch da sind.
Mark S. schrieb: > Es kommt vor dass LTSpice sich an Transienten im FemtoSec-Bereich tot > rechnet. Ursache ist meistens der ideale, d.h. wirklichkeitsfremde > Schaltplan. Oft hilft es, ein paar parasitäre Elemente einzubauen, z.B. > Spannungsquellen mit einen Innenwiderstand > Kondensatoren mit einen ESR > Dioden, denen ein realer Typ als Modell zugewiesen wurde > usw usf Ja genau diese Fehler treten erst im fs Bereich auf. Der Schaltplan ist so real wie es nur geht. Selbst Kleinigkeiten wie die Zuleitungsinduktivitäten von den Kondensatoren sind modelliert. Bei den IGBT`s verwende ich auch ein "reales" Modell. Die einzigen "hart" schaltenden Elemente sind zwei SR FF`s mit Schmitt Trigger am Eingang. Diese steuern aber nur eine behavioral voltage source welche über einen 2Ohm Widerstand am Gate des IGBT liegt. Werde aber auf deinen Rat hin an die Ausgänge der FF noch ein RC hängen um auch diese Flanken zu verzögern >Mach ihn doch höher um zu sehen ob die Spitzen immer noch da sind. Ja sind sie. Zudem MUSS die Simulation mit der realen Schaltung durchgeführt werden da diese sonst ihre komplette Aussagekraft verliert..
Du kannst ja mal die option gear versuchen. .options method=gear Oder das hier. Da wird an jeden Knoten eine Kapazität nach masse geschaltet. Das ist ist aber "Teufelszeug" da es Nebenwirkungen hat. .options cshunt=1e-16
Sind parasitäre Induktivitäten dabei? Mir ist mal ähnliches passiert mit einer lib von Varistoren. Dort haben die parasitären Induktivitäten solche Probleme breitet. Fakt ist, dass es die Spikes in der Realität nicht gegeben hätte.
Helmut S. schrieb: > Du kannst ja mal die option gear versuchen. > > .options method=gear > > > > Oder das hier. Da wird an jeden Knoten eine Kapazität nach masse > geschaltet. Das ist ist aber "Teufelszeug" da es Nebenwirkungen hat. > > .options cshunt=1e-16 Von dem "Teufelszeug" lass ich lieber die Finger wobei die Auswirkungen auf eine sehr niederohmige Leistungsschaltung wahrscheinlich vernachlässigbar wären. Die Alternative Integrationsmethode scheint die Lösung zu sein. Zumindest sind in den Zwischenzeitlich simulierten 10ms noch keine Spikes aufgetreten. Obwohl der Vorwiderstand der Gates + deren Kapazität schon ein RC TP ist, hat der zusätzliche TP davor die Simulation der Schaltvorgänge um ein Vielfaches beschleunigt und es kann zusätzlich die Flankensteilheit der Gatetreiber simuliert werden.
Gear dämpft halt auch alle anderen realen Schwingungen, da würde ich lieber bei Modified Trap bleiben und die Spikes ignorieren oder im Post-Processing die entsprechenden Datenpunkte löschen.
Schpeis schrieb: > Gear dämpft halt auch alle anderen realen Schwingungen, da würde ich > lieber bei Modified Trap bleiben und die Spikes ignorieren oder im > Post-Processing die entsprechenden Datenpunkte löschen. Meines Wissens nach ist Gear die Standardmethode in PSPICE. Die Methode GEAR is OK. Einzig bei Oszillatoren mit schwacher Mitkopplung gibt es da Probleme. Die Methode "modified trap" ist genauer, aber wenn die mal ausnahmsweise Probleme macht, dann kann man es auf jeden Fall mit Gear versuchen.
:
Bearbeitet durch User
Helmut S. schrieb: > Meines Wissens nach ist Gear die Standardmethode in PSPICE. Warum steht dann im Helpfile von LTspice folgendes?
1 | Keyword Default Description |
2 | method trap Numerical integration method, either trapezoidal or Gear |
Oder ist damit was anderes gemeint?
Schpeis schrieb: > Gear dämpft halt auch alle anderen realen Schwingungen, da würde ich > lieber bei Modified Trap bleiben und die Spikes ignorieren oder im > Post-Processing die entsprechenden Datenpunkte löschen. Ab welcher Frequenz werden die Schwingungen gedämpft? Zumindest in meinem Fall sind selbst noch die 110MHz Schwingungen von den IGBT Induktivitäten bei jedem Schaltverhalten sichtbar. Habe zwar (noch) nicht nachgemessen ob diese immer noch die selbe Amplitude haben wie bei trap aber gefühlsmäßig schon. Hast du hierfür Unterlagen o.Ä.? Da es hierbei um eine Abschlussarbeit geht würde ich es gerne sauber Dokumentieren
Aber auch hier: solange er Schaltplan geheim bleibt, ist die ganze Diskussion Kaffeesatzleserei.
Angehängte Dateien:
-
gear.JPG
62 KB -
modified_trap.JPG
65 KB -
trapezoidal.JPG
64 KB
Gästchen schrieb: > Aber auch hier: > solange er Schaltplan geheim bleibt, ist die ganze Diskussion > Kaffeesatzleserei. Wie bereits im Startbeitrag beschrieben treten diese Spannungsspitzen willkürlich auf. Diese sind nicht auf ein "reales" Problem wie z.B. Gatewiderstände zurückzuführen sondern sind Simulationsfehler von LTspice. Bei der Schaltung handelt es sich um eine Abschlussarbeit und diese darf nicht veröffentlicht werden, würde bei diesem Problem aber auch nicht helfen. Das Problem wurde bereits einzig und allein durch die alternative Integrationsmethode Gear gelöst. @Schpeis Zumindest in meiner Schaltung kann ich keine Nachteile der unterschiedlichen Methoden erkennen. Trotzdem vielen Dank für den Hinweis.
Michael M. schrieb: > Bei der Schaltung handelt es sich um eine Abschlussarbeit und diese darf > nicht veröffentlicht werden Sorry, das habe ich überlesen, dafür habe ich das Verständnis. > würde bei diesem Problem aber auch nicht > helfen. Das sehe ich allerdings anders: erst wenn man die Schaltung sieht, hat man ganz andere Chancen das Problem zu lösen, auch andere Ideen.
Zum Thema gear vs. Trapezoidal: http://www.linear.com/solutions/5739 Ist natürlich klar, dass LTspice auf der Konkurrenz rumtrampelt. Daher mit etwas Skepsis lesen. Entscheidende Stellen dennoch: "But Gear integration doesn’t just dampen numerical ringing, it dampens all ringing, even physical ringing, making it possible for a circuit that malfunctions in real life, due to an oscillation, to simulate as perfectly stable and functional because the instability was damped out of numerical existence." "PSpice’s documentation states that it uses a modified Gear method and does indeed seem better at picking a small enough time step to reduce the error than the Gear integration implementation in Berkeley SPICE." "The nature of the error of Gear integration is to make circuits look more stable in simulation than they actually are in real life."
Michael M. schrieb: > Wie bereits im Startbeitrag beschrieben treten diese Spannungsspitzen > willkürlich auf. Diese sind nicht auf ein "reales" Problem wie z.B. > Gatewiderstände zurückzuführen sondern sind Simulationsfehler von > LTspice. Mich plagt dasselbe Problem bei einer in gewissem Maße vergleichbaren Aufgabenstellung (Schalten von Netzspannung mit FETs in einem insgesamt größeren Aufbau). Diese Spikes sind völlig unphysikalisch, sie treten zufällig auf, mit angeblichen Strömen bis in den Kilo-Ampere-Bereich oder Spannungsimpulsen an harmlosen Knoten, die die Betriebsspannung überschreiten und schon deshalb unmöglich sind. Mit Überschwingern oder realem Schaltungsverhalten hat es nichts zu tun. Die tatsächlich auftretenden Ströme in der simulierten Schaltung liegen Größenordnungen darunter. Mit unzureichender Modellierung der Schaltung hat es auch eher nichts zu tun. Alle Kapazitäten haben sinnvolle Innenwiderstände, es gibt nur eine Induktivität, deren Parameter sind vernünftig gewählt und die ist nicht die Ursache. Der Rest sind Widerstände und Standard-Bauteile, deren Modelle natürlich fehlerbehaftet sein könnten, aber darauf habe ich keinen Einfluss, die kommen von den Halbleiterherstellern und sind nun mal so. Wenn diese Spikes auftreten, erlebe ich es oft (aber nicht immer), dass die Simulation mit dem berüchtigten "time step too small"-Fehler abbricht (wobei der Spike und der Abbruch nicht zusammenfallen müssen). Das Internet ist voll von Tips und (meist ergebnislosen) Diskussionen dazu, es ist eine andere Baustelle, aber der Verdacht liegt nahe, dass beide etwas miteinander zu tun haben könnten. Ich neige wie Michael M. zu der Auffassung, dass es sich dabei um einen Software-Bug handelt, eventuell getriggert von Situationen, wo LTSpice ohnehin Probleme hat ("... too small"). Meine aktuelle und derzeit (heute Nachmittag) mäßig erfolgreiche Strategie dagegen sieht so aus: integration: gear solver: alternate cshunt 1e-14 gmin 1e-10 abstol 1e-10 reltol 0.003 trtol 7 Subjektives Empfinden: alle diese Parameter haben etwas gebracht, trtol war der wichtigste. Und dazu noch eine "irre" Beobachtung: die Simulation läuft durch, wenn ich an einer Stelle einen idealen OpAmp verwende. Verwende ich dort den realen TLV170, bekomme ich den "time step .."-Fehler, aber an einem FET, der weit davon weg ist in der Schaltung und von dem OpAmp überhaupt nichts weiß. Ich bin jetzt erst einmal froh, dass ich nicht allein bin und außer mir noch jemand über dieses Phänomen gestolpert ist. Noch schöner fände ich es, wenn jemand mit mehr Wissen über Simulationen als ich eine kompetente Anleitung geben könnte, wie man LTSpice bei dieser Art von Aufgabenstellungen (Netzspannung, FETs und Ströme im Ampere-Bereich) zur zuverlässigen Arbeit bewegen könnte. Fazit ohne wirkliche Lösung, mein laienhafter Eindruck ist a) es ist ein echter Bug in LTSpice b) der gesamte vorgegebene Parametersatz ist für Simulationen im genannten Spannungs- und Leistungsbereich nicht optimal.
Man könnte es ja in einem anderen SPICE mal nachbauen bei Verwendung der gleichen Modelle. Wenn es dort dann nicht auftritt, hat LTspice ein Problem. Das Phänomen kennt bestimmt jeder von LTspice. Meist erledigt es sich bei einem kleinen Umbau von was auch immer in der Schaltung. Ist nicht vorhersehbar und tritt gerne auf, wenn extreme Dynamikbereiche auftreten. LTspice hat auch noch diverse Bugs. Schön wäre es, wenn man dem Programm sagen könnte, bis zu welcher Frequenz es überhaupt simulieren soll.
Dieter R. schrieb: > Ich bin jetzt erst einmal froh, dass ich nicht allein bin und außer mir > noch jemand über dieses Phänomen gestolpert ist. Noch schöner fände ich > es, wenn jemand mit mehr Wissen über Simulationen als ich eine > kompetente Anleitung geben könnte, wie man LTSpice bei dieser Art von > Aufgabenstellungen (Netzspannung, FETs und Ströme im Ampere-Bereich) zur > zuverlässigen Arbeit bewegen könnte. > > Fazit ohne wirkliche Lösung, mein laienhafter Eindruck ist > > a) es ist ein echter Bug in LTSpice > b) der gesamte vorgegebene Parametersatz ist für Simulationen im > genannten Spannungs- und Leistungsbereich nicht optimal. Du bist bei weitem nicht alleine. Such einfach mal nach LTSpice + IGBT hier im Forum, und du siehst, dass nahezu jeder Leistungselektroniker damit zu kämpfen hat. Das ist eine sehr unglückliche Kombination. Ich habe in meinen mehreren Jahren Berufserfahrung in der Leistungselektronik viele Schaltungen aufgebaut und vermessen. Ich weiß oft, was in der Messung zu erwarten ist, und meistens stimmen meine Messungen mit meinen Erwartungen überein. Wenn ich allerdings versuche, dasselbe in LTSpice abzubilden, kommen irgendwelche Artefakte auf, die nichts mit der Realität zu tun haben. Ich bin an dem Punkt angekommen, LTSpice für die Leistungselektronik sein zu lassen. Ich habe ohnehin nie den wirklichen Sinn dahinter verstanden... Gruß,
> Autor: Dieter R. (drei) > a) es ist ein echter Bug in LTSpice Schreib doch einen bug-report an Mike (Entwickler von LTspice). Die email Adresse steht in Help->About.
Helmut S. schrieb: >> Autor: Dieter R. (drei) >> a) es ist ein echter Bug in LTSpice > > Schreib doch einen bug-report an Mike (Entwickler von LTspice). Die > email Adresse steht in Help->About. Mach ich gerne, muss allerdings erst einmal die NDA-Frage klären. Unabhängig davon: ich habe jetzt nur LTSpice zur Verfügung. Hat jemand eine Empfehlung für einen Simulator, der erstens bezahlbar ist und zweitens grundsätzlich und erfahrungsgemäß für solche Aufgabenstellungen besser geeignet? Das Wissen, dass andere ähnliche Probleme haben, bringt mich ja nicht weiter. Mike Engelhardts Lösung wird, wenn denn eine kommt, wohl dauern - schließlich füllt das Thema (time step ...) seit Jahren die diversen Internet-Foren, es dürfte ihm also nicht unbekannt sein. Nachsatz 1: ich arbeite zur Zeit mit Circuitstudio. Das gibt eine Vorstellung von der Größenordnung, die ich als bezahlbar empfinden würde. Nachsatz 2: auch Circuitstudio beinhaltet wohl einen Simulator. Allerdings finde ich keine Dokumentation dazu, ich weiß nicht, wie ich den zum Laufen bringe. Für Hinweise wäre ich dankbar. Im Moment habe ich allerdings den Eindruck, dass ich bei der Verwendung dieses Simulators Pionierleistungen erbringen müsste, ich suche aber eher nach einer verfügbaren Lösung.
:
Bearbeitet durch User
TINA gibts doch in einer Free-Version. Aber ich weiß nicht wo der Unterschied zur Professional-Version ist. Der SIMETRIX-Simulator ist auch nicht schlecht. Mir persönlich ist das aber zu viel Aufwand und ich möchte die Vorzüge von LTspice einfach nicht missen.
:
Bearbeitet durch User
Abdul K. schrieb: > TINA gibts doch in einer Free-Version. Aber ich weiß nicht wo der > Unterschied zur Professional-Version ist. > Der SIMETRIX-Simulator ist auch nicht schlecht. > > Mir persönlich ist das aber zu viel Aufwand und ich möchte die Vorzüge > von LTspice einfach nicht missen. Jetzt bin ich ehrlich gesagt angepisst - nicht von Abdul K., sondern von meinen heutigen Erlebnissen: 1. Die Vorzüge von LTSpice nützen mir nichts, wenn es crasht. Genau das ist das Thema dieser Diskussion, einschließlich der offenbar branchenweit bekannten mangelnden Eignung für Power-Simulationen. 2. TINA scheint mir nach kurzem Antesten doch eher etwas für den Ausbildungsbereich in der Berufsschule zu sein, wenn überhaupt. Vernünftige Ausgaben kann man damit jedenfalls nicht erzeugen, es gibt nur ein eher lächerliches (oder sagen wir mal, unprofessionelles) Pseudo-Oszilloskop. Oder habe ich da etwas grundlegendes übersehen? 3. Simetrix gibt es in einer Evaluierungs-Version von der Hersteller-Website und in (mindestens) 3 Free-Versionen von diversen Halbleiter-Herstellern. Erfreulich. das Benutzer-Interface ist etwas ungewohnt, wenn man von LTSpice kommt, aber man findet sich schnell zurecht. Der Import von fremden Spice-Modellen ist geradezu genial. Dann aber die Ernüchterung (2 Versionen ausprobiert, Original und von einem IC-Hersteller): Schaltung mit 30 Bauteilen eingegeben, davon 2 FETs und der Rest Kleinkram, um mal die Mindestanforderungen meines Problems anzutesten, Simulation gestartet, nichts tut sich, keine Meldung, einfach nur tot. Des Rätsels Lösung findet sich im Logfile: "this circuit is too large to simulate with this version. Too many analog nodes.". Was soll das? Eine ernsthafte Entscheidung über die Brauchbarkeit dieser Software kann man mit solch rigiden Begrenzungen nicht treffen. Bevor ich jetzt mit Simetrix verhandele: weiß jemand, was eine Vollversion kostet? Die Website schweigt sich darüber leider aus (was erfahrungsgemäß heißt, wir liegen mindestens bei 5 bis 10kEUR). Das macht ja alles keinen Sinn, wenn es meine Möglichkeiten um Zehnerpotenzen überschreitet und ist für derzeit einmaligen Einsatz einfach nicht drin.
> Die Vorzüge von LTSpice nützen mir nichts, wenn es crasht
Was meinst du mit "crashed"?
Helmut S. schrieb: >> Die Vorzüge von LTSpice nützen mir nichts, wenn es crasht > > Was meinst du mit "crashed"? Erst die hier besprochenen Spikes (die mehr oder weniger ein Schönheitsfehler sind), aber dann Abbruch mit der berühmten Fehlermeldung "time step too small". Sobald ich die komplette Schaltung zusammenhabe, bricht es unter irgendwelchen Bedingungen (Variation von Betriebsspannung/Last/Temperatur) mit dieser Fehlermeldung hab. Funktionieren tut es nur meistens mit den erwähnten Krücken, wie Austausch eines realen OpAmp gegen einen vereinfachten. Aber auch das erlaubt keine Simulation unter allen Betriebsbedingungen. Meine Erfahrung deckt sich damit mit dem Zitat von Abdul K.: "Meist erledigt es sich bei einem kleinen Umbau von was auch immer in der Schaltung." Umgekehrt heißt das allerdings in meinem Fall, Vergleiche über alle Betriebsbedingungen kriege ich nicht zum Laufen. Ob man das nun Crash nennt oder sonstwie, ist egal. Es funktioniert halt nicht.
Eventuelle spikes und "time step to small" sind kein "crash" sondern Konvergenzprobleme.
Mit deinem NDA kommen wir hier nicht weiter. Kannst ja mal Simetrix fragen, ob sie dir eine Version mit mehr Freiheiten zum Testen senden. Ich würde generell mal versuchen möglichst alle Induktivitäten zu eliminieren. Und in den Modellen nachschauen, obs da seltsame Konstrukte gibt. Kandidaten wie die Modelle von Infineon, Microchip usw. Oder PSPICE oder HSPICE Konstrukte wie das ^ muß zu ** übersetzt werden.
Abdul K. schrieb: > Man könnte es ja in einem anderen SPICE mal nachbauen bei Verwendung der > gleichen Modelle. Wenn es dort dann nicht auftritt, hat LTspice ein > Problem. Bei einer Simulationen mit einer kleineren Anzahl von Bauteilen und auch IGBTS (2 anstatt 12) läuft die Simulation durch und es treten keine Spikes auf. Das ganze noch in akzeptabler Geschwindigkeit. Die ganzen Probleme treten erst bei einer höheren Anzahl an Knoten und Modellen auf. Deshalb meine Vermutung, dass LTspice bei einer höheren Anzahl an Knoten/Bauteilen die Genauigkeit reduzieren muss und dadurch Rechenfehler auftreten >Schön wäre es, wenn man dem Programm sagen könnte, bis zu welcher >Frequenz es überhaupt simulieren soll. Hierzu müsste ab einer gewissen Flankensteilheit begrenzt werden. In der Leistungselektronik treten allerdings von Natur aus einige kV/us bzw. kA/us auf. Denke nicht das hier eine Begrenzung der Flanken noch zu einem akzeptablen Ergebnis führen würde. Ps: Wird dieser Beitrag jetzt erneut schlecht bewertet weil kein Schaltplan veröffentlicht wird? Mein Startbeitrag bezog sich nur auf die Rechenfehler von LTspice bei Leistungselektronik, nicht auf Schaltungsspezifische Probleme wie Gatewiderstände.
Michael M. schrieb: > Ps: Wird dieser Beitrag jetzt erneut schlecht bewertet weil kein > Schaltplan veröffentlicht wird? Mein Startbeitrag bezog sich nur auf die > Rechenfehler von LTspice bei Leistungselektronik, nicht auf > Schaltungsspezifische Probleme wie Gatewiderstände. Ehrlich gesagt bin ich auch etwas verärgert darüber, wie einige darauf herumreiten, dass (aus gutem Grund) nicht jeder seinen Schaltplan veröffentlichen kann oder will. Das Problem ist ein grundsätzliches und nicht vom spezifischen Schaltplan abhängig, so viel kann man mit Sicherheit sagen. Der Tenor ist ja, dass Irregularitäten auch bei anderen aufgetreten und branchenbekannt sind, weshalb hier mehrfach von LTSpice abgeraten wird bei Aufgaben der Leistungselektronik. Das wundert mich insoweit, als LTSpice ja gerade für Schaltwandler propagiert wird. Es ist offenbar ein schmaler Grat zwischen dem, was noch geht, und dem, wo LTSpice versagt. Mit der Qualität der Modelle hat es allenfalls bedingt etwas zu tun, wenn gleichzeitig behauptet wird, dass es z. B. mit Simetrix besser funktionieren soll. Da werden schließlich die gleichen Modelle verwendet (jedenfalls dann, wenn ich selbst ein Hersteller-Modell hineinlade). Jedenfalls scheint es keine allgemeingültigen Empfehlungen zu geben, wie man mit LTSpice weiterkommt, wenn die genannten Probleme auftreten. Ich zitiere nochmal Abdul K.: "Meist erledigt es sich bei einem kleinen Umbau von was auch immer in der Schaltung." Das ist auch meine Erfahrung - es scheint, als würde man gegen den Zufall kämpfen. Falls jemand echte Empfehlungen hätte, welche Parameter für eine konsistent erfolgreiche Simulation von Leistungselektronik-Schaltungen mit LTSpice zu wählen sind oder welche Tricks zu beherzigen sind, wäre ich für Hinweise und Empfehlungen weiter sehr, sehr dankbar. Ich habe allerdings schon tagelang (!) das Internet nach solchen Empfehlungen durchsucht und zahllose Abhandlungen zu dem Thema gelesen. Dieser Thread ist erstaunlicherweise der erste, der das Problem der auch von mir beobachteten irregulären Spikes thematisiert. Und mindestens der hundertste, der keine Lösung weiß.
Was mich an dieser Stelle interessieren würde (auch, wenn ich den Thread hijacke): Was erhofft ihr euch persönlich von Ltspice im Verbindung mit Leistungselektronik? 1) Meine LE Anfänge haben sich auf Umrichter im unteren kW Bereich begrenzt. Die Auslegung der Halbleiter und passiven Komponenten (DC Link und Drossel im Filter) basierte auf mathematischen Gleichungen, die Regelung wurde digital mittels uC realisiert. Vor allem in 3 Phasen Systemen, wenn man Clarke Park (Raumzeigermodulation) anwendet, stelle ich mir die ganze Umwandlung und Rechnerei in Ltspice sehr kompliziert vor. 2) Anschließend habe ich Umrichter im MW Bereich entwickelt. Gleiches Phänomen: die ganze Realisierung in Ltspice war ein Alptraum. Lediglich die "alten Hasen", die mit Ltspice aufgewachsen sind, konnten das einigermaßen in die Tat umsetzen. So wirklich sauber lief es aber auch nicht. 3) Nun bin ich in der Entwicklung von Schaltnetzteilen (inkl PFC) tätig, wo viel mit EMV (Filterauslegung CM und DM) sowie Gain Phase Messungen zwecks Filter - und Reglerauslegung gearbeitet wird. Zu diesen Themen gibt es viele Doktorarbeiten und Veröffentlichungen, die das mathematisch beschreiben. Und es gibt ebenfalls zahlreiche Bücher, die die Übertragungsfunktionen herleiten. Ich für meinen Teil frage mich ernsthaft, wofür man Simulationssoftware braucht. Ein gründlicher, mathematischer Ansatz sollte ausreichend sein. Meine Frage an euch: Wo seht ihr den Mehrwert an Simulationen in der Leistungselektronik? Gruß,
Al3ko -. schrieb: > Was mich an dieser Stelle interessieren würde (auch, wenn ich den Thread > hijacke): > > Was erhofft ihr euch persönlich von Ltspice im Verbindung mit > Leistungselektronik? Nein, das ist kein Hijacking, die Frage ist berechtigt. Ich für meinen Teil simuliere gar keine Leistungselektronik in dem von dir genannten Sinn. Ich arbeite an einem Gerät, das Netzspannungs-versorgt ist, wechselnde Gesamtleistung bis zu einigen Hundert W hat und in der Stromversorgung sind ein paar FETs. Eigentlich hätte ich geglaubt, dass dies ein originärer Anwendungsfall von LTSpice ist. Sinn der Simulation ist nun, das Gesamtverhalten zu simulieren und fehlerfreie Funktion des Geräts sicherzustellen unter Berücksichtigung von allem, was in freier Wildbahn so auftritt - Brownouts, Überspannung, diverse Lastfälle, wechselnde Betriebstemperatur. Ohne Simulation, bloß mit Papier und Bleistift, ist das nicht mehr beherrschbar bzw. mit sehr großen Unsicherheiten behaftet. Sinn der Simulation ist, diese Unsicherheiten zu verringern. Der Threadersteller hat eine ganz andere Aufgabenstellung. Insoweit habe ich den Thread auch gehijackt, allerdings aus der eigenen leidvollen Erfahrung, dass ich die gleichen Probleme beobachte, inklusive der physikalisch nicht erklärbaren Spikes. Und in der Hoffnung, dass jemand hilfreiche Hinweise geben kann - die uns dann allen helfen.
> Wo seht ihr den Mehrwert an Simulationen in der Leistungselektronik? > nun, viele (mich eingeschlossen) sind einfach zu faul, alles über Formeln und Excell-Tabellen zu bestimmen. Da is LTSpice einfach mal bequemer, und es lädt auch zum spielen mit div Parametern ein. Die Skepsis hinsichtlich der Resultate teile ich allerdings auch. Nach wie vermute ich das Problem vorzugsweise in unzureichender Modellierung der Realität. LTSpice selbst ist imho ein recht ausgereifter Simulator, TINA ist dagegen Spielkram, also eher für diejenigen, die mit einem Bosch IXO zufrieden zu stellen sind. Und ja, die Fehlermeldungen im Zusammenhang von "time-step too small" versteht außer Mike Engelhardt und Helmut Sennewald wohl keiner auf dieser Welt.
:
Bearbeitet durch User
In SPICE kann man Dinge untersuchen, die man eben nicht vollständig versteht! Damit ist es neben dem Versuchsaufbau und dessen Messungen das ideale Tool zum Lernen. Und Bauelemente benutzen, die man nicht vorliegen hat (wegen Preis, Beschaffbarkeit, laufender Bestellung, physikalischer Unrealisierbarkeit heutzutage). Bzw. sie testen bis sie kaputt wären. Man kann den Versuchsaufbau im ICE mitschleppen und belästigt dort keine Mitfahrenden mit Lötdämpfen. usw. Wer ein Thema völlig versteht, brauch SPICE eigentlich nicht mehr. Der benutzt auch keine komplizierten Formeln aus wissenschaftlichen Abhandlungen mühsam zusammengesucht, sondern ein paar Faustformenln oder gar nur Intuition und es paßt dann. Wer SPICE nicht verstehen WILL(wie z.B. seine Frau), der muß es nicht nutzen und sollte nicht ständig drüber meckern. Das Argument, daß LTspice genau hier das nicht kann wofür es gedacht ist, sollte auch Autor Mike E. wurmen und zu Tätigkeit veranlassen. LTspice arbeitet intern mit diversen mathematischen Tricks. Das rächt sich vielleicht hier ganz konkret. Vielleicht hat er einfach noch keine passende Lösung gefunden bzw. nicht die Zeit es zu implementieren. Verstehe z.B. nicht, warum er durch die Welt chatten muß um LTspice zu promoten. Sein Argument für die automatische nicht abschaltbare Skalierung der Vertikalachse in Graphen läßt auch tief blicken: Er schrieb dazu: "Das verhindert, daß ich ständig durch Anrufe gestört werde" Hallo, wer ruft ihn direkt an und darf er sein Telefon nicht für externe abschalten? Hat TINA es denn beschaulich simulieren können? Mir ist TINA einfach zu umständlich in der Bedienung. Andererseits benutzt ArnoR es sehr gern und er ist wahrlich kein Anfänger. Das muß ja einen Grund haben. Anderer Weg wäre es in SIMPLIS zu realisieren. Aber da muß man erstmal Modelle erzeugen, denn das kann nicht direkt SPICE verwenden.
Mark S. schrieb: >> Wo seht ihr den Mehrwert an Simulationen in der Leistungselektronik/ überall ? >> > nun, viele (mich eingeschlossen) sind einfach zu faul, alles über > Formeln und Excell-Tabellen zu bestimmen. Da is LTSpice einfach mal > bequemer, und es lädt auch zum spielen mit div Parametern ein. > Eben. > Die Skepsis hinsichtlich der Resultate teile ich allerdings auch. Nach > wie vermute ich das Problem vorzugsweise in unzureichender Modellierung > der Realität. Die Kunst ist zu erkennen, wo man drehen muß. > Und ja, die Fehlermeldungen im Zusammenhang von "time-step too small" > versteht außer Mike Engelhardt und Helmut Sennewald wohl keiner auf > dieser Welt. Hm. Vermutlich läßt sich diese Fehlermeldung in "völlig überhöhte Dynamik der Flankensteilheit" übersetzen. Anscheinend setzt LTspice aus einer Prognose zurückliegender Zeitpunkte einen in der Zukunft, der aber manchmal einfach zu progressiv falsch liegt. Die nachfolgende Aufteilung auf der Zeitschiene erzeugt wiederum einen neuen falschen Zeitpunkt. Dann bricht wohl LTspice intern ab. Wieviele Iterationen es da macht, weiß ich nicht.
>oder im >Post-Processing die entsprechenden Datenpunkte löschen. Diese Vorgehensweise ist vielleicht bei kleinen Schaltungen noch akzeptabel aber bedeutet einen enormen Aufwand bei großen Schaltungen. Das ganze Automatisieren möchte ich auch nicht, denn es könnte ja ein "realer" Spike gelöscht werden. >Was erhofft ihr euch persönlich von Ltspice im Verbindung mit >Leistungselektronik? ..nicht die grundsätzliche Dimensionierung der Schaltung. Diese muss ja bereits für die Simulation (zumindest größtenteils) vorliegen. Wie bereits von Dieter R. und Mark Space erwähnt kann die Schaltung in relativ kurzer Zeit auf ihr Verhalten in Extrembedingungen getestet werden. Lastsprünge, Ausfall einer Versorgung,.. Des weiteren wird es sehr schnell sehr aufwendig Bauteile wie eine stromabhängige Induktivität bei händischer Berechnung zu berücksichtigen. Weiterhin lädt es ein, zumindest wenn die genauen Modelle verfügbar sind, abzuschätzen wie sich z.B. verschiedene Gatewiderstände auf die Oberwellen auswirken. In diesen Situationen erhoffe ich mir etwas Unterstützung von Spice. >Erst die hier besprochenen Spikes (die mehr oder weniger ein >Schönheitsfehler sind), aber dann Abbruch mit der berühmten >Fehlermeldung "time step too small". Najo Schönheitsfehler.. Die Simulationsergebnisse werden nicht nur von "time-step-too-small"-Kennern betrachtet sondern auch von diversen anderen. Wie erklärt man hierbei, dass diese Spannungsspitze von 1kV aus dem realen Aufbau stammt, hingegen eine andere mit 1.5kV ein Fehler ist und somit ignoriert werden kann/muss? > Hm. Vermutlich läßt sich diese Fehlermeldung in "völlig überhöhte > Dynamik der Flankensteilheit" übersetzen. > Anscheinend setzt LTspice aus einer Prognose zurückliegender Zeitpunkte > einen in der Zukunft, der aber manchmal einfach zu progressiv falsch > liegt. Die nachfolgende Aufteilung auf der Zeitschiene erzeugt wiederum > einen neuen falschen Zeitpunkt. Dann bricht wohl LTspice intern ab. > Wieviele Iterationen es da macht, weiß ich nicht. In der Tat verschwinden die Spikes wenn der maximum time step auf verschwindend kleine Werte gestellt wird. Dies vervielfacht die allerdings ohnehin schon lange Simulationszeit.. Für mich ist LTspice ist eines der besten Simulationstools nur leider trimmt es den timestep auf zu aggressive Werte um die Geschwindigkeit zu erhöhen. Dies rächt sich bei "plötzlichen" transienten. Vielleicht wäre hierfür eine spezielle Option für Leistungselektroniksimulation, welche bei Detektion von steilen Transienten z.B. die letzten Datenpunkte löscht und mit einem kleineren timestep erneut simuliert, zielführend. Weiß jemand ob Mike Engelhard bereits eine solche Funktion implementiert oder geplant hat?
Du kannst ihn ja anschreiben. Ich persönlich finde die Kommunikation mit ihm sobald man nicht einer exakt gleichen Meinung ist, als sehr schwierig. Er schnappt schnell ein und blockt dann ganz. Daher sehe ich von Anfragen, wenn sie nicht wirklich ein extremes Problem darstellen, komplett ab. Und das, wo wir mal praktisch Nachbarn waren, da er in der gleichen Stadt in DE Physik studierte, wo ich damals auch wohnte. Wenn LTspice mit solchen transienten Ereignissen nicht umgehen kann, als "SwitcherCAD", wer sollte es sonst können? Dafür ist es doch gedacht. Als Verkaufshilfe für Schaltreglerbausteine. Alle weiteren Funktionen kamen im Laufe der Zeit hinzu oder wurden unter akademischen Aspekten wohlwollend von LTC 'zugelassen'. So daß es momentan ein praktisch vollständiges SPICE ist. Fehlt nur noch das ganze Drumherum wie automatische Parameterextraktion. Da ist LTspice eine echte Wüste. Das merkt man aber als Anfänger erst viel später. Es ist halt recht effektiv, hat fast alle Funktionen for free freigeschaltet, und ist kostenlos. Wer viel Geld hat, nimmt vielleicht was anderes. Und sei es nur ergänzend.
Abdul K. schrieb: >> Und ja, die Fehlermeldungen im Zusammenhang von >> "time-step too small" versteht außer Mike Engelhardt >> und Helmut Sennewald wohl keiner auf dieser Welt. > > Hm. Vermutlich läßt sich diese Fehlermeldung in "völlig > überhöhte Dynamik der Flankensteilheit" übersetzen. Eher unwahrscheinlich. Die Numerik kämpft mit mehreren Fehlerquellen, die in unterschiedlichen Situationen zum Tragen kommen. Der Diskretisierungsfehler, der dadurch entsteht, dass man ein stetiges System nur zu diskreten Zeitpunkten betrachten und berechnen kann, wird tatsächlich kleiner, wenn man die Stützstellen dichter setzt. Der Abbruchfehler aber, der durch die endliche Genauigkeit der Zahlendarstellung entsteht, wird natürlich umso größer, je mehr Rechenoperationen benötigt werden, um in der simulierten Zeit eine Nanosekunde voranzukommen, weil sich dieser Fehler akkumuliert. (Der nächste Rechenschritt baut ja auf den leicht fehlerhaften Resultaten des vorherigen auf. Es gibt also irgendwo eine optimale Schrittweite.) Es kann (aus Gründen, die ich nicht verstanden habe) vorkommen, dass sich der akkumulierte Abbruchfehler viel stärker auswirkt als der Diskretisierungsfehler. Dann VERSCHLECHTERT sich die erzielte Genauigkeit, wenn man den Zeitschritt verkleinert; das kann bis zur kompletten Divergenz gehen --> "time step too small". Übergang auf hochgenaue Zahlen löst das Problem nicht grundsätzlich, sondern schiebt die Grenze nur etwas weiter hinaus (weil der Fehler im gefürchteten schlechtesten Fall exponenziell wächst.) Ohne LTSPICE zu kennen würde ich aus der Ferne vermuten, dass die Spikes nichts mit "time step too small" zu tun haben; das sind mMn unterschiedliche Fehler.
Possetitjel schrieb: > Ohne LTSPICE zu kennen würde ich aus der Ferne vermuten, > dass die Spikes nichts mit "time step too small" zu tun > haben; das sind mMn unterschiedliche Fehler. Mit Kenntnis von LTSpice und aus der Nähe betrachtet kann ich die Erkenntnisse von Michael M. vollumfänglich bestätigen: Wählt man den "Maximum Timestep" immer kleiner (was dann zu immer größeren Rechenzeiten führt), verschwinden sowohl die Spikes als auch die Abbrüche mit "time step too small". Alle anderen Parameter helfen mal hier und da, aber nie grundsätzlich. Maximum Timestep auf 50 ns und dann ggf. noch kleiner auf 20 oder 10 ns hat dagegen in meinen aktuellen Versuchen immer funktioniert. Da große Teile der Simulation auch mit wesentlich (Faktor 10 bis 100) größerem "Maximum Timestep" problemlos und entsprechend schnell laufen, bleibt als Fazit der dringende Wunsch an Mike Engelhardt, an dem Algorithmus, der den intern verwendeten jeweiligen Timestep bestimmt, etwas zu ändern. Mehr Dynamik bitte.
@Posse: Wenn das stimmt, was du schreibst. Warum wird dann mit maximum time-step kleiner gestellt, der Fehler auch kleiner bzw. verschwindet oft ganz? Das beißt sich. Ich vermute, daß man mit tripdv und tripdt LOKAL für einzelne Bauelemente kleinere time-steps statisch und dynamisch definieren kann. Aber so ganz durchschaue ich das noch nicht, daher benutze ich diese beiden Kommandos nicht. LTC hat sie aber in diversen eigenen Libs drin. Eventuell ist das ein zumindest praktikables Hilfskonstrukt, um die Sim-Zeit nicht unnötig über global maximum time-step aufzublähen.
Abdul K. schrieb: > Ich vermute, daß man mit tripdv und tripdt LOKAL für einzelne > Bauelemente kleinere time-steps statisch und dynamisch definieren kann. > Aber so ganz durchschaue ich das noch nicht, daher benutze ich diese > beiden Kommandos nicht. LTC hat sie aber in diversen eigenen Libs drin. > Eventuell ist das ein zumindest praktikables Hilfskonstrukt, um die > Sim-Zeit nicht unnötig über global maximum time-step aufzublähen. Wo genau und wie ungefähr werden diese Parameter verwendet? Kannst du bitte Beispiele nennen, man kann das ja mal ausprobieren. Es geht schließlich nichts dabei kaputt, aber stundenlange Simulationen beschleunigen wäre eine echte Verbesserung.
Abdul K. schrieb: > Wenn das stimmt, was du schreibst. Warum wird dann mit > maximum time-step kleiner gestellt, der Fehler auch > kleiner bzw. verschwindet oft ganz? Das beißt sich. Hmm. Verstehe ich Dich richtig: Wenn man die maximale Schritt- weiter VERKLEINERT, verschwindet der Fehler "time step too small"?
Manchmal scheint es so zu sein. Beispiele habe ich momentan keine. Google halt.
Possetitjel schrieb: > Abdul K. schrieb: > Hmm. > Verstehe ich Dich richtig: Wenn man die maximale Schritt- > weiter VERKLEINERT, verschwindet der Fehler "time step > too small"? Ja sie verschwinden komplett. Der dafür benötigte timestep ist allerdings sehr klein. So werden schnell aus ein paar Minuten Simulationszeit einige Stunden. >Die Numerik kämpft mit mehreren Fehlerquellen, die in >unterschiedlichen Situationen zum Tragen kommen. Der >Diskretisierungsfehler, der dadurch entsteht, dass man >ein stetiges System nur zu diskreten Zeitpunkten >betrachten und berechnen kann, wird tatsächlich kleiner, >wenn man die Stützstellen dichter setzt. Du gehst davon aus, dass LTspice ein gegebenes Signal zu diskretisieren versucht und dann wird der Fehler mit vielen Datenpunkten kleiner. LTspice hingegen versucht den nächsten Punkt zu erraten und nutzt dazu die vergangenen Werte. Mit diesem erratenen Wert wird das ganze System durchgerechnet und wenn sich die (bin mir nicht mehr ganz sicher aber ich glaube gelesen zu haben das dies das Prinzip ist) Ströme in den Knoten aufheben, dann war die Annahme korrekt. Falls nicht versucht LTspice mit immer kleineren Iterationschritten sich dem richtigen Punkt anzunähern. Angenommen die Spannung an einem Kondensator ist für 10ms 100V. Somit schätzt LTspice diese Spannung zum Zeitpunkt 10.1ms (übertriebene Schrittweite aber ich denke es sollte das Prinzip verdeutlichen) die Spannung ebenfalls auf 100V. Hat nun jedoch zum Zeitpunkt 10.001,s z.B. ein Fet eingeschalten, so kann LTspice keine Lösung mehr finden, da es für eine Kondensatorspannung von 100V keine mehr gibt. Durch Iteration dieser Annahme versucht es dennoch eine Lösung zu finden. Mögliche Lösungen sind dann z.B. die richtige Spannung, Spannungen von einigen Gigavolt oder eben der Abbruch mit dem berühmten "time-step-too-small" Fehler.. Lösungsansätze wie eine kleine Kapazität auf gnd sorgen nur dafür, dass LTspice frühzeitig anfängt die Schrittweite zu verringern. Versucht mal bei euren Schaltungen die Taktfrequenz so weit zu erhöhen bis die Schaltvorgänge direkt aufeinander folgen. Dann läuft dieselbe Simulation ohne Fehler und ohne Tricks wie cshunt und dergleichen weil LTspice nie in Versuchung gerät die Schrittweite stark zu erhöhen. Diese Informationen stammen aus einem Dokument welches ich vor einiger Zeit im Internet gefunden habe. Finde es leider nicht mehr aber das sollte grundsätzlich dessen Aussage gewesen sein. Bitte korrigiert mich wenn ich falsch liege. :-)
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.