Block Diagramming

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.

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?

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

Cameron:-)

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

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.

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.

organization

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

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.

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

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

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

Just don't show it to the boss!

-- snip --

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

fundamentally

subtracted,

organization,

[snip]

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

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

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.

organization,

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.

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:

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

21st Century process control specification and design

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

So: thanks, and don't stop!