LTspice: Wenn ich einen Schaltplan in einen Subcircuit verwandle, verhält es sich anders. Warum?

Ich versuche, einen Niederfrequenz-LED-Blinker basierend auf einem BEAM Pummer (im Grunde ein Paar CMOS-Wechselrichter, die als Oszillator verdrahtet sind, plus eine Ladungspumpe) in LTspice zu modellieren. Ich habe die Basis-Blinkerschaltung an eine Spannungsquelle und einen LED-Ausgang angeschlossen, und sie scheint ordnungsgemäß zu funktionieren und alle etwa 2 Sekunden Stromspitzen von ~ 40 mA durch die LED zu erzeugen.

Aber wenn ich versuche, nur mit dem Flasher-Teil eine .subckt-Definition zu erstellen und diese in eine Testschaltung einzubeziehen, funktioniert es nicht richtig: Ich erhalte für einige Zeit einen verrauschten µA-Pegel-Ausgang durch die LED, die mit den Ausgangspins verbunden ist ns, dann sperrt der Oszillator.

  • Das SPICE-Fehlerprotokoll meldet Singular matrix: Check node d:u1:6#int1 Iteration No. 19, was bei der Standalone-Version nicht angezeigt wird. Ich bin mir nicht sicher, wie ich node finden soll d:u1:6#int1.
  • Meine anfängliche Vermutung war, dass eine GNDVerbindung nicht richtig hergestellt wurde, aber ich habe versucht, eine Massereferenz auf verschiedene Arten durch einen externen Stift zu leiten, und es machte keinen Unterschied.
  • PULSEEs gibt eine Eigenart darin, dass ich eine Spannungsversorgung mit 100% Einschaltdauer anstelle einer konstanten Gleichspannung in der Standalone-Version verwenden muss , oder der Oszillator startet nicht. Könnte das zusammenhängen? Das Einstellen der Spannung der Testschaltung auf PULSEschien keinen Unterschied zu machen.

Was könnte ich noch falsch machen? Ich habe die .subckt-Netzlisten-Pin-Reihenfolge dreimal mit der in der Symboldatei definierten Reihenfolge überprüft und bin mir ziemlich sicher, dass sie korrekt ist. Die Dokumentation sagt mir, dass das GNDbereits global verbunden sein sollte. Ist es eine Startup-Sache? Zwei Wechselrichter sind in einer Kette verdrahtet, um den Oszillator herzustellen. Muss ich beim Start den Eingang von einem explizit auf 5 V und den anderen auf 0 V setzen?

Als Referenz gibt es hier eine ZIP-Datei , die das Testschema und die .sub- und .asy-Definitionen sowie die eigenständige Version des Flasher-Subcircuits enthält, um zu beweisen, dass es tatsächlich funktioniert.

Jede Hilfe wird sehr geschätzt!

Antworten (1)

Um meine eigene Frage zu beantworten: Es scheint, dass LTspice erfordert, dass Textdateien mit der Windows Latin 1-Codepage und CRLF-Zeilenenden gespeichert werden. Ich verwende Wine auf einem Mac und mein Texteditor speichert standardmäßig als UTF-8. Ich vermute, LTspice interpretiert das UTF-8 µ auf Kondensatorwerten als etwas Ungültiges falsch, gibt aber verwirrenderweise keine Fehlermeldung aus.

