¿ªÔÆÌåÓý

Date

Re: LTspice XVII error work around #Time-step-too-small

 

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.


Re: LTspice XVII error work around #Time-step-too-small

 

¿ªÔÆÌåÓý

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


Re: LTspice XVII error work around #Time-step-too-small

 

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.


Re: LTspice XVII error work around #Time-step-too-small

 

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.?


Re: LTspice 24.1 Simulation Errors

 

¿ªÔÆÌåÓý

On 25/02/2025 09:17, herman.vos via groups.io wrote:
I have just uploaded the update on the 74LVC1G.lib here:
Thanks for this. However, I just tried the old model library, and no syntax errors are reported in V24.1.4.

Parentheses in the .model statements have always been ignored anyway, so it shouldn't matter whether they are unbalanced. The other "errors" with VCC & VCC3 aren't strictly errors either, because parameters should recurse down the hierarchy provided they are not redefined somewhere. I think we can regard previous versions of V24.1 as being a little overzealous.

As a purist, though, I appreciate the corrections, which I will incorporate in any future versions of the library.

--
Regards
Tony


Re: LTspice XVII error work around #Time-step-too-small

 

¿ªÔÆÌåÓý

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


Re: Issues running LTspice as a batch service

 

¿ªÔÆÌåÓý

This is a good example in support of the file management strategy of including all symbols (and models and whatnot) that are not part of the LTspice installation in the same directory (folder) as the schematic which uses/invokes them. Doing so ensures that all files that the simulation needs are available to whichever user (or other entity) is going to use the simulation.

Donald.

On 2/25/25 22:08, Andy I via groups.io wrote:

On Tue, Feb 25, 2025 at 08:32 PM, Jeff Kayzerman wrote:
.... Does anyone know why running in batch mode as a service account it would fail to look in the search paths?
This is only a guess here.? But I suspect you have defined User folders for your symbols and models, which reside in one of your account's folders, perhaps under its "Documents" folder or "AppData" or whatever.? The other account does not have the same folders.? Well, it has the same-named folders but they are distinct for each user.? So it does not see the same library areas.
?
The settings in the .ini file are relative to each account's folders, as managed by MS-Windows.? Windows does a good job of hiding their actual physical locations.
?
Andy
?


Re: LTspice XVII error work around #Time-step-too-small

 

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
?
?


Re: LTspice XVII error work around #Time-step-too-small

 

¿ªÔÆÌåÓý

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


Re: LTspice XVII error work around #Time-step-too-small

 

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
?


Re: LTspice XVII error work around #Time-step-too-small

 

"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
?
?


Re: LTspice XVII error work around #Time-step-too-small

 

¿ªÔÆÌåÓý

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

Virus-free.


LTspice XVII error work around #Time-step-too-small

 

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:?


Re: Frequency dependent common mode inductor

 

From (complete_reference):

Bxxx n1 n2 V=<expression>
Bxxx n1 n2 I=<expression> [Rpar=<value>] *[Cpar=<value>]
+ [[ic=<value>] tripdv=<value>] [tripdt=<value>]
+ [Laplace=<func(s)> [window=] [nfft=<num>] [mtol=<num>]]
* + [[units] Freq=<valuelist> [delay=<value>]] <=================
* + [NoJacob]
* Bxxx n1 n2 R=<expression>
* Bxxx n1 n2 P=<expression> [VprXover=<value>]

-marcel


Re: Frequency dependent common mode inductor

 

¿ªÔÆÌåÓý

I guess so. LTspice comes with lots of models for them from Schaffner and W¨¹rth. Do you have a part number for yours?

F2 > [Contrib] > Schaffner > EMI
F2 > [Contrib] > Wurth > EMC-Components > CommonMode_Chokes

Or you could try to make one from two coupled inductors. It's easier than you probably thought.

Not quite so easy to tune it to exactly fit your table though, but there's usually significant tolerance on EMC chokes, anyway.

--
Regards,
Tony


On 26/02/2025 08:55, F.an via groups.io wrote:

is it possible to build a "Frequency dependent common mode inductor" in LTspice?
?
f Ls Cs Rs
[HZ] [uH] [pF] [ohm]
50 2040.3 4966800000 0.11861
100 2023.6 1251600000 0.13833
500 1997.3 50727000 0.47052
1000 1962.3 12905000 1.2977
5000 1636 619260 15.796
10000 1320.2 191850 36.245
50000 710.19 14266 144.23
100000 520.68 4864.9 247.12
500000 212.64 476.5 958.8
1000000 15.536 1631.6 1963.6
5000000 6.5795 154.02 79.92


Re: Frequency dependent common mode inductor

 

¿ªÔÆÌåÓý

