OPAMP OP37 Error when loading the netlist

[UmbraDeorum]

Current Behavior:

I am appending the error report generated from the application when attempting to simulate with the OPAMP OP37.
I just begun studying circuits, so of course my setup may be completely wrong and/or nonsensical, but should this result in the error I'm getting?

The simulator gave an error when loading the netlist. Probably some SPICE field is wrong, please, check them.
If the parts are from the simulation bin, report the bug in GitHub.

Errors:
stdout Note: No compatibility mode selected!
stdout Circuit: simulator netlist
stderr Error: unknown subckt: xu1 3 2 9 8 1 op37g


Netlist:
Simulator Netlist
R3 1 3 100000
DLED1 4 0 LED_GENERIC
XU1 3 2 9 8 1 OP37G
R4 4 1 220
R2 2 1 100000
R1 3 0 100000
VCC2 2_VCC2_aux 0 DC 9V
RVCC2 2_VCC2_aux 2 0.1
C1 2 2 1u IC=0
VCC1 10_VCC1_aux 2 DC 9V
RVCC1 10_VCC1_aux 10 0.1

*Typ RED,GREEN,YELLOW,AMBER GaAs LED: Vf=2.1V Vr=4V If=40mA trr=3uS
.MODEL LED_GENERIC D (IS=93.1P RS=42M N=4.61 BV=9 IBV=10U CJO=2.97P VJ=.75 M=.333 TT=4.32U)

.option savecurrents
.option interp
.OP
*.TRAN 1ms 100ms
* .AC DEC 100 100 1MEG
.END

Build:
Fritzing Version 1.0.4 (CD-2065-0-a8c6ef7c 2024-10-07) 64 [Qt 6.5.3]

Operating System:
Windows 11

Steps to reproduce:

• Attach the OP37 in the breadboard.
• Attempt to initiate simulation mode.
• The simulation fails with the error.

Expected Behavior

The simulation should work regardless of the setup (e.g. smoking component or nothing happening).

[UmbraDeorum]

Will upload a different bug report first chance I get, regarding same issue with the OP482.

[failiz]

Thanks for reporting this but, please, do not open a new report for the OP482. They are the same issue.

The issue with all this analog device components is that they are missing the SPICE subcircuit that specify how they behave. These parts were added in 2014 by the old development team. I suspect that they had these SPICE subcircuits in a library that we would need to load. The SPICE output of Fritzing was sponsored by analog devices: https://blog.fritzing.org/2014/07/14/new-fritzing-release-0-9

You can download the SPICE model from their website (simulation): https://www.analog.com/en/products/op37.html#tools-header and then add that in the part fpz as a model, but it is quite tricky.

@KjellMorgenstern , any chance that you could try to contact the old developers to see if they had an agreement with analog devices or who was their contact there? If not, we may add their models in out parts, see their license terms:

Copyright 1995-2015 by Analog Devices, Inc.
The information in this SPICE Model is protected under United States copyright laws. ADI hereby grants You a nonexclusive, nontransferable license to use this SPICE Model as long as You abide by the terms of this Agreement.
You may not sell, loan, rent, lease, or license the SPICE Model, in whole, in part, or in modified form, to anyone outside Your company. You may modify this SPICE Model to suit Your specific applications, and You may make copies of this SPICE Model for use within Your company.
You may include copies of Analog Devices’ SPICE models with any software you sell or distribute. However, you may not make changes to the redistributed copies of Analog Devices SPICE models other than to:

• Include comments.
• Change nomenclature so that it will run on Your company’s software. No changes may be made that affect the performance or function of the model.

Analog Devices includes SPICE models in its library that have been developed by third parties. These models may not be redistributed.

[UmbraDeorum]

Thank you for the quick and detailed reply!
I'll not open a new report for the second component.

[vanepp]

As a data point, I exported the OP37 from Fritzing0.9.3b and grabbed the spice model from that exported part. It looks basic to me (no added libraries):

<url>http://www.analog.com/OP37</url> <spice> <line>X{instanceTitle} {net connector3} {net connector2} {net connector7} {net connector4} {net connector6} OP37G</line> </spice>

although I don't know all that much about spice and perhaps the OP37G is the library reference? No, the current part in 1.0.4 appears identical, so I don't think there were any extra librarys in the older code.

this is from a part exported from 1.0.4

<spice> <line>X{instanceTitle} {net connector3} {net connector2} {net connector7} {net connector4} {net connector6} OP37G</line> </spice>

although I guess a library referred to by OP37G could be missing from somewhere I am not aware of.

[failiz]

I think the idea of the developers was to add the models using the standard library folder for ngspice. But they were not added into the code or maybe the users were supposed to do it manually. But the development stopped and this feature was not added.

