|
Trying to get this opamp model to work. I keep getting errors. I know it has to do with the "TABLE" lines, but not sure how to fix. Model was pulled from OnSemi's website.
?
File is posted in the temp section as NCS2001_test.zip
|
I get "timestep too small".
?
Is that NOT the error you see?
Andy
?
|
I downloaded a model from OnSemi and am having issues with it simulating. Something about the TABLE lines. I am not a Spice expert, but would like some guidance to get the model working.
?
|
There appears to be something missing from
your upload. Download the .ZIP to Downloads and open it from
there. There is a wire form C3 that goes nowhere and one
labelled fb that also goes nowhere. Also, there is a PULSE spec
with no generator associated and no Table lines on the .ASC or
in the .NET file.
On 2025-04-10 22:17, DerekK wrote:
I downloaded a model from OnSemi and am having issues with it
simulating. Something about the TABLE lines. I am not a Spice
expert, but would like some guidance to get the model working.
?
--
Best wishes John Woodgate RAYLEIGH Essex 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 Thu, Apr 10, 2025 at 05:17 PM, DerekK wrote:
I downloaded a model from OnSemi and am having issues with it simulating. Something about the TABLE lines. I am not a Spice expert, but would like some guidance to get the model working.
I still get the "timestep too small" error.? ?But I'm using the computer with the older LTspice version today.
?
See the FAQ file for help with "timestep too small" errors - if that is what you see.? If not, read on. ?
Which version of LTspice did you try?? I suspect the problem you have may be version-specific.? What specific error messages do you get?? Not "something about the TABLE lines", but what exact errors did you see?
?
The NCS2001.LIB model file looks to be poorly formed, and that might be the source of problems.? I see about a dozen TABLEs that look something like this:
GD16 16 1 TABLE {V(16,1)} ((-100,-100E-15)(0,0)(1m,1u)(2m,1m))?
which looks wrong for multiple reasons.? For one, I think there should not be all those {curly braces} like this pair around V(16,1).? I think you can delete the curly braces.? Technically there "should" be parentheses around everything after "TABLE", but sometimes parentheses are optional in SPICE and that might be the case here.? However, this format looks wrong for a G-source TABLE() function where all the values should be in pairs, but it might be right for a B-source TABLE() where the first parameter is an index into the remaining pairs of values.? This could be an issue.? I think older versions of LTspice upgrade the G-source to a B-source where this kind of TABLE() function would be OK, but that might not happen anymore since LTspice's netlisting changed.? If so, this could be a new (unreported) bug.
?
I think the things John mentioned are non-issues.? Wires to nowhere do not matter even if they look funny.? The same with comment text, assuming that you meant it to be a comment.
?
Andy
?
|
Derek,
?
If I am right about the formatting of the G-source TABLE() functions, you can modify them like the following:
?
First TABLE function (1 of 12):
? ? old line:? GD16 16 1 TABLE {V(16,1)} ((-100,-100E-15)(0,0)(1m,1u)(2m,1m))?
? ? new line:? GD16 16 1 16 1 TABLE((-100,-100E-15)(0,0)(1m,1u)(2m,1m))?
?
Note what I've done is:
- Move the keyword "TABLE" to the right, past the V-source that previously came after it.
- Change "V(x,y)" to "x y".
- Leave the rest of the line intact.
From my read, this would make the syntax "correct" according to the LTspice Help page for G-sources.? You would need to repeat this 12 times, once for each of the 12 TABLE() functions in that model.
?
But the catch is that this is obscure SPICE syntax, and there is no guarantee that either older versions or newer versions of LTspice handle it correctly.? When Analog Devices re-coded LTspice 24, they may or may not have carried forward the right processing of these TABLE() functions.
?
This model also has an E-source with {curly braces} that maybe should not be there.? But that is yet another matter.
?
Andy
?
|
On Thu, Apr 10, 2025 at 02:54 PM, John Woodgate wrote:
There is a wire form C3 that goes nowhere and one labelled fb that also goes
I extracted the main simulation I was working on. The .asc is the portion that should work. It is just that I was getting errors about the model.
|
On Thu, Apr 10, 2025 at 04:41 PM, Andy I wrote:
But the catch is that this is obscure SPICE syntax,
Thanks Andy. I will attempt to correct the model when I get back to this next week. I was not sure how to handle the TABLE statement. I do have the latest LTSpice loaded.?
?
As for the age of the model, I have no idea what OnSemi is basing this off of.
|
Derek,
?
I think your voltage source V1 is wrong.? Its sine wave amplitude is 1.2 V with a DC offset of 0.6 V, so it swings between -0.6 V and 1.8 V.? That goes low enough to violate the Absolute Maximum Input Common Mode Voltage Range, and Note 1 below the table.? You would be damaging the part.
?
Andy
?
|
Derek,
?
I have (maybe) good news and mostly not so good news.
?
I think my obsessing over the syntax was somewhat misplaced.? In my opinion this form of the TABLE function is rare, and it's not documented in LTspice's help, but it does exist in at least two other SPICE programs - even with those darned curly braces!.? The problem is that LTspice is not obligated to support it, even though it does now it previously did and it would be best if it continues to do so.
?
From what I can tell, older versions of LTspice did correctly handle that TABLE() syntax.? It silently converted the G-sources to B-sources, with the B-source's TABLE() function which is better suited for that TABLE() syntax.
?
From your experience with this model file, it is possible that LTspice version 24.1 broke that, and it no longer works.? If so, you should report it to Analog Devices.
?
Separately, I modified onsemi's NCS2001 model file by converting the TABLEs to the other form as documented in LTspice's Help.? Today I can't use the computer that has the latest LTspice, at least for a few more hours.? But with an older version, my modified model file runs without syntax errors.? (The unmodified model did too, so that is not really an improvement for those using pre-24.1 LTspice.)
?
Interestingly, after changing the TABLE() syntax, LTspice does not convert the G-sources to B-sources.? So the old code knew what to do in either case and did it correctly.? Let's hope that v24.1.6 can handle the alternate TABLE() syntax.
?
However, I still can not run your simulation.? It always aborts while trying to find the initial operating point, always with a "timestep too small" error.? That is not a real timestep because it is still in the DC phase, but that's a detail left for another time.
?
So the bottom line is I still can't get it to work.? Syntax-wise, it seems to be OK.? But for me, both original and modified models quit in the same way.? Maybe you will have better luck, as the latest LTspice might converge better.? I did not try modifying your circuit to see if the misconvergence? problem could be avoided another way.
?
I uploaded my modified model file in: NCS2001_test_AI.zip in the Temp folder.
?
Andy
?
|
Oops, I mis-stated.??I wrote:
The problem is that LTspice is not obligated to support it, even though it does now and it would be best if it continues to do so.
That should have said, "... even though it previously did and it would be best if it continues to do so."
?
Andy
?
|
Hi,
?
The line
?
GD16 16 1 TABLE {V(16,1)} ((-100,-100E-15)(0,0)(1m,1u)(2m,1m))?
?
is pspice syntax and accepted by LTspice. You need not change it. The only downside of the pspice syntax is that it is not documented, for obvious reasons.
?
I reiterate: We don't change LTspice just for the fun of changing things. We have very good reasons. Above all, we strive to let the program be backward compatible. That's much harder than it might appear, though. We want everything that worked in prior versions to keep working, unless there is a good reason not to.
?
Best Regards,
Mathias
?
On Fri, Apr 11, 2025 at 01:41 AM, Andy I wrote:
Derek,
?
If I am right about the formatting of the G-source TABLE() functions, you can modify them like the following:
?
First TABLE function (1 of 12):
? ? old line:? GD16 16 1 TABLE {V(16,1)} ((-100,-100E-15)(0,0)(1m,1u)(2m,1m))?
? ? new line:? GD16 16 1 16 1 TABLE((-100,-100E-15)(0,0)(1m,1u)(2m,1m))?
?
?
?
But the catch is that this is obscure SPICE syntax, and there is no guarantee that either older versions or newer versions of LTspice handle it correctly.? When Analog Devices re-coded LTspice 24, they may or may not have carried forward the right processing of these TABLE() functions.
?
?
Andy
?
|
It's not that they look funny, it's that the
output of U2 (marked 'fb' for 'feedback?), goes nowhere, and the
supply rail from C3 looks as if it should power something,
perhaps a missing U1? I also note that U3 doesn't do anything
useful; it and R7 could be eliminated and V2 connected to R6.
On 2025-04-11 00:18, Andy I via
groups.io wrote:
I think the things
John mentioned are non-issues.? Wires to nowhere do not matter
even if they look funny.?
--
Best wishes John Woodgate RAYLEIGH Essex 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
|
Now the OP tells us that the.ASC is just a
fragment of something bigger, so loose ends are to be expected.
On 2025-04-11 09:56, John Woodgate
wrote:
It's not that they look funny, it's that the
output of U2 (marked 'fb' for 'feedback?), goes nowhere, and
the supply rail from C3 looks as if it should power something,
perhaps a missing U1? I also note that U3 doesn't do anything
useful; it and R7 could be eliminated and V2 connected to R6.
On 2025-04-11 00:18, Andy I via
groups.io wrote:
I think the things
John mentioned are non-issues.? Wires to nowhere do not matter
even if they look funny.?
--
Best wishes John Woodgate RAYLEIGH Essex 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
--
Best wishes John Woodgate RAYLEIGH Essex 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 Thu, Apr 10, 2025 at 10:57 PM, Andy I wrote:
I think your voltage source V1 is wrong.? Its sine wave amplitude is 1.2 V with a DC offset of 0.6 V, so it swings between -0.6 V and 1.8 V.? That goes low enough to violate the Absolute Maximum Input Common Mode Voltage Range, and Note 1 below the table.? You would be damaging the part.
In case I did not state this adequately, the concern is that you would literally fry U3.? Its input pin is being pulled well beyond U3's VEE supply voltage.
?
It does not appear to affect the simulation's convergence problem that I see.? It might be only a hardware problem.? And that op-amp would distort pretty badly, so maybe it would also affect how well it simulated - if only it simulated at all.
?
Andy
?
|
DerekK
John Woodgate