PLC features (was: is the list broken)

H

Thread Starter

Harald Albrecht

[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
 
R

Rick Jafrate

Harald,

I had a look at the Aachen University web page you suggested to our group. It seems they have been dreaming the same dream I have been having for the past 18 years or so. I agree with you whole heartedly in your above comments about modularity and the need to have all necessary
information about a module (I used to use the word object but too many people got confused) online, but I don't see why this should prevent the use of sub-mili-second algorithms. It would seem to me that the primary resource that would be consumed would be memory and disk.

Is the limitation you are thinking of an artifact of the windows implementation of Aachen's Object Management System? Could you elaborate some more?

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

Harald Albrecht

Well -- my separation between sub-mili-second and above is probably totally misleading to some extend. The object management system developed by my collegue doesn't prevent this. Traversing objects is as fast as it probably could be, because objects are linked using doubly-linked lists. When running objects within a task, you only have to traverse the list and execute the
function blocks's methods. Signals are transfered using connection objects ("wires") between output and input ports of function blocks, to keep the information hiding principle alive. As this involves copying this is not as fast as an hand-optimized structured text, where the whole loop is written as one monolithic code block. But this is a price to pay if you want to use the function block technique and still want to engineer the system at runtime.

As for speed we have to cope with two requirements: raw speed when running function blocks in a task, and second: engineering the system online. Currently, requests coming in from the network are served whenever no task is currently running. This also means that the request has to be served in toto before the next task can be awoken, so task jitters can happen. Interrupting request handling is not a good idea either, as the object database then could be in an inconsistent state. For the systems where we use this system, cycle times are sometimes around 100-250ms, but most often around 1s. Task jitters are not too important and can be tolerated to some extend.

For very tight closed loops you typically don't engineer the system during operation, so a special solution might be to lock out engineering services during "full-speed" operation of the loops. Before changing the system online, one would switch from "run" level to "engineering" level in such a scenario. Then you would have
only to consider get/set services retrieving or setting values of function block ports and to make sure that they do not interfere with a high-priority execution task. Currently, our systems don't have such a differentiation between "run" and "engineering". If you use the object management system with 10,000 objects of a oil
cracker, you simply can't halt it, because you would need days to shut down the entire cracker -- just toooo expensive. So you have (slower) loops running and at the same you engineer other parts online, test them, and if they are satisfyingly working, you just leave them running.

As a sidenote: commercial PLCs typically avoid the problem about request handling and task jitters due to the comparable simple requests they use -- you can send them only rather short requests, so request handling time is (very) bound. One solution probably would be to break every request into subparts and lock out any task during handling subparts but allowing task to start between subparts. But locking can easily eat up quite some time due to scheduling.

BTW - the tasking mechanism of the object management system can be replaced, because that's just something executing service requests and function block methods.

Bottom line -- depending on how you plan to mainly use your system, you will either lock out engineering when in the "run" level or accept engineering at every time at the expensive of task jitters. But that are probably two ends of the same thing, so you can only have one or the other to some extend, but not both to 100% at the
same time.

As another side note: the object management system was born on a Linux system. Only many curses later it also run on Win32 and OpenVMS. Porting it to a 16bit uC then was comparable easy
(grin).

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
 
J

Johan Bengtsson

I don't think what you describe you want will be a real problem to implement, eventually, It will probably run a little bit faster here than in an "ordinary" PLC since what *will* take up the most of the scan time is scheduling and other such stuff and not the actual work. (making the difference in scan time being more constant regardless of program size for small to medium programs, large and huge programs will of course have a higher scan time.)


/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

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