Alternate description

[From Bruce Abbott (980929.2200 EST)]

Rick Marken (980929.1820) --

Bruce Abbott (980929.1800 EST)

I can see now that your "conventional diagram" of a control system
can be viewed as the PCT diagram turned on its side with some
new names for the PCT variables. I've copied your diagram with a
double line added to indicate where I think you assume the separation
between system and environment is:

                              ORGANISM || ENVIRONMENT
                                         >>
                                         >> disturbance
                                         >> >
                         error || action V
input---->[comparator]-------->[actuator]|------->[CEV]---+---->
                ^ || |output
                > >>===========|| |
                +------------------------------[sensor]|---+
                             feedback ||
                                                      >>

This diagram is indeed equivalent to the PCT diagram with some
word changes: "input" is "reference" in PCT; "output" is "irrelevant
side effects" in PCT; "feedback" is "perception" in PCT; "actuator"
is "output function" in PCT; "sensor" is "input function" in PCT.

"Actuator" and "sensor" are just my terms for the hardware that determines
the action and feedback functions; I could have used function names instead
(e.g., feedback function). "Output" is "input" in PCT, not "irrelevant side
effects" as you claim; to make this clearer I have moved the label slightly
in the diagram. The rest is correct. PCT's "irrelevant side effects" would
involve a line coming off the action variable; they are side effects of
action, not input (to use the PCT terms).

The rest of your post reminds me of the scene in Monty Python's "Search for
the Holy Grail" where the villagers are trying to figure out, logically, how
to prove that someone is a witch. As I recall, the chain of reasoning
involved the fact that a duck floats on water.

Regards,

Bruce

[From Rick Marken (980929.2130)]

Bruce Abbott (980929.2200 EST)

The rest of your post reminds me of the scene in Monty Python's
"Search for the Holy Grail" where the villagers are trying to
figure out, logically, how to prove that someone is a witch.
As I recall, the chain of reasoning involved the fact that a
duck floats on water.

Why? What was wrong with it? If Ramachandran and Blakeslee
can use thje word "output" to refer to a controlled input
variable doesn't that suggest that others have been using
the term "output" this way?

Best

Rick

···

--
Richard S. Marken Phone or Fax: 310 474-0313
Life Learning Associates e-mail: rmarken@earthlink.net
http://home.earthlink.net/~rmarken/

[From Bruce Abbott (980930.1715 EST)]

Bill Powers (980930.0851 MDT) --

I'm not going to be drawn into an argument over which set of labels is best.
I didn't invent either way of labeling the control system diagram, and I can
see circumstances under which one or the other of them makes good sense. My
point in showing how they differ was and is to point out that different
people use different labels and one must be careful to understand how those
terms are used by a given individual if one is to avoid confusion. Here is
the PCT diagram arrangement, relabeled to reflect engineering usage:

      PCT ARRANGEMENT with CONVENTIONAL LABELS
                                  input
                                    >
                    feedback v error
          [f=g(o)]------------>[comparator]---------->[a=f(e)]
             ^ |
             > >
             +--------------------[CEV]<-----------------+
                    output ^ action
                                    >
                                    >
                               disturbance

This is the same diagram as the conventional one, with the components
rearranged. If it's wrong, then so is the PCT diagram: they are the same
except for the labels. In this diagram, the control system controls its
output, so long as the feedback signal accurately represents the state of
the output.

Two points:

1. The system works the same no matter how you label it.

2. This way of labeling the system emphasizes the relationship, enforced
    by the system, between the "input" (time-varying reference) and "output"
    (time-varying changes in the output which follow the reference in spite
    of disturbances acting on the output variable). For example, the
    position of the joystick of a jet (back or forward) is the input, and
    the angle of the elevators on the jet's tail is the controlled output.
    The system automatically varies the force applied to the elevators as
    necessary to overcome disturbances to their angle, so that the actual
    angle agrees with that called for by the joystick, within the limits
    of error of the system.

Regards,

Bruce

[From Bill Powers (981001.0538 MDT)]

Bruce Abbott (980930.1715 EST)--

I'm not going to be drawn into an argument over which set of labels is best.

That is not what the argument is at this point. The argument is over the
nature of what each element of the diagram is supposed to represent in the
real system.

... one must be careful to understand how those
terms are used by a given individual if one is to avoid confusion.

I don't think that the so-called standard engineering diagram achieves that
goal. There is no single canon that is adhered to by all engineers, nor are
engineers often careful to be sure their diagrams are accurate reflections
of their equations. I have never seen a formal discussion of diagramming
conventions in any text on control theory.

Here is
the PCT diagram arrangement, relabeled to reflect engineering usage:

               PCT ARRANGEMENT with CONVENTIONAL LABELS
                                  input
                                    >
                    feedback v error
          [f=g(o)]------------>[comparator]---------->[a=f(e)]
             ^ |
             > >
             +--------------------[CEV]<-----------------+
                    output ^ action
                                    >
                                    >
                               disturbance

This is the same diagram as the conventional one, with the components
rearranged.

This is a very poor diagram, because there is no convention for which
labels represent physical variables and which represent relationships among
variables -- i.e., functions. It's a mnemonic, not a meaningful diagram. In
the environment, for example, you have a variable, "CEV", in a box, and
another variable right next to it, "output", labelling a line. So what is
the meaning of a box, and what is the meaning of a directed line? I can't
see that you're following any convention at all. Can you explain what this
diagram means?

The label [f=g(o)] is incorrect. g(o) is a function representing the entire
path from action to input, which includes the properties of the _lines_ you
have labeled output and action. What does a line mean, and what does a box
mean, in your diagrams?

Here is how I would rearrange it:

                 PCT ARRANGEMENT with CONVENTIONAL LABELS
                                  input
                                    >
                feedback v error
          [Fi]------------>[comparator]---------->[Fo]---+
             ^ actuator |
             > v
       CEV or "output"<-----------------------------qo or action
                       environmental feedback function ^

                                                         >
                                                         >
                                                     disturbance

Note that engineering practice is to introduce the disturbance at the same
place where the output of the actuator first affects the environment, at
what we call qo. It doesn't matter whether it's brought in there or at the
location called "CEV or output" -- one just adjusts the magnitude of the
disturbance as appropriate. In the case of tachometer feedback in a system
for controlling the RPM of a shaft, disturbances (loads) would act directly
on the output RPM, the CEV. In the case of a system for controlling
illumination for photography, the disturbance could be an extra source of
light adding to the output of the illumination system. It can easily happen
that disturbances act in several places in the diagram -- both at qo and at
CEV.

The arrow from "qo or action" to "CEV or output", as drawn above, has a
label which is often omitted from the engineering diagram. And I have just
looked up some diagrams in old textbooks and find that authors frequently
show the feedback arrow starting at the arrow going to the output, with a
meaning that is totally ambiguous until you read the equations (where it
usually turns out to mean a physical variable like a force or a voltage).
Engineers have been no more careful about their diagramming conventions, it
seems, than have psychologists. Their diagrams often fail to match their
equations.

If it's wrong, then so is the PCT diagram: they are the same
except for the labels. In this diagram, the control system controls its
output, so long as the feedback signal accurately represents the state of
the output.

You have that backward. The output or CEV is DEFINED by the form of the
input function, Fi. What is controlled is whatever is sensed. The feedback
signal is made to match the reference signal; that's the basic mode of
action of a feedback control system. The state of the environment that
corresponds to the feedback signal is then whatever is required to produce
a feedback signal matching the reference signal. If the input function is a
multiplier of 10, then the CEV is 1/10 of the reference signal. If the
input function is a square function, the CEV is the square root of the
reference signal (when the error is zero). If the perceptual signal is the
natural log of the CEV, then the CEV is e^(reference signal).

In the diagram you offer, "output" is attached to the line connecting the
CEV to the input function. Suppose the CEV is a light intensity, and the
action is the amount of current flowing into a light bulb. The input
function is then a photocell. What physical variable (or other entity) does
"output" represent here? Where is the inverse-square law connecting the
light bulb's brightness to the intensity of light falling on the photocell?

If the controlled environmental variable is the RPM of a shaft, the CEV
would be that RPM, with a tachometer converting the RPM into an electrical
signal that is the perception of RPM. To what does the "output" arrow
correspond in that case?

Two points:

1. The system works the same no matter how you label it.

This is true. However, when you measure the variables, they may not behave
the way the labels might lead you to expect. If you labeled the output
quantity the "controlled variable," for example, you would find that it is
not controlled: every environmental disturbance causes it to change. It is
not a controlled variable just because you attach that label to it.

2. This way of labeling the system emphasizes the relationship, enforced
   by the system, between the "input" (time-varying reference) and "output"
   (time-varying changes in the output which follow the reference in spite
   of disturbances acting on the output variable). For example, the
   position of the joystick of a jet (back or forward) is the input, and
   the angle of the elevators on the jet's tail is the controlled output.
   The system automatically varies the force applied to the elevators as
   necessary to overcome disturbances to their angle, so that the actual
   angle agrees with that called for by the joystick, within the limits
   of error of the system.

I think this is, indeed, why engineers have often drawn the diagram as you
present it. It's one of the most confusing aspects of PCT for people who
have learned control theory this way. The first thing the
engineer-psychologist does is look for the input to the living control
system that is causing the output. And what does he find? Sensory inputs!
So, he says, sensory inputs must be the reference signals that are causing
control systems in the body to make outputs match them. The early
engineering psychologists actually put the reference signal and the
perceptual signal in the environment, as well as the comparator, so what
the "human operator" percieved was the error signal! That's probably why we
get questions about how the environment can set reference signals inside
the person. The engineer is used to a control system with a knob or a lever
sticking out of it that lets someone change the control system's reference
level at will. But there are no such knobs or levers in living control
systems; the sensory inputs are in the feedback path; they aren't reference
signals. Reference signals come from higher systems inside the organism.

Bruce, all a "conventional diagram" is is the way people used to draw
things, usually without thinking much about why they drew them that way. If
you ask a control engineer about the details of his diagram -- what it
means, for example, to have one arrow branching off the side of another
line -- he'll probably have no answer ready for you. Crack any control
system text and you'll find very few system diagrams -- engineers are
taught to work with equations, not block diagrams. If the block diagrams
don't really make sense, or have no agreed-on meanings, who cares? The
equations tell the story. Or so they think. This may explain why so many
"control engineers" seem to have such a poor intuitive grasp of control
processes.

My background in diagramming came not from servo analysis or operations
research but from analog computing and circuit design, where diagrams had
to correspond exactly to the physical setup -- in fact, the diagrams were
the "source code" for the actual setup. You couldn't get by with a vague
wave of the arms, or switch randomly back and forth between symbols for
functions and symbols for variables. I have to say this: you could not turn
your diagram into a working system: it simply leaves out too much. I
wouldn't know what kind of physical thing to put between the box you label
CEV and the one you label f=g(o) -- that line you label "output." And I
would have to say the same thing about the diagrams from control
engineering that you're talking about.

Best,

Bill P.