|
I had downloaded the MAX44241 Spice model and Ltspice schematic from Analog's website. For some reason I get the following error message. " Analysis: Time step too small; initial timepoint; trouble with u1: desd-instance d:u1:3 " I didn't change anything within the model or schematic itself so I'm not too sure why is occurred. Please note I am limited to use Ltspice XVII and can't update my software to LTspice 24, due to my company not approving that version of the software. I was wondering if there is a work around to get that error to not show up anymore and run without any issues within LTspice XVII.
Link:?
|
Such errors are difficult to resolve. In this
particular case, where an ADI schematic won't run. I suggest a
report to ADI's Engineer Zone. It should run in XVII, unless ADI
say it won't.
On 2025-02-26 14:02, ehernan3 via
groups.io wrote:
I
had downloaded the MAX44241 Spice model and Ltspice
schematic from Analog's website. For some reason I get the
following error message. " Analysis: Time step too small;
initial timepoint; trouble with u1: desd-instance d:u1:3 " I
didn't change anything within the model or schematic itself
so I'm not too sure why is occurred. Please note I am
limited to use Ltspice XVII and can't update my software to
LTspice 24, due to my company not approving that version of
the software. I was wondering if there is a work around to
get that error to not show up anymore and run without any
issues within LTspice XVII.
Link:?
--
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
|
"Time step too small" errors have plagued SPICE users for half a century.? It is not easy to predict when they will happen, and can be even harder to eliminate them.
?
Download the LTspice FAQ file.? Open it, and read until you find the section about "time step too small" errors.? Then read that section carefully.? It has a couple dozen things to TRY, in an attempt to get around the problem.? There are no guarantees. ?
Andy
?
?
|
Also FYI -
?
The occurrence of the error tends to depend on both the SPICE part models, and on the circuit you used them in.? That model from Analog Devices might work perfectly in every other circuit they tried, but not your circuit.
?
That being said, if one must put the blame somewhere, it is most often caused by deficiencies in a part's model, rather than actually caused by the circuit where it was used.? Many SPICE models today - most of them - have functions that are not as well-behaved as they should be.? Discontinuities in those functions or their derivatives are the kinds of things that can lead to "time step too small" errors.
?
Andy
?
|
On 26/02/2025 15:02, ehernan3 via
groups.io wrote:
I
had downloaded the MAX44241 Spice model and Ltspice schematic
from Analog's website. For some reason I get the following error
message. " Analysis: Time step too small; initial timepoint;
trouble with u1: desd-instance d:u1:3 " I didn't change anything
within the model or schematic itself so I'm not too sure why is
occurred. Please note I am limited to use Ltspice XVII and can't
update my software to LTspice 24, due to my company not
approving that version of the software. I was wondering if there
is a work around to get that error to not show up anymore and
run without any issues within LTspice XVII.
The MAX44241 model is now supplied with LTspice, as from 02/15/22.
Have you been able to update your components since since that date?
There is a line in the changelog suggesting this a corrected model,
which implies the previous one might have been problematic.
The model supplied with LTspice is different from the one on the ADI
website.
I have version LTspiceXVII 17.1.15 and the MAX44241 example circuit
runs fine with the current supplied model. I have uploaded this
model to Files > Temp as MAX44241.lib.zip.
Try that.
--
Regards,
Tony
|
Did you use the MAX44241 model that comes with LTspice?? Or did you download the Macro Model from ADI's website?
?
They are probably not the same.? (I didn't check this, but you could.)? You might find that the model that comes with LTspice, works a little better than the other one.
?
Andy
?
?
|
On 26/02/2025 15:35, Andy I via
groups.io wrote:
Did you use the MAX44241 model that comes with LTspice?? Or
did you download the Macro Model from ADI's website?
?
They are probably not the same.? (I didn't check this, but
you could.)? You might find that the model that comes with
LTspice, works a little better than the other one.
They're not the same. I have already uploaded the current model file
to Files > Temp.
--
Regards,
Tony
|
I downloaded it directly from ADI's Website because the version that I have for LTspice XVII doesn't include the MAX44241.? When I checked if the component was within my version of Ltspice it wasn't.?
|
Thank you for uploading the file, but when I try to open the .zip file I get an message saying "Assert Error ( WZTStamp.c@556)" The parameter is incorrect." . Would you be able to re upload the file or if there is a work around for this error as well.? ?
In any case thank you again for your help.
|
On 26/02/2025 16:34, ehernan3 via
groups.io wrote:
Thank you for
uploading the file, but when I try to open the .zip file I get an
message saying "Assert Error (WZTStamp.c@556)" The parameter
is incorrect." . Would you be able to re upload the file or if
there is a work around for this error as well.?
As far as I can see, there's nothing wrong with the uploaded zip,
but I updated the upload with just the .lib file.
Can you normally open zip files in Explorer?
--
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.
|
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
|
Yeah I normally don't have issues with .zip files, but for some reason I couldn't the files within that zip
?
|
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
|
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
?
|
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.
|
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.
|
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.
|
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
|
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.
|
John Woodgate
Tony Casey
eewiz