Yes, as a piece of circuit or a subcircuit. But the data you have is all expressed in series component terms, whereas the circuit needs, at least,? parallel resistance and capacitance elements, which possibly could be calculated from your data. Obviously, the inductor does not have a physical series capacitor. Have you asked the manufacturer for a SPICE (not 'LTspice') model?

On 2025-02-26 07:55, F.an via groups.io wrote:
is it possible to build a "Frequency dependent common mode inductor" in LTspice?
?
f Ls Cs Rs
[HZ] [uH] [pF] [ohm]
50 2040.3 4966800000 0.11861
100 2023.6 1251600000 0.13833
500 1997.3 50727000 0.47052
1000 1962.3 12905000 1.2977
5000 1636 619260 15.796
10000 1320.2 191850 36.245
50000 710.19 14266 144.23
100000 520.68 4864.9 247.12
500000 212.64 476.5 958.8
1000000 15.536 1631.6 1963.6
5000000 6.5795 154.02 79.92
--
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

Virus-free.


Frequency dependent common mode inductor

 

is it possible to build a "Frequency dependent common mode inductor" in LTspice?
?
f Ls Cs Rs
[HZ] [uH] [pF] [ohm]
50 2040.3 4966800000 0.11861
100 2023.6 1251600000 0.13833
500 1997.3 50727000 0.47052
1000 1962.3 12905000 1.2977
5000 1636 619260 15.796
10000 1320.2 191850 36.245
50000 710.19 14266 144.23
100000 520.68 4864.9 247.12
500000 212.64 476.5 958.8
1000000 15.536 1631.6 1963.6
5000000 6.5795 154.02 79.92


Re: Monitor simulation percent completion from python

 

The expanded netlist returned few weeks ago in 24.1.3. It shows the components with their parameters immediately at the start of the simulation in the log file. But not the timing related parameters. All parameters are listed using .options logparams , but only when the simulation is finished.
?


Re: Create symbols.

 

OOHH, thanks, I'll look into them....
Let's see if I can associate the symbol of an existing OP with the model I'm interested in, which is the MCP65R46.


Re: .MEAS Failure

 

On Tue, Feb 25, 2025 at 12:59 AM, eewiz wrote:
Subtracting 8ms from the start and stop values on the abscissa saw the plot window simply stop rendering in mid-redraw.
FYI, that is not what I suggested.? Leave the Start and Stop (or Left and Right) values alone.? Let LTspice figure them out on its own.? Change the text in the "Quantity Plotted" box.? THAT is the thing that shifts the entire waveform horizontally, shifting it so that time values that were near 8 ms, become near 0 seconds where resolution is better.? A picosecond out of 8 milliseconds is 0.125 part per billion.? A picosecond out of nanoseconds is a part per thousand.? Much less likely to be lost due to limited numerical precision.
?
But I suggested it only as a way to visually see smaller increments of time, which you do not need to do if you don't want to.
?
The .raw file for the run is 11.5GB.
.SAVE might help.
?
Before trying to shift the abscissa I did see that the values either side of 2.
With 15 digits, the values were much closer to 2 but still no 2.000000000000 value.
Of course you won't.? You 'never' will.? The chances are vanishingly small.
?
Keep these two fundamental principles in mind:
  1. SPICE/LTspice is a discrete time simulator.? There is no continuous time.
  2. .MEASURE is a POST-processing step.? All .MEAS commands are processed AFTER the simulation is over and done with.? It does not command the simulator to re-simulate until it finds the exact point where the voltage was 2.00000000000.? It interpolates between the closest simulated points that straddle it.? The chance that one of those simulated points hits 2.00000000000 volts exactly is astronomically small.? It will 'never' happen.
?
Therefore the effect, however it may be accomplished, is to print the time at which the next sample found is LESS-THAN 2 volts.
That is not what it does either.? It takes the two points that surround 2 V, and then it interpolates between them, to extract the time when a straight-line waveform would have crossed 2.0 V exactly.? That happens before the sample that was less than 2 V.
?
Wouldn't it be a phenomnal waste of processor time to interpolate between points, following the resultant curve, to find a point on that curve that is exactly 2.0000000000 volts when simply looking for the first value of data less-than 2 volts provides the same result.
It would not be a waste of time.? In your case, the difference between the interpolated time and the last simulated time might be mere nanoseconds, or who knows, femtoseconds?? But in another case it might be milliseconds or more.? LTspice always does the right thing, by interpolating and not ignoring the fact that waveforms take time to get from point A to point B.? Assuming that it ignores it would be wrong.
?
?
Regardless of how it is accomplished, the end result of using FALL=1 is to print the time at which the first data value less-than 2 is found.
That's incorrect.
?
Andy
?