Re: LTspice 24.1 Simulation Errors
Hi Ben and Mathias,
I greatly appreciate the effort to come to a new and improved version!
?
?
@John Woodgate,
Thanks for your phrasing of the principles. This is exactly what I meant!
?
@Tony Casey,
I noticed you're the owner/author of library 74LVC1G.lib
Should I share the fixes with you in a 1-1 so you can verify what I did, or just upload in the files section as a v1.5 ?
?
?
I sincerely hope this great community can take the step to jointly fix the issues in the legacy and move on
?
Kind regards
Herman
|
Re: Has anyone tried 24.1.3?
Runs well!
?
revision info says:
2/14/25 LTspice 24.1.3
? ? ? ?* Re-enabled expanded netlist functionality
? ? ? ?* Bug fixes
|
Re: LTspice 24.1 Simulation Errors
On Mon, Feb 17, 2025 at 07:30 PM, <mhx@...> wrote:
The helpfile of version 17.1.15 clearly explains what 'negative hysteresis' does (logarithmic behavior as a function
of Vc, tanh-like current limiting). Other simulators (e.g. XSPICE) have this as a settable feature too. I used this
possibility almost exclusively and don't recall any problems with NR.
Negative hysteresis was (and is) supported for a voltage-controlled switch.? Negative hysteresis has never been supported for a Schmitt trigger logic device, and the help documentation never said it was.? In XVII, as Mathias noted, negative hysteresis on a Schmitt would either result in a convergence problem or (at best) behave like zero hysteresis.? This was objectively incorrect, and users deserve a clear error message if they specify negative hysteresis for a Schmitt trigger.
?
This is just one example. We saw many examples of circuits that didn't operate the way people expected, with varying results.
?
We don't want to trigger unnecessary rework for netlists that were working correctly -- we generally operate by the same principles that John Woodgate suggested:
- Code that was correct in earlier versions must be accepted
- Code that was not correct, but tolerated, in earlier versions should not be accepted but should create a clear statement of the error, so that it can be corrected.
One of the greatest things about LTspice is the sheer volume of collateral out in the wild.? Reworking the netlist parser was a necessary step to enable future feature development and to address problems, but it was also a far-reaching change, and while we run many thousands of tests, there were some problems that snuck by.? We've been working feverishly to address each and every issue that has come to our attention.? The vast majority of the known issues are addressed in version 24.1.3 which was just released over the weekend.? This version also restored the expanded netlist functionality.? If more situations that arise that don't fit the principles above, we will address those as well in a future revision.
?
-Ben?
|
Re: LTspice 24.1 Simulation Errors
No it wasn't. Negative hysteresis went unchecked in LTspiceXVII. This was a severe bug because it occasionally
lead to oscillations during Newton iteration. When it did work, it had the effect of zero hysteresis. The helpfile of version 17.1.15 clearly explains what 'negative hysteresis' does (logarithmic behavior as a function of Vc, tanh-like current limiting). Other simulators (e.g. XSPICE) have this as a settable feature too. I used this possibility almost exclusively and don't recall any problems with NR. -marcel
|
I noticed that 24.1.3 addresses bug fixes.
|
Re: Weird results DC operating point for Tube amplifier
Forgot to mention I use the alternate solver.
Le 17/02/2025 à 19:21, Jerry Lee Marcel
via groups.io a écrit?:
toggle quoted message
Show quoted text
For me the simulation is correct.
8.6V at the LM317 input, 5.8V at the output.
Gain of about 15.
I run version x64 24.1.2
Le 17/02/2025 à 18:00, Carlo a
écrit?:
Hello,
I uploaded the project "Bravo_Ocean_ampli" in
Files->Temp. As you can check the .tran analysis returns a
weird DC operating point (aka ITS/Initial Transient Solution).
Namely the current through R4 connected to LM317 Out pin is
negative -165.5mA. Of course physically it can't be the case
(note that it isn't a problem related to how R4 pins are
arranged in the schematic).
?
What could actually be the problem with this circuit
simulation ? Thanks.
|
Re: Weird results DC operating point for Tube amplifier
Following up on that. I added a 6V source just for the heater and terminated the LM317 current source into ground. Low and behold I see a +/150mV sine wave at the output. I don't know if a real 12AU7 would be happy with a plate voltage of 12V (the DC operating point) but the model works with it.
--
David Schultz
"The cheeper the crook, the gaudier the patter." - Sam Spade
|
Re: Weird results DC operating point for Tube amplifier
On 2/17/25 11:54 AM, John Woodgate wrote: There is 26.5 V across the 12.6 V heater, but the current is not too excessive, so, yes, the model is suspect. But there are other issues, some related to the heater perhaps. But it's a weird circuit anyway, including a valve/tube/ a FET and an IC. Is it some sort of demonstration of those mixed-up technologies?
Stepping back and looking at it... The IRF530 appears to be connected as a class A amplifier with the LM317 as a constant current load. Input to the IRF530 is from the tube which also has a current source as its load. From there, things get weird. 24V is very low for a 12AU7. Data sheets show a range of plate voltages from 100V to 300V. The heater drive is extremely weird. Instead of a 12V supply, the IRF530 load current gets connected here. Which would be bad in almost every way I can think of. It will drive the source voltage on the IRF530 way high. Meaning that the output voltage range is very asymetric. The current at least is about what the tube wants. Then there is the voltage at the heater. In excess of the available 24V drive so there is a problem in the model. Gee, I wonder if this is part of the problem: * Heater model
*
* Can be operated from AC or DC power sources.
* NB: When operating from DC power sources, "Skip initial transient
* solution" must be checked, to make use of this model.
* Perhaps one of the heaterless models would be better. I really like that heater warm up time parameter of 10.5 seconds. I bet that works really well with a 10 millisecond simulation time. :-) -- David Schultz "The cheeper the crook, the gaudier the patter." - Sam Spade
|
Re: LTspice 24.1 Simulation Errors
Thanks for the clarification. ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of John Woodgate via groups.io
Sent: Monday, February 17, 2025 2:33 PM
To: [email protected]
Subject: Re: [LTspice] LTspice 24.1 Simulation Errors? Of course not. If one simulation gives Vout = 1.010 and another gives Vout = 1.0988452, the results are different but consistent. On 2025-02-17 19:10, Christopher Paul via groups.io wrote: But if it’s more accurate, isn’t it different? And if it’s different, isn’t it inconsistent? ? ? There is no answer to that question, because it can never happen if both versions of the simulator are working correctly, except, of course, that a later version might give a more accurate result, but not an inconsistent one. On 2025-02-17 18:03, Dave Daniel via groups.io wrote: That's a decent codification, and it makes sense. But I have one question: what happens if the code, which is correct for both versions of the simulator, results in different simulation results on each simulator version? Which set of results should be accepted as "correct" (insofar as simulation can be correct) and how do I choose or even know which one is correct? After all, I used a simulator to show as correctly as possible how the design will behave on the bench (ignoring, for the moment, all the differences between correctly simulated behavior and real-world behavior)?
DaveD On 2/17/2025 12:49 PM, John Woodgate via groups.io wrote: I agree, but I'd like to state the rules more clearly: - Code that was correct in earlier versions must be accepted
- Code that was not correct, but tolerated, in earlier versions should not be accepted but should create a clear statement of the error, so that it can be corrected.
On 2025-02-17 17:37, Dave Daniel via groups.io wrote: Hmmm... despite my earlier comments about maintaining backwards compatibility and thinking about it some more, I can see and agree that erroneous simulation of legacy designs is not good and that, despite the (possibly large) effort that is or would be needed to address those errors in legacy designs that show up in a newer simulator that catches the errors is good.
Thanks for pointing that out.
I think, however, that parsing LTspice syntax in legacy designs correctly should be supported. But that probably has its own complications when improving the simulator.
DaveD On 2/17/2025 12:25 PM, Mathias Born via groups.io wrote:
[snip] ? I think ADI should ensure that correct LTspice syntax from the past should be parsed correctly.
Anything that ran in the past should be parsed and accepted.? The problem is that anything that ran in the past could be counted as "correct syntax".? Unfortunately as it may be, that is how SPICE developed and grew over half a century.? This seems to be an important aspect about which some of the programmers and management at Analog Devices do not yet understand.
I strongly disagree. Anything that constitutes an error and ran nevertheless should not be accepted. That's where 24.1 shines. It might be too restrictive in some areas, but we have been making adjustments were needed.
?
-- OOO - Own Opinions Only John M Woodgate, Rayleigh, Essex UK If something is true: * as far as we know - it's science * for certain, it's mathematics * unquestionably, it's religion.
?
--
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: LTspice 24.1 Simulation Errors
Of course not. If one simulation gives Vout =
1.010 and another gives Vout = 1.0988452, the results are
different but consistent.
On 2025-02-17 19:10, Christopher Paul
via groups.io wrote:
But
if it’s more accurate, isn’t it different? And if it’s
different, isn’t it inconsistent?
?
?
There
is no answer to that question, because it can never happen
if both versions of the simulator are working correctly,
except, of course, that a later version might give a more
accurate result, but not an inconsistent one.
On 2025-02-17 18:03, Dave Daniel via
groups.io wrote:
That's a
decent codification, and it makes sense. But I have one
question: what happens if the code, which is correct for
both versions of the simulator, results in different
simulation results on each simulator version? Which set of
results should be accepted as "correct" (insofar as
simulation can be correct) and how do I choose or even know
which one is correct? After all, I used a simulator to show
as correctly as possible how the design will behave on the
bench (ignoring, for the moment, all the differences between
correctly simulated behavior and real-world behavior)?
DaveD
On 2/17/2025 12:49 PM, John Woodgate
via groups.io wrote:
I
agree, but I'd like to state the rules more clearly:
- Code
that was correct in earlier versions must be accepted
- Code
that was not correct, but tolerated, in earlier
versions should not be accepted but should create a
clear statement of the error, so that it can be
corrected.
On 2025-02-17 17:37, Dave Daniel via
groups.io wrote:
Hmmm...
despite my earlier comments about maintaining backwards
compatibility and thinking about it some more, I can see
and agree that erroneous simulation of legacy designs is
not good and that, despite the (possibly large) effort
that is or would be needed to address those errors in
legacy designs that show up in a newer simulator that
catches the errors is good.
Thanks for pointing that out.
I think, however, that parsing LTspice syntax in legacy
designs correctly should be supported. But that probably
has its own complications when improving the simulator.
DaveD
On 2/17/2025 12:25 PM, Mathias Born
via groups.io wrote:
[snip]
?
I think ADI should ensure
that correct LTspice
syntax from the past should be parsed
correctly.
Anything that ran in the past
should be parsed and accepted.? The problem is
that anything that ran in the past could be
counted as "correct syntax".? Unfortunately as
it may be, that is how SPICE developed and grew
over half a century.? This seems to be an
important aspect about which some of the
programmers and management at Analog Devices do
not yet understand.
I strongly disagree. Anything
that constitutes an error and ran nevertheless
should not be accepted. That's where 24.1 shines.
It might be too restrictive in
some areas, but we have been making adjustments were
needed.
?
-- OOO - Own Opinions Only John M
Woodgate, Rayleigh, Essex UK If something is true: * as
far as we know - it's science * for certain, it's
mathematics * unquestionably, it's religion.
?
--
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: Can Someone Please Determine Why this Model of a 6mA Op-amp Draws 85mA
On Mon, Feb 17, 2025 at 07:08 AM, Andy I wrote: Nisshinbo Micro Devices Inc., which appears to not be the same company, unless
it replaced the New Japan Radio Company (did it?) Yes, it did. "New Japan Radio Co., Ltd. (JRC) and RICOH Electronic Devices Co., Ltd. merge to form Nisshinbo Micro Devices Inc. as of January 1, 2022." NJM4580 is very similar to LM833 from NSC. Both use nearly the same circuit with PNP inputs. NE5532 (Signetics/Philips/NXP) has a different structure with NPN inputs. But all three types show similar technical characteristics in the linear working area. In the NJM4580 v2 model from 2016 JRC specified RP = 3.25E+04. Bernhard
|
Re: LTspice 24.1 Simulation Errors
But if it’s more accurate, isn’t it different? And if it’s different, isn’t it inconsistent? ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of John Woodgate via groups.io
Sent: Monday, February 17, 2025 1:59 PM
To: [email protected]
Subject: Re: [LTspice] LTspice 24.1 Simulation Errors? There is no answer to that question, because it can never happen if both versions of the simulator are working correctly, except, of course, that a later version might give a more accurate result, but not an inconsistent one. On 2025-02-17 18:03, Dave Daniel via groups.io wrote: That's a decent codification, and it makes sense. But I have one question: what happens if the code, which is correct for both versions of the simulator, results in different simulation results on each simulator version? Which set of results should be accepted as "correct" (insofar as simulation can be correct) and how do I choose or even know which one is correct? After all, I used a simulator to show as correctly as possible how the design will behave on the bench (ignoring, for the moment, all the differences between correctly simulated behavior and real-world behavior)?
DaveD On 2/17/2025 12:49 PM, John Woodgate via groups.io wrote: I agree, but I'd like to state the rules more clearly: - Code that was correct in earlier versions must be accepted
- Code that was not correct, but tolerated, in earlier versions should not be accepted but should create a clear statement of the error, so that it can be corrected.
On 2025-02-17 17:37, Dave Daniel via groups.io wrote: Hmmm... despite my earlier comments about maintaining backwards compatibility and thinking about it some more, I can see and agree that erroneous simulation of legacy designs is not good and that, despite the (possibly large) effort that is or would be needed to address those errors in legacy designs that show up in a newer simulator that catches the errors is good.
Thanks for pointing that out.
I think, however, that parsing LTspice syntax in legacy designs correctly should be supported. But that probably has its own complications when improving the simulator.
DaveD On 2/17/2025 12:25 PM, Mathias Born via groups.io wrote:
[snip] ? I think ADI should ensure that correct LTspice syntax from the past should be parsed correctly.
Anything that ran in the past should be parsed and accepted.? The problem is that anything that ran in the past could be counted as "correct syntax".? Unfortunately as it may be, that is how SPICE developed and grew over half a century.? This seems to be an important aspect about which some of the programmers and management at Analog Devices do not yet understand.
I strongly disagree. Anything that constitutes an error and ran nevertheless should not be accepted. That's where 24.1 shines. It might be too restrictive in some areas, but we have been making adjustments were needed.
?
-- OOO - Own Opinions Only John M Woodgate, Rayleigh, Essex UK If something is true: * as far as we know - it's science * for certain, it's mathematics * unquestionably, it's religion.
?
|
Re: LTspice 24.1 Simulation Errors
There is no answer to that question, because
it can never happen if both versions of the simulator are
working correctly, except, of course, that a later version might
give a more accurate result, but not an inconsistent one.
On 2025-02-17 18:03, Dave Daniel via
groups.io wrote:
toggle quoted message
Show quoted text
That's a decent codification, and it makes sense. But I have one
question: what happens if the code, which is correct for both
versions of the simulator, results in different simulation results
on each simulator version? Which set of results should be accepted
as "correct" (insofar as simulation can be correct) and how do I
choose or even know which one is correct? After all, I used a
simulator to show as correctly as possible how the design will
behave on the bench (ignoring, for the moment, all the differences
between correctly simulated behavior and real-world behavior)?
DaveD
On 2/17/2025 12:49 PM, John Woodgate
via groups.io wrote:
I agree, but I'd like to state the rules
more clearly:
- Code that was correct in earlier
versions must be accepted
- Code that was not correct, but
tolerated, in earlier versions should not be accepted but
should create a clear statement of the error, so that it
can be corrected.
On 2025-02-17 17:37, Dave Daniel
via groups.io wrote:
Hmmm... despite my earlier comments about maintaining
backwards compatibility and thinking about it some more, I can
see and agree that erroneous simulation of legacy designs is
not good and that, despite the (possibly large) effort that is
or would be needed to address those errors in legacy designs
that show up in a newer simulator that catches the errors is
good.
Thanks for pointing that out.
I think, however, that parsing LTspice syntax in legacy
designs correctly should be supported. But that probably has
its own complications when improving the simulator.
DaveD
On 2/17/2025 12:25 PM, Mathias
Born via groups.io wrote:
[snip]
I think ADI should ensure that correct
LTspice syntax from the past should be
parsed correctly.
Anything that ran in the past should be parsed and
accepted.? The problem is that anything that ran in
the past could be counted as "correct syntax".?
Unfortunately as it may be, that is how SPICE
developed and grew over half a century.? This seems to
be an important aspect about which some of the
programmers and management at Analog Devices do not
yet understand.
?
?
I strongly disagree. Anything that constitutes an error
and ran nevertheless should not be accepted. That's where
24.1 shines.
It might be too restrictive in some areas, but we have
been making adjustments were needed.
?
Best Regards,
Mathias
-- OOO - Own Opinions Only John M
Woodgate, Rayleigh, Essex UK If something is true: * as far as
we know - it's science * for certain, it's mathematics *
unquestionably, it's religion.
|
Re: Weird results DC operating point for Tube amplifier
For me the simulation is correct.
8.6V at the LM317 input, 5.8V at the output.
Gain of about 15.
I run version x64 24.1.2
Le 17/02/2025 à 18:00, Carlo a écrit?:
toggle quoted message
Show quoted text
Hello,
I uploaded the project "Bravo_Ocean_ampli" in Files->Temp.
As you can check the .tran analysis returns a weird DC operating
point (aka ITS/Initial Transient Solution). Namely the current
through R4 connected to LM317 Out pin is negative -165.5mA. Of
course physically it can't be the case (note that it isn't a
problem related to how R4 pins are arranged in the schematic).
?
What could actually be the problem with this circuit
simulation ? Thanks.
|
Re: LTspice 24.1 Simulation Errors
That's a decent codification, and it makes sense. But I have one
question: what happens if the code, which is correct for both
versions of the simulator, results in different simulation results
on each simulator version? Which set of results should be accepted
as "correct" (insofar as simulation can be correct) and how do I
choose or even know which one is correct? After all, I used a
simulator to show as correctly as possible how the design will
behave on the bench (ignoring, for the moment, all the differences
between correctly simulated behavior and real-world behavior)?
DaveD
On 2/17/2025 12:49 PM, John Woodgate
via groups.io wrote:
toggle quoted message
Show quoted text
I agree, but I'd like to state the rules
more clearly:
- Code that was correct in earlier versions
must be accepted
- Code that was not correct, but tolerated,
in earlier versions should not be accepted but should create
a clear statement of the error, so that it can be corrected.
On 2025-02-17 17:37, Dave Daniel via
groups.io wrote:
Hmmm... despite my earlier comments about maintaining backwards
compatibility and thinking about it some more, I can see and
agree that erroneous simulation of legacy designs is not good
and that, despite the (possibly large) effort that is or would
be needed to address those errors in legacy designs that show up
in a newer simulator that catches the errors is good.
Thanks for pointing that out.
I think, however, that parsing LTspice syntax in legacy designs
correctly should be supported. But that probably has its own
complications when improving the simulator.
DaveD
On 2/17/2025 12:25 PM, Mathias Born
via groups.io wrote:
[snip]
I think ADI should ensure that correct LTspice
syntax from the past should be parsed correctly.
Anything that ran in the past should be parsed and
accepted.? The problem is that anything that ran in the
past could be counted as "correct syntax".?
Unfortunately as it may be, that is how SPICE developed
and grew over half a century.? This seems to be an
important aspect about which some of the programmers and
management at Analog Devices do not yet understand.
?
?
I strongly disagree. Anything that constitutes an error and
ran nevertheless should not be accepted. That's where 24.1
shines.
It might be too restrictive in some areas, but we have
been making adjustments were needed.
?
Best Regards,
Mathias
-- OOO - Own Opinions Only John M
Woodgate, Rayleigh, Essex UK If something is true: * as far as
we know - it's science * for certain, it's mathematics *
unquestionably, it's religion.
|
Re: Weird results DC operating point for Tube amplifier
There is 26.5 V across the 12.6 V heater, but
the current is not too excessive, so, yes, the model is suspect.
But there are other issues, some related to the heater perhaps.
But it's a weird circuit anyway, including a valve/tube/ a FET
and an IC. Is it some sort of demonstration of those mixed-up
technologies?
On 2025-02-17 17:16, Andy I via
groups.io wrote:
Have you yet run simpler simulations, with just the 12AU7, to
verify that its model is good?
?
From where I stand, having done only a cursory check, it
might not be a good model.? It seems to be generating energy in
its heater that comes out of the heater pin.? How is it doing
that?
?
Andy
?
-- OOO - Own Opinions Only
John M Woodgate, Rayleigh, Essex UK
If something is true:
* as far as we know - it's science
* for certain, it's mathematics
* unquestionably, it's religion.
|
Re: LTspice 24.1 Simulation Errors
I agree, but I'd like to state the rules more
clearly:
- Code that was correct in earlier versions
must be accepted
- Code that was not correct, but tolerated,
in earlier versions should not be accepted but should create a
clear statement of the error, so that it can be corrected.
On 2025-02-17 17:37, Dave Daniel via
groups.io wrote:
Hmmm... despite my earlier comments about maintaining backwards
compatibility and thinking about it some more, I can see and agree
that erroneous simulation of legacy designs is not good and that,
despite the (possibly large) effort that is or would be needed to
address those errors in legacy designs that show up in a newer
simulator that catches the errors is good.
Thanks for pointing that out.
I think, however, that parsing LTspice syntax in legacy designs
correctly should be supported. But that probably has its own
complications when improving the simulator.
DaveD
On 2/17/2025 12:25 PM, Mathias Born
via groups.io wrote:
[snip]
I think ADI should ensure that correct LTspice
syntax from the past should be parsed correctly.
Anything that ran in the past should be parsed and
accepted.? The problem is that anything that ran in the
past could be counted as "correct syntax".? Unfortunately
as it may be, that is how SPICE developed and grew over
half a century.? This seems to be an important aspect
about which some of the programmers and management at
Analog Devices do not yet understand.
?
?
I strongly disagree. Anything that constitutes an error and
ran nevertheless should not be accepted. That's where 24.1
shines.
It might be too restrictive in some areas, but we have been
making adjustments were needed.
?
Best Regards,
Mathias
-- OOO - Own Opinions Only
John M Woodgate, Rayleigh, Essex UK
If something is true:
* as far as we know - it's science
* for certain, it's mathematics
* unquestionably, it's religion.
|
Re: LTspice 24.1 Simulation Errors
Hmmm... despite my earlier comments about maintaining backwards
compatibility and thinking about it some more, I can see and agree
that erroneous simulation of legacy designs is not good and that,
despite the (possibly large) effort that is or would be needed to
address those errors in legacy designs that show up in a newer
simulator that catches the errors is good.
Thanks for pointing that out.
I think, however, that parsing LTspice syntax in legacy designs
correctly should be supported. But that probably has its own
complications when improving the simulator.
DaveD
On 2/17/2025 12:25 PM, Mathias Born via
groups.io wrote:
[snip]
I think ADI should ensure that correct LTspice
syntax from the past should be parsed correctly.
Anything that ran in the past should be parsed and
accepted.? The problem is that anything that ran in the past
could be counted as "correct syntax".? Unfortunately as it
may be, that is how SPICE developed and grew over half a
century.? This seems to be an important aspect about which
some of the programmers and management at Analog Devices do
not yet understand.
?
?
I strongly disagree. Anything that constitutes an error and ran
nevertheless should not be accepted. That's where 24.1 shines.
It might be too restrictive in some areas, but we have been
making adjustments were needed.
?
Best Regards,
Mathias
|
Re: LTspice 24.1 Simulation Errors
On Mon, Feb 17, 2025 at 05:28 PM, Andy I wrote:
On Mon, Feb 17, 2025 at 03:22 AM, @HermanVos wrote:
As an example: a negative hysteresis in a Schmitt trigger which is not possible.
I have to disagree (somewhat) with what you're saying.
?
Negative hysteresis might be "not possible" in real hardware where hysteresis is designed-in.? But it was always allowable in LTspice elements where the hysteresis parameter Vh or Ih was available.? It might have been inadequately documented.? In the documentation for the controlled switches (S- and W-elements), the Help describes how a negative value for Vh or Ih makes the device transition smoothly between states:
If Vh is positive, the switch shows hysteresis .... If Vh is negative, the switch will smoothly transition between the on and off impedances.
I believe the "Schmitt" gates are made the same way, even in spite of its name which suggests positive hysteresis.? Nothing prevents you from using a negative number, and getting the same smooth transition as the controlled switches.? As they say, that's a feature, not a bug.
?
No it wasn't. Negative hysteresis went unchecked in LTspiceXVII. This was a severe bug because it occasionally lead to oscillations during Newton iteration. When it did work, it had the effect of zero hysteresis. A Schmitt trigger is a logic device, negative hysteresis make no sense there. Thus, we changed it so that 17.1 automatically corrected a negative value into a positive. However, that drastically changed the behavior of some circuits. In the end, we decided to not permit this any longer to prevent this error from sneaking in ever again.
?
These are good questions.? I can't answer them without examining the models more closely.? But if it's true that there was no parameter named "VCC", then all versions of LTspice should have / would have complained bitterly about that and refused to run.? LTspice would not ever have substituted a different parameter, whether or not it had a similar name.
?
This is simply not true. Prior versions run any circuit that uses undefined parameters inside sub-circuits. You'll get a warning in the log afterwards.
I think ADI should ensure that correct LTspice syntax from the past should be parsed correctly.
Anything that ran in the past should be parsed and accepted.? The problem is that anything that ran in the past could be counted as "correct syntax".? Unfortunately as it may be, that is how SPICE developed and grew over half a century.? This seems to be an important aspect about which some of the programmers and management at Analog Devices do not yet understand.
?
?
I strongly disagree. Anything that constitutes an error and ran nevertheless should not be accepted. That's where 24.1 shines.
It might be too restrictive in some areas, but we have been making adjustments were needed.
?
Best Regards,
Mathias
|
Re: Weird results DC operating point for Tube amplifier
Have you yet run simpler simulations, with just the 12AU7, to verify that its model is good?
?
From where I stand, having done only a cursory check, it might not be a good model.? It seems to be generating energy in its heater that comes out of the heater pin.? How is it doing that?
?
Andy
?
|
Jay Philippbar
John Woodgate