RE: LinuxPLC

S

Thread Starter

Scott Cornwall

Dan wrote...
> It would be easier on all of us if there were as few of these abstract machines as possible, but the minumum realistic number is probably greater than one. <

IEC1131 provides Instruction List as a base language. Should a virtual machine for IL be the run time engine for this project ? The JVM is becoming some sort of industry standard in the IT world, maybe an ILVM could be the standard for the automation world. It does not (should not) restrict the languages that compile for the virtual machine.


> This is really a key question:
> If the definition of "PLC" is limited to something with a fixed:
>
> scan inputs
> compute logic (maybe with function block kludges)
> set outputs
>
> Then I see this project as limiting itself to technology that was at least obsolecent when Linux was invented. While it's important to
support that technology, and I realize that some members of this list are interested in nothing else, it's at least equally important to provide for evolution to more modern and effective approaches. Yes, we at Control Tech believe that we have one of these. I *do not* believe that it's the only possible one, nor am I trying to push it as part of the LinuxPLC, but I think that it would be a serious long term mistake to make such approaches excessively difficult to fit into this project.<

Yes.
This project (starting in 2000) needs to be careful about making the direct comparison of LinuxPLC == PLC circa 1970's. We are seeing this influence the concept already with people being adamant that Ladder is the only important language. Ladder is important, but so are other languages which have more power and flexibility and other advantages. Also the memory map being considered is pushing the project down a
particular design path. I know Modbus is important, but what about the complex structured variables you will want in your LinuxPLC for the future. Those Modbus extensions mentioned earlier could be extremely important (are the details available). Some consideration should be given to an object model for the user programs at an early stage also. IEC1131 provides a framework where Function Blocks
are the objects.

Scott Cornwall
www.psc.fp.co.nz

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
If you want to build a PLC, build a PLC. If you want to build something else, say a computer control system, please call it something else other than a PLC.

Can anyone name a successfully marketed PLC that does not run ladder logic?

There are plenty of good computer control systems, but they are not _by definition_ PLC's

You may or may not personally like laddder logic, and it may or may not be the best fit for a given application, but it's a language spoken by many many people in the industrial control world.

C may not be as nice and elegant as say C++, but most of the successful *NIX kernels are written in C

--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.
--


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
A
I agree that we need to support the three 1131 type languages as a base. However, we should plan on other modern languages being used eventually. Ladder will be around for a long time yet, but it will eventually lose ground
to modern languages. At the very least, a means to easily program a custom ladder instruction block in a modern language is needed (by easily I mean without requiring a machine integrator to understand large amounts of the plc core engine code). Even the big boys are testing this with the introduction of Rockwell's OpenPLC a couple of years ago (a god-awfully expensive but low
end pentium PC that runs on a special CPU card in a SLC500 style chassis) and their extensions to their SoftLogix5 PLC (software products called RSextensions and RSsidewinder if I remember correctly).

Someone's earlier idea of different front end applications that 'compile' down to a common set of p-code provides the machine integrator with different programming options.

Alan Locke
Controls Engineer, Boeing

"My opinions are my own and not necessary those of my employer"

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
On Mon Jan 10 21:38:57 2000 Alan Locke wrote...
>
>Stan Brown wrote:
>>If you want to build a PLC, build a PLC. If you want to build something
>>else, say a computer control system, please call it something else
>>other than a PLC.
>>
>>Can anyone name a succesffully markedted PLC that does not run ladder
>>logic?
>>
>>There are plenty of good computer control systems, but they are not _by
>>definantion_ PLC's
>>
>>You may or may not personally like laddder logic, and it may or may not
>>be the best fit for a given application, but it's a language spoek by
>>many many people in the industrial control world.
>>
>>C may not be as nice and elegant as say C++, but most of tthe
>>succesfful *NIX kernels are written in C
>
>I agree that we need to support the three 1131 type languages as a base.
>However, we should plan on other modern languages being used eventually.
>Ladder will be around for a long time yet, but it will eventually lose ground
>to modern languages. At the very least, a means to easily program a custom
>ladder instruction block in a modern language is needed (by easily I mean
>without requiring a machine integrator to understand large amounts of the plc
>core engine code). Even the big boys are testing this with the introduction
>of Rockwell's OpenPLC a couple of years ago (a god-awfully expensive but low
>end pentium PC that runs on a special CPU card in a SLC500 style chassis) and
>their extensions to their SoftLogix5 PLC (software products called RSextensions
>and RSsidewinder if I remember correctly).

