S
First let me apologize for not responding to specific mail messages, I seem to have corrupted the mail folder for this group :-(
Thanks Jiri for the tips on setting up elm, they helped a lot.
Curt, based upon your last message, it appears that you don't want to write a proposal for the design spec for the first version of this
project. OK, I will take a crack at it. This will be very brief, since it's really just to try to focus our ideas, and will need significant
fleshing out before we can start using it as a basis for writing code,
Here goes:
The (insert agreed upon name her) will be refereed to as the PLC for the rest of this document.
The PLC shall consist of a number of cooperating process. These process shall communicate with each other via shred memory segments. These shared memory segments will be discussed at greater length later in this document.
Run time tasks that will be needed, please note this does not include programming/editing/documentation functionality, even though they will be used at run time. The tasks listed below are the ones that will need
to be running, when the PLC is controlling the process/machine, and not being edited or examined by a person. Also note that not all of these
tasks must run for a given application. For example, if you don't need PID control, then you don't need to run the PID execution engine.
Also note that it is possible to run more than one of each of these. For example the I/O scanners will be hardware specific, thus if you
wanted to talk to AB RIO, and OPTO22, on the same PLC, you would need to run 2 different I/O scanners.
I/O scanner(s)
Logic engine(s)
Timer execution engine(s)
PID execution engine(s)
Counter execution engine(s)
Motion control engine(s)
Other tasks may be added as required.
Shared memory segments:
Shared memory segments will be of the following types:
I/O data table
Non I/O data table
Force Table(s) (one per I/O scanner program)
Input inversion tables (one per I/O scanner)
Interface between the tasks, and the shared memory segments will be by a standardized library. This library if called to access any segment, will create all of the segments defined in the config files, if it fails to find that they have already been created. This will avoid the need for a shared memory manager task.
The shared memory library calls will include a parameter which defines which logic engine you are, if you are a logic engine. This will be used to enforce "ownership" of real outputs. Thus only one logic engine can have control of a given real output. This cannot be changed without shutting the system down.
Some details about specific tasks
Logic engines may run any of several different programming languages (TBD). Where feasible, online editing of these will be provided. In all cases one line examination of run time status must be provided.
Data table details
Data tables shall use the AB syntax for declaring what type, file number, and element they are. Later support for user defined structs,
which must consist of aggregates of the predefined data types is planned.
Run time resizing of the data table files is a highly desirable feature.
OK guys, lay into it. raise your objections, and add your details, please
--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.
--
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
Thanks Jiri for the tips on setting up elm, they helped a lot.
Curt, based upon your last message, it appears that you don't want to write a proposal for the design spec for the first version of this
project. OK, I will take a crack at it. This will be very brief, since it's really just to try to focus our ideas, and will need significant
fleshing out before we can start using it as a basis for writing code,
Here goes:
The (insert agreed upon name her) will be refereed to as the PLC for the rest of this document.
The PLC shall consist of a number of cooperating process. These process shall communicate with each other via shred memory segments. These shared memory segments will be discussed at greater length later in this document.
Run time tasks that will be needed, please note this does not include programming/editing/documentation functionality, even though they will be used at run time. The tasks listed below are the ones that will need
to be running, when the PLC is controlling the process/machine, and not being edited or examined by a person. Also note that not all of these
tasks must run for a given application. For example, if you don't need PID control, then you don't need to run the PID execution engine.
Also note that it is possible to run more than one of each of these. For example the I/O scanners will be hardware specific, thus if you
wanted to talk to AB RIO, and OPTO22, on the same PLC, you would need to run 2 different I/O scanners.
I/O scanner(s)
Logic engine(s)
Timer execution engine(s)
PID execution engine(s)
Counter execution engine(s)
Motion control engine(s)
Other tasks may be added as required.
Shared memory segments:
Shared memory segments will be of the following types:
I/O data table
Non I/O data table
Force Table(s) (one per I/O scanner program)
Input inversion tables (one per I/O scanner)
Interface between the tasks, and the shared memory segments will be by a standardized library. This library if called to access any segment, will create all of the segments defined in the config files, if it fails to find that they have already been created. This will avoid the need for a shared memory manager task.
The shared memory library calls will include a parameter which defines which logic engine you are, if you are a logic engine. This will be used to enforce "ownership" of real outputs. Thus only one logic engine can have control of a given real output. This cannot be changed without shutting the system down.
Some details about specific tasks
Logic engines may run any of several different programming languages (TBD). Where feasible, online editing of these will be provided. In all cases one line examination of run time status must be provided.
Data table details
Data tables shall use the AB syntax for declaring what type, file number, and element they are. Later support for user defined structs,
which must consist of aggregates of the predefined data types is planned.
Run time resizing of the data table files is a highly desirable feature.
OK guys, lay into it. raise your objections, and add your details, please
--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.
--
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc