J
Phil Covington:
> Maybe there should be controller memory that is not device specific that the Logic Engine has access to for its purposes. The controller memory would be flat and could contain any data type. There could be a mechanism (Controller Memory Manager?) for mapping controller memory to driver memory and loading and unloading drivers through a defined Driver Interface. If a Driver Interface is defined that every I/O driver must
implement, then the details of how the driver deals with the I/O are seperated from the controller and Logic Engine.<
Agreed.
> An Object Oriented approach here would be useful as you could encapsulate the controller's memory (data) with the Controller Memory Manager
(procedures to operate on that data).<
Probably make the drivers separate processes for their mutual protection. (Hmm, that would mean you could have proprietary device drivers. Hmmmm.)
> On start up the details of which drivers to load, driver settings, etc.. could be stored in a simple DB that the Controller Memory Manager reads. <
(Don't forget dynamic loading and unloading.)
> The core of the LinuxPLC then could be broken down to three basic components: Device Driver Interface, Controller Memory Manager, and Logic
Engine. People interested in a certain type of I/O device would implement the device driver (with a defined interface), another group could work on the Controller Memory Manager, and still another group would work on the Logic Engine. One these components are coded, then a Ladder, SFC, Logic Block, C, or whatever front end could be developed to generate a program that the Logic Engine executes.<
I would suggest a C interface directly to the flat-memory representation. Some programs really don't need to have the logic engine in the way...
(That would mean making sure more than one Logic Engine can run at a time, but that shouldn't be a great problem. Each engine only sets the outputs
that it has explicit values for, and leaves the rest to others.)
Jiri
--
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
> Maybe there should be controller memory that is not device specific that the Logic Engine has access to for its purposes. The controller memory would be flat and could contain any data type. There could be a mechanism (Controller Memory Manager?) for mapping controller memory to driver memory and loading and unloading drivers through a defined Driver Interface. If a Driver Interface is defined that every I/O driver must
implement, then the details of how the driver deals with the I/O are seperated from the controller and Logic Engine.<
Agreed.
> An Object Oriented approach here would be useful as you could encapsulate the controller's memory (data) with the Controller Memory Manager
(procedures to operate on that data).<
Probably make the drivers separate processes for their mutual protection. (Hmm, that would mean you could have proprietary device drivers. Hmmmm.)
> On start up the details of which drivers to load, driver settings, etc.. could be stored in a simple DB that the Controller Memory Manager reads. <
(Don't forget dynamic loading and unloading.)
> The core of the LinuxPLC then could be broken down to three basic components: Device Driver Interface, Controller Memory Manager, and Logic
Engine. People interested in a certain type of I/O device would implement the device driver (with a defined interface), another group could work on the Controller Memory Manager, and still another group would work on the Logic Engine. One these components are coded, then a Ladder, SFC, Logic Block, C, or whatever front end could be developed to generate a program that the Logic Engine executes.<
I would suggest a C interface directly to the flat-memory representation. Some programs really don't need to have the logic engine in the way...
(That would mean making sure more than one Logic Engine can run at a time, but that shouldn't be a great problem. Each engine only sets the outputs
that it has explicit values for, and leaves the rest to others.)
Jiri
--
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
