Why program with high level programming languages? (was PLCS: PLC Fortran)

B

Brian E Boothe

i'm not saying LL isnt usefull.... it is for its specific purpose.. but actually calling it a actual LANGUAGE is a bit far for me. user's AID
maybe..
 
Interpreter v. Compiler is determined by when the program is converted to machine level instructions. A compiler converts the program code into the machine instructions, which is then used as a binary distribution. Characterized by a faster execution than interpreted language.

Interpreted means that the program code is converted into machine instruction during execution of the program. This obviously takes longer to execute, but is much easier to debug. It has nothing to do with translating when used in this context.

I do not understand your reference to eic. I am familiar with their product, and it is just what it claims: a package that lets you run
interpreted C programs. Meaning that the code is not compiled before execution. In fact, at their command prompt, you can enter C program lines and have them execute immediately, similar to using a python or basic interpreter in immediate mode.

IFAIK, most PLC's run as interpreted, not compiled, language. This gives the ability to do online monitoring and editing without having to compile the edits into the code all the time.

--Joe Jansen
 
C
Actually it's not uncommon to do both with the same system. The human usable language is compiled to an intermediate language which is then interpreted at runtime. The advantage of doing this is that the IL can be readily and unambiguously decompiled to perform the feats of
magic with online editing, etc. The interpreter can be optimized for the specific finite IL. With today's optimizing compilers, decompiling often
does not yield recognizable source code if it's possible at all.

Regards

cww Who is not a Computer Scientist, just an old UNIX hacker.
--
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.
 
V

Vladimir E. Zyubin

1. Again. Language is a set of specific rules. There is no demand to be neither interpreted nor compiled among the rules.

2. I refer to eic in order to demonstrate the fact that C is not a "compiled language"... as well as I refer to the ladder compilers in order to demonstrate, ladder is not an "interpreted language"...

3. Really our case is an example of terminological muddle... between "language" and "language translator", it execution model... (For example: If we say "Borland C++ 4.0", we really speak about the compiler, not about the C++ language)

etc.

Thanks. Vladimir.
 
B

Bram van Kampen

Well, different horses for different courses. Ladder type languages are fine where abstraction requirements are relatively low, and where there is an installed base to work on, compatible with the target hardware.

if you are reading this on a computer with a GUI, realise that this GUI is based on many millions of lines of Code. This Code was likely written in C or CPP, with a spattering of assembly. Ladder Logic is also a High level language, the processor that runs the code could not possibly understand the diagrams you create. There is an interpretor or compiler involved there.

Had Bill Gates written in ladder logic, that would probably have been the language I earn my bread in now. As it happens, for better or worse, I write windows in CPP to provide the bread, and ladder logic in evening hours, to provide the jam.
 
B

Bram van Kampen

Well, different horses for different courses. Ladder type languages are fine where abstraction requirements are relatively low, and where there is an installed base to work on, compatible with the target hardware. if you are reading this on a computer with a GUI, realise that this GUI is based on many millions of lines of Code. This Code was likely written in C or CPP, with a spattering of assembly. Ladder Logic is also a High level language, the processor that runs the code could not possibly understand the diagrams you create. There is an interpretor or compiler involved there. Had Bill Gates written in ladder logic, that would probably have been the language I earn my bread in now. As it happens, for better or worse, I write windows in CPP to provide the bread, and ladder logic in evening hours, to provide the jam.
 
B

Bob Peterson

This is an interesting question. IMHO, you should use the "highest" level programming language that best meets your needs.

People have different ideas about what this term even means. I suppose the "lowest" level programming language is machine code. No one would even consider programming in such a language today except maybe as an educational
exercise. With respect to machine code, even assembler is a higher level language (than machine code).

Higher level languages shield you from many of the details required to write code such as:

- mapping physical memory locations to variable names
- allowing you to use a symbolic variable name rather then just an address to refer to your data
- standardized I/O access
- standardized function set(s)

Imagine if you had to write the machine code for all the things that printf() does for you already. You would not be real efficient in generating code.

Others may decide that "higher" level languages must have other attributes. This is sort of a "how many angels can dance on a pin head" type question because its really related to what it is you are trying to do.

There are a few on this list who don't deal well with RLL and think text based languages are "higher" level. But for the purposes RLL is used, its almost always a far better choice. The main reasons do not have anything to do with programmer productivity as you might initially suspect. The biggest thing RLL has going for it is the huge number of people who understand enough about it to be able to do debugging and minor program changes at the factory floor. This translates in higher uptime, productivity, and profitability, which is what its all about. Programming costs for many systems are such a
tiny part of the cost of the system that programming costs themselves are really not all that significant..

Think about it for a while and you will almost certainly agree. A typical system I work on has maybe 600 hours of electrical engineering time in it. I'd guess the time spent is roughly about 1/4 hardware related (BOMs, drawings, etc), 1/4 defining how the stuff works, 1/4 actual programming, and 1/4 debug and testing. So I have only spent 150 hours on actual programming,
say about $10,000. On a typical $1,000,000 system this is about 1%.

However, its not unusual for a machine to cost that much (or far more) worth of production per MINUTE when it is down. Therefore, its far more important to be able to keep the machine running, and be able to debug problems faster, than worrying over saving a few $ in programming time.

Bob Peterson
 
B

Brian E Boothe

Simple answer is outside of the Box solutions, typical answers would be Passing TCP/IP packets,
Active-x Control's / OPC-DDE / Trending / memory management / CPU optimization / switching of printers
Data collection / DBF Routines /..cross platform development Linux > MAC > PC ect
I dont think the person that asks that question really has a Programmers Thought pattern..
Ladder logic has one SET Purpose. (CONTAINED Instructions). for the Controller...such as RS-LOGIX on the other hand High level languages Move across MANY MANY platforms and Processors..
ive been hearing this question alot?... why in gods name would someone ask such a question... you cant do ANY of the above in Ladder
logic?? i'm really not understanding this question??..
 
B

Blunier, Mark

> > > hello, i'm writing in just to enquire something. why does someone
> > > need to program with high level programming languages? is it
> > > easier? faster? less debugging time? or some other reasons?
>
> This is an interesting question. IMHO, you should use the "highest"
> level programming language that best meets your needs.

While you should use the programming language the best meets your needs, if it is a tie, use the lowest level, not the highest level language.
Fox example, almost any program written in C could be written in C++, but if the complexities of C++ is not needed, and many more people can program in C that can't use C++, C would be prefereable.

Mark Blunier
Any opinions expressed in this message are not necessarily those of the company
 
B

Bob Peterson

Brian Boothe wrote:
> Simple answer is outside of the Box solutions, typical answers would be
> Passing TCP/IP packets, Active-x Control's / OPC-DDE / Trending / memory
> management / CPU optimization / switching of printers
> Data collection / DBF Routines /..cross platform development Linux > MAC
> > PC ect

The simple answer you gave does not deal with reality very well. Few lower level control systems need (or even use) the kinds of things you talk about. These are not really machine control issues but more like SCADA. They are
all nice to have, and even important, but don't have anything to do with machine control directly.

> dont think the person that asks that question really has a Programmers
> Thought pattern..

I don't think in terms of C for doing things that work best in RLL. Despite what you might think, RLL is extremely powerful for solving certain types of common control problems. It does not deal well with numerical or data driven
applications. But these are not the most common control applications. Look at how many PLCs are sold world wide versus how many control applications are done in C. That SHOULD tell you something.

> ladder logic has one SET Purpose. (CONTAINED Instructions). for the
> Controller...such as RS-LOGIX
> on the other hand High level languages Move across MANY MANY platforms
> and Processors..
> ive been hearing this question alot... why in gods name would
> someone ask such a question... you cant do ANY of the above in Ladder
> logic?? i'm really not understanding this question??..

Quite frankly, people that like text based languages just refuse to deal with the issue of uptime, online programming, and other PLC features designed to keep your factory producing widgets. The built-in and intuitive diagnostics
available with RLL that just don't exist with "higher" level languages. These are the main reasons (IMHO) that RLL refuses to die. Nothing that has tried to replace it does it any better, or typically even as well. There are
some things available that MAY improve programmer productivity, but this is such a small part of most systems that a little increase in productivity is dwarfed by the ongoing cost of keeping the machine going for the next 20 years.

Bob Peterson
 
M

Michael Griffin

Ladder logic is a *very* high level language, certainly much higher level than 'C++' or other similar languages. Very high level languages tend to be application specific, which is why ladder logic is good at what it is intended for, but not very good for general computing use.

Langauges such as grafcet are even higher level still, which is why they are even better still for an even narrower range of applications, but are not able to easily replace everything that ladder does well.

I believe it was Nicolas Wirth (the creator of Pascal, among other things) who said that programming languages are created for people to read, not for computers. A programming language, and a program written in it, should be judged by how well the intended audience is able to read and comprehend it.

I learned a long time ago that it is very easy to write complex programs. Writing simple ones is the real challenge.

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

Vladimir E. Zyubin

Hello Michael,

On Wednesday, June 05, 2002, 9:37:49 AM, Michael Griffin wrote:
[...]
MG> Ladder logic is a *very* high level language, certainly much higher level
MG> than 'C++' or other similar languages. Very high level languages tend to be
MG> application specific, which is why ladder logic is good at what it is
MG> intended for, but not very good for general computing use.
MG> Langauges such as grafcet are even higher level still, which is why they are
MG> even better still for an even narrower range of applications, but are not
MG> able to easily replace everything that ladder does well.

High level language is that reflects the human side of HMI (HMI in the broad means)
Low level language is that reflecs the machine side of HMI...

Also there is the following classification of the languages:

