H
[email protected] (smarkley) wrote:
> I think that it sort of disintegrated due
> to lack of agreement on what a PLC
> really is and an inability to focus on a
> core document describing the
> requirements.
How true... people want to use PLCs for everything, from high-speed closed loops running as tight as within 1ms schedules, up to data compression (oops), up to large-scale function block systems. Looks like MS Office and DCOM would do here the trick once again
> Many seemed to be more interested in some kind of
> high speed controller
> rather then a general purpose PLC.
In my opinion, the problem could be the term and ideo of "Programmable Logic Controllers" itself. PLCs became widely used for replacing relay circuits. That is there "ladder diagrams" come
from. Interesting enough, ladder diagrams became famous in North America, but not in Europe, where Structured Text made its way instead. Think of both of some kind of low-level assembler. They
are powerful but lack the right level of abstraction in quite some applications. The advantage is, that engineering tools can be easily realized for both languages, and both programs from both languages can be run quite fast (because the engineer can optimize).
On the other hand, most non-trivial ladder diagrams and structured text programs become easily spaghetti code and unmaintainable,
because information hiding is a pain to do: which code blocks touch marker M42?
Now comes in the Spani... (oops, wrong movie); now came function block technique, featuring information hiding. While it is much more
convenient to engineer larger applications, you can still compile your function blocks straight into structured text.
Unfortunately that's what almost all vendors do. The usual problems are: the plant changes, so an external contractor gets the current program database snapshot. Back to home he adds/changes the function blocks, ladder diagrams, structured
code. In the meantime server personnal had to change the running system to in order to cope with small problems. After some days or weeks the contractor comes back, downloads the new PLC
software...and boom. Nothing runs anymore. Its simply a pain in the ass to find out what was changed in such a situation. And all that because only code is downloaded to the PLCs. If instead the function blocks would be inserted as objects into the running system, one could make sure that there are no conflicts. The PLC could give a proper description of what's currently inside and how all those things relate to each other -- the system should be self-describing in this situation.
But that would not be a "hacker's PLC" anymore, so you would probably not run your 1ms loops anymore on such a system, but instead "slower" (250ms anyone?) applications with the benefit of
online-engineering instead of downloading code.
And then there's still quite some applications beyond simple signal-processing: hierarchical command-driven operation using control units understanding clear-text commands. For instance: motors can understand "take into operation", "turn left", "turn right", "stop", "take out of operation", etc. Then superiour control units can be told run complete tasks only by sending them one command: "pump", "flush", etc., operating several secondary control units accordingly.
The bottom line: it seems to me that what is necessary is a separation of concerns. What kind of modules/blocks are needed? For what applications? So maybe it is possible to make a modular LinuxPLC that can be configured to handle different applications at the same time or at least after compile-time configuration.
Regards,
Harald
--
Harald Albrecht
Chair of Process Control Engineering
Aachen University of Technology
Turmstrasse 46, D-52064 Aachen, Germany
Tel.: +49 241 80-7703, Fax: +49 241 8888-238
email: [email protected]-aachen.de
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
> I think that it sort of disintegrated due
> to lack of agreement on what a PLC
> really is and an inability to focus on a
> core document describing the
> requirements.
How true... people want to use PLCs for everything, from high-speed closed loops running as tight as within 1ms schedules, up to data compression (oops), up to large-scale function block systems. Looks like MS Office and DCOM would do here the trick once again
> Many seemed to be more interested in some kind of
> high speed controller
> rather then a general purpose PLC.
In my opinion, the problem could be the term and ideo of "Programmable Logic Controllers" itself. PLCs became widely used for replacing relay circuits. That is there "ladder diagrams" come
from. Interesting enough, ladder diagrams became famous in North America, but not in Europe, where Structured Text made its way instead. Think of both of some kind of low-level assembler. They
are powerful but lack the right level of abstraction in quite some applications. The advantage is, that engineering tools can be easily realized for both languages, and both programs from both languages can be run quite fast (because the engineer can optimize).
On the other hand, most non-trivial ladder diagrams and structured text programs become easily spaghetti code and unmaintainable,
because information hiding is a pain to do: which code blocks touch marker M42?
Now comes in the Spani... (oops, wrong movie); now came function block technique, featuring information hiding. While it is much more
convenient to engineer larger applications, you can still compile your function blocks straight into structured text.
Unfortunately that's what almost all vendors do. The usual problems are: the plant changes, so an external contractor gets the current program database snapshot. Back to home he adds/changes the function blocks, ladder diagrams, structured
code. In the meantime server personnal had to change the running system to in order to cope with small problems. After some days or weeks the contractor comes back, downloads the new PLC
software...and boom. Nothing runs anymore. Its simply a pain in the ass to find out what was changed in such a situation. And all that because only code is downloaded to the PLCs. If instead the function blocks would be inserted as objects into the running system, one could make sure that there are no conflicts. The PLC could give a proper description of what's currently inside and how all those things relate to each other -- the system should be self-describing in this situation.
But that would not be a "hacker's PLC" anymore, so you would probably not run your 1ms loops anymore on such a system, but instead "slower" (250ms anyone?) applications with the benefit of
online-engineering instead of downloading code.
And then there's still quite some applications beyond simple signal-processing: hierarchical command-driven operation using control units understanding clear-text commands. For instance: motors can understand "take into operation", "turn left", "turn right", "stop", "take out of operation", etc. Then superiour control units can be told run complete tasks only by sending them one command: "pump", "flush", etc., operating several secondary control units accordingly.
The bottom line: it seems to me that what is necessary is a separation of concerns. What kind of modules/blocks are needed? For what applications? So maybe it is possible to make a modular LinuxPLC that can be configured to handle different applications at the same time or at least after compile-time configuration.
Regards,
Harald
--
Harald Albrecht
Chair of Process Control Engineering
Aachen University of Technology
Turmstrasse 46, D-52064 Aachen, Germany
Tel.: +49 241 80-7703, Fax: +49 241 8888-238
email: [email protected]-aachen.de
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc