N'Abend.
Folgende Direktiven stehen auf dem Plan:
.param U_soll = 19
.param I_max = 4.5
.param R4 = 80600
.param R5 = 20000
.param R_last = U_soll / I_max
.param R_fb1 = (U_soll / 0.8 - 1) * 1000
.param U_rng = 9.4 / (R4 + R5) * R5
.param U_sense_max = 0.173 * U_rng - 0.026
.param R_sense = U_sense_max / (1.3 * I_max)
Der Plan funktioniert auch, die Ergebnisse der Schaltung basierend auf
den v.g. Berechnungen sind soweit korrekt. Mit Hilfe einer externen
Berechnung käme ich auch zu den Werten - aber warum zweimal rechnen?
Die Methode mit "View -> SPICE Error Log", wie im Forum schon mehrfach
beschrieben greift nicht. Gibt es in LTspice IV Änderungen gegenüber
früheren Versionen?
Ich verstehe deine Frage nicht ganz.
Wenn du die Werte von berechneten Bauteileparametern, die in der
Schaltung verwendet werden, ablesen willst, dann kannst du die im
expanded listing sehen, wenn diese Option im Control Panel gesetzt ist.
Control Panel -> Operation x Generate Expanded Listing
Dann die Simulation laufen lassen. Wenn die durch ist,
Vew -> SPICE error Log
Dort sieht man dann die berechneten Bauteilewerte in der Netzliste.
Wenn du nur Berechnungen sehen willst, dann .MEASURE Kommandos in den
Schaltplan einfügen.
.meas Usense_max_ param Usense_max
Das Ergebnis ist dann auch in dem Error Logfile.
Helmut S. schrieb:> Control Panel -> Operation x Generate Expanded Listing
Ich nehme an, dass du eine Windows Version verwendest, die Max Version
scheint da eine andere Implementierung zu haben.
Bei mir:
a) rechte Maus-Taste -> Submenu -> View -> SPICE Netlist -> darauf folgt
das Fenster mit der Datei.net
b) Cursor in das Fenster setzen -> Maus-Taste -> Generate Expanded
Listing -> es erfolgt die Ausgabe der Fehlermeldung "Trouble expanding
netlist."
Die Sache mit den "meas"-Direktiven muss ich mir mal zu Gemüte führen.
Hallo.
Meine Direktiven habe ich um den folgenden Eintrag ergänzt:
.meas U_sense_max param U_sense_max
Im Logfile steht dann:
Measurement "u_sense_max" FAIL'ed
Ich bin mir aber noch nicht im klaren, was die o.g. Zeile bedeuten bzw.
bewirken soll. Mal sehen, vllt finde ich eine Erklärung hierzu.
Hallo.
Ich habe gerade beim Mac noch'n versteckten Knopf für "Generate Expanded
listing" gefunden. Jetzt stehen die gerechneten Bauteilwerte im Log-File
- das ist ja schon mal was. :-))
Die meas-Directive habe ich geändert, aber der lauf dauert etwa 15
Minuten. Mal sehen was später drin steht.
Hallo.
Also. das Eintragen der gerechneten Bauteilwerte in die durch "Generate
Expanded Listing" erweiterte Log-Datei funktioniert. Aber die
Erweiterungs-Option muss vor dem Öffnen der Logdatei gesetzt sein.
Das Eintragen von Werten in die Log-Datei bei der Verwendung der
"meas"-Directive funktioniert nur, wenn der Ausgabenamen einen
Unterschied zum Parameternamen aufweist.
.meas U_sense_max param U_sense_max <<-- das funktioniert nicht.
.meas U_sense_max_Wert param U_sense_max <<-- so ist es ok
Ich habe beide Varianten getestet.
Hallo.
Jetzt wollte ich es noch einmal ganz genau wissen.
Die Directiven habe ich wie folgt im Schema eingetragen.
.meas x1 param R_fb1
.meas x2 param U_rng
.meas x3 param R_sense
.meas x4 param U_sense_max
Nach Ablauf der Analyse habe ich dann die folgende Darstellung im
Log-File gefunden:
x1: r_fb1=22750
x2: u_rng=1.86879
x3: r_sense=0.0508205
x4: u_sense_max=0.2973
Die meas-Directive kann aber noch viel mehr. Es lohnt sich auf jeden
Fall, das Internet zu plündern. Dabei habe ich diesen Link gefunden:
https://rze-falbala.rz.e-technik.fh-kiel.de/komiue/LTSpice-Anleitung/LTspiceIV(Mai2010).pdf
Aus dem Inhalt der Kurzanleitung lassen sich einige gute Hinweise
entnehmen.
Hallo.
Eine kleine Beobachtung als Nachtrag zu den MEAS-Kommandos.
Ich will ja nicht knauserig sein, was LTspice mit den Nachkommstellen so
macht, im allgemeinen reichen mir, wenn nötig, 2 höchsten 3
Nachkommstellen. Aber es ist schon lustig, was LTspice da macht. Schauen
wir mal nach, wie das so abläuft.
.param R_sense = U_sense_max / (1.3 * I_max)
R_sense ist aber kein einfacher Bauteilwert, sondern stellt den
Widerstandswert von 2 parallel geschalteten Widerständen dar. Im Schema
habe ich tatsächlich 2 Widerstände verwendet, obwohl für die Simulation
einer gereicht hätte. Also habe ich den Bauteilwert für R22 und R23 im
Schema wie folgt zugewiesen
{R_sense * 2}
Das funktioniert auch prächtig, wie ich in der Log-Datei nachlesen kann.
r22 n013 0 0.101641093609284
r23 n013 0 0.101641093609284
Also, aus R_sense werden die Werte für R22 und R23 mit 15 (in Worten
fünfzehn) Nachkommastellen berechnet, woraus man schließen kann, dass
der Wert von R_sense schon ebenfalls mindestens 15 Nachkommastellen
aufweisen muss. Doch schauen wir weiter.
Nach Abschluss der TRAN-Analyse werden die MEAS-Kommandos abgearbeitet,
speziell dieses
.meas x3 param R_sense
wobei die Variable R_sense verwendet wird, bei der bekanntlich ein Wert
mit mindestens 15 Nachkommastellen vorliegen muss. Aber in der Log-Datei
findet sich folgende Darstellung
x3: r_sense=0.0508205
Ich meine, woher weiß LTspice, dass ich mit 15 Nachkommastellen ohnehin
nix am Hut habe? Denn bei dieser Wertausgabe werden von ehemals 15
Nachkommastellen doch glatt 8 Nachkommastellen unterschlagen, wobei die
7 verbliebenen eh noch zuviel sind, eine Wertausgabe von 0.051 wäre doch
mich allemal ausreichend.
Flash schrieb:> Ich meine, woher weiß LTspice, dass ich mit 15 Nachkommastellen ohnehin> nix am Hut habe?
Ich vermute, LTspice gibt den Wert so aus, wie er bei der Lösung der
Gleichung - d.h. die Abweichung zwischen zwei Iterationen unterschreitet
die gesetzten Grenzen - anfällt.
> eine Wertausgabe von 0.051 wäre doch mich allemal ausreichend.
Eigentlich gäbe es dafür die Option measdgt - es funktioniert aber nur,
wenn man sie größer als den Defaultwert von 6 setzt.
1
--- Expanded Netlist ---
2
r1 nc_01 0 0.333333333333333
3
.op
4
.opt measdgt=3 list
5
.end
6
x1: r1=0.333333
7
8
--- Expanded Netlist ---
9
r1 nc_01 0 0.333333333333333
10
.op
11
.opt measdgt=8 list
12
.end
13
x1: r1=0.33333333
Bleibt also nur das händische formatieren mit round(*).
> eine Wertausgabe von 0.051 wäre doch mich allemal ausreichend.
Eigentlich gäbe es dafür die Option measdgt - es funktioniert aber nur,
wenn man sie größer als den Defaultwert von 6 setzt.
Normalerweise beschweren sich ja die Leute, daß sie zu wenig Stellen
hinter dem Komma haben. :-)
Wobei eh die Frage ist, mit welchem Gleitkommaformat LTspice intern
arbeitet. Wenn es nur die 32Bit-Version ist, dann wären die Mantisse
23Bit. Das sind also etwas mehr als 6 Stellen im Dezimalsystem. Davon
abziehen müßte man noch das numerische Rauschen und Sättigungseffekte
durch z.B. krumme Kennlinien. Also 4 Stellen Genauigkeit würde ich mal
sagen. Was völlig reicht. Früher gabs Rechenschieber und damit wurden
Kriege gewonnen oder verloren.
Helmut S. schrieb:> Normalerweise beschweren sich ja die Leute, daß sie zu wenig Stellen> hinter dem Komma haben. :-)
Ich beschwer' mich ja auch nicht. Ich find's halt nur lustig - rein
oberflächlich betrachtet.
Der Einsatz eines errechneten Parameters in der weiteren Simulation
sollte schließlich mit der höchsten Genauigkeit erfolgen, schlechter
wird's eh von selbst - soweit ist das Verhalten von LTspice sogar sehr
löblich.
Im übrigen ist das Verrechnen von gaaanz großen Werten mit gaaanz
kleinen Werten in der früheren 8-bit-Zeit auf dem PC schon ein großes
Risiko gewesen, für ganz extreme Genauigkeiten gab's die schwerfällige
BCD-Arithmetik. Aber bei 64 Bit sollte das heute kein Problem mehr sein.
globul schrieb:> Ich vermute, LTspice gibt den Wert so aus, wie er bei der Lösung der> Gleichung - d.h. die Abweichung zwischen zwei Iterationen unterschreitet> die gesetzten Grenzen - anfällt.
Nee, an der Stelle war keine Iteration im Spiel, zugrunde lag eine
lineare Gleichung x = y / (a * b). Meine Fragestellung war auch nicht
wirklich ernst gemeint. LTspice hatte den Wert schon einmal berechnet
und an zwei verschiedenen Stellen mit unterschiedlicher Anzahl von
Nachkommastellen ausgegeben - das liegt wohl eher in der Laune des
Programmierers, als er die Ausgabe unter MEAS codiert hatte.
Abdul K. schrieb:> Wobei eh die Frage ist, mit welchem Gleitkommaformat LTspice intern> arbeitet.
[link zu ltwiki entfernt - da war Flash schneller]
Interessant wäre zu wissen, wie das dann mit dem Alternate Solver
funktioniert. Aus der Hilfe: "Typically the alternate solver will
simulate at half the speed of the normal solver but with one thousand
times more internal accuracy."
Gut, der Matrix-Compiler kann einiges optimieren - aber abgesehen von
ein paar Brosamen in
http://cds.linear.com/docs/en/lt-journal/LTJournal-V24N4-01-df-SPICEDifferentiation-MikeEngelhardt.pdf
(wurde hier schon mal diskutiert), hab ich noch nichts genaueres dazu
gefunden.
globul schrieb:> Gut, der Matrix-Compiler kann einiges optimieren - aber abgesehen von> ein paar Brosamen in> http://cds.linear.com/docs/en/lt-journal/LTJournal-V24N4-01-df-SPICEDifferentiation-MikeEngelhardt.pdf> (wurde hier schon mal diskutiert), hab ich noch nichts genaueres dazu> gefunden.
Nun habe ich gerade mal gelernt, den Namen von LTspice korrekt schreiben
zu können. Gut. Und dass der olle Newton (wo ist eigentlich der Kollege
Raphson gebleiben?) bei LTspice mit an Bord ist, konnte ich heute in
einem Logfile nachlesen. Mit Newton-Iterationen habe ich schon so manche
kommerzielle Schlacht gewonnen.
Und da es mich bis jetzt außer etwas Zeit letztlich auch kein Geld
gekostet hat, hatte ich eh nie die Absicht, zu meckern. Nach der Lektüre
des oben verlinkten Artikels wächst mein Vertrauen in LTspice ungemein.
Bisher hatte sich das Gefälle so dargestellt: Berkley's Pspice oben und
LTspice darunter. Diese Ansicht muss ich wohl revidieren. Obwohl, es
gibt ein paar Mängelpunkte, die sind aber auch Mac-spezifisch und haben
mit dem eigentlichen Kern von LTspice nichts zu tun. Ich denke die paar
Probleme werden dann mit der zeit auch noch gelöst werden.
Flash schrieb:> Berkley's Pspice oben und> LTspice darunter.
Pspice ist aber nicht von Berkley sondern von OrCad (inzwischen gehört
es zu Cadence…hab schon ewig nicht mehr nach PSpice geschaut). Aus
Berkeley kommt nur der Unterbau, auf den quasi alle Simulatoren
aufbauen: Spice 3F5. ;)
> Interessant wäre zu wissen, wie das dann mit dem Alternate Solver
funktioniert. Aus der Hilfe: "Typically the alternate solver will
simulate at half the speed of the normal solver but with one thousand
times more internal accuracy."
Wie wäre es mit "x86 Extended Precision Format"
https://en.wikipedia.org/wiki/Extended_precision
