Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Problems when simulating a simple analog integrator in Pspice

Status
Not open for further replies.
You know... I was preparing a simulation using his circuit... and I noticed the stage after saturation... I had the idea that what I saw, he will likely see it too. I know he may not be as curious as I and may prefer ignoring this part since his teacher will not ask about it for sure. But... I couldn't ignore it since, on the other hand, I supposed it is related to his actual studies so he may enjoy talking about it too. :roll:

Edited:
I didn't continue... waiting to know his opinion... the boss's opinion :grin:
 
Last edited:
Kerim, for my opinion, your contribution No.17 simply was to long.
May be I am to impatient - but I must confess, I didn't start to read. Sorry.
Nevertheless: Regards
LvW
 

Hi,

... I would be surprised if you did. :wink:

You know, the detailed reply is addressed to the OP so that he can have more chance to discuss any minor step on it in case he looks to master this basic circuit by himself.
In fact, I wish he doubts in every line I wrote and compares it to his knowledge before accepting any detail.
This is how I started learning science. :grin:
 
According to my experience in 99% of all errors the cause of the problems was on the user side

Most of "Timestep too small" or "No Convergence in DC analysis" errors are caused by the engine using non-globally convergent algorithm, not the user. People just got used to them, and learned how to overcome those problems by changing settings, circuit topology etc. But just because you can often use some hackery to solve the problem, it doesn't mean the problem does not exist. There is no such thing like "no convergence" in reality. Lack of convergence guarantee is a failure of simulator, not the user.

But note: This way is neither logical nor gives it correct results because in reality no circuit starts signal processing from exactly zero volts. No transistor amplifier will give reasonable simulation results after disabling the bias point calculation.

Huh? So how come I always disable this option and get very accurate results of the TRAN analysis? Just as in the OP problem - disabling DC causes the results to be correct?

You are obviously wrong. If the circuit was unconnected from the power supply for long enough, and assuming it has no batteries inside or other power sources, it starts exactly from zero when connected to power supply. The operating point is reached long long after that. DC bias point calculation is a hack for getting bias point faster. It only saves you from running TRAN from zero initial condition and waiting (probably for a very long time) until the circuit stabilizes. However, DC bias point calculation can get you totally incorrect results in some circuits, because it ignores dynamic behaviour of the circuit.

Try to calculate DC bias point for a transistor amplifier powered from an AC voltage source, rectified by any diode rectifier (simulated together as a one circuit). You will get incorrect results - the DC analysis will tell you the output voltage from the rectifier is 0, therefore the operating point of the aplifier is also 0, which is obviously much different from what you get when you build the circuit in reality.

BTW: Probably the main misconception about SPICE is that it is a simulation program. It is not (at least not a real-time simulation program like e.g. iCircuit). It is a circuit analysis program. It is extremely useful when you know how each analysis is defined mathematically and what it does. However if you are not careful, you can easily ask it to calculate something that has no physical meaning. E.g. DC point calculation algorithm is non-physical. No real circuit reaches the operating point by "disconnecting capacitors and short-circuiting inductors" and SPICE does exactly that. This is just an analysis, for which some assumptions about circuit have to be made, otherwise you get crap out. The same about AC analysis - it is just response of the linearised circuit - its results are ok as long the circuit obeys some assumptions about linearity, otherwise they are totally wrong.
 
Last edited:

Hi rapidcoder, yes - partly I agree, however, not in total. But I think it is an interesting discussion and perhaps some beginners can learn something from it. Therefore, some comments from my side:

Most of "Timestep too small" or "No Convergence in DC analysis" errors are caused by the engine using non-globally convergent algorithm, not the user. People just got used to them, and learned how to overcome those problems by changing settings, circuit topology etc. But just because you can often use some hackery to solve the problem, it doesn't mean the problem does not exist. There is no such thing like "no convergence" in reality. Lack of convergence guarantee is a failure of simulator, not the user.

May be I should say 98% or 95% (instead of 99%) are user-relevant? I agree, that indeed you have listed some cases (no convergence) where the program itself is the cause of some problems. On the other hand - I am involved in simulation activities since more than 20 years - and I must confess that I have noticed not very often the error message "No convergence". And, more than that, sometimes it was me who was responsible for this error due to some entry failures.

Quote LvW: But note: This way is neither logical nor gives it correct results because in reality no circuit starts signal processing from exactly zero volts. No transistor amplifier will give reasonable simulation results after disabling the bias point calculation.

Quote rapidcoder:Huh? So how come I always disable this option and get very accurate results of the TRAN analysis? Just as in the OP problem - disabling DC causes the results to be correct?
You are obviously wrong. If the circuit was unconnected from the power supply for long enough, and assuming it has no batteries inside or other power sources, it starts exactly from zero when connected to power supply.

Please read carefully my wording: I did not speak about power switch-on but about "signal processing". Obviously, this means: Desired action (amplification, filtering etc). Of course, if you like to watch the transient behaviour due to power switch-on you can cancel the dc bias calculation. But who wants this?

The operating point is reached long long after that. DC bias point calculation is a hack for getting bias point faster. It only saves you from running TRAN from zero initial condition and waiting (probably for a very long time) until the circuit stabilizes. .

I am afraid we speak about different modes of operation. Of course, you can disable dc point calculation and immediately start TRAN analyses - if you want to do this! This means: If you are interested to see how and when the circuit stabilizes.
But if I am interested in signal processing properties only (and this is normally the case) I think the dc bias option is the best and quickest option.

However, DC bias point calculation can get you totally incorrect results in some circuits, because it ignores dynamic behaviour of the circuit

I don't understand this statement. Please, can you give an example? Dynamic behaviour is time dependent, correct?
Do you speak about time dependent unit or parts?

Try to calculate DC bias point for a transistor amplifier powered from an AC voltage source, rectified by any diode rectifier (simulated together as a one circuit). You will get incorrect results - the DC analysis will tell you the output voltage from the rectifier is 0, therefore the operating point of the aplifier is also 0, which is obviously much different from what you get when you build the circuit in reality.

Good point. I think, this is a good example for my claim that the user often is the source of errors.
Of course, I must not command a dc analysis if the main supply is not a dc source. It's clearly a user fault.

BTW: Probably the main misconception about SPICE is that it is a simulation program. It is not (at least not a real-time simulation program like e.g. iCircuit). It is a circuit analysis program. It is extremely useful when you know how each analysis is defined mathematically and what it does. However if you are not careful, you can easily ask it to calculate something that has no physical meaning.

Agreed to 100%.

E.g. DC point calculation algorithm is non-physical. No real circuit reaches the operating point by "disconnecting capacitors and short-circuiting inductors" and SPICE does exactly that.

