Medición de la eficiencia en varias cargas en LTSpice

Puede hacer un lote de ejecuciones agregando una tarjeta .STEP PARAM, si agrega "No restablecer T = 0 cuando se detecta un estado estable". Entonces podría ajustar su RLOAD usando 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 tener 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" debajo de todas las partes. Entonces, hay un poco de software que está dentro del código de visualización esquemático. 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 descubrir cómo mostrar todos esos informes automáticamente. Y sospecho que Mike no quería tener que ir a buscar un resultado complejo de "buena apariencia" para eso. Otra razón es que el informe de eficiencia probablemente esté "hackeado" porque el departamento de ventas lo exigió para LTspice como una forma de hacer que la selección de sus chips convertidores de energía sea más fácil, conveniente y competitiva con otros que también tienen formas de proporcionar dichos informes para sus propias piezas. Y como el departamento de ventas norequieren múltiples informes de apoyo, no había necesidad de "ir allí".

He podido generar múltiples ejecuciones, sin problema, con la tarjeta .STEP y con una tarjeta .OPTION para jugar con valores SSTOL. Entonces el motor Spice lo hará. Y estoy seguro de que los datos podrían colocarse fácilmente 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 maravillosamente" en su mente y 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 genere llamadas telefónicas de soporte adicionales.

(Estoy seguro de que el equipo de ventas ya aceptó la necesidad de llamadas de soporte con respecto a UNO de esos informes. Es necesario, competitivamente. Así que es una obviedad. Tienen que morder esa bala. Pero es posible que no estén muy contentos si Mike y agrega algo que hace que las llamadas sean más costosas y más frecuentes, sin primero pedirles permiso. Podría colarse, si cree que no habrá tales problemas).

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 hace) y luego simplemente solicita después de cada .STEP PARAM que presione ENTER o algo así para pasar a la siguiente valor de .STEP PARAM. Esto no agregaría ningún cambio al código de visualización, no agregaría ningún cambio al código 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 código especial se detenga antes de pasar a el siguiente valor de .STEP PARAM. Mike podría comprar esa idea.

Ya sé que funciona, porque puedo realizar una serie de simulaciones ahora mismo con el producto existente. Y muestra el Informe de Eficiencia de la última simulación. Entonces solo recoge los datos de la última ejecución. Entonces, es seguro que agregar un cuadro de diálogo de solicitud sería bastante fácil de hacer, muy claro para Mike, y puede tener una oportunidad.

Le he escrito a Mike. Voy a ver que dice de todo esto.