Re: How to include component values in LTSpice trace formulas

#108557

... I forgot to clarify that the capacitance value does not change over time - I just want to try different values to figure out what works best. But I don't want to have to remember to put the changed value in the trace formula as well as changing it in the schematic - I'd like to be able to change it only one place on the schematic and then have that value automatically used in the trace formula ...

Re: How to include component values in LTSpice trace formulas

#108556

Oooops - just found a problem with using .PARAM statements to do what I wanted. To briefly summarize my objective, it is to plot a trace of the energy stored in a capacitor over time. I want to use the formula E = 1/2 * C * V**2.?

So here's the problem I ran into: the .PARAM statement works fine on the schematic for all sorts of purposes, but I am unable to access .param values in trace formulas. For example, I can easily define a trace like "v(nodeA)*I(resistorB)*100". But LTSpice does not let me access .params like r(resistor1) as part of the trace formula - or, at least, I can't find anything in the program or documentation that lets me do that.

> If anyone knows a clean, direct way to get param values into the formula for a trace, I'd love to know what it is <

But in the meantime, here's an outline of the hack that I think should work, in case anyone is interested, and in case there isn't a way to get the .param value directly into the trace formula:

1. Enter a directive, .param MyCapValue=<desired_cap_value> on the schematic.

2. Set the value of the capacitor in question to {MyCapValue}

3. If necessary, also use MyCapValue to manipulate other values in the circuit. In my case, I will set MyInductanceValue to <desired_product_of_L*C> / {MyCapValue}, in order to make sure the resonant frequency? of the LC tank circuit stays the same regardless of the chosen capacitance value.

4. Set up a grounded DummyDCVoltageSource separate from the main circuit and set it's output voltage to {MyCapValue}.

5. Stick a label on the dummy source output, say "D".

6. Stick labels on both sides of the capacitor, say C1 and C2

7. Then the trace formula for energy stored in the capacitor would be (v(C1)-v(C2))**2*0.5*v(D)

I haven't actually tried this yet, so I don't know whether LTSpice will give me grief about misusing units (e.g., using Volts to represent Farads), but I figure that can be worked.

Re: Funny problem in simulation with .option gshunt=1.5e-7

#108555

Hello Alan,

I just tried again with gshunt to check that it really has been used inside the subcircuit.

I got +25% more supply current even with only gshunt=1e-11.

?

The more interesting option is gmin which is much less critical. It's applied across all PN-junctions in a simulation.I often try with gmin=1e-10, if a circuit doesn't converge.

Best regards,

Helmut

?

Re: Funny problem in simulation with .option gshunt=1.5e-7

#108554

开云体育

Now you node better.

John Woodgate OOO-Own Opinions Only
J M Woodgate and Associates 
Rayleigh, Essex UK

On 2018-11-18 18:09, alan.revera@... [LTspice] wrote:

Show quoted text

?

I thought this only add to the external circuits, not the inside of the opamp.

Re: Funny problem in simulation with .option gshunt=1.5e-7

#108552

Thanks guys, I thought this only add to the external circuits, not the inside of the opamp. Now I know. I notice the Ti models don't work as well as the LT models, The LT models don't need to play around with all these.

Thanks

Alan

Re: Funny problem in simulation with .option gshunt=1.5e-7

#108553

I thought this only add to the external circuits, not the inside of the opamp.

Re: How to include component values in LTSpice trace formulas

#108551

Thanks so much Andy, and the other folks who responded. That's the approach I'll use. To answer a question in one of the responses about what I'm trying to do, it's to try various values of C, L and other parameters for an LC tank circuit for a Tesla coil to see which values result in the greatest energy being stored.

... and thanks for the other info, like using ** instead of ^ - that would explain the weird results I got when I used ^ :-)

Re: Funny problem in simulation with .option gshunt=1.5e-7

#108550

Ala,

Gshunt should probably be no larger than 1e-10.

Your value (1.5e-7) is a thousand to a million times too large.? Side-effects like the ones you observed should be expected.

Andy

Re: Problems using Pspice fet model for infineon BSR202N.

#108549

Richard,

TRTOL is not very well understood, by most of us.? Almost all SPICE programs set TRTOL to 7, which is a slightly odd number.? Most SPICE users don't change that.? LTspice's default is 1, and there is some commentary about it in the LTspice Help pages, but it's not exactly clear.

I would not necessarily assume that smaller TRTOL improves accuracy.? In principle, with the default settings, SPICE simulations should be pretty accurate anyway, since everything was optimized at those settings.? It's those odd cases that require special tweaking, and then there is no certainty that smaller *TOL always equates to greater accuracy.? What TRTOL affects is LTspice's truncation error estimate, which is not the same thing as the inaccuracy of the simulated waveforms.? (My recollection is that the truncation error is a separate calculation on the side of the regular circuit calculations, which doesn't affect the simulated waveforms, but is used only to decide when to discard the current time point, back up a little, and set the timestep smaller.)

The Help page says that a larger TRTOL value (greater than 1) is "usually a better overall solution" for transistor level circuits (compared to SMPS circuits??), but it doesn't say what "better" means.? Faster?? More accurate?? Less likely to do something unexpected with certain third-party models?? Helmut has recommended never setting TRTOL greater than 1, which differs from Mike Engelhardt's suggestion.

If TRTOL affects how often LTspice needs to back up, then there is probably a "sweet spot" where that happens least often and the simulation proceeds fastest.? If so, then setting TRTOL larger might make it back up more often, causing the simulation to run slower rather than faster.? But I might misunderstand how it works.

Regards,

Andy

Re: LTSpive IV vs XVII voltage generators

#108548

开云体育

Thanks to all who replied to my question about this.

Larry Benko

On 11/17/2018 11:55 PM, analogspiceman@... [LTspice] wrote:

Show quoted text

?

Excellent catch.? Bravo!? This question is closed.

---In LTspice@..., wrote :

I remember I noticed this but also that there was an entry in the
changelog about this and, sure enough, here it is:

04/24/18 Corrected the behavior of SINE voltage and current sources
when Ncycles is specified and revised the help to match.

--

Vlad

Re: Funny problem in simulation with .option gshunt=1.5e-7

#108547

Hello,

Adding 6MegOhm resistors from every node to GND will kill practically every circuit, because there are resistors with kOhm to MegOhms inside the subcircuit.

Best regards,

Helmut

Funny problem in simulation with .option gshunt=1.5e-7

#108546

Hi

I encountered a strange problem, I uploaded the file in Temp. It's a simple circuit using LT6202. If I put in .option gshunt=1.5e-7, you can check current through R2 and R3 is 50mA. But if you delete the .option gshunt=1.5e-7, then current goes down to about 3.5mA as specified on the datasheet of LT6202. This happens on LT1803, but ok with LT1360.

Strange!!! Any explanation on this?

Re: Problems using Pspice fet model for infineon BSR202N.

#108545

Ok. Sorry. I've solved the curiosity. I put in a delay in my gate drive to allow for the delayed "startup" voltage sources. It was my delay causing it to wait 20us before doing anything..

Re: Problems using Pspice fet model for infineon BSR202N.

#108544

Thank you both Bordodynov and Andy.
That was extremely helpful. I'm hoping you can confirm my understanding, that reducing TRTOL slows the simulation but should make it more accurate. It should not make it less accurate. Is that correct? Similarly with the Alternate solver. Right?

One curiosity... I removed the "startup" .trsn modifier, but the simulation still appears to do nothing for 20us. I've closed and restarted LTspice, but still it seems to be using "startup". Do I need to do something more than removing the modifier?

Regards and thanks..
Richard

Re: LTSpive IV vs XVII voltage generators

#108543

Excellent catch.? Bravo!? This question is closed.

---In LTspice@..., <imbvlad@...> wrote :

I remember I noticed this but also that there was an entry in the
changelog about this and, sure enough, here it is:

04/24/18 Corrected the behavior of SINE voltage and current sources
when Ncycles is specified and revised the help to match.

--

Vlad

Re: LTSpive IV vs XVII voltage generators

#108542

I remember I noticed this but also that there was an entry in the
changelog about this and, sure enough, here it is:

04/24/18 Corrected the behavior of SINE voltage and current sources
when Ncycles is specified and revised the help to match.

-- 

Vlad
______________________
ltspicegoodies.ltwiki.org -- holding, among others:
a universal analog/digital filter, block-level models
for power electronics (and not only), math blocks
with a more stream-lined approach, some digital
ADC, DAC, (synchronous-)counter, JKflop, etc.

Re: Edge triggered b-source logic and integrated averaging in LTspice

#108541

Hello analogspiceman,

Thanks for your uploaded example "sampled_average_expanded.asc".

I have now a better understanding after I plotted V(4), V(3) , V(x) and V(s) in one plot.

Best regards,

Helmut

---In LTspice@..., <helmutsennewald@...> wrote :

Hello analogspiceman,

Thanks a lot for ths idea of a "sampled" average.

I have made an example with your formulas. Please check my circuit.

I wonder a little bit were the integration really starts and stops compared to the sample clock pulse.

Files > Temp

sampled_average.zip

Best regards,

Helmut

Re: Frequency calc durung trans sim

#108540

Agreed.? (Although Mike is brilliant he can be very stubborn once his mind is closed.)

---In LTspice@..., <helmutsennewald@...> wrote :

Hello analogspiceman,

I have been aware of this command, but it would be a nightmare to download a few thousands of my schematics, modify it and upload it again. I would also loose the time stamp which is a good indicator for me whether an example may be easier due to new features or more experience. I simply have rated this reset to minimum size as a bad design decision.

Best regards,

Helmut

---In LTspice@..., <analogspiceman@...> wrote :

Hello Helmut,

Mike added a command line switch to automatically resize text when an old file is opened with this switch, but it is a lot of trouble to use and it often only fixes some of the text.

---In LTspice@..., <helmutsennewald@...> wrote :

Hello eT,

Have you tried my older eyamples before?

freq_meter_test1.zip, freq_meter_test2.zip

Don't wonder about the small size of characters in these files. When Mike implemented the variable size of characters, he decided to set the text of all older schematics to a minimum size. This has been a really bad decision. You should manually change the size of all text to the new default for better readability.

Best regards,

Helmut

Re: Frequency calc durung trans sim

#108539

Hello analogspiceman,

I have been aware of this command, but it would be a nightmare to download a few thousands of my schematics, modify it and upload it again. I would also loose the time stamp which is a good indicator for me whether an example may be easier due to new features or more experience. I simply have rated this reset to minimum size as a bad design decision.

Best regards,

Helmut

---In LTspice@..., <analogspiceman@...> wrote :

Hello Helmut,

Mike added a command line switch to automatically resize text when an old file is opened with this switch, but it is a lot of trouble to use and it often only fixes some of the text.

---In LTspice@..., <helmutsennewald@...> wrote :

Hello eT,

Have you tried my older eyamples before?

freq_meter_test1.zip, freq_meter_test2.zip

Don't wonder about the small size of characters in these files. When Mike implemented the variable size of characters, he decided to set the text of all older schematics to a minimum size. This has been a really bad decision. You should manually change the size of all text to the new default for better readability.

Best regards,

Helmut

Re: How to include component values in LTSpice trace formulas

#108538

开云体育

Correction. Replace ^ by **, and the last number should be 10**(-15).? It may be possible to work round the '1F' problem by changing it to '1C/1V', which is '1 coulomb per volt'.

John Woodgate OOO-Own Opinions Only
J M Woodgate and Associates 
Rayleigh, Essex UK

On 2018-11-17 21:38, John Woodgate jmw@... [LTspice] wrote:

Show quoted text

Click on the title of the plot of the voltage (V(n005) for example) across your capacitor and change? the expression? to V(n005)^2*10^(-7)/2, if your capacitor is 100 nF. The y-axis is in terms of volt-squared, because LTspice doesn't know that the '10^(-7)' is a capacitor.? It ought to be plotted in joules if you multiply it by 1F/1J (1 farad/1joule), but it doesn't work because LTspice recognizes '1F' as '1 femto', i.e. 1-^(-15).