Better Programming Language (was: Re: BUSN: The future of Industrial automation business?)

J

Thread Starter

Jiri Baum

Jake Brodsky:
> I wish the industry would adopt some more useful language standards for control than Relay Ladder Logic. Using common languages such as C and C++ doesn't help much. What we really need is a scripting language oriented around time and event based controls and some control kernel utilities which clearly show latencies, pending tasks, memory usage, and other such things in a manner that doesn't require a computer science background to understand.<

Do you have any more detailed ideas?

It's easy to see that the status quo is not as useful as it should be. But whenever I try to think in detail how such a programming language should work, I'm never quite sure that it would actually be all that much better.

So, any ideas?


Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
C

Curt Wuollet

And that's not even the problem. The problem is to make it as simple as ladder logic so the market will accept it. I have been thinking of sort of a 4GL for automation. Where a general
class 4GL makes DB operations and reports simple, this would make control and communications simple. There are a finite number of operations that comprise a large percentage of the work, so it seems feasible to automate those operations. But, none of the other alternatives have gained much traction so it might be a futile effort. Especially if it isn't blessed by a megacorp.

Regards

cww
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned
Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive
Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to
Linux.
 
B

Brian E Boothe

ohh in other words another Lazy Mans Compiler or Tokenizer ?? Being a programmer is alot more than easily Getting functions and procedures and your Program up and Running..What exactly do u want ?? give me an example? Have U Tried Visual Basic ? if You Think VB is real complicated.. i think you should change careers.
 
J

James Ingraham

It's not that VB is complicated. It's that it sucks for control issues.

It's not that that C can't do the job, it's that it is very difficult to monitor, test, debug, and change in real-time. Not to mention the overhead of the language for very simple control tasks.

It's not that ladder logic can't accomplish the control tasks, it's that it's painful when algorithms become complicated.

Flowcharts seem like a good idea, but then jumping-around-willy-nilly was excised from "modern" programming languages a long time ago for a good reason.

I tried LabView for control stuff once. I kinda liked it. The rest of my programming staff wondered what the hell I was doing playing with Egyptian heiroglyphics during busines hours. (There were other limitations, too.)

I occaissionally get people telling me I should use CNC controls for our stuff. Unfortunately, CNC controls are GREAT for CNCs; that doesn't make them good at other kinds of control.

I think Java may have some potential; since it runs on a VM it is fairly easy to do real-time monitoring / changes, and it could be fairly simple with some standardized class library. I doubt seriously that the JCP would bother with it, which means we'd never get a standard. And as much as I like Java, I can't show it to a maintenance electrician and say "See, when the bit is on it turns green."

I use a lot of entivity's Think & Do, A-B's ControlLogix, and our own C on QNX system. I'm support 22 different controls schemes right now. When I complain to A-B or entivity or QNX, they always say, "Well, what's better?"

NOTHING. Everything is terrible. The only thing I can do is pick a solution and live with its limitations.

-James Ingraham
Sage Automation, Inc.
 
Brian E Boothe:
> ohh in other words another Lazy Mans Compiler or Tokenizer ??

No.

> Being a programmer is alot more than easily Getting functions and
> procedures and your Program up and Running..What exactly do u want ??
> give me an example?

A language oriented toward industrial control. For instance, SQL is a language oriented toward database access; postscript is a language oriented toward page description.

This would require understanding on a fundamental level the task faced by the industrial control programmer, distilling its essence and embodying it in a language design. The problem with RLL is that it encourages (forces) one to look at the trees when one should be looking at the forest, both during programming and later during troubleshooting and maintenance.

> Have U Tried Visual Basic ? if You Think VB is real complicated.. i
> think you should change careers.

Personally, I think VB is a baroque language descended from Fortran and Cobol, mutated under the new moon, never quite acquiring any elegance or modern features in any sensible way. It barely managed to get subroutines callable by name. In addition, it is somewhat oriented toward designing the UI (badly), while for control one would prefer a language which is oriented toward control.


Jiri

--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
M

Michael Griffin

Jiri Baum wrote:
<clip>
> This would require understanding on a fundamental level the task faced by the industrial control programmer, distilling its essence and embodying it in a language design. The problem with RLL is that it encourages (forces) one to look at the trees when one should be looking at the forest, both during programming and later during troubleshooting and maintenance.

Isn't this what graphcet (SFC) or state diagrams are intended for? People have already spent a great deal of time pondering this question, and these are the answers they came up with. I haven't seen any better ideas yet for taking a problem from design to programming to maintenance.

You need to see both the forest and the trees, and I think combining SFC (or state logic) with ladder can provide this.

<clip>
> Personally, I think VB is a baroque language descended from Fortran and Cobol, mutated under the new moon, never quite acquiring any elegance or modern features in any sensible way. It barely managed to get subroutines callable by name. In addition, it is somewhat oriented toward designing the UI (badly), while for control one would prefer a language which is oriented toward control.

It is a deceptive language, in that it can be both simple and complex at the same time. It is simple in that an inexperienced person can get a small program working quickly, but complex in that it is difficult for even an experienced programmer to get a non-trivial program working correctly.

The typical development process with Visual Basic emphasises writing and debugging code, rather than analysis and correct initial implementation. While the first method may be workable with very small projects, it can be a disaster with larger ones.

The root if the problem is that the core of Visual Basic is a rather archaic language, even if it has had various newer features grafted onto it. Quite a few things end up being the responsibility of the programmer, rather than
being handled by the compiler or the nature of the language itself.


--

************************
Michael Griffin
London, Ont. Canada
************************
 
Jiri Baum:
> > This would require understanding on a fundamental level the task faced by the industrial control programmer, distilling its essence and embodying it in a language design. The problem with RLL is that it encourages (forces) one to look at the trees when one should be looking at the forest, both during programming and later during troubleshooting and maintenance.

Michael Griffin:
> Isn't this what graphcet (SFC) or state diagrams are intended for?

Yes, but I don't believe they do anywhere near as much as could be done.

> > Personally, I think VB is a baroque language descended from Fortran and Cobol, mutated under the new moon, never quite acquiring any elegance or modern features in any sensible way.
...
> The root if the problem is that the core of Visual Basic is a rather archaic language, even if it has had various newer features grafted onto it.

Yes, that's a great part of it. To suggest an alternative, try python--easy to read, modern, clean.


Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
S

ScienceOfficer

James Ingraham, as usual, got a lot of content into a detailed yet concise post. The words to remember: "When I complain to A-B or entivity or QNX, they always say, 'Well, what's better?' NOTHING. Everything is terrible. The only thing I can do is pick a solution and live with its limitations."

I personally have been predicting the imminent death of ladder logic for 19.5 years now, and on the date I'm thinking of, a helpful and influential engineer from a major PLC company was agreeing with me. Over those years and three careers, I have seen the ebb and flow of assembly language, PL/1, FORTRAN, BASIC, FORTH, C*, Pascal, various flowcharting languages, RAIL,
Karel, Sequential Function Charts, Structured Text, and everything else that's out there today doing the PLC function. Only Relay Ladder Logic
(RLL) has monotonically increased market share during all that time. Incredibly, that's despite the total incompatibility of RLL between brands
and the shaky compatibility within a single brand!

In the thousands of _discrete_ control applications I've touched, all but 1.5 of the successful ones were RLL. (I've been involved with dozens of projects that didn't fall under discrete/PLC control, and I used C*, *nix,
etc., etc. for those.) Those 1.5 projects that didn't go RLL include one brilliant success using SFCs in a PLC-5, and one brilliant success using
SFCs in a PLC-5 that the end user demanded be recoded to RLL before he would pay the final 10%!

The following is opinion, based upon observation, so be kind in your responses: RLL seems to fulfill a market need, and a successor must
provide users with the value they perceive in RLL. The graphical presentation and onscreen animation are obviously vital. I have wondered
if the low information density of an RLL screen, say compared to a Visual Basic screen, is comforting to the end users. I'm going out on a limb by saying that the ordinary coil instruction, Output Energize in A-B lingo, is what keeps RLL alive for discrete control.

In North America, Latch and Unlatch don't seem to be popular in discrete control programming. Personally, I invoke them frequently, because the
reasons for turning something on are not always the opposite of the reasons for turning them off. (Friday is not the opposite of Saturday.)

Latch is equivalent to IF A THEN B. Unlatch is equivalent to IF A THEN NOT B. In mathematical logic language, Output Energize is B IF AND ONLY IF A, or in shorthand, B IFF A.

I am not aware of any language that implements IFF as RLL does (but if it's out there, I'll know about it soon! <G>). I think that the successor to RLL for discrete control will be the language that implements the simple coil as only RLL does today, as far as I know.

I'm not done yet.

I believe that RLL (and the canonical PLC architecture) thrives as long as all I/O are star connected to the central processor. Yet, we are ten years down the road of distributing control to small, independent intelligences.

First came distributed I/O, with a central Big Iron PLC. Then came extremely distributed I/O, with the various fieldbuses. Then came extremely small controllers, tightly integrated with the Big Iron CPU via the various fieldbuses.

The breakthrough that I think will turn everything upside down will be a comprehensible system for managing networked I/O and distributed control.

This will be a graphical system for configuration, control, and data collection (slight grin from the A-B gang!) that establishes unique, graphically displayed interrelationships between extremely distributed intelligences.

Here's the atomic paradigm: An illuminated button box and a motor starter. The coil on the starter understands its relationship with the green and red buttons. The lamps on the button box understand their relationship with the auxiliary contacts on the starter. Only network connections exist. The operator can see and quickly comprehend the status of the buttons, lamps, and starter. Somewhere, a configuration software created these relationships and maintains them.

When we get to there, automation will move from product expertise to process expertise. And then, I'll be moving on to my next career!

Hope this helps!

Larry Lawver
Rexel / Central Florida
 
I remember quite a while back a promising language called Forth. I am sure there are users who will remember this language. It basically has a very small instruction set.

The programmer uses this small instruction set to built up simple commands applicable to the application. He then keeps building up to a level of abstraction whereby only one command is called to run the application.

The programmer can be said to be writting a language and not a program as such. The language is simple to use and allows the programmer to move up in the level of abstraction.

About 10 years ago the language was used extensively in control applications but it seems to have gone of the boil. I feel it still has got very good potential.
 
C
I used FORTH many years ago and it was a great idea and was one of the better languages for small systems. It was efficient and very low in
overhead which made it popular for kit computers as well. It would be a good language to develop a PLC in on PLC class hardware. Unfortunately, the world had gone a different way and automation has
focused on totally eliminating programming skills from the picture. This, as far as I can tell is the single most important criteria. Sound engineering practice, efficiency, reliablity, investment protection, and other things that used to be important are secondary concerns at best. Any sort of bloated kludge as output is permissable as long as you can do it with minimal learning and a mouse in your hand.

I know this might annoy some folks but that's because they lack the perspective to see that using 40 million lines of buggy secret code and Visual Basic to control a process, is simply wrong from any rational engineering viewpoint. But using maybe 32k of FORTH running on the bare
metal would require skills beyond point and click and wouldn't look very kewl. I would hope that we will swing back towards a reasonable compromise, reasonable ease of use on a platform more suitable for automation. But I'm clearly not in the mainstream here and it'll apparently get much
worse before it gets better. Marketing will prevail before reason does.

My point is that an awful lot of "programmers" today would derive a great deal of perspective from doing a project in FORTH or assembler. It's hard to justify many orders of magnitude more bloat to accomplish the task more slowly and much less reliably to avoid learning to program. It's just not that hard to teach people to program and it would vastly improve the end product.

Regards

cww
 
Larry "ScienceOfficer" Lawver:
> Latch is equivalent to IF A THEN B. Unlatch is equivalent to IF A THEN NOT B. In mathematical logic language, Output Energize is B IF AND ONLY IF A, or in shorthand, B IFF A.
>
> I am not aware of any language that implements IFF as RLL does (but if it's out there, I'll know about it soon! <G>). <

Most do - it's the assignment statement, B = A

> Here's the atomic paradigm: An illuminated button box and a motor starter. The coil on the starter understands its relationship with the green and red buttons. <

Sounds very very object-oriented. I wonder to what extent it'll actually work - for instance, if the green button should turn the motor on only
in manual mode, where is that put in?

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
M

Michael Griffin

> > Here's the atomic paradigm: An illuminated button box and a motor
> > starter. The coil on the starter understands its relationship with
> > the green and red buttons.
>
> Sounds very very object-oriented. I wonder to what extent it'll
> actually work - for instance, if the green button should turn the
> motor on only in manual mode, where is that put in?
<clip>

Actually it simply sounds like a function block with parameters. The input addresses of the red and green buttons are input parameters, and the address of the contactor is an output parameter (actually in/out so you can seal in).
If you need a different functionality, then you either write a new block (if you think you can re-use it later), or just not use a block for that application.

So far what I've described isn't an advanced concept. However, suppose you also encapsulated the fault detection and alarm messaging? When you use the block in a project, the alarm messages automatically come with it. Your system could direct the alarm messages to the appropriate alarm display device which is selected at run time.

************************
Michael Griffin
London, Ont. Canada
************************
 
S

ScienceOfficer

Message text written by Jiri Baum
>Larry "ScienceOfficer" Lawver:
> Latch is equivalent to IF A THEN B. Unlatch is equivalent to IF A
> THEN NOT B. In mathematical logic language, Output Energize is B IF
> AND ONLY IF A, or in shorthand, B IFF A.

> I am not aware of any language that implements IFF as RLL does (but if
> it's out there, I'll know about it soon! <G>).

Most do - it's the assignment statement, B = A<

Jiri--- In another universe, I sent the final edit of that comment, instead of what I actually posted. Yes, of course you are right; I meant to say that what was needed was a way to implement "IFF" in a way that keeps the logical flow going from left to right, as a typical output coil instruction does.

You had other comments, and Michael Griffin responded:

"> > <Lawver> Here's the atomic paradigm: An illuminated button box and a motor
> > starter. The coil on the starter understands its relationship with
> > the green and red buttons.

"> <Baum"> Sounds very very object-oriented. I wonder to what extent it'll actually
> work - for instance, if the green button should turn the motor on only
> in manual mode, where is that put in?

