S
From: Simon Martin=20
To: Simon Martin=20
Sent: 11 January 2000 09:04
Subject: Re: LinuxPLC: Design (long)
Hi all,
Design take 3. Tanks for all the contributions. New bits:
a) four tier construction (LinuxPLC, iomap, interface, driver).
b) virtual interfaces (sotware modules) to generate counters/timers/etc,
making the LinuxPLC engine itself as simple as possible.
c) define the PLC as a state machine resolver.
Discussions required:
a) how do we define real time.
b) what data do we have to pass to a state transition function. what is
global, what is not.
Please read the definitions before replying.
1) Definitions
*) The PLC runs on VirtualIO (i.e. it lives in never, never land) with =
as
few restrictions as possible.
*) Immediate input processing would halt the scan, signal the PhysicalIO
mapping process to update the corresponding value, and wait for the =
value to be returned.
*) Immediate output processing would be signaled to the PhysicalIO =
mapping processes.
Scaling would be a requirement for the PhysicalIO process.
*) The mapping between VirtualIO and PhysicalIO is via a master process
(iomap) that assigns VirtualIO to PhysicalIO, a set of Interfaces that
implement the protocol with a given device (PLC, remote IO, etc), and a =
set of low level drivers. The master process is configured by the user
creating/modifying the /etc/iomap.conf file. This file contains the
VirtualIO <-> PhysicalIO equivalences, plus any additional data required =
to identify the module upon which the IO point actually resides.
*) The Interfaces implement all the required protocol to converse with =
an external module (could be software, could be hardware). The Interfaces =
use 0
or more hardware drivers. For example:
counters - external software module, increments on every scan
timers - external software module, signals on time
*) The hardware drivers implement the low level protocol to the io cards
inside the
*) There are 3 discrete memory areas. One is the input for the current =
scan,
the second is the outpur from the current scan and the data area for the
current reads from the PhysicalIO. The user is responsible for making =
sure
that the IO definition avoids stomping values. The iomap process can
generate warnings for this. The third memory area is the storage space =
for
the state machines.
*) At the start of a scan, the LinuxPLC process signals the iomap to =
read
data and processes any state machine updates. Once the iomap signals
completion, the input page is written to disk (non blocking) and the
LinuxPLC starts the scan. Immediate IO is transfered via the output =
page, so
as not to modify the data being written to disk. At the end of the scan =
the
iomap process is signaled to update the PhysicalIO units.
*) The LinuxPLC itself is a state machine resolver that works upon a set =
of
state machines. The states of each machine and the actions performed =
going
from one state to the next are defined by the programming language. =
Ladder
Logic generates a state machine that has only one state, but many
transitions to/from this state, the transition functions can be internal =
PLC
functions or external user written modules. State machine was chosen due =
to the fact that "any computable problem can be resolved by a state =
machine",
parameterisation is easily achieved, it is easy to debug, it easy to
generate status information (real time).
*) A set of compilers will convert from source language to state machine
definition. (Ladder to state, IL to state, Function Block to state)
generating the required information for monitoring and on line
modifications.
*) All the data in the state machines are arrays of pointers. This means
that any modifications to a state are handled in a free memory space and
updates are just changing pointers.
*) All memory must be assigned in fixed blocks. Once we have a =
definition
for the VirtualIO, StateMachine then we fix the block size. This will =
avoid
memory fragmentation and the need for scavenging.
2) VirtualIO Model
enum io_update_type { io_update_periodic, io_update_immediate_read,
io_update_immediate_write,
io_update_immediate_read_write };
enum io_value_type { io_value_bool, io_value_long, io_value_float };
struct tag_io_value {
enum io_value_type value_type; /* type of value */
union {
BOOLEAN b;
long l;
float f;
} data;
};
struct tag_io_point {
char point_tag[MAX_TAG];
char point_description[MAX_DESCRIPTION];
struct tag_io_value value;
};
struct tag_io_block {
enum io_update_type update_type; /* type of update */
long address_points; /* number of address points in =
this
block */
char block_tag[MAX_TAG];
char block_description[MAX_DESCRIPTION];
struct tag_io_point point[];
};
3) State Machine Model
enum condition_type { condition_standard, condition_function };
struct tag_condition {
enum condition_type type;
long io_point;
struct tag_io_value value;
BOOLEAN (*function)(struct tag_condition *this);
};
struct tag_event {
long conditions;
struct tag_condition *condition[];
long (*transition_function)(struct tag_event *this);
long next_status;
};
struct tag_state {
long events;
struct tag_event *event[];
};
struct tag_machine {
long states;
struct tag_state *state[];
};
__ _ Debian GNU User
/ /(_)_ __ _ ___ __ Simon Martin
/ / | | '_ \| | | \ \/ / Project Manager
/ /__| | | | | |_| |> < Isys
\____/_|_| |_|\__,_/_/\_\ mailto: [email protected]
There is a chasm of carbon and silicon the software cannot bridge
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
To: Simon Martin=20
Sent: 11 January 2000 09:04
Subject: Re: LinuxPLC: Design (long)
Hi all,
Design take 3. Tanks for all the contributions. New bits:
a) four tier construction (LinuxPLC, iomap, interface, driver).
b) virtual interfaces (sotware modules) to generate counters/timers/etc,
making the LinuxPLC engine itself as simple as possible.
c) define the PLC as a state machine resolver.
Discussions required:
a) how do we define real time.
b) what data do we have to pass to a state transition function. what is
global, what is not.
Please read the definitions before replying.
1) Definitions
*) The PLC runs on VirtualIO (i.e. it lives in never, never land) with =
as
few restrictions as possible.
*) Immediate input processing would halt the scan, signal the PhysicalIO
mapping process to update the corresponding value, and wait for the =
value to be returned.
*) Immediate output processing would be signaled to the PhysicalIO =
mapping processes.
Scaling would be a requirement for the PhysicalIO process.
*) The mapping between VirtualIO and PhysicalIO is via a master process
(iomap) that assigns VirtualIO to PhysicalIO, a set of Interfaces that
implement the protocol with a given device (PLC, remote IO, etc), and a =
set of low level drivers. The master process is configured by the user
creating/modifying the /etc/iomap.conf file. This file contains the
VirtualIO <-> PhysicalIO equivalences, plus any additional data required =
to identify the module upon which the IO point actually resides.
*) The Interfaces implement all the required protocol to converse with =
an external module (could be software, could be hardware). The Interfaces =
use 0
or more hardware drivers. For example:
counters - external software module, increments on every scan
timers - external software module, signals on time
*) The hardware drivers implement the low level protocol to the io cards
inside the
*) There are 3 discrete memory areas. One is the input for the current =
scan,
the second is the outpur from the current scan and the data area for the
current reads from the PhysicalIO. The user is responsible for making =
sure
that the IO definition avoids stomping values. The iomap process can
generate warnings for this. The third memory area is the storage space =
for
the state machines.
*) At the start of a scan, the LinuxPLC process signals the iomap to =
read
data and processes any state machine updates. Once the iomap signals
completion, the input page is written to disk (non blocking) and the
LinuxPLC starts the scan. Immediate IO is transfered via the output =
page, so
as not to modify the data being written to disk. At the end of the scan =
the
iomap process is signaled to update the PhysicalIO units.
*) The LinuxPLC itself is a state machine resolver that works upon a set =
of
state machines. The states of each machine and the actions performed =
going
from one state to the next are defined by the programming language. =
Ladder
Logic generates a state machine that has only one state, but many
transitions to/from this state, the transition functions can be internal =
PLC
functions or external user written modules. State machine was chosen due =
to the fact that "any computable problem can be resolved by a state =
machine",
parameterisation is easily achieved, it is easy to debug, it easy to
generate status information (real time).
*) A set of compilers will convert from source language to state machine
definition. (Ladder to state, IL to state, Function Block to state)
generating the required information for monitoring and on line
modifications.
*) All the data in the state machines are arrays of pointers. This means
that any modifications to a state are handled in a free memory space and
updates are just changing pointers.
*) All memory must be assigned in fixed blocks. Once we have a =
definition
for the VirtualIO, StateMachine then we fix the block size. This will =
avoid
memory fragmentation and the need for scavenging.
2) VirtualIO Model
enum io_update_type { io_update_periodic, io_update_immediate_read,
io_update_immediate_write,
io_update_immediate_read_write };
enum io_value_type { io_value_bool, io_value_long, io_value_float };
struct tag_io_value {
enum io_value_type value_type; /* type of value */
union {
BOOLEAN b;
long l;
float f;
} data;
};
struct tag_io_point {
char point_tag[MAX_TAG];
char point_description[MAX_DESCRIPTION];
struct tag_io_value value;
};
struct tag_io_block {
enum io_update_type update_type; /* type of update */
long address_points; /* number of address points in =
this
block */
char block_tag[MAX_TAG];
char block_description[MAX_DESCRIPTION];
struct tag_io_point point[];
};
3) State Machine Model
enum condition_type { condition_standard, condition_function };
struct tag_condition {
enum condition_type type;
long io_point;
struct tag_io_value value;
BOOLEAN (*function)(struct tag_condition *this);
};
struct tag_event {
long conditions;
struct tag_condition *condition[];
long (*transition_function)(struct tag_event *this);
long next_status;
};
struct tag_state {
long events;
struct tag_event *event[];
};
struct tag_machine {
long states;
struct tag_state *state[];
};
__ _ Debian GNU User
/ /(_)_ __ _ ___ __ Simon Martin
/ / | | '_ \| | | \ \/ / Project Manager
/ /__| | | | | |_| |> < Isys
\____/_|_| |_|\__,_/_/\_\ mailto: [email protected]
There is a chasm of carbon and silicon the software cannot bridge
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc