Linux PLC: ISA Article and a Charter of sorts(long)

Curt Wuollet:
> What do we do about intelligent I/O that presents in IEEE floats, for example. And we need to deal with some weird data types for stuff like I've got that can be boolean or integer. What people tend to do is model with 16bit regs and you simply read more or less of them and do the translation. A node struct will need a type member so the PLC "Knows" what it's dealing with or how do we abstract that?.<

I vote they should be converted to a native format. This ties in with point (5) below.

An interface to the raw data should be available, but not encouraged.

Simon Martin:
> > 2) PLC engine.
> >
> > The PLC engine runs a set of rules on the IO to generate the output. Again, let's define a model. A simple model I can think of is the status of one or more outputs is defined the status of one or more inputs, this would translate
as: ...
The io may be physical or virtual. The IO is stored in shared memory. < <

You'll probably find that to be a very limiting model; despite what ladder pretends, it doesn't actually do that :)

I would suggest that initially at least the interface be in ordinary C. We'll want the thing to be programmable in C (among other things) and
it's much easier to translate a ruleset into C than the other way around. (Not to mention the performance advantage.)

> > 4) The PLC Engine knows nothing about programming languages.
> >
> > A set of middleware translators are written to go between the PLC engine representation and any programming language (Ladder, etc). < <

Yes. (In fact, the PLC engine should probably be in a separate process.)

> > 3) IO to Physical IO mapping
> >
> > A set of processes map the virtual IO to physical IO and feed the corresponding drivers. This process is user configurable via the file
/etc/iomap.conf, which defines IO range, IO driver responsible and any other data required by the driver to identify the physical IO module.< <

Curt Wuollet:
> (3) sounds fine, some of this will can loaded to the map on init.<

Yes. Don't forget that it should be able to add and remove drivers on-line. (Probably easiest to have them as separate processes again - we
can always make them loadable later.)

> > 5) Keep everything isolated via abstraction models.
> >
> > OK we all bash MS Windows NT, but I think one of the greatest things to come out of it is the HAL (Hardware Abstraction Layer). This presents all the rest of the operating system with a "concept of a computer", < <

Note that it goes the other way, too: it presents the hardware driver with a "concept of a control program", regardless of what language the
control program is in.


Jiri

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

Firstly I apologize for sending in HTML format. I won't do it again. Secondly taking on board the suggestions from Curt Wuollet,
PETERSONRA, Jiri Brown, Stan Brown, Alan Locke, I modify my original post. If others have replied, I'm sorry but I just have not
read them yet.

<snip>
>1) IO
>
>Let's define an IO model. As far as I can see (please correct me if I'm wrong) the >type of IO that is available is analog (12/16
bit)/digital, periodic/immediate >update. If these are the only requierements then I would suggest that an IO node >would be defined
adequately by:
>
>enum io_update_type { io_update_periodic, io_update_immediate };
>
>struct tag_io {
> enum io_update_type update;
> long value;
>};

This is changed to:

enum io_update_type { io_update_periodic, io_update_immediate };
enum io_value_type { io_value_bool, io_value_long, io_value_float };

struct tag_io_point {
enum io_value_type value_type; /* type of value */
char point_tag[MAX_TAG];
char point_description[MAX_DESCRIPTION];
union {
BOOL b;
long l;
float f;
} 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[];
};

Immediate input processing would be signaled from the IO mapping processes.
Immediate output processing would be signaled to the IO mapping processes.
Scaling would be a requirement for the PhysicalIO process.
The mapping between VirtualIO and PhysicalIO is a user dependant thing. We cannot force people to do one thing or another, if they
want to create a discontinuous map, there may be a very good reason for it (futur enhancements, etc.) and so we can't say no to
them.
If we create an IO block to represent a different PLC, how would we express it in terms of what we have got above, just as another
1000 points?

