Feature Request: LTSpice ASC File Export

[ksugahar]

Summary

Add the ability to export SchemDraw circuits to LTSpice ASC format, enabling a seamless workflow from documentation to simulation.

Motivation

SchemDraw creates beautiful publication-quality circuit diagrams. However, users often need to simulate these circuits as well. Currently, this requires manually recreating the circuit in LTSpice, which is:

1. Time-consuming - Redrawing the same circuit twice
2. Error-prone - Manual transcription can introduce mistakes
3. Maintenance burden - Changes must be made in two places

An ASC export feature would allow users to:

• Design circuits once in Python
• Generate both documentation (PDF/SVG) and simulation files (ASC)
• Maintain a single source of truth for circuit designs

Proof of Concept

I have developed a working prototype that demonstrates this is feasible.

Supported Components

• Resistors, Inductors, Capacitors
• Current sources, Voltage sources
• Wires and ground symbols
• Labels and output flags
• SPICE directives (.ac, .tran, etc.)

Example Usage

with schemdraw.Drawing() as d:
    I1 = d.add(elm.SourceI().up().label('I1\nAC 1'))
    R1 = d.add(elm.Resistor().right().label('R1\n1k'))
    d.add(elm.Dot())
    C1 = d.add(elm.Capacitor().down().label('C1\n1u'))
    d.add(elm.Line().left().to(I1.start))
    d.add(elm.Ground())

    d.save('rc_filter.pdf')
    # Proposed: d.save('rc_filter.asc')  # LTSpice format

Key Technical Challenges Solved

1. Coordinate transformation: SchemDraw uses floating-point coordinates with Y increasing upward; LTSpice uses integer grid coordinates with Y increasing downward.

2. Symbol anchor points: LTSpice symbols have complex anchor point rules that differ by component type and rotation.

3. Wire routing: Automatic wire generation to connect component terminals.

Proposed Implementation

Add asc as a supported format in Drawing.save():

d.save('circuit.asc')  # Auto-detect from extension

Or as a separate module:

from schemdraw.backends import ltspice
ltspice.save(d, 'circuit.asc')

Questions

1. Would this feature be appropriate for the core SchemDraw package, or better as a separate extension?
2. Are there preferred patterns for adding export backends?
3. Would you be interested in reviewing a pull request for this feature?

I'm happy to share my proof-of-concept code or submit a PR if there's interest.

[ksugahar]

I've published my proof-of-concept implementation:

Repository: https://github.com/ksugahar/schemdraw-to-ltspice

The repository includes:

• Core converter module (src/schemdraw_to_ltspice.py)
• 7 working examples, each with Python source, PDF output, and LTSpice ASC file

Feel free to review the code. I'm happy to adapt it for integration into SchemDraw if there's interest.

[gsteele13]

Wow, as a teacher of an electronics course in applied physics, I was just googling exactly this. @ksugahar I will check out your code, it would be awesome to be able to use it! My goal is to get a workflow where students draw the circuit with the LTSpice GUI but then configure simulations, run analysis, plot data in python. Key to that is the ability to draw the circuit in python based on the LTSpice ASC file. I'll test it out and let you know! I would definitely thumbs up that this would end up in the Schemdraw library.

[gsteele13]

I see now that this is an exporter: what I would be even more interested in is an importer, I guess not too hard...?

[ksugahar]

Thanks for your interest, @gsteele13! Great to hear this could be useful for teaching.

Regarding an importer (ASC → SchemDraw) — that's an interesting idea, though my current focus is on the exporter direction. My motivation is around automated circuit generation: SchemDraw's Python API is well-suited for LLMs to generate circuit topologies programmatically, whereas LTSpice's ASC format (with its integer grid coordinates and complex anchor point rules) is much harder for LLMs to produce directly.

The workflow I'm aiming for is:

LLM  →  SchemDraw (Python)  →  LTSpice (ASC)

SchemDraw serves as an intermediate representation that is both human-readable and LLM-friendly.

That said, an importer is definitely a possibility for the future. The ASC format is fairly structured, so parsing it should be feasible. If you'd like to try the current exporter in the meantime, please check out the repository — any feedback would be appreciated!

[cdelker]

I think this is a nice idea and it would get a lot of use. I'm leaning toward keeping it as a separate module rather than part of the schemdraw core. Even if it's separate, I'd be willing to support and include tests in the core code to make sure they stay compatible.

Some thoughts on implementation, in no particular order:

1. A netlist has information that the schematic often does not. Component values, voltages, etc. are entered in schemdraw as strings, and would need a way to be converted or simultaneously input as circuit parameters. Components like BJTs need a way to be associated with a particular spice model. And of course, simulation parameters, probes, etc.

2. There are a lot of flavors of spice netlists, and universally supporting multiple formats would be challenging. It might be worth looking at something like spicelib as an interface to see if that could help cover different options and ensure proper syntax.

3. Assuming it relies on proximity of an element's anchor points to determine what's connected to each netlist node. Many of the schemdraw examples "cheat" by drawing one long ground line across the bottom of the drawing, and placing vertical elements ending anywhere along that line. So the algorithm would need some smarts to handle situations like this, or perhaps throw warnings for unexpected floating elements.

4. Elements often have implied or undrawn connections. Opamps, for example, have power/ground connections that are often omitted from the schematic, but these need to be connected in the netlist.

5. Netlist output can't really be added as a new schemdraw backend (alongside the SVG and Matplotlib backends), at least without some rework, because the backend only knows about Segments (primitive lines, circles, etc.), not the electrical elements themselves.

Going the other direction - creating a schematic from a netlist - is even harder. As nice as it sounds, I don't see a path for achieving this adequately. There is a lot more information in a schematic than in a netlist (think logical grouping of circuit functions, standardized layouts for commonly recognizable subcircuits, signal flow direction, grouping of multiple opamps or gates within a single IC package...) Drawing a good schematic is an art form, and there's not enough in a netlist to get there. See here for some good discussion.