Ist es möglich, in LTspiceIV den OpAmp-Typ, der für eine Simulation verwendet wird, als Parameter definieren?
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.
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
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...
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
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.
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.
Uhu Uhuhu schrieb: > Die Sprache > wurde seither offenbar nicht überarbeitet. Dann mach. Was schätzt du, du hast die Implementierung in drei Wochen fertig?
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"
@Yalu: Misst, den Thread hab ich die ganze Zeit gesucht. Danke!
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.