Hi KiCaders,
I’m simulating a simple difference amplifier using the LM741. For some reason the op-amp saturates at +/-14V instead of +/-15V. Any idea why? Attached is the .sch and the .mod file. The node sequence needs to be changed to 3 2 7 4 6.
Lab2_diffAmp.sch (5.2 KB)
LM741.MOD (2.5 KB)
TIA,
-May
Exactly as it should be… take a look at the 741 data sheet… specifically “Output voltage swing”.
1 Like
Ah. I see. Thanks a lot 
The Lab2 in your filename makes me think this might be for school??? If you need more idealized opamp models (the type they typically teach about in school), then I suggest checking here:
Ste - your deduction is correct. I’m teaching the biomedical instrumentation lab and added a simulation component to the circuits the students build. I have tried the universal op-amp and found it pretty convenient. However, part of the class’s objective is to have the students look for spice models from the manufacturer. Of course, I make sure I choose components whose manufacturer offer a spice model.
I’m new to all this and started learning KiCad over the summer. KingJL’s clarification is exactly the type of issues/limitations I want the students to learn to be aware of ( myself included). I’m learning with my students this semester, ha!
If you want to know more info about opamps, or tell your students, then I highly recommend “Op Amps for Everyone”, aka SLOD006B
The first copy a simple search brought up is:
1 Like
Ah, OK. Makes sense. For beginners, I completely agree with the approach of finding a matching model from the manufacturer. Though, once you get more experienced with “SPICE-ing”, part of the process will become knowing when to avoid manufacturers’ models. It can go either way, where they are either not modeling enough or modeling way too much (gets too slow or never converges). Here is an example of the former, if you’re interested:
1 Like
I see. Good to know. The students and I are taking our baby steps in SPICE-ing. I will keep this in mind though. - Thank you!
On a different but related note:
Here is one implementation that keeps throwing the “time step too small” error. 1us should be OK given that the input signal is 1.5kHz. I have a very similar schematic and the time step works just fine. It worked for all the other students, exceptCR_Lab1.sch (4.3 KB) this one.
Fun fact: it starts to work when you set the time step to 4u instead of 1u. Help, please!
This is a GREAT resource! Thank you paulvdh.
Hoo boy…convergence issues. Unfortunately we’re way past beginner on this one. There’s a lot to cover on this topic, so I’ll cherry pick what I think is the most important to know.
First, I suggest reading 15.3.9 of the ngspice manual. The first parameter tstep of the .tran statement is not the timestep interval, but the data output print interval. SPICE has an internal timestep control algorithm which senses changes in the waveforms and automatically increases or decreases the timestep as it sees fit. However, you can specify a maximum to force it always to operate at or below a certain timestep size. That’s the 4th parameter tmax, but you need to specify the 3rd parameter tstart (even if it’s zero) to use it, like so:
.tran 1u 5m 0 1u
So that explains the error you get, but it doesn’t fix it. Some node within the opamp subcircuit is failing to converge when beginning at a certain time step. It fails, tries at a smaller step, fails, and repeats this cycle until it hits its minimum. There can be many causes, and therefore, many fixes. For beginners, I recommend trying a slew of various things until you can get it to converge. Here are some suggestions (not in any particular order):
1.) Try a different model from a different manufacturer. Some are outdated, poorly written, or poorly tested. I attached one which is more stable but might take longer to converge since it has many internal nodes. It is made out of the transistor-based schematic found in section 7.2 of the datasheet.
LM741.lib (996 Bytes)
2.) Tweak the tstep and/or tmax parameters, like we discussed above.
3.) Try adding the .options method=gear command to the schematic. This forces gear integration instead of trapezoidal integration (the default) for the capacitor/inductor differential equations. Trapezoidal integration can cause oscillations. Mostly, the oscillations just show up as error in the output, but I’ve seen cases where it exacerbates convergence issues.
4.) Sometimes an over idealized circuit can cause issues so it’s better to try to include parasitics which match a real-world scenario. For example, voltage sources or inductors without series resistance. Try adding some series resistance to these, even if it’s only on the order of 1m or 10m. Adding bypass capacitors on IC power pins can help too, as long as there’s series resistance on the lines since they work in tandem.
5.) Since SPICE default options are meant for IC simulations, you can increase the convergence tolerances to match discrete circuity better. This helps to avoid infinitely bouncing between values very close to each other and hit the iteration limit. For beginners, I would just mess with RELTOL (default is 0.001 or 0.1%). So for example, to increase to 1%:
.options RELTOL=0.01
6.) You can give the program more chances to arrive at a solution by increasing the iteration limit for each time step by modifying ITL4 (default is 10). For example:
.options ITL4=50
I actually did some low-level digging, and if I change the E-source to a V-source within TI’s LM741.MOD file (line 55) it seems to fix the convergence issues. I’m not a fan of E-sources, especially the ones with the POLY(x) modifier. They constantly cause convergence issues, from my experience. This type of tweaking is well beyond beginner or even intermediate, but I thought I’d mention it and at least attach the result if you wanted to try it out:
LM741_no_e-source.MOD (2.5 KB)
WoW!! There is so much happening under the hood. I will surely try some of the suggestions you listed. What I have a hard time understanding though, is that I used the same .MOD file, same spice command, and pretty much the same components, and it converged (attached).
Anway, I don’t want to waste your time on such minor issues. Thanks for the elaborate explanation, Ste!
L1Q_INV-amp.sch (4.5 KB)
Yep, no problem.
“pretty much” is the key phrase there. When the underlying system is unstable, then even the tiniest of differences can have a big impact. Changing that 20k/10k ratio to 100k/50k is plenty to nudge it into non-convergence.
Maybe a silly Idea:
How about adding some noise into the circuit, just as in real circuits, for example to a signal source or a power supply voltage.
Would that help in preventing convergence problems?
I would say that in general, adding more instability to an unstable system will just make it more likely to fail. But, I mean it’s possible that would change the behavior, just like any little change to the circuit will, to the point where it will converge under a certain time step that it wouldn’t before. But then maybe it will not converge on many other timesteps that it did prior to adding the noise source. So I think this is a bad idea.
In my opinion, the best way to solve these problems is to address the underlying model itself. All the other “solutions” are more luck to try and step around timesteps that are giving the underlying model issues.