Design (long) - take 3

S

Thread Starter

Simon Martin

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
 
P

Phil Covington

----- Original Message -----
From: Simon Martin

<snip>

>*) 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.

Are you proposing that the user would create this /etc/iomap.conf file? I would hope that the user would not have to know anything about the layout
of virtual memory. The driver should request that the "iomap" process map the driver
into virtual memory with the actual locations in virtual memory decided by the "iomap" process and not the user.

I would rather see a /etc/iodrv.conf file that the user creates which lists the drivers to be loaded, the driver's settings, and the valid i/o addresses that the drivers support. There could be a seperate tag database or file that ties the tag names and descriptions to the driver i/o
addresses. The memory manager could take care of loading the drivers, asking the drivers to validate the requested i/o addresses as given in the iodrv.conf and tag database files, and mapping the driver i/o addresses into the controller virtual memory. The selected logic engine could have access to the tag database and operate on the tags though the memory manager. The memory manager knows which tag is represented by which virtual memory location - the controller logic engine doesn't have to know about the
virtual memory. When the controller logic engine writes to a particular tag, the memory manager finds its virtual memory address and writes the
value into virtual memory and also notifys the responsible driver that it needs to update the i/o point. A virtual driver could be also loaded by the memory manager to handle requests for writes (and reads) from tags that don't actually connect to the outside world. The actual values only change and are stored in (and can be persisted from) virtual memory ; kind of like
the internal coils and register locations in a PLC.

Let the driver determine whether its i/o addresses are polled or interrupt driven. If your control engine wants to scan tags like ladder logic then let it scan the controller's virtual memory through the memory manager. If
you want an event driven logic engine, have the memory manager notify the logic engine when an interesting change occurs on its tag.

<more snipped>

>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[];
>};

I don't think it is a good idea to store IO tags and descriptions in the virtual memory area. Also I don't think it is a good idea to impose a complex structure on the virtual memory area. I would hope that the only object that has access to virtual memory would be the memory manager ("iomap process") - all access to virtual memory is through the memory manager whether it's from the driver's point of view or the logic engine's point of view.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S

Simon Martin

Taking this a little further, why have a io scan structure at all. The only IO that has to be brought in fresh is the stuff that is marked as immediate, all the rest will be updated periodically. As the actual io processes are
independent from the PLC engine they can run at whatever rate they are programmed for. The results are written to the current output page, which will become the input page for the next PLC scan. All IO will work at its' optimum rate. It also makes it independent of however many Logic programs are running.

With respect the PLC core, this run's some code generated in some way that will interface with IO. If we want full generality we need to create
compilers <xxx> to an intermediate language (and then to assembler) or directly to assembler. The <xxx> language would have certain extensions to
handle IO in the case languages that aren't designed for it, i.e. 'C', BASIC, etc.

Debian GNU User
Simon Martin
Project Manager
Isys
mailto: [email protected]

There is a chasm of carbon and silicon the software cannot bridge

----- Original Message -----
From: Ken Crater

Simon said:
>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.

I guess I'm uncomfortable with this model (as elaborated) for a number of reasons: ...<clip>

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
R

R A Peterson

In a message dated 01/13/2000 06:56:15 PM Central Standard Time,
[email protected] writes:

<< Taking this a little further, why have a io scan structure at all. The only
IO that has to be brought in fresh is the stuff that is marked as immediate,
all the rest will be updated periodically. As the actual io processes are
independent from the PLC engine they can run at whatever rate they are
programmed for. The results are written to the current output page, which
will become the input page for the next PLC scan. All IO will work at its'
optimum rate. It also makes it independent of however many Logic programs
are running.

With respect the PLC core, this run's some code generated in some way that will interface with IO. If we want full generality we need to create
compilers <xxx> to an intermediate language (and then to assembler) or directly to assembler. The <xxx> language would have certain extensions to
handle IO in the case languages that aren't designed for it, i.e. 'C',
BASIC, etc.
>>

The reason to have the inputs scanned before executing the program and setting the outputs afterward is twofold:

1) All PLCs do it that way (except a few that allow you some control over when I/O is serviced or via immediate I/O instructions). If you are going to have a PLC it should work like a PLC.

2) Sometimes it matters if an input will gets set mid-scan. This could create all kinds of unintentional scan races.

One other thing on the I/O structure. I would like to see a "one-shot" bit. This bit would come on with the input but only stay on for onescan. A similar bit would also be available for output bits.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Phil Covington wrote:
> ----- Original Message -----
> From: Simon Martin
>
> <snip>
>
> >*) 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.
>
> Are you proposing that the user would create this /etc/iomap.conf file?
> I would hope that the user would not have to know anything about the layout
> of virtual memory. The driver should request that the "iomap" process map
> the driver
> into virtual memory with the actual locations in virtual memory decided by
> the "iomap"
> process and not the user.

I think the idea was to say "input 001 => device YZ1 rack 1 point 3;
input 002 => device YZ1 rack 1 point 4" etc. (maybe not that syntax, but
then again maybe yes).

In the above, "input 001", "input 002" etc are VirtualIO, while YZ1:1:3
and YZ1:1:4 are PhysicalIO.

> I don't think it is a good idea to store IO tags and descriptions in the
> virtual memory
> area.

Hence the use of numbered inputs and outputs.

> Also I don't think it is a good idea to impose a complex structure on
> the virtual
> memory area. I would hope that the only object that has access to virtual
> memory would
> be the memory manager ("iomap process") - all access to virtual memory is
> through the memory manager whether it's from the driver's point of view or
> the logic engine's point of view.

I think we are overloading the term "Virtual" here. Unfortunately I can't think of a better word straight off.


Jiri

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
On Thu Jan 13 20:51:46 2000 Simon Martin wrote...
>
>Taking this a little further, why have a io scan structure at all. The only
>IO that has to be brought in fresh is the stuff that is marked as immediate,
>all the rest will be updated periodically. As the actual io processes are
>independent from the PLC engine they can run at whatever rate they are
>programmed for. The results are written to the current output page, which
>will become the input page for the next PLC scan. All IO will work at its'
>optimum rate. It also makes it independent of however many Logic programs
>are running.

This has beeen done. Primarily in some older controlers, and then again, as an option in some high end comtrolers. In general asynch. I/O
make for harder application programing. I don't think it should be the only choice.

--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
K
On Thu, Jan 13, 2000 at 08:03:09PM -0500, [email protected] wrote:

> The reason to have the inputs scanned before executing the program and
> setting the outputs afterward is twofold:
>
> 1) All PLCs do it that way (except a few that allow you some control over
> when I/O is serviced or via immediate I/O instructions). If you are going to
> have a PLC it should work like a PLC.

I think there's a chance that this will not be a PLC, but rather a machine that can be (or become, or be used as) a PLC. The end result could work
exactly like a PLC, but it could also work in other ways depending on the "brains" associating input and outputs.


...
> One other thing on the I/O structure. I would like to see a "one-shot" bit.
> This bit would come on with the input but only stay on for onescan. A similar
> bit would also be available for output bits.

That sounds like a task that the PLC engine could handle. The very notion of a scan could be left up to the PLC engine to implement, while another type of controller might not have a use for it, and perhaps might have a use for asynchronous I/O.

--
Ken Irving
Trident Software
[email protected]


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S

Simon Martin

I would use sockets to talk between different parts of the system, but not for control. Use shared memory for the time critical parts of the code. Sockets are serial data (PLC requires datapoint 5, sends request, receives data processes, now required datapoint 7, etc.) which would slow things down, but monitoring, programming, etc. should all be sockets

Debian GNU User
Simon Martin
Project Manager
Isys
mailto: [email protected]

There is a chasm of carbon and silicon the software cannot bridge

----- Original Message -----
From: nick

As for Design ( long), it might be nice if the i/o used sockets to talk to the control process. Also , if the control process has a set of
public tables ( pass worded ) it will look like a remote i/o rack. This will enable encapsulation of i/o with logic.

1,000,000,000 I/O points might be good if you collect data for a big plant. No, I don't want to read all of them each scan.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
On Fri Jan 14 11:22:27 2000 nick wrote...
>
>As for Design ( long), it might be nice if the i/o used sockets to talk
>to the control process. Also , if the control process has a set of
>public tables ( pass worded ) it will look like a remote i/o rack. This
>will enable encapsulation of i/o with logic.

I think we have agreed on having I/O data tables (shared memory ?) that are updated by the various I/O scanner processes, and used by the
various logic engines.


--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.
--

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Simon Martin:
> >Taking this a little further, why have a io scan structure at all. The
> >only IO that has to be brought in fresh is the stuff that is marked as
> >immediate, all the rest will be updated periodically.
...
> >The results are written to the current output page, which will become
> >the input page for the next PLC scan. All IO will work at its' optimum
...

Stan Brown:
> This has beeen done. Primarily in some older controlers, and then
> again, as an option in some high end comtrolers. In general asynch.
> I/O make for harder application programing. I don't think it should
> be the only choice.

I think Simon meant that while IO would work at its own rate, as far as the PLC program is concerned new inputs would only arrive at the beginning of each scan. No asynch programming required.

Basically, scanning time is reduced to zero at the expense of latency.


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
 
On Sun Jan 16 07:22:52 2000 Jiri Baum wrote...
>
>Simon Martin:
>> >Taking this a little further, why have a io scan structure at all. The
>> >only IO that has to be brought in fresh is the stuff that is marked as
>> >immediate, all the rest will be updated periodically.
>...
>> >The results are written to the current output page, which will become
>> >the input page for the next PLC scan. All IO will work at its' optimum
>...
>
>Stan Brown:
>> This has beeen done. Primarily in some older controlers, and then
>> again, as an option in some high end comtrolers. In general asynch.
>> I/O make for harder application programing. I don't think it should
>> be the only choice.
>
>I think Simon meant that while IO would work at its own rate, as far as the
>PLC program is concerned new inputs would only arrive at the beginning of
>each scan. No asynch programming required.
>
>Basically, scanning time is reduced to zero at the expense of latency.

If thats what he meant, I can buy into that.

Jut remember to provide a semaphore locking mechnism, so the various tasks can lock the I/O data table shared memory segments as needed.

--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
Thanks Jiri,

That's exactly what I meant.

Debian GNU User
Simon Martin
Project Manager
Isys
mailto: [email protected]

There is a chasm of carbon and silicon the software cannot bridge

----- Original Message -----
From: Jiri Baum

Simon Martin:
> >Taking this a little further, why have a io scan structure at all. The
> >only IO that has to be brought in fresh is the stuff that is marked as
> >immediate, all the rest will be updated periodically.
...
> >The results are written to the current output page, which will become
> >the input page for the next PLC scan. All IO will work at its' optimum
...

Stan Brown:
> This has beeen done. Primarily in some older controlers, and then
> again, as an option in some high end comtrolers. In general asynch.
> I/O make for harder application programing. I don't think it should
> be the only choice.

I think Simon meant that while IO would work at its own rate, as far as the
PLC program is concerned new inputs would only arrive at the beginning of
each scan. No asynch programming required.

Basically, scanning time is reduced to zero at the expense of latency.


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


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top