There are 2 discrete memory areas. One is the input for current scan area, the second is the output from current scan area and data
read from the physical io. They are rotated (just pointers being shuffled), with no data copying except that caused by the scan
itself. What happens here if the PLC writes to a value being read from the inputs? Registers must be separeted into Input/Output I
suppose.

>2) PLC engine.
>
>The PLC engine runs a set of rules on the IO to generate the output. Again, let's >define a model. A simple model I can think of is
the status of one or more outputs >is defined the status of one or more inputs, this would translate as:
<snip>
>The io may be physical or virtual. The IO is stored in shared memory.

Please correct me in this, this is the shakiest bit of my knowledge as I work in R&D in motion control, a combination of input
values will cause an action. The action can be set outputs, perform a function. This function can be an internal function block
written by us for the LinuxPLC, or an external binary written by the user for the LinuxPLC. Either way it resolves to a bit of code.
Are there any more variants to be taken care of?

As mere interest at this moment, if the PLC is signaled for the immediate change of a value mid-way through a scan, do we reset the
scan, just do the change, which may create an inconsistent view of the input conditions.

>3) IO to Physical IO mapping
>
>A set of processes map the virtual IO to physical IO and feed the corresponding >drivers. This process is user configurable via the
file /etc/iomap.conf, which >defines IO range, IO driver responsible and any other data required by the driver to >identify the
physical IO module.
>

I think we all agree here.

>4) The PLC Engine knows nothing about programming languages.
>
>A set of middleware translators are written to go between the PLC engine >representation and any programming language (Ladder,
etc). This has the advantage of >being able to see the program as I like it, if I understand IL, I see it as IL, if I >understand
Ladder, I see it as ladder. A standard annotation format must be >developed to be able to transport non-executable information from
one format to >another.

This is a set of external programs that precompile the incoming code to a standard set of rules run by the PLC. They are not to be
seen as "interpreters", they are "compilers". This is one of the reasons why we must create a very good rule model, as everything
interfaces with this.

>5) Keep everything isolated via abstraction models.
>
>OK we all bash MS Windows NT, but I think one of the greatest things to come out of >it is the HAL (Hardware Abstraction Layer).
This presents all the rest of the >operating system with a "concept of a computer", filling in the blanks where >required,
translating where required. I would hope that this would be one of the >goals. The PLC just understands conditions and io, other
processes understand >Ladder, ModBus, DH, DH+, etc.

As I mentioned earlier, I work in motion control. The company I work for as consultant has various axis interface cards (servo with
incremental encoder, servo with absolute encoder, servo with resolver, stepper encoder, stepper, analog out, etc), any combination
of which can be loaded in a controller. At the moment the low level servo code is full of exceptions caused by the fact that this
card works like this, this one doesn't, etc. It works very well, but maintenance is a nightmare as you are never really sure what a
change will incurr. Here we have a real nightmare, how many combinations can we have?

Again, your comments please.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Mon Jan 10 07:40:50 2000 Simon Martin wrote...
>
>Hi all,
>
>Firstly I apologize for sending in HTML format. I won't do it again. Secondly taking on board the suggestions from Curt Wuollet,
>PETERSONRA, Jiri Brown, Stan Brown, Alan Locke, I modify my original post. If others have replied, I'm sorry but I just have not
>read them yet.
>
><snip>
>>1) IO
>>
>>Let's define an IO model. As far as I can see (please correct me if I'm wrong) the >type of IO that is available is analog (12/16
>bit)/digital, periodic/immediate >update. If these are the only requierements then I would suggest that an IO node >would be defined
>adequately by:
>>
>>enum io_update_type { io_update_periodic, io_update_immediate };
>>
>>struct tag_io {
>> enum io_update_type update;
>> long value;
>>};
>
>This is changed to:
>
>enum io_update_type { io_update_periodic, io_update_immediate };
>enum io_value_type { io_value_bool, io_value_long, io_value_float };
>
>struct tag_io_point {
> enum io_value_type value_type; /* type of value */
> char point_tag[MAX_TAG];
> char point_description[MAX_DESCRIPTION];
> union {
> BOOL b;
> long l;
> float f;
> } 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[];
>};
>
>Immediate input processing would be signaled from the IO mapping processes.
>Immediate output processing would be signaled to the IO mapping processes.

Both imediat inputs, and imediate ouptuts are trigered from the
application program. In the case of imediate inputs, the application
program waits on a fresh set of data, befre proceding. In the case of
imediate outputs, I am not certain if existing PLC's wait for this to
coomplete before resuming execution of the application program, but I
don't really see any reason a Linux Based PLC (which might be runing on
a multiprocessor machine) should do this.

>Scaling would be a requirement for the PhysicalIO process.
>The mapping between VirtualIO and PhysicalIO is a user dependant thing. We cannot force people to do one thing or another, if they
>want to create a discontinuous map, there may be a very good reason for it (futur enhancements, etc.) and so we can't say no to
>them.
>If we create an IO block to represent a different PLC, how would we express it in terms of what we have got above, just as another
>1000 points?

How about PLC_ID:MEMORY_LOCATION ?
>
>There are 2 discrete memory areas. One is the input for current scan area, the second is the output from current scan area and data
>read from the physical io. They are rotated (just pointers being shuffled), with no data copying except that caused by the scan
>itself. What happens here if the PLC writes to a value being read from the inputs? Registers must be separeted into Input/Output I
>suppose.

This used to be common. What happens, is that if physicall inputs have
been maped to this area, the user writen vaule is overwriten on the
next input scan. If however, there is no maping of that particular
input address to physical inputs the value will stay ther.

Which brings up the pint, that all data table needs to non-volatile, IE
if the sysstem goes down, all data table values should be init'd to the
last values, before the application program is re-enabled.

Also don't forget about non-I/O data table.
>
>>2) PLC engine.
>>
>>The PLC engine runs a set of rules on the IO to generate the output. Again, let's >define a model. A simple model I can think of is
>the status of one or more outputs >is defined the status of one or more inputs, this would translate as:
><snip>
>>The io may be physical or virtual. The IO is stored in shared memory.
>
>Please correct me in this, this is the shakiest bit of my knowledge as I work in R&D in motion control, a combination of input
>values will cause an action. The action can be set outputs, perform a function. This function can be an internal function block
>written by us for the LinuxPLC, or an external binary written by the user for the LinuxPLC. Either way it resolves to a bit of code.
>Are there any more variants to be taken care of?

Just please don't forget the run time statuses must be visible in the
language that they were programed in (ladder for instance), and that it
must be possible to edit this application code, in the original
language at run time. This should be done as an "edit set" whch can be
switched in and out very easily. This is required for testing run time
changes, and being able to back out of them very fast.

>
>As mere interest at this moment, if the PLC is signaled for the immediate change of a value mid-way through a scan, do we reset the
>scan, just do the change, which may create an inconsistent view of the input conditions.
>

The scan should see the value of the imnputs that ws true at the
begining of the scan. if I do an imediate input the values are updated,
and the scan is continued from there. Never shouls the system restart
the scan from the begining on it's own!

>>3) IO to Physical IO mapping
>>
>>A set of processes map the virtual IO to physical IO and feed the corresponding >drivers. This process is user configurable via the
>file /etc/iomap.conf, which >defines IO range, IO driver responsible and any other data required by the driver to >identify the
>physical IO module.
>>
>
>I think we all agree here.
>
>>4) The PLC Engine knows nothing about programming languages.
>>
>>A set of middleware translators are written to go between the PLC engine >representation and any programming language (Ladder,
>etc). This has the advantage of >being able to see the program as I like it, if I understand IL, I see it as IL, if I >understand
>Ladder, I see it as ladder. A standard annotation format must be >developed to be able to transport non-executable information from
>one format to >another.
>
>This is a set of external programs that precompile the incoming code to a standard set of rules run by the PLC. They are not to be
>seen as "interpreters", they are "compilers". This is one of the reasons why we must create a very good rule model, as everything
>interfaces with this.

I don't see how they can be compilers, and give the run time viewing,
and editing that is required. I don't object to compiling the code, I
just want to make certain we don't miss the basic functionality here.

>
>>5) Keep everything isolated via abstraction models.
>>
>>OK we all bash MS Windows NT, but I think one of the greatest things to come out of >it is the HAL (Hardware Abstraction Layer).
>This presents all the rest of the >operating system with a "concept of a computer", filling in the blanks where >required,
>translating where required. I would hope that this would be one of the >goals. The PLC just understands conditions and io, other
>processes understand >Ladder, ModBus, DH, DH+, etc.
>
>As I mentioned earlier, I work in motion control. The company I work for as consultant has various axis interface cards (servo with
>incremental encoder, servo with absolute encoder, servo with resolver, stepper encoder, stepper, analog out, etc), any combination
>of which can be loaded in a controller. At the moment the low level servo code is full of exceptions caused by the fact that this
>card works like this, this one doesn't, etc. It works very well, but maintenance is a nightmare as you are never really sure what a
>change will incurr. Here we have a real nightmare, how many combinations can we have?

I don't understand the question. Please resate.


--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.
--
______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
D
> From: Curt Wuollet [mailto:[email protected]]
> Subject: Re: LinuxPLC: Linux PLC: ISA Article and a Charter of
> sorts(long)

> I am primarily concerned with doing things so as to take the best
> advantage of the Linux environment for performance and efficency
> reasons and so we don't write an operating system in the process.

Absolutely!

> My interest is in a solid foundation so that people have a framework
> to add to and test ideas. My expertise, (such as it is) is in hardware
> and system software. I would probably enjoy using C instead of ladder.
> You guys are the experts on what you want to DO with the thing.
> Together we should make a great team. I can probably code a ladder
> language or a state language if neccessary, but I am really hoping
> someone who knows more about them (like Ken C :^)) Will do that.

I'm the main designer and a major implementor of our Quickstep products so
I'll try to help a little :). My main main expertise is in development
languages and tools in general; I'm a relative newbie to automation (been
here about 7 years).

Fundamentally, I seriously doubt that mapping a state language like a
cleaned up Quickstep into an RLL/IEC1131 fixed processing loop is a
realistic goal. For example: Quickstep performs only the required IO at the
time that it's required. Some IO takes significant time to read or write
and we can't afford to waste it.

It is very desirable for this project to support both types of languages.
To do that, I think that we need to separate the RTLinux/kernel support for
industrial IO from the support for the PLC programming cycle. Some types of
programming cycle support will probably also have to be in RTLinux or kernel
for adaquate performance in some applications (is that weasily enough for
you :)). A basic PLC cycle might be one of these. Since I agree that
writing end user apps in kernel mode is a very bad idea, I suspect that
languages such as state based languages with complex processing cycles will
best be implemented by an RTLinux bytecode interpreter for a specialized
abstract machine. It would be easier on all of us if there were as few of
these abstract machines as possible, but the minumum realistic number is
probably greater than one.

As a first step, I'm serious considering trying to hook one or more of the
free scripting languages available on Linux (starting with Python) to your
initial PLC core. This may seem silly: "such an approach can't possibly
offer real time performance". Not for many applications, maybe for some,
but that's not the important point. The idea would be to provide test bed
on which we could simply prototype some of the candidates for lower level
abstract machines. Does this sound crazy to everyone else?

Ken Irving says:
> > A description of some of the workings of different PLCs might be
> > useful. Is there a simple statement of what _a_PLC_ is and does,
> > matching all the varieties available?

This is really a key question:
If the definition of "PLC" is limited to something with a fixed:

scan inputs
compute logic (maybe with function block kludges)
set outputs

