S
There has been an ongoing discussion about handling of various types of
memory that will be accessible by the user program processing control
logic. Let me clear, this is the memory as seen by the user program,
not memory as seen by the LinuxPLC core code itself.
Since this data is the interface between the various I/O engines, and
the various? user programming languages, I thought I would take a moment
and describe how this is done is existing PLC's
In general these are handled as files, consisting of elements of
various types. Typically there can be up to 1000 files of a given data
type. With some exceptions these files can consist of up to 1000 elements each.
Lets talk about the data types.
First we have Input data tables, these represent the status of real physical input devices. Typically these are treated as 16 bit words,
and handled on a bit by bit basis. The I/O scanner program reads real inputs and updates this data table. Before these inputs are mapped into the input data table visible by the logic processing engine, they are checked against "force tables" There is a force table location for each input bit. This location can have 1 of 3 states. These are "Force On, Force Off, Pass as read. These force tables can be enabled and disabled as a set.
Next we have outputs. These are again treated as 16 bit words of bits. The logic processing engine sets these values, the I/O scanner program the updates the real physical outputs based upon these states. These outputs also have corresponding force tables. The work like the ones for inputs except that the are checked by the I/O scanner program before updating the physical outputs.
Next we have integer data, normally 16 bit signed numbers.
Then we have floats.
Next there are 32 bit long integers.
Then we have binary data. This data in general is treated as long arrays of bits.
Then we have timer struts. These consist of a 16 bit word each forpreset, and accumulated values, and 16 bits of status, eg timer timing, timer done.
Counters are similar to timers, typical status bits include counter done, counter overflow etc.
These are the most common types, there are others such as PID control files, but i think it's to early to talk about them.
Can we get a consensus on these types?
--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.
--
_____________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
memory that will be accessible by the user program processing control
logic. Let me clear, this is the memory as seen by the user program,
not memory as seen by the LinuxPLC core code itself.
Since this data is the interface between the various I/O engines, and
the various? user programming languages, I thought I would take a moment
and describe how this is done is existing PLC's
In general these are handled as files, consisting of elements of
various types. Typically there can be up to 1000 files of a given data
type. With some exceptions these files can consist of up to 1000 elements each.
Lets talk about the data types.
First we have Input data tables, these represent the status of real physical input devices. Typically these are treated as 16 bit words,
and handled on a bit by bit basis. The I/O scanner program reads real inputs and updates this data table. Before these inputs are mapped into the input data table visible by the logic processing engine, they are checked against "force tables" There is a force table location for each input bit. This location can have 1 of 3 states. These are "Force On, Force Off, Pass as read. These force tables can be enabled and disabled as a set.
Next we have outputs. These are again treated as 16 bit words of bits. The logic processing engine sets these values, the I/O scanner program the updates the real physical outputs based upon these states. These outputs also have corresponding force tables. The work like the ones for inputs except that the are checked by the I/O scanner program before updating the physical outputs.
Next we have integer data, normally 16 bit signed numbers.
Then we have floats.
Next there are 32 bit long integers.
Then we have binary data. This data in general is treated as long arrays of bits.
Then we have timer struts. These consist of a 16 bit word each forpreset, and accumulated values, and 16 bits of status, eg timer timing, timer done.
Counters are similar to timers, typical status bits include counter done, counter overflow etc.
These are the most common types, there are others such as PID control files, but i think it's to early to talk about them.
Can we get a consensus on these types?
--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.
--
_____________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc