1. Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.
    Dismiss Notice

block diagrams, feedback loops, etc.

Discussion in 'Mathematics and Physics' started by PG1995, Jul 9, 2014.

  1. PG1995

    PG1995 Active Member

    Joined:
    Apr 18, 2011
    Messages:
    1,645
    Likes:
    13
    Hi

    I'm creating this thread to proceed with the discussion of this block diagram from this thread. In that thread the block diagram was discussed from post #18 to #20. You can also find some related material to the discussion of block diagram between the posts #4 and #17. Thanks.

    Now I'm able to get some clearer picture of the diagram. Please note that one of main objective is to understand how a real system is transferred into a block diagram and how the diagram is interpreted.

    Note to self: Don't confuse Isc(t) with short circuit current of solar cell.

    In post #20 of the referenced thread in reply to my question, you said, "That line is labeled i_in(t) which is the input current to the buck converter. The capacitor C_in will be charged by the difference in the i_sc(t) and i_in(t) currents". I don't get it. The line I_in(t) runs from buck converter into Cin, notice the arrow head. Perhaps, this is how it should be interpreted. The behavior of block Cin is dictated by two input variables, i.e. Isc(t) and Iin(t). Here, the behavior is referred to the charging of the system which also dictates the output Vin(t). Also note that the amount of Iin(t) is controlled by the variable s(t). I think that I'm still confused but hopefully you can see where I have it wrong and what is really confusing me.

    Note to self: The variable s(t) coming out of PWM block is continuous variable and in reality is a rectangular wave.

    In my view it would have been better if arrows haven't been drawn above solar cell and buck converter blocks because they give the impression as if some variable is being input into the blocks. But perhaps that's the way block diagrams are drawn or I'm just reading too much into it!

    The digital system which you have drawn at the bottom is in fact a way of looking at what is happening inside the microcontroller. I see the disable detect block as a battery charging algorithm. The value of D[n] is basically determined by the disable detect block. For instance, when a battery is in its first stage of charging, i.e. bulk charging, then disable detect won't play any role as far as I can see and how I conceptualize my project. In other words, disable detect block comes higher in hierarchy of determining the value of D[n] than P&O block.

    I'm sorry to say this but I don't see any particular feedback loop in the given block diagram. For example, in both these block diagrams, #1 and #2, you can clearly see the feedback loops along with other important blocks. Could you please help me with this? Thank you.

    Regards
    PG
     

    Attached Files:

    Last edited: Jul 10, 2014
  2. steveB

    steveB Well-Known Member Most Helpful Member

    Joined:
    Jan 16, 2009
    Messages:
    1,297
    Likes:
    629
    Note that you should add analog filtering blocks in front of the A/D converters, assuming that is how you will implement it.

    You will need to mentally distinguish the aspects of the diagram that are based on a "model viewpoint" and those that are based on a "functional viewpoint". Those arrows you are questioning are important from a model viewpoint because when you mathematically model these subsystems, you find that those are truly inputs to your subsystem model. However, functionally, you don't need to do anything with these because they are automatic feedback paths that exist on their own based on the system design. You are free to draw a functional block diagram that does not include the model inputs and outputs.

    The disable detect block is whatever you make it to be. I did not specify anything about it. I just put it there to allow you to modify the basic feedback control. Obviously if the battery is fully charged you dont want to keep charging, and their may be other reasons to modify the D[n] signal before going to the converter. This is the power of digital control. It allows you to make many conditional checks.

    The block diagrams you showed are the classic linear system types of diagrams. Your system is nonlinear and much more complicated by switching effects. You would need to linearize the system model to develop a traditional control loop block diagram. I've done that myself and have the linear model already derived, but this is beyond what you need based on what you have identified as your plan for your project.

    As far as the feedback loop, you should still be able to see it in that diagram. You have D[n] driving s(t) which controls the buck converter, which controls the power flow from the solar cells. you measure the solar cell power and the microprocessor uses that measurement to update D[n] appropriately.
     
  3. PG1995

    PG1995 Active Member

    Joined:
    Apr 18, 2011
    Messages:
    1,645
    Likes:
    13
    Like this? What labels should be used for the outputs of the filters?

    I understand such things are better explained and understood when discussed in proper context and we are, in my view, short of proper context here. Anyway, let's give it a try. How do you differentiate between "model viewpoint" and "functional viewpoint" in the context of given project?

    Let's get back to those arrows. I interpret them solely on the basis of diagram without knowing the exact reason as follows. The arrow coming into solar cell indicates that the cell's behavior is influenced by Vin(t), and the arrow coming into the buck converter indicates that the behavior of buck is dependent upon I_L(t). What do you say? Please let me know.

    Okay. Perhaps, we can have a look at it in future. But what does really make the given system a non-linear system? Theoretically speaking, a linear system is one which obeys the principle of superposition. When we say that the system has been linearized it simply means that the system's behavior is being approximated using a linear equivalent model. At this stage, I'm not really interested in linearizing it as you say it's beyond what I need and possibly it's also beyond what I can understand but I'm interested in knowing what really makes that system non-linear. According to you, one reason is switching effects though I don't know why. If possible, please let me know. Thanks.

    In my humble view, you have described a 'circular' control loop or path and not feedback loop! :) Although as you say this is a non-linear system, I think there should still be a single feedback path from the output to input. I believe that the loop labelled Iin(t) is the main feedback loop. Is it?

    The system is always trying to make the variables Isc(t) and Iin(t) equal. The value of variable Vin(t) depends upon Isc(t)-Iin(t). Assuming that the system is stable, that is Isc(t) and Iin(t) are approximately equal. In such a case. if Isc(t) increases then the variable s(t) increases, or if Isc(t) decreases the variable s(t) decreases. I don't know if I have it correct but you will see how I'm thinking about it, or this just shows that in my mind I'm still trying to make the diagram look more and more like this diagram of a linear system. Thanks.

    Regards
    PG
     

    Attached Files:

  4. dave

    Dave New Member

    Joined:
    Jan 12, 1997
    Messages:
    -
    Likes:
    0


     
  5. steveB

    steveB Well-Known Member Most Helpful Member

    Joined:
    Jan 16, 2009
    Messages:
    1,297
    Likes:
    629

    Yes, that looks good to me.

    Labels are your choice, but those signals should be functions of continuous time (t), not discrete time [n] I often use a "prime" notation for filtered signals.

    So you could call them i_sc'(t) and v_in'(t).

    I think you are correct that context is very important. Also, viewpoint is important. Different people often view systems in different ways, and I don't claim there is any right way to do these things. There can be wrong ways, but there is a large space of grey area, in my opinion. You don't necessarily need to accept all of my ideas and opinions in this area. All I can do is present my viewpoint, and you have to judge whether it is suitable to meet your goals.

    It's not always easy to make the distinction and there are so many different kinds of block diagrams, some more accurate than others, and some more useful than others. The model viewpoint is usually a direct representation of the mathematical model you formulate. Usually, I try to use the state space representation for dynamic systems. When you do so, there are clearly defined inputs, outputs and states in the subsystem model. A model-based block diagram should include all inputs and outputs, as formulated, in my opinion. A functional diagram is generally better to help others understand the basic important variables and interactions that need to be worried about.

    Yes, that seems correct to me. I would add that those signals would make more sense to you if you had the actual mathematical model of the system in question. Keep in mind that there are often different ways to model a system, and the choice you make to model the system might change inputs to outputs and outputs to inputs.

    But, don't get too hung up on all this. Basically, make a model of the system, and then the inputs and outputs are clear after that. Before that, it might look strange.


    There are many examples of things that make a system nonlinear. Multiplication of variables, or transcendental functions operating on variables are clear examples. Switching effects induce nonlinear effects too, usually. Any system that generates harmonics is nonlinear. Really, just about every system is nonlinear, but there can be ranges of operation where the nonlinearity is so mild that a linear model tells you everything you need to know, if you obey the range restrictions.

    So, now we get into terminology issues. To me any circular loop or path is a feedback path. However, you may prefer to label "feedback loops" as special cases of useful feedback intended to control performance. You will find that your system has all kinds of feedback paths, but you are designing a particular feedback control loop also.

    I dont think Iin(t) is the main feedback loop, but you can argue that Iin(t) is the variable you are trying to control with your feedback loop. In effect you can think of Iin(t) as the output, and the duty cycle D is the input. You then implement a digital controller that monitors Iin(t) and controls it. But, it is a little more involved than that because you are really trying to maximize power from the solar cell. So, I view Iin(t) control as an inner feedback loop, and then you have a maximizing controller that sets the value of Iin(t) that will maximize the power. This is one of a few reasons why I mentioned the use of a PI loop as an inner loop and a P&O as an outer loop. This viewpoint makes the operation clearer and easier to design for. However, you are implementing one P&O maximizing controller which tends to obscure the function. But, I'm glad that you see that Iin(t) is a critical variable for control, ultimately. Still, my original explanation that the loop is D[n] driving the system to set the solar cell power is your outer control loop, and since you are not doing an explicit inner loop for Iin(t), this seems like an acceptable viewpoint.

    Well, you have some of this correct. Isc does not equal Iin, because Isc is a filtered version of Iin, but the average values are about equal, if that is what you mean. But, you are really trying to control Isc to be at the maximum power point.

    Dont try too hard to force your system into that block diagram. That diagram is similar to the PI inner control loop I suggested, but you are developing a maximizing controller. A maximizing controller is not a "setpoint" controller, in the strict sense. However, you can think of a maximizing controller as a regulator that sets the slope of the controlled variable (in this case the power) to zero. A "regulator" is a setpoint controller with setpoint equal to zero, by the way. There are many viewpoints you can take here, but if you get too hung up on these matters, you can get confused. Since you are not trying to do linearization and PI control. I would just view this as a power maximizing feedback loop. You monitor power and set the duty cycle to the value that maximizes power. That's a simple viewpoint that matches what you are trying to do.

    Don't take this to mean that your attempts to formulate these viewpoints is in any way misguided. On the contrary, it is the correct thing to do, generally
     
    • Like Like x 1

Share This Page