Block Diagramming

To my knowledge there is no formal definition of block diagramming 
"languages" outside of such proprietary applications such as Simulink 
and it's ilk, or such things as ladder diagrams (which I'm going to 
claim isn't the same thing).  One sees minor variations of block 
diagramming style within a discipline like control systems engineering, 
and there can be severe divergences between disciplines (the common x in 
a circle that denotes a summation block in control, for instance, 
usually denotes a multiplier or other frequency mixing function in a radio).

This makes sense, because block diagrams seem to work best if one has a 
bit of flexibility with the way one shows things.  It would be difficult 
to design one "language" that would work as well for radio as it does 
for control loops.

None the less, do any of you know of any attempt (or success) to develop 
a standard, formal system of block diagramming outside of the 
proprietary ones mentioned?  I'm writing a document that claims this 
ain't so; I'd like to have some hope of being correct.

Thanks in advance.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Tim,

You first have to tell us what type of block diagram you are talking about.
The term is used for a vast variety of situation.  But ladder diagrams is
DEFINITELY not one of them.  I do block diagrams to define the functionality
of the process units of a complete refinery.  I use them to the
interconnectivity of a control network.  I use them to build organization
charts.  The only thing all these have in common is that they connect
rectangles with lines.

Any standards concerning block diagrams must necessarily reflect the
requirements of a given technology in a given industry.

Walter.

"Tim Wescott" <tim@wescottnospamdesign.com> wrote in message
news:108r5ghmbpj7759@corp.supernews.com...
> To my knowledge there is no formal definition of block diagramming
> "languages" outside of such proprietary applications such as Simulink
> and it's ilk, or such things as ladder diagrams (which I'm going to
> claim isn't the same thing).  One sees minor variations of block
> diagramming style within a discipline like control systems engineering,
> and there can be severe divergences between disciplines (the common x in
> a circle that denotes a summation block in control, for instance,
> usually denotes a multiplier or other frequency mixing function in a
radio).
>
> This makes sense, because block diagrams seem to work best if one has a
> bit of flexibility with the way one shows things.  It would be difficult
> to design one "language" that would work as well for radio as it does
> for control loops.
>
> None the less, do any of you know of any attempt (or success) to develop
> a standard, formal system of block diagramming outside of the
> proprietary ones mentioned?  I'm writing a document that claims this
> ain't so; I'd like to have some hope of being correct.
>
> Thanks in advance.
>
> -- 
>
> Tim Wescott
> Wescott Design Services
> http://www.wescottdesign.com
>

Walter Driedger wrote:
> Tim,
> 
> You first have to tell us what type of block diagram you are talking about.
> The term is used for a vast variety of situation.  But ladder diagrams is
> DEFINITELY not one of them.  I do block diagrams to define the functionality
> of the process units of a complete refinery.  I use them to the
> interconnectivity of a control network.  I use them to build organization
> charts.  The only thing all these have in common is that they connect
> rectangles with lines.
> 
> Any standards concerning block diagrams must necessarily reflect the
> requirements of a given technology in a given industry.
> 
> Walter.
> 
> "Tim Wescott" <tim@wescottnospamdesign.com> wrote in message
> news:108r5ghmbpj7759@corp.supernews.com...
> 
>>To my knowledge there is no formal definition of block diagramming
>>"languages" outside of such proprietary applications such as Simulink
>>and it's ilk, or such things as ladder diagrams (which I'm going to
>>claim isn't the same thing).  One sees minor variations of block
>>diagramming style within a discipline like control systems engineering,
>>and there can be severe divergences between disciplines (the common x in
>>a circle that denotes a summation block in control, for instance,
>>usually denotes a multiplier or other frequency mixing function in a
> 
> radio).
> 

Ahh, my thoughts are being clarified already.

Control systems block diagrams, as one would use to define (or 
illustrate) the structure of a control system so that you can 
intelligently extract transfer functions and/or devise controllers.  My 
experience with these specifically pertains to diagramming the 
controller and plant structure in a motion control system or something 
similar, and with designing radios (which uses a surprisingly similar 
set of blocks).

It would be interesting for me to get a feel for what you put in such a 
diagram.  Given that I've generally done production systems with 
fixed-tune controllers there's usually enough information in my initial 
block diagram that I can be 90% confident that my system will be stable 
when I first turn it on (and 10% of the time it really is!).  As you've 
stated before your situation is quite different, with many more unknowns 
at start-up.  If I were in your shoes I would still indicate roughly 
what a plant is expected to do -- integrate, low-pass, lead-lag, etc. -- 
do you find it useful to do this in your environment?

Unrelated question:  When you are using a block diagram to define the 
interconnectivity of a control network, is it largely what you'd do if 
you were defining an office network, or is there a large amount of 
information that's specific to the control problem?

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

"Tim Wescott" <tim@wescottnospamdesign.com> wrote in message
news:108rn5tp459jjb1@corp.supernews.com...
>
> Unrelated question:  When you are using a block diagram to define the
> interconnectivity of a control network, is it largely what you'd do if
> you were defining an office network, or is there a large amount of
> information that's specific to the control problem?

Hehe... sometimes it *includes* designing an office network (ie. Ethernet
LAN).

Cameron:-)

Tim Wescott wrote:

> To my knowledge there is no formal definition of block diagramming 
> "languages" outside of such proprietary applications such as Simulink 
> and it's ilk, or such things as ladder diagrams (which I'm going to 
> claim isn't the same thing).  One sees minor variations of block 
> diagramming style within a discipline like control systems engineering, 
> and there can be severe divergences between disciplines (the common x in 
> a circle that denotes a summation block in control, for instance, 
> usually denotes a multiplier or other frequency mixing function in a 
> radio).
> 
> This makes sense, because block diagrams seem to work best if one has a 
> bit of flexibility with the way one shows things.  It would be difficult 
> to design one "language" that would work as well for radio as it does 
> for control loops.
> 
> None the less, do any of you know of any attempt (or success) to develop 
> a standard, formal system of block diagramming outside of the 
> proprietary ones mentioned?  I'm writing a document that claims this 
> ain't so; I'd like to have some hope of being correct.
> 

There is a properly designed graphical programming languaga called 
Prograph. It was designed and implemented by a bunch of Canadian 
academics about 15 or so years ago and there was at least one commercial 
implementation of the language (on the Macintosh, which was probably the 
only suitable platform in that era). It is a data flow object oriented 
language. Googling for Prograph may still turn something up (although 
you'll probably also get a lot of hits for Prograph monitors !).

FWIW there's also a graphical programming language built in to LabView - 
I think it's called "Z".

There was also another block diagram type language for DSP developed at 
Berkeley, whose name escapes me. This was also late 1980's/early 1990's.

Paul

On Mon, 26 Apr 2004 23:07:09 UTC, Tim Wescott 
<tim@wescottnospamdesign.com> wrote:

> To my knowledge there is no formal definition of block diagramming 
> "languages" outside of such proprietary applications such as Simulink 
> and it's ilk, or such things as ladder diagrams (which I'm going to 
> claim isn't the same thing).  One sees minor variations of block 
> diagramming style within a discipline like control systems engineering, 
> and there can be severe divergences between disciplines (the common x in 
> a circle that denotes a summation block in control, for instance, 
> usually denotes a multiplier or other frequency mixing function in a radio).
> 

There is Grafcet, a language developped by the French in the second 
half of the 1970s.  It borrows concepts from finite-state machines and
Petri nets.


It is used to describe sequential systems.


I use it to discuss such systems with customers, and then I derive the
ladder programs for programmable logic controllers.  Some PLCs of 
French design accept Grafcet directly.  The OMRONs blissfully ignore 
it so I have to manually tranlate my Grafcets to ladder programs.


Grafcet is a high-level language while ladder programs are 
assembly-like languages.
-- 
Jean Castonguay
&#4294967295;lectrocommande Pascal

Tim,

Well, I see a series of blocks connected by lines.  Each block has one or
more inputs and one output.  Each line represents a signal, product or other
'thing' which is transferred to other point(s) in the system.

Blocks carry out functions.  They are the micro-plant.  In the block goes an
identifier and some form of transfer function.  It could be Boolean,
LaPlace, a computer program, the simulation of a collapsing super nova or
even text such as "compares expense forms with company policies and issue
instructions to accounting if approved."  A block with multiple outputs is
really several parallel blocks with the same inputs, i./e. "compares expense
forms with company policies and returns to employee if not approved."   They
can be flush, adjacent if they are carried out by the same plant (or
supervisor).

Lines come in two varieties, information and matter/energy.  The difference
is that matter/energy can only go to a single destination.  If it goes to
more than one, two blocks need to used at the split point.  One multiplies
by x% and sends it one way, the other by (100-x%) and sends it another way.
Information lines can split off into as many directions as required as
information is not consumed.  Perhaps the two lines could be called
'consumables' and 'non-consumables'.  For ease of reading in particular
applications, special line symbols can be used but there are fundamentally
only two types.  Every line carries an identification.

Lines can only come together at blocks because there must be an explanation
of the rules of combination.  Matter/energy lines usually come together at a
function block that is nothing other than a simple addition, unless, of
course, chemical reactions occur.  Signal lines can be added, subtracted,
ANDed or merged in some other way to form a new type.  (Interesting note,
when I review P&IDs any time two signal lines come together without some
function at the junction, I know there is a mistake.  But piping can come
together at any time.  Matter simply adds.  That is understood.)

Blocks need not be rectangles.  For well known math functions such as
ADD/SUB, a simple circle with +s and -s on each signal line is simpler.  For
ANDs and ORs, I like the US MIL Boolean symbols.  (I do NOT like the
European custom of making every symbol a rectangle with text inside.)

A system of blocks and lines is called a 'network'.  A block can be drawn
around an entire network and defined as a block of its own.  A separate,
parallel block is needed for every individual output.

Now you've got me thinking.  Can the concept outlined above be applied to
all the various systems, including chemical processes, office organization,
logic diagrams, and communications networks?  Can the technique really be
defined in an application independent way?  Can it be attached to a graphics
platform such as MS Visio?  Can I get rich and famous from being involved in
the development of such a product?

I have trouble applying the concept to an electrical schematic at the
detailed level.  the block diagram is a lot more complex than the schematic.
The example I'm trying to diagram consists of a battery supplying a resistor
in series with two parallel resistors.  Everything influences everything
else!

Another question:  Am I describing a universal simulator?  The basic logic
engine handles the connectivity.  Specialized packages handle transfer
functions, Boolean, process models, etc.  It would be hard to develop a
model that handles office politics but you could still draw the diagram.

Walter.

"Tim Wescott" <tim@wescottnospamdesign.com> wrote in message
news:108rn5tp459jjb1@corp.supernews.com...
> Ahh, my thoughts are being clarified already.
>
> Control systems block diagrams, as one would use to define (or
> illustrate) the structure of a control system so that you can
> intelligently extract transfer functions and/or devise controllers.  My
> experience with these specifically pertains to diagramming the
> controller and plant structure in a motion control system or something
> similar, and with designing radios (which uses a surprisingly similar
> set of blocks).
>
> It would be interesting for me to get a feel for what you put in such a
> diagram.  Given that I've generally done production systems with
> fixed-tune controllers there's usually enough information in my initial
> block diagram that I can be 90% confident that my system will be stable
> when I first turn it on (and 10% of the time it really is!).  As you've
> stated before your situation is quite different, with many more unknowns
> at start-up.  If I were in your shoes I would still indicate roughly
> what a plant is expected to do -- integrate, low-pass, lead-lag, etc. -- 
> do you find it useful to do this in your environment?
>
> Unrelated question:  When you are using a block diagram to define the
> interconnectivity of a control network, is it largely what you'd do if
> you were defining an office network, or is there a large amount of
> information that's specific to the control problem?
>
> Tim Wescott
> Wescott Design Services
> http://www.wescottdesign.com

> Walter Driedger wrote:

> > Tim,
> >
> > You first have to tell us what type of block diagram you are talking
about.
> > The term is used for a vast variety of situation.  But ladder diagrams
is
> > DEFINITELY not one of them.  I do block diagrams to define the
functionality
> > of the process units of a complete refinery.  I use them to the
> > interconnectivity of a control network.  I use them to build
organization
> > charts.  The only thing all these have in common is that they connect
> > rectangles with lines.
> >
> > Any standards concerning block diagrams must necessarily reflect the
> > requirements of a given technology in a given industry.
> >
> > Walter.
> >
> > "Tim Wescott" <tim@wescottnospamdesign.com> wrote in message
> > news:108r5ghmbpj7759@corp.supernews.com...
> >
> >>To my knowledge there is no formal definition of block diagramming
> >>"languages" outside of such proprietary applications such as Simulink
> >>and it's ilk, or such things as ladder diagrams (which I'm going to
> >>claim isn't the same thing).  One sees minor variations of block
> >>diagramming style within a discipline like control systems engineering,
> >>and there can be severe divergences between disciplines (the common x in
> >>a circle that denotes a summation block in control, for instance,
> >>usually denotes a multiplier or other frequency mixing function in a
> >
> > radio).
> >
>

Walter Driedger wrote:

> Tim,
> 
> Well, I see a series of blocks connected by lines.  Each block has one or
> more inputs and one output.  Each line represents a signal, product or other
> 'thing' which is transferred to other point(s) in the system.
> 
> Blocks carry out functions.  They are the micro-plant.  In the block goes an
> identifier and some form of transfer function.  It could be Boolean,
> LaPlace, a computer program, the simulation of a collapsing super nova or
> even text such as "compares expense forms with company policies and issue
> instructions to accounting if approved."  A block with multiple outputs is
> really several parallel blocks with the same inputs, i./e. "compares expense
> forms with company policies and returns to employee if not approved."   They
> can be flush, adjacent if they are carried out by the same plant (or
> supervisor).

This is the variety of block diagram that I'm considering.

> Lines come in two varieties, information and matter/energy.  The difference
> is that matter/energy can only go to a single destination.  If it goes to
> more than one, two blocks need to used at the split point.  One multiplies
> by x% and sends it one way, the other by (100-x%) and sends it another way.
> Information lines can split off into as many directions as required as
> information is not consumed.  Perhaps the two lines could be called
> 'consumables' and 'non-consumables'.  For ease of reading in particular
> applications, special line symbols can be used but there are fundamentally
> only two types.  Every line carries an identification.

Good distinction.  Do you actually note them that way, or do you just 
keep in in mind?  I'm working on some tutorial material that's primarily 
aimed at signal processing block diagrams where everything is assumed to 
be information, but sooner or later that signal processing is going to 
turn a shaft, and you can't really call it a "signal" any more.  This 
has always bugged me on my block diagrams, where I measure reality, 
convert it to a number, wring it out with fancy software, apply it to a 
DAC and drive a big thermally sensitive motor with it.  On the one hand 
it unifies the math to show it all the same way, but it sure makes a 
difference when you start sticking your hands on the real thing.

> Lines can only come together at blocks because there must be an explanation
> of the rules of combination.  Matter/energy lines usually come together at a
> function block that is nothing other than a simple addition, unless, of
> course, chemical reactions occur.  Signal lines can be added, subtracted,
> ANDed or merged in some other way to form a new type.  (Interesting note,
> when I review P&IDs any time two signal lines come together without some
> function at the junction, I know there is a mistake.  But piping can come
> together at any time.  Matter simply adds.  That is understood.)

Unless one is the fresh water pipe and the other is waste -- then you 
may want to ask a question or two :).

> Blocks need not be rectangles.  For well known math functions such as
> ADD/SUB, a simple circle with +s and -s on each signal line is simpler.  For
> ANDs and ORs, I like the US MIL Boolean symbols.  (I do NOT like the
> European custom of making every symbol a rectangle with text inside.)

I've taken to using a circle for any operation that combines two numbers 
in a predictable way -- certainly addition and multiplication both get a 
circle, with a symbol inside showing which is which.  I've also done 
this with controlled limiters where you want to take the maximum of two 
signals (fixed limiters get a rectangular box).

> A system of blocks and lines is called a 'network'.  A block can be drawn
> around an entire network and defined as a block of its own.  A separate,
> parallel block is needed for every individual output.
> 
> Now you've got me thinking.  Can the concept outlined above be applied to
> all the various systems, including chemical processes, office organization,
> logic diagrams, and communications networks?  Can the technique really be
> defined in an application independent way?  Can it be attached to a graphics
> platform such as MS Visio?  Can I get rich and famous from being involved in
> the development of such a product?

Well, that's what got _me_ started.  I do control loops and (to a small 
extent) radios.  Both radio engineers and control engineers know that a 
block with "f(.)" means "apply function f to the input", and "k/s" means 
"integrator with gain k", etc.  What really set me off, though, is that 
if you see a circle with an X in it on a radio block diagram it's a 
mixer that's essentially multiplying it's inputs, but if you see the 
same thing in a control block diagram it's a summation, and somebody 
forgot to note the signs of the input lines.  That means that you can 
severely misinterpret a block diagram unless you know what "dialect" it 
is.

I started took to avoiding a circle with an "X" in it, but putting a "+" 
or a "x" in my blocks.  Now I'm using a capital sigma (summation) or pi 
(product).  Pi is admittedly obscure, but at least no one is going to 
look at it and assume that they know what it is!

> I have trouble applying the concept to an electrical schematic at the
> detailed level.  the block diagram is a lot more complex than the schematic.
> The example I'm trying to diagram consists of a battery supplying a resistor
> in series with two parallel resistors.  Everything influences everything
> else!

I can't find the #$%@ thing, but the "The Control Handbook" by the IEEE 
has an article on an alternate form of block diagramming for simulating 
real systems.  It models _everything_ as an energy transfer, and each 
block has to specify what form the energy is coming in, how much is 
wasted, how it may be stored (or discharged), and the form of the energy 
coming out.  Thus, for instance, a motor is nothing but a transformer 
that converts volts and amps into torque and RPM with a little bit of 
wasted heat and stored rotational energy.  The nice thing about it is 
that the generator model is built in: turn the shaft and it becomes the 
input and the electrical side is now the output.

> Another question:  Am I describing a universal simulator?  The basic logic
> engine handles the connectivity.  Specialized packages handle transfer
> functions, Boolean, process models, etc.  It would be hard to develop a
> model that handles office politics but you could still draw the diagram.

Just don't show it to the boss!

-- snip --

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I don't know if it is applicable here, but when I'm doing block diagrams,
straight or smooth lines on the blocks indicate known functions, and wavy
lines indicate unknowns or "unsures".  As the system becomes better defined,
wavy lines are replaced with the straight ones.  On a typical four sided
block, the number of sides still wavy would be indicative of how much isn't
known about the block.   In some cases, wavy lines will indicate information
passing in an unknown way to a block.

It is possible to define the four or so sides of a block to be indicative of
certain standard properties.  Making the appropriate side wavy lets you know
what part of the block to work on or have someone else look at.

 Its proven handy in database and data flow diagrams.  Naturally, if your
systems are all well defined, then straight lines will do.



Michael



"Tim Wescott" <tim@wescottnospamdesign.com> wrote in message
news:10969qreoafuida@corp.supernews.com...
> Walter Driedger wrote:
>
> > Tim,
> >
> > Well, I see a series of blocks connected by lines.  Each block has one
or
> > more inputs and one output.  Each line represents a signal, product or
other
> > 'thing' which is transferred to other point(s) in the system.
> >
> > Blocks carry out functions.  They are the micro-plant.  In the block
goes an
> > identifier and some form of transfer function.  It could be Boolean,
> > LaPlace, a computer program, the simulation of a collapsing super nova
or
> > even text such as "compares expense forms with company policies and
issue
> > instructions to accounting if approved."  A block with multiple outputs
is
> > really several parallel blocks with the same inputs, i./e. "compares
expense
> > forms with company policies and returns to employee if not approved."
They
> > can be flush, adjacent if they are carried out by the same plant (or
> > supervisor).
>
> This is the variety of block diagram that I'm considering.
>
> > Lines come in two varieties, information and matter/energy.  The
difference
> > is that matter/energy can only go to a single destination.  If it goes
to
> > more than one, two blocks need to used at the split point.  One
multiplies
> > by x% and sends it one way, the other by (100-x%) and sends it another
way.
> > Information lines can split off into as many directions as required as
> > information is not consumed.  Perhaps the two lines could be called
> > 'consumables' and 'non-consumables'.  For ease of reading in particular
> > applications, special line symbols can be used but there are
fundamentally
> > only two types.  Every line carries an identification.
>
> Good distinction.  Do you actually note them that way, or do you just
> keep in in mind?  I'm working on some tutorial material that's primarily
> aimed at signal processing block diagrams where everything is assumed to
> be information, but sooner or later that signal processing is going to
> turn a shaft, and you can't really call it a "signal" any more.  This
> has always bugged me on my block diagrams, where I measure reality,
> convert it to a number, wring it out with fancy software, apply it to a
> DAC and drive a big thermally sensitive motor with it.  On the one hand
> it unifies the math to show it all the same way, but it sure makes a
> difference when you start sticking your hands on the real thing.
>
> > Lines can only come together at blocks because there must be an
explanation
> > of the rules of combination.  Matter/energy lines usually come together
at a
> > function block that is nothing other than a simple addition, unless, of
> > course, chemical reactions occur.  Signal lines can be added,
subtracted,
> > ANDed or merged in some other way to form a new type.  (Interesting
note,
> > when I review P&IDs any time two signal lines come together without some
> > function at the junction, I know there is a mistake.  But piping can
come
> > together at any time.  Matter simply adds.  That is understood.)
>
> Unless one is the fresh water pipe and the other is waste -- then you
> may want to ask a question or two :).
>
> > Blocks need not be rectangles.  For well known math functions such as
> > ADD/SUB, a simple circle with +s and -s on each signal line is simpler.
For
> > ANDs and ORs, I like the US MIL Boolean symbols.  (I do NOT like the
> > European custom of making every symbol a rectangle with text inside.)
>
> I've taken to using a circle for any operation that combines two numbers
> in a predictable way -- certainly addition and multiplication both get a
> circle, with a symbol inside showing which is which.  I've also done
> this with controlled limiters where you want to take the maximum of two
> signals (fixed limiters get a rectangular box).
>
> > A system of blocks and lines is called a 'network'.  A block can be
drawn
> > around an entire network and defined as a block of its own.  A separate,
> > parallel block is needed for every individual output.
> >
> > Now you've got me thinking.  Can the concept outlined above be applied
to
> > all the various systems, including chemical processes, office
organization,
> > logic diagrams, and communications networks?  Can the technique really
be
> > defined in an application independent way?  Can it be attached to a
graphics
> > platform such as MS Visio?  Can I get rich and famous from being
involved in
> > the development of such a product?
>
> Well, that's what got _me_ started.  I do control loops and (to a small
> extent) radios.  Both radio engineers and control engineers know that a
> block with "f(.)" means "apply function f to the input", and "k/s" means
> "integrator with gain k", etc.  What really set me off, though, is that
> if you see a circle with an X in it on a radio block diagram it's a
> mixer that's essentially multiplying it's inputs, but if you see the
> same thing in a control block diagram it's a summation, and somebody
> forgot to note the signs of the input lines.  That means that you can
> severely misinterpret a block diagram unless you know what "dialect" it
> is.
>
> I started took to avoiding a circle with an "X" in it, but putting a "+"
> or a "x" in my blocks.  Now I'm using a capital sigma (summation) or pi
> (product).  Pi is admittedly obscure, but at least no one is going to
> look at it and assume that they know what it is!
>
> > I have trouble applying the concept to an electrical schematic at the
> > detailed level.  the block diagram is a lot more complex than the
schematic.
> > The example I'm trying to diagram consists of a battery supplying a
resistor
> > in series with two parallel resistors.  Everything influences everything
> > else!
>
> I can't find the #$%@ thing, but the "The Control Handbook" by the IEEE
> has an article on an alternate form of block diagramming for simulating
> real systems.  It models _everything_ as an energy transfer, and each
> block has to specify what form the energy is coming in, how much is
> wasted, how it may be stored (or discharged), and the form of the energy
> coming out.  Thus, for instance, a motor is nothing but a transformer
> that converts volts and amps into torque and RPM with a little bit of
> wasted heat and stored rotational energy.  The nice thing about it is
> that the generator model is built in: turn the shaft and it becomes the
> input and the electrical side is now the output.
>
> > Another question:  Am I describing a universal simulator?  The basic
logic
> > engine handles the connectivity.  Specialized packages handle transfer
> > functions, Boolean, process models, etc.  It would be hard to develop a
> > model that handles office politics but you could still draw the diagram.
>
> Just don't show it to the boss!
>
> -- snip --
>
> -- 
>
> Tim Wescott
> Wescott Design Services
> http://www.wescottdesign.com

On Sat, 01 May 2004 03:41:07 +0000, Walter Driedger wrote:
> A block with multiple outputs is
> really several parallel blocks with the same inputs, i./e. "compares expense
> forms with company policies and returns to employee if not approved."   They
> can be flush, adjacent if they are carried out by the same plant (or
> supervisor).
[snip]
> A system of blocks and lines is called a 'network'.  A block can be
> drawn around an entire network and defined as a block of its own.  A
> separate, parallel block is needed for every individual output.

Why is this restriction to single outputs useful for a
diagramming technique?  Seems darn painful to me.  Sure, if you
have some proof or simulation engine underneath, then it might
very well behave as though that were the case, but you wouldn't
really want to have to draw it that way!  Lots of common
processes produce multiple outputs.  Take your matter splitter,
for example.  Wouldn't that be more convenient as one box, with
one input and two outputs, one was the k% leg and the other the
(100-k)% leg?  You can label it, then, as a two-way splitter.
What if you'd built it as two separate gain blocks, as you
described, but you wanted to wrap the whole thing inside a
system block?

Maybe I missed something from earlier in the thread.  This is
the first post in the thread that I've seen.

Cheers,

-- 
Andrew