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
|
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
?
|
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
?
|
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
?
|
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
?
|
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.
|
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.
|
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 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
?
|
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
|
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.
?
|
Re: Overriding a library diode's internal parameter(s)
Indeed -?almost everything in LTspice is case-insensitive, just like all SPICE programs.
?
LTspice does recognize upper/lowercase in a very limited situation in the waveform viewer, where "mHz" and "MHz" do not mean the same thing.? That is ONLY in the waveform viewer part of LTspice.
?
Andy
|
Re: Overriding a library diode's internal parameter(s)
More specifically, being SPICE, it doesn't
matter: SPICE is case-insensitive, regardless of what the OS
does.
On 2025-04-10 21:44, Richard Andrews
via groups.io wrote:
Does it matter if it's "rs", "RS", or "Rs"? It being windows
probably not?
--
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
|
Re: Overriding a library diode's internal parameter(s)
Does it matter if it's "rs", "RS", or "Rs"? It being windows probably not?
|
Re: Overriding a library diode's internal parameter(s)
Actually, I meant: LTspice XVII doesn't recognize rs as
a parameter of a diode model, which cannot be true.
But what really matters is why
the error occurs and how can it be fixed.
On 2025-04-10 21:18, Andy I via
groups.io wrote:
On Thu, Apr 10, 2025 at 03:13 PM, John Woodgate wrote:
Ah, that would means that
LTspice XVII doesn't recognize rs as a parameter of a
diode, which cannot be true.
No, that is actually correct.? Here is what a Diode element
line should look like, according to LTspice's Help:
Syntax: Dnnn anode
cathode <model> [area] [off] [m=<val>]
[n=<val>] [temp=<value>]
Notice there is no parameter named Rs.? The only listed
parameters are Area, "off", M, N, and Temp.
?
But you are mistaking it for the .MODEL parameter Rs.? .MODEL
parameters go only in .MODEL statements, not in the element
line.? The entire list of diode model parameters belong only in
the .MODEL statement.
?
Andy
?
--
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
|
Re: Overriding a library diode's internal parameter(s)
On Thu, Apr 10, 2025 at 03:13 PM, John Woodgate wrote:
Ah, that would means that LTspice XVII doesn't recognize rs as a parameter of a diode, which cannot be true.
No, that is actually correct.? Here is what a Diode element line should look like, according to LTspice's Help:
Syntax: Dnnn anode cathode <model> [area] [off] [m=<val>] [n=<val>] [temp=<value>]
Notice there is no parameter named Rs.? The only listed parameters are Area, "off", M, N, and Temp.
?
But you are mistaking it for the .MODEL parameter Rs.? .MODEL parameters go only in .MODEL statements, not in the element line.? The entire list of diode model parameters belong only in the .MODEL statement.
?
Andy
?
|
Re: Overriding a library diode's internal parameter(s)
On Thu, Apr 10, 2025 at 02:59 PM, Richard Andrews wrote:
Well defining it twice is no good.
Actually, defining something twice (or more) is usually OK in most SPICE programs.? I think it was designed to work that way.
?
In LTspice, sometimes you get a warning message, sometimes not.? And in newer versions, sometimes now it aborts, which could be considered either good or bad.
?
Andy
?
|
Re: Overriding a library diode's internal parameter(s)
On Thu, Apr 10, 2025 at 01:59 PM, Bell, Dave wrote:
The diode’s parameter string includes “rs=0.0384”, and I want to vary that to adjust the curve to the panel I want to simulate.
FYI, another way you can do that, which might work reasonably well, is this:
- Edit the .MODEL command to make its Rs=0.
- Add a discrete resistor in series with the diode, with resistance = Rs.
There might be some advantage to doing it this way, e.g., if the value of Rs needs to vary.? If it is inside the .MODEL definition, it can't.? If it is an external resistor, it could.
?
Andy
?
|
Re: Overriding a library diode's internal parameter(s)
On Thu, Apr 10, 2025 at 01:59 PM, Bell, Dave wrote:
I imagine I could use a default “D” diode and modify all of the params, but I don’t see any way to copy the LONG string listed in “Pick new diode”.
When you use "Pick New Diode", you select from the diodes in your standard.dio (and/or user.dio).? Therefore, open standard.dio in Notepad/Wordpad or your editor of choice, or in LTspice itself.? Find the line, highlight it, and Ctrl-C (copy).? Be careful not to save the file standard.dio when you're done.
?
The diode’s parameter string includes “rs=0.0384”, and I want to vary that to adjust the curve to the panel I want to simulate.
The model adds a multiplier to the diode, “N=15”, which I successfully changed to “N={Ns}” so I could vary the number of cells.
I tried adding an override of rs by “N={N} Rs={Rser}”, but the second term throws an “unrecognized” fault.
Right-clicking the diode symbol doesn’t offer any route to setting any terms.
Be careful here.? You are mixing up your parameters.
?
Rs is a .MODEL parameter.? It can be changed only by editing the .MODEL statement.? You can use AKO: or you can replicate the entire .MODEL statement, but it must be done only with the .MODEL statement.? Like all .MODEL parameters, the Rs parameter never comes up in an Attribute of a symbol.? You can't do it that way.
?
N, as you've used it here (as N sets of series-connected diodes) is an element parameter.? It can be changed only in the element line, the one that begins with a "D".? That can be done on an Attribute line of a symbol, because the symbol with its attributes create the D diode element statement.??Do not attempt to modify the N that is a .MODEL parameter because it is not the same thing; and anyway that would not be the right place to change element parameters.
?
Clearly, these two parameters must not be modified the same way as each other.? .MODEL parameters, and element parameters.? Two completely independent things.
?
Andy
?
|
Re: Overriding a library diode's internal parameter(s)
I have to think on that, Andy!
?
Please see the file AD_PV_Sim 250410.zip I just uploaded.
?
Dave
?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]>
On Behalf Of Andy I via groups.io
Sent: Thursday, April 10, 2025 12:10 PM
To: [email protected]
Subject: EXTERNAL: Re: [LTspice] Overriding a library diode's internal parameter(s)
?
Be careful with diode parameter 'N'.
'N' in the .model statement means Emission Coefficient.
'N' in the diode element line is the diode multiplier.
This is a SPICE thing that the UCal/Berkeley guys got wrong.
Now back to your regularly scheduled program.
|
John Woodgate
DerekK
Bell, Dave