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.
Mach mal den Namen etwas anders. .meas U_sense_max_ param U_sense_max Alternative .meas U_sense_max555 param U_sense_max
:
Bearbeitet durch User
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.
Danke für die Bestätigung. Das gleiche Verhalten hatte ich in Windows vor einiger Zeit festgestellt.
:
Bearbeitet durch User
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(*).
1 | .opt measdgt=8 List |
2 | .param r1=1/3 |
3 | .op |
4 | .meas x1 param round(r1*1k)/1k |
5 | |
6 | x1: round(r1*1k)/1k=0.333 |
(*) http://ltwiki.org/index.php5?title=Undocumented_LTspice#Format_and_Layout
> 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.
:
Bearbeitet durch User
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.
Hallo. Das habe ich gerade gefunden: LTspice verwendet grundsätzlich das Gleitkommaformat mit 11-bit-Exponent und 52-bit-Mantisse. Siehe hier: http://ltwiki.org/index.php5?title=Undocumented_LTspice#Numerical_Accuracy.2FDynamic_Range
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
Helmut S. schrieb: > Wie wäre es mit "x86 Extended Precision Format" Klingt einleuchtend - ich seh schon, manchmal denke ich zu kompliziert ;)
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.