I tested the limit function in the battery discharge and it doesn't seem to reproduce the discharge curve correctly, so I uploaded my test.

Tim

Thank you for pointing this out. This taught me a lot!

eetech00,

That is pretty much all correct -- but I want to clarify what you wrote at the end.? I want to make sure that it is not taken out of context.

The first line of a SPICE netlist file is ignored ONLY when you use that netlist file as your top-level SPICE netlist to be simulated.? If it is instead used as a subcircuit (or any other .include or .lib file) so that it is called by another netlist or schematic, then that first line in that netlist will NOT be ignored.? Even though it may have a green color, it is not ignored -- unless you try to "execute" ("Run") that subcircuit file as if it were a full SPICE netlist.? Subcircuit files are not meant to be "run" that way, but LTspice won't stop you from trying.

It is only the first line of the main SPICE netlist that is ignored, not other netlists.? Technically, SPICE uses it as a Title card (Title line), where that line is not treated as a SPICE element or command, but instead SPICE or LTspice uses it to 'name' the simulation.? That line gets printed in the output files.? In the old days, it would be printed at the top of every page of your output data.? LTspice wisely fills that first line with the full filespec of the schematic that you're running.

Andy

On Mon, Jul 3, 2023 at 11:05 AM, Andy I wrote:

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

So....in the context of LTspice:

1. A schematic is a graphical representation of a circuit regardless if its hierarchical or not. The file extension is .asc
2. A netlist is a text-based, spice representation of a circuit. The file extension can be anything.
3. A subcircuit (.subckt) is also a text-based, spice representation of a circuit. The file extension can be anything.
??? However, a subcircuit must be called from another circuit in order to execute.

Each of #1 and #2 above can be loaded and run in LTspice.
But #3 above must be called from either #1 or #2.

Now...regarding a comment on the first line.....the first line is "enforced" as a comment only in the spice netlist circuit representation.
So, a green first line IS meaningful, but only in a spice netlist circuit, as it is a comment and WILL be ignored.

Some suggestions:

C4 N001 batt1 1000p Rpar=0.1?? <-Rpar replaces resistor
C5 N002 N001 10u Rpar=0.1????? <-Rpar replaces resistor
C6 vsoc1 0 6480 Rpar=10k???????? <-Rpar replaces resistor
B3 vsoc1 0 I=limit(0,1,V(vsoc1))*I(V1)??????????? <-simplified, convergence friendly
I1 N002 N003 PWL file=Test_PWL_2mod.txt <--remove unused lines in file (containing tabs only)
E1 batt1 0 vsoc1 0 table=(trimmed out values for this explanation)
V1 N003 0 0????????????????????????????????? <-current meter replaces resistor
.tran 35000
* Voc
.ic V(vsoc1)=1
.backanno
.end

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