" <Griffin> Actually it simply sounds like a function block with parameters. The input
addresses of the red and green buttons are input parameters, and the address
of the contactor is an output parameter (actually in/out so you can seal in).
(...clip...)

" So far what I've described isn't an advanced concept. However, suppose you
also encapsulated the fault detection and alarm messaging? When you use the block in a project, the alarm messages automatically come with it. Your system could direct the alarm messages to the appropriate alarm display device which is selected at run time."

I have had great success in training my clients to use structured design concepts and to treat automation elements as objects. Function Block
Diagrams (FBDs) have been received enthusiastically by my newer clients in our newer products. So far, so good.

However, FBDs suffered a severe pushback in our motion products. Our graphical motion language, which my clients and I have used very productively, is replaced in our newer products by a ladder-based instruction set demanded by the customer base!

Further, my larger point was that I don't think RLL works for (future) extremely distributed control. I agree with Michael entirely, as long as the project resides, at runtime, in a central controller. What I'm looking for is a way to graphically manage, say, a button box and a starter, both intelligent, with no central intelligence online at runtime.

Hope this helps!

Larry Lawver
Rexel / Central Florida
 
Larry "ScienceOfficer" Lawver:
> > > > Latch is equivalent to IF A THEN B. Unlatch is equivalent to IF
> > > > A THEN NOT B. In mathematical logic language, Output Energize
> > > > is B IF AND ONLY IF A, or in shorthand, B IFF A.

> > > I am not aware of any language that implements IFF as RLL does
> > > (but if it's out there, I'll know about it soon! <G>).

Jiri Baum:
> > > Most do - it's the assignment statement, B = A

Larry "ScienceOfficer" Lawver:
> Jiri--- In another universe, I sent the final edit of that comment,
> instead of what I actually posted.

No worries, that happens :)

> Yes, of course you are right; I meant to say that what was needed was
> a way to implement "IFF" in a way that keeps the logical flow going
> from left to right, as a typical output coil instruction does.

Still, that's a syntactic matter; depending on the language, it might even be possible to override it (Ada, forth, partially in C++).

In logical languages (Prolog, Mercury) assignment goes both ways, so you can write A=B instead of B=A, but hardly anyone programs in them.

> You had other comments, and Michael Griffin responded:

> > > <Lawver> Here's the atomic paradigm: An illuminated button box
> > > and a motor starter. The coil on the starter understands its
> > > relationship with the green and red buttons.

> > > <Baum> Sounds very very object-oriented. I wonder to what extent
> > > it'll actually work - for instance, if the green button should
> > > turn the motor on only in manual mode, where is that put in?

Michael Griffin:
> > Actually it simply sounds like a function block with parameters. The
> > input addresses of the red and green buttons are input parameters,
> > and the address of the contactor is an output parameter (actually
> > in/out so you can seal in).

The phrasing was more object oriented than that; but yes, that's another sensible way of doing it.

> (...clip...)

> > "So far what I've described isn't an advanced concept. However,
> > suppose you also encapsulated the fault detection and alarm
> > messaging? When you use the block in a project, the alarm messages
> > automatically come with it. Your system could direct the alarm
> > messages to the appropriate alarm display device which is selected
> > at run time."

Yup, that'd be good. Make sure, though, that the alarm messages can be interpreted by other parts of the program instead - sometimes it might
be able to handle such errors satisfactorily (or, for that matter, blink them out on a light).

> I have had great success in training my clients to use structured
> design concepts and to treat automation elements as objects. Function
> Block Diagrams (FBDs) have been received enthusiastically by my newer
> clients in our newer products. So far, so good.

At least *some* good news :)

> However, FBDs suffered a severe pushback in our motion products. Our
> graphical motion language, which my clients and I have used very
> productively, is replaced in our newer products by a ladder-based
> instruction set demanded by the customer base!

Hmm, I wonder if it would make sense to make a FBD to RLL compiler. Then it would resemble the early days of high-level languages - the program
is written in COBOL or something, compiled, but then patched in binary so it no longer corresponds to the source.

Here, you'd write the program in FBD, compile it to RLL, which the client would then modify if they wished. You'd program in a sensible
language, the client would have RLL, and everyone would be happy.

FBD to RLL shouldn't be a big problem, just a lot of work. You could even make it produce comments, probably better ones than humans do.

> Further, my larger point was that I don't think RLL works for (future)
> extremely distributed control. I agree with Michael entirely, as long
> as the project resides, at runtime, in a central controller. What I'm
> looking for is a way to graphically manage, say, a button box and a
> starter, both intelligent, with no central intelligence online at
> runtime.

Hmm, that'd be much more challenging, compiling stuff to multiple independent processors like that... Though perhaps not as challenging as it sounds at first sight. Hmm.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
Top