Re: CD4000 Library Additions
I have randomly found this topic while searching for CD4026 library for LTS. Would you still be able to share your extended library??
?
Thanks?
|
Re: Passing a Mosfet Value as a parameter to a hierarchical subcircuit
That's not the 24.1.8 help, then. You must have looked at an older version.
?
On Tue, May 6, 2025 at 12:22 AM, John Woodgate wrote:
Well, it's hardly hidden away. It's the third short paragraph in the .PARAM help:
To invoke parameter substitution and expression evaluation, enclose the expression in curly braces. The enclosed expression will be replaced with the floating-point value.
|
Re: OPA square wave generator, single supply OPA is not working
thanks Andy. I am trying to learn LTspice and opa & this group for help at the same time of which may meet alot of new stuff. i ould try files/uploading later on.
|
Re: Passing a Mosfet Value as a parameter to a hierarchical subcircuit
Very possibly. I think that the new feature of
.PARAM, to pass strings, needs to be clearly explained in the
.PARAM Help, as, for example:
?.PARAM can be used in two ways:
1. To pass a numerical value
[Some text]
2. To pass a string
[Some text]
On 2025-05-05 23:38, Andy I via
groups.io wrote:
On Mon, May 5, 2025 at 06:22 PM, John Woodgate wrote:
Well, it's hardly hidden
away. It's the third short paragraph in the .PARAM help:
To invoke parameter substitution
and expression evaluation, enclose the expression in
curly braces. The enclosed expression will be replaced
with the floating-point value.
There is some chance that statement is still correct as it
stands, though maybe confusing.
?
Evaluating a parameter's value from its formula would apply
only to parameters and formulas that can evaluate to numbers.?
If a parameter holds a text string, then I think it does not
need to be evaluated because the string itself IS the value.?
Enclosing such a parameter inside curly braces feels like it is
unnecessary and should not be done.
?
OTOH, if you can build expressions that use non-numerical
parameters (e.g., ModelName+".sub"), then curly braces might be
needed, and then that Help statement should be modified.
?
?
?
--
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: Passing a Mosfet Value as a parameter to a hierarchical subcircuit
On Mon, May 5, 2025 at 06:22 PM, John Woodgate wrote:
Well, it's hardly hidden away. It's the third short paragraph in the .PARAM help:
To invoke parameter substitution and expression evaluation, enclose the expression in curly braces. The enclosed expression will be replaced with the floating-point value.
There is some chance that statement is still correct as it stands, though maybe confusing.
?
Evaluating a parameter's value from its formula would apply only to parameters and formulas that can evaluate to numbers.? If a parameter holds a text string, then I think it does not need to be evaluated because the string itself IS the value.? Enclosing such a parameter inside curly braces feels like it is unnecessary and should not be done.
?
OTOH, if you can build expressions that use non-numerical parameters (e.g., ModelName+".sub"), then curly braces might be needed, and then that Help statement should be modified.
?
?
?
|
Re: Passing a Mosfet Value as a parameter to a hierarchical subcircuit
Well, it's hardly hidden away. It's the third
short paragraph in the .PARAM help:
To invoke parameter substitution and
expression evaluation, enclose the expression in curly braces.
The enclosed expression will be replaced with the
floating-point value.
On 2025-05-05 23:00, Andy I via
groups.io wrote:
On Mon, May 5, 2025 at 05:38 PM, John Woodgate wrote:
Well, I now have 24.1.8,
but the Help still says: The
enclosed expression will be replaced with the
floating-point value.
It would not surprise me if they did not catch every instance in
the Help that needed to be changed.
?
You ought to point out where you saw that in the Help.
?
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: Passing a Mosfet Value as a parameter to a hierarchical subcircuit
On Mon, May 5, 2025 at 05:38 PM, John Woodgate wrote:
Well, I now have 24.1.8, but the Help still says: The enclosed expression will be replaced with the floating-point value.
It would not surprise me if they did not catch every instance in the Help that needed to be changed.
?
You ought to point out where you saw that in the Help.
?
Andy
?
?
|
Re: Passing a Mosfet Value as a parameter to a hierarchical subcircuit
On Mon, May 5, 2025 at 03:30 PM, John Woodgate wrote:
I've never heard of that procedure. Let's see what others say.
It was OK.? But it probably was not clear exactly what was going on, at first glance.? We are so accustomed to seeing only top-level schematics that we forget there are other kinds, in LTspice-land.
?
Per's .ASC schematic file is a lower-level hierarchical schematic.? It is not meant to be run by itself.? It is meant to be "called" by a higher-level schematic.
?
The .ASY symbol file that accompanies it is the symbol that represents that lower-level schematic.? Symbols for lower-level blocks are supposed to have no Attributes, no simulation commands, and maybe no power supplies.? In that regard, everything appears to have been done correctly.
?
?
?
|
Re: Passing a Mosfet Value as a parameter to a hierarchical subcircuit
On Mon, May 5, 2025 at 01:03 PM, Per wrote:
I want to do something like add MOS=IPB107N20N3 in the PARAMS section on the Navigate/Edit Schematic Block but it moans at me about not being able to resolve the parameter.
Then it appears you know how to add .PARAMs to your symbol already.? That wasn't clear, because the uploaded symbol does not have any parameters added to it yet.
?
However, if you are using anything before the latest versions of LTspice, parameter values must be numeric only, so attempting to do a parameter assignment "MOS=IPB107N20N3" will fail, unless IPB107N20N3 is another parameter whose value is numeric.? The rest of this message is for people who are not running the latest version of LTspice.
?
You can still use PARAMs to change or set the model of a transistor, by defining the transistor models with numeric names.? For example:
?
.SUBCKT IPB107N20N3_L0 drain gate source ...
...
.ENDS
...
.SUBCKT AnotherFET drain gate source
...
.ENDS
?
.model 1 AKO: IPB107N20N3_L0
.model 2 AKO: AnotherFET
.model 3 AKO: ...
...
.PARAM MOS=1
?
But don't forget that both NMOS symbols inside your "bimos.asc" schematic must have their Prefix values changed from "MN" to "X", to make them work with that Infineon SPICE model which is a .SUBCKT model.? Also, if you use the Infineon model named just "IPB107N20N3", that model requires a special MOSFET symbol with 5 pins.? I hope you are aware of how those models are supposed to work.
?
Andy
?
?
|
Re: Passing a Mosfet Value as a parameter to a hierarchical subcircuit
Well, I now have 24.1.8, but the Help still
says: The enclosed expression
will be replaced with the floating-point value.
On 2025-05-05 22:24, John Woodgate
wrote:
OK, so it's MY Help that needs to be
updated. I will see.
On 2025-05-05 22:02, Mathias Born via
groups.io wrote:
It's already in there. In great detail.
?
On Mon, May 5, 2025 at 10:36 PM, John Woodgate wrote:
So the Help needs to be
updated, ASAP.
On 2025-05-05 20:37, Mathias
Born via groups.io wrote:
Not quite. LTspice also knows string parameters,
which were introduced extactly for the purpose discussed
here.
?
Best Regards,
Mathias
?
On Mon, May 5, 2025 at 07:16 PM, John Woodgate wrote:
.PARAM can only
be used to pass numbers. From the Help: To invoke parameter
substitution and expression evaluation, enclose
the expression in curly braces. The enclosed
expression will be replaced with the
floating-point value.
--
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
|
Re: Passing a Mosfet Value as a parameter to a hierarchical subcircuit
OK, so it's MY Help that needs to be updated.
I will see.
On 2025-05-05 22:02, Mathias Born via
groups.io wrote:
It's already in there. In great detail.
?
On Mon, May 5, 2025 at 10:36 PM, John Woodgate wrote:
So the Help needs to be
updated, ASAP.
On 2025-05-05 20:37, Mathias Born
via groups.io wrote:
Not quite. LTspice also knows string parameters, which
were introduced extactly for the purpose discussed here.
?
Best Regards,
Mathias
?
On Mon, May 5, 2025 at 07:16 PM, John Woodgate wrote:
.PARAM can only be
used to pass numbers. From the Help: To invoke parameter substitution
and expression evaluation, enclose the expression
in curly braces. The enclosed expression will be
replaced with the floating-point value.
--
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: Passing a Mosfet Value as a parameter to a hierarchical subcircuit
It's already in there. In great detail.
?
On Mon, May 5, 2025 at 10:36 PM, John Woodgate wrote:
So the Help needs to be updated, ASAP.
On 2025-05-05 20:37, Mathias Born via groups.io wrote:
Not quite. LTspice also knows string parameters, which were introduced extactly for the purpose discussed here.
?
Best Regards,
Mathias
?
On Mon, May 5, 2025 at 07:16 PM, John Woodgate wrote:
.PARAM can only be used to pass numbers. From the Help: To invoke parameter substitution and expression evaluation, enclose the expression in curly braces. The enclosed expression will be replaced with the floating-point value.
|
Re: Passing a Mosfet Value as a parameter to a hierarchical subcircuit
So the Help needs to be updated, ASAP.
On 2025-05-05 20:37, Mathias Born via
groups.io wrote:
Not quite. LTspice also knows string parameters, which were
introduced extactly for the purpose discussed here.
?
Best Regards,
Mathias
?
On Mon, May 5, 2025 at 07:16 PM, John Woodgate wrote:
.PARAM can only be used
to pass numbers. From the Help: To invoke parameter substitution and
expression evaluation, enclose the expression in curly
braces. The enclosed expression will be replaced with
the floating-point value.
--
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: Passing a Mosfet Value as a parameter to a hierarchical subcircuit
NOW It does, but not all are running the latest version(s)
?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]>
On Behalf Of Mathias Born via groups.io
Sent: Monday, May 05, 2025 12:38 PM
To: [email protected]
Subject: EXTERNAL: Re: [LTspice] Passing a Mosfet Value as a parameter to a hierarchical subcircuit
?
Not quite. LTspice also knows string parameters, which were introduced extactly for the purpose discussed here.
On Mon, May 5, 2025 at 07:16 PM, John Woodgate wrote:
.PARAM can only be used to pass numbers. From the Help:
To invoke parameter substitution and expression evaluation, enclose the expression in curly braces. The enclosed expression will be replaced with the floating-point value.
|
Re: Passing a Mosfet Value as a parameter to a hierarchical subcircuit
Not quite. LTspice also knows string parameters, which were introduced extactly for the purpose discussed here.
?
Best Regards,
Mathias
?
On Mon, May 5, 2025 at 07:16 PM, John Woodgate wrote:
.PARAM can only be used to pass numbers. From the Help: To invoke parameter substitution and expression evaluation, enclose the expression in curly braces. The enclosed expression will be replaced with the floating-point value.
|
Re: Passing a Mosfet Value as a parameter to a hierarchical subcircuit
I've never heard of that procedure. Let's see
what others say.
On 2025-05-05 20:22, Per wrote:
Thanks for the reply. That's a big not going to happen then.
:-(
?
As an aside the .asc file is 'linked' to the .asy file. It
does not need a simulation directive. You drop the .asy on the
schematic and off you, don't, go. Yes you could have internal
supplies but otherwise you would link them in hopefully with net
labels or pins/ports.
?
Either I am wrong or I think you know that one.
--
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: Passing a Mosfet Value as a parameter to a hierarchical subcircuit
Thanks for the reply. That's a big not going to happen then. :-(
?
As an aside the .asc file is 'linked' to the .asy file. It does not need a simulation directive. You drop the .asy on the schematic and off you, don't, go. Yes you could have internal supplies but otherwise you would link them in hopefully with net labels or pins/ports.
?
Either I am wrong or I think you know that one.
|
Re: Passing a Mosfet Value as a parameter to a hierarchical subcircuit
.PARAM can only be used to pass numbers. From
the Help: To invoke parameter
substitution and expression evaluation, enclose the expression
in curly braces. The enclosed expression will be replaced with
the floating-point value.
Your .ASC is incomplete, anyway. There are
no supply voltages and no simulation directive. Your.ASY has no
attributes. Maybe that is OK, but maybe not.
On 2025-05-05 18:03, Per wrote:
Hi,
?
I want to make my own block for a bidirectional mosfet. I can
set up the .asc file with two mosfets in it and draw the .asy
file.
?
I want to do something like add MOS=IPB107N20N3 in the PARAMS
section on the Navigate/Edit Schematic Block but it moans at me
about not being able to resolve the parameter.
?
.asc and .asy file, hopefully, in the temp directory in a bit
as bimos.zip
?
Thanks for any help.
?
Per
--
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
|
Passing a Mosfet Value as a parameter to a hierarchical subcircuit
Hi,
?
I want to make my own block for a bidirectional mosfet. I can set up the .asc file with two mosfets in it and draw the .asy file.
?
I want to do something like add MOS=IPB107N20N3 in the PARAMS section on the Navigate/Edit Schematic Block but it moans at me about not being able to resolve the parameter.
?
.asc and .asy file, hopefully, in the temp directory in a bit as bimos.zip
?
Thanks for any help.
?
Per
|
Re: OPA square wave generator, single supply OPA is not working
I uploaded "LT1006 oscillator.zip" to the Temp folder.? It has three schematics:
?
- "Original (corrupt!).asc" is the original schematic that wai wai attached to a message.? It is corrupt, probably because it was attached to a message.
- "Fixed the corrupt values.asc" is the same except that I substituted the "mu" or "micro" character (?) for each instance of the corrupt character, hopefully restoring the original values.
- "Just the fixed oscillator.asc" is the same schematic but with the three other op-amps and all their unrelated circuitry removed, and with one change to the oscillator's biasing, which makes it oscillate with either dual or single supplies.
?
Why was the original file corrupt?? (Sorry, long story ahead.)? LTspice uses the Greek letter "mu" (?) to mean micro.? By default, if you have a capacitor, inductor, or resistor with a value in micro-anything - even if you physically type a "u" - LTspice converts it to a mu (?).? (You can disable that if you like, in the Settings / Control Panel.)? That letter is represented by the single byte hex B5 (0xB5).? Some may think of it as if it was part of the ASCII character set, but it is not.? PCs with MS-Windows knew 0xB5 meant "?".
?
All is well if those schematics stay within LTspice, and move to and from your computer's drive and most other drives.? But if you take the actual text code (of an LTspice .ASC schematic file) and open it or copy-and-paste it into a text editor, bad things might happen to it.? Some editors preserve it.? Others do not; they notice it is a non-ASCII character and attempt to convert it into something else, which might be either one or two bytes.? We saw that a lot before 2020 when this group was hosted on Yahoo!Groups, because Yahoo's editor would corrupt those bytes if anyone ever edited an LTspice schematic file that had been previously uploaded.
?
In this particular case, when wai wai copied-and-pasted the contents of their original schematic file into their message for the group, those characters found themselves converted from ? to 湩 and they were now corrupt and not recognized by LTspice.? (That is one of the reasons why you should never ever paste a schematic file into your messages in this group!)? I think LTspice interpreted the "1湩" capacitor as a 1 (Farad) capacitor.? And similarly for the others.? Like all good SPICE programs, unrecognized multipliers are ignored.
?
In the second file inside the .ZIP, I fixed those corrupt values.? I assumed that all six bad values were supposed to be microfarads.
?
Most of the circuitry on that schematic was entirely unrelated to wai wai's question about the oscillator.? So I deleted it.? The third schematic has just the oscillator, with one small change so that it oscillates with either dual or single supplies.
?
Andy
?
?
|
wai wai
John Woodgate
Bell, Dave