1. first generation languages (example - machine code)
"http://www.InstantWeb.com/D/dictionary/foldoc.cgi?first+generation+language":http://www.InstantWeb.com/D/dictionary/foldoc.cgi?first+generation+language

2. second generation languages (example - assemblers)
"http://www.InstantWeb.com/D/dictionary/foldoc.cgi?query=second+generation+language":http://www.InstantWeb.com/D/dictionary/foldoc.cgi?query=second+generation+language

3. third generation languages ("common purpose languages", example - C, Pascal, Fortran, etc., etc.)
"http://www.InstantWeb.com/D/dictionary/foldoc.cgi?third+generation+language":http://www.InstantWeb.com/D/dictionary/foldoc.cgi?third+generation+language

4. fourth generation languages ("application specific", example - SQL; Focus, Metafont, PostScript, RPG-II, S, etc.)
"http://www.InstantWeb.com/D/dictionary/foldoc.cgi?fourth+generation+language":http://www.InstantWeb.com/D/dictionary/foldoc.cgi?fourth+generation+language

5. fifth generation languages ("AI languages", "a mith", example - no implemented yet)
"http://www.InstantWeb.com/D/dictionary/foldoc.cgi?fifth+generation+language":http://www.InstantWeb.com/D/dictionary/foldoc.cgi?fifth+generation+language

LD is a low level fourth generation language.

"Low level" - because it has no means to structurize the program, "Fourth generation" - because it is a "application specific" language,
i.e. it has limited capabilities.

--
Best regards,
Vladimir mailto:[email protected]
 
R

Richard Higginbotham

Bob Peterson wrote:

>The simple answer you gave does not deal with reality very well. Few
>lower level control systems need (or even use) the kinds of things you
>talk about. These are not really machine control issues but more like
>SCADA. They are all nice to have, and even important, but don't have
>anything to do with machine control directly.

He left out code reuse, up time, dev. time, and a few others that apply, but that is yet another rehash of this old topic (which has been around since before C was the next big thing).

>I don't think in terms of C for doing things that work best in RLL.
>Despite what you might think, RLL is extremely powerful for solving
>certain types of common control problems. It does not deal well with
>numerical or data driven applications. But these are not the most
>common control applications. Look at how many PLCs are sold world wide
>versus how many control applications are done in C. That SHOULD tell
>you something.

Yes, that you should never expect to get a nice juicy steak, you should give up, conform to the norm and head down to McDondalds (over a billion served) because thats what most people like. Planning a big event, Wedding Reception maybe, it doesn't really matter if your situation is different. If you want something special just ask for extra cheese on all those Big Macs. You just dont get it, lots of people eat at McDonalds, there CANT be anything better and if there is, well, it really just doesn't apply.</sarcasm>

>Quite frankly, people that like text based languages just refuse to deal
>with the issue of uptime, online programming, and other PLC features
>designed to keep your factory producing widgets. The built-in and
>intuitive diagnostics available with RLL that just don't exist with
>"higher" level languages. These are the main reasons (IMHO) that RLL
>refuses to die. Nothing that has tried to replace it does it any
>better, or typically even as well. There are some things available that

Because they realise those feature have nothing to do with ladder logic. RLL has its own syntax and repersentation (graphic) thats not particularly special. You can write out RLL as text ( and others like SFC, etc.). Compile and download it to controllers, been done since the 80's man. RLL is nothing more than a pared down "text" base language used so unskilled (non-programmer) Joe Billy Bob Blow has some hope of getting a software program to work... eventually.

Its logic along the lines of: I don't design bridges for a living. Dont know whats involved, or even how to start. BUT I do know how to make some neat stuff with legos. Legos are easy, anyone can use legos. Let me build your new bridge out of legos. You'll save time and money because so many people know how to use legos. If bridge collapses, you dont have to worry about the design, we'll just throw on some more legos. Some people think legos are unsuitible to building skyscrapers because of the complexity of skyscrapers, but they're wrong because legos are so easy to use, anyone can use them. They were designed for children after all.

>MAY improve programmer productivity, but this is such a small part of
>most systems that a little increase in productivity is dwarfed by the
>ongoing cost of keeping the machine going for the next 20 years.

Ahh, this is where I talk about code reuse, and you reply "what, i've been cutting and pasting for years." If you have the luxury of just having that machine "run" for the next 20 years, consider yourself lucky. Everywhere I've been, its constant upgrades, additions, change in control philosophy, etc. There are so many oppertunities to do more with less, reduce chances of human error, reduce down time, reduce development time, it boggles the mind that theres resistance to a proven way of solving the same old problems. Sure there are differences between batch control and web development, but thats no excuse not to learn from outside the box and apply those things that are relevant and helpful.

Sometimes when you design things to account for the lowest common denominator, you get stuff designed BY the lowest common denominator.

Richard Higginbotham
speaking for me
 
Top