¿Por qué LTSpice a veces deja de imprimir a mitad de camino de una simulación?

(Supongo que está realizando un análisis .TRAN)

Primero que nada, deberías haber proporcionado un esquema para simular. Lo sé. Piensas que este es un problema común con una explicación simple. Pero no es nada de eso, en absoluto. Y aunque ocasionalmente encuentre este problema, puede ser que cada vez sea por una razón diferente que requiera una explicación diferente. Por lo tanto, usted mismo no presta servicio al no proporcionar un ejemplo específico. En su lugar, nos pide que escribamos un capítulo o dos, tal vez incluso un libro, sobre el tema. Y eso es pedir, demasiado.

De hecho, hay un capítulo sobre este tema incluido en "El libro de las especias", de Andrei Vladimirescu. Capítulo 10. Te recomiendo que lo consigas y lo leas. Tenga en cuenta que el libro no es sobre LTspice; en cambio, se trata de casi todos los programas de todos Spice. Y todos ellos tienen problemas similares a los que usted describe.

Muchas implementaciones comerciales de Spice tienen una serie de heurísticas adicionales para ayudarles a superar algunos de los casos más importantes. Sin embargo, como todo, estos mismos son a menudo espadas de dos filos que cortan de manera sorprendente. Puede encontrar que un programa comercial de Spice lo hace mucho mejor simulando una determinada categoría de situaciones, mientras que ahora lo hace más pobremente en otros (o, donde necesita "especificar algo específico" en su configuración para recuperar el comportamiento anterior). Toda área temática requiere una experiencia que pocas personas (según mi experiencia) posean en su totalidad.

(Conozco exactamente a una UNA persona que considero que está "siempre bien situada para resolver cualquier problema de convergencia" porque nunca he visto un caso en el que no fue capaz de identificar exactamente dónde agregar algo para que Spice funcione bien en el problema.

Para las simulaciones .TRAN (y esas no son las únicas funciones donde surgen problemas), permítanme enumerar algunas ideas sin ningún orden en particular que se apliquen a cualquier programa Spice, incluyendo LTspice:

1. Busque casos en su circuito en los que la proporción del componente de mayor valor con respecto al componente de menor valor supere unos nueve órdenes de magnitud. Rangos inusuales como este sugieren fuertemente la necesidad de una corrección de algún tipo.
2. El almacenamiento de carga insuficiente conduce a tiempos de conmutación que se acercan al tiempo cero y esto puede resultar en una seria desaceleración al principio o más tarde durante la simulación.
3. Los MOSFET tienen más problemas de convergencia que los BJT, ya que los MOSFET tienen una autoconducción de cero en DC para sus puertas. Los BJT, por supuesto, no tienen ese problema. Además, Spice asume que los BJT están realizando durante la primera iteración, mientras que los MOSFET se supone que no son conductores (a menos que se proporcione su parámetro NFS por debajo del umbral). Por lo tanto, si los MOSFET están presentes, preste especial atención a los parásitos y Los parámetros del modelo. También tenga en cuenta que un circuito con muchos MOSFET, inicialmente considerados no conductores, hace que un circuito comience de manera muy diferente a un circuito BJT poblado donde se supone que son conductores. Esta es toda una área propia.
4. Muchas implementaciones de Spice (incluidas LTspice) ofrecen diferentes métodos de solución. Trapezoidal (y / o modificado ) y Gear de orden variable, son dos de estas categorías básicas. LTspice ofrece una manera de seleccionar entre estos. Podría encontrar que uno funciona donde el otro funciona peor.
5. Verifique los modelos de dispositivos para ver si proporcionan conductancias poco realistas.
6. Busque en .OPTIONS para LTspice: ABSTOL y RELTOL. Relájalos y ve si eso ayuda.
7. Reducir el paso de tiempo máximo.
8. Use TRTOL y configúrelo en un valor grande (como 1000 o algo así).
9. En lugar de relajar RELTOL, intente ajustarlo para evitar eludir algún dispositivo "inactivo" en el esquema.

En el pasado, solo he usado algunos programas Spice diferentes. Por lo tanto, mi experiencia no es lo suficientemente buena como para darle algo parecido a una encuesta de ellos. Pero ninguno de ellos que he experimentado está libre de áreas problemáticas. Todos ellos tienen dificultades cuando se enfrentan a ciertas simulaciones. Algunos tienen mejores heurísticas para algunos problemas, mientras que hacen más mal en otros problemas. Ninguno de ellos ha sido, creo, una panacea que resuelve todos los problemas que enfrentan. Y todos los mejores (NO considero que MULTISIM valga la pena, pero no lo he usado en años, así que quizás hoy sea mejor) tienen suficientes áreas problemáticas que ninguno de ellos parece "el camino a seguir".

Escribí vagamente porque no proporcionaste ningún circuito. (Desde luego, no puedo elegir algo específico en LTspice, sin ningún esquema). Quizás estos pensamientos ayuden. Podría haber tenido suerte. Pero ... sería mucho mejor si proporcionara un caso específico.

LTspice utiliza un solucionador que se basa en la convergencia. También utiliza un paso de tiempo variable, lo que significa que el paso de tiempo se basa en parámetros de precisión.

Si el siguiente paso de tiempo no es convergente, se 'respalda' y lo intenta de nuevo, explicar esto en detalle requeriría un conocimiento de los métodos numéricos (de los cuales solo entiendo los conceptos básicos). Si no vuelve a converger y no cumple con los requisitos de tolerancia, realiza una copia de seguridad y vuelve a intentarlo, lo que hace que la simulación no pueda resolver nuevos pasos de tiempo.

Si tiene problemas de convergencia, intente esto (FUENTE: LT spice wiki )

  

Agregue una pequeña conductancia de 1e10 (= 10GOhm) paralela a cada diodo de transistores y diodos.

.options gmin=1e-10   

  

Aumente la tolerancia permitida de 1e-12 a 1e-10 para los criterios de convergencia.

 .options abstol=1e-10  

  

Aumente la tolerancia permitida de 0.0001 a 0.003 para los criterios de convergencia. ¡Nunca más grande que 0.003!

.options reltol=0.003  

  

Capacitancia agregada desde cada nodo al suelo. Agregar un CSHUNT pequeño a cada nodo puede resolver algunos problemas de "paso de tiempo interno demasiado pequeño" causados por oscilaciones de alta frecuencia o ruido numérico. Predeterminado = 0.

.options cshunt=1e-15 

Editar: Las probabilidades son que el cshunt junto con otra resistencia en el circuito creará un circuito RC y ayudará a limitar el ancho de banda (es difícil si el solucionador quiere simular más de GHz de ancho de banda porque necesita usar muchos pasos de tiempo). Una resistencia puede ayudar a reducir los nodos flotantes o nodos que tienen alta impedancia pero que necesitan ser referenciados a tierra. Ambos métodos truncan los errores numéricos en el solucionador y reducen el tiempo que necesita resolver. Muchas veces la adición de pFs y Mohms está bien porque esos valores son cercanos a los del aire o de un plano a otro en FR4. Al hacerlo, simulas parásitos y haces que el circuito se comporte más como lo haría en el mundo real.

Si tuviéramos superconductores de circuito y pudiésemos construir elementos de circuito ideales, crearía muchos problemas, como resonadores más allá del rango de GHz, en todos nuestros PCB. El mundo real no es así, pero la especia LT sí lo es, a menos que observes los parásitos.

Mira la barra de estado. Eso te da el progreso de la simulación. Si dice Defcon 1, entonces está teniendo problemas de convergencia y está intentando otros métodos más lentos para intentar que el circuito converja.