J
Jiri Baum
Curt Wuollet:
> What do we do about intelligent I/O that presents in IEEE floats, for example. And we need to deal with some weird data types for stuff like I've got that can be boolean or integer. What people tend to do is model with 16bit regs and you simply read more or less of them and do the translation. A node struct will need a type member so the PLC "Knows" what it's dealing with or how do we abstract that?.<
I vote they should be converted to a native format. This ties in with point (5) below.
An interface to the raw data should be available, but not encouraged.
Simon Martin:
> > 2) PLC engine.
> >
> > The PLC engine runs a set of rules on the IO to generate the output. Again, let's define a model. A simple model I can think of is the status of one or more outputs is defined the status of one or more inputs, this would translate
as: ...
The io may be physical or virtual. The IO is stored in shared memory. < <
You'll probably find that to be a very limiting model; despite what ladder pretends, it doesn't actually do that
I would suggest that initially at least the interface be in ordinary C. We'll want the thing to be programmable in C (among other things) and
it's much easier to translate a ruleset into C than the other way around. (Not to mention the performance advantage.)
> > 4) The PLC Engine knows nothing about programming languages.
> >
> > A set of middleware translators are written to go between the PLC engine representation and any programming language (Ladder, etc). < <
Yes. (In fact, the PLC engine should probably be in a separate process.)
> > 3) IO to Physical IO mapping
> >
> > A set of processes map the virtual IO to physical IO and feed the corresponding drivers. This process is user configurable via the file
/etc/iomap.conf, which defines IO range, IO driver responsible and any other data required by the driver to identify the physical IO module.< <
Curt Wuollet:
> (3) sounds fine, some of this will can loaded to the map on init.<
Yes. Don't forget that it should be able to add and remove drivers on-line. (Probably easiest to have them as separate processes again - we
can always make them loadable later.)
> > 5) Keep everything isolated via abstraction models.
> >
> > OK we all bash MS Windows NT, but I think one of the greatest things to come out of it is the HAL (Hardware Abstraction Layer). This presents all the rest of the operating system with a "concept of a computer", < <
Note that it goes the other way, too: it presents the hardware driver with a "concept of a control program", regardless of what language the
control program is in.
Jiri
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
> What do we do about intelligent I/O that presents in IEEE floats, for example. And we need to deal with some weird data types for stuff like I've got that can be boolean or integer. What people tend to do is model with 16bit regs and you simply read more or less of them and do the translation. A node struct will need a type member so the PLC "Knows" what it's dealing with or how do we abstract that?.<
I vote they should be converted to a native format. This ties in with point (5) below.
An interface to the raw data should be available, but not encouraged.
Simon Martin:
> > 2) PLC engine.
> >
> > The PLC engine runs a set of rules on the IO to generate the output. Again, let's define a model. A simple model I can think of is the status of one or more outputs is defined the status of one or more inputs, this would translate
as: ...
The io may be physical or virtual. The IO is stored in shared memory. < <
You'll probably find that to be a very limiting model; despite what ladder pretends, it doesn't actually do that
I would suggest that initially at least the interface be in ordinary C. We'll want the thing to be programmable in C (among other things) and
it's much easier to translate a ruleset into C than the other way around. (Not to mention the performance advantage.)
> > 4) The PLC Engine knows nothing about programming languages.
> >
> > A set of middleware translators are written to go between the PLC engine representation and any programming language (Ladder, etc). < <
Yes. (In fact, the PLC engine should probably be in a separate process.)
> > 3) IO to Physical IO mapping
> >
> > A set of processes map the virtual IO to physical IO and feed the corresponding drivers. This process is user configurable via the file
/etc/iomap.conf, which defines IO range, IO driver responsible and any other data required by the driver to identify the physical IO module.< <
Curt Wuollet:
> (3) sounds fine, some of this will can loaded to the map on init.<
Yes. Don't forget that it should be able to add and remove drivers on-line. (Probably easiest to have them as separate processes again - we
can always make them loadable later.)
> > 5) Keep everything isolated via abstraction models.
> >
> > OK we all bash MS Windows NT, but I think one of the greatest things to come out of it is the HAL (Hardware Abstraction Layer). This presents all the rest of the operating system with a "concept of a computer", < <
Note that it goes the other way, too: it presents the hardware driver with a "concept of a control program", regardless of what language the
control program is in.
Jiri
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc