Controls Block Diagrams

Who??

Quite a few of them. Which do you want to use?

In general you show a summing junction with a circle. This circle is often decorated with one thing or another (older texts cross the circle diagonally, dividing it into four parts -- which is confusing, because in a control block diagram that means addition, while in a RF block diagram it means mixing).

At any rate, you decorate the signals coming into the circle with their sign in the summation, by putting a little '+' or '-' by the signal (or, if you quarter the circle, by putting a '+' or '-' in the appropriate circle quarter).

Here's an article on the subject:

Note that the block diagram method that I present is somewhat different from what is commonly seen -- but it makes things explicit that have been used in ad-hoc ways elsewhere, and is (in my opinion, of course), superior to what's normally used.

Many thanks for the helpful info from a lurker.

That is a serious amount of work you put into that webpage. About all that is missing is instructions on Mason's rule.

It isn't as pretty, but signal flow graphs work fine instead of block diagrams. I find they are easier to do with Inkscape. You draw a vector and plop down a label. Gain is a number, integrator is 1/s, etc. And the form is more of a standard for design, but it is not acceptable to the style police for publication. [Publication is where accurate technical diagrams become pretty but full of errors.]

It may not surprise you to know that there isn't uniformity across platforms in the process control business. The couple of systems that I've worked a lot with have the + signal to the summer as the target, and the - as the measured value. The control block (PID or whatever) has a selector that can be for 'direct' or 'reverse' action. For a stable system with the output looped back to the measurements, the setting has to be reverse. Control gain is always positive.

HTH

I like your use of the Sigma for summation, Pi for product, etc. You didn't answer my question directly, but your examples have given me a hint.

Most (all?) of your feedback summing junctions use a minus (-) input for the feedback signal. See your Figure 12 on the above page. That would make your H(z) transfer function 'positive'. That's the way I've seen most controls people do things.

I just got into an argument with someone who wanted to change an existing specification, defined as described above, to show a negative feedback function gain (H(z)) to a positive summing junction input. I said 1) that's the way its usually done and 2) why revise an existing document?

Its a reactive load feedback signal for generator voltage regulation, if anyone needs to know.

Signal flow graphs are superior for linear, time-invariant systems, but real-world systems often boil down to things that are easier to express in a block.

And I left out Mason's rule on purpose -- the page is for beginners, and I didn't want to scare them off. Besides -- by the time I get to the level of complexity where I'm thinking of applying Mason's rule, I've long since put the linearized system description into a state-space representation, and solved that. I've been out of school for over 20 years now, and I think I've used Mason's rule for pay twice in all that time.

If you have a physical feedback signal that's negative polarity then that representation makes sense -- you do like to be able to equate measurable nodes with signals on the diagram. If that's what's motivating the guy, well, it's probably going to enhance the overall clarity of the system design, and it might even be something that I'd do.

If that's _not_ what reflects reality, then I'm on your side.

(Obvious examples of the negative polarity feedback are cases where you're just plain reading a quantity with a negating amplifier. Less obvious ones are times where, for instance, you're measuring the period of a motor rotation and controlling it's drive -- in that case your linearized model needs to have a sign change either in the motor (because you're controlling period, and positive drive increments leads to negative period increments) or in the feedback (because you're controlling speed, and positive speed increments lead to negative period increments).

I had a class from Sam Mason, taught from Mason & Zimmerman, "Electronic Circuits, Signals, and Systems".

And a class taught by Jim Melcher, with textbook, Zimmerman & Mason, "Electronic Circuit Theory".

Both very nice guys, and both died young, Mason from a cerebral hemorrhage and Melcher from colon cancer :-(

But I never knew of anything called Mason's rule... just flow-graph circuit analysis... which I never much cared for as an analysis tool. ...Jim Thompson

BlockDiagrams.html

Mason's rule gives a fixed algorithm for computing a transfer function from a flow graph or block diagram, given that you know the transfer functions of each of the legs or blocks.

It's one of those things that's superbly handy in an academic setting, but doesn't seem to have much application in real life.

(At least not for me -- by the time I get a control system block diagram that's complicated enough for Mason's rule it's covering enough of the system that it has significant nonlinearities, and linear analysis has been tossed out the window.)

Yup, Lots of academics non-realities. I had several graduate-level courses in non-linear control theory... all that Lyapunov fun stuff ;-) ...Jim Thompson

OK, the power station fraternity. They tend to be locked into their own paradigm, which hails from many years ago. Easier to just go with what they want?

I've used signal flow graphs for filter design. I don't run into the need for Mason's rule often, but it is good to know.