Vorbemerkung
Wenn ich hier von "Anfänger" spreche, so meine ich damit nicht unbedingt Anfänger auf dem Gebiet der Elektronik,
sondern eher Anfänger in der Handhabung von LTspice.
Trotzdem bemühe ich mich immer, so zu schreiben, dass auch Personen mit weniger Wissen und Erfahrung meinen
Ausführungen folgen können. Wer schon alles weiss und kann, wird dieses Howto natürlich nicht benötigen.
Es ist ein etwas längeres Tutorial. Üblicherweise schreibe ich hier sonst eher nur eine allgemeine, kurze Einführung,
das eigentliche Tutorial befindet sich dann als PDF-Datei in dem beigefügten Archiv.
Heute findet sich hier der volle Text, zum Nachlesen auch beigefügt als PDF.
--- --- ---
Wer gerade mit LTspice angefangen hat, steht vor vielen Problemen: LTspice ist in hohem Masse gewöhnungsbedürftig,
die Hilfe-Datei eher - mal bös ausgedrückt - von Elektronik-Gurus für Elektronik-Gurus gemacht, und auch das (grafische)
"User Interface" nicht unbedingt das Nonplusultra. Auf der anderen Seite aber ein riesengrosses Plus:
LTspice ist schnell und vor allem -- kostenlos und frei erhältlich!!
Die ersten Schaltpläne sind eingegeben, die Ausgangssspannung eine schöne Kurve im Plotfenster,
und wenn man jetzt noch ein paar Messdaten hätte, wäre die Welt in Ordnung.
Die Welt der Zahlen - anscheinend eine exakte Welt, Zahlen lügen nicht, sie strahlen so etwas Beruhigendes aus.
Tja, dann fangen wir mal an. Um die Grundlagen und Grenzen zu verstehen, was das Messen mit LTspice betrifft,
beginnen wir mit etwas ganz Einfachem, nämlich einer Sinusspannung. Dazu geben wir den folgenden Schaltplan ein:
Wir haben da eine Spannungsquelle mit einer Sinusspannung von 1 Volt (Spitzenspannung) und einer Frequenz von 1kHz.
Und weil LTspice eigentlich keine schwebenden Ausgänge mag, fügen wir einen Lastwiderstand zwischen Ausgang und Masse hinzu.
Den Ausgang bezeichnen wir mit dem Label "out".
Wir machen eine Transientenanalyse von 2ms, lassen die Messwerte von Zeit Null an speichern
und wählen dazu einen maximalen Timestep von 1ms.
Im Plotfenster lassen wir uns die Ausgangsspannung anzeigen, wir sehen wie erwartet eine Sinuskurve von zwei Zyklen.
Um überhaupt Spannungsverläufe anzeigen zu können, muss LTspice natürlich eine Menge berechneter Daten speichern,
je nachdem wie umfangreich bzw. kompliziert der Schaltplan ist, kann das schon riesig sein, diese Daten werden in einer temporären Datei ausgelagert.
Alles, was wir also in LTspice als Benutzer messen können, erfolgt somit nicht während, sondern erst nach vollendeter Simulation!
Das erkennt man auch daran, dass LTspice die .measure-Anweisung zuletzt ausführt und einen entsprechenden Text im Status bar anzeigt.
Die Anweisung zum Messen geschieht mit ".measure", abgekürzt zu ".meas" ist ebenfalls ok.
Bis man sich an die Syntax gewöhnt hat, benutzt man am besten den sogenannten "measure Statement Editor".
Dazu im Toolbar ".op" anklicken, im Editor-Fenster ".meas" eingeben und mit Enter oder per Maus bestätigen
und an geeigneter Stelle auf dem Schaltplan platzieren.
Das war aber jetzt noch nicht besagter "measure Statement Editor"!
Dazu Rechtsklick auf den Schriftzug ".meas". Jetzt erst öffnet sich dieser Editor.
Bei "Applicable Analysis" wählen wir aus dem Dropdown-Menü "TRAN", bei "Result Name" geben wir "V0" ein,
bei "Genre" wählen wir "FIND" und bei "Measured Quantity" ergänzen wir "v(out)". [Kleinschreibung ok]
Mit der Selektion von "FIND" hat sich das Editor-Fenster verändert.
TRAN ist eine zeitbezogene Analyse, die X-Achse ist diese Zeitachse, und "Point" fragt uns,
zu welchem Zeitpunkt wir den Wert von v(out) messen wollen.
Im Plotfenster scheint die Sinuskurve ziemlich genau bei Null Volt zu beginnen, aber man kann ja nie wissen,
möglicherweise beginnt sie bei 0.0135 Volt??
Wir stellen uns einfach mal dumm und geben im Eingabefenster neben "AT" den Wert 0 ein und klicken OK.
Im Schaltplan finden wir jetzt die ergänzte measure-Anweisung: ".meas TRAN V0 FIND v(out) AT 0":
finde in der TRAN-Analyse den Wert von v(out) zum Zeitpunkt Null und gib ihn unter dem Namen "V0" aus.
Aber wo finden wir die Ausgabe? -- In der SPICE error log Datei (bzw. Output log Datei).
Wir führen die Simulation erneut aus, dann entweder CTRL-L oder im Schaltplanfenster Rechtsklick / View / SPICE error log:
v0: v(out)=0 at 0 wird angezeigt.
So weit so gut, zum Zeitpunkt Null ist unsere Sinusspannung tatsächlich 0 Volt, wie sollte das auch anders sein.
Im Plotfenster sehen wir noch weitere Punkte, an denen die Sinuskurve Null Volt betragen sollte,
nämlich bei 0.5ms, 1ms, 1.5ms und 2ms.
Wir wollen jetzt aber nicht alle durchtesten, wir beschränken uns auf die Mitte (1ms) und das Ende (2ms).
Da wir jedem Messwert einen Namen geben müssen und nicht unter ein- und demselben Namen
mehrere Ergebnisse anzeigen lassen können, müssen wir wohl oder übel zweimal den "measure Statement Editor" aufrufen:
.meas TRAN V1ms FIND v(out) AT 1ms
.meas TRAN V2ms FIND v(out) AT 2ms
Nach der Eingabe dieser Direktiven nochmal ausführen und die SPICE error log (mit CTRL-L) aufrufen:
Da liegt sie nun in Trümmern, unsere heil geglaubte Zahlenwelt!!
Die ausgegebenen Werte sind zwar nahe bei Null, aber eben nicht genau Null! Wie kann das sein?!?
Kann LTspice nicht rechnen? CPU mit Rechenfehler?
Kein Grund zur Sorge, das haben wir gleich! Schauen wir uns erst mal an, was und wie viel Daten LTspice überhaupt gesammelt hat . . .
Für einen ersten Überblick gehen wir dazu ins Plotfenster, Rechtsklick / View / Mark Data Points:
Oha! Viel ist's gerade nicht . . . :-(
Und bei 1ms ist gar kein Datenpunkt in der Nähe . . . Überhaupt scheinen die Datenpunkte nicht gleichmässig,
sondern eher ziemlich unregelmässig verteilt zu sein . . .
Das hat seinen Grund und ist so gewollt per Algorithmus! Wo eine Kurve sich wenig ändert, da gibt's wenige,
wo sie sich schnell ändert, da gibt es mehr Datenpunkte. Sehen wir uns einen Kurvenausschnitt mal genauer an!
Wenn wir genau hinschauen, so erkennen wir, dass die Datenpunkte einfach durch gerade Linien miteinander verbunden sind!
Das ist gar keine Kurve! Und selbst wenn LTspice zwischen 2 Datenpunkten interpoliert, kann der genaue Wert so nicht gefunden werden!
Kann man denn nicht die Anzahl der Datenpunkte festlegen oder wenigstens vermehren? -- Doch, das kann man, in Grenzen,
indem man den "maximum timestep" verringert. Und das machen wir jetzt.
Wir ändern dazu die TRAN-Anweisung: Rechtsklick auf die TRAN-Anweisung, im nun geöffneten Editor ändern wir "Maximum Timestep"
von 1ms auf 1us (1 mikrosekunde): .tran 0 2m 0 1u
Nach erneuter Ausführung haben wir zwar ein paar Punkte mehr, aber eigentlich immer noch weniger als erwartet.
Schauen wir uns die Log-Datei mit den Messergebnissen an:
v0: v(out)=0 at 0
v1ms: v(out)=-9.218031e-007 at 0.001
v2ms: v(out)=-4.900594e-016 at 0.002
Immer noch sind V1ms und V2ms ungleich Null. Wir geben noch nicht auf, wollen es wissen und verringern noch einmal
"Maximum Timestep", diesmal auf 1ns, starten die Simulation und . . .
. . . jetzt liegen im Plotfenster die Punkte dicht beieinander, aber die Simulation dauert nun ewig
und die Kurve zeichnet sich im Schneckentempo. Und die Messergebnisse?
v0: v(out)=0 at 0
v1ms: v(out)=1.807855e-009 at 0.001
v2ms: v(out)=-4.898586e-016 at 0.002
Zwar nochmal ein wenig näher an Null heran, aber eben nicht genau 0.000.... auf 99 Stellen!
Wir geben auf!
Hatte etwa Bob Pease doch recht getan, als er den Computer bei National Semiconductor vom Dach warf?
[URL: Bob Pease - ein Mann, ein Wort!] -- unbedingt anschauen!!
Fazit: Wir müssen uns bei jeder Simulation bewusst sein, dass sie nur ein Herantasten an die Wirklichkeit darstellt
und nicht in jedem Fall den theoretisch exakten Wert vermitteln kann.
Macht das Simulieren und Messen von simulierten Daten daher keinen Sinn? -- Nein, das glaube ich nicht,
wir dürfen nur nicht den Simulator "vergöttern".
Ein Ausweg aus dem Dilemma bleibt uns noch: wir runden auf fünf Stellen nach dem Komma.
Das vorherige Ergebnis verwenden wir als Parameter für eine neue Messanweisung:
wir benennen das Resultat V1ms_r (r für relativiert), wählen bei "Genre" PARAM
und geben bei "measured Quantity" folgendes ein: round(V1ms*100k)/100k.
Nach der Eingabe vergrössern wir "max Timestep" auf 10n, ausführen und das Ergebnis in der log-Datei ansehen:
v0: v(out)=0 at 0
v1ms: v(out)=3.387552e-006 at 0.001
v2ms: v(out)=-4.898561e-016 at 0.002
v1ms_r: round(v1ms*100k)/100k=0
v2ms_r: round(v2ms*100k)/100k=0
So, jetzt ist die Null da und unsere Welt wieder in Ordnung! Wie schön!
Von diesem letzten Schritt lernen wir noch eine Sache:
wir können ein Messergebnis als Parameter für weitere Berechnungen verwenden!
Wir nähern uns dem Finale dieser Sinus-Episode: wenn wir schon einmal dabei sind,
wollen wir auch "Berg" und "Tal" der Sinuswelle berechnen, die Maxima und Minima.
Wir ahnen schon, dass auch hier die Messwerte möglicherweise nicht die erwarteten +1 und -1 erreichen . . . -- mal sehen!
Wir platzieren wie schon gewohnt ".meas" auf dem Schaltplan und rufen mit Rechtsklick
den ".measure Statement Editor" [mSE] auf. Bei "Analysis" wieder TRAN, bei "Result Name" nehmen wir Vmax,
bei "Genre" augenfällig "MAX" und bei "Quantity" wie schon gehabt "v(out)".
Und da das Minimum berechnen ganz ähnlich ist, noch einmal den mSE aufrufen,
das Ergebnis nennen wir "Vmin", Genre "MIN" und Quantity gleichfalls "v(out)".
Ein grosser Unterschied zu den vorigen Messungen ist, das wir bei MAX und MIN einen Wert nicht
zu einem bestimmten Zeitpunkt, sondern innerhalb einer Zeitspanne (Intervall) suchen!
Ohne Angabe bzw. Eingrenzung des Intervalls sucht LTspice in der ganzen, im Plotfenster angezeigten Zeitspanne
nach dem Maximum, also von Null bis 2 Millisekunden. Wenn nun der zweite "Berg" eine winzige Idee grösser ist als der erste,
bleibt der erste logischerweise unberücksichtigt. Wenn wir wissen wollen, wie gross das Maximum in der ersten Periode ist,
dann müssen wir den Bereich eingrenzen. Wir könnten die ganze Periode nehmen, also von Null bis 1 Millisekunde.
Wenn wir nur das Maximum suchten, würde die positive Halbwelle bis 0.5ms reichen, aber da wir auch das Minimum
in der negativen Halbwelle messen wollen, ist die ganze erste Periode bis 1ms ein Muss.
Wie legt man denn nun den Bereich fest? Umgangssprachlich würde man für einen Bereich "von .. bis" erwarten,
aber diese Schlüsselwörter sind "versteckt", man sieht nur die kryptischen "TRIG" und "TARG" --- arrgh!
Ganz unten, etwas oberhalb des Test-Buttons, liest man "Error: Missing trig/from". Und wenn man dann zu TRIG aufschaut,
erkennt man ein Drop-down Menü, das klappen wir auf und wählen dort "FROM".
In das Eingabefenster rechts davon schreiben wir 0, bei "TARG" entsprechend "TO" und als Endwert geben wir 1ms ein.
Das war's fürs Maximum, für das Minimum verfahren wir ebenso.
Anschliessend führen wir die Simulation wieder aus und sehen in der log-Datei nach dem Ergebnis:
v0: v(out)=0 at 0
vmax: MAX(v(out))=0.999505 FROM 0 TO 0.001
vmin: MIN(v(out))=-0.999531 FROM 0 TO 0.001
Also doch! Auch hier wieder das Ziel +1 und -1 knapp verfehlt! Als letzten Versuch verringern wir noch einmal
"max timestep" auf 1u, Ergebnis:
v0: v(out)=0 at 0
vmax: MAX(v(out))=0.999998 FROM 0 TO 0.001
vmin: MIN(v(out))=-0.999998 FROM 0 TO 0.001
Wir könnten wieder runden, aber wirklich notwendig ist das natürlich nicht!
Wir kennen ja jetzt die Ursache, wissen, dass es systembedingt ist und müssen damit leben! Punkt!
Wer mag, kann es ja versuchen zu runden, er/sie wird sehen, dass dann die ersehnte Eins erscheint.
- Zahlenmässiges (benutzer-deklariertes) Messen von elektrischen Grössen geschieht erst nach vollendeter Simulation
- Messen erfolgt mit der Anweisung ".meas[ure]" - Punkt nicht vergessen, Abk. zu .meas ok!
- Bis man die Syntax der verschiedenen Messanweisungen auswendig kann, den "measure Statement Editor" benutzen
- man kann die Messanweisung auf einen bestimmten Analysetyp (TRAN, AC, DC usw.) beschränken: .meas TRAN ...
- jede Messung muss mit einem unverwechselbaren Namen (unique identifier) gekennzeichnet sein: .meas TRAN V0 ...
- die Messergebnisse findet man in der SPICE error / Output - Log - Datei (Rechtsklick-View- ...)
- Die Simulation selbst und die mit ihr verbundenen internen Messwerte, sie besitzen keine unendlich feine Auflösung,
geringe Abweichungen von dem theoretisch zu erwartenden Ergebnis sind möglich.
- Man kann mitunter die Anzahl der Messwerte vergrössern auf Kosten der Simulationszeit, bei der TRAN-Analyse z.B.
durch Verringern des "Maximum Timestep", [hier abgekürzt mts]:
mts = 1m --- 57 Messwerte --- Simulationsdauer 0.097s
mts = 1u --- 165 Messwerte --- Simulationsdauer 0.136s
mts = 1n --- 1956 Messwerte --- Simulationsdauer 18s
[woher ich das weiss, bleibt in dieser ersten Lektion noch mein kleines Geheimnis . . . ;-)]
- Innerhalb eines Intervalls kann man Maxima und Minima messen, indem man bei Genre "MAX" bzw. "MIN" selektiert.
- Bei solchen Messungen über eine Zeitspanne (Intervall) kann man den Messbereich eingrenzen mit den Schlüsselwörtern "FROM" und "TO".
Dieser gewählte Bereich muss sich innerhalb der Simulationsdauer befinden, sonst gibt es eine Fehlermeldung!
Das war's für diesmal. Wer Lust hat, kann die nicht gemachten Nulldurchgänge und Maximum/Minimum der 2. Periode versuchen zu messen.
RudiS
Wenn ich hier von "Anfänger" spreche, so meine ich damit nicht unbedingt Anfänger auf dem Gebiet der Elektronik,
sondern eher Anfänger in der Handhabung von LTspice.
Trotzdem bemühe ich mich immer, so zu schreiben, dass auch Personen mit weniger Wissen und Erfahrung meinen
Ausführungen folgen können. Wer schon alles weiss und kann, wird dieses Howto natürlich nicht benötigen.
Es ist ein etwas längeres Tutorial. Üblicherweise schreibe ich hier sonst eher nur eine allgemeine, kurze Einführung,
das eigentliche Tutorial befindet sich dann als PDF-Datei in dem beigefügten Archiv.
Heute findet sich hier der volle Text, zum Nachlesen auch beigefügt als PDF.
--- --- ---
Wer gerade mit LTspice angefangen hat, steht vor vielen Problemen: LTspice ist in hohem Masse gewöhnungsbedürftig,
die Hilfe-Datei eher - mal bös ausgedrückt - von Elektronik-Gurus für Elektronik-Gurus gemacht, und auch das (grafische)
"User Interface" nicht unbedingt das Nonplusultra. Auf der anderen Seite aber ein riesengrosses Plus:
LTspice ist schnell und vor allem -- kostenlos und frei erhältlich!!
Die ersten Schaltpläne sind eingegeben, die Ausgangssspannung eine schöne Kurve im Plotfenster,
und wenn man jetzt noch ein paar Messdaten hätte, wäre die Welt in Ordnung.
Die Welt der Zahlen - anscheinend eine exakte Welt, Zahlen lügen nicht, sie strahlen so etwas Beruhigendes aus.
Tja, dann fangen wir mal an. Um die Grundlagen und Grenzen zu verstehen, was das Messen mit LTspice betrifft,
beginnen wir mit etwas ganz Einfachem, nämlich einer Sinusspannung. Dazu geben wir den folgenden Schaltplan ein:
Wir haben da eine Spannungsquelle mit einer Sinusspannung von 1 Volt (Spitzenspannung) und einer Frequenz von 1kHz.
Und weil LTspice eigentlich keine schwebenden Ausgänge mag, fügen wir einen Lastwiderstand zwischen Ausgang und Masse hinzu.
Den Ausgang bezeichnen wir mit dem Label "out".
Wir machen eine Transientenanalyse von 2ms, lassen die Messwerte von Zeit Null an speichern
und wählen dazu einen maximalen Timestep von 1ms.
Im Plotfenster lassen wir uns die Ausgangsspannung anzeigen, wir sehen wie erwartet eine Sinuskurve von zwei Zyklen.
Um überhaupt Spannungsverläufe anzeigen zu können, muss LTspice natürlich eine Menge berechneter Daten speichern,
je nachdem wie umfangreich bzw. kompliziert der Schaltplan ist, kann das schon riesig sein, diese Daten werden in einer temporären Datei ausgelagert.
Alles, was wir also in LTspice als Benutzer messen können, erfolgt somit nicht während, sondern erst nach vollendeter Simulation!
Das erkennt man auch daran, dass LTspice die .measure-Anweisung zuletzt ausführt und einen entsprechenden Text im Status bar anzeigt.
Die Anweisung zum Messen geschieht mit ".measure", abgekürzt zu ".meas" ist ebenfalls ok.
Bis man sich an die Syntax gewöhnt hat, benutzt man am besten den sogenannten "measure Statement Editor".
Dazu im Toolbar ".op" anklicken, im Editor-Fenster ".meas" eingeben und mit Enter oder per Maus bestätigen
und an geeigneter Stelle auf dem Schaltplan platzieren.
Das war aber jetzt noch nicht besagter "measure Statement Editor"!
Dazu Rechtsklick auf den Schriftzug ".meas". Jetzt erst öffnet sich dieser Editor.
Bei "Applicable Analysis" wählen wir aus dem Dropdown-Menü "TRAN", bei "Result Name" geben wir "V0" ein,
bei "Genre" wählen wir "FIND" und bei "Measured Quantity" ergänzen wir "v(out)". [Kleinschreibung ok]
Mit der Selektion von "FIND" hat sich das Editor-Fenster verändert.
TRAN ist eine zeitbezogene Analyse, die X-Achse ist diese Zeitachse, und "Point" fragt uns,
zu welchem Zeitpunkt wir den Wert von v(out) messen wollen.
Im Plotfenster scheint die Sinuskurve ziemlich genau bei Null Volt zu beginnen, aber man kann ja nie wissen,
möglicherweise beginnt sie bei 0.0135 Volt??
Wir stellen uns einfach mal dumm und geben im Eingabefenster neben "AT" den Wert 0 ein und klicken OK.
Im Schaltplan finden wir jetzt die ergänzte measure-Anweisung: ".meas TRAN V0 FIND v(out) AT 0":
finde in der TRAN-Analyse den Wert von v(out) zum Zeitpunkt Null und gib ihn unter dem Namen "V0" aus.
Aber wo finden wir die Ausgabe? -- In der SPICE error log Datei (bzw. Output log Datei).
Wir führen die Simulation erneut aus, dann entweder CTRL-L oder im Schaltplanfenster Rechtsklick / View / SPICE error log:
v0: v(out)=0 at 0 wird angezeigt.
So weit so gut, zum Zeitpunkt Null ist unsere Sinusspannung tatsächlich 0 Volt, wie sollte das auch anders sein.
Im Plotfenster sehen wir noch weitere Punkte, an denen die Sinuskurve Null Volt betragen sollte,
nämlich bei 0.5ms, 1ms, 1.5ms und 2ms.
Wir wollen jetzt aber nicht alle durchtesten, wir beschränken uns auf die Mitte (1ms) und das Ende (2ms).
Da wir jedem Messwert einen Namen geben müssen und nicht unter ein- und demselben Namen
mehrere Ergebnisse anzeigen lassen können, müssen wir wohl oder übel zweimal den "measure Statement Editor" aufrufen:
.meas TRAN V1ms FIND v(out) AT 1ms
.meas TRAN V2ms FIND v(out) AT 2ms
Nach der Eingabe dieser Direktiven nochmal ausführen und die SPICE error log (mit CTRL-L) aufrufen:
Da liegt sie nun in Trümmern, unsere heil geglaubte Zahlenwelt!!
Die ausgegebenen Werte sind zwar nahe bei Null, aber eben nicht genau Null! Wie kann das sein?!?
Kann LTspice nicht rechnen? CPU mit Rechenfehler?
Kein Grund zur Sorge, das haben wir gleich! Schauen wir uns erst mal an, was und wie viel Daten LTspice überhaupt gesammelt hat . . .
Für einen ersten Überblick gehen wir dazu ins Plotfenster, Rechtsklick / View / Mark Data Points:
Oha! Viel ist's gerade nicht . . . :-(
Und bei 1ms ist gar kein Datenpunkt in der Nähe . . . Überhaupt scheinen die Datenpunkte nicht gleichmässig,
sondern eher ziemlich unregelmässig verteilt zu sein . . .
Das hat seinen Grund und ist so gewollt per Algorithmus! Wo eine Kurve sich wenig ändert, da gibt's wenige,
wo sie sich schnell ändert, da gibt es mehr Datenpunkte. Sehen wir uns einen Kurvenausschnitt mal genauer an!
Wenn wir genau hinschauen, so erkennen wir, dass die Datenpunkte einfach durch gerade Linien miteinander verbunden sind!
Das ist gar keine Kurve! Und selbst wenn LTspice zwischen 2 Datenpunkten interpoliert, kann der genaue Wert so nicht gefunden werden!
Kann man denn nicht die Anzahl der Datenpunkte festlegen oder wenigstens vermehren? -- Doch, das kann man, in Grenzen,
indem man den "maximum timestep" verringert. Und das machen wir jetzt.
Wir ändern dazu die TRAN-Anweisung: Rechtsklick auf die TRAN-Anweisung, im nun geöffneten Editor ändern wir "Maximum Timestep"
von 1ms auf 1us (1 mikrosekunde): .tran 0 2m 0 1u
Nach erneuter Ausführung haben wir zwar ein paar Punkte mehr, aber eigentlich immer noch weniger als erwartet.
Schauen wir uns die Log-Datei mit den Messergebnissen an:
v0: v(out)=0 at 0
v1ms: v(out)=-9.218031e-007 at 0.001
v2ms: v(out)=-4.900594e-016 at 0.002
Immer noch sind V1ms und V2ms ungleich Null. Wir geben noch nicht auf, wollen es wissen und verringern noch einmal
"Maximum Timestep", diesmal auf 1ns, starten die Simulation und . . .
. . . jetzt liegen im Plotfenster die Punkte dicht beieinander, aber die Simulation dauert nun ewig
und die Kurve zeichnet sich im Schneckentempo. Und die Messergebnisse?
v0: v(out)=0 at 0
v1ms: v(out)=1.807855e-009 at 0.001
v2ms: v(out)=-4.898586e-016 at 0.002
Zwar nochmal ein wenig näher an Null heran, aber eben nicht genau 0.000.... auf 99 Stellen!
Wir geben auf!
Hatte etwa Bob Pease doch recht getan, als er den Computer bei National Semiconductor vom Dach warf?
[URL: Bob Pease - ein Mann, ein Wort!] -- unbedingt anschauen!!
Fazit: Wir müssen uns bei jeder Simulation bewusst sein, dass sie nur ein Herantasten an die Wirklichkeit darstellt
und nicht in jedem Fall den theoretisch exakten Wert vermitteln kann.
Macht das Simulieren und Messen von simulierten Daten daher keinen Sinn? -- Nein, das glaube ich nicht,
wir dürfen nur nicht den Simulator "vergöttern".
Ein Ausweg aus dem Dilemma bleibt uns noch: wir runden auf fünf Stellen nach dem Komma.
Das vorherige Ergebnis verwenden wir als Parameter für eine neue Messanweisung:
wir benennen das Resultat V1ms_r (r für relativiert), wählen bei "Genre" PARAM
und geben bei "measured Quantity" folgendes ein: round(V1ms*100k)/100k.
Nach der Eingabe vergrössern wir "max Timestep" auf 10n, ausführen und das Ergebnis in der log-Datei ansehen:
v0: v(out)=0 at 0
v1ms: v(out)=3.387552e-006 at 0.001
v2ms: v(out)=-4.898561e-016 at 0.002
v1ms_r: round(v1ms*100k)/100k=0
v2ms_r: round(v2ms*100k)/100k=0
So, jetzt ist die Null da und unsere Welt wieder in Ordnung! Wie schön!
Von diesem letzten Schritt lernen wir noch eine Sache:
wir können ein Messergebnis als Parameter für weitere Berechnungen verwenden!
Wir nähern uns dem Finale dieser Sinus-Episode: wenn wir schon einmal dabei sind,
wollen wir auch "Berg" und "Tal" der Sinuswelle berechnen, die Maxima und Minima.
Wir ahnen schon, dass auch hier die Messwerte möglicherweise nicht die erwarteten +1 und -1 erreichen . . . -- mal sehen!
Wir platzieren wie schon gewohnt ".meas" auf dem Schaltplan und rufen mit Rechtsklick
den ".measure Statement Editor" [mSE] auf. Bei "Analysis" wieder TRAN, bei "Result Name" nehmen wir Vmax,
bei "Genre" augenfällig "MAX" und bei "Quantity" wie schon gehabt "v(out)".
Und da das Minimum berechnen ganz ähnlich ist, noch einmal den mSE aufrufen,
das Ergebnis nennen wir "Vmin", Genre "MIN" und Quantity gleichfalls "v(out)".
Ein grosser Unterschied zu den vorigen Messungen ist, das wir bei MAX und MIN einen Wert nicht
zu einem bestimmten Zeitpunkt, sondern innerhalb einer Zeitspanne (Intervall) suchen!
Ohne Angabe bzw. Eingrenzung des Intervalls sucht LTspice in der ganzen, im Plotfenster angezeigten Zeitspanne
nach dem Maximum, also von Null bis 2 Millisekunden. Wenn nun der zweite "Berg" eine winzige Idee grösser ist als der erste,
bleibt der erste logischerweise unberücksichtigt. Wenn wir wissen wollen, wie gross das Maximum in der ersten Periode ist,
dann müssen wir den Bereich eingrenzen. Wir könnten die ganze Periode nehmen, also von Null bis 1 Millisekunde.
Wenn wir nur das Maximum suchten, würde die positive Halbwelle bis 0.5ms reichen, aber da wir auch das Minimum
in der negativen Halbwelle messen wollen, ist die ganze erste Periode bis 1ms ein Muss.
Wie legt man denn nun den Bereich fest? Umgangssprachlich würde man für einen Bereich "von .. bis" erwarten,
aber diese Schlüsselwörter sind "versteckt", man sieht nur die kryptischen "TRIG" und "TARG" --- arrgh!
Ganz unten, etwas oberhalb des Test-Buttons, liest man "Error: Missing trig/from". Und wenn man dann zu TRIG aufschaut,
erkennt man ein Drop-down Menü, das klappen wir auf und wählen dort "FROM".
In das Eingabefenster rechts davon schreiben wir 0, bei "TARG" entsprechend "TO" und als Endwert geben wir 1ms ein.
Das war's fürs Maximum, für das Minimum verfahren wir ebenso.
Anschliessend führen wir die Simulation wieder aus und sehen in der log-Datei nach dem Ergebnis:
v0: v(out)=0 at 0
vmax: MAX(v(out))=0.999505 FROM 0 TO 0.001
vmin: MIN(v(out))=-0.999531 FROM 0 TO 0.001
Also doch! Auch hier wieder das Ziel +1 und -1 knapp verfehlt! Als letzten Versuch verringern wir noch einmal
"max timestep" auf 1u, Ergebnis:
v0: v(out)=0 at 0
vmax: MAX(v(out))=0.999998 FROM 0 TO 0.001
vmin: MIN(v(out))=-0.999998 FROM 0 TO 0.001
Wir könnten wieder runden, aber wirklich notwendig ist das natürlich nicht!
Wir kennen ja jetzt die Ursache, wissen, dass es systembedingt ist und müssen damit leben! Punkt!
Wer mag, kann es ja versuchen zu runden, er/sie wird sehen, dass dann die ersehnte Eins erscheint.
___ ___ ___
Fassen wir das, was wir in dieser ersten Lektion gelernt haben, noch einmal zusammen:
- Zahlenmässiges (benutzer-deklariertes) Messen von elektrischen Grössen geschieht erst nach vollendeter Simulation
- Messen erfolgt mit der Anweisung ".meas[ure]" - Punkt nicht vergessen, Abk. zu .meas ok!
- Bis man die Syntax der verschiedenen Messanweisungen auswendig kann, den "measure Statement Editor" benutzen
- man kann die Messanweisung auf einen bestimmten Analysetyp (TRAN, AC, DC usw.) beschränken: .meas TRAN ...
- jede Messung muss mit einem unverwechselbaren Namen (unique identifier) gekennzeichnet sein: .meas TRAN V0 ...
- die Messergebnisse findet man in der SPICE error / Output - Log - Datei (Rechtsklick-View- ...)
- Die Simulation selbst und die mit ihr verbundenen internen Messwerte, sie besitzen keine unendlich feine Auflösung,
geringe Abweichungen von dem theoretisch zu erwartenden Ergebnis sind möglich.
- Man kann mitunter die Anzahl der Messwerte vergrössern auf Kosten der Simulationszeit, bei der TRAN-Analyse z.B.
durch Verringern des "Maximum Timestep", [hier abgekürzt mts]:
mts = 1m --- 57 Messwerte --- Simulationsdauer 0.097s
mts = 1u --- 165 Messwerte --- Simulationsdauer 0.136s
mts = 1n --- 1956 Messwerte --- Simulationsdauer 18s
[woher ich das weiss, bleibt in dieser ersten Lektion noch mein kleines Geheimnis . . . ;-)]
- Innerhalb eines Intervalls kann man Maxima und Minima messen, indem man bei Genre "MAX" bzw. "MIN" selektiert.
- Bei solchen Messungen über eine Zeitspanne (Intervall) kann man den Messbereich eingrenzen mit den Schlüsselwörtern "FROM" und "TO".
Dieser gewählte Bereich muss sich innerhalb der Simulationsdauer befinden, sonst gibt es eine Fehlermeldung!
Das war's für diesmal. Wer Lust hat, kann die nicht gemachten Nulldurchgänge und Maximum/Minimum der 2. Periode versuchen zu messen.
RudiS
Zuletzt bearbeitet: