On 04/07/2023 00:00, Tony Casey wrote:

It may or may not be more convergence friendly, but your mod for B3 has changed the discharge to be an incremental function of SOC, which it wasn't before. The given discharge defined by I1 is presumably important, but that's not been preserved.

?

--

Regards,

Tony?

On 3 Jul 2023 20:50, "eetech00 via groups.io" <eetech00@...> wrote:

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

More...

The limit() function in the B-source produces an exponential decay of SOC1, instead of a linear one, but it never reaches zero before flipping. Extending the analysis time, we see that the problem is that the last time coordinate in the Test_PWL_2mod.txt file is 38000.01s, at which the value is -1. Therefore this means that beyond time=42300.365s, when SOC1 reaches 1, the battery is then charged at 1A forever, i.e. the voltage rises up to the maximum value specified in the SOC characteristic table of E1, 27.91842V, at which it remains forever.

This problem was in the original schematic that was uploaded, which had an analysis time of 70000s. In my modified file, I shortened this to 35000, which was sufficient to complete the discharge, but which hid this issue.

There's another, much more subtle issue. If you look in the (original) PWL text file, you see this sequence repeated:

0.01??? -1
0.21??? -1
0.21??? 0.984848485
0.31??? 0.984848485
0.31??? 2.954545455
0.41??? 2.954545455
0.41??? 0.984848485
0.51??? 0.984848485
0.51??? 0
0.81??? 0
0.81??? 0.492424242
1.21??? 0.492424242
1.21??? 0

If you zoom into I(I1) in the waveform viewer (or set the total analysis time to 10s or so), you would expect to see that between 0.51s and 0.81s the current is zero. But that is not what you see. Similarly, between 0s and 0.21s, you should see -1A. Again, you don't see that. Similarly, between 0.81s and 1.21s it should be constant at 0.4924A, but it's not. And, in fact, nowhere does the current actually reach 2.9545A. The highest value it gets to according to the trace marker is 1.9696A. As it happens, 1.9696A is exactly midway between 0.9848A and 2.9545A. Similarly, between 0.51s and 0.81s, instead of zero, you get 0.2462A, which is exactly half of 0.4922A.

So, the actual I(I1) waveform is nothing like the PWL table. For this battery simulation, the discharge time is completely wrong and way optimistic. If you average what the current the PWL should give you for the first 1.21s, the answer is 0.73611V. What you actually get is 0.42703A.

What LTspice is clearly doing is that when it encounters duplicated timesteps, it averages the corresponding amplitudes. No mention in the ErrorLog. WTF! So, what should it do? I'd say, it should flag an error because you can't have two different values at the same time. I might have expected it would discard any repeated timestep, but it doesn't do that either.

Just out of curiosity, I typed just the above values into the the PWL(t) dialogue box. Same result. No warning or error message. At least that was consistent.

Someone please tell me if this is a known feature, because I've not encountered it before. But then, I would never have typed in duplicated timesteps before.

If anyone agrees this is bug, I will submit a report.

I believe I fixed the subcircuit. On the model now you just have to paste on the spice line "p=101325 d=3e-3 aa=100e-6".

Subcircuit and symbol are labeled paschens-spark_gap, thank you.

Use a current meter in circuit 2 to measure the current like I suggested (keeping apples to apples).

Then, try sims with no load. What happens to the output?

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.