LTSpice Sim Fails After Circuit Changes

I am using LTSpice XVII under WINE in Linux. The sim works when I start out but then fails (become inaccurate) after a time spent adding, moving and deleting components. If I wipe everything back to the simple start circuit it does not work correctly as it did originally, although the signal sources do.

Is this a known problem and is there any way to get around it?

Kevin Foster

Reply to
Kevin Foster
Loading thread data ...

Perhaps it is the circuit. I don't mean to insult, but from your postings w e can tell there are a few holes in your knowledge base.

If nothing else changed it is probably your changes. you need to do things the old way, you should already know how it works, every waveform, every vo ltage. At one time it was all done on paper (or actually napkins at the gre asy spoon restaurant).

I can design you an amp, an SMPS and a few other things on paper but I have a shit ton of trouble with doing it on the computer. So I still do it (whe n I do) on paper.

I think everyone should be given a pad of the graph paper and made to actua lly draw out things, and label it with all expected waveforms and voltages before being allowed to use Spice in any of it's versions. You should not n eed a simulation unless the thing is exceedingly complex, and most things a ren't. What happens at startup ? What happens at shutdown ? You should alre ady know this and the computer is just a tool to confirm it. You decided th e capacitor values, you designed the reset circuit. If it doesn't work in a simulation you should already know why.

I am not being hostile or trying to insult, thought I have been told I soun d that way sometimes. It is just it seems you got a bit more to learn. Work it out yourself before giving it to Spice, YOU designed it, YOU should kno w everything about it. Every bias on transistors, every time constant, ever ything period. Spice can be a nice tool to save you from wasting paper and then to confirm that the thing runs as YOU intended, but it cannot do it fo r you.

Bottom line if the unchanged circuit still runs in the simulation but the n ew and improved version does not, it has nothing to do with your computer.

They sat Madman Muntz used to walk through the engineering department and c ut components out of the prototypes the engineers were making. If it stoppe d working it was included in the final design. You might just have pulled a "Muntz" and removed something that was actually needed. But he did it one component at a time. If you remove a whole bunch of shit, why did you inclu de it in the first place ? Think back to WHY it is there.

Reply to
jurb6006

Can you post a netlist of the working circuit, and the non-working edit?

Reply to
bitrex

Look for a boo-boo in the schematic. Sometimes reading thru the netlist will help you spot the error. ...Jim Thompson

--
| James E.Thompson                                 |    mens     | 
| Analog Innovations                               |     et      | 
 Click to see the full signature
Reply to
Jim Thompson

In addition:

I haven't "upgraded" to XVII... MANY hiccups have been reported. ...Jim Thompson

--
| James E.Thompson                                 |    mens     | 
| Analog Innovations                               |     et      | 
 Click to see the full signature
Reply to
Jim Thompson

Thank you for your reply. There is most likely no problem with the circuit, since it is from an LT datasheet. It just seems like the more I tinker with the sim, the less reliable the output is.

As was suggested by another, I will go through the netlist and see if I can spot what is happening. Might have something to do with running Wine Linux.

Kevin Foster

Reply to
Kevin Foster

if I has a badly behaved sim, another test would be save it and re-load it in a new instance of ltspice and see if it is consistently bad or if it behaves better before looking for differences in the saved files.

--
This email has not been checked by half-arsed antivirus software
Reply to
Jasen Betts

It runs fine in Wine on RHEL6, Fedora, and Debian--about one crash a month. Usually it says "can't start marching waves", at which point if you touch the plot window, down she goes. You can still save the simulation if you only touch the schematic window. So it's unlikely to be that.

Try poking around on the "SPICE" tab in the control panel. Turn on the 'alternate solver' for a start, and think about all the abs tolerances if you're running at unusually low currents.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

I had a similar problem just yesterday. This fixed it...

On the 'Edit Simulation Command' menu, tick the 'Start external DC supply voltages at 0V' box.

Cheers

--
Clive
Reply to
Clive Arthur

As Phil Hobbs suggested, use "alternate solver". The basic solver is set up for show so that Mikey can claim fastest simulator... but it takes liberties and model simplifications in the process.

And go back to LTspice IV, XVII is _known_ to have bugs... join the LTspice List to follow all the whine. ...Jim Thompson

--
| James E.Thompson                                 |    mens     | 
| Analog Innovations                               |     et      | 
 Click to see the full signature
Reply to
Jim Thompson

I tried that with my circuit, but it made no difference.

It was weird. The circuit was using an LT micropower comparator with reference and was designed to generate pulses when an external voltage exceeded a certain level. Quite straightforward, and it worked until I changed the resistance, but not the ratio, of a potential divider.

The thing that made it work again was the fix described above.

I've been using LTspice for years, albeit not intensively, and every so often it does something odd. Less often than it used to, that may be bug fixes or it may have subliminally trained me to avoid certain mistakes.

Cheers

--
Clive
Reply to
Clive Arthur

You could post your .asc file so we could peruse it for quirks. ...Jim Thompson

--
| James E.Thompson                                 |    mens     | 
| Analog Innovations                               |     et      | 
 Click to see the full signature
Reply to
Jim Thompson

Sadly not. It would be great if all who could read SED had implicitly signed some sort of binding NDA, but until that happens, I can't post details of my client's IP, and without the details it would be pointless.

OK, that's sort of fatuous. But wouldn't it be great?

Cheers

--
Clive
Reply to
Clive Arthur

Yup, sounds like pilot error, such as ignoring the input bias current.

Cheers

Phil Hobbs

Reply to
Phil Hobbs

No, not by orders of magnitude.

But it doesn't matter. The circuit simulates now and works (I mean in the physical domain - breadboard) as expected.

Cheers

--
Clive
Reply to
Clive Arthur

You could send it to me privately. I have no problem signing an NDA. I do so almost daily. ...Jim Thompson

--
| James E.Thompson                                 |    mens     | 
| Analog Innovations                               |     et      | 
 Click to see the full signature
Reply to
Jim Thompson

I'm pretty sure that numerical solvers depend upon the luckiness of their numbers being "approximately correct", or for that matter, incorrect just enough to be useful. With floating point (most often, double precision, I think?), the last couple bits are noisy, due to nonidealities in transcendental functions, and bit rounding after arithmetic operations.

Not having written SPICE myself, I'm just guessing here, but -- producing inversions of nearly-singular matrices is one of those ill-posed problems. The answer exists, but getting from A to B (or rather, to A^-1) is non-obvious. (A singular -- non-invertible -- matrix is the multivariable equivalent of "divide by zero".) If the rounding errors happen to coincide to a nearly-singular case, it will fail in a deterministic but non-obvious way. (And for that matter, it might be a combination of errors which isn't even near-singular, but just so happens to be an unfortunate combination for the algorithms used to compute it.)

In other words, in the region where the calculation fails, there are combinations of LSBs that work, and that do not work; it's not a sudden failure.

This does suggest that, if your circuit is failing, occasionally, it's still so far from well-behaved that it's probably a "wrong" circuit to begin with. But with nonlinear, time-dependent circuits, I don't think that's even a generally applicable case -- all circuits are "wrong", at some timestep or another, which is why variable timestep is used in the first place. Even with, for example, Jim's favorite continuous-derivatives function blocks. (It's just a matter of changing that fail-space from dense to sparse, and dodging the potholes.)

Hmm, now I wonder if there could be a rigorous definition to "fail space", between linear algebra and computer science.

Tim

--
Seven Transistor Labs, LLC 
Electrical Engineering Consultation and Contract Design 
 Click to see the full signature
Reply to
Tim Williams

Clive has not indicated if he's followed advice here and set Solver = Alternate?

One of my general rules of thumb is... if I experience repeated convergence issues... non-convergence or slow convergence, I'm doing something wrong, and I should revisit the pieces individually. ...Jim Thompson

--
| James E.Thompson                                 |    mens     | 
| Analog Innovations                               |     et      | 
 Click to see the full signature
Reply to
Jim Thompson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.