This is OK, but again we must emphasize the existing paradigm for acceptance.

--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.
--
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
P
Stan Brown said:

> Can anyone name a succesffully markedted PLC that does not run ladder logic? <

I work with the Siemens (aka Texas Instruments) 505 line of PLC's. Yes, they do support ladder; however, the program development environment which allows the fastest application build for this PLC does not use ladder as the development language, rather it compiles code down to ladder. The actual development is done using a CASE tool (APT) which allows the programmer to use Function Block like objects for Valves, Motors, and Loop Controllers, and SFC's (Sequential Function Block) Diagrams for sequencing, and a Math
Language for a structured code. I believe the basic functionality in ladder or a ladder-like language is desired (or required); but the idea of layering on additional languages which have state based, sequence based, or object based characteristics is highly desirable for a modern controller.

Paul R Nelson, PE
Auburn Site Engineering and Controls
Dow Corning Corporation
(517) 496-7013
[email protected]
(my opinions are not necessarily
those of my employer)

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
On Tue Jan 11 08:23:06 2000 wrote...
>
>Stan Brown said:
>
>
>> Can anyone name a succesffully markedted PLC that does not run
>ladder logic?
>
>I work with the Siemens (aka Texas Instruments) 505 line of PLC's. Yes, they
>do support ladder; however, the program development environment which allows
>the fastest application build for this PLC does not use ladder as the
>development language, rather it compiles code down to ladder. The actual
>development is done using a CASE tool (APT) which allows the programmer to
>use Function Block like objects for Valves, Motors, and Loop Controllers,
>and SFC's (Sequential Function Block) Diagrams for sequencing, and a Math
>Language for a structured code. I believe the basic functionality in ladder
>or a ladder-like language is desired (or required); but the idea of layering
>on additional languages which have state based, sequence based, or object
>based characteristics is highly desirable for a modern controller.

I agree that _additional_ languages are desirable. My point is that ladder logic is a prerequisite to call something a PLC. Almost all
modern PLC's do support some other style of programing, but the common
ground they all meet on is ladder logic.


--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.
--
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
To Ladder Logic or Not to Ladder Logic has been an argument since before I was into control systems and I have no doubt it will continue to be for a long time to come.

The point is, IMHO, that there has never been, and probably will never be a _better_ language than ladder for pointy end machine control (which doesn't mean that others aren't as good).

Modern does not mean better.

Progress does not mean improvement.

Function block programming compliments ladder logic, as does grafcet. Many of the improvements to come will be based (like grafcet) on how we define a process, or (like AutomationX) on how we visualise it, and integrating control, data handling, specification, resource management etc. (PLC) Software development will be aided more by Project Management tools (Version Management (CVS?), Librarians, etc) and spec to code tools, than by arguments over which is the best language to use.

Ladder Logic, much maligned, was amongst the first visual programming languages, and supports the object paradigm in a number of ways (including
modeling the real world). I believe many of the arguments against ladder logic are due to professional jealousy and elitism, after all anyone who can understand a relay circuit diagram can understand most ladder logic.

That said I feel that the ideal language to start with is Instruction List (IL). Certainly, all IEC 1131-3 languages with the exception of grafcet can
be compiled down to IL. I also believe, as with comms. drivers, editors and HMI's, ultimately the greater the choice, the more attractive the LinuxPLC will be. IEC 1131-3 should be supported, but so should anything else that the highly imaginative list members can come up with.


_______________________________________________
LinuxPLC mailing list
[email protected]uxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top