Puede hacer un lote de ejecuciones agregando una tarjeta .STEP PARAM, si agrega "No restablecer T = 0 cuando se detecta un estado estable". Por lo tanto, podría ajustar su RLOAD utilizando dicho valor de parámetro. El problema es que el Informe de eficiencia solo reflejará la última ejecución, creo. LTSpice no puede producir más de uno de ellos.
Puede obtener una idea de cómo el software de LTspice maneja el Informe de Eficiencia simplemente agregando una tarjeta o una parte, como una resistencia, debajo de su circuito en algún lugar. El informe se moverá "mágicamente" por debajo de todas las partes. Así que hay un poco de software en marcha que está dentro del código de visualización del esquema. Y dudo que este código de visualización tenga acceso a más de una estructura de datos para el informe. Una razón es que si dichos datos fueran una matriz de tales estructuras, entonces el código de visualización tendría que averiguar cómo mostrar todos esos informes, automáticamente. Y sospecho que Mike no quería tener que descubrir una salida compleja para eso. Otra razón es que el informe de eficiencia es probablemente "pirateado" porque el departamento de ventas lo solicitó para LTspice como una forma de hacer que la selección de sus chips convertidores de energía sea más fácil y más conveniente y competitiva con otros que también tienen formas de proporcionar dichos informes para su propio partes. Y dado que el departamento de ventas no requirió el soporte de múltiples informes, no hubo necesidad de "ir allí".
He podido generar múltiples ejecuciones, no hay problema, con la tarjeta .STEP y con una tarjeta .OPTION para jugar con los valores de SSTOL. Así que el motor Spice lo hará. Y estoy seguro de que los datos podrían ser fácilmente colocados en una matriz de estructuras, con un conteo, también. Estoy bastante seguro de que Mike no tendría ningún problema allí. Así que creo que probablemente no sucederá a menos que alguien le dé a Mike un algoritmo claro y convincente que simplemente "cante bellamente" en su mente y que sea fácil de implementar, con respecto a la visualización de tales resultados del motor. Probablemente tiene muy poca motivación para proporcionar varios informes. Pero podría estar interesado si puede ver claramente cómo hacer un trabajo confiable de una manera que no cause llamadas telefónicas adicionales de soporte.
(El equipo de ventas, estoy seguro, ya aceptó la necesidad de realizar llamadas de soporte con respecto a UN tal informe. Es necesario, de manera competitiva. Por lo tanto, es obvio. Tienen que morder esa bala. Pero es posible que no estén muy contentos Si Mike sale y agrega algo que hace que las llamadas sean más caras y más frecuentes, sin pedirles permiso primero. Es posible que pueda colarlo, si siente que no habrá ningún problema de este tipo.)
Otra posible sugerencia para Mike sería otra opción en la simulación .TRAN, donde muestra el informe en el esquema (como ya lo hizo) y luego simplemente solicita a cada .STEP PARAM que presione ENTER o algo así para que se mueva en el siguiente valor .STEP PARAM. Esto no agregaría ningún cambio al código de visualización, no agregaría ningún cambio al código de Spice que genera los datos, y solo agregaría una opción arcana (e ignorada por la mayoría de las personas) que permite que este bit especial de código se detenga antes de pasar a el siguiente valor .STEP PARAM. Mike podría comprar esa idea.
Ya sé que funciona, porque ahora mismo puedo realizar una serie de simulaciones con el producto existente. Y muestra el Informe de eficiencia de la simulación última . Así que simplemente recoge los datos de la última ejecución. Por lo tanto, es seguro que agregar un cuadro de diálogo de solicitud sería bastante fácil de hacer, muy claro para Mike, y podría tener una oportunidad.
Le he escrito a Mike. Veré lo que dice sobre todo esto.
