ungelöst Bitte um Überprüfung der KCL-demo (LTspice Marotte?)

[RudiS]

Ich habe aus Spass ein kleines Demo zum KCL (Kirchhoff's current law) gemacht und war nahe daran zu verzweifeln . . .
Das KCL besagt, dass die Summe der in einen Knoten hineinfliessenden Ströme gleich der Summe
der aus dem Knoten hinausfliessenden Ströme ist, wenn ich mich recht erinnere.
Die Schaltung ist total simpel:

Nach der Ausführung findet sich in der Log-Datei folgendes Ergebnis:



Die Messergebnisse sind keine irgendwelchen krummen Dezimalzahlen: 225mA !!
Dennoch ergibt die Subtraktion 0.225 - 0.225 nicht 0.0, wie es eigentlich zu erwarten wäre!
Denn: wie aus dem vorigen Bild ersichtlich, rechnet der NORMALE (!) solver: -0.225 - (-0.225) = 2.77...e-17 ! (eigentlich sollte das Null sein)

Schuld ist der Solver: Normal!!!!!
Schaltet man in den Einstellungen (Control Panel / SPICE / Solver) um auf "Alternate",
dann ist es ok:


Solch ein "Fehler" (ist das ein Fehler oder eine Marotte?) kann sehr schwer zu entdecken sein, ich habe auch etliche Minuten gebraucht,
bis mir die Idee kam, den Solver umzuschalten!
Mein Computer ist uralt (GA-EP45-UD3 von 2008!!), da habe ich immer so ein klein wenig Angst, dass die CPU falsch rechnet, oder man lastet
es LTspice an als Rundungsfehler oder was weiss ich.
Jedenfalls wäre es mir eine grosse Erleichterung zu wissen, dass bei anderen ebenfalls dieser Fehler auftritt. Mein LTspice ist 17.0.36.0 von Dez. 2022,
es gibt einige Versionen von LTspiceXVII!
Daher meine Bitte: Ladet die asc-Datei doch herunter und testet das mal, mit normalem Solver und alternate Solver, und berichtet über das Ergebnis.
Bitte auch die LTspice-Version angeben.

RudiS

 

[Hencobike]

Habe es mit LtSpice 24 getestet, ohne irgendeine weitere Einstellung vorgenommen zu haben. Bei mir sieht es so aus:

 

[spicer]

Bei mir mit V17.1.8 sieht es so aus:

Bitte, Anmelden oder Registrieren to view codes content!

Mit V17.0.37.0:

Bitte, Anmelden oder Registrieren to view codes content!

 

[RudiS]

Daniel, erst mal danke für Deine Bemühungen!
Das Problem war aber doch der normale Solver, da gab's bei mir eben den Fehler, und ich wollte wissen,
ob bei anderen Leuten mit dem normalen Solver der gleiche Fehler auftritt . . .
Mit dem alternate solver war bei mir ja auch alles ok.
Im übrigen gibt die Antwort darauf, ob das Ergebnis falsch ist, nur die LOG-Datei, nicht die bei .op-Simulation zuerst angezeigten Operation Points.
Die waren bei mir - egal mit welchem Solver - immer korrekt.

 

[RudiS]

@Henkobike
Leider hast Du kein Printout der LOG-Datei beigefügt, daher kann ich nicht ersehen, ob mit LTspice24 der Fehler auftritt.
Und nur die LOG-Datei zeigt, welchen Solver Du benutzt hast. Wie ich schon gesagt habe, mit dem alternate Solver war bei mir auch alles ok,
nur eben mit dem normalen Solver nicht.
Der normale Solver ist schneller, aber ungenauer. Trotzdem: selbst der billigste Taschenrechner zeigt: 0.225 - 0.225 = 0,
bei LTspice normalem Solver ist die Subtraktion 0.225 - 0.225 = 2.77e-17, eben nicht Null, und das verstehe ich nicht,
weil es sich bei dieser Subtraktion nicht um irgendwelche krummen Dezimalzahlen handelt.

 

[spicer]

Am Solver hab ich selbst nie etwas geändert. Wusste nichtmal, dass man den ändern kann.
Habe den auf standard.

 

[Hencobike]

Gilt auch für mich:

Am Solver hab ich selbst nie etwas geändert. Wusste nichtmal, dass man den ändern kann.
Habe den auf standard.

 

[Hencobike]

Habe diese Spice Einstellung,.Auf welche Einstellung sollte es umgestellt werden, um die Genauigkeitsprüfung zu checken?

 

[Udo]

Ich habe auf meinem PC LTspice XVII und LTspice 24.1.6 installiert, wobei ich LTspice 24.1.6 fast nie benutze. Grund: Die ständigen updates gehen mir auf den Zeiger und sind aus meiner Sicht ein Indiz dafür, dass es sich bei den updates hauptsächlich um Bug-fixes handelt.

Ich habe das Beispiel von RudiS auf beiden Versionen laufen lassen, und siehe da > LTspice XVII zeigt bei KCL....=0, egal welcher solver eingestellt ist. LTspice 24.1.6 dagegen liefert die von RudiS bemängelte Differenz.

Ob da evtl. Rundungsfehler oder standardmässig "eingebaute" Toleranzen verantworlich sind, kann ich nicht beurteilen.

Mein Fazit: Ich arbeite mit LTspice XVII, aus vielen anderen Gründen .....

 

[RudiS]

Hallo Udo,

zunächst vielen Dank für Deine Hilfe und Unterstützung. Vor allen freue ich mich, dass Du das für mich wichtige Ergebnis mitlieferst,
nämlich ob die Rechnung "in den Knoten hineinfliessende Ströme" (jct.a_in) minus "aus den Knoten herausfliessende Ströme" (jct.a_out) Null (in Zahlen: 0) ergibt
oder ob LTspice da einen Wert ungleich Null ausgibt:
Strom-hinein 　　 -0.225
Strom-heraus ー　-0.225
---------------------------------
Ergebnis: 　　　　　０(Null)

0.225 ist kein krummer Dezimalwert, selbst bei .opt measdgt=15 liefert LTspice keinen anderen, krummeren Wert zurück.
Daher ist es mir unbegreiflich, wieso diese Rechnung bei LTspice nicht Null ergibt, wo sogar ein Billigst-Taschenrechner zu 5 Euro
als Ergebnis Null ausgibt.

Mein persönlicher Eindruck insgesamt ist, dass LTspice unter der Hand von Mike Engelhardt konsistenter war . . .
Schade, dass er nicht mehr an Bord ist . . .

Eine letzte Bitte hätte ich noch an Dich: könntest Du mir noch sagen, welche Version (Versionsnummer und Datum)
von LTspiceXVII Du benutzt. Vielen Dank dafür.

RudiS

 

[RudiS]

Hallo Henkobike,

Danke, dass Du am Ball bleibst und Dich noch einmal meldest. In dem Screenshot von Dir ist der Solver auf "Normal" eingestellt, das ist ok.
Wichtig für mich ist das Ergebnis in der LOG-Datei (output log oder SPICE error log), da in dieser Datei die Ergebnisse der .measure-Anweisungen
aufgelistet sind.

Ich habe bei mir nach der Ausführung in LTspice in der Log-Datei folgende Ergebnisse:
jct.a_in: i(v1)=-0.225
i1: i(r1)=-0.1
i2: i(r2)=-0.125
jct.a_out: i1+i2=-0.225
m.true: true=99
m.false: false=-1
kcl: if(jct.a_in==jct.a_out, true, false)=-1
lts.marotte: jct.a_in-jct.a_out=2.77556e-017
[kl. Intermezzo: um Text aus dem Fenster der LOG-Datei direkt zu kopieren, den gewünschten Text mit der Maus selektieren
(Rechtsklick Kopieren funktioniert nicht!), und dann CTRL-C, das kopiert den selektierten Bereich.]

hineinfliessender Strom (jct.a_in) ist -0.225,
herausfliessender Strom ist auch -0.225, sind also beide gleich, richtig?
In der Zeile "kcl" vergleiche ich beide mit der if-Funktion:
wenn jct.a_in identisch ist mit jct.a_out, dann gib "true" aus, andernfalls gibt "false" aus.
LTspice gibt "-1" aus, der Wert für "false", sagt also, beide Ströme sind nicht gleich. Das ist aber FALSCH!
Sie sind nämlich gleich.

Was ich gern von Dir wissen wollte, ist: welchen Wert liefert LTspice bei Dir für "kcl", -1 oder 99 (false oder true)?
Ich habe bei mir noch eine Messanweisung beigefügt, die diesen LTspice-Fehler belegt:
.meas LTs.marotte param jct.A_in-jct.A_out

Wie Du siehst, fordert diese Anweisung LTspice auf, die Differenz "Strom-ein - Strom-aus" zu bilden,
das sollte eigentlich Null sein, ist es aber nicht, laut LTspice (normal solver) 2.77...e-17
Wenn es Dir also nicht zu viel Mühe macht, das noch einmal laufen zu lassen und mir mitzuteilen,
welcher Wert (99 oder -1) für "kcl" ausgegeben wird, wäre ich dir sehr dankbar. LTspice24 oder XVII??
Wenn XVII, bitte Versionsnummer und Versionsdatum beifügen.

RudiS

 

[Udo]

1. screenshot meiner LTspice version LTspiceXVII 17.0.37.0
2. Ergebnis mit solver - Einstellung "normal", wobei es mit dieser Version egal ist, ob bei diesem KCL-demo.asc File "normal" oder "alternate" benutzt wird.

 

[Hencobike]

Wenn ich es richtig gemacht habe, hier die *.log Ausgabe

 

[RudiS]

Ich danke hiermit noch einmal allen, die mich in meinem Verlangen unterstützt haben, eine verlässliche LTspice XVII version zu finden,
denn ehrlich gesagt bin ich von meiner Version (17.0.36.0) etwas enttäuscht, denn der "normal solver" könnte auch in anderen Fällen
ein falsches Ergebnis liefern, ohne dass es einem auffällt.

In gleichem Sinne meine ich mich erinnern zu können, dass der LTspice-interne Wert für "pi" in früheren Versionen mindestens 9stellig,
wenn nicht sogar 15stellig war. In meiner LTspice-Version ist er auf den Wert von 3.14159 geschrumpft.
Das mag in vielen Fällen ausreichen, aber bestimmt nicht in den Fällen, wo es auf hohe Präzision ankommt.
Zum Überprüfen folgendes eingeben (Versionsnummer ändern oder löschen):

.param LTsXVII.17.0.36.0_pi=pi
.meas LTs_pi param LTsXVII.17.0.36.0_pi



RudiS

P.S.: Ich möchte diese Anfrage noch ca. eine Woche auf "ungelöst" lassen, vielleicht gibt es ja noch andere Versionen,
bei denen der "normal solver" das eigentlich zu erwartende Ergebnis zurückliefert. Vielen Dank für Euer Verständnis.

 

[Udo]

Hallo RudiS, bei meiner Version LTspice XVII.17.0.37.0 habe ich nichts einstellen müssen, um auf das richtige Ergebnis zu kommen, also nix mit pi.

User-Defined Functions

User-Defined Functions​

The menu command Plot Settings=>Edit Plot Defs File allows you to enter your own function definitions and parameter definitions for use in the waveform viewer. These functions are kept in the file %HOMEPATH%\Documents\LTspiceXVII\plot.defs.

Then the syntax is the same as the .param and .func statements used for parameterized circuits. E.g., the line

.func Pythag(x,y) {sqrt(x*x+y*y)}

defines the function Pythag() to be the square root of the sum of its two arguments.

Similarly, the line

.param twopi = 2*pi

defines twopi to be 6.28318530717959. Note that it uses the internally defined constant pi of the waveform viewer.

Ich verstehe allerdings überhaupt nicht, was die einfache Differenzbildung in Deinem Beispiel mit pi zu tun haben sollte.

Udo

 

[Udo]

Ich hänge noch ein "Help"-file an. Auf Seite 105 sind die von LTspice XVII intern verwendeten Konstanten gelistet.

@spicer. Daniel, vielleicht kannst Du entscheiden, wo man dieses nützliche file bevorzugt ablegt, um allen Usern Zugang zu verschaffen. Es ist allerdings in english language.
----
Udo

 

[RudiS]

Hallo Udo,

Es tut mir leid, durch ungeschickte Wortwahl Missverständnisse heraufzubeschworen zu haben.

In gleichem Sinne meine ich mich erinnern zu können, dass der LTspice-interne Wert für "pi" in früheren Versionen mindestens 9stellig,
wenn nicht sogar 15stellig war.

Hier wollte ich mit "in gleichen Sinne" eigentlich nur ausdrücken, dass frühere Versionen von LTspiceXVII unter M. Engelhardt konsistenter waren -- pi selbst hat mit der KCL-Sache gar nichts zu tun. Gemäss dem Motto: viele Köche verderben den Brei, geht meine Befürchtung dahin, dass unter den neuen Köchen LTspice an "Geschmack" verloren hat. Es ist bis jetzt nur eine dumpfe Ahnung, dass LTspice möglicherweise an Wert und Zuspruch verliert, und was man so über LTspice24 hört und liest, ist eher beunruhigend.

Aber schau doch mal, was ich in dem vorigen Zitat sage: in meiner jetzigen Version von LTspice (17.0.36.0) ist der Wert für pi nur 3.14159, ich meine aber -- wenn meine Erinnerung mich nicht betrügt --, dieser wäre in FRÜHEREN Versionen 9stellig, wenn nicht gar 15stellig gewesen. Damit will ich nicht ausschliessen, dass in einer nachfolgenden Version wie z.B. 17.0.37.0 dieser Wert korrigiert, sprich mit mehr Stellen ersetzt wurde, das weiss ich jedoch nicht, weil ich keine nachfolgende Version im Einsatz habe. Das pi meiner Version ist eben nur 5stellig:



Es würde mich allerdings schon interessieren, ob in Deiner LTspice-Version die Zuordnung der internen Konstante "PI" an einen Parameter mehr Stellen aufweist.

RudiS

 

[Udo]

Hallo Rudi(S),

meine Version zeigt beim Sim-Test exakt dieseleben pi-Werte an, wie bei Deiner Version. Die Frage ist aber: Ist das nur eine abgekürzte Darstellung, und es wird mit der internen Konstanten gerechnet oder Nicht ?
Mike Engelhardt können wird nicht mehr fragen, aber Analog.com.

Ansonsten gilt der Grundsatz: Wenn man sich auf eine(n) neue(n) Freund:in (...Version) einlässt, sollte man Vorsicht walten lassen.
---
Udo

 

[RudiS]

Hallo Udo,

danke für die schnelle Antwort, ich kann eigentlich nur Bedauern äussern, dass bei Dir PI auch nur als verkürzter Wert zugeordnet wird.
Ich werde wahrscheinlich noch irgendwo auf einer HDD eine ältere Version besitzen, wenn ich sie finde und es ein anderes Ergebnis für PI gibt,
dann melde ich mich noch einmal.

Die Frage ist aber: Ist das nur eine abgekürzte Darstellung, und es wird mit der internen Konstanten gerechnet oder Nicht ?

Ehrlich gesagt, halte ich das für unwahrscheinlich, es würde auch keinen Sinn machen. Von einem wissenschaftlichen Standpunkt her
bin ich der Auffassung: wenn es einen genaueren Wert gibt (Frage: wie viele Nachkommastellen wären angemessen?), dann sollte man
den auch anwenden. Wem's weniger reicht, der kann ja immer noch runden: .meas rounded.pi param round(my.pi*100k)/100k

Ich habe noch einen Test gemacht, ohne PI gesondert anzeigen zu lassen:



Wie Du siehst, gibt es durchaus einen Unterschied. Der mag für uns Privatleute unbedeutend sein, wer aber beruflich mit LTspice arbeitet
und Vorgaben des Auftraggebers erfüllen muss, der kann diese Differenzen möglicherweise nicht so einfach ignorieren.

Grüsse zum morgigen Osterfest,

Rudi

 

[Hencobike]

Hier noch meine Log-Ausgabe für LTspice 24.0.9