# Modular design (Re: SOFT, ENGR, INFO: The Linux PLC Project)

J

#### Jiri Baum

[email protected] wrote on AUTOMATION-L
> I would like to suggest (may be implied by some, but surely not by all)
> that the control part should be divideable. That is one part interpreting
> a PLC program, one part running a precompiled C controller directly using
> the API, one part running a set of PID controllers and so on at the same
> time if that is desired.

I think I suggested it before, but I stuck it onto the end of some obscure thread where nobody saw it

Another part (front-end) that I had on the list was a PLC server - emulates a PLC on an industrial bus (or even Ethernet). This can be used both for legacy[1] HMI systems, and for linux HMIs running on a separate computer.

A further front-end is the HMI; even if you separate the control and the HMI into different boxes, I don't see any reason why they couldn't run the same architecture: the control' box presents itself as a PLC to the HMI' box, which then needs the linuxPLC driver, the core, and the HMI, WWW and CORBA front-ends. (Should I draw a diagram for this?)

The other thing that ought to be modular is the back-end, so that any number of I/O drivers can run at the same time; and these should be
separate from the bus drivers, so that several I/O drivers and the PLC server can all share the same bus.

Whether these modules are separate processes or dynamically loaded into the core process is an interesting design question. I'd lean toward separate processes, but they have some performance penalty.

> (two controlling parts should of course NOT affect the same output, but
> be running side by side towards the same memory area controlling
> different outputs)

Yes - though I think enforcing this requirement would be more trouble than it's worth.

> It would even be possible to put them in a chain, one using anothers
> output as its input.

They can communicate using the "internal relays" provided by the core (or more likely a pseudo-driver[2]); for anything complicated, though, you have to start thinking of the various multiprocessing anomalies (non-atomicity,
deadlocks, livelocks) and we'll eventually have to provide primitives for that (or document those that already exist).

I think we should take this discussion to the linuxplc list.

Jiri

[1] legacy: (adj.) non-linux
[2] Keep everything out of the core - small is bug-free. Besides, it's not
as pseudo as it sounds - it needs to write the relays to a file to keep
them across power-failures.
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

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