|
Of course, the error is more likely with me, but:
?
I’m experimenting with a simple solar cell/array simulator I can reuse with larger models.
It’s working and stable, at a wide range of open circuit voltages and short circuit currnts, and with different Diode models.
(A current source across a string of ‘N’ diodes of known Vfwd)
?
But when I inserted a .step of the Voc parameter, while it seems to simulate correctly, I got a weird .measure result.
?
.param Voc 75
.step param Voc list 32 45 75
.param Vc 0.8921
.param Vc2 0.7451
.param Isc 1.2
?
.param nCells {Voc/Vc}
.param nCells2 {Voc/Vc2}
.meas nC PARAM {nCells}???????????????????????? ; here to annotate in the log file
.meas nC2 PARAM {nCells2}???? ?????????????? ; here to annotate in the log file
?
From the log file:
?
.step voc=32
.step voc=45
.step voc=75
?
Measurement: nc
? step??? 84.0712924560027
???? 1??????? 84.0713
???? 2??????? 84.0713
???? 3??????? 84.0713
?
Measurement: nc2
? step??? 100.657629848343
???? 1??????? 100.658
???? 2??????? 100.658
???? 3??????? 100.658
?
How can nc or nc2 remain the same at all three different values of Voc?
The voltages and currents correvtly follow the stepped Voc, but
just those two .measures are wrong/
?
Dave
?
?
|
I need to refresh my memory about this.? However, ...
?
Remember that all .MEAS commands are evaluated after all simulations are complete.? I think it means that user-defined PARAMeters hold their final values, at the last .STEP in the sequence.? Voltages and currents can be recalled from each .STEP, but parameter values can not.
?
To overcome that, you could use voltages to 'save' each parameter value from every .STEP.
?
Andy
?
|
Thanks for the nudge, Andy!
Yep, the give-away was that the values for Ncells was always for the last Voc step.
?
At one point, I did have voltages for Ncells/2, but thought it looked kludgy, and “fixed it” by .meas PARAM!
?
Dave
?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]>
On Behalf Of Andy I via groups.io
Sent: Wednesday, April 30, 2025 5:38 PM
To: [email protected]
Subject: EXTERNAL: Re: [LTspice] Possible g;itch in stepping parameters
?
I need to refresh my memory about this.? However, ...
Remember that all .MEAS commands are evaluated after all simulations are complete.? I think it means that user-defined PARAMeters hold their final values, at the last .STEP in the sequence.? Voltages and currents can be recalled from each
.STEP, but parameter values can not.
To overcome that, you could use voltages to 'save' each parameter value from every .STEP.
|
The reason this happens is the braces on the? .meas xxx param yyy lines.
That has a special effect of fixing the meas result to the first one. Remove all the braces! You don't ever need them for .param directives, anyway.
-- Regards, Tony
Of course, the error is more likely with me, but:
?
I’m experimenting with a simple solar cell/array simulator I can reuse with larger models.
It’s working and stable, at a wide range of open circuit voltages and short circuit currnts, and with different Diode models.
(A current source across a string of ‘N’ diodes of known Vfwd)
?
But when I inserted a .step of the Voc parameter, while it seems to simulate correctly, I got a weird .measure result.
?
.param Voc 75
.step param Voc list 32 45 75
.param Vc 0.8921
.param Vc2 0.7451
.param Isc 1.2
?
.param nCells {Voc/Vc}
.param nCells2 {Voc/Vc2}
.meas nC PARAM {nCells}???????????????????????? ; here to annotate in the log file
.meas nC2 PARAM {nCells2}???? ?????????????? ; here to annotate in the log file
?
From the log file:
?
.step voc=32
.step voc=45
.step voc=75
?
Measurement: nc
? step??? 84.0712924560027
???? 1??????? 84.0713
???? 2??????? 84.0713
???? 3??????? 84.0713
?
Measurement: nc2
? step??? 100.657629848343
???? 1??????? 100.658
???? 2??????? 100.658
???? 3??????? 100.658
?
How can nc or nc2 remain the same at all three different values of Voc?
The voltages and currents correvtly follow the stepped Voc, but
just those two .measures are wrong/
?
Dave
?
?
|
Remove all the braces, then it will work as you want. You never need
braces anyway with .param directives.
If used with .meas xxx param yyy, you will only get one measured
value, as you observed. Sometimes, this can be what you want, but
not this time.
--
Regards,
Tony
toggle quoted message
Show quoted text
Of course, the error is more likely with me,
but:
I’m experimenting with a simple solar cell/array simulator I can
reuse with larger models.
It’s working and stable, at a wide range of open circuit voltages
and short circuit currnts, and with different Diode models.
(A current source across a string of ‘N’ diodes of known Vfwd)
But when I inserted a .step of the Voc parameter, while it seems
to simulate correctly, I got a weird .measure result.
.param Voc 75
.step param Voc list 32 45 75
.param Vc 0.8921
.param Vc2 0.7451
.param Isc 1.2
.param nCells {Voc/Vc}
.param nCells2 {Voc/Vc2}
.meas nC PARAM {nCells}???????????????????????? ; here to annotate
in the log file
.meas nC2 PARAM {nCells2}???? ?????????????? ; here to annotate in
the log file
From the log file:
.step voc=32
.step voc=45
.step voc=75
Measurement: nc
? step??? 84.0712924560027
???? 1??????? 84.0713
???? 2??????? 84.0713
???? 3??????? 84.0713
Measurement: nc2
? step??? 100.657629848343
???? 1??????? 100.658
???? 2??????? 100.658
???? 3??????? 100.658
How can nc or nc2 remain the same at all three different values of
Voc?
The voltages and currents correvtly follow the stepped Voc, but
just those two .measures are wrong/
|
On 01/05/2025 02:37, Andy I via
groups.io wrote:
Remember that all
.MEAS commands are evaluated after all simulations are complete.?
I think it means that user-defined PARAMeters hold their final
values, at the last .STEP in the sequence.? Voltages and currents
can be recalled from each .STEP, but parameter values can not.
That's not quite true. In order for them to captured and printed in
the logfile, the braces need to be removed. Then it will work.
--
Regards,
Tony
|
On Thu, May 1, 2025 at 06:52 AM, Tony Casey wrote:
That's not quite true. In order for them to captured and printed in the logfile, the braces need to be removed. Then it will work.
Interesting!
?
Andy
?
|
Hi Dave,
?
This works exactly as you expect in latest LTspice.
?
Best Regards,
Mathias
|
"Exactly as you expect ...". That's a tough one to define.? Care to elaborate, which way would be the "expected" one?
?
Andy
|
On 01/05/2025 12:47, Tony Casey via
groups.io wrote:
Remove
all the braces, then it will work as you want. You never need
braces anyway with .param directives.
If used with .meas xxx param yyy, you will only get one measured
value, as you observed. Sometimes, this can be what you want, but
not this time.
.step voc=45
tnom = 27
temp = 27
method = modified trap
.step voc=75
Measurement: nc
? step??? ncells
???? 1??? 35.8704
???? 2??? 50.4428
???? 3??? 84.0713
Measurement: nc2
? step??? ncells2
???? 1??? 42.9473
???? 2??? 60.3946
???? 3??? 100.658
Total elapsed time: 0.119 seconds.
--
Regards,
Tony
|
What I mean is you would expect the parameters to just work.
Latest LTspice produces this .meas result:
?
Measurement: nc
? step ? ?{nCells}
? ? ?1 ? ?35.8704181146
? ? ?2 ? ?50.4427754736
? ? ?3 ? ?84.071292456
Measurement: nc2
? step ? ?{nCells2}
? ? ?1 ? ?42.947255402
? ? ?2 ? ?60.394577909
? ? ?3 ? ?100.657629848
?
Best Regards,
Mathias
?
On Thu, May 1, 2025 at 09:35 PM, Andy I wrote:
"Exactly as you expect ...". That's a tough one to define.? Care to elaborate, which way would be the "expected" one?
?
Andy
|
Is that*with* the incorrectly inserted? curlies?
?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]>
On Behalf Of Mathias Born via groups.io
Sent: Thursday, May 01, 2025 1:10 PM
To: [email protected]
Subject: EXTERNAL: Re: [LTspice] Possible g;itch in stepping parameters
?
What I mean is you would expect the parameters to just work.
Latest LTspice produces this .meas result:
? step ? ?{nCells}
? ? ?1 ? ?35.8704181146
? ? ?2 ? ?50.4427754736
? ? ?3 ? ?84.071292456
Measurement: nc2
? step ? ?{nCells2}
? ? ?1 ? ?42.947255402
? ? ?2 ? ?60.394577909
? ? ?3 ? ?100.657629848
On Thu, May 1, 2025 at 09:35 PM, Andy I wrote:
"Exactly as you expect ...". That's a tough one to define.? Care to elaborate, which way would be the "expected" one?
|
Yes, it is.
However, curly braces are perfectly fine in any expression and putting them in a .meas is therefore not incorrect. At least not anymore.
?
On Thu, May 1, 2025 at 10:44 PM, Bell, Dave wrote:
Is that*with* the incorrectly inserted? curlies?
?
?
|
On Fri, May 2, 2025 at 06:38 AM, Mathias Born wrote:
Yes, it is.
However, curly braces are perfectly fine in any expression and putting them in a .meas is therefore not incorrect. At least not anymore.
Although I am happy to hear that, I would be real careful about making changes like that.? On face value, this seems like it is a great thing.? But things are rarely as simple as they seem.
?
Are you suggesting that expressions like this one:
E_ABMGATE ? ?YINT 0 VALUE {{IF(V(A) > {VTHRESH} ?& ?
+ V(B) > {VTHRESH},{VDD},{VSS})}}
are now admissible in LTspice 24.1.7 and moving forward, and no longer produce warnings or errors?? Until now, that was not "perfectly fine" when written that way and the reason may have been semi-obvious.? Have you forever changed the rules for curly braces?? Have you considered every possible consequence of that change, both good and bad?
?
On the one hand, I would like to see fewer instances (preferably none) where LTspice objects to bad syntax like that one.? On the other hand, every change has consequences.
?
Don't misunderstand me.? I would be delighted to be rid of the above syntax difficulty, at long last - especially as it seemed that LTspice both objected and accepted it.? But I worry about the consequences.
?
Andy
?
?
|
In versions prior to 24.1, parameter substitutions almost worked like C-macros. This elicited creative use cases like dynamic nodes, stepping models etc. It also caused hard to fix bugs, in particular in sub-circuits.
24.1.x works very differently. It's a complete rewrite of the entire netlist processing; the reason will become obvious in the near future. Unfortunately, this meant that said creative use cases no longer worked in the initial version. Since then, adjustements have been made as needed to stay backward compatible.
?
Anyway, as a result it matters not whether you write x, (x),?{x}, or 'x' in an expression. (The latter is hspice syntax.)
?
As to the worry part: We are aware, after seeing how the release of 24.1 did not quite go as intended :-(
?
Best Regards,
Mathias
?
?
On Fri, May 2, 2025 at 02:22 PM, Andy I wrote:
On Fri, May 2, 2025 at 06:38 AM, Mathias Born wrote:
Yes, it is.
However, curly braces are perfectly fine in any expression and putting them in a .meas is therefore not incorrect. At least not anymore.
Although I am happy to hear that, I would be real careful about making changes like that.? On face value, this seems like it is a great thing.? But things are rarely as simple as they seem.
?
Are you suggesting that expressions like this one:
E_ABMGATE ? ?YINT 0 VALUE {{IF(V(A) > {VTHRESH} ?& ?
+ V(B) > {VTHRESH},{VDD},{VSS})}}
are now admissible in LTspice 24.1.7 and moving forward, and no longer produce warnings or errors?? Until now, that was not "perfectly fine" when written that way and the reason may have been semi-obvious.? Have you forever changed the rules for curly braces?? Have you considered every possible consequence of that change, both good and bad?
?
On the one hand, I would like to see fewer instances (preferably none) where LTspice objects to bad syntax like that one.? On the other hand, every change has consequences.
?
Don't misunderstand me.? I would be delighted to be rid of the above syntax difficulty, at long last - especially as it seemed that LTspice both objected and accepted it.? But I worry about the consequences.
?
Andy
?
?
|
On Fri, May 2, 2025 at 01:22 AM, Andy I wrote: E_ABMGATE ? ?YINT 0 VALUE { { IF(V(A) > { VTHRESH } ?& V(B) > { VTHRESH },{ VDD },{ VSS } ) } } The above illustrates why '{{' instead of '{' could matter, e.g. when the source file also defines " .param VTRESH = aa + bb ". In that case it matters (because of precedence rules) whether VTRESH is evaluated before its value is substituted, or if the (debracketed) *text* of VTRESH is substituted in the VALUE above before VALUE is evaluated as an expression. I would hate to debug that type of errors or mistakes. I think it also matters how { (VTRESH) } is handled. -marcel
|
Don't worry, it doesn't matter. An expression like
?
?VTHRESH & V(B)
?
is evaluated as if it had been written as
?
(aa + bb) & V(B)
?
Best Regards,
Mathias
?
On Fri, May 2, 2025 at 05:34 PM, <mhx@...> wrote:
On Fri, May 2, 2025 at 01:22 AM, Andy I wrote:
E_ABMGATE ? ?YINT 0 VALUE { { IF(V(A) > { VTHRESH } ?& V(B) > { VTHRESH },{ VDD },{ VSS } ) } }
The above illustrates why '{{' instead of '{' could matter, e.g. when the source file also defines
" .param VTRESH = aa + bb ". In that case it matters (because of precedence rules) whether
VTRESH is evaluated before its value is substituted, or if the (debracketed) *text* of VTRESH
is substituted in the VALUE above before VALUE is evaluated as an expression. I would hate to
debug that type of errors or mistakes.
I think it also matters how { (VTRESH) } is handled.
-marcel
|
is evaluated as if it had been written as (aa + bb) & V(B) How can your be sure that that was the intention? -marcel
|
On Fri, May 2, 2025 at 02:02 PM, <mhx@...> wrote:
is evaluated as if it had been written as (aa + bb) & V(B)
How can your be sure that that was the intention?
I think it is clear - to me at least - that it is the intention, and the only thing that makes sense.? If you started with
VTHRESH & V(B)
with or without curly braces anywhere in there, it seems clear that you want to get the logical AND of something called VTHRESH and the boolean version of voltage V(B).? ?Whether or not VTHRESH has an expression behind it, that should make no difference.? You can not evaluate the AND operation until you know what VTHRESH is, and that means evaluating its formula and turning it into a numerical value.? It makes no sense whatsoever to apply the AND operation to only a portion of what makes up VTHRESH.
?
Therefore, there is an implicit order of operations like this:
( VTHRESH ) & V(B)
no matter whether you wrote VTHRESH or {VTHRESH} and no matter if there was a formula that defines VTHRESH.? The AND operation can only be applied to VTHRESH, not to ESH while omitting VTHR.? ?:-)
?
Andy
?
?
?
|
On Fri, May 2, 2025 at 11:34 AM, <mhx@...> wrote:
E_ABMGATE ? ?YINT 0 VALUE { { IF(V(A) > { VTHRESH } ?& V(B) > { VTHRESH },{ VDD },{ VSS } ) } }
The above illustrates why '{{' instead of '{' could matter, ...
For the life of me, I can not understand the purpose of "{{", no matter how hard I try.
?
I get it if the formula was something like this: "... { { thing1 } + thing2 } ...".
?
I do not understand when the formula uses: "... { { thing1 } } ...".
?
What that seems to be saying is this:
- Evaluate "{ thing1 }" and replace "{ thing1 }" with its numerical value.? Let's say it evaluates to 4.72.
- Evaluate "{ 4.72 }" and replace it with its numerical value.
Huh?? What is the meaning of { 4.72 }?? Since 4.72 is already a number and is guaranteed to be a number and only a number, there is no purpose of trying to evaluate it a second time as if it were an expression and find its numerical value.? You already have it.? In fact it's kind of an error to try.? (Like pointer redirection applied too many times?)
?
Can someone explain to me the meaning or purpose of "{ { thing1 } }", as it relates to LTspice?
?
Re: text substitution - that is something I much prefer to avoid.? It is too much of a grey area, a "can of worms".? As I understand it, the .text directive did text substitution, but nothing else actually did.? But I might be wrong about it.
?
Andy
?
?
|
Bell, Dave
Tony Casey