.asc LTspice support?

[crabdancing]

I am trying to get into using this software, however it seems the electronics community has settled on LTSpice as their go-to -- every time I get a file it's a .asc. Are there any plans to support this format?

(In the meantime, is there any workaround for converting to a format Oregano understands?)

[drahnr]

Is there a standardized format for that? If so I could potentially write a parser, if it has to be reverse engineered I am not going to invest much time into that.

[crabdancing]

It is a non-binary format that is semi human readable, so it should be pretty easy. There is some kinda vague documentation here with file examples:
http://ltwiki.org/index.php?title=Most_frequently_asked_questions_for_beginners

Unfortunately, it doesn't appear to explain the details of the .asc format, but it looks like it's a simple plaintext column format, delimited by spaces and newlines. I can give you some sample files if you like!

LTSpice 17 (stylized XVII) seems to be the de facto standard software in many electronics circles -- so supporting its formats is really the only way to gain traction with Oregano I think. I'd really like to not use LTSpice, but unfortunately I've been forced to resort to it, since it has a lot of components in its database and it's compatible with all the schematic files I've come across. Thankfully LTSpice, though it doesn't have binary compatibility with Linux, seems to work excellently with Wine.

If you don't want to install LTSpice for testing, perhaps I can help you with testing! Let me know if that's something you need. :)

[drahnr]

If it is test I might give it a whirl and introduce some rust in this codebase and use the parser syntax generator used by pest - but I'll first need to figure out how much work that'd actually be and if it is feasable and how to introduce that into the buildsystem.

I fully second the necessity to support this format, another big topic is to get more part items.

And examples are very much appreciated :)

[crabdancing]

I've never worked with rust, so I'm totally unable to help there -- but I know C++, C, Python, Bash and Markdown -- so if any of those things come in, I can send you pull requests if you want help. :) I'd really love for this program to be able to seamlessly replace LTSpice in the electrical engineering community.

(Is there some reason C/C++ is nonviable? Just curious!)

As for part items...

The components visualizations in LTspice are called "symbols", stored under lib/sym in the root LTspice installation directory. Then there's the actual component behavior... which seems to be controlled by lib/cmp. Sadly, I do see some things under lib/sub that are binary files... not sure what they are.

I just checked the LTSpice license, and it said...

"Redistribution of this software is permitted as long as it is distributed in its entirety, with all documentation, example files, symbols, and models without modification or additions." -- LTspiceHelp.chm

They didn't specify that I had to distribute it in executable installer form, so here's the entire installation directory! You can easily unpack it and view the lib directory without any nonsense proprietary executable running. ^.^

(Of course, the executables are included in order to stay within the bounds of the license.)

There is also a thing in the license that forbids "reverse-engineering". Which, to me, seems ridiculous. I'm not allowed to know what my computer is doing when it runs your software? That's dumb. That's why I don't like proprietary software!

Anyway, you may want to look into clean room reverse engineering to avoid any code being "derived work" -- (I did some searches on how, e.g., GIMP managed to legally gain support for PSD format, but I couldn't find anything. Perhaps we should drop those peeps a line...)

Finally, you may also want to look into moving this repository from Github to somewhere else, given that Microsoft now owns this place and I don't know what extra YouTube-esque faux-copyright enforcement measures they might take against projects like this.

Anyway, let me know if I can be of any other help! :)

[crabdancing]

I have created a simple circuit simulation, as an example. Here is the contents of the sample.asc file.

Version 4
SHEET 1 880 680
WIRE 240 -80 32 -80
WIRE 240 -48 240 -80
WIRE 32 0 32 -80
WIRE 240 48 240 16
WIRE 32 160 32 80
WIRE 240 160 240 128
WIRE 240 160 32 160
WIRE 240 208 240 160
FLAG 240 208 0
SYMBOL res 224 32 R0
SYMATTR InstName R1
SYMATTR Value 200
SYMBOL LED 224 -48 R0
SYMATTR InstName D1
SYMATTR Value LXHL-BW02
SYMBOL Misc\\battery 32 -16 R0
WINDOW 123 0 0 Left 2
WINDOW 39 0 0 Left 2
SYMATTR InstName V1
SYMATTR Value 5
TEXT -2 232 Left 2 !.tran 10

It's actually suuuper short. There just appears to be one line per wire or component (with a few extra for defining values for specific components). A lot of it is pretty much just basic intuitive stuff. The TEXT line with the !.tran 10 is probably because I told it to simulate the circuit for 10 seconds.

I have also attached said file, for your convenience. Unfortunately, Github forced me to add a .txt to the end because they "don't support that file". Riiiight.

I've also attached a screencap of what the circuit looks like in the program. Should give you some ideas as to where to get started.

sample.asc.txt

[drahnr]

The whole point of rust is zero-overhead memory and type safety - nice features for parsers and friends. Another topic is, that I rather spent more time developing rust than spending my spare time debugging C/C++ :)
I'll hopefully find some time digging into this, but it seems it is going to be a bit.

[drahnr]

Ok so as it seems right now it is rather unlikely that I'll find time to implement this anytime soon. I am happy to review PRs though. I know that this is a bummer and I would love to see this implemented.

[crabdancing]

Understandable.