S
Hi all:
This is a RFC (Request For Comment). I apologize for writing C code, but I think better in code than in any natural language (it's a sorry life). After reading quickly through all the mail from this list (it is a busy list isn't it), and weaving in a bit of my own experience I would like to say the following on the design:
1) IO
Let's define an IO model. As far as I can see (please correct me if I'm wrong) the type of IO that is available is analog (12/16 bit)/digital, periodic/immediate update. If these are the only requierements then I would suggest that an IO node would be defined adequately by:
enum io_update_type { io_update_periodic, io_update_immediate };
struct tag_io {
enum io_update_type update;
long value;
};
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:
enum comparison_type { comparison_equals, comparison_greater, comparison_greater_equal,
comparison_less, comparison_less_equal }
struct tag_condition {
struct tag_io *io;
long value;
enum comparison_type comparison;
};
enum conjuntcion_type { conjuntion_and, conjunction_or, conjuntion_none
};
struct tag_rule {
struct tag_condition lcondition;
enum conjunction_type conjunction;
struct tag_condition rcondition;
};
struct tag_list_io {
struct tag_io io;
struct tag_list_io *next;
};
struct tag_step {
struct tag_rule *rule;
struct tag_list_io *set
}
The io may be physical or virtual. The IO is stored in shared memory.
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.
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). This has the advantage of being able to see the program as I like it, if I understand IL, I see it as IL, if I understand Ladder, I see it as ladder. A standard annotation format must be developed to be able to transport non-executable information from one format to another.
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", filling in the blanks where required, translating where required. I would hope that this would be one of the goals. The PLC just understands conditions and io, other processes understand Ladder, ModBus, DH, DH+, etc.
(Flame shields are up and at full strength, Mr Spock)
Debian GNU User
Simon Martin
Project Manager
Isys
mailto: [email protected]
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
This is a RFC (Request For Comment). I apologize for writing C code, but I think better in code than in any natural language (it's a sorry life). After reading quickly through all the mail from this list (it is a busy list isn't it), and weaving in a bit of my own experience I would like to say the following on the design:
1) IO
Let's define an IO model. As far as I can see (please correct me if I'm wrong) the type of IO that is available is analog (12/16 bit)/digital, periodic/immediate update. If these are the only requierements then I would suggest that an IO node would be defined adequately by:
enum io_update_type { io_update_periodic, io_update_immediate };
struct tag_io {
enum io_update_type update;
long value;
};
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:
enum comparison_type { comparison_equals, comparison_greater, comparison_greater_equal,
comparison_less, comparison_less_equal }
struct tag_condition {
struct tag_io *io;
long value;
enum comparison_type comparison;
};
enum conjuntcion_type { conjuntion_and, conjunction_or, conjuntion_none
};
struct tag_rule {
struct tag_condition lcondition;
enum conjunction_type conjunction;
struct tag_condition rcondition;
};
struct tag_list_io {
struct tag_io io;
struct tag_list_io *next;
};
struct tag_step {
struct tag_rule *rule;
struct tag_list_io *set
}
The io may be physical or virtual. The IO is stored in shared memory.
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.
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). This has the advantage of being able to see the program as I like it, if I understand IL, I see it as IL, if I understand Ladder, I see it as ladder. A standard annotation format must be developed to be able to transport non-executable information from one format to another.
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", filling in the blanks where required, translating where required. I would hope that this would be one of the goals. The PLC just understands conditions and io, other processes understand Ladder, ModBus, DH, DH+, etc.
(Flame shields are up and at full strength, Mr Spock)
Debian GNU User
Simon Martin
Project Manager
Isys
mailto: [email protected]
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc