开云体育

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.