LTspice issues.

I don't have an answer but I get similar errors from time to time. I haven't been using LTSpice for very long either. When the "error at...." message comes up, it's usually when I forget to complete a connection and leave a node open. It may also happen when one makes a connection that LTSpice doesn't understand.

I have even less clue about the "Step size too small" thing. Until someone with more insight comes along to enlighten us, I surmise that it happens when certain combinations of circuit arrangement, component values and signal and measurement parameters require more complex calculations than LTSpice wants to attempt. Maybe multiple parasitic oscillations. I don't know. Just guessing.

"Jamie" schrieb im Newsbeitrag news:Yb0gn.1532$ snipped-for-privacy@newsfe07.iad...

Hello Jamie,

If the simulator stops with "time step too small", you should try some options to help the solver.

2. .tran 20m

Set a small time step in .TRAN , e.g 100n if you have a 100kHz switching frequency.

.tran 0 20ms 0 100n

If it alreay fails at the beginning, you should try with the option "startup" in the .TRAN command. Sometimes additional ".nodeset" will help to get the simulation started.

.tran 0 40ms 0 100n startup

I prefer to continue as shown below.

Control Panel -> SPICE -> Reset to default Control Panel -> Hacks -> Reset to default

There are some options which can be helpful. Try either one, some or all in combination. These are SPICE directives which you place in your schematic.

.options gmin=1e-10 .options abstol=1e-10 .options reltol=0.003

2. If that fails, you could try with the Alternate solver. Therefore don't use any option from above orr set them to their default values.

Control Panel -> SPICE -> Reset to default Control Panel -> SPICE -> Solver: Alternate

The default values: .options gmin=1e-12 .options abstol=1e-12 .options reltol=0.001

2. If it still fails, go back to the normal solver.

Control Panel -> SPICE -> Solver: Normal

Use the following only as the last option, because it can have a lot of side effects, especially if you have used a larger value for cshunt.

.options cshunt=1e-15

This adds a capacitor with 1fF from every node to GND. I wouldn't go higher than 1e-14.

You should also use a combination of these options as in 2) in this case. .options gmin=1e-10 .options abstol=1e-10 .options reltol=0.003

Best regards, Helmut

Hello Jamie,

In addition to the good tips of Helmut, you may check your circuit for unrealistic components. A real inductor has loss that you can model with resistors and capacitors.

To increase the simulation speed and/or solve convergence problems, you can add a resistor in parallel with problematic inductors. You may add a capacitor in series with the parallel resistor when the effect on circuit behavior is too large.

Good luck with getting your simulation to run!

Wim PA3DJS

und

It is better to use the values that are part of the inductor rather than adding ones. Right click on the inductor and fill in the stray values. The solver runs faster with them built into the part because it has an extra optimization for that.

I have come to the conclusion there is a bug in it. Because when I receive this error, changing a value enough to make it happy allows a SIM operation. Then after a SIM run, I can go back and change that same component to the value I had that generated the error to which it will then exec the SIM with no problems.

Since I do a lot of coding my self, I see this as an initiation problem of variables or something of that sort on start up!.

I don't recall seeing this problem before the last update that was done. But then again, I'm getting old and memory loss maybe an issue :)

Hello Jamie,

Can you send me one example for trying?

Best regards, Helmut

Hello Jamie,

Maybe you feel it's different, because LTspice nowadays tries with "pseudo transient analysis" to find the operating point when the classic methods failed. Older versions simply started with the transient simulation even without having found an operating point. You could suppress this method with this SPICE-directive. .options ptrantau=0

Best regards, Helmut

As I indicated in another message, I found that after I make the SIM happy, I run a SIM and if I change the values back to where they were that caused the problem, I can rerun SIM with no issues ;/

Something is wrong with the software. A initiation problem perhaps?

BTW. I do use the options in the control panel to make it nearest to real world operation as possible. Nice features btw and still learning what most of them do, good thing there are docs :)

I tried a combination of things and no matter what I did, once the error was there, it just wasn't going to start. This error takes place at the very beginning. It does not happen once the annalistic data starts collecting.

Who knows, maybe one day I'll track it down..

Thanks.

But toggling the values between SIMS does not explain why I can get it to SIM with the values that originally generated the problem.

Oh well. One day I may find out the issue.

I'll keep that noted, I don't remember seeing this in older versions, It may have something to do with it.

Thanks.

Changing inductors to capacitors can have lots of consequences :-)

Assuming that you didn't actually mean what you wrote, try using the "alternative" solver for a start.

Maybe post the .asc file and people might take a look at it.

You might want to review the following article, which discusses some of the possible causes of Spice convergence failures (which is what you're seeing here). Much of the discussion applies to most SPICE variants and derivatives.

round

it

ld

ps

I am not familiar with LTspice. However when you can add parasitics inside the inductor subcircuit model, I agree that it is better to do that instead of adding parasitics externally. Off course it depends on how the parasitics are modeled inside the inductor subcircuit and whether or not parameter extraction has been done for certain inductor types.

Best regards,

Wim PA3DJS