Forums » CircuitLab Support Forum

Run DC Result on these two Circuits:

Expected results:

Extreme weirdness (such as voltages in the 10s-of-K, currents in GAs!!):

The only change? R2 from 2.4K to 2.35K!

Any idea what's going on?

@Signality and @ReverseEMF: Sorry, I have too many questions here:

• I don’t understand the circuit itself, input is at Vcc +/- 0.94V , is LM324 rail to rail?

• It should oscillate heavily because of double inverters, why asking DC Solver?

• WHAT is the DC solver basically supposed to do, at which “time” will be the result computed?

Regards, Sancho

Here's the complete circuit (I was attempting to simulate it in stages):

The goal is to cycle a battery (i.e. charge to full, then discharge to zero) over an over. If you're wondering why it drains the battery to zero, it's for someone else, and that's what they spec'ed ;)

@ReverseEMF, @Sancho_P,

"I don’t understand the circuit itself, input is at Vcc +/- 0.94V , ..."

https://www.circuitlab.com/circuit/d4ssv6/

and

https://www.circuitlab.com/circuit/9k9fz7/

are basically a precision current source sourcing current into a precision current sink with a 5k load at the common point to give the current difference between the source and the sink somewhere to go.

A simplified version - which also doesn't solve properly in CL for different and perfectly valid reasons - that you're already discussing, is here:

RefHi = RefLo = 0.94V across their respective 4.7k resistors.

The opamps set the same voltage across the respective npn and pnp transistor emitter resistors.

Thatsets 200uA through the npn and approx 400uA through the pnp so there should be 200uA flowing into ground through the 5k resistor.

" ...is LM324 rail to rail?"

The CL LM324 model is rail to rail i/o even though the real device isn't. Even so, in the real circuit, the opamp doesn't have to be RIRO so it should work anyway you look at it.

"It should oscillate heavily because of double inverters, why asking DC Solver?"

There's no overall feedback from BatTest to anywhere else so there's no problem with oscillation.

"WHAT is the DC solver basically supposed to do, at which “time” will be the result computed?"

In spice the DC solver finds the DC conditions at time = 0. Basically the quiescent conditions.

In CL it should be doing the same but ... who knows man?

@Signality:

1) OK, I understand now, I thought the inputs should stay off the +/- 1.5V margin as well.

So CL’s model is not rail to tail, hmmm.

2) The DC solver … I still have problems with that. Exactly with the point “zero”.

Anyway, your first suggestion ...

“ramping up supplies”

(generally a great advice, should be the first to learn _ before _ clicking “Simulate”)

... isn’t clear to me in this context (DC Solver).

Did you mean to ramp up only LM324’s supply?

@Sancho_P,

1) You said:

"So CL’s model is not rail to tail, hmmm."

I said:

"The CL LM324 model is rail to rail i/o even though the real device isn't."

2) The links here:

https://www.circuitlab.com/forums/support/topic/58nkjz96/phantom-current/#comment_3380

are worth reading to get some background on what simulators really are and how they work.

There's a good one I keep coming across but I can't remember the link just now. Have a trawl around the spice wiki page?

That aside, yes, the problem with supplies ramped from zero is that the DC solution is always zero.

Ramped supplies don't have to start from zero though. Sometimes starting from a lower, valid supply voltage to a higher - or vice versa - can be enough to get a sim started.

That's why my set of examples includes the option to introduce glitches or steps into supplies. Sometimes that can be as effective as a ramp from zero.

As to which supply; well you just have to experiment but always remember what effect that may have on the results you're looking for and how it may differ from your original expectations.

It also comes back to my feature requests about having the plot start sometime after T=0 so that you don't have to wade through a mass of data as the circuit settles down from the startup transient before you get to the bit you want to see with the supplies stable.

http://en.wikipedia.org/wiki/SPICE

This - from the author of spice - makes very interesting reading:

http://www.cs.sandia.gov/nacdm/talks/Nagal_Larry_NACDM2004.pdf

More:

http://www.designers-guide.org/

1) Yep, my typo, thanks.

2) Seems to be a common basic (spice?) simulator problem.

OK, I’m John Average:

• 1) It should simply work!

• 2) No documentation, please, it should simply work!

(Sorry, this is true = = reality, and I don’t think really bad about it because we have to take what we get)

Perhaps add a parameter to the current source/sink that limits the voltage (i.e. a Maximum voltage setting -- Max positive and Max negative.)

And also, how about adding a current regulator.symbol (i.e. a device that constrains current but has no voltage supply of it's own.)