You are right - it is not physical insofar as it neglects the time. On the other hand - don`t forget that we are doing the same by hand calculation of the dc properties. We neglect C and L. Is this wrong? Not a suitable example, for my opinion.
Generations of engineers have done this before PC's were available. I think the human brain is capable enough to extrapolate how the status will be after all power switch-on transients have disappeared. As an example, in control electronics we very often use the "final value theorem" that does exactly the same. It is a very effective tool.

The same about AC analysis - it is just response of the linearised circuit - its results are ok as long the circuit obeys some assumptions about linearity, otherwise they are totally wrong.

No, the results are not "wrong" - this sounds to me as if the simulator did something wrong.
The user is faulty if he applies the (correct!) simulator results to a circuit that does not comply with the assumptions that were the basis for the simulation results (linearity).

Finally, I think you again have presented another good example for blaming the program although the user has made an error.
________________
Regards
LvW
 
  • Like
Reactions: FvM

    FvM

    Points: 2
    Helpful Answer Positive Rating
Hi KerimF!

Thanks for your detailed analysis of this circuit!! I am really grateful that you did this, and I really learn from you a lot!
Your analysis is right, at least I agree with you all:grin: The whole process happens as what you posted.
It is my fault that I did not state my question clearly. What I meant was that: my transient simulation result showed that the output of the opamp was clipped at the supply rail from the beginning, i.e. from t=0. There is not any integration process at the output. This is what I meant:oops:
I will be more careful when I state a question next time! Your detailed analysis really surprised me! Your carefulness really makes me feel shamed. It is a good lesson for me!
Thanks agains!
 

I will be more careful when I state a question next time! Your detailed analysis really surprised me! Your carefulness really makes me feel shamed. It is a good lesson for me!

I am the one to say sorry... Your first question is indeed very clear.

What I wrote was just an introduction of the reason we need to specify initial conditions to some voltages and currents before starting a transient analysis.

I wish I use the same simulator as yours (mine is LTspice) so that I can give you a real example (simulation) for every case. I usually have a better understanding while noticing differences among possible related ideas than concentrating on a specific one.

But did you get your ramp or not yet?
You know... Many ideas were also given and deal directly with your question (skipping unnecessary introductions as mine :grin: though I hope you enjoyed reading it).

The end goal, I guess, is that you get the answer of your question... in a way or another. :wink:

Kerim
 

I am the one to say sorry... Your first question is indeed very clear.

What I wrote was just an introduction of the reason we need to specify initial conditions to some voltages and currents before starting a transient analysis.

I wish I use the same simulator as yours (mine is LTspice) so that I can give you a real example (simulation) for every case. I usually have a better understanding while noticing differences among possible related ideas than concentrating on a specific one.

But did you get your ramp or not yet?
You know... Many ideas were also given and deal directly with your question (skipping unnecessary introductions as mine :grin: though I hope you enjoyed reading it).

The end goal, I guess, is that you get the answer of your question... in a way or another. :wink:

Kerim

Yes, I got my ramp! I just set the initial condition of the capacitor to zero(which I forgot to do so before) and then get the expected result.
 

Thank you for replying.

For instance, when I was much younger, I used to give private lessons mainly in Math and Physics. After a few years later, all new students started to ask me if I can get them the steps to the results 'only' for their (school or college) problems (by writing them in a book)... claiming they have no more time to think/discuss with a teacher about why each step was chosen to reach the required answer. :roll: Since then. I quitted teaching and have focused on the design instead :-D
 

Hi Kerim,

may I ask you a question related to one of your statements:

What I wrote was just an introduction of the reason we need to specify initial conditions to some voltages and currents before starting a transient analysis.

I am involved since more than 25 years in circuit simulatuions - mostly analog.
I cannot remember one single case with a necessity to specify initial conditions before starting transient analysis to get the expected result (provided I have described the circuit and the kind of analysis correctly!!!) - with one exception: linear oscillator circuits.
(Related to the analog integrator - with "described correctly" I mean, for example: Step function as input rather than a dc source).

Therefore, it would be interesting for me to learn in which cases you think it would be necessary to specify initial conditions. Of course, when I know one cap is already charged at t=0 because of the history, a respective IC is in order. But this is a special case.
I think, it would be interesting also for some other forum members to learn from this discussion and to hear about some specific provisions that are (perhaps?) required for errorless simulation results.
Thank you and regards
LvW
 

Hi LvW,

Thank you for pointing out this.

I didn't have the chance, while designing my circuits at work, to analyze them on any simulator till I was able downloading LTspice, a couple of years ago. So almost all of you here (I mean the old wise guys) are likely much more experienced than I in working with the terms and functions related to various spice programs. Practically, I have just started to be familiar with LTspice though I am glad with this little knowledge I can simulate rather complex circuits, some of them were hard for me to design earlier.

I am sorry that I didn't notice that in English the word 'need' means 'necessary'. I thought it could mean just 'needing if we like'. So I thought that later (which will never come :wink: ) we can get different linear ramp times by just changing the initial voltage of C1. You may not see an importance in using this initial function but in my humble simulations it helps me sometimes. For example, in some circuits, it can help me get the result in a shorter time. If I know that a reference voltage (made by two resistors to get 2.5 V for example) but filtered with a relatively high value capacitor, I won't wait for this capacitor to charge through the resistors. I just let its initial value be 2.5V. So I.C. is another tool/function which is good to know just in case.

As we know, there are two kinds of problems; exercises and real designs.
I remember I solved thousands of problems in Math, Physics and even Electronics which had no real value to reality in them. That is why they were called exercises. But these non-practical problems are indeed the base of all our practical/useful knowledge one may have now to design and build real things.

Post #1 is an exercise... it can't be used as a real circuit but its analysis can be extended to cover even a whole book :grin:

Finally, just to be sure I got your point, would you please show me how to correct my silly statement which stimulated you :smile:

Kerim
 

Finally, just to be sure I got your point, would you please show me how to correct my silly statement which stimulated you

Hi Kerim, thanks for your quick reply. I can assure you - you got the point by 100%.
(I guess, you are "flirting" a bit by recognizing your own statements as "silly"?).

I'm completely satisfied with your explanation:
You may not see an importance in using this initial function but in my humble simulations it helps me sometimes. For example, in some circuits, it can help me get the result in a shorter time. If I know that a reference voltage (made by two resistors to get 2.5 V for example) but filtered with a relatively high value capacitor, I won't wait for this capacitor to charge through the resistors. I just let its initial value be 2.5V. So I.C. is another tool/function which is good to know just in case.

So finally, we are again on the same line (initial conditions are seldom "needed" or "necessary", but helpful in some cases).

Thanks and regards
LvW
 

If I want to see the integrator behaviour, I will put a pulse DC source at input which is going to start after a delay of some usec. Transient simulation will show a ramping output.
 

If I want to see the integrator behaviour, I will put a pulse DC source at input which is going to start after a delay of some usec. Transient simulation will show a ramping output.

Yes, that's the best and most logical approach.
 
Last edited:

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top