Michael Griffin:
> I don't see much use for an "object oriented ladder logic" language.
> Typical machine control programs are written at such a high level that
> the advantages of object oriented methods are less tangible. A timer
> function (or "class", if you will) is already an inherent part of a
> typical PLC system.

Goodness, it's distressing hearing ladder logic described as "high level"...

Ladder logic typically works very close to the (machine) hardware, perhaps one abstraction level away if the programmer is disciplined. (I'm as guilty of that as the next guy.)

Perhaps the existing abstraction techniques don't fit automation well; I don't know; or else they are not widely known, maybe because they're explained or promoted badly, or not implemented in common programming environments.

One exception seems to be feedback control, for which PID controllers are generally used. But that's a very limited domain...


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

 

> Goodness, it's distressing hearing ladder logic described as "high
> level"...
>
> Ladder logic typically works very close to the (machine) hardware,
> perhaps one abstraction level away if the programmer is disciplined.
> (I'm as guilty of that as the next guy.)
>
> Perhaps the existing abstraction techniques don't fit automation well;
> I don't know; or else they are not widely known, maybe because they're
> explained or promoted badly, or not implemented in common programming
> environments.
>
> One exception seems to be feedback control, for which PID controllers
> are generally used. But that's a very limited domain...

I would suggest that the assertion that RLL works very close to the machine hardware is not so. What it works very closely with is the I/O associated with the hardware. The underlying structure is well hidden from the programmer. The proof of this is that PLC5 code can be run w/o any change on a windows NT machine. The hardware is radically different, but the code is not.

One of the problems with the various languages you seem to be advocating is that they are text based and thus not very easy to follow or debug. RLL (at least in its simpler forms) is graphical in nature and very simple to follow and debug. Its problem is in data handling, which RLL is not all that well suited for anyway.

RLL's biggest failure is in reusability. AB could do the autmation world a BIG favor by finding a way to introduce user programable function block programming in PLC5s and SLCs. Are you listening AB????? The library utilities are helpful, but tedious to use and maintain. A simple way to make your own function blocks would dramatically improve the usability and debugability of PLC5s and SLCs. There is really little difference between a timer block and a user created function block anyway. I do not know why they have chosen not to go down this path. It would seem to me to be such a huge advantage over everything else out there that it would have to be a major competitive advantage.

If a were a cynic, I'd probably suggest at this point that they have this capability (since it would seem to be a relatively simple thing to add) and are not releasing it for some nefarious reason. Likely related to maintaining their bloated marketing force. Think about it - if they had this, it would be such a huge advantage they would no longer need as big a marketing force. Since the marketing dept makes all the technical decisions at AB, they are unlikely to do anything that might reduce that influence. Of course, I would only believe this if I were a cynic.

Bob Peterson

 

At 12:57 15/12/01 +1100, you wrote:
>Jiri Baum:
>> > Ladder logic typically works very close to the (machine) hardware,
>> > perhaps one abstraction level away if the programmer is
>> > disciplined. (I'm as guilty of that as the next guy.)
>
>Bob Peterson:
>> I would suggest that the assertion that RLL works very close to the
>> machine hardware is not so. What it works very closely with is the
>> I/O associated with the hardware.
>
>Sorry, I meant the hardware of the machine it's controlling.

That is, it operates closer to the conception of the application (the machine you want to control) than to the PLC's microprocessor. That makes it a high level language. When you compare it to a language like 'C', you can see that ladder logic is in fact a *very* high level language. I'm not saying it's a good one (I wouldn't say that 'C' is a good one either).

>> The proof of this is that PLC5 code can be run w/o any change on a
>> windows NT machine.
>
>So? The existence of an emulator proves very little. It is a
>fundamental thesis in computer science that anything can emulate
>anything else...
>
>
>In RLL, everything is done directly by turning the outputs on and off
>and there are no mechanisms for encapsulating this. With discipline,
>you can have abstract operations associated with internal coils and
>only set the outputs according to those, but you get no support for
>this from the language.

Portability and reusability are red herrings. These are more issues of good languages versus bad languages. The real question for "high" versus "low" is does the language describe what you want the machine to do, or does it describe how to make the CPU hardware do what you want it to do? When you look at it this way, you can see that even a simple coil instruction (let alone a timer or counter) incorporates a lot of work into a simple instruction. Clearly with ladder logic, you are concentrating on what you want the *machine* to do, rather than on manipulating the microprocessor.
This is the difference between a high or low level language. It is irrelevant as to whether the ladder instructions are interpreted in software, or executed directly in hardware (or micro-code). The real question is whether the language models the application or the computing hardware. You may judge that ladder is a "bad" language by criteria that you define, but that is another issue altogether.

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

 

> I would suggest that the assertion that RLL works very close to the
> machine hardware is not so. What it works very closely with is the
> I/O associated with the hardware. The underlying structure is well
> hidden from the programmer. The proof of this is that PLC5 code can
> be run w/o any change on
> a windows NT machine. The hardware is radically different, but
> the code is
> not.

About ten years ago, I had the privilege of adding some new instructions and rewriting the communications subsystem for an Apache Sentinel (aka Mesabi Mark 5) line controller. The instruction interpreter (the instruction set was essentially text-based ladder instructions), looked dangerously close to microcode to me.

<aside>
The Sentinel was designed in maybe '84 specifically for two piece canmaking machinery. It had two processors, a Motorola 68020 to solve the control logic, and a 68000 to handle I/O. It solved control routines only on discrete I/O changes, which allowed the single line controller to handle a cupping press, a dozen bodymakers, a canwasher, and several other pieces of high-speed equipment. Programmed properly, it had a scan-time of no more than 3 ms. There's still can plants scattered throughout the world that swear by them. </aside>

I'm no S5/S7 expert, but it looks like S5/S7 STL gets very close to the silicon. If you translate Siemens RLL into STL, that too can tell you how thin the layer is.

> RLL's biggest failure is in reusability. AB could do the autmation
> world a BIG favor by finding a way to introduce user programable
> function block programming in PLC5s and SLCs. Are you listening
> AB????? The library utilities are helpful, but tedious to use and
> maintain. A simple way to make
> your own function blocks would dramatically improve the usability and
> debugability of PLC5s and SLCs. There is really little
> difference between a
> timer block and a user created function block anyway. I do not
> know why they
> have chosen not to go down this path. It would seem to me to be
> such a huge
> advantage over everything else out there that it would have to be a major
> competitive advantage.

No doubt, AB's PLC5, SLC500, and Micrologix instruction sets don't help you when trying to re-use code. Rumor has it the ControlLogix family programmed with RSLogix5000, is moving rapidly towards IEC 1131 compliance of some sort. This apparently will have ways of encapsulating and re-using user-written function blocks, which isn't there yet in the current version.

Joseph P. Manns, PE

 

AB RLL is reuseable. With existing programming tools one can cut and paste chunks of code from a "reusable code project" that you can create and paste it into the project that you are working on. Yes, it would be great for AB to supply a library of code - someone needs to call their marketing department and say " lots of money for very little work on AB's part" - and I am sure it would be shortly forthcoming (uh shortly in AB terms can mean years and years...)

 

Michael Griffin:
> That is, it operates closer to the conception of the
>application (the machine you want to control) than to the PLC's
>microprocessor. That makes it a high level language. When you compare
>it to a language like 'C', you can see that ladder logic is in fact a
>*very* high level language. I'm not saying it's a good one (I wouldn't
>say that 'C' is a good one either).

Just FYI, a high level language is: (taken from http://www.webopedia.com/TERM/H/high_level_language.html)
"A programming language such as C, FORTRAN, or Pascal that enables a programmer to write programs that are more or less independent of a particular type of computer. Such languages are considered high-level because they are closer to human languages and further from machine languages. In contrast, assembly languages are considered low-level because they are very close to machine languages.

The main advantage of high-level languages over low-level languages is that they are easier to read, write, and maintain. Ultimately, programs written in a high-level language must be translated into machine language by a compiler or interpreter. "

So C isn't the best example for comparison. If anything ladder is more of a somewhat machine independant (some instructions are portable, some aren't) assembly language with built in types commonly used for automation. The logic behind most of those types is in fact very simple. A few instructions each.

Richard Higginbotham

 

Grayg Ralphsnyder:
> AB RLL is reuseable. With existing programming tools one can cut and
> paste chunks of code from a "reusable code project" that you can
> create and paste it into the project that you are working on.

!!

> Yes, it would be great for AB to supply a library of code - someone
> needs to call their marketing department and say " lots of money for
> very little work on AB's part"

You underestimate it - initially, to make a good general-purpose library requires quite a bit of design, and ongoing, it has to be supported.


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

 

Joseph P. Manns, PE:
> About ten years ago, I had the privilege of adding some new
> instructions and rewriting the communications subsystem for an Apache
> Sentinel (aka Mesabi Mark 5) line controller. The instruction
> interpreter (the instruction set was essentially text-based ladder
> instructions), looked dangerously close to microcode to me.

Precisely.

As far as these definitions are concerned, the machine being controlled should be considered a peripherial, just like the keyboard or a printer. Consider the abstraction provided by those - the OS demultiplexes keys and translates them (and their combinations) into characters, ready to use.

Obviously, some amount of low-level work is unavoidable, because each machine is different; but that should be confined to designated `low-level' parts of the program, and the confinement should be enforced by the language and/or the OS.


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

 

Actually, we are trying to accomplish something similar to this with the "PLC Archive", but for any and all models of PLC. If anyone has any useful code blocks, fragments, or examples they would like to contribute, the address is:

"http://www.control.com/PLCArchive":http://www.control.com/PLCArchive

The files are all in PDF format, and so don't require any special software to view them. If you want to contribute something, there is free software available on the internet to create PDF files. I can repeat my previous description of how to do this for anyone who may have missed it the first time. It is really very simple, and it won't cost you anything.
I believe the archive administrator would welcome submissions from any and all sources. I would suppose that these need not be limited to PLC code either. Useful relevant computer code (VB, C, etc.) or other sorts of information would be welcome. Submissions of course, should be by the author or with the author's permission. The archive administrator can correct me on any of these points if I am wrong.
We get plenty of requests on this list for code samples which illustrate some particular point or simply provide a general example. It would be nice if these could be contributed to the archive and so provide a first point of reference for these questions when they arise again. In return for a small bit of effort, your reward is undying fame and the gratitude of generations yet to come.

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

 

At 10:56 17/12/01 -0600, Joseph P. Manns, PE wrote:
<clip>
>The Sentinel was designed in maybe '84 specifically for two piece
>canmaking machinery. It had two processors, a Motorola 68020 to solve
>the control logic, and a 68000 to handle I/O. It solved control
>routines only on discrete I/O changes, which allowed the single line
>controller to handle a cupping press, a dozen bodymakers, a canwasher,
>and several other pieces of high-speed equipment. Programmed properly,
>it had a scan-time of no more than 3 ms. There's still can plants
>scattered throughout the world that swear by them.
<clip>

This sounds like it must have been an interesting project to work on. I have always fascinated by unusual hardware (as long as I don't have to fix it of course!). I've worked with high speed equipment of similar vintage which was programmed by wire wrap connections between logic chips. This is about as "low level" as you can get. I was never really tempted to try any major re-programming of these systems. The "Sentinel" sounds a little friendlier to work with.

>I'm no S5/S7 expert, but it looks like S5/S7 STL gets very close to the
>silicon. If you translate Siemens RLL into STL, that too can tell you
>how thin the layer is.
<clip>

S5 STL even more so than S7 (keeping in mind there are two completely separate and very different families of S7). The binary codes for S5 are called "M" codes and are documented in the Siemens manuals. Some S5 CPUs simply interpret M code in software, while others have an M code chip
(co-processor) which will execute certain instructions in hardware. In this sense, the STL can be considered the assembly language for an S5 series CPU.
This was not unique either. The early AB PLC/2 CPUs (e.g. PLC-2/15,
PLC-2/30) used bit slice processors (AMD 2901 I think?) to execute ladder instructions.

The following is more a general reply to the discussion taking place than to your particular comments, but I thought this was a convenient place to do so.

We can get tied up in knots trying to draw a strict line between high and low level languages. There really isn't one. Some people have proposed a "portability test", where if a language is portable then it is "high level", and if it is not portable, then it is "low level". This is perhaps close to the mark, but not for the reasons stated.

I think the simplest rule is to ask if the syntax and structure of the language models the application problem domain, or whether it describes the computing system. If the former, I would call it high level, and if the latter, then low level. The aformentioned "portability test" invokes this rule indirectly by making the assumption that if a language describes the computing system, then applications written it it are unlikely to be portable.
Under the rule outlined above, S5 STL would be a "low level" language, because a program written in it is at least as much a description of the computing system (the S5 CPU architecture) as it is a description of the application being solved. A program written in S5 Ladder though, is primarily concerned with the application problem, and much less so with the computing system.
If you doubt that this distinction exists, then consider the following. If you were to be presented with a list of S5 STL instructions along with their definitions, you could come up with a fairly clear description of the S5 system architecture including accumulators (ACCU1, ACCU2), condition codes (CC0, CC1), and the logic stack (RLO). If you were however presented with a list of ladder instructions, you would be unable to make a similar description to the same degree of detail.

The fact that the ladder language does not have a detailed description of the particular computing system built into it is what makes it more portable. The portability however, is a side effect of it being "high level".

If I had to construct a hierarchy of PLC languages, I would list them as follows:

STL - Low level - equivalent to assembly language.
Ladder, or Structured Text - High level.
SFC (Grafcet), State Logic, Flow Charts - Very high level.

The difference between "high level" and "very high level" languages is more a matter of degree than of kind. These methods incorporate more assumptions about the application domain into their overall structure and syntax which tends to make them more concise, but less flexible. If the language is applied in the intended domain this loss of flexibility is of no consequence, and indeed may actually be an advantage in helping to ensure the problem is stated more clearly.


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

 

Michael Griffin:
> If I had to construct a hierarchy of PLC languages, I would list them
> as
> follows:

> STL - Low level - equivalent to assembly language.
> Ladder, or Structured Text - High level.
> SFC (Grafcet), State Logic, Flow Charts - Very high level.

Agreed. (I'd probably use `low', `medium' and `high', but same thing.)

> These methods incorporate more assumptions about the application
> domain into their overall structure and syntax which tends to make
> them more concise, but less flexible.

Indeed they do - which might be why general-purpose software engineering techniques haven't had much impact in the automation world. Designed for a different domain, they are ill-suited to this one.


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

 

Jiri wrote:

>Indeed they do - which might be why general-purpose software engineering techniques haven't had much impact in the automation world. Designed for a different domain, they are ill-suited to this one.<

Jiri,

This has actually been somewhat dissapointing for me. I have always thought that object orientation would be a perfect fit in automation. By making each discreet device (air cylinder, motor, or whatever) an object, and describing it with code, you could expose methods like
Air_Cylinder_1.Extend() and have the extend method do the error checking, etc.

This is obviously not ideal in ladder logic, but do you think it may take off once IEC 1131 gets rolling? Does anyone else have opinions on this? I could see this being very conducive to code re-use, etc.

Anyone have any opinions? ( <-- There is as loaded question!)

--Joe Jansen

 

Joe:
>This has actually been somewhat dissapointing for me. I have always thought that object orientation would be a perfect fit in automation. By making each discreet device (air cylinder, motor, or whatever) an object, and describing it with code, you could expose methods like Air_Cylinder_1.Extend() and have the extend method do the error checking, etc.<

Shahid:
Indeed, this concept is partially used through the implementation of the Function block (An object is used multiple times as required just by calling and passing different parameters, eg 20 motors call same MOTOR Block). However, the code is written/developed only once!

What I would really like to see (and work) is the idea of "Operator Overloading" where for example a Centrifugal Pump can inherit its properties from its parent: PUMP [Class or Block] and then add its own special functionality to this. Some of the Advance Process Control vendor are already dealing in this area (like Gensym, and I am sure there are other), but this should come more to the main stream Controller/PLC/DCS (like AB, Schneider, Siemens etc). Those who are already using some form of programming languages other than LADDER are already experimenting with this idea but the IEC would really bring all together (hopefully).

Shahid

 

At 13:35 20/12/01 -0500, Joe Jansen wrote:
<clip>
>This has actually been somewhat dissapointing for me. I have always
>thought that object orientation would be a perfect fit in automation.
>By making each discreet device (air cylinder, motor, or whatever) an
>object, and describing it with code, you could expose methods like
>Air_Cylinder_1.Extend() and have the extend method do the error
>checking, etc.

I suspect the reason you haven't seen it is because the problems object orientation solves aren't the ones the people in this business are most concerned about. I think you answered your own question by the fact that you had a hard time coming up with a really worth while example to illustrate your point.
The perceived need has been less one of how do deal with small local problems, than how to integrate and coordinate the various functions. There
*has* been a lot of development along the lines of SFC, State, Flowcharts, etc.


>This is obviously not ideal in ladder logic, but do you think it may
>take off once IEC 1131 gets rolling? Does anyone else have opinions on
>this? I could see this being very conducive to code re-use, etc.
<clip>
I don't see what IEC61131 would have to do with it - it isn't in the standard in any of the IEC languages that I am aware of. However, if people do feel there is a benefit to it, I don't see why it would be any more difficult to implement in ladder than in any other language. Methods would simply be functions or function calls. Instantiation would be done as the program is entered into the programming software (i.e. statically rather than dynamically).
One very simple way of doing this would be via a mechanism similar to Modula-2 opaque types. I think that a company such as Siemens could implement this in Step-7 with relatively minor changes to the programming software.
People have done object oriented computer programming with conventional computer programming languages. You just don't get inheritance or operator overloading and you don't have the compiler enforcing the rules. You could use object oriented design and programming in ladder logic today (at least with some PLCs) provided you don't mind living within the same restrictions.


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

 

True object based software is dynamic, intelligent and aware.

A true object will have a string if attributes attached to it, attributes that are assigned depending on the environment in which it is placed, the ability to use these attributes to satisfy the conditions of the environment in which it's placed, the ability to "know" its place within that environment, the ability to gain "knowledge" by knowing its place within that environment.

Collections of objects within a structure will develop knowledge of that structure, leading to a gaining of further knowledge - automatically.

True object based software is the next wave.

Bob Pawley

 

Back in 1996 I was programming user defined function blocks on Siemens PLCs. Why AB haven't implemented this is a mystery, but wouldn't
constitute a competative advantage.