Block Diagramming

Andrew Reilly wrote:
> 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,

For "line" I assumed "pathway". At one level, an address bus, no matter
how wide, is a single line. At a higher level, both the address and data
busses are a single line. In a sense, a good block-diagram model has to
be fractal.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

"Tim Wescott" <tim@wescottnospamdesign.com> wrote in message
news:10969qreoafuida@corp.supernews.com...
>
> 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.

I'm trying to design this hypothetical universal simulator.  In practice
I've never made the disticnction simply because a given diagram has never
used both.  Most of mine are pure signal.  When I've done material I've
never associated it with quantities because I'm not a process engineer.

Walter

go to bottom --

"Andrew Reilly" <andrew-newspost@areilly.bpc-users.org> wrote in message
news:pan.2004.05.01.07.48.54.468961@areilly.bpc-users.org...
> 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.

Nothing missed.  The reason I did this is to maintain the form

output1 = f1(x, y, z)

In this way every block has an equation with a single output.  It's not as
difficult as it seems since having a multiple output situation simply has
multiple lines coming out of your box.  What I'm suggesting is you separate
the box with the multiple outputs into multiple boxes.  The only thing that
might be awkward is a simultaneous equation.  In that case, you could take
the entire results vector as a single signal (line).

Walter.

Walter Driedger wrote:

> go to bottom --
> 
> "Andrew Reilly" <andrew-newspost@areilly.bpc-users.org> wrote in message
> news:pan.2004.05.01.07.48.54.468961@areilly.bpc-users.org...
> 
>>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.
> 
> 
> Nothing missed.  The reason I did this is to maintain the form
> 
> output1 = f1(x, y, z)
> 
> In this way every block has an equation with a single output.  It's not as
> difficult as it seems since having a multiple output situation simply has
> multiple lines coming out of your box.  What I'm suggesting is you separate
> the box with the multiple outputs into multiple boxes.  The only thing that
> might be awkward is a simultaneous equation.  In that case, you could take
> the entire results vector as a single signal (line).
> 
> Walter.
> 
> 

I usually take the vector approach, unless I want to show two outputs of 
different "character", whatever that should happen to mean for that 
particular block diagram.  It could be as close as a plant output and 
it's measured value, or as different as a driver amplifier and an 
over-temp alarm signal.

-- 

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

"Walter Driedger" <walter@driesmithdger.ca> wrote in message
news:n%Ekc.308350$Pk3.112698@pd7tw1no...

<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.
>
> 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?
>

Unfortunately it has been done, I have taken part in "management consultant"
run events designed to map out the company's material and data flows.  I
seem to recall that it was a patented "Top Mapping" kit by DEC (as in VAX!,
which dates it!) with pictures of factories, warehouses, lorries, islands
roads etc.  We used large sheets of paper and that 3M spray that allows you
to move bits.  When everyone agreed a sheet of clear film was stuck on top
and in exchange for large sums of money the consultants photo-reduced the
output and used it to propose expensive new systems.  The technique also
seems to be called SEEMAP, and I'm sure the symbols are available in MS
Office powerpoint/publisher format.

Paul Russell <prussell@sonic.net> wrote in message news:<cIljc.8314$Fo4.106776@typhoon.sonic.net>...
> 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

I strongly recommend, to any who are seriously interested in block
diagramming languages, that you download and play around with Ptolemy
II from UC Berkeley:

http://ptolemy.eecs.berkeley.edu/ptolemyII/

Rick

At this point I shall blow the ControlDraw trumpet. ControlDraw is designed
for Control Sysem engineers

I'll quote from the manual on the simulation of diagrams:
ControlDraw symbols can be given a formula to relate it's outputs with it's
inputs.

The values of outputs are sent through the connections to the inputs to
which they connect.

In addition the object itself has a value - this is then used to animate the
object.

The Symbol Dynamics form provides a drag and drop interface for defining the
objects script and testing it.

When a page is in run mode or static run mode then each symbol executes the
logic, clicking a Symbol calls up the Dynamics Popup Menu.

If the diagram contains steps and transitions then AutoSFC functions are
executed so the the SFC can Run with no code.

If a page has an associate matrix you can use the matrix in simulations


This provides unlimited simulation capabilities.

Symbol code is programmed in VBScript. It is possible to introduce script
errors, see Simulation Error Handling for a guide to removing the errors


Variables

A CD2 object can support a number of variables:

IO Variables are the inputs and outputs of the object

Any Input that is derived from an object's output that in turn gets it's
values from preceding objects is read only. It may be written during the
execution of the expression, however it will be subsequently overwritten by
the preceding objects output.

The outputs are related to the input by the expression you enter

You can also declare local variables within the objects expression. these
are not save between executions of the object expression

There are also global variables that apply to each object in the simuation,
these has the form ObjVals(sym####) where #### is the IDD of the object.

The Simulation language VBScript


Displaying Dynamics

ControlDraw Objects can display their dynamic state in a number of ways

A drop down list in their the Symbol Dynamics form allows selection of

0 -None

1 - Select picture

2 - Display Value

3 - Height to value

4 - Width to Value

5 - Highlight if True



Francis
www.controldraw.com
21st Century process control specification and design


> I strongly recommend, to any who are seriously interested in block
> diagramming languages, that you download and play around with Ptolemy
> II from UC Berkeley:
>
> http://ptolemy.eecs.berkeley.edu/ptolemyII/
>
> Rick

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.
> 
> Thanks in advance.
> 

I want to thank you all for your comments, but I don't want you to stop.

So: thanks, and don't stop!

-- 

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