|
|
Yes.
You can use it in a text file with an .inc directive.
OR
You can place it on the schematic as .model statement, then use v49DL45 in the Diode symbol "value" attribute.
However, remove "t_measured=27" from the .model? statement. It is not needed or recognized in LTspice.
|
Hello, I found a PSpice model at Vishay.
?
****
Copyright 2020 Vishay Intertechnology, Inc.
All rights reserved.
****
*produced by Vishay General Semiconductor Taiwan
*Allen Su, 2017/10/24
* PSPICE
.MODEL v40dl45 D IS=6E-005 RS=0.003654 N=1.234
+ CJO=9929p M=1.662 VJ=14.52 TT=246p eg=0.67 xti=6.3 BV=49.5 IBV=222.79 t_measured=27
Can I use this as text (.inc) in the schematic, or does a component have to be created?
Thanks very much
?
|
Re: Scaling a lithium ion battery schematic
Ahh, yes; thanks very much.
T
|
Re: Scaling a lithium ion battery schematic
On 04/07/2023 14:47, Tim Hutcheson via groups.io wrote:
Tony, since limit(x,y,z) is? equivalent to min(max(x,y),z)
shouldn't your original limit expression
B3 vsoc1 0 I=limit(0,1,V(vsoc1))*I(V1)
have been written as
B3 vsoc1 0 I=limit(V(vsoc1),0,1)*I(V1)
although it doesn't seem to matter in this case.
I think you have me confused with eetech00. My B-source expression didn't have a limit() function, which changes the discharge characteristic from linear to logarithmic. In any event, the order of the arguments in the limit() function doesn't matter - the answer is always the middle value, unless two of them evaluate to the same value, in which case that's the answer. This very thing was discussed recently. Don't forget, all three arguments could be variables. The B-source expression can further be simplified and improved to: I=if(V(vsoc1)>0,I(R10),0)..because V(SOC1) cannot be greater than 1, so long as the analysis time doesn't exceed the length of the PWL, in which case everything goes pear-shaped, anyway.
--
Regards,
Tony
|
Re: Scaling a lithium ion battery schematic
Tony, since limit(x,y,z) is? equivalent to min(max(x,y),z) shouldn't your original limit expression
B3 vsoc1 0 I=limit(0,1,V(vsoc1))*I(V1)
have been written as
B3 vsoc1 0 I=limit(V(vsoc1),0,1)*I(V1)
although it doesn't seem to matter in this case.
|
Re: Scaling a lithium ion battery schematic
This certainly appears to be a bug to me. Thanks for reporting it
to us, at least.
Donald
On 2023-07-04 06:57, Tony Casey wrote:
toggle quoted message
Show quoted text
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?
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 -0.9848A. 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
and 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.
--
Regards,
Tony
|
Re: Scaling a lithium ion battery schematic
On 03/07/2023 22:56, apotorski@... wrote:
Thank you for
pointing this out. This taught me a lot!
In case you haven't read any of the later messages, you should note
that the discharge times the simulations produce are very optimistic
because the PWL isn't working as expected. This is to do with the
duplicated timesteps in the PWL, which are not interpreted as you
might expect. I'm guessing that this might have arisen in a
translation from Excel, because Excel accepts duplicated X values
(timesteps) and plots instantaneous transitions. In reality, this is
not possible, and LTspice deals with it in a different and quite
unexpected way.
--
Regards,
Tony
|
Re: Scaling a lithium ion battery schematic
On 04/07/2023 12:57, Tony Casey wrote:
Similarly,
between 0s and 0.21s, you should see -0.9848A.
I meant: ..between 0s and 0.21s, you should see -1A.
--
Regards,
Tony
|
Re: Scaling a lithium ion battery schematic
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?
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.
--
Regards,
Tony
|
Re: Multiple instances of "C:U2:spark"
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.
|
Re: Scaling a lithium ion battery schematic
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?
|
Re: Scaling a lithium ion battery schematic
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
|
Re: Scaling a lithium ion battery schematic
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
|
Re: Scaling a lithium ion battery schematic
Thank you for pointing this out. This taught me a lot!
|
Re: Multiple instances of "C:U2:spark"
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
|
Re: Multiple instances of "C:U2:spark"
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.
|
Re: Scaling a lithium ion battery schematic
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
|
Re: Multiple instances of "C:U2:spark"
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
|
Re: Limitation of line length for B-source equations?
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
|
Tim Hutcheson
Tony Casey