[KjellMorgenstern]

The following AD parts within Fritzings have SPICE models available which are not integrated yet:

AD8210
AD584
AD654 - not recommended for new designs
AD8226
AD8541
AD8561
ADTL082
OP27 - not recommended for new designs
OP37 - not recommended for new designs
OP482
SSM2212
SSM2220 - obsolete
TMP01

There is a huge a number of more recent parts, e.g ADA4807-1 , which are marked "production" or "recommended for new designs" , and which are not integrated to Fritzing.

As I understood the license, it is permitted to bundle the models with Fritzing releases, but we shouldn't include them in fritzing-parts (as that would be somewhat 're-licensing').

Independent from that, maybe it could help to make Fritzing "SPICE" property editable by the user. It is quite easy to get this wrong though, and there are few possible verification (-> possibly crashing Fritzing, or silently messing up simulation results). On the other hand, easy manual testing could increase the quality, as opposed to the current way, where you have to modify the part, and re-import it to Fritzing.

[failiz]

As I understood the license, it is permitted to bundle the models with Fritzing releases, but we shouldn't include them in fritzing-parts (as that would be somewhat 're-licensing').

We do not need them in the fpz files, they can be store in a folder in Fritzing and the simulator can add them if they are in use (we need to include the file that defines that model). See the ngspice manual:

2.8 .INCLUDE
General form:
.INCLUDE filename
Examples:
.INCLUDE /users/spice/common/bsim3-param.mod
Frequently, portions of circuit descriptions will be reused in several input files, particularly with
common models and subcircuits. In any ngspice input file, the .INCLUDE line may be used to
copy some other file as if that second file appeared in place of the .INCLUDE line in the original
file.
If the filename is a relative path and the file is not found, it is searched for in the locations
given by variable sourcepath (13.7). There is no restriction on the file name imposed by ngspice
beyond those imposed by the local operating system.
2.9 .LIB
General form:
.LIB filename libname
Examples:
.LIB /users/spice/common/mosfets.lib mos1

[failiz]

Independent from that, maybe it could help to make Fritzing "SPICE" property editable by the user. It is quite easy to get this wrong though, and there are few possible verification (-> possibly crashing Fritzing, or silently messing up simulation results). On the other hand, easy manual testing could increase the quality, as opposed to the current way, where you have to modify the part, and re-import it to Fritzing.

Yes, editable spice fields will help to minimize these issues or that we lack a model for a part (e.g., a model available online cannot be redistributed) as they could find it and add it. They may break the simulation or get bad results but I think it is unlikely that they crash the program. In case that the simulation stops working, it would be easy to remove the parts slowly until finding the one that causes the problem.

However, the risk is that users will modify one part and then adds the same part from the inspector (instead of coping and paste the part with the modified spice). In that case, two identical parts would behave differently. This can be intended or not, but it is difficult to see, except by analyzing the spice fields (which is quite tricky for long models or subcircuits). Maybe we could add a small icon on the parts with modified spice fields while simulating them, or adding a reset mechanism to go back to the default spice field.

[KjellMorgenstern]

The download I found is a .cir file (pspice format apparently) , not a module or library like xspice. This could be a related thread: https://sourceforge.net/p/ngspice/discussion/133842/thread/286a096d/

[failiz]

I did not tried it, but I don't see any problem with the cir file. The cir file defines the subcircuit that we use.

Adding this line in the spice netlist would be enough:
.INCLUDE OP37.cir

Incase that they use any pspice syntax, we can automatically translate them with the command set ngbehavior=ps

[KjellMorgenstern]

Wouldn't we directly add the .cir content in the SPICE field of the part?

[failiz]

We could copy the content of the OP37.cir file in the spice field of the part, but that could trigger issues with the copyright and will make the netlist less readable.

We could also add the .INCLUDE OP37.cir` line in the netlist if there is an OP37 model in the netlist. If so, ngspice will read that file and use its model when simulating our circuit. Not sure how it works internally, but I do not think they use temporal files to create a netlist that contains both (user netlist + OP37 subcircuit).

[failiz]

I made a quick test, I can simulate the model downloaded from Analof Devices website, see below.

I had to modify a few things:

1. Add the line .INCLUDE OP37.cir to the spice netlist. This can be done in software or in the FPZ spice definition (I have not test that though)
2. Modify the name of the model (in the cir file the model is called OP37, not OP37g as in the FPZ file)
3. The model uses a code model (spice2poly.cm) and we need to load that from the simulator side. I just added another line: m_simulator->command("codemodel ./spice2poly.cm");. This means, that currently you cannot simulate the part without modifying the code.

Thus, no technical limitations to simulate this. It is an issue of sorting out the copyright issue.