Then I see this project as limiting itself to technology that was at least
obsolecent when Linux was invented. While it's important to support that
technology, and I realize that some members of this list are interested in
nothing else, it's at least equally important to provide for evolution to
more modern and effective approaches. Yes, we at Control Tech believe that
we have one of these. I *do not* believe that it's the only possible one,
nor am I trying to push it as part of the LinuxPLC, but I think that it
would be a serious long term mistake to make such approaches excessively
difficult to fit into this project.

<Asbestos On>

Dan Pierson
Control Technology Corp.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Mon, Jan 10, 2000 at 11:02:45AM -0500, Stan Brown wrote:
> On Mon Jan 10 07:40:50 2000 Simon Martin wrote...
> >
(snip)
>
> >Please correct me in this, this is the shakiest bit of my knowledge as I work in R&D in motion control, a combination of input
> >values will cause an action. The action can be set outputs, perform a function. This function can be an internal function block
> >written by us for the LinuxPLC, or an external binary written by the user for the LinuxPLC. Either way it resolves to a bit of code.
> >Are there any more variants to be taken care of?
>
> Just please don't forget the run time statuses must be visible in the
> language that they were programed in (ladder for instance), and that it
> must be possible to edit this application code, in the original
> language at run time. This should be done as an "edit set" whch can be
> switched in and out very easily. This is required for testing run time
> changes, and being able to back out of them very fast.

(snip)

> >>4) The PLC Engine knows nothing about programming languages.
> >>
> >>A set of middleware translators are written to go between the PLC engine >representation and any programming language (Ladder,
> >etc). This has the advantage of >being able to see the program as I like it, if I understand IL, I see it as IL, if I >understand
> >Ladder, I see it as ladder. A standard annotation format must be >developed to be able to transport non-executable information from
> >one format to >another.
> >
> >This is a set of external programs that precompile the incoming code to a standard set of rules run by the PLC. They are not to be
> >seen as "interpreters", they are "compilers". This is one of the reasons why we must create a very good rule model, as everything
> >interfaces with this.
>
> I don't see how they can be compilers, and give the run time viewing,
> and editing that is required. I don't object to compiling the code, I
> just want to make certain we don't miss the basic functionality here.

There are options in between interpreting and compiling in modern systems,
and this can cloud the issue. Perl interprets code at runtime, but it
first compiles (whether to native or some pcode I'm not sure). Actual
(simple) runtime interpreters involve parsing text continuously, and
surely the PLC engine won't do that.

> >>5) Keep everything isolated via abstraction models.
> >>
> >>OK we all bash MS Windows NT, but I think one of the greatest things to come out of >it is the HAL (Hardware Abstraction Layer).
> >This presents all the rest of the >operating system with a "concept of a computer", filling in the blanks where >required,
> >translating where required. I would hope that this would be one of the >goals. The PLC just understands conditions and io, other
> >processes understand >Ladder, ModBus, DH, DH+, etc.
> >
> >As I mentioned earlier, I work in motion control. The company I work for as consultant has various axis interface cards (servo with
> >incremental encoder, servo with absolute encoder, servo with resolver, stepper encoder, stepper, analog out, etc), any combination
> >of which can be loaded in a controller. At the moment the low level servo code is full of exceptions caused by the fact that this
> >card works like this, this one doesn't, etc. It works very well, but maintenance is a nightmare as you are never really sure what a
> >change will incurr. Here we have a real nightmare, how many combinations can we have?
>
> I don't understand the question. Please resate.

It sounds to me that the low level code in question was developed
under some set of assumptions, or based on one or more target card
models. Then, to accomodate other cards, some sort of conditionals
(or run time exceptions) cause branching/subbing to handle different
special cases. I think he (Simon?) is hoping this does not happen in
the Linux PLC project.

I don't know if a single PLC engine can accomodate all the options, i.e.,
to emulate existing PLCs or other models as they may come along. If
it can, then a specific PLC model might be cleanly represented by
a translator, which would actively link to the PLC engine and visa
versa. An alternative approach might be to completely swap out the
PLC engine with one that specifically targets one (or more) PLC models.
The nightmare approach would be to have a single engine which runs all
the models by conditionals or exceptions. Just my $0.02.

--
Ken Irving
Trident Software
[email protected]


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Hi Phil,

Yes I would expect that. But please read and understand your EULA and the GPL. That's why proposed policy differs from my personal opinion. Fragmentation at this stage will almost guarantee failure. That's why I simply ask that we have a system to port first. Who knows? We might be successful enough to get blown out of the water by MicroSoft(tm.) ControlX(tm.) Version 1.0

_______________________________________________

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

Phil Covington

I was not proposing that coding should be done to the least common denominator... If it is coded for Linux then the ideas behind the code design can be used to code for other operating systems.

What I was alluding to is that using terms like "Windoze", "Microsloth", and "lose32" is silly and childish. A better place for that would be in the OS advocacy newsgroup. If this is to be a truly "open" project, then why would anyone care what operating system it was ported to, proprietary or not? All I am saying is that this is not a trivial project and so it would be better
not to alienate potential coders by adopting a snooty "my operating system is better (or more open) than your operating system" attitude in this group.

Phil Covington (L[ose]nix and Windoze Programmer <grin>)
vHMI

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

Phil Covington

Curt,

I totally agree that this system should be developed under Linux and that Linux is the best OS to get a system like this up and running. The system then could be ported to what ever OS you might have need to use. It is just my observation that many people are turned off to the idea of changing to Linux by the overzealous pro-Linux advocates that love to bash MS... Look
at all the soft-PLC packages out there available for Win NT... to get companies to adopt the LinuxPLC it will take much more than casting a few
dispersions directed at Microsoft and Windows.

I have been using Linux with the KURT v1.23 (and now v2.0) patch for a soft-PLC like system. Since I wanted to be able to communicate via ethernet to a Host Engineering EBC module and Automation Direct I/O I didn't use RT-Linux. I now see that there is a PCI ethernet realtime driver available for RT-Linux though... I contacted Host Engineering and requested their
Ethernet SDK source code so that I could port it to Linux. The control program is written in C as a RTMOD and is loaded or unloaded from the kernel as needed. Unfortunately I have not gotten around to writing a Ladder to C translator yet that then could be compiled to a RTMOD. I have also had good luck with using Opto 22's SNAP with the system. Right now I am trying to figure out how to talk to Optimation's Opti-Logic ethernet system since they only have a Windows SDK available. Lots of fun...

Phil Covington
vHMI

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Peace please gentlemen. I have been trying hard to stay out of religion and I apologize for using the term windoze after a long and frustrating
day. For the purposes of this project, I hwve been grouping it under proprietary operating systems to be non-discriminatory. We seem to all
agree that Linux is the platform for now, the other discussion IS more suitable for Slashdot. Let's beat the swords into plowshares and direct
the zeal into fleshing out the memory map. For my part, I will try not to editorialize. The ControlX thing was (I hope) a joke. Any comments
on Fred's paper? I don't see a need for the ring buffering, but the rest seems like a good way to be as flexible as possible.

The Modbus map I am doing is a struct of arrays grouped by type, digital ins are unsigned short as are digital outs. The modbus holding registers and some other feature registers are Unsigned
int. Analog ins, highs and lows are float and there are some other misc types. The idea was to group the arrays that would be scanned
individually and seperate from the items that would be set on initialization. The grouping by type will allow a function to be written for each type. Because the arrays have to accomodate a full
map and the most that the physical rack will hold is 64 points, I'm using another array to hold the limits to short circuit the scan to addresses actually occupied.

The part I am pondering right now is how to tie the data to a Modbus address. The map can be non contiguous so I either have to use a 2xn array and store data and address in the pair or
declare structs like below and use arrays of the structs.

#define BASE_ADDRESS 0xXXXXXX

typedef struct
{
unsigned short data;
int address;
} D_PT;

typedef struct
{
unsigned int data;
int address;
} A_OUT;
.
.
.

typedef struct
{
D_PT d_pts[256];
A_OUT a_outs[128];
.
.
.
int limits[8][2]; /* These would be the first and last array member filled */
} RACK

struct
{
RACX rack_0;
RACK rack_1;
.
.
.
} modmap;


That would be my drivers map. The next drivers map would start at

BASE_ADDRESS + sizeof(modmap);


This is workable I think but will be confusing to dereference.

Comments?



Curt Wuollet

struct

Curt Wuollet,
Wide Open Technologies

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/
 
On the DL205 from AutomationDirect (Koyo) and I think most PLCs, the routing is
1. Scan inputs
2. Implement logic
3. Set outputs
Additionally, the DL205 (and the SLC50x, if I remember correctly) gives you "Immediate Inputs" and "Immediate Outputs".

Also, Intellution's FIX (also Wonderware, I believe) lets you indicate which "registers" (tags) to update and how often.

I see a way that we might integrate these two things, allowing for very scalable I/O memory. We could allow the application program to indicate
which I/O ranges to control, and when; i.e. define blocks of memory (an I/O database table, for instance) and offer a time-based daemon entry
(cron-like, but on a millisecond scale?), or even a "scan flag" set from user logic that says "get this block of inputs before the next logic
scan" or "set these outputs after this scan".

Also, is there any reason to deal with 16 bit shorts? Most likely we'll be on 32 bit processors, and PLC data types seem most commonly dictated by processor structure. We may be best of with unsigned 32 bit numbers as "native" and fastest. Along the same line, I think many of us are used to keeping track of what's binary, octal, hex, BCD, etc. in our data and instructions ("gee, does that timer count in BCD or binary?" -famous last words on an Omron or Koyo!), so we should be able to standardize that greatly with Linux underneath.

Rob Martin
[email protected]

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sun Jan 9 14:11:16 2000 Rob Martin wrote...
>
>Curt Wuollet wrote:
>>
>> Phil Covington wrote:
>> >
>> > Ken Irving wrote:
>>
>> Call this an I/O deamon and we're not very far apart. I envision a clear division at the map with I/O processes on one side and everything else on the other, this lessens the amount of running code that has to be synchronized for data consistancy. I like the flat map with data abstraction. All we are really talking about is moving more functionality to the I/O side. Suppose we make the shared memory map just an array of say 16 bit shorts. suppose the driver maps and overall map exist on this same page?
The reason I don't want userland maps is that we may want either I/O or the logic engine or both to be realtime and explicitly scheduled. The code for hard real time is RTLinux unless we want to write our own.<<
>
>On the DL205 from AutomationDirect (Koyo) and I think most PLCs, the routing is
> 1. Scan inputs
> 2. Implement logic
> 3. Set outputs

Most A'B PLC's work this way. Although there are models that support asunch I/O. This has an I/O scanne process that reads, and writes
from/to the I/O data table at it's own speed. Makes for some interesting omplications in the application program.

>Additionally, the DL205 (and the SLC50x, if I remember correctly) gives you "Immediate Inputs" and "Immediate Outputs". <

A feature which every so often is useful. Howevr in general the impact on the application program hurts almost as much as the feature helps.

>Also, Intellution's FIX (also Wonderware, I believe) lets you indicate which "registers" (tags) to update and how often.<

Good application enables (factory Link for one) group these into "tables" which have triigeres. The users application can then control
this, for example update fats, if the screen is visible, slowly if not.

>Also, is there any reason to deal with 16 bit shorts? Most likely we'll be on 32 bit processors, and PLC data types seem most commonly dictated by processor structure. We may be best of with unsigned 32 bit numbers as "native" and fastest. Along the same line, I think many of us are used to keeping track of what's binary, octal, hex, BCD, etc. in our data and instructions ("gee, does that timer count in BCD or binary?" -famous last words on an Omron or Koyo!), so we should be able to standardize that greatly with Linux underneath.<

