|
You have the Eeyore settings too high in both
simulators
On 2025-02-28 13:43, Robert via
groups.io wrote:
This morning I again broke up the big reservoir capacitor
into one reservoir capacitor for every SMPS, and this time the
model remained happy. Aaaaand the results are in. LTSpice (with
similar PTC and similar regulator) showed reasonable agreement
with Simplis (with the PTC as a fixed resistor and the correct
regulator). BTW, Simplis converges with no fiddling about, but
then it is intended to address the problems associated with SMPS
modelling. What's not so good (but interesting) is when I
compare the modelled steady state currents with my pages of
maths and with measurement of the built unit:
?
LTSpice: 1100 mA
Simplis: 1050 mA
Calculated worst possible case: 602 mA
Measured under normal operating conditions: 574 mA
?
?
--
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
|
This morning I again broke up the big reservoir capacitor into one reservoir capacitor for every SMPS, and this time the model remained happy. Aaaaand the results are in. LTSpice (with similar PTC and similar regulator) showed reasonable agreement with Simplis (with the PTC as a fixed resistor and the correct regulator). BTW, Simplis converges with no fiddling about, but then it is intended to address the problems associated with SMPS modelling. What's not so good (but interesting) is when I compare the modelled steady state currents with my pages of maths and with measurement of the built unit:
?
LTSpice: 1100 mA
Simplis: 1050 mA
Calculated worst possible case: 602 mA
Measured under normal operating conditions: 574 mA
?
?
|
On Thu, Feb 27, 2025 at 09:26 AM, Andy I wrote:
Of course it should not have made any difference whatsoever.
I think it would make a difference because the solver has to determine additional unknowns with more capacitors, namely the current through each individual capacitor. There are no additional nodes, but there are more branches. This may be enough to make the matrix numerically unsolvable.
|
Yes, I read all the advice and started out with a very low value for CSHUNT, but ended up with 5pF in order to get convergence. However, this was BEFORE I added the LT1375. Rather than a proper SMPS I was initially working with a switched load on the PTC, and then a Heath-Robinson arrangement of switches and pulse generators set up to do something SMPS-like in the simplest possible way, because the regulator I'm actually using (MCP16331T-E/CH) doesn't appear to have a SPICE model. So 5pF was not unreasonable. If I had stuck with 1e-15 I would still be tearing my hair out. However, having made some progress and achieved something that didn't look completely wrong, I then went on a search for something a bit like a MCP16331T-E/CH that had a model, in order to move a little closer to reality. I was not surprised to find I now had convergence problems again, but this time no matter what I did I either got no convergence at all, or LTSpice slowed to a crawl. But with CSHUNT removed and the timebase shift, I now have all six SMPS's working with the PTC in place, and I can see that it should pass the formal inrush current test by a significant margin, even though strictly speaking it doesn't have to (if the customer asks you to jump a hurdle, and doing so wont kill you, you jump the hurdle). Apart from the capacitor oddity, the model is now stable against changes. And yes, when I replaced one big capacitor with several capacitors in parallel I used ideal capacitors, not capacitors with parasitics. I might try again now I've made various changes.
?
Regarding voltage/current sources, I gave the voltage source a series resistor. From what I've read, LTSpice will convert such voltage source to the equivalent current source before modelling commences, so I didn't do that manually.
?
?
|
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:
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.
--
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
|
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.
|
On Thu, Feb 27, 2025 at 09:58 AM, Robert wrote:
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.
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
?
|
On Thu, Feb 27, 2025 at 07:04 AM, eewiz wrote:
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.
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
?
|
On Thu, Feb 27, 2025 at 04:20 AM, Robert wrote:
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
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
?
|
On Thu, Feb 27, 2025 at 04:20 AM, Robert wrote:
5pF is not unreasonable for the circuit I'm modelling,
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
?
|
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.
|
On 27/02/2025 11:33, Robert via
groups.io wrote:
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.
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
|
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.
|
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.
|
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.
|
On Wed, Feb 26, 2025 at 11:07 AM, Robert wrote:
As it happens I'm struggling with this old SPICE chestnut right now, working on trying to model the effect of a PTC fuse. This post resulted in me adding the directive: ?
.OPTIONS ITL4=100 ABSTOL=1E-9 VNTOL=1E-3 RELTOL=0.01 CSHUNT=5e-12
?
and that worked just fine for a while ... until I added an LT1375HV to the mix to try to move closer to what I actually want to model. ...
Did you try some or all of the options listed in the LTspice FAQ (Frequently Asked Questions) file?? Please see the message # 158795 that I sent earlier today about that.
?
These "Timestep too small" errors do not have one remedy that always works.? That is why the FAQ file lists several things to try, and suggests trying all of them until you find something that works.
?
More than likely, your original circuit already had issues which had prompted you to add those .OPTIONS to the simulation to get it to work - and they helped that one case.? Then, adding another component to the circuit changed the mix of part models that were in your simulation, causing the "time step too small" error to return.? Like I say, no single remedy always works.? You have to be persistent.
If it's any consolation, upgrading from LTspice XVII to the latest version after I added the LT1375HV didn't help me.
I would not expect that to make any difference.? It is not a bug in a version of LTspice.? Both versions have essentially the same simulator algorithms so they do pretty much the same thing.
Neither did switching to the Gear integration method, which was recommended in that post I referenced.
That is but one of several things to try.? Download and read that FAQ file, then start trying the many things it suggests to try.
?
Tony's note about the rather large value for CSHUNT is important.? That number is "huge", and it is applied to every single circuit node!? It probably significantly (negatively) alters your simulated results, whether or not it helps avoid the "timestep too small" errors.? I think it should be at least one order of magnitude smaller than 5E-12.? The original note you said you got this from, did not mention CSHUNT, but it is one of the things that can help with these errors.
?
Andy
?
|
It looks like a corrupt download to me: an
error in the PDF code. Delete the .ZIP and try downloading
again.
On 2025-02-26 16:31, ehernan3 via
groups.io wrote:
Yeah I normally don't have issues with .zip files, but for
some reason I couldn't the files within that zip
?
--
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
|
Yeah I normally don't have issues with .zip files, but for some reason I couldn't the files within that zip
?
|
On 26/02/2025 16:58, Robert via
groups.io wrote:
As it happens I'm struggling with this old SPICE chestnut
right now, working on trying to model the effect of a PTC fuse.
This
post resulted in me adding the directive: ?
.OPTIONS ITL4=100 ABSTOL=1E-9 VNTOL=1E-3 RELTOL=0.01
CSHUNT=5e-12
?
and that worked just fine for a while ... until I added an
LT1375HV to the mix to try to move closer to what I actually
want to model. If it's any consolation, upgrading from LTspice
XVII to the latest version after I added the LT1375HV didn't
help me. Neither did switching to the Gear integration method,
which was recommended in that post I referenced.
5pF is very high capacitance to add to every node in your circuit.
It could significantly change the behaviour of many circuits.
Does the supplied LT1375HV example circuit simulate OK in your
version of LTspice without any .options? I just tried it in XVII
V17.1.15 and it worked fine.
I guess your schematic must have other components on it, since you " added
the LT1375HV"? Most likely, it would be one of those that
was causing problems. The LT-supplied models usually don't cause any
problems at all, but other proprietary models, often do.
If you still have trouble, you might consider uploading your
schematic to Files
> Temp, together with all models and symbols that didn't
originally come with LTspice. Multiple files should be uploaded in a
zip. Someone will take a look.
--
Regards,
Tony
|
As it happens I'm struggling with this old SPICE chestnut right now, working on trying to model the effect of a PTC fuse. This post resulted in me adding the directive: ?
.OPTIONS ITL4=100 ABSTOL=1E-9 VNTOL=1E-3 RELTOL=0.01 CSHUNT=5e-12
?
and that worked just fine for a while ... until I added an LT1375HV to the mix to try to move closer to what I actually want to model. If it's any consolation, upgrading from LTspice XVII to the latest version after I added the LT1375HV didn't help me. Neither did switching to the Gear integration method, which was recommended in that post I referenced.
|
John Woodgate
eewiz
Tony Casey