Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
- LTspice
- Messages
Search
Re: LTspice XVII error work around
#Time-step-too-small
¿ªÔÆÌåÓýI've never tried it with a switcher, but once
I looked at the ripple voltage and current at the reservoir
capacitor of a simple power supply, and saw what appeared to be
a 'ghost' of the series inductor (limiting inrush current) on
the AC side affecting the phase angle. Changing the inductor
value changed the phase a bit. This 'ghost' inductance might
series resonate with the lossless capacitor so as to produce
oscillations. Could be worth investigating. On 2025-02-27 17:29, eewiz via
groups.io wrote:
--
OOO - Own Opinions only If something is true: * as far as we know - it's science *for certain - it's mathematics *unquestionably - it's religion |
Re: LTspice XVII error work around
#Time-step-too-small
For resevoir and pump capacitors in switchers, I have found that adding ESR close to reality for the capacitor type, size and capacitance makes things better.
I have also found that adding some milliohms to model trace resistance in to and out of switchers helps.
If you are using 0V voltage sources to monitor input and output currents, series resistance can be added within each voltage source.
Even if you have only one bulk resevoir cap you can use five 0V sources, one for each switcher, to monitor the current into each switcher.
?
All for now
?
Sent:?Thursday, February 27, 2025 at 9:58 AM
From:?"Robert via groups.io" <birmingham_spider@...> To:[email protected] Subject:?Re: [LTspice] LTspice XVII error work around #Time-step-too-small Yes, I did try setting the maximum timestep, and all the other things in the FAQ. I also tried tweaking the circuit (same function, different way of achieving it), but as eewiz has found that just moved the problem to another random part of the circuit. Nothing I tried solved the problem, until I shifted the time base. Of course that could just as equally create a problem where none existed, as may the other fixes, but why would you go out of your way to create a convergence problem? As for models being "dodgy", well that is inevitable when a component behaves in a complicated way. A PTC fuse has only two legs and a simple task to perform, but in modelling terms its behaviour is complicated. Add in a monolithic SMPS, and there is even more to go awry when modelling.
?
Later this morning I added the remaining five SMPS's. I would like each to have its own reservoir cap, so I can measure the DC current each contributes, but that just results in a convergence failure. So I'm having to live with them sharing one big capacitor in the model.? ?Same (perfect) capacitance in the same electrical location, but one way of achieving that works and the other doesn't.
|
Re: LTspice XVII error work around
#Time-step-too-small
On Thu, Feb 27, 2025 at 09:58 AM, Robert wrote:
Let me see if I understand.? You have 3? 5 or 6 ideal capacitors connected in parallel, which fails?? And when replaced by one ideal capacitor with the same total capacitance, it doesn't? ?
I just want to make sure you did not accidentally select capacitors from LTspice's "Select Capacitor" menu.? All the capacitors in that menu are complex models for real (purchasable) capacitors, including parasitics.? They aren't ideal.? I'm assuming you didn't do that.
?
So let's say the capacitors you used really were ideal.? Of course it should not have made any difference whatsoever.? The fact that it does, suggests that you are right on the hairy edge of instability, and even the slightest change in matrix element calculations, caused one version to fail.? Could have gone either way.
?
Andy
? |
Re: LTspice XVII error work around
#Time-step-too-small
On Thu, Feb 27, 2025 at 07:04 AM, eewiz wrote:
You probably meant to say that you increased the tolerance values.? But you did that by making the magnitude of their negative exponents smaller, right?? So it's confusing to keep it straight, which way they went.? :-) ?
Decreasing them would have set their tolerances even tighter, which could be good for ultimate accuracy but bad for avoiding convergence failures.
?
Andy
? |
Re: LTspice XVII error work around
#Time-step-too-small
On Thu, Feb 27, 2025 at 04:20 AM, Robert wrote:
FYI, that is not unusual.? Combining models into the same simulation is often what causes misbehavior to rear its ugly head.? It's just how things often go.
?
Another thing you might consider, is changing your own models to avoid voltage sources, such as your PWL voltage source.? SPICE is happier with current sources, even to the point where a Norton equivalent circuit is less likely to lead to problems than its Thevenin equivalent, even though we know they are "identical".? They aren't - well, in SPICE they aren't.? (This is not just an LTspice thing.)
?
Andy
? |
Re: LTspice XVII error work around
#Time-step-too-small
On Thu, Feb 27, 2025 at 04:20 AM, Robert wrote:
Keep in mind, 5pF will be added to every single node in the circuit.? If you have an IC, which it appears you do (LT1375HV, maybe others), then it is added to every internal node of those models too.? It could significantly alter the simulation. ?
Helmut's recommendation in the FAQ file was CSHUNT = 1e-15, and not larger.? That is 1 fF (femtoFarad), or 0.001 pF.? He also noted: "Be very careful with this option. It may disturb your circuit."
?
IMO, 0.5 pF is not unreasonable for external pins that land on PCB pins (oops!) pads, but it is much too large for anything internal.? Also remember that many most SPICE models are not physical, and disturbing an internal node like this might change its calculations significantly.
?
Andy
? |
Re: plot window
alan,
?
I don't think you can add more than what LTspice gives you already in those plots.? There is no option to change the "Quantity Plotted" on the right axis, so no, you can't "hack" it to add something else.? In .AC analysis it insists on having the left and right axes that way.
?
Of course you can plot S21 and SWR in separate plot panes, which might be a better way to handle it.? ?(My LTspice is set up to use Vertical window tiles, which helps a bit.)
?
Andy
? |
Re: .MEAS Failure
Indeed, it is troubling to wonder exactly what is meant by asking when a signal is "< 2V".? That happens continuously, after the signal crosses below 2.0 V.? Surely you would not want the .MEAS command to spit out volumes of data for every possible time value from that point forward.? (There are infinitely many, after all.? Try fitting THAT in your .LOG file.)
?
IMO, that is one of the many things that causes much grief and confusion about the .MEASURE syntax.? Well, for me it is.
?
That is not LTspice's fault.? The .MEASURE command evolved over years (decades?) before there was an LTspice, so LTspice inherited the varied and confusing syntax that was already out there.
?
Also, for syntax sticklers, the fact that the .MEASURE command uses the assignment operator ("=") as if it were a comparison operator (should have been "==") is a little bit troubling.? But that is life and it is what it is (we have to accept it).? LTspice can't "fix" syntax mistakes without breaking it for thousands of existing SPICE users.
?
FYI, changing the "Quantity Plotted" is not a normal feature that everyone needs to know and understand.? It is one of those "rarely used" things that occasionally comes in handy, but you are not likely to know until then, and maybe never.
?
Andy
? |
Re: plot window
¿ªÔÆÌåÓýOn 27/02/2025 16:10, alan victor via
groups.io wrote:
Only for Bode. If you choose the Cartesian format, you can get imaginary. what other options do you want? S-parameters of 1 and 2 port networks are automatically available as plot options if you use the .NET directive with .AC analyses. This then gives you the options: Sxx, Yxx, Zxx, Zin & Zout. See: Help > LTspice > LTspice? > Dot Commands > .NET ¡ª Compute Network Parameters in a .AC Analysis For SWR and other formats like Gmax and MSG, I have defined plot functions, which are stored in the plot.defs file. Hardly anyone actually uses plot.defs, but it's very useful once you get used to it. E.g.: * Functions for RF design using S-parameters with 2 port networks * Note: due to the way LTspice displays functions (as voltages), MSG & Gmax are exported as square roots since they are powers to start with .func mS11() {mag(S11(V1))} .func mS21() {mag(S21(V1))} .func mS12() {mag(S12(V1))} .func mS22() {mag(S22(V1))} .func DeltaInt() {S11(V1)*S22(V1)-S12(V1)*S21(V1)} .func MSGInt() {ms21()/ms12()} .func KR() {(1-ms11()**2-ms22()**2+mag(DeltaInt())**2)/2/mag(S21(V1)*S12(V1))} .func GmaxInt() {1/(Kr()+sqrt(Kr()**2-1))*MSGInt()} .func MSG() {sqrt(MSGInt())} .func Gmax() {sqrt(GmaxInt())} .func VSWR(Sxx) {(1+mag(Sxx))/(1-mag(Sxx))} (Functions including "Int" are not for plotting, they are intermediate functions. Note: if you edit plot.defs (Plot Settings > Edit Plot Defs file), the changes don't become active until LTspice is closed and re-started. -- Regards, Tony |
Re: plot window
Thanks Tony.?
?
Yes, I tried. All I get are selections on GD and phase.?
?
For example, in using the s parameter script it would be nice to plot transmission gain s21 and SWR (for which I have a simple
expression) on left and right axis of a single plot pane. Are there more plot options if I rev up from LTspice XVII??
?
All done in simple AC analysis, so X axis is frequency.? |
Re: LTspice XVII error work around
#Time-step-too-small
Yes, I did try setting the maximum timestep, and all the other things in the FAQ. I also tried tweaking the circuit (same function, different way of achieving it), but as eewiz has found that just moved the problem to another random part of the circuit. Nothing I tried solved the problem, until I shifted the time base. Of course that could just as equally create a problem where none existed, as may the other fixes, but why would you go out of your way to create a convergence problem? As for models being "dodgy", well that is inevitable when a component behaves in a complicated way. A PTC fuse has only two legs and a simple task to perform, but in modelling terms its behaviour is complicated. Add in a monolithic SMPS, and there is even more to go awry when modelling.
?
Later this morning I added the remaining five SMPS's. I would like each to have its own reservoir cap, so I can measure the DC current each contributes, but that just results in a convergence failure. So I'm having to live with them sharing one big capacitor in the model.? ?Same (perfect) capacitance in the same electrical location, but one way of achieving that works and the other doesn't. |
Re: plot window
¿ªÔÆÌåÓýOn 27/02/2025 15:38, alan victor via
groups.io wrote:
(This only applies to plots in the frequency domain.) Did you try to change it? If you bring the cursor close to the left axis, its appearance will change to a ruler. You can right-click and you will get a dialogue where you can change the quantities plotted: Bode, Nyquist or Cartesian. For Bode, you can choose either phase or group delay, or none, by right-clicking on the right axis. -- Regards, Tony |
Re: LTspice XVII error work around
#Time-step-too-small
¿ªÔÆÌåÓýOn 27/02/2025 11:33, Robert via
groups.io wrote:
While changing the time base in some way can apparently cure the #Time-step-too-small problem, it can also do the reverse, as can any other circuit change. You also don't mention whether you have set a maximum time step. Sometimes this also makes the issue disappear. The underlying issue remains that one or more of the models is dodgy in some way. -- Regards, Tony |
Re: LTspice XVII error work around
#Time-step-too-small
I have also found that altering the start time of switching regulators can stop singular matrix (SM), time step (TS) and/or femtosecond crawl issues.
The MC34036 switcher invariable causes problems if permitted to start on its own.
Precharging its timing capacitor with ic=1.5 added to the capacitor's value causes the regulator to start later because the capacitor must discharge down to 1.24V before the requlator starts pumping.
In one instance, this was all it took to eliminate my singular matrix issue.
?
In another case, changing a capacitor ESR value in a charge pump eliminated a time step issue.
Also, I often find that reducing the tolerance values of trtol, abstol, vntol and chgtol help convergence and to reduce the likelyhood of SM, TS or femtosecond pace issues as a circuit grows.
?
I have a simulation that only runs with the level3a op-amp that comes with LTspice with its parameters set to mimic my desired op-amp.
Replacing the level3a with almost any "real" op-amp's model immediatly causes a singular matrix in some diode or transistor in some other part of my project that has nothing to do with the amplifier circuit where the op-amp was replaced.
Erasing that semiconductor with modifications to keep things working, simply shifts the complaint to another unrelated semiconductor and then another and so on, until I go back to the level3a op-amp.
I have tried dozens of "real" op-amp models and most cause the ascribed failure.
The ones that don't, have been so far removed from my desired op-amp, they are of no use to me in this instance.
Every one of those op-amp models works as it should when in a simple test circuit. ?
At times, I have to add a V source between ground and the output of switching requlator to prop up that output.
Doing so elimintes any ripple at the switcher's output and most likely reduces transient currents within the regulator circuit.
It can take a lot of trial error problem solving from there to eliminate the return of SM or TS issues when the prop is removed.
?
I push the go button and hold my breath each time after adding to or altering something in my project
?
All for now ?
Sent:?Thursday, February 27, 2025 at 5:33 AM
From:?"Robert via groups.io" <birmingham_spider@...> To:[email protected] Subject:?Re: [LTspice] LTspice XVII error work around #Time-step-too-small Well after a day of fiddling about with the values in my .OPTIONS and different integration methods (including the suggestions in the FAQ), I finally got my circuit modelling with just:
?
.OPTIONS ITL4=100 ABSTOL=1E-9 VNTOL=1E-3 RELTOL=0.01
?
You'll notice I took out CSHUNT. 5e-12 was the value I had to use (with LTSpice XVII) before I added the LT1375HV. Now I have got the model to converge with the LT1375HV (for the moment, at least; I have more things I need to add), I found that I could make CSHUNT anything from 5e-20 to 5e-12, with no obvious effect, so I then removed CSHUNT completely and it still converges. So what did I do to make it converge?
?
What I'm trying to determine is inrush current, so I have a PWL voltage source set to mirror what the external power supply will do when the test is performed for real. I happened to have it going from 0 volts at 1 ms to 28 V at 2 ms (because the test is defined in ms, and I like to steer clear of whatever SPICE does at time 0). Sometimes it's good to leave a problem overnight, and in the middle of the night I realised the model always fell apart before it got to 1 ms.? ?So this morning I simply changed the voltage generator to go from 0 at 1 ?s to 28 V at 1 ms, and the problem went away >doh!<. I do still need the .OPTIONS line above, but I'm using the default integration method (which is trapezoidal on LTSpice 24).
?
So there's another way to address the problem; timeshift the model so the circuit is doing something different at the time when the non-convergence kicks off.
|
Re: LTspice XVII error work around
#Time-step-too-small
Well after a day of fiddling about with the values in my .OPTIONS and different integration methods (including the suggestions in the FAQ), I finally got my circuit modelling with just:
?
.OPTIONS ITL4=100 ABSTOL=1E-9 VNTOL=1E-3 RELTOL=0.01
?
You'll notice I took out CSHUNT. 5e-12 was the value I had to use (with LTSpice XVII) before I added the LT1375HV. Now I have got the model to converge with the LT1375HV (for the moment, at least; I have more things I need to add), I found that I could make CSHUNT anything from 5e-20 to 5e-12, with no obvious effect, so I then removed CSHUNT completely and it still converges. So what did I do to make it converge?
?
What I'm trying to determine is inrush current, so I have a PWL voltage source set to mirror what the external power supply will do when the test is performed for real. I happened to have it going from 0 volts at 1 ms to 28 V at 2 ms (because the test is defined in ms, and I like to steer clear of whatever SPICE does at time 0). Sometimes it's good to leave a problem overnight, and in the middle of the night I realised the model always fell apart before it got to 1 ms.? ?So this morning I simply changed the voltage generator to go from 0 at 1 ?s to 28 V at 1 ms, and the problem went away >doh!<. I do still need the .OPTIONS line above, but I'm using the default integration method (which is trapezoidal on LTSpice 24).
?
So there's another way to address the problem; timeshift the model so the circuit is doing something different at the time when the non-convergence kicks off. |
Re: LTspice XVII error work around
#Time-step-too-small
5pF is not unreasonable for the circuit I'm modelling, but I've changed this value over a wide range trying to model my circuit and the OP might also want to try that; pick a value (eg 0.5pF) and take the exponent both up and down.
?
Regarding my own fight with this problem, I can model the LT1375HV on its own, and I can model the PTC fuse on its own, but when the two are combined I get convergence problems, either a complete failure or continuous use of tiny timesteps that make modelling impossibly slow (fs/s). If I continue to get nowhere I'll upload the files and start a new thread. |
to navigate to use esc to dismiss