Forum: Analoge Elektronik und Schaltungstechnik LTspice: OpAmp-Typ als Parameter?


von Uhu U. (uhu)


Lesenswert?

Ist es möglich, in LTspiceIV den OpAmp-Typ, der für eine Simulation 
verwendet wird, als Parameter definieren?

von Hannes J. (Firma: _⌨_) (pnuebergang)


Lesenswert?

Versuch es mal ähnlich wie in 
http://sci.tech-archive.net/Archive/sci.electronics.cad/2004-10/0021.html 
für Transistor-Modelle beschrieben.

Vielleicht geht es auch mit subckts.

von Helmut S. (helmuts)


Lesenswert?

Hallo,

das geht meines Wissens nach nur, wenn die Modellnamen Zahlen sind.

.STEP param M list 324 1013 1028

Statt dem Originalmodellnamen schreibst du {M} an den Opamp im 
Schaltplan.


Die Opampmodelle müssen dann so aussehen.

.subckt 324 ......
.ends

.subckt 1013 .....
.ends

von Uhu U. (uhu)


Lesenswert?

Ja, das steht in dem von Hannes Jaeger verlinkten Beitrag.

Ich habe allerdings das Problem, daß das mit der Syntax für models 
zusammen paßt, aber nicht mit der für subpackages. Die sind letztlich 
ein Pfad im Dateisystem.

Da hilft wohl nur rumprobieren. Das sieht alles sehr nach einem 
Syntaxentwurf mit minimalem Einsatz von Hirnschmalz aus. Nicht sehr 
vertrauenserweckend...

von Helmut S. (helmuts)


Lesenswert?

Uhu Uhuhu schrieb:
> Syntaxentwurf mit minimalem Einsatz von Hirnschmalz aus. Nicht sehr
> vertrauenserweckend...

Nach dem Kommentar werde ich deine Fragen in Zukunft wohl ignorieren.
Am besten du schreibst dir selber ein SPICE-Programm. Als 
Besserwisser(Ahnungsloser?) sollte das für dich ja kein Problem sein.

Helmut

von Uhu U. (uhu)


Lesenswert?

Helmut S. schrieb:
> Als
> Besserwisser(Ahnungsloser?) sollte das für dich ja kein Problem sein.

Ich hab mir spaßeshalber mal die Quellen von Spice 3f4 runtergezogen und 
in die Verarbeitung des Eingabetextes gesehen.

Das ist alles gewachsen und handgestrickt.

von Simon K. (simon) Benutzerseite


Lesenswert?

Ist ja auch Open-Source. ;-)

von Uhu U. (uhu)


Lesenswert?

Simon K. schrieb:
> Ist ja auch Open-Source. ;-)

Das ist mit Sicherheit nicht der Grund. Von dieser Version gingen die 
aktuellen xSpice-Versionen mal aus, vor bald 20 Jahren. Die Sprache 
wurde seither offenbar nicht überarbeitet.

von Ach ja (Gast)


Lesenswert?

Uhu Uhuhu schrieb:
> Die Sprache
> wurde seither offenbar nicht überarbeitet.

Dann mach. Was schätzt du, du hast die Implementierung in drei Wochen 
fertig?

von Yalu X. (yalu) (Moderator)


Lesenswert?

Uhu Uhuhu schrieb:
> Ich habe allerdings das Problem, daß das mit der Syntax für models
> zusammen paßt, aber nicht mit der für subpackages. Die sind letztlich
> ein Pfad im Dateisystem.

Das stimmt nicht. Subckt-Namen und Dateinamen von Einzelmodellen oder
Bibliotheken sind zwei völlig unterschiedliche Dinge, zwischen denen es
keinerlei Abhängigkeiten gibt. Deswegen können Subckt- genauso wie
Model-Namen als Parameter definiert werden, solange die Namen die Text-
repräsentation numerischer Werte sind. Die Dateinamen spiele dabei keine
Rolle.

> Das sieht alles sehr nach einem Syntaxentwurf mit minimalem Einsatz
> von Hirnschmalz aus.

Wieder mal ein echter Uhu: Gerade erst mit LTSpice angefangen, vor ein
paar Tagen noch nicht einmal die AC-Analyse gekannt, aber trotzdem
gleich mal Stunk machen :-/

Das hat überhaupt nichts mit der Syntax und noch weniger mit der Menge
des bei deren Entwurf eingesetzten Hirnschmalzes zu tun. Obwohl LTSpice
viele Erweiterungen gegenüber Ur-Spice hat (z.B. auch den PARAM-Befehl),
ist die Festlegung von Bauteiltypen per Parameter ein in der dezeitigen
Version nicht (offiziell) vorgesehenes Feature. Da ist nichts Hirnloses
dabei, und wenn sich die Entwickler durch dumme Äußerungen wie den
deinigen nicht entmutigen lassen, werden sie dieses Feature vielleicht
irgendwann implementieren.

Wie die Beiträge von Hannes und Helmut zeigen, ist die Parametrierung
von Bauteiltypen dennoch möglich, allerdings nur mit einem kleinen Hack:
Parameter in LTSpice sind grundsätzlich numerische Werte bzw. Ausdrücke.
Ein Subckt-Name hingegen ist ein Textstring. Ein undokumentiertetes
Feature erlaubt jedoch die Verwendung von Parametern und Ausdrücken auch
als Subckt-Name. Die numerischen Werte werden in diesem Fall einfach
durch ihre Textrepräsentation ersetzt. Das ist nicht sehr konsistent,
aber nützlich. Deswegen und weil dieses Feature offiziell ja gar nicht
existiert, kann man den Entwicklern hier keinerlei Vorwürfe machen.

Noch ein kleiner Tipp: Du brauchst, um die Opamps in "numerische" Namen
umzubenennen, nicht die Bibliotheksdateien zu ändern. Es genügt, zu
jedem verwendeten Typ einen Wrapper mit neuem Namen zu schreiben, in dem
ggf. auch die Anzahl und Reihenfolge der Anschlussknoten angepasst
werden kann. Das hatten wir aber alles schon:

  Beitrag "Re: LTSpice: opamp sweep parametrisieren"

von Simon K. (simon) Benutzerseite


Lesenswert?

@Yalu: Misst, den Thread hab ich die ganze Zeit gesucht. Danke!

von Hannes J. (Firma: _⌨_) (pnuebergang)


Lesenswert?

Helmut S. schrieb:
> Uhu Uhuhu schrieb:
>> Syntaxentwurf mit minimalem Einsatz von Hirnschmalz aus. Nicht sehr
>> vertrauenserweckend...
>
> Nach dem Kommentar werde ich deine Fragen in Zukunft wohl ignorieren.
> Am besten du schreibst dir selber ein SPICE-Programm. Als
> Besserwisser(Ahnungsloser?) sollte das für dich ja kein Problem sein.

Ich glaube, ich spare mir den Uhu in nächster Zeit auch. Da suche ich 
extra die Infos raus, und statt mal damit rumzuspielen setzt er einen 
dicken Haufen in den Thread.

von Uhu U. (uhu)


Lesenswert?

Nehmen wir das Beispiel

   SYMBOL Opamps\\LT1007 -176 112 R0

aus dem .asc-File.

Yalu X. schrieb:
> Das hat überhaupt nichts mit der Syntax ... zu tun.

Wenn man an Stelle des Symbolpfades eine syntaktische Variable 
<expression> zuläßt und die formale Sprache eine Produktion ähnlich wie

   <expression> ::= <string> | <variable>

enthält, dann könnte man sowas ohne Hacks und Gemurkse auflösen und es 
wäre spezifiziert.

Entsprechendes müßte man für .step, .param usw. machen und am Ende hätte 
man eine ziemlich einfach zu handhabende, übersichtliche Steuersprache.

Die Notation war schon in den 1950er Jahren bekannt und wurde schon für 
die Sprachdefinition von Algol 60 benutzt. Sie hat den Vorteil, daß man 
solche Sprachen sehr einfach implementieren kann.

So viel zur Syntax.

Aber vielen Dank für deinen Hinweis, wie man die Sache flicken kann, 
ohne an den Libs rumzubasteln. Dein Vorschlag leistet viel mehr, als 
das, was ich suchte: ich wollte einfach nur eine Variable, in die ich 
den Typ eintragen kann, statt zum Probieren immer jeden Opamp einzeln zu 
ersetzen.

Ich habs letztlich mit dem Replace-Befehl des Editors gemacht. Auch 
häßlich, aber sehr simpel.

Bitte 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
Noch kein Account? Hier anmelden.