I think that the colors (and to some degree the file formatting) that LTspice uses in its Netlist Editor do not distinguish between a full (top-level) SPICE Netlist, and something you're creating to use only as a Subcircuit.? To the LTspice Netlist Editor, a netlist is a netlist, no matter how it is intended to be used or run.??Hence, you might see the same colors and stuff happening in a Subcircuit netlist -- when edited in LTspice's Netlist editor -- that do not need to be done that way when it is a subcircuit file.

LTspice's Netlist Editor even lets you "run" a subcircuit netlist simulation, which of course makes no sense to do.? But you can, and you would get errors because it wasn't a top-level netlist.? LTspice assumes you know what you're doing, and you pay the price when you don't

Even when drawing hierarchical schematics, LTspice doesn't make you specify "This is my top-level schematic" or "This is a lower-level schematic".? It doesn't care.? A schematic is a schematic.? It's all a matter of how you end up using it.? I guess that once it knows a schematic will be a lower-level in the hierarchy, then it can add the .SUBCKT and .ENDS lines to the netlist it creates.

Andy

ADI responded here: .
I don't think the answer works, but it triggered a nice solution with .TEXT (.text supports "+" continuation and can be put in a .INC file).

-marcel

开云体育

开云体育

On 03/07/2023 18:32, Tony Casey wrote:

I uploaded the amended 24V Li-Ion schematic to Files > Temp.

Uploaded an amended schematic with a crude fix to clamp SOC between 0 and 1.

开云体育

On 03/07/2023 18:31, Bell, Dave wrote:

One suggestion I would make, aside from any corrections others may have:

?

Your 38,000 second long PWL file can be reduced to the first 13 lines.

?

The rest of the file is 18999 repeats of the same waveform.

Then, in the model (,asc), replace this:

PWL file=Test_PWL_2mod.txt

With this:

PWL repeat forever (file=Test_PWL_2mod.csv) endrepeat

?

That will make the waveform last exactly as long as the .tran directive requires.

Great suggestion!

开云体育

开云体育

On 03/07/2023 17:55, Tony Casey wrote:

Yes, the 24V battery doesn't discharge because the 24V characteristics table is messed up. The X values (SOC) should go from 0 to 1. It actually goes from 1.98 to 99.85. The Y values (voltage) should go from 0 to ~24+. Instead, they go from 28 to 18.

Summarising, it looks like the X values are 100X too big, i.e. are in % and not decimal, and the Y values go in the wrong direction. So the table for your 24V battery is actually a SOD (state of discharge) instead of SOC (state of charge).

I fixed the 24V battery SOC table and amended the analysis duration to stop just after SOC reaches zero. The schematic has logical fault in it, so SOC is allowed to go outside the range 0 to 1, which is meaningless and creates havoc interpreting the results. I didn't fix that.

I uploaded the amended 24V Li-Ion schematic to Files > Temp.

开云体育

开云体育

On 03/07/2023 16:56, apotorski@... wrote:

I have been given the task of scaling down a 50V lithium ion battery to 24V. I think I have successfully uploaded both schematics and the PWL file in a zip file. The 50V schematic seems to work fine, the battery discharges to 0V after a certain amount of time. I was able to upload the 24V battery specs in the form of a table to a new voltage dependent voltage source, but I did not change any other component values and I did not change the PWL file. I run the simulation and the battery voltage never gets to 0V. I might not understand the function of the PWL file at the independent current source. My end goal is to get the 24V simulation working correctly by seeing the battery discharge to 0V and also understanding the purpose/function of the PWL file at the independent current source. I am not an electrical engineer, but want to try my best to understand my task. Anyone's help is much appreciated.

Yes, the 24V battery doesn't discharge because the 24V characteristics table is messed up. The X values (SOC) should go from 0 to 1. It actually goes from 1.98 to 99.85. The Y values (voltage) should go from 0 to ~24+. Instead, they go from 28 to 18.

Summarising, it looks like the X values are 100X too big, i.e. are in % and not decimal, and the Y values go in the wrong direction. So the table for your 24V battery is actually a SOD (state of discharge) instead of SOC (state of charge).

I have been given the task of scaling down a 50V lithium ion battery to 24V. I think I have successfully uploaded both schematics and the PWL file in a zip file. The 50V schematic seems to work fine, the battery discharges to 0V after a certain amount of time. I was able to upload the 24V battery specs in the form of a table to a new voltage dependent voltage source, but I did not change any other component values and I did not change the PWL file. I run the simulation and the battery voltage never gets to 0V. I might not understand the function of the PWL file at the independent current source. My end goal is to get the 24V simulation working correctly by seeing the battery discharge to 0V and also understanding the purpose/function of the PWL file at the independent current source. I am not an electrical engineer, but want to try my best to understand my task. Anyone's help is much appreciated.?

I uploaded a new file labeled Paschens-spark_gap. It's a work in progress. And thank you for your help Tony.

开云体育

On 03/07/2023 15:50, Tony Casey wrote:

it always places a comment on the first line (the sub-schematic line)

I mean: it always places a comment on the first line (the sub-schematic name)

开云体育

On 03/07/2023 15:25, Andy I wrote:

That advice only applies to the top-level netlist, not to subcircuits.? Subcircuits usually begin with the ".subckt" command.? Comments are recommended (to document your work), but otherwise they are unnecessary for subcircuits.? The first line of a top-level netlist is ignored (treated like a comment, even if it doesn't start with a "*" character).? The first line of a subcircuit is not ignored.

It's interesting that LTspice text editor still tries to nudge you to have a line above the .subckt definition. The syntax highlighting colour is always green (comment) for the first line, even if that contains the .subckt definition. I suppose syntax highlighting routine doesn't distinguish whether it is a global netlist or a local one. Placing a carriage return on a blank first line is enough to turn the .subckt line to blue.

I noticed that if you use LTspice to create a netlist from a hierarchical schematic, it always places a comment on the first line (the sub-schematic line) followed by a blank line and then the .subckt definition on the third line. Whereas creating a top level netlist omits the blank line, but still places the original schematic file name as a comment on the first line.

Tony wrote, "It is also normal to begin a .subckt definition with a comment, starting with "*". Originally, SPICE assumed the first line was always a comment, but I'm not sure how strictly that is enforced, now. LTspice is quite forgiving of certain things."

That advice only applies to the top-level netlist, not to subcircuits.? Subcircuits usually begin with the ".subckt" command.? Comments are recommended (to document your work), but otherwise they are unnecessary for subcircuits.? The first line of a top-level netlist is ignored (treated like a comment, even if it doesn't start with a "*" character).? The first line of a subcircuit is not ignored.

Andy

Richard,

For some reason, you don't seem to like following advice.? Where is your schematic (.asc) file where this error happened?? Where is the symbol (.asy) file?? I really don't care that someone else could create another (different) new symbol from your subcircuit; where is YOUR symbol file?? Yes, it makes a difference.

Looking at the second subcircuit file that you have uploaded --

I do not know if this has any bearing on the new (singular matrix) error message that you got, but the syntax you used is probably not right.? It's better, but still wrong.? LTspice expects to have a number for its component values, not an expression.? You used a resistor "value" of "1e12 / Vspark", which is not a number.? Perhaps in your mind it should evaluate to a number, but that expression is an expression, not a number.? It must be a number.? I'm guessing that LTspice probably used the "1e12" as the resistor's value and ignored what comes after it, but that is only a guess.

If you wanted that expression to turn into a number, you need to enclose it within curly braces, like this:

? ??Rspark p n {1e12 / Vspark}

Curly braces turn an expression into a number.? Try doing that.? Do the same thing with your capacitor's value:

? ??Cspark p n {8.85e-12 * aa / d}

As I say, it might or might not work, but try it.? Only you have the schematic and the symbol, because you did not bother to include them when you uploaded your model.

What is "aa"?? Is that a parameter that gets passed to this subcircuit?? Same with "d".

The voltage source in your subcircuit still is incorrect.? You have a voltage source named "Vspark" and it's connected between nodes "=" and "(B", and it has a confusing value.? I'm surprised that LTspice accepted it and didn't abort on that.

In the resistor's expression, it refers to the value Vspark.? But Vspark is not defined as a paramater.? Is that supposed to represent a fixed parameter?? Or the voltage on some (yet unknown) node in your subcircuit?? Or the current through the voltage source coincidentally named "Vspark"?? What you wrote does not make sense.

FYI, the subcircuit you uploaded does not have a node "b", so the error message you quoted us could only have come from the schematic file WHICH YOU DID NOT BOTHER TO UPLOAD.? Please.? When we ask you to upload your schematic and symbol files, please follow that advice, and do it.

By the way, I know a pretty good reference to help you with "model cards" and other SPICE syntax.? It's called "Help" and it comes with LTspice.? Run LTspice, then go to its built-in Help.? In fact, much of LTspice's Help about individual component lines and models, happens to be written from the point of view of Netlist syntax, which is exactly where you need when creating a subcircuit.? Admittedly it is somewhat sparse in places, but it is there and it is more useful that you probably think it is.

Andy

开云体育

On 03/07/2023 14:30, Richard Andrews via groups.io wrote:

I uploaded a new file. Now I get that ltspice thinks B is a node. Hello Tony Casey, I'll try your first option later. Thank you.

This is what you uploaded:

.subckt sparkgap p n

* Parameters
* d: Gap distance in meters
* aa: Gap area in sqr meters
* p: Gas pressure in Pascals

* Model constants
?.param A = 5.19e-11
?.param B = 23.8
?.param C = 11.6

* Spark gap voltage
Vspark = (B * p * d) / log(A * p * d) - log(log(1+(1/1.2)))-C

* Capacitance of gap
* Spark gap resistance
Cspark p n 8.85e-12 * aa / d
Rspark p n 1e12 / Vspark

.ends

Yes, I looked at all the spark gap models and none were satisfactory to my needs.

I uploaded a new file. Now I get that ltspice thinks B is a node. Hello Tony Casey, I'll try your first option later. Thank you.

开云体育

On 03/07/2023 13:21, Richard Andrews via groups.io wrote:

I had a reference to help me with model cards, but I seem to have misplaced it.

What I would suggest is that you initially develop your spark gap model as a schematic, without worrying too much about SPICE netlist syntax. You can then extract the netlist and use that as a basis for your .subckt when you have got it working. You're making life much more difficult than it needs to be.

BTW, did you look at all the previous spark gap models in the group's Files section? If not, go to Files and type "spark gap" in the search box. You should get 40 hits, including some complete libraries and some development schematics that help the understanding of how they work.

I had a reference to help me with model cards, but I seem to have misplaced it.