I am trying to simulate a simple op-amp circuit which can drive a capacitive load (around 1nF in parallel with 100k) without ringing, as described in for example
I drew the schematic in KiCad (8.0.4) schematic editor, placed the spice .lib file in the project folder and linked to it from the op-amp properties, under Simulation Model. As suggested in one of the threads above I also checked that the mapping from model pins to simulation pins was correct (it was not, by default) and ran an Electical Rules Check which had no errors (warning that the second op-amp was unused).
As others have noted, I then got an error:
doAnalyses: OP: Timestep too small; cause unrecorded. run simulation(s) aborted
The solutions given in other threads (check the pins are correct, already done) and (simplify the schematic, it is already as simple as it can be made) do not seem to be the problem.
Here is a zip of the project, including the spice .lib file.
Thanks, that enabled me to do operating point, dc and ac analyses correctly and get reasonable (expected) results.
Transient analysis however once again gives me
doAnalyses: TRAN: Timestep too small; time = 1e-14, timestep = 1.25e-15: trouble with xu1.x_u1:dvn-instance d.xu1.x_u1.d1 run simulation(s) aborted
Iâm trying to do a step-function analysis (ie to the leading edge of a square wave) at 1ms (so, 1e-3) intervals for 100ms. I donât see where the very small floating point numbers are coming from.
You could start by posting the whole error message:
Note: Codel model file loading path is /home/paul/downloads/cv-output/
Background thread stopped with timeout = 0
Note: Compatibility modes selected: ps lt a
Circuit: KiCad schematic
Reducing trtol to 1 for xspice 'A' devices
Doing analysis at TEMP = 27,000000 and TNOM = 27,000000
Using transient initial conditions
Warning: singular matrix: check node xu1.x_u1.8
Warning: singular matrix: check node xu1.x_u1.8
Warning: singular matrix: check node xu1.x_u1.8
Warning: singular matrix: check node xu1.x_u1.8
Warning: singular matrix: check node xu1.x_u1.8
Warning: singular matrix: check node xu1.x_u1.8
doAnalyses: TRAN: Timestep too small; time = 1e-14, timestep = 1,25e-15: trouble with xu1.x_u1:dvn-instance d.xu1.x_u1.d1
run simulation(s) aborted
That Timestep too small looks like a red herring. ngSpice dynamically scales the timestep according to what itâs thinks is best. That singular matrix does not sound good.
In the properties of the OPA2192ID I noticed a
Sim.Pins 1=OUT 2=IN- 3=IN+ 4=VEE 8=VCC
I donât know if that works, my knowledge of ngSpice is very limited, but on the Simulation Model (button at the bottom) and then the Pin Assignments tab also has a list of mapping pins between the symbol and the spice model. That is at least confusing.
Also, each tab page in the simulator has itâs own error message window.
I clicked around a bit, but got totally lost quickly, and canât help much. I do see 4 defined simulations / tab pages in the simulator. Looks like youâre attempting to do too much at once.
The only simulations Iâve bult myself was a combination of Râs and Câs (with a 4-phase PWM filter) that worked quite nice. I have also ran some existing and working opamp circuits, but that is about all.
In my experience, the âTimestep too smallâ error message means nothing.
It just tells you that the simulation wonât converge, but not why.
Itâs mostly either a model problem, or a pin assignment problem (that covers around 90% of my problems until now).
Good Luck.
Your second cv-output.zip will run after changing the tran command to .tran 1u 2m, no âTimestep too smallâ is seen (KiCad 8.0.4, ngspice-42, MS Windows 10), but there is no transient in the input.
You have to give a transient actively, e.g. by a pulse source as input.
At 1ms the input jumpes from 0 to 5, and the rise time and the circuit will determine the response. You may need to enlarge the x axis around 1ms to see the effects.
So the algorithm just reaches itâs optimization limit because there is no circuit transient behavior to solve for without a proper input transient, it would seem.
I have not tried ngspice, but often in LTSpice I get progress down to picseconds per second or smaller. It usually means the simulation is stuck somehow but does not give much of a clue as to how to fix it. One thing to try (is there any such choice in ngspice?) is to change the integration method. In LTSpice those are gear, trapezoid, or modified trapezoid. Sometimes changing the integration method will get the simulation going. If I do not specify a maximum step size, a switcher simulation might typically run at uSec per second.
And if you set your end time just after that and scale the y axis without zoom, you can use the special âtuneâ probe that lets you see the real-time effects of changing that cap.
I did not change the end time. I do find it a bit annoying that each time you changed the tuned value, the window zooms out to show the full simulation duration, and each time you zoom back in you get a different scale, which makes it difficult to judge influences on slewrate and peaking and such.
In this particular case the interesting thing starts at 1ms, and is finished at 1.0012ms, roughly 1us later. That is a ratio of 1:1000. By setting the simulation time to âjust afterâ you still have the first idle milli second for the âstartup / stabilizingâ of the circuit.
At least having an option for the panning / zooming to not change at all during tuning would be a very simple and to implement and useful feature request. The only reason I have not made this feature request myself long ago, is that I rarely do anything with simulations myself and therefore I do not feel confident enough to make feature requests in this direction.
I learned about this compensation technique around 1975.
Around 2003 I was an applications engineer for Micrel which made an âLDO controllerâ IC. That controls a MOSFET to make an LDO. But the DS had no information about using these techniques for amplifier compensation when driving a large MOSFET. A customer had an oscillating design, and compensating it with this general approach fixed the problem. I had no good way to quickly optimize the design so I probably overcompensated the heck out of it, making the overall response slower than necessary. But the customer seemed to be happy with the fix.
I used this technique again a few years ago to hold a capacitor at about 1V with an op amp output. But after almost 50 years, I guess that this technique may still not be near-universally knownâŚ
It is not for stabilizing, but totally user selectable.
Have a look at the input pulse of V1: y1=0 y2=5 td=1m tr=100n tf=1u tw=1 per=1
The delay time td is set to 1m. You may give it a 1u. y1=0 y2=5 td=1u tr=100n tf=1u tw=1 per=1
and limit the simulation time to 10u.
And thatâs it.
And if I have to insist on the td=1m delay for whatever reason, I just change my tran simulation command:
Time step: 100n, Final time 1009u, Initial time: 999u
and get a nice plot covering the relevant time slot.
The problem with such methods is that you have to know in advance what you want to simulate, and what part interest you at a particular time.
In the end those are still workarounds for KiCad resetting itâs zoom level each time a circuit is tuned, a simulation is rerun or whatever. KiCad not bluntly resetting such things each time makes the simulator easier, more intuitive and pleasant to use. For you it probably does not a big difference, but it matters a lot more for beginners. Some time ago I did a simulation to filter out ripple on a PWM signal. Residual ripple was a few microvolt (In the end it was below the simulator threshold) and each time it took a lot of zooming to get back to even being able to see the ripple. It would have been so much easier if the simulator just stayed with the zoomed window.
Similarly, there is also no way to zoom out one or two steps. Zooming out quickly goes back to the whole time and voltage range. It would be much more user friendly if this can be done in steps, similar to how a real oscilloscope works.
And there are some considerable improvements in the GUI around simulations, but there is still a long way to go before I would call it intuitive and user friendly.