Control.com - Nerds in Control
from the None department...
Why program with high level programming languages? (was PLCS: PLC Fortran)
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?
why does someone need to program with high level programming languages? is it easier? faster? less debugging time? or some other reasons?
Higher level languages generally are faster to write and easier to debug. Normally there is a performance trade-off; high-level languages like Java, Basic, and LISP go through some kind of interpreter that costs time. A mid-level language like C runs circles around these, but you have to do your own memory allocation and clean-up.
At the lowest level, assembly language is as fast as you can get, but is very difficult to program in. (Of course, a bad assembly programmer might end up with code that runs slower than a good C programmer's optimized code). Ladder logic is a very, very high-level language; you are completely isolated from the underlying architecture, there is no memory managment and rarely any file management. (Don't confuse file management with the Allen-Bradley "files"; file is really a misnomer in this case. They are really much closer to memory areas than files.)
For example, you could write a ladder logic interpretter in C, but it is impossible to write a C compiler in ladder logic. This is an acid test for determining whether a language is "high-level" or "low-level."
-James
Sage Automation, Inc.
At the lowest level, assembly language is as fast as you can get, but is very difficult to program in. (Of course, a bad assembly programmer might end up with code that runs slower than a good C programmer's optimized code). Ladder logic is a very, very high-level language; you are completely isolated from the underlying architecture, there is no memory managment and rarely any file management. (Don't confuse file management with the Allen-Bradley "files"; file is really a misnomer in this case. They are really much closer to memory areas than files.)
For example, you could write a ladder logic interpretter in C, but it is impossible to write a C compiler in ladder logic. This is an acid test for determining whether a language is "high-level" or "low-level."
-James
Sage Automation, Inc.
Please don't take this as a flame, but we generally don't consider (computer scientists being we) ladder logic to be a high level language. It is actually on a par with assembler, with the exception of some fancy function blocks added later to the original language.
If the inability to write a compiler in the high level language is the test, here are a couple of thoughts:
ADA can be used to write cross-assemblers. Would it be a low level language?
My hand held calculator (OK, actually none of my calculators are this stupid, but let's say I got one in a box of breakfast cereal) can't be used to write a compiler. Is it a high level language?
The "acid test" makes it seem that anything of limited capability is a higher level.
In computer science, we tend to define languages by the "generation." The determining factors are platform independence, specific memory structure independence, strenght of typing, scoping of variables, flexibility of parameter passing, protection of code integrity, etc.
Otherwise, I totally agree with the below. You make a very good observation about optimizing compilers. This may not still be the case, but there was a day when you could take an optimized Waterloo FORTRAN compiler and have it smoke most assembly language programmers, whether optimized for speed or code size. Nowadays, sadly, the processors are so fast and memory so cheap that the real programmers are a dying breed.
George G. Robertson, P.E.
Manager of Engineering
Saulsbury E & C
grobertson@si-tx.com
(915) 366-4252
If the inability to write a compiler in the high level language is the test, here are a couple of thoughts:
ADA can be used to write cross-assemblers. Would it be a low level language?
My hand held calculator (OK, actually none of my calculators are this stupid, but let's say I got one in a box of breakfast cereal) can't be used to write a compiler. Is it a high level language?
The "acid test" makes it seem that anything of limited capability is a higher level.
In computer science, we tend to define languages by the "generation." The determining factors are platform independence, specific memory structure independence, strenght of typing, scoping of variables, flexibility of parameter passing, protection of code integrity, etc.
Otherwise, I totally agree with the below. You make a very good observation about optimizing compilers. This may not still be the case, but there was a day when you could take an optimized Waterloo FORTRAN compiler and have it smoke most assembly language programmers, whether optimized for speed or code size. Nowadays, sadly, the processors are so fast and memory so cheap that the real programmers are a dying breed.
George G. Robertson, P.E.
Manager of Engineering
Saulsbury E & C
grobertson@si-tx.com
(915) 366-4252
> Please don't take this as a flame, but we
> generally don't consider (computer scientists
> being we) ladder logic to be a high level
> language. It is actually on a par with
> assembler, with the exception of some fancy
> function blocks added later to the original
> language.
I respectfully diagree - having done quite a bit of programming in C, assembly, VB, and LL. Perhaps I am thinking from a code production point of view, but I would rank a language's level based on how much work it saves the programmer. Perhaps the most common operation in LL is the single bit test. In LL it's just one statement. In assembly you have to OR the word against a mask and check the CPU non-zero bit if the CPU supports it, or if not, you have to do an additonal comparrison. The programmer has to figure out the bit mask for each bit that is tested, quite a bit of work on his part if its a large system. It is just one instruction in LL with a simple bit designation method, that makes it a fairly high level language. The graphical program development environment for most PLCs is also rather sophisticated when compared to the traditional programming environment (text editor and compiler).
Please don't confuse the availabilty of a large library of functions (such as in C) for a language level. LL is a quite ridgid and unflexibible language when compared to the likes of C but that also in no way means it is "low level." The IEC-61131 tried to address the cross platform compatibility issue, but not too successfully.
It does provide some freedom from being tied to a specific memory structure (varies in degree by PLC brand), allowes scoped variables, and parameter passing. LL has some shortcoming, but it is still a living, evolving language (as opposed to FORTRAN, Pascal, et al), and I would rather use it for online debugging of an operating piece of machinery than any other language.
> generally don't consider (computer scientists
> being we) ladder logic to be a high level
> language. It is actually on a par with
> assembler, with the exception of some fancy
> function blocks added later to the original
> language.
I respectfully diagree - having done quite a bit of programming in C, assembly, VB, and LL. Perhaps I am thinking from a code production point of view, but I would rank a language's level based on how much work it saves the programmer. Perhaps the most common operation in LL is the single bit test. In LL it's just one statement. In assembly you have to OR the word against a mask and check the CPU non-zero bit if the CPU supports it, or if not, you have to do an additonal comparrison. The programmer has to figure out the bit mask for each bit that is tested, quite a bit of work on his part if its a large system. It is just one instruction in LL with a simple bit designation method, that makes it a fairly high level language. The graphical program development environment for most PLCs is also rather sophisticated when compared to the traditional programming environment (text editor and compiler).
Please don't confuse the availabilty of a large library of functions (such as in C) for a language level. LL is a quite ridgid and unflexibible language when compared to the likes of C but that also in no way means it is "low level." The IEC-61131 tried to address the cross platform compatibility issue, but not too successfully.
It does provide some freedom from being tied to a specific memory structure (varies in degree by PLC brand), allowes scoped variables, and parameter passing. LL has some shortcoming, but it is still a living, evolving language (as opposed to FORTRAN, Pascal, et al), and I would rather use it for online debugging of an operating piece of machinery than any other language.
If LL is High level, write some string processing, communications parsing, sequencing with multiple possible sequences, historical
logging, advanced process control, and operator interface routines in it.
Bit testing is easy in other HLLs if the functions are in the library.
(Now the gloves are coming off!)
George G. Robertson, P.E.
Manager of Engineering
Saulsbury E & C
grobertson@si-tx.com
(915) 366-4252
logging, advanced process control, and operator interface routines in it.
Bit testing is easy in other HLLs if the functions are in the library.
(Now the gloves are coming off!)
George G. Robertson, P.E.
Manager of Engineering
Saulsbury E & C
grobertson@si-tx.com
(915) 366-4252
OK, try this. Pick your language of choice, then write a ready to execute program that takes the third bit from one 16 bit data word, tests it to be set and if it is then set the seventh bit in a different data word without changing any other bit in that word. Spend less than 15 seconds designing your program and have the program ready to execute in less than 30 seconds from the time you begin typing. Ready, set, go.
One of the reasons we have multiple languages is that each is suited to doing different things. LL excels at bit logic. I would of course never dream of parsing a string with LL. But then I don't need to parse a long string to control say a
packaging machine for example, so your comparrison fails on that point because its out of the scope of application. (LL however isn't really all that bad at short string comparrisons thay you may need to do for RS232 instrument communications)
Most PLCs use 16 or 32 bit processors, which of course means they work with 16 or 32 bit words. LL language takes care of the bit level access for you, saving you huge ammounts of work and the trouble of developing bit masks for all your desired IO cominations. The above example's solution is a PLC program that looks something
like XIC B3/2 OTE B3/22 for an AB PLC. If it was converted to assembly there would be considerably more typing to do and you would have to develop a bit mask for your test and a bit mask to write your result. In C there would be almost as many
characters typed before you even began production on useful code.
(int i,o,/r/nmain{}) <-DOESNT DO ANYTHING YET!
LL was never intended for word processing and its advocates dont pretend that it ever was. But its foes so often find that as a fault. Its intent was to provide a easy to use language that saved huge ammounts of work in writing bit logic programs. Within that scope, it certianly meets the criteria to qualify as a higher level language. Sometimes the simple can be elegant and advanced.
One of the reasons we have multiple languages is that each is suited to doing different things. LL excels at bit logic. I would of course never dream of parsing a string with LL. But then I don't need to parse a long string to control say a
packaging machine for example, so your comparrison fails on that point because its out of the scope of application. (LL however isn't really all that bad at short string comparrisons thay you may need to do for RS232 instrument communications)
Most PLCs use 16 or 32 bit processors, which of course means they work with 16 or 32 bit words. LL language takes care of the bit level access for you, saving you huge ammounts of work and the trouble of developing bit masks for all your desired IO cominations. The above example's solution is a PLC program that looks something
like XIC B3/2 OTE B3/22 for an AB PLC. If it was converted to assembly there would be considerably more typing to do and you would have to develop a bit mask for your test and a bit mask to write your result. In C there would be almost as many
characters typed before you even began production on useful code.
(int i,o,/r/nmain{}) <-DOESNT DO ANYTHING YET!
LL was never intended for word processing and its advocates dont pretend that it ever was. But its foes so often find that as a fault. Its intent was to provide a easy to use language that saved huge ammounts of work in writing bit logic programs. Within that scope, it certianly meets the criteria to qualify as a higher level language. Sometimes the simple can be elegant and advanced.
> From: T. Connolly
>
> OK, try this. Pick your language of choice, then write a ready to
> execute program that takes the third bit from one 16 bit data word, tests
> it to be set and if it is then set the seventh bit in a different data
> word without changing any other bit in that word. Spend less than 15
> seconds designing your program and have the program ready to execute in
> less than 30 seconds from the time you begin typing. Ready, set, go.
No Problem. In _my_ LPLC (distinct fron the MAT/LPLC project) that becomes:
if(iX)qY else cqY;
Every language (that I know of) gives you logic operators. And coding the logic, in and of itself is simple. But it's nothing magical or even very
clever to hide all the details so all the user has to worry about is logic.
Now I've got one for you. Take a couple different cranky old NC lathes, (customer's choice) a measuring instrument (also customer's choice) a
couple different green screen terminals, one with an attached serial printer and let's throw in a barcode reader (customers choice). You get
$ 1000.00 for new hardware. The idea is to read a barcode, measure the part, factor in the measurement and upload the proper part programs to the lathes and diaplay and log the results. Show and tell is the day after tomorrow. Try not to write more than a couple pages of code.
> One of the reasons we have multiple languages is that each is suited to
> doing different things. LL excels at bit logic. I would of course never
> dream of parsing a string with LL. But then I don't need to parse a long
> string to control say a packaging machine for example, so your
> comparrison fails on that point because its out of the scope of
> application. (LL however isn't really all that bad at short string
> comparrisons thay you may need to do for RS232 instrument communications)
>
> Most PLCs use 16 or 32 bit processors, which of course means they work
> with 16 or 32 bit words. LL language takes care of the bit level access
> for you, saving you huge ammounts of work and the trouble of developing
> bit masks for all your desired IO cominations. The above example's
> solution is a PLC program that lookes something like XIC B3/2 OTE B3/22
> for an AB PLC. If it was converted to assembly there would be
> considerably more typing to do and you would have to develop a bit mask
> for your test and a bit mask to write your result. In C there would be
> almost as many characters typed before you even began production on
> useful code. (int i,o,/r/nmain{}) <-DOESNT DO ANYTHING YET!
That's a bit unfair, you get software on the PLC. If you have the framework built, which happens only once on either, all you have to do is code the logic. This looks to be about the same length in your example and mine. Mine is even a bit more human readable IMHO but that's largely a matter
of taste. And we both have to relate the bits to I/O at some point.
> LL was never inteneded for word processing and its advocates dont pretend
> that it ever was. But its foes so often find that as a fault. Its
> intent was to provide a easy to use language that saved huge ammounts of
> work in writing bit logic programs. Within that scope, it certianly
> meets the criteria to qualify as a higher level language. Sometimes the
> simple can be elegant and advanced.
I wouldn't argue that LL isn't a high level language since you can have some powerful functions. I would argue that a lot of real world tasks are much more than bit logic and mapping them to the relay model gets very ugly and expensive. I think the optimal solution should offer good tools for logic solving, including LL and much better tools for the rest of the
solution. As wide an array of tools as possible for the many problems encountered. Having C and Fortran and ncurses and sockets and scripting
and a serious database and every other tool you might need without reaching for the credit card, you can handle just about anything. The right tool for the job and all the tools in one box. I still wouldn't use Fortran again.
Regards
cww
>
> OK, try this. Pick your language of choice, then write a ready to
> execute program that takes the third bit from one 16 bit data word, tests
> it to be set and if it is then set the seventh bit in a different data
> word without changing any other bit in that word. Spend less than 15
> seconds designing your program and have the program ready to execute in
> less than 30 seconds from the time you begin typing. Ready, set, go.
No Problem. In _my_ LPLC (distinct fron the MAT/LPLC project) that becomes:
if(iX)qY else cqY;
Every language (that I know of) gives you logic operators. And coding the logic, in and of itself is simple. But it's nothing magical or even very
clever to hide all the details so all the user has to worry about is logic.
Now I've got one for you. Take a couple different cranky old NC lathes, (customer's choice) a measuring instrument (also customer's choice) a
couple different green screen terminals, one with an attached serial printer and let's throw in a barcode reader (customers choice). You get
$ 1000.00 for new hardware. The idea is to read a barcode, measure the part, factor in the measurement and upload the proper part programs to the lathes and diaplay and log the results. Show and tell is the day after tomorrow. Try not to write more than a couple pages of code.
> One of the reasons we have multiple languages is that each is suited to
> doing different things. LL excels at bit logic. I would of course never
> dream of parsing a string with LL. But then I don't need to parse a long
> string to control say a packaging machine for example, so your
> comparrison fails on that point because its out of the scope of
> application. (LL however isn't really all that bad at short string
> comparrisons thay you may need to do for RS232 instrument communications)
>
> Most PLCs use 16 or 32 bit processors, which of course means they work
> with 16 or 32 bit words. LL language takes care of the bit level access
> for you, saving you huge ammounts of work and the trouble of developing
> bit masks for all your desired IO cominations. The above example's
> solution is a PLC program that lookes something like XIC B3/2 OTE B3/22
> for an AB PLC. If it was converted to assembly there would be
> considerably more typing to do and you would have to develop a bit mask
> for your test and a bit mask to write your result. In C there would be
> almost as many characters typed before you even began production on
> useful code. (int i,o,/r/nmain{}) <-DOESNT DO ANYTHING YET!
That's a bit unfair, you get software on the PLC. If you have the framework built, which happens only once on either, all you have to do is code the logic. This looks to be about the same length in your example and mine. Mine is even a bit more human readable IMHO but that's largely a matter
of taste. And we both have to relate the bits to I/O at some point.
> LL was never inteneded for word processing and its advocates dont pretend
> that it ever was. But its foes so often find that as a fault. Its
> intent was to provide a easy to use language that saved huge ammounts of
> work in writing bit logic programs. Within that scope, it certianly
> meets the criteria to qualify as a higher level language. Sometimes the
> simple can be elegant and advanced.
I wouldn't argue that LL isn't a high level language since you can have some powerful functions. I would argue that a lot of real world tasks are much more than bit logic and mapping them to the relay model gets very ugly and expensive. I think the optimal solution should offer good tools for logic solving, including LL and much better tools for the rest of the
solution. As wide an array of tools as possible for the many problems encountered. Having C and Fortran and ncurses and sockets and scripting
and a serious database and every other tool you might need without reaching for the credit card, you can handle just about anything. The right tool for the job and all the tools in one box. I still wouldn't use Fortran again.
Regards
cww
T. Connolly:
> OK, try this. Pick your language of choice, then write a ready to
> execute program that takes the third bit from one 16 bit data word, tests
> it to be set and if it is then set the seventh bit in a different data
> word without changing any other bit in that word.
As I said, LL is a 1-bit language, so dealing with 1-bit quantities is the most natural. Most other assemblies are 8-bit, so the most natural quantity to deal with is 8 bits.
FWIW, the C statement would be: "if (a&8) b|=128;" but it's the wrong way to do it (or to compare languages, for that matter).
Indeed, you shouldn't *need* to think that it's the third bit or the seventh bit; you should just assign them names once (or have them assigned
automatically, for internal coils) and then just use the names.
Then it'd become: "if (c) d=ON;" if you were going for clarity, or: "d|=c;" if you weren't.
...
> Most PLCs use 16 or 32 bit processors, which of course means they work
> with 16 or 32 bit words. LL language takes care of the bit level access
> for you, saving you huge ammounts of work and the trouble of developing
> bit masks for all your desired IO cominations.
Well, it pretends to be a 1-bit processor for you. Big deal. Took me all of an afternoon to write that for the MAT LPLC.
> The above example's solution is a PLC program that lookes something like
> XIC B3/2 OTE B3/22 for an AB PLC.
I'm not sure how that is the third bit or the seventh bit; in any case, it's bad that you deal with the addresses explicitly. Even in most assembly languages you can give addresses names, let alone anything higher.
> If it was converted to assembly there would be considerably more typing
> to do and you would have to develop a bit mask for your test and a bit
> mask to write your result.
Again, that's because you're trying to deal with a non-native word size.
> In C there would be almost as many characters typed before you even began
> production on useful code.
Presumably this would be just one line in a large program; in any case, amount of typing alone isn't a good indicator of language level.
> LL was never inteneded for word processing and its advocates dont pretend
> that it ever was.
LL was intended mostly to pretend to be a relay diagram without being too much work to implement. At which it succeeded admirably, and it enabled the complication of control logic by an order of magnitude or two, but no more.
> Within that scope, it certianly meets the criteria to qualify as a higher
> level language. Sometimes the simple can be elegant and advanced.
Nope - it isn't. It's about the most primitive language you could possibly devise for writing bit logic programs. That doesn't mean it's not useful; certainly low-level languages have their place; but there's no way you can bend the definition to make it high-level.
It doesn't provide encapsulation, or code reuse, or any of those things a high level language does. The solution to Jim Pinto's problem of large
projects isn't some magical ``intelligent'' solutions but solid software engineering principles.
Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
> OK, try this. Pick your language of choice, then write a ready to
> execute program that takes the third bit from one 16 bit data word, tests
> it to be set and if it is then set the seventh bit in a different data
> word without changing any other bit in that word.
As I said, LL is a 1-bit language, so dealing with 1-bit quantities is the most natural. Most other assemblies are 8-bit, so the most natural quantity to deal with is 8 bits.
FWIW, the C statement would be: "if (a&8) b|=128;" but it's the wrong way to do it (or to compare languages, for that matter).
Indeed, you shouldn't *need* to think that it's the third bit or the seventh bit; you should just assign them names once (or have them assigned
automatically, for internal coils) and then just use the names.
Then it'd become: "if (c) d=ON;" if you were going for clarity, or: "d|=c;" if you weren't.
...
> Most PLCs use 16 or 32 bit processors, which of course means they work
> with 16 or 32 bit words. LL language takes care of the bit level access
> for you, saving you huge ammounts of work and the trouble of developing
> bit masks for all your desired IO cominations.
Well, it pretends to be a 1-bit processor for you. Big deal. Took me all of an afternoon to write that for the MAT LPLC.
> The above example's solution is a PLC program that lookes something like
> XIC B3/2 OTE B3/22 for an AB PLC.
I'm not sure how that is the third bit or the seventh bit; in any case, it's bad that you deal with the addresses explicitly. Even in most assembly languages you can give addresses names, let alone anything higher.
> If it was converted to assembly there would be considerably more typing
> to do and you would have to develop a bit mask for your test and a bit
> mask to write your result.
Again, that's because you're trying to deal with a non-native word size.
> In C there would be almost as many characters typed before you even began
> production on useful code.
Presumably this would be just one line in a large program; in any case, amount of typing alone isn't a good indicator of language level.
> LL was never inteneded for word processing and its advocates dont pretend
> that it ever was.
LL was intended mostly to pretend to be a relay diagram without being too much work to implement. At which it succeeded admirably, and it enabled the complication of control logic by an order of magnitude or two, but no more.
> Within that scope, it certianly meets the criteria to qualify as a higher
> level language. Sometimes the simple can be elegant and advanced.
Nope - it isn't. It's about the most primitive language you could possibly devise for writing bit logic programs. That doesn't mean it's not useful; certainly low-level languages have their place; but there's no way you can bend the definition to make it high-level.
It doesn't provide encapsulation, or code reuse, or any of those things a high level language does. The solution to Jim Pinto's problem of large
projects isn't some magical ``intelligent'' solutions but solid software engineering principles.
Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
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..
maybe..
Yes its True that Ladder logic can appear to be a Somewhat Subset of Assembly but doesnt have the functionality of true 80xxx or 68xxx Assembly
its defined in my terms as a IN-BOX language
Tightly Bound By its Purpose..in which it only has ONE.,,, Actualy assembler or any other REAL language can take on more Personality and is only Limited by the user or (Developers) imagination
even to create another Language...or ladder Interpreter or take over what the ladder Does and forget ladder logic...Ladder Logic was created for
electricians who know nothing about software to mimic there circuits and Performing a Task Instead of Million Relays... and the comment of Real programmers being A Dying Breed???, what do u mean about Real ?? 80xxx/ 68HC11 /ASM /C++ ?DELPHI is still in full usage today ? Your
Obvioulsy Not a Real Programmer...
its defined in my terms as a IN-BOX language
Tightly Bound By its Purpose..in which it only has ONE.,,, Actualy assembler or any other REAL language can take on more Personality and is only Limited by the user or (Developers) imagination
even to create another Language...or ladder Interpreter or take over what the ladder Does and forget ladder logic...Ladder Logic was created for
electricians who know nothing about software to mimic there circuits and Performing a Task Instead of Million Relays... and the comment of Real programmers being A Dying Breed???, what do u mean about Real ?? 80xxx/ 68HC11 /ASM /C++ ?DELPHI is still in full usage today ? Your
Obvioulsy Not a Real Programmer...
George Robertson:
> Please don't take this as a flame, but we generally don't consider
> (computer scientists being we) ladder logic to be a high level language.
> It is actually on a par with assembler, with the exception of some fancy
> function blocks added later to the original language.
Indeed, in some ways it is lower than assembler - most assemblers are symbolic, whereas most ladders expect physical memory addresses like M1.4
> You make a very good observation about optimizing compilers.
...
> Nowadays, sadly, the processors are so fast and memory so cheap that the
> real programmers are a dying breed.
Also, processors nowadays are designed more for optimizing compilers than human programmers - RISC, pipelining, etc.
Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
> Please don't take this as a flame, but we generally don't consider
> (computer scientists being we) ladder logic to be a high level language.
> It is actually on a par with assembler, with the exception of some fancy
> function blocks added later to the original language.
Indeed, in some ways it is lower than assembler - most assemblers are symbolic, whereas most ladders expect physical memory addresses like M1.4
> You make a very good observation about optimizing compilers.
...
> Nowadays, sadly, the processors are so fast and memory so cheap that the
> real programmers are a dying breed.
Also, processors nowadays are designed more for optimizing compilers than human programmers - RISC, pipelining, etc.
Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
Hello List,
LM> really much closer to memory areas than files.) For example, you could
LM> write a ladder logic interpretter in C, but it is impossible to write a C
LM> compiler in ladder logic. This is an acid test for determining whether a
LM> language is "high-level" or "low-level."
It is a wrong statement... It is impossible (in practice) to write a C compiler in the machine codes... directly... by "0"s and "1"s...
And you could write a machine codes interpreter in C. So, do you think machine-codes is a high level languages? Wrong.
"High-level" refers to the human side of the programming... "low-level" refers to the machine side... (If we take in mind that programming is a communication between human being and a dumb piece of iron :-)
--
Best regards,
Vladimir mailto:zyubin@iae.nsk.su
LM> really much closer to memory areas than files.) For example, you could
LM> write a ladder logic interpretter in C, but it is impossible to write a C
LM> compiler in ladder logic. This is an acid test for determining whether a
LM> language is "high-level" or "low-level."
It is a wrong statement... It is impossible (in practice) to write a C compiler in the machine codes... directly... by "0"s and "1"s...
And you could write a machine codes interpreter in C. So, do you think machine-codes is a high level languages? Wrong.
"High-level" refers to the human side of the programming... "low-level" refers to the machine side... (If we take in mind that programming is a communication between human being and a dumb piece of iron :-)
--
Best regards,
Vladimir mailto:zyubin@iae.nsk.su
Wow! Didn't expect that response.
A few salient points from the above.
From George G. Robertson, P.E. :
>If LL is High level, write some string
>processing, communications parsing,
>sequencing >with multiple possible sequences,
>historical logging, advanced process control,
>and operator >interface routines in it.
The fact that you can't do this in Ladder Logic is precisely what makes it a "higher-level" language. Yes, your calculator is "higher-level" than your PC, precisely because it limits your functionality and in doing so makes it very, very easy to use. However, this is a moot point because your doesn't really have a programming language. (Now somebody is gonna jump on me 'cause they have some fancy calculator that runs FORTH or something.)
I do see your point. For example, Java, as a programming language, is far more powerful and flexible than Ladder Logic and is generally considered a "high-level" language. So if Ladder is so limited, how can it be high-level? Thanks, T. Connolly, for providing the answer:
>Please don't confuse the availabilty of a large
>library of functions (such as in C) for a
>language level
Remember, in C you can't even put output on the screen without a library! (C++ takes care of this). Jave needs it's libraries to get everything done, too. Ladder is the same way; there ARE PLC's that can manipulate strings, have user-defined functions, and have large libraries. Generally, these libraries are to handle PID loops or motion or some other control-oriented task. There are doubtlessly PID libraries for C, but the language itself has no inherent ability to do it.
Jiri Baum had a great point about LL often being lower-level because you talk directly to memory addresses. I haven't dealt with any of these in a while, since my company now uses nothing but ControlLogix. I really don't know how to respond to this one.
Also, to Vladimir Zyubin's point:
>It is impossible (in practice) to write a C
>compiler in the machine codes...
>directly... >by "0"s and "1"s... And you could >write a >machine codes interpreter in C. So, do
>you think >machine-codes is a high level
>languages?
It is impossible in practice to do ANYTHING in machine codes. This is not really a programming language. Since machine-codes are not a language at all (at least to us) the discussion of "high-level" or "low-level" is meaningless. But obviously, machine-codes is as low as you get.
On the issue of credibility: I am NOT a computer scientist. I am a Software Engineer, which is accurately described as "applications programmer." Many computer scientist don't write any actualy code ever. So any profs out there who want to take me to town, so be it. But I stick by my definitions, while acknowledging that this is not a cut-and-dried proposition.
-James
Sage Automation, Inc.
A few salient points from the above.
From George G. Robertson, P.E. :
>If LL is High level, write some string
>processing, communications parsing,
>sequencing >with multiple possible sequences,
>historical logging, advanced process control,
>and operator >interface routines in it.
The fact that you can't do this in Ladder Logic is precisely what makes it a "higher-level" language. Yes, your calculator is "higher-level" than your PC, precisely because it limits your functionality and in doing so makes it very, very easy to use. However, this is a moot point because your doesn't really have a programming language. (Now somebody is gonna jump on me 'cause they have some fancy calculator that runs FORTH or something.)
I do see your point. For example, Java, as a programming language, is far more powerful and flexible than Ladder Logic and is generally considered a "high-level" language. So if Ladder is so limited, how can it be high-level? Thanks, T. Connolly, for providing the answer:
>Please don't confuse the availabilty of a large
>library of functions (such as in C) for a
>language level
Remember, in C you can't even put output on the screen without a library! (C++ takes care of this). Jave needs it's libraries to get everything done, too. Ladder is the same way; there ARE PLC's that can manipulate strings, have user-defined functions, and have large libraries. Generally, these libraries are to handle PID loops or motion or some other control-oriented task. There are doubtlessly PID libraries for C, but the language itself has no inherent ability to do it.
Jiri Baum had a great point about LL often being lower-level because you talk directly to memory addresses. I haven't dealt with any of these in a while, since my company now uses nothing but ControlLogix. I really don't know how to respond to this one.
Also, to Vladimir Zyubin's point:
>It is impossible (in practice) to write a C
>compiler in the machine codes...
>directly... >by "0"s and "1"s... And you could >write a >machine codes interpreter in C. So, do
>you think >machine-codes is a high level
>languages?
It is impossible in practice to do ANYTHING in machine codes. This is not really a programming language. Since machine-codes are not a language at all (at least to us) the discussion of "high-level" or "low-level" is meaningless. But obviously, machine-codes is as low as you get.
On the issue of credibility: I am NOT a computer scientist. I am a Software Engineer, which is accurately described as "applications programmer." Many computer scientist don't write any actualy code ever. So any profs out there who want to take me to town, so be it. But I stick by my definitions, while acknowledging that this is not a cut-and-dried proposition.
-James
Sage Automation, Inc.
James Ingraham:
> Wow! Didn't expect that response.
> A few salient points from the above.
George G. Robertson, P.E. :
> >If LL is High level, write some string processing, communications
> >parsing, sequencing with multiple possible sequences, historical
> >logging, advanced process control, and operator interface routines in
> >it.
> The fact that you can't do this in Ladder Logic is precisely what
> makes it a "higher-level" language.
You can do it, by the Church-Turing thesis; it's just a lot of pain, especially since you don't get any code reuse. (No functions, no code
reuse.) So you'd end up writing a lot of very repetitive code.
In reality, you'd probably write yourself a higher-level language that compiles into ladder if you actually had to do that.
> Yes, your calculator is "higher-level" than your PC, precisely because
> it limits your functionality and in doing so makes it very, very easy
> to use.
That has nothing to do with higher or lower level.
> I do see your point. For example, Java, as a programming language, is
> far more powerful and flexible than Ladder Logic and is generally
> considered a "high-level" language. So if Ladder is so limited, how
> can it be high-level?
It isn't. The reason Java is considered high-level isn't because it has a large library available, but because it has the concept of libraries, and functions, and objects, and local variables, and so on.
In Java, you could write an AirCylinder object that would handle all the standard things with air cylinders, and then use it for every cylinder in the machine, and the whole factory. In LL, for every cylinder you have to manually allocate the timeout timers and repeat the logic for "if the extended sensor doesn't come on within so many seconds, trip an alarm".
> Thanks, T. Connolly, for providing the answer:
> >Please don't confuse the availabilty of a large library of functions
> >(such as in C) for a language level
> Remember, in C you can't even put output on the screen without a
> library!
Well, LL doesn't even have the concept of a library (or, for that matter, even a function), so that's that.
> (C++ takes care of this).
FWIW, no (it's also in the library).
> Ladder is the same way; there ARE PLC's that can manipulate strings,
> have user-defined functions, and have large libraries.
I've never seen this done in a way that wouldn't be severely tacked-on; but yeah, if it can do those things (user-defined functions, libraries) then it's somewhat higher level, depending on the extent to which it does them.
> Also, to Vladimir Zyubin's point:
> >It is impossible (in practice) to write a C compiler in the machine
> >codes... directly... by "0"s and "1"s... And you could write a
> >machine codes interpreter in C. So, do you think machine-codes is a
> >high level languages?
> It is impossible in practice to do ANYTHING in machine codes. This is
> not really a programming language.
It satisfies the definition.
...
> But obviously, machine-codes is as low as you get.
Yup.
> On the issue of credibility: I am NOT a computer scientist. I am a
> Software Engineer, which is accurately described as "applications
> programmer." Many computer scientist don't write any actualy code
> ever.
Well, I've written code; you can even look at some of it if you like.
> So any profs out there who want to take me to town, so be it. But I
> stick by my definitions, while acknowledging that this is not a
> cut-and-dried proposition.
It is cut-and-dried, at least in the broad outline. You'd be hard-pressed to invent a more low-level language for bit logic without actually going to machine-codes-equivalent.
Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
> Wow! Didn't expect that response.
> A few salient points from the above.
George G. Robertson, P.E. :
> >If LL is High level, write some string processing, communications
> >parsing, sequencing with multiple possible sequences, historical
> >logging, advanced process control, and operator interface routines in
> >it.
> The fact that you can't do this in Ladder Logic is precisely what
> makes it a "higher-level" language.
You can do it, by the Church-Turing thesis; it's just a lot of pain, especially since you don't get any code reuse. (No functions, no code
reuse.) So you'd end up writing a lot of very repetitive code.
In reality, you'd probably write yourself a higher-level language that compiles into ladder if you actually had to do that.
> Yes, your calculator is "higher-level" than your PC, precisely because
> it limits your functionality and in doing so makes it very, very easy
> to use.
That has nothing to do with higher or lower level.
> I do see your point. For example, Java, as a programming language, is
> far more powerful and flexible than Ladder Logic and is generally
> considered a "high-level" language. So if Ladder is so limited, how
> can it be high-level?
It isn't. The reason Java is considered high-level isn't because it has a large library available, but because it has the concept of libraries, and functions, and objects, and local variables, and so on.
In Java, you could write an AirCylinder object that would handle all the standard things with air cylinders, and then use it for every cylinder in the machine, and the whole factory. In LL, for every cylinder you have to manually allocate the timeout timers and repeat the logic for "if the extended sensor doesn't come on within so many seconds, trip an alarm".
> Thanks, T. Connolly, for providing the answer:
> >Please don't confuse the availabilty of a large library of functions
> >(such as in C) for a language level
> Remember, in C you can't even put output on the screen without a
> library!
Well, LL doesn't even have the concept of a library (or, for that matter, even a function), so that's that.
> (C++ takes care of this).
FWIW, no (it's also in the library).
> Ladder is the same way; there ARE PLC's that can manipulate strings,
> have user-defined functions, and have large libraries.
I've never seen this done in a way that wouldn't be severely tacked-on; but yeah, if it can do those things (user-defined functions, libraries) then it's somewhat higher level, depending on the extent to which it does them.
> Also, to Vladimir Zyubin's point:
> >It is impossible (in practice) to write a C compiler in the machine
> >codes... directly... by "0"s and "1"s... And you could write a
> >machine codes interpreter in C. So, do you think machine-codes is a
> >high level languages?
> It is impossible in practice to do ANYTHING in machine codes. This is
> not really a programming language.
It satisfies the definition.
...
> But obviously, machine-codes is as low as you get.
Yup.
> On the issue of credibility: I am NOT a computer scientist. I am a
> Software Engineer, which is accurately described as "applications
> programmer." Many computer scientist don't write any actualy code
> ever.
Well, I've written code; you can even look at some of it if you like.
> So any profs out there who want to take me to town, so be it. But I
> stick by my definitions, while acknowledging that this is not a
> cut-and-dried proposition.
It is cut-and-dried, at least in the broad outline. You'd be hard-pressed to invent a more low-level language for bit logic without actually going to machine-codes-equivalent.
Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
I think that part of the problem with this discussion is a confusion between language level and generality. IMHO, the best definition of a
high level language is a language whose level of abstraction is closely matched to abstractions of the problem domain in question. This means that level and generality are best considered as two axis of a graph (please imagine it, I'll spare you my lame text graphics).
Some examples:
Assembly: Very general -- you can do anything in it with nearly equal difficulty. The difficulty of an assembly program scales non-linearly with the size of the program pretty much independent of problem domain. Very, very low level.
Basic: General for problems of limited scope. Mid level. No particular problem domain. Lacks features for handling large or complex problems. No real ability to express solutions in the domain
of the problem. See Visual Basic below.
C: Very general. Designed to do almost anything you can do with assembly. Abstractions are reasonably well suited to writing device drivers and operating systems. They are not well suited to many other domains (yes, you can design function libraries and data structures that are suited to other domains, but the resulting code is still very full of low level C details). Low to at most mid level.
C++: Very general. Very, very complex. Can do a pretty good job of raising the abstraction level close to the problem domain by proper use of generics, overloading and classes. A fair amount of basic C level cruft still tends to show through and clutter up the code. Mid/high level in general use.
Java: Looks rather like C++ at first glance but removes most of the complex and dangerous features. Can be used in many problem domains
with appropriate class libraries but basic language features always show through and clutter the code. Has features like garbage collection, array bounds checking, etc. that prevent common programmer errors. Thus, quite general, high level.
Lisp: Very general. Designed to work in the problem domain by implementing domain specific languages in lisp then solving the problem in the domain specific language. Low/mid (if you're doing things like writing lisp systems in lisp) to very high level (for serious problem solving). Not popular. Generally compiled with an optimizing compile (contrary to many impressions). One of the best languages ever created for writing compilers (the only real
competitors are the function languages such as SML).
Visual Basic: The full "language" is an IDE for writing simple GUI applications. The language is somewhat higher level than common Basic, but still lacks features for structuring and managing large programs or for expressing solutions in terms of a problem domain other than ActiveX controls. I'd still say general. Mid level for
general problem domains. Quite high level for simple GUIs.
RPG II: Designed for batch accounting problems. Very productive in that domain. Difficulty of using in any other domain quickly scales
exponentially (been there, it hurt). Thus high level, not at all general.
Ladder Logic: Designed for digital machine control. Has had features to deal with analog and motion grafted on to it, but they don't really
fit into the language model. Very productive in applications where it applies well. Not general. Level is hard to say -- the extreme
detail required and common lack of features like abstract memory addressing and basic abstraction mechanisms make it low level but the clarity and brevity of its display of domain logic make it high level.
Quickstep: Designed for machine control in discrete manufacturing. Textual language is more verbose than ladder for simple digital logic,
but does a vastly better job of integrating motion and analog. Not general outside of its domain. High level in its domain but would
benefit from adding common features of general purpose high level languages (unlike ladder, I can see how to add them to Quickstep).
The last three are examples of _domain specific languages_. I like to refer to these as nice, comfy straight jackets. They are designed both to make it easy to solve problems of specific type and to make it as hard as possible to make common mistakes in solving that type of problem. This trade off necessarily sacrifices generality. IMHO, it's a good trade off, but comparing domain specific languages and general purpose higher level languages is comparing apples and avocados.
Dan Pierson
high level language is a language whose level of abstraction is closely matched to abstractions of the problem domain in question. This means that level and generality are best considered as two axis of a graph (please imagine it, I'll spare you my lame text graphics).
Some examples:
Assembly: Very general -- you can do anything in it with nearly equal difficulty. The difficulty of an assembly program scales non-linearly with the size of the program pretty much independent of problem domain. Very, very low level.
Basic: General for problems of limited scope. Mid level. No particular problem domain. Lacks features for handling large or complex problems. No real ability to express solutions in the domain
of the problem. See Visual Basic below.
C: Very general. Designed to do almost anything you can do with assembly. Abstractions are reasonably well suited to writing device drivers and operating systems. They are not well suited to many other domains (yes, you can design function libraries and data structures that are suited to other domains, but the resulting code is still very full of low level C details). Low to at most mid level.
C++: Very general. Very, very complex. Can do a pretty good job of raising the abstraction level close to the problem domain by proper use of generics, overloading and classes. A fair amount of basic C level cruft still tends to show through and clutter up the code. Mid/high level in general use.
Java: Looks rather like C++ at first glance but removes most of the complex and dangerous features. Can be used in many problem domains
with appropriate class libraries but basic language features always show through and clutter the code. Has features like garbage collection, array bounds checking, etc. that prevent common programmer errors. Thus, quite general, high level.
Lisp: Very general. Designed to work in the problem domain by implementing domain specific languages in lisp then solving the problem in the domain specific language. Low/mid (if you're doing things like writing lisp systems in lisp) to very high level (for serious problem solving). Not popular. Generally compiled with an optimizing compile (contrary to many impressions). One of the best languages ever created for writing compilers (the only real
competitors are the function languages such as SML).
Visual Basic: The full "language" is an IDE for writing simple GUI applications. The language is somewhat higher level than common Basic, but still lacks features for structuring and managing large programs or for expressing solutions in terms of a problem domain other than ActiveX controls. I'd still say general. Mid level for
general problem domains. Quite high level for simple GUIs.
RPG II: Designed for batch accounting problems. Very productive in that domain. Difficulty of using in any other domain quickly scales
exponentially (been there, it hurt). Thus high level, not at all general.
Ladder Logic: Designed for digital machine control. Has had features to deal with analog and motion grafted on to it, but they don't really
fit into the language model. Very productive in applications where it applies well. Not general. Level is hard to say -- the extreme
detail required and common lack of features like abstract memory addressing and basic abstraction mechanisms make it low level but the clarity and brevity of its display of domain logic make it high level.
Quickstep: Designed for machine control in discrete manufacturing. Textual language is more verbose than ladder for simple digital logic,
but does a vastly better job of integrating motion and analog. Not general outside of its domain. High level in its domain but would
benefit from adding common features of general purpose high level languages (unlike ladder, I can see how to add them to Quickstep).
The last three are examples of _domain specific languages_. I like to refer to these as nice, comfy straight jackets. They are designed both to make it easy to solve problems of specific type and to make it as hard as possible to make common mistakes in solving that type of problem. This trade off necessarily sacrifices generality. IMHO, it's a good trade off, but comparing domain specific languages and general purpose higher level languages is comparing apples and avocados.
Dan Pierson
Thanks, Dan Pierson!
I think that was a very eloquent description.
Am I wrong in saying that perhaps we've all been crazy to try an shoe-horn ladder logic into the discussion? Also, I'm curious what you would say about flow-charting systems like Think & Do.
-James Ingraham
Sage Automation, Inc.
I think that was a very eloquent description.
Am I wrong in saying that perhaps we've all been crazy to try an shoe-horn ladder logic into the discussion? Also, I'm curious what you would say about flow-charting systems like Think & Do.
-James Ingraham
Sage Automation, Inc.
Nice write-up
It seems to me the underlying debate here is really what "low level" and "high level" means. Settle that and then whether or not LL is high level or low level will be apparent to all.
I stand by my general definitions:
Low level = work.
High level = less work (because someone else previously put in a lot of work)
High level is generally more rigid because the programmers that write the compiler/interpreter cannot anticipate all possible uses for the language so some language grammer, naming rules, and data typing are imposed so that the compiler can determine what the programmer's intent is with a degree of precision.
Language sophistication does not equal language level. C is a very unsophisticated language. Take away the libraries and your not left with much.
The more a language takes care of basic work for the programmer when instructing the hardware what to do, then the higher it rises above the low language level, sometimes at the cost of flexibility.
Inflexibility does not mean limitations. I once lived in Korea for a period of time during my teens. I learned a little Korean, and sometimes my sentences were twice as long as someone fluent in the language, but I was able to say what I needed. The point is that my grasp of the language made my communicaitons somewhat inflexible, but not necessarily limited in what I could eventually communicate.
If you could program a controller by talking to it in plain english you would have to stick to some very strict grammer rules. If your processor doesn't know a particular word you would have to use a series of other words. Your program would become very verbose. Then someone will come along and tell you to talk in C because
its better. You'll never reach an agreement with them.
I stand by my general definitions:
Low level = work.
High level = less work (because someone else previously put in a lot of work)
High level is generally more rigid because the programmers that write the compiler/interpreter cannot anticipate all possible uses for the language so some language grammer, naming rules, and data typing are imposed so that the compiler can determine what the programmer's intent is with a degree of precision.
Language sophistication does not equal language level. C is a very unsophisticated language. Take away the libraries and your not left with much.
The more a language takes care of basic work for the programmer when instructing the hardware what to do, then the higher it rises above the low language level, sometimes at the cost of flexibility.
Inflexibility does not mean limitations. I once lived in Korea for a period of time during my teens. I learned a little Korean, and sometimes my sentences were twice as long as someone fluent in the language, but I was able to say what I needed. The point is that my grasp of the language made my communicaitons somewhat inflexible, but not necessarily limited in what I could eventually communicate.
If you could program a controller by talking to it in plain english you would have to stick to some very strict grammer rules. If your processor doesn't know a particular word you would have to use a series of other words. Your program would become very verbose. Then someone will come along and tell you to talk in C because
its better. You'll never reach an agreement with them.
You've hit the biggest nail on the head here. Is ladder really easier? For an electrician, yes. For other people, no. Hence someone replacing
hardwired relay ladder logic with a PLC finds the language to be well suited and "high level" by the definition of ease of use. Of course, the
front panel of my Microwave at home would then be a "high level" language (while the VCR, of course, would be very low.) Someone unfamiliar with relay logic, might not find ladder to be so simple. They might find BASIC to be a higher level language.
My original post dealt with abstraction from the machine, although I did not put it so eloquently as subsequent posters to this list. I still stand by RLL have a low level of abstraction from the machine, and being only slight higher level than assembler.
A free online dictionary of computing defines languages by the number of machine language instructions represented by each instruction in the language. Hence assembly is a first generation language, and the elusive AI is a fifth generation language.
I'm not sure I'm comfortable with this definition alone, however. It would imply that my optimizing compiler reduces the level of my source
code.
BTW, whatever happened to that poor chap who originally asked about FORTRAN on his PLC?
George G. Robertson, P.E.
Manager of Engineering
Saulsbury E & C
grobertson@si-tx.com
(915) 366-4252
hardwired relay ladder logic with a PLC finds the language to be well suited and "high level" by the definition of ease of use. Of course, the
front panel of my Microwave at home would then be a "high level" language (while the VCR, of course, would be very low.) Someone unfamiliar with relay logic, might not find ladder to be so simple. They might find BASIC to be a higher level language.
My original post dealt with abstraction from the machine, although I did not put it so eloquently as subsequent posters to this list. I still stand by RLL have a low level of abstraction from the machine, and being only slight higher level than assembler.
A free online dictionary of computing defines languages by the number of machine language instructions represented by each instruction in the language. Hence assembly is a first generation language, and the elusive AI is a fifth generation language.
I'm not sure I'm comfortable with this definition alone, however. It would imply that my optimizing compiler reduces the level of my source
code.
BTW, whatever happened to that poor chap who originally asked about FORTRAN on his PLC?
George G. Robertson, P.E.
Manager of Engineering
Saulsbury E & C
grobertson@si-tx.com
(915) 366-4252
Talk about opening a can of worms! Obviously the definition of a low level or high level language is kinda all over the place. So here goes the definitions going from low level (machine)to high level (fully abstracted):
1. machine code (1 or 0 in a 8,16 ,32, 64 or 128 bit grouping)
2. Pseudo code, also know as assembler (16 or 32 bit pattern for a given pseudo code (or assembly instruction).
3. compiled mid language such as C, C++. You can insert assembly as inline code in C and you need libraries for anything, and supports cross platform coding.
4. compiled high level such as FORTRAN, Cobol, or any Visual xxx stuff (cannot insert inline assembly code without setting up a framework, cross platform support is not a bed of roses).
5. interpreted languages (cannot run without a supporting infrastructure). You could put the Visual xxx stuff here since you need the support of the Windows environment.
Usually if a language instruction correlates directly with a machine code bit pattern it is low level. If a language instruction correlates to a set of bit patterns or has no correlation whatsoever (APL anyone), then it is of a higher level.
Ladder is a lot like Pseudo code, one ladder instruction is a defined bit pattern for the processor.
1. machine code (1 or 0 in a 8,16 ,32, 64 or 128 bit grouping)
2. Pseudo code, also know as assembler (16 or 32 bit pattern for a given pseudo code (or assembly instruction).
3. compiled mid language such as C, C++. You can insert assembly as inline code in C and you need libraries for anything, and supports cross platform coding.
4. compiled high level such as FORTRAN, Cobol, or any Visual xxx stuff (cannot insert inline assembly code without setting up a framework, cross platform support is not a bed of roses).
5. interpreted languages (cannot run without a supporting infrastructure). You could put the Visual xxx stuff here since you need the support of the Windows environment.
Usually if a language instruction correlates directly with a machine code bit pattern it is low level. If a language instruction correlates to a set of bit patterns or has no correlation whatsoever (APL anyone), then it is of a higher level.
Ladder is a lot like Pseudo code, one ladder instruction is a defined bit pattern for the processor.
> Ladder is a lot like Pseudo code, one ladder
> instruction is a defined bit pattern for the
> processor.
- actually, ladder is an interpreted language, often compiled to a pcode series of hex numbers to save memory, but then interpreted by the PLC. It does not compile to machine language to be executed directly on the processor. The interpreter takes care a great deal of work for the programmer.
> instruction is a defined bit pattern for the
> processor.
- actually, ladder is an interpreted language, often compiled to a pcode series of hex numbers to save memory, but then interpreted by the PLC. It does not compile to machine language to be executed directly on the processor. The interpreter takes care a great deal of work for the programmer.
Hello List,
T. Connolly wrote:
>> Ladder is a lot like Pseudo code, one ladder instruction is a defined
>> bit pattern for the processor.
>
> - actually, ladder is an interpreted language,
[...]
wrong statement...
Interpreter - it is a kind of translaters (not of languages!)... Quite possible some ladder translators have the compiler form... As well as there are C-interpreters.
Have a look at the yahoo.com results on "C language interpereter"
for example:
====
EiC Home Page
... EiC is a freely available C language interpreter in both source and binary
form.
EiC allows you to write C programs, and then "execute" them as if they were a ...
http://www.kd-dev.com/~eic/
====
--
Best regards,
Vladimir mailto:zyubin@iae.nsk.su
T. Connolly wrote:
>> Ladder is a lot like Pseudo code, one ladder instruction is a defined
>> bit pattern for the processor.
>
> - actually, ladder is an interpreted language,
[...]
wrong statement...
Interpreter - it is a kind of translaters (not of languages!)... Quite possible some ladder translators have the compiler form... As well as there are C-interpreters.
Have a look at the yahoo.com results on "C language interpereter"
for example:
====
EiC Home Page
... EiC is a freely available C language interpreter in both source and binary
form.
EiC allows you to write C programs, and then "execute" them as if they were a ...
http://www.kd-dev.com/~eic/
====
--
Best regards,
Vladimir mailto:zyubin@iae.nsk.su
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
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
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.
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.
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.
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.
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.
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.
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.
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
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
> > > 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
> > > 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
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??..
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??..
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
> 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
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
************************
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
************************
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+generati on+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+g eneration+language":http://www.InstantWeb.com/D/dictionary/foldoc.cg i?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+generati on+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+generat ion+language":http://www.InstantWeb.com/D/dictionary/foldoc.cgi?four th+generation+language
5. fifth generation languages ("AI languages", "a mith", example - no implemented yet)
"http://www.InstantWeb.com/D/dictionary/foldoc.cgi?fifth+generati on+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:zyubin@iae.nsk.su
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+generati on+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+g eneration+language":http://www.InstantWeb.com/D/dictionary/foldoc.cg i?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+generati on+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+generat ion+language":http://www.InstantWeb.com/D/dictionary/foldoc.cgi?four th+generation+language
5. fifth generation languages ("AI languages", "a mith", example - no implemented yet)
"http://www.InstantWeb.com/D/dictionary/foldoc.cgi?fifth+generati on+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:zyubin@iae.nsk.su
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
>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
Your use of this site is subject to the terms and conditions set forth under Legal Notices and the Privacy Policy. Please read those terms and conditions carefully. Subject to the rights expressly reserved to others under Legal Notices, the content of this site and the compilation thereof is © 1999-2010 Nerds in Control, LLC. All rights reserved.
Users of this site are benefiting from open source technologies, including PHP, MySQL and Apache. Be happy.
Fortune
Workers of the world, arise! You have nothing to lose but your
chairs.
Servo, stepping motor control, analog & web HMI in one system!
Control.com is the largest Automation community on the web. Learn how to advertise here now...
