These are exactly my thoughts. I already don't like the use of suffixes as they are. The model names should match the part exactly; schematics are not just for simulation, they are for publication as well. One of the great things about a standardized setup like this is that we can cut out lots of redundant intermediary steps which slow down the process of, say, importing a netlist to a PCB editor and having everything go right the first time, even having the PCB program choose all the correct transistors and pads automatically.
The only reason we are using suffixes in the first place is because the standard model sets are terrible and we have to make the good models stand out somehow, so neither us nor the simulator confuse it for a faulty model.
That's one of the very reasons this project is needed. There's no point in having faulty models in a simulation library - that is totally unacceptable. With those completely out of the way, we no longer need to work around them.
We need to put that behind us. We need to replace the discrete model libraries of LTSpice from the outset with a library of properly vetted models. We will need to keep a "dirty" library alongside in case there is no model, but it has to be heavily isolated, and shouldn't touch the project unless specifically included by the user.
There is also a way that we could seamlessly import schematics using the dirty models. The "ako" parameter in a .model statement makes it a copy of another transistor. For instance:
.model BC560C ako:BC560C_C
BC560_C -> BC560C
.model Q2SC5200 ako:2SC5200_K
.model FJP5200 ako:FJP5200
2SC5200_k -> Q2SC5200 = FJP5200
This is how I switch models over to my kean.bjt library when someone sends me a simulation. You could write a whole list of these to a modelimport.lib file and then put '.inc modelimport.lib' on the schematic of a non-standardized simulation. Again, this would remove all the steps of clicking and changing each model, and is something anyone could do.
It is important to consider that LTSpice as well as being a simulation is also a structured simulation program. It has its own system. The problem is, the discrete models are faulty most of the time so even if the system works well, the result will be garbage. We need to take advantage of LTSpice's built-in system rather than trying to subvert it. This will make simulation more intuitive with less need to reach into the engine to start the car.
About the mfg model parameter. This parameter might be used by some PCB or BOM programs, so ideally it would reflect the actual manufacturer. Is there another parameter we can use? What about inline comments? For instance:
.model Fake NPN(params) * demonstration model by keantoken
Where the * tells the simulator everything after that is a comment. So here we go: let's make a standard format for models that again, suits our needs. Taking advantage of SPICE syntax, we can format models in a human-readable way that allows us to put comments inline with the model:
.model Fake NPN (
+ * Fake demonstration model by keantoken of DIYAudio
+ * human-readable SPICE model with infotext
+ * Version 1
+ Hfe=100 Re=80m )
This way, the comments are inside the model and are unlikely to be separated from it. We can add all the info we need and leave the SPICE parameters alone so they can do the job they were intended for.
I didn't think about pcb programs, as it's not so easy to have everything well integrated. But that would be nice. I use eagle. Perhaps a good script could help integration. I tried that new eagle ltspice integration and it really didn't provide anything useful, it's broken.
That would be nice. I've been fussing about having to search and switch models all the time. There is one issue with ltspice that bothers me: it can only give models for insertion from its own databases and when I used .include or .lib, those models in those libraries don't come up as available to put in schematics. And when we add models to the main libraries and have to embed them into the schematics for sharing, we get a bunch of warnings for duplicate models.
I didn't even know this existed, but obviously there is still a lot about lyspice that I don't know about. This could be good and it would simplify things.
One question comes to mind though, as I just mentioned above, when we send out a schematic for someone else to simulate, the models should be embedded so that simulation runs the same everywhere. So how can this be handled?
One other thing I didn't know and think about, but sure, when integrating with a pcb program, this needs to work.
Ok, the comments are probably the way to go and would leave the mfg param do its job. However when I embed models into a schematic for sharing, I don't like the multiple lines of comments and a model spanning too many lines, as those really blow up the visual size of the schematic on the screen. When hitting the space bar to view a whole schematic, and the models are using up a lot of space, then we see a smaller schematic and too much noise from models.
I have been reducing the font size on some models embedded in schematics so they would not bother me as much when hitting the space bar to see all.
This is good, a serious discussion with many opinions considered and something really nice can come out of it.
I think you could put the model library inline with the netlist, and provide everything necessary along with the file. The problem however is that when the user tries to change or modify the schematic, the default simulator action is to use it's own faulty libraries and whatever the other user has put in it. We can't expect anyone to have studied all the models they've gathered for correctness, or to NOT have downloaded all the messed up model libraries from manufacturers. Years of simulations on DIYAudio have shown us this.
Many people seem to be comfortable with running simulations with the first models they can find and if it gives the wrong output, "it's the simulator's fault, or "simulation is a flawed concept".
When you are working and sharing with others and intended to get a real, practical result, all these problems just blow up and it wastes your time and everyone else's. Everyone is afraid of sharing their simulations because they don't want to go through the tedious process of getting the simulation ready. So many people don't even know HOW to do that. Even those who DO know how, forget something the first time and then have to do it again. No one wants to suffer the embarrassment or inconvenience of this process. Really, LTSpice should have this function built in, and I consider this a capital design flaw.
Imagine a world where sharing a simulation is as easy as clicking a button, choosing the simulation, and uploading the file. No preparation needed. No embarassment. It works every time because the simulator is set up to make portable simulations by default, and break portability only by explicit user directive.
People don't miss what they don't see, and this is one of those things. The trick will be making the kit so seamless and convenient, that all the previous SPICE users will want to switch to it. Portable standardized SPICE simulations should be the norm, not the exception. As it is, LTSpice already has many inconvenient aspects, and I don't think it should be hard to improve on that.
Many people seem to be comfortable with running simulations with the first models they can find and if it gives the wrong output, "it's the simulator's fault, or "simulation is a flawed concept".
When you are working and sharing with others and intended to get a real, practical result, all these problems just blow up and it wastes your time and everyone else's. Everyone is afraid of sharing their simulations because they don't want to go through the tedious process of getting the simulation ready. So many people don't even know HOW to do that. Even those who DO know how, forget something the first time and then have to do it again. No one wants to suffer the embarrassment or inconvenience of this process. Really, LTSpice should have this function built in, and I consider this a capital design flaw.
Imagine a world where sharing a simulation is as easy as clicking a button, choosing the simulation, and uploading the file. No preparation needed. No embarassment. It works every time because the simulator is set up to make portable simulations by default, and break portability only by explicit user directive.
People don't miss what they don't see, and this is one of those things. The trick will be making the kit so seamless and convenient, that all the previous SPICE users will want to switch to it. Portable standardized SPICE simulations should be the norm, not the exception. As it is, LTSpice already has many inconvenient aspects, and I don't think it should be hard to improve on that.
My idea was to replace standard.bjt with our library so it would be working with the simulator. This is what my model shows when I add it to the standard.bjt.
As far as adding this to the schematic of a simulation, yeah, it will get in the way. If you add it to the netlist manually however, I don't think it will show up on the schematic. Still, it won't be selectable from the GUI. You'll have to change the BJT name manually in order to use it.
As far as adding this to the schematic of a simulation, yeah, it will get in the way. If you add it to the netlist manually however, I don't think it will show up on the schematic. Still, it won't be selectable from the GUI. You'll have to change the BJT name manually in order to use it.
Attachments
Last edited:
The best way would be to do that then, change that standard.bjt, so all and only the model we want show up and are usable by the gui and when those who share the simulations are also using the same bjt file, then all should be well.
This is coming together.
I can't wait to also see some oddities being solved on the mac version, so we can do everything without needing windoze.
One thing that I also thought that should be available with the database and management system for models, is a model request system, so when we need one that's not in the "good" database, we can post a model request and hopefully what we need will be quickly found and made right.
This is coming together.
I can't wait to also see some oddities being solved on the mac version, so we can do everything without needing windoze.
One thing that I also thought that should be available with the database and management system for models, is a model request system, so when we need one that's not in the "good" database, we can post a model request and hopefully what we need will be quickly found and made right.
Model requests could be handled like feature requests in a VCS like Git. VCS provides all the functionality for keeping track of versions, tracking features, bugfixes, and so on. The important thing is to make it easy to submit requests and bugs, and that all the submissions go to a central place such as a Git server where everyone can see them.
I wonder if it would be possible to get the Mac version to work on Linux, since they are very similar. That begs the question though, if there is a Mac version, where is the Linux version?
I wonder if it would be possible to get the Mac version to work on Linux, since they are very similar. That begs the question though, if there is a Mac version, where is the Linux version?
From what I understand, this mac version is not a wine "bottled" version that still has windoze underpinnings, and it's supposed to be native.
This would logically mean that its unix based underpinnings are very similar to linux's, however the gui doesn't look and feel at all like an X11 based one, it really does feel like the real mac, which is the way it should be, so it may be using gui libraries that are mac specific and that's not usable on linux.
Perhaps asking the guy who writes it? (is that Mike? as I understand it...)
There may be a linux version already, or in the works though...
Using wine isn't a good solution and it's only good temporarily.
I asked to split this thread, so now it has it's own place.
The most basic step we can make that gets this running immediately is to make a zip file with a structure that mimics the LTSpice directory tree. Then the user simply unzips it over a new LTSpice installation, and it replaces all the relevant files. Instant installation. For instance:
From here we can basically fill it full of stuff as long as it all works together and is portable and platform-independent.
The most basic step we can make that gets this running immediately is to make a zip file with a structure that mimics the LTSpice directory tree. Then the user simply unzips it over a new LTSpice installation, and it replaces all the relevant files. Instant installation. For instance:
Code:
/lib/ Obviously, for libraries, symbols, models, subcircuits...
/lib/sym/
Signal.asy full-featured signal generator - triangle, sweep, square, etc.
Tnpn, Tpnp, Tnmos, etc. Crude but effective real-time thermal models.
Reworked symbols for basic components so that "standard" simulations stand out and can't mix with unstandard ones.
/lib/cmp/
standard.bjt and others (with our good models, and set to read-only)
/lib/sub/
subcircuits for Signal.asy, thermal semiconductor models, etc.
/templates/ Template schematics containing all the relevant coding done for drop-in usage.
Linear.asc Basically ampsim5.asc; THD, noise, SNR, slew rate, and so on.From here we can basically fill it full of stuff as long as it all works together and is portable and platform-independent.
Cool! But a prior backup may be a good idea before overwriting this, and perhaps double checking that it does work properly on all the platforms in the same way.
Not using windows or linux, I can't compare, but I can double check on the mac layout to make sure it matches.
We don't want to remove all the models that come with ltspice though, especially if we have no other known good model to replace them with, we should keep them handy if needed, otherwise the chase for models continues.
Not using windows or linux, I can't compare, but I can double check on the mac layout to make sure it matches.
We don't want to remove all the models that come with ltspice though, especially if we have no other known good model to replace them with, we should keep them handy if needed, otherwise the chase for models continues.
Very good then. I will follow recommendations and do what needs to be done to check on the mac platform.
It's a pain not to be able to choose models from the gui. I always have to add models to the standard library and then comment them out later when they're in place in schematics.
I want to have the models not in the default standard libraries put into an external file so it can be shared along with the asc file.
And since the mac ltspice has been crash prone when models are duplicated in the standard libraries and embedded in the asc file, I prefer leaving them in external files, which prevents those crashes. Besides, having models embedded in asc files is nice for sharing, but it makes for very messy schematics, especially when many models are embedded.
I like to make the schematics clean and understandable. I've seen so many that aren't even readable by a normal human being. If I can't easily make out everything in a schematic, then it needs to be cleaned up.
If we get this sharing going well enough, then we no longer need to bother with embedding and external model files, we just need to point to a link where the repository is for those who don't already have that.
It's a pain not to be able to choose models from the gui. I always have to add models to the standard library and then comment them out later when they're in place in schematics.
I want to have the models not in the default standard libraries put into an external file so it can be shared along with the asc file.
And since the mac ltspice has been crash prone when models are duplicated in the standard libraries and embedded in the asc file, I prefer leaving them in external files, which prevents those crashes. Besides, having models embedded in asc files is nice for sharing, but it makes for very messy schematics, especially when many models are embedded.
I like to make the schematics clean and understandable. I've seen so many that aren't even readable by a normal human being. If I can't easily make out everything in a schematic, then it needs to be cleaned up.
If we get this sharing going well enough, then we no longer need to bother with embedding and external model files, we just need to point to a link where the repository is for those who don't already have that.
I've been looking through the LTSpice manual and discovered I can do this:
It actually download the file from the net! This could help. We could host the latest version somewhere and instead of distributing copies, we would point the simulator to the webpage. That way the file would always be the latest version.
This solves another problem as well. Every time you make a new schematic you have to add all the support files to its directory. If we put the .ferret command in a template schematic, then a whole simulation environment could be downloaded into the directory the template was saved to. Then to share the simulation, just zip the directory and it should work for anyone.
Of course this has the disadvantage that there could be a lot of redundant files; different environments/contexts could be provided so you wouldn't have a digital model library taking up space in a tube amp simulation.
The main advantage is that it's user-friendly. A person only needs to run the simulation and everything works out, with less needing to mess with files and directories, as long as there is a server and an internet connection. You don't need to worry about having an old version.
The .ferret command could be manually added into the template with notepad so that it doesn't show up on the schematic, in case there needed to be a lot of URLs.
Code:
.lib https://startfetch.com/keantoken/ltspice/kean4.bjtIt actually download the file from the net! This could help. We could host the latest version somewhere and instead of distributing copies, we would point the simulator to the webpage. That way the file would always be the latest version.
This solves another problem as well. Every time you make a new schematic you have to add all the support files to its directory. If we put the .ferret command in a template schematic, then a whole simulation environment could be downloaded into the directory the template was saved to. Then to share the simulation, just zip the directory and it should work for anyone.
Of course this has the disadvantage that there could be a lot of redundant files; different environments/contexts could be provided so you wouldn't have a digital model library taking up space in a tube amp simulation.
The main advantage is that it's user-friendly. A person only needs to run the simulation and everything works out, with less needing to mess with files and directories, as long as there is a server and an internet connection. You don't need to worry about having an old version.
The .ferret command could be manually added into the template with notepad so that it doesn't show up on the schematic, in case there needed to be a lot of URLs.
Wouldn't it be good to have a wiki on this site with the info about doing all this properly? with links, details and explanations.
This is the first time I even heard of that .ferret command, and I'm sure I'm not the only one. What is it? what does it do?
There are enough differences between platforms to make it tricky to make it work everywhere, so if a wiki has the info related to each platform, that can remove the searching every time for anyone who doesn't know yet how to do it.
Besides, for those like me who's memory fails all the time, a place to check things out and recall procedures would be a great help.
We're getting somewhere!
This is the first time I even heard of that .ferret command, and I'm sure I'm not the only one. What is it? what does it do?
There are enough differences between platforms to make it tricky to make it work everywhere, so if a wiki has the info related to each platform, that can remove the searching every time for anyone who doesn't know yet how to do it.
Besides, for those like me who's memory fails all the time, a place to check things out and recall procedures would be a great help.
We're getting somewhere!
Ok, here's my first feedback on this: I've just tried adding that line to a small sim.
.lib https://startfetch.com/keantoken/ltspice/kean4.bjt
And it tells me in a popup: Could not open library file
I'm on mac, so here is one example of platform specific issue.
.lib https://startfetch.com/keantoken/ltspice/kean4.bjt
And it tells me in a popup: Could not open library file
I'm on mac, so here is one example of platform specific issue.
First, see if you can download the file in your browser using this:
http://startfetch.com/keantoken/ltspice/kean4.bjt
If not, then it is a problem with the server or with your network. If you can download the file, then it's a problem with LTSpice. If you go to Help->About, it will give you Mike's email address and you can send him a report.
http://startfetch.com/keantoken/ltspice/kean4.bjt
If not, then it is a problem with the server or with your network. If you can download the file, then it's a problem with LTSpice. If you go to Help->About, it will give you Mike's email address and you can send him a report.
That was the first thing I checked, and it does come up.
I wouldn't know what to send and ask. I'm not sure what to expect exactly.
What is supposed to happen with that file when it comes through? Where should it go? Does it allow seeing those models in the gui?
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.