16 nits is the native size for a lot of digital I/O.


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

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

Gilles Allard

Some PLC implements the "image register" concept to insure the I/O values do not change during a scan. If the I/O process is asynchronous
(it has to be), then there should be a method to get an image (a snapshot) at the beginning of the scan and an update method to send the "image register" to the outputs.

Gilles

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
Simon Martin wrote:
>
> In the motion control world you've got CNC and servo controllers. I would
> not like to specify exactly what a CNC is, but if it does not have g-code,
> then it ain't.

Oh, I don't know ... <smile> ... names can be difficult things.

Early Hurco controllers did not have G-codes. The original Summit Engineering Bandit controllers (supposedly the first CNC with MDI input)
didn't have G-codes for the first two years.

Mark

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sun, Jan 09, 2000 at 10:20:21AM -0500, Stan Brown wrote:
> The idea of having a seerate shared memort area for each type is probably OK. I can't see a given system talking to to many different brands of I/O.<

What if one of the I/O devices goes west and you replace it with a different brand?

I vote for the Controller Memory Manager scheme. It should be possible to muck around to any extent with the actual I/O devices without having to touch the program.

(Yes, this means each point individually mapped between the memory map and the device driver.)

> >I would lean toward the conventional approach of having an intermediate
> >memory map between the device drivers physical IO map and the ladder
> >logic engine that is updated in full on a periodic basis.
...
> The convential approach is correct here in 95% of the cases.

The rest of the time, there can be a special instruction saying "update these 3 I/O points" which will cover the rest of the cases.


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 Wed Jan 12 07:24:48 2000 Simon Martin wrote...
>
>Hi all,
>
>Maybe this is a weird question, but what exactly IS a PLC, that is to say, what differences a PLC from any other piece of equipment that handles logic.<

My definition, for what it's worth:

1. Runs ladder logic (may run other languages)
2, Industrialy hardened hardware.
3. Talks to real physwical I/O (digital, analog, motion control)
4. Program can be viewd with statuses in real time.
5, I/O can be forced
6. Data table values can be changed in real time.
9. Program can be edited in real time.

Those are the ones that come to mind. Any others?

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
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:

1. Any I/O model that relies upon the convention of scanning all inputs and/or updating all outputs as a monolithic function will not be general enough. For instance, some analog I/O with which I'm familiar take a finite (and significant) time to update, as do complex I/O such as motion controllers. If such things are treated as part of a "scan", the cycle time will become horrendous. If they're treated separately, with only the digital I/O being subject to a scan, we begin to create a divergent model of our I/O for which there is no real basis.

I would propose as an alternative that we make available methods/procedures for both (a.) updating the universe (or a subset thereof -- for instance, "all digital inputs") of I/O and (b.) updating a specific I/O point. This would allow a language engine to select its model of execution.

I know that the previously-proposed model could be read as providing these two mechanisms, but I'm a bit uncomfortable with the presumption of an I/O scan as part of the "normal" functionality.

2. As fond as I am of state programming for automation, I don't believe that *all* languages should be force-fit into a state paradigm. This feels a bit strained (e.g., calling an LD program a "single state" program <g>). The more we discuss this, the more I believe that a programming interface is the best "core" for our effort, and let the language execution engine take
whatever form fits best for the language.

If we do choose the direction I'm suggesting (and others have previously suggested), a good starting point might be to examine some of the services that a "typical" language execution engine might require. An attempt to generalize these services to the greatest degree possible now will pay dividends later in flexibility.

In short, I think there's little rationale for coding this the way one would code a conventional PLC, and a lot of reason to do it differently.

Ken Crater
Control.com Inc.
[email protected]

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Re the problem of scanning both digital and (slow) analog I/O: I can't remember who did it, but some years ago there was a PLC with multiple scans, so more-critical stuff could be watched more closely.

Pete


-----Original Message-----
From: Ken Crater <[email protected]>

>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
 
Top