Re: [Qscada-developers] short interesting article

[Iain B. <ia...@ne...>]

On Tue, 2006-11-14 at 13:20 -0500, wireless wrote:
> Hello Everyone,
> 
> 
> http://www.stateworks.com/active/content/en/home/view_newsletter.php?id=26
> 
> This is pushing a vendor solution,but I do agree with the state machine
> approach to controls. Especially if you are going to migrate
> from one plc(dcs) to another or from a plc to an embedded linux system
> runing pid code, or from a plc to qscada etc etc....

Coming from the other side (I started writing state machines and control
systems code in C and C++) I've recently started using IEC 61131-3, and
I can't comprehend how anybody could like ladder logic!  It is a
suffocating language!  Sure, it may be "easier" for an "old"
hardware-control systems engineer to pick up, but at what cost? [answer
to rhetorical question: the cost is the limitations of what you can do
with ladder, and how long it takes you to do anything!]

I tried some of my earlier IEC 61131-3 programs in each of ladder (LD),
structured text (ST) (a kind of pascal-like language); Continuous
Function Charts (CFC); Function Block Diagram (FBD); and a bit of
Sequential Function Charts (SFC) as mentioned in the above article.

This is what I found:

LD was the hardest to program in - some elements of my specifications
took hundreds of lines of ladder, and there is no easy way of reading
through such monolithic code. (There's no empty lines, and comment
blocks like a textual programming language).

SFC is great for making simple state machines, especially when
managers / customers specify a particular state machine, but don't want
to see all the code behind it.  However, SFC has to rely on the others
for doing the work.

CFC is probably the best "Graphical" language in IEC 61131-3.  It
approaches the all-great all-powerful G+ graphical programming language
developed by LabView (this is by far the best graphical programming
language I have ever seen).  It's great for writing a graphical spec
which the customer can agree on, then implementing is the same form.

As an example, attached is a spec that I wrote with a customer, and the
final implementation in IEC 61131-3.  Customers get excited when they
see the implementation looking like their spec - and it has advantages
for the programmer too - if there are functional errors, we can go back
to the spec and say "it's performing the way you specified", and prove
it by showing them the implementation.  It would be near-impossible to
get a non-programming customer to agree to c++ code as a specification.

FBD seems to be a bad mix of LD and CFC.  Your limited to ladder like
steps, without the freedom of CFC, but at least you can use more
complicated structures than LD.

and finally, ST, or structured text, is by far the easiest for
implementing comms and the "guts" of the program.  Anything difficult is
done here!  And the outcome is often the most compact.

I disagree with the stateworks claim that "building any complex system
requiring several cooperating state machines ... with the means offered
by the SFC notation is theoretically and practically just impossible."
given that you can and must call on the other languages in IEC 61131-3
to supplement your state machines.

Anyway, that was a fun little exercise.  Hope you find my thoughts
interesting, on with work! ...

-- 
Iain Buchanan <iaindb at netspace dot net dot au>

What no spouse of a writer can ever understand is that a writer is working
when he's staring out the window.