Wenn man bedenkt, dass SPICE eine (ziemlich alte) Computersprache ist, ist das Ersetzen von u durch µ, das Probleme verursacht, wahrscheinlich nicht allzu überraschend.
LTSpice ist wählerisch in Bezug auf Einheiten. Wenn Sie beispielsweise Megaohm verwenden möchten, müssen Sie die Einheiten genau richtig buchstabieren, sonst ersetzt es stillschweigend einen anderen Widerstand, der um Größenordnungen entfernt ist. Es akzeptiert kein M, nur Meg mit einem großen M.
Nein, @Kaz, du hast nicht Recht. Auf keinen Fall ersetzt LTspice einen Widerstand „stillschweigend“! Wenn ein gültiges Suffix verwendet wird (M, m, Meg, MEG usw. sind alle gültig), dann muss sich LTspice nicht „beschweren“, sonst wird es natürlich. GEWÜRZE, inkl. LTspice, sind CASE INSENSITIVE, daher wird jede „Groß-/Kleinschreibungskombination“ von MEG (mEg, MeG,...) als „mega“ (x 1e6) interpretiert, sowohl „M“ als auch „m“ als „milli“ (x 0,001). Da die nachfolgenden Zeichen von SPICEs ignoriert werden, können auch Einheiten eingegeben werden, z. 4,7 uF (dass 'F' keine Wirkung hat). Aber Achtung: 0.001F = 0.001femtoFarad nicht 0.001Farad!
@EricBest Dies ist ein Fehler, da wir in der Elektronik-Kurzschrift Mund unterscheiden m. Wenn ich in einem Schaltplan 2M neben einem Widerstand sehe, bedeutet das für mich zwei Millionen Ohm, nicht zwei Milliohm. Es ist in Ordnung, Meg, MEG und meg als gleichwertig zu behandeln, aber nicht M und m.
@Kaz, es ist kein Fehler, es ist einfach eine Folge der Tatsache, dass SPICEs (historisch) CASE INSENSITIVE sind. Aus diesem Grund musste ein „Kompromiss“ gewählt werden, um diese allgemein bekannten Abkürzungen für „milli“ (m) und „mega“ (M) zu unterscheiden. Man muss sich einfach damit abfinden...
@EricBest: Haben Sie jemals versehentlich 10mig oder 10mug oder 10mfg oder ähnliches für einen Widerstandswert geschrieben? Es wird als 10 Milli interpretiert. Dies ist ein Usability-Fehler, es sei denn, Sie sagen, dass Fehlerberichte nicht erforderlich sind, und wenn Sie in Ihrer .asc-Datei etwas falsch machen, sind nasale Dämonen eine richtige Konsequenz.
@PlasmaHH: Nein. Bug ist ein Fehler beim Programmieren, der unbeabsichtigt entstanden ist. Das ist nicht der Fall. Die grundlegende Funktionalität von SPICEs besteht darin, dass sie ABSICHTLICH nur das !erste! Buchstabe, der UNMITTELBAR hinter dem Wert steht (andere beliebige Buchstaben können ohne Wirkung folgen), es sei denn, diese Buchstaben bilden das Wort MEG (oder seine Groß-/Kleinbuchstabenkombinationen), in diesem Fall wird es als Präfix 'mega' gewertet. Nur wenn dieser 1. Buchstabe nicht mit einem der erwarteten Präfixe identisch ist oder es sich nicht um den oben beschriebenen 'meg-Fall' handelt, gibt es eine Fehlermeldung.
@EricBest: Ein Bug ist auch ein Fehler in der Spezifikation, der sich später als nicht wirklich gewollt herausstellt und/oder sinnvoll ist. Wenn ein Taschenrechner 3 für 1+1 ausgibt, dann ist es ein Fehler, unabhängig von der Spezifikation, die dies sagt.
@PlasmaHH: Nein. Noch einmal: Das beschriebene Verhalten ist von Anfang an voll GEWOLLT. Ihr Vergleichsbeispiel ist falsch - es ist nicht analog. Wenn ein Taschenrechner 3 für 1+1 ausgibt, handelt es sich zweifellos um einen Fehler. Die Eingabewerte wurden richtig eingegeben und das erwartete Ergebnis ist falsch. Wenn in unserem Fall die Eingabe in Ordnung ist (gemäß der angegebenen Spezifikation), ist auch das Ergebnis in Ordnung. Sie können kein richtiges Ergebnis erwarten, wenn Sie einen Unsinn als Eingabe eingegeben haben. (Fortsetzung)
@PlasmaHH: (Fortsetzung) Die Spezifikation ist klar: was auch immer mit 'm' oder 'M' (der Preis für die inhärente Groß- und Kleinschreibung) beginnt, bedeutet immer "milli", es sei denn, es geht weiter mit 'zB ...', 'zB...', 'eG...' oder 'EG...', dann bedeutet es "mega". Diese Eigenschaft ermöglicht das Einfügen von Einheiten wie mV, mVolt, mA, Milliampere, mH, MilliHenry usw., da alle nachfolgenden Buchstaben ignoriert werden.
OMG der Penis wedelt hier so erstaunlich.
@PlasmaHH +1 'nasale Dämonen'