Today is...
Friday, October 20, 2017
Welcome to Control.com, the global online
community of automation professionals.
Featured Video...
Featured Video
Wiring and programming your servos and I/O just got a lot easier...
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive
Data Types
Just to start out, below is a first idea about general data types - just to simplify interchange.
By August Albert on 7 January, 2000 - 12:57 am

Just to start out, below is a first idea about general data types - just to simplify interchange.

/*
* File: DATA_TYPES.H
* LinuxPLC basic data types
*
* History:
* 06Jan00 AA 01 First pass - based on other modern standards
*/

typedef BOOLEAN unsigned char; /* 0 = false, 0xFF = true */
typedef INT8 char; /* 8-bit signed integer */
typedef INT16 short int; /* 16-bit signed integer */
typedef INT32 long int; /* 32-bit signed integer */
typedef UINT8 unsigned char; /* 8-bit unsigned integer */
typedef UINT16 unsigned short int; /* 16-bit unsigned integer */
typedef UINT32 unsigned long int; /* 32-bit unsigned integer */
typedef FP32 float; /* 32-bit IEEE floating point */
typedef FP64 double; /* 64-bit double-prec IEEE floating
point */

/* is there an ASNI standard (or need?) for 64-bit ints? */
/* typedef INT64 ??; ?* 64-bit signed integer */
/* typedef UINT64 ??; ?* 64-bit unsigned integer */

typedef struct t_str32 { /* string, len first, max 31 char
(with null-term) */
UINT8 length; /* why len? to simplify variable
sized headers */
UINT8 str[32];
} STRING32;

typedef struct t_vis_str { /* printable string, len first, max
255 char */
UINT8 length; /* why len? to simplify variable
sized headers */
UINT8 first_char; /* nothing stops you from using
null-term strings elsewhere */
} VISIBLE_STRING;

typedef struct t_oct_str { /* binary 'string', len first */
UINT32 length;
UINT8 first_octet;
} OCTET_STRING;

typedef struct t_date {
UINT16 year;
UINT8 month;
UINT8 day;
UINT8 day_of_week;
} DATE;

typedef struct t_time {
UINT8 hour;
UINT8 minute;
UINT8 second;
UINT16 hundred_micro_sec;
} TIME;

/* we should also have a "packed timestamp" type with date & time and
* a "time_since_01-Jan-2000" type for rapid time period calcs
* - suggestions? */

/* other complex objects (analog in etc) should be a different header file
* this header is for the basic 'elemental' data types
*/


August Albert
august@shinmark.com
Singapore


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Bayern on 7 January, 2000 - 5:50 pm

August Albert wrote:
>
> Just to start out, below is a first idea about general data types - just to
> simplify interchange.
>
> /*
> * File: DATA_TYPES.H
> * LinuxPLC basic data types
> *
> * History:
> * 06Jan00 AA 01 First pass - based on other modern standards
> */
>
> typedef BOOLEAN unsigned char; /* 0 = false, 0xFF = true */

...ahhh...

Could we make that 0=False non-0=True, with a STRONG recommendation that
true be set to 0xFF??

As it is currently defined, BOOLEAN acutally has three states, FALSE,
TRUE, NO-SURE.

Mark

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By August Albert on 8 January, 2000 - 11:37 am

At 04:50 PM 1/7/00 -0600, you wrote:
>August Albert wrote:
> > typedef BOOLEAN unsigned char; /* 0 = false, 0xFF = true */
>Could we make that 0=False non-0=True, with a STRONG recommendation that
>true be set to 0xFF??
>
>As it is currently defined, BOOLEAN acutally has three states, FALSE,
>TRUE, NO-SURE.
>
>- Mark

Agreed. Good point. This is meant to be a data object def for unambiguous exchange, not a logical test condition. The 00/FF def I took from both the Modbus and Foundation Fieldbus specs. I'd prefer adding just a comment such as:

typedef BOOLEAN unsigned char; /* 0 = false, 0xFF = true */
/* note: values > 0 and < 0xFF will be treated as true, but are improper */

Also, I'd like to take the "len" field off my STRING32 object as it's size is known. As mentioned the only reason I suggested the size first on VISIBLE_STRING is to that a parser can rapidly determine the size of a block containing this object.


August Albert
august@shinmark.com
Singapore


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Bayern on 9 January, 2000 - 12:03 pm

August Albert wrote:

> Agreed. Good point. This is meant to be a data object def for unambiguous exchange, not a logical test condition. The 00/FF def I took from both the Modbus and Foundation Fieldbus specs. I'd prefer adding just a comment such as:
>
> typedef BOOLEAN unsigned char; /* 0 = false, 0xFF = true */
> /* note: values > 0 and < 0xFF will be treated as true, but are improper */ <

OK with me. I just want to assure that there are two and only two states for a boolean, and that those two states are well defined! (something
about making sure that everyone's code is interchangeable <grin>).

Mark

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

At 08:59 PM 1/7/2000 -0500, you wrote:
>From: Mark Bayern <mark@mlb.net>

>> * File: DATA_TYPES.H
>> * LinuxPLC basic data types
>> *
>> * History:
>> * 06Jan00 AA 01 First pass - based on other modern standards
>> */
>>
>> typedef BOOLEAN unsigned char; /* 0 = false, 0xFF = true */
>
>...ahhh...
>
>Could we make that 0=False non-0=True, with a STRONG recommendation that
>true be set to 0xFF??


I know that there are arguments for FALSE and !FALSE, but I would prefer to see 0xFF for true, because it is the most positive. If every bit turns from 0 to 1, then it is clearly a TRUE signal. Otherwise, if !FALSE was TRUE, there are many conditions that would create a TRUE, and only one that would create a false.

Bill Sturm
Applied Grinding Technologies

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Bayern on 10 January, 2000 - 3:01 pm

Bill wrote:
>
> At 08:59 PM 1/7/2000 -0500, you wrote:
> >Date: Fri, 07 Jan 2000 16:50:16 -0600
> >From: Mark Bayern <mark@mlb.net>
> >Organization: MLB Electronics, Inc.
> >To: linuxplc@linuxplc.org
> >Subject: Re: LinuxPLC: Data Types
> >Reply-To: linuxplc@linuxplc.org
> >
> >> * File: DATA_TYPES.H
> >> * LinuxPLC basic data types
> >> *
> >> * History:
> >> * 06Jan00 AA 01 First pass - based on other modern standards
> >> */
> >>
> >> typedef BOOLEAN unsigned char; /* 0 = false, 0xFF = true */
> >
> >...ahhh...
> >
> >Could we make that 0=False non-0=True, with a STRONG recommendation that
> >true be set to 0xFF??
>
> I know that there are arguments for FALSE and !FALSE, but I would prefer to
> see 0xFF for true, because it is the most positive. If every bit turns
> from 0 to 1, then it is clearly a TRUE signal. Otherwise, if !FALSE was
> TRUE, there are many conditions that would create a TRUE, and only one that
> would create a false.
>
> Bill Sturm
> Applied Grinding Technologies

0xFF is 'the most positive'? <grin> Since the high order bit is set it looks awfully negative to me.

...end of silliness...

I'd go either way as long as it is well defined. Once again, a boolean should have only two states. I don't really care if 0xAA is true or
false, as long as it is not indeterminate.

Mark

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Simon Martin on 10 January, 2000 - 8:42 pm

The problem with 0xFF as TRUE and not 0xFF as FALSE does not read very well in C. The logical not operator will convert any non-zero number to 0, and 0 to 1. If we use unsigned 8 bit storage then -!0 will give 0xFF and -!1 will give 0. What we should do is invert the meaning, Let 0 = True, not 0 = false. This is a true 'C'-ism. All functions return 0 for ok and non-zero to specify an error.

Debian GNU User
Simon Martin
Project Manager
Isys
mailto: smartin@isys.cl

----- Original Message -----
From: Bill
To: linuxplc@linuxplc.org
Sent: 10 January 2000 14:22
Subject: Re: Re: LinuxPLC: Data Types

At 08:59 PM 1/7/2000 -0500, Mark Bayern wrote:
>
>> * File: DATA_TYPES.H
>> * LinuxPLC basic data types
>> *
>> * History:
>> * 06Jan00 AA 01 First pass - based on other modern standards
>> */
>>
>> typedef BOOLEAN unsigned char; /* 0 = false, 0xFF = true */
>
>...ahhh...
>
>Could we make that 0=False non-0=True, with a STRONG recommendation that
>true be set to 0xFF??


I know that there are arguments for FALSE and !FALSE, but I would prefer to
see 0xFF for true, because it is the most positive. If every bit turns
from 0 to 1, then it is clearly a TRUE signal. Otherwise, if !FALSE was
TRUE, there are many conditions that would create a TRUE, and only one that would create a false.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Phil Covington on 13 January, 2000 - 6:14 pm

Yes, In an Allen Bradley World, this is all true :-)

Phil Covington
vHMI

----- Original Message -----
From: "Stan Brown" <stanb@awod.com>
To: "Linux PLC list" <linuxplc@linuxplc.org>
Sent: Thursday, January 13, 2000 5:59 PM
Subject: LinuxPLC: Data table


> 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 for
> preset, 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 stanb@netcom.com
843-745-3154
> Westvaco
> Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Nick Busigin on 13 January, 2000 - 7:01 pm

Hello!

I just joined the list. The concept of a GNU licensed Linux based PLC
is of great interest to me. Hopefully, I will be able to contribute a
bit to this project.

On Thu, 13 Jan 2000, Stan Brown wrote:

> 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

Hi Stan,

Your description is a good start (and very reminiscent of Allen-Bradley
PLCs).

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

Since this is going to be a software based PLC, let's not place any
arbitrary limits on things (unless absolutely necessary). Let the
number of files and their lengths be user-configurable.

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

Sound reasonable, however, let's let the user decide how many bits per
integer word to have (ie. 8, 16, 32 or 64). The main thing is to have a
data table that maps to real i/o in an efficient fashion.

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

The same comments apply as for your description of inputs and for the
rest of the descriptions of data types you mentioned.

> Then we have timer struts. These consist of a 16 bit word each for
> preset, and accumulated values, and 16 bits of status, eg timer
> timing, timer done.

I would recommend staying away from hard coding status bits to actual
bits in a word. Let the user deal with symbolic names rather than
having to worry about remembering that bit 15 is the timer-done bit,
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?

I'll have to read through the archives as what I'm going to suggest/ask
next may already have been discussed... Has anyone taken a look at the
IEC 1131 series of specifications? These may contain many of the
definitions that we are discussing. Also, conforming to an existing
standard may be very worth while.

I'll go and read the archives to see what you fellas have been up to.
Very interesting project!

Nick

--------------------------------------------------------------------------
Nick Busigin ...Sent from my Debian/GNU Linux Machine... nick@xwing.org

To obtain my pgp public key, email me with the subject: "get pgp-key"
--------------------------------------------------------------------------



_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

Mostly this is a "me too" post. I think this will be a good interface
for the core to present to the front-ends.

Stan Brown wrote:
> 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.

If we have these three, let's have the remaining one, "invert". Partly
for completeness, partly because it doesn't cost anything, partly
because it'll probably come in handy sometimes.

(Completeness - with one bit of data, there's only four operations you
can do on it.)

> Then we have timer struts. These consist of a 16 bit word each for
> preset, and accumulated values, and 16 bits of status, eg timer timing, timer done.

If we want uniformity, we could have these as three separate files.

> Can we get a consensus on these types?

You have my vote, anyway... This is simple enough that we can hope to get it done promptly, yet flexible enough to serve most purposes.

I'll put together a C header file for it.

Jiri
<jiri@baum.com.au>
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

> On Thu, 13 Jan 2000, Stan Brown wrote:
> > 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.

Nick Busigin wrote:
> Since this is going to be a software based PLC, let's not place any
> arbitrary limits on things (unless absolutely necessary). Let the
> number of files and their lengths be user-configurable.

Fixed-size buffers are a lot easier to handle; and using exactly one VM
page may have some advantages. (How would you resize a shared memory
area?)

> Sound reasonable, however, let's let the user decide how many bits per
> integer word to have (ie. 8, 16, 32 or 64). The main thing is to have a
> data table that maps to real i/o in an efficient fashion.

Yes, but in the first version I'd prefer to have just one (and 16-bit is
just as good as any other).

Besides, for the digital inputs and outputs it'll just be a pointer to
4K of memory, do what you will with it.

> > Then we have timer struts. These consist of a 16 bit word each for
> > preset, and accumulated values, and 16 bits of status, eg timer
> > timing, timer done.
>
> I would recommend staying away from hard coding status bits to actual
> bits in a word. Let the user deal with symbolic names rather than
> having to worry about remembering that bit 15 is the timer-done bit,
> etc..

Why can't we have both? The user will be handed an opaque 16-bit value,
with a bunch of functions to convert it into real-world conditions.
(That's in C. In stepladder it's handled behind-the-scenes from start to
finish.)

inline timer_done(i16 status) /* returns TRUE if timer is finished,
FALSE otherwise */
{return status & TIMER_DONE_B;}

Jiri
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Thu Jan 13 19:32:20 2000 Jiri Baum wrote...
>
>Mostly this is a "me too" post. I think this will be a good interface
>for the core to present to the front-ends.
>
>Stan Brown wrote:
>> 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.
>
>If we have these three, let's have the remaining one, "invert". Partly
>for completeness, partly because it doesn't cost anything, partly
>because it'll probably come in handy sometimes.

Hmm it's realy unheard of. But I can't think of any real reason to not have it. On the other hand, I can think of many reasons to never use
it.
>
>(Completeness - with one bit of data, there's only four operations you
>can do on it.)
>
>> Then we have timer struts. These consist of a 16 bit word each for
>> preset, and accumulated values, and 16 bits of status, eg timer timing,
>> timer done.
>
>If we want uniformity, we could have these as three separate files.

No, you miss the point. Thnif of a struct. Each of the three 16 bit loactions in a given time struct are associated wiht _taht specific
timer. You might have may files of timers, each consisting of many
timer structs, each of these having the subcomponents.
>
>> Can we get a consensus on these types?
>
>You have my vote, anyway... This is simple enough that we can hope to
>get it done promptly, yet flexible enough to serve most purposes.
>
>I'll put together a C header file for it.

Thanks, very much.
--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

On Thu Jan 13 19:01:01 2000 Nick Busigin wrote...
>
>Hello!
>
>I just joined the list. The concept of a GNU licensed Linux based PLC
>is of great interest to me. Hopefully, I will be able to contribute a
>bit to this project.
>
>On Thu, 13 Jan 2000, Stan Brown wrote:
>
>> 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
>
>Hi Stan,
>
>Your description is a good start (and very reminiscent of Allen-Bradley
>PLCs).

What a surprise :-) I have been programming AB PLC's since the black box
AB PLC days :-)
>
>> 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.
>
>Since this is going to be a software based PLC, let's not place any
>arbitrary limits on things (unless absolutely necessary). Let the
>number of files and their lengths be user-configurable.

Yes, that was the intent. I really was just throwing in the sizes for
clarity for those unfamiliar with the basic PLC memory concepts. On the
other hand we will have to have some limits, to allow the instructions
to have fixed size. The address portion of these instructions will only
be able to handle a certain size of file/word component.
>
>> 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.
>
>Sound reasonable, however, let's let the user decide how many bits per
>integer word to have (ie. 8, 16, 32 or 64). The main thing is to have a
>data table that maps to real i/o in an efficient fashion.

16 bits has a _long_ history here. And most real world I/O is designed
with this in mind.
>
>> 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.
>
>The same comments apply as for your description of inputs and for the
>rest of the descriptions of data types you mentioned.

I strongly believe that I/O data types need to be 16 bit. Other non
-I/O data tables could be different sizes, but existing practice has
proven that 16 bits is by far the most common, and is well suited to
the types of things done with PLC's Floats, and 32 bit ints' are a nice
addition, but i would not want to use them for everything.
>
>> Then we have timer struts. These consist of a 16 bit word each for
>> preset, and accumulated values, and 16 bits of status, eg timer
>> timing, timer done.
>
>I would recommend staying away from hard coding status bits to actual
>bits in a word. Let the user deal with symbolic names rather than
>having to worry about remembering that bit 15 is the timer-done bit,
>etc..

These can be refereed to by symbolic names such as .td for timer done,
.tt for timer timing, but ultimately they do resolve down to specific
bits, and us PLC types like to know the low level details in our
application programs :-)
--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Thu Jan 13 18:12:52 2000 Phil Covington wrote...
>
>Yes, In an Allen Bradley World, this is all true :-)
>
They pretty much dominate the market. IMHO that's a good enough reason
to come close to their design, for general aceptance of the project.
It's going to be a hard sell anyway.
--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Phil Covington on 13 January, 2000 - 9:10 pm

----- Original Message -----
From: "Stan Brown" <stanb@awod.com>

> On Thu Jan 13 18:12:52 2000 Phil Covington wrote...
> >
> >Yes, In an Allen Bradley World, this is all true :-)
> >
> They pretty much dominate the market. IMHO that's a good enough reason
> to come close to their design, for general aceptance of the project.
> It's going to be a hard sell anyway.

Agreed!

Phil Covington
vHMI
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

> >If we have these three, let's have the remaining one, "invert". Partly
> >for completeness, partly because it doesn't cost anything, partly
> >because it'll probably come in handy sometimes.

Stan Brown wrote:
> Hmm it's realy unheard of. But I can't think of any real reason to not
> have it. On the other hand, I can think of many reasons to never use
> it.

It really freaks the electrician if you tell him not to worry about
figuring out the N/O contacts (like it says in the diagram) and wire the
sensor N/C :-)

Seriously, though, you'd never use it in your design; you might use it
in later kluges and workarounds (same as the other kind of forces, no?).

> >> Then we have timer struts. These consist of a 16 bit word each for
> >> preset, and accumulated values, and 16 bits of status, eg timer timing,
> >> timer done.
> >
> >If we want uniformity, we could have these as three separate files.
>
> No, you miss the point. Thnif of a struct. Each of the three 16 bit
> loactions in a given time struct are associated wiht _taht specific
> timer. You might have may files of timers, each consisting of many
> timer structs, each of these having the subcomponents.

Yup - it's just an implementation question. If you make it a struct,
then you have to have a 48-bit file. If you make it three files, you can
use the existing 16-bit ones. Probably doesn't matter in the end. It's
the difference between T[5].setvalue and T.setvalue[5]

I'll probably end up doing something in between: user will see the
former, which will be implemented as the latter.

Jiri
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Simon Martin on 14 January, 2000 - 6:10 am

Jiri:

<snip>
>>
>> Since this is going to be a software based PLC, let's not place any
>> arbitrary limits on things (unless absolutely necessary). Let the
>> number of files and their lengths be user-configurable.
>
>Fixed-size buffers are a lot easier to handle; and using exactly one VM
>page may have some advantages. (How would you resize a shared memory
>area?)

I agree.

>> Sound reasonable, however, let's let the user decide how many bits per
>> integer word to have (ie. 8, 16, 32 or 64). The main thing is to have a
>> data table that maps to real i/o in an efficient fashion.
>
>Yes, but in the first version I'd prefer to have just one (and 16-bit is
>just as good as any other).

I agree.

>> > Then we have timer struts. These consist of a 16 bit word each for
>> > preset, and accumulated values, and 16 bits of status, eg timer
>> > timing, timer done.
>>
>> I would recommend staying away from hard coding status bits to actual
>> bits in a word. Let the user deal with symbolic names rather than
>> having to worry about remembering that bit 15 is the timer-done bit,
>> etc..
>
>Why can't we have both? The user will be handed an opaque 16-bit value,
>with a bunch of functions to convert it into real-world conditions.
>(That's in C. In stepladder it's handled behind-the-scenes from start to
>finish.)
<snip>

Just a quick question. Why run timer code INSIDE the PLC code. If it is
treated (by the PLC) as just another IO then great. In the external io
handling stuff there is module that handles timers. The PLC just handles IO
registers. This structure facilitates the use of more esoteric IO (PID for
example) without complicating the PLC. Again a motion module (something I
have a lot of experience in) can run with its' own timing etc, and just
receive updates from the PLC. The PLC is not responsible for running the
PID, profiling, etc. it just hits values and carries on.

__ _ Debian GNU User
/ /(_)_ __ _ ___ __ Simon Martin
/ / | | '_ \| | | \ \/ / Project Manager
/ /__| | | | | |_| |> < Isys
\____/_|_| |_|\__,_/_/\_\ mailto: smartin@isys.cl

There is a chasm of carbon and silicon the software cannot bridge
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Fri Jan 14 11:45:00 2000 nick wrote...
>
>Some German prox switches are inverted. ( negative logic?)
>
Fine, that's an application coding issue ( -| |- vs -|/|- ), not a reason to have an invert function in the force table. Force tables are for testing and emergency use only, you should never run a sustem with forces on without being in close attendance to the system.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Fri Jan 14 11:32:32 2000 nick wrote...
>
>hi all,
>
>one thing to remember when working with shared memory and multi-platforms is little endian vs big endian.

Shared memory exists only on the local machine, it's not visible to
another computer. I believe it's just the native fomrat for the
computer it's runing on.
>
>any tools that write to disk must have an option to produce flat files.
>
>This is also an issue then coping data over sockets . The data should
>not be shipped as any thing larger then a byte. if you read one byte at
>a time the conversion is cake.

Well defined network byte order here. Read any standard text on UNIX
networking protocol programing.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Fri Jan 14 07:06:05 2000 Simon Martin wrote...
>
>Just a quick question. Why run timer code INSIDE the PLC code. If it is
>treated (by the PLC) as just another IO then great. In the external io
>handling stuff there is module that handles timers. The PLC just handles IO
>registers. This structure facilitates the use of more esoteric IO (PID for
>example) without complicating the PLC. Again a motion module (something I
>have a lot of experience in) can run with its' own timing etc, and just
>receive updates from the PLC. The PLC is not responsible for running the
>PID, profiling, etc. it just hits values and carries on.

Timers. might very well execute in a "timer execution module", which
could be common to several logic engines, however what we were talking
about there was the view of the timer, as seenfrom inside the logic
processors engine.
--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
-
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Thu Jan 13 21:57:57 2000 Jiri Baum wrote...
>
>> >If we have these three, let's have the remaining one, "invert". Partly
>> >for completeness, partly because it doesn't cost anything, partly
>> >because it'll probably come in handy sometimes.
>
>Stan Brown wrote:
>> Hmm it's realy unheard of. But I can't think of any real reason to not
>> have it. On the other hand, I can think of many reasons to never use it.
>
>It really freaks the electrician if you tell him not to worry about
>figuring out the N/O contacts (like it says in the diagram) and wire the
>sensor N/C :-)

No, mine understand the concept of fail safe witing, and always ask which contact to bring in. Usually they already no, they just want confirmation.

>Seriously, though, you'd never use it in your design; you might use it
>in later kluges and workarounds (same as the other kind of forces, no?).

No, a force is a _cery short term_ testing solution. Never left in place after I walk away from the machine/process.

>> >> Then we have timer struts. These consist of a 16 bit word each for
>> >> preset, and accumulated values, and 16 bits of status, eg timer timing,
>> >> timer done.
>> >
>> >If we want uniformity, we could have these as three separate files.
>>
>> No, you miss the point. Thnif of a struct. Each of the three 16 bit
>> loactions in a given time struct are associated wiht _taht specific
>> timer. You might have may files of timers, each consisting of many
>> timer structs, each of these having the subcomponents.
>
>Yup - it's just an implementation question. If you make it a struct,
>then you have to have a 48-bit file. If you make it three files, you can
>use the existing 16-bit ones. Probably doesn't matter in the end. It's
>the difference between T[5].setvalue and T.setvalue[5]

Big difference as I see it. See my reply on timer executin engines.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 14 January, 2000 - 7:47 am

<clip>
Just a quick question. Why run timer code INSIDE the PLC code. If it is
treated (by the PLC) as just another IO then great. In the external io
handling stuff there is module that handles timers. The PLC just handles IO
registers. This structure facilitates the use of more esoteric IO (PID for
example) without complicating the PLC. Again a motion module (something I
have a lot of experience in) can run with its' own timing etc, and just
receive updates from the PLC. The PLC is not responsible for running the
PID, profiling, etc. it just hits values and carries on.
</clip>

This is approaching the object oriented approach used by AutomationX and
Object Automation.

Here what are being proposed as Linux modules, are infact control objects.

A softPLC is wired to a softTIC is wired to a real TE and a real RTD.

Alternatively, and here is where things get tricky (this is really advanced
stuff), there is no PLC.

The logic for each type of object (Motor, Valve, Vessel) is all embedded in
the class. Of course in the commercial systems mentioned above, these
objects are all integrated into a single application.

In AutomationX, the class encapsulates everything that an object requires
(e.g. Visualisation, Logic, Alarms, Trends) and provides the methods
required to utilise the imbedded functionality.

Classes specify the attributes (visual image, colour, inputs, outputs) and
the behaviour (animation, state transition, fault logic) of objects.

This is something for the future.

Regards
Mark Hutton
Software Engineer
Vogal Software Services
Regent House, Welbeck Way, Peterborough. UK PE2 7WH
Tel: +44 (0)1733 370789 Fax: +44 (0)733 370701
mark.hutton@vogal.demon.co.uk

THINK BIG, Start Small.

(This one's for Simon :-)

If you knew Suse like I know Suse ........
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Fri Jan 14 07:38:56 2000 Mark Hutton wrote...

><clip>
>Just a quick question. Why run timer code INSIDE the PLC code. If it is
>treated (by the PLC) as just another IO then great. In the external io
>handling stuff there is module that handles timers. The PLC just handles IO
>registers. This structure facilitates the use of more esoteric IO (PID for
>example) without complicating the PLC. Again a motion module (something I
>have a lot of experience in) can run with its' own timing etc, and just
>receive updates from the PLC. The PLC is not responsible for running the
>PID, profiling, etc. it just hits values and carries on.
></clip>
>
>This is approaching the object oriented approach used by AutomationX and
>Object Automation.
>

This approach has been tried by the DCS manufacturers with their "motor blocks", and "valve blocks" It has failed miserably. We for instance even on a job with a DCS, will put all motors, and digital valves in a PLC, so that we can program them in an under-stable fashion. This is ugly because then we have to have a DCS/PLC gateway, which the DCS vendors in general have also done a poor job of implementing (why should they make it work well, they want to sell you their I/O).

Please. lets not repeat this mistake.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Fri Jan 14 11:50:47 2000 Ranjan Acharya wrote...
>
>I would like the rich variety of data types (similar to those available to a
>high-level programming language) such as: Boolean, single-precision floating
>point (IEEE 754 32-bit), double-precision FP (64-bit), long FP (80-bit),
>signed/unsigned 8-bit integer, s/u 16-bit i, s/u 32-bit i, s/u 64-bit i and
>perhaps even consideration of a 128-bit integer. Many times I have had to
>chain together two 16-bit signed integers in a PLC / controller with limited
>data types to get a not-quite 32-bit integer. The floating point thing is
>really important too -- all the way at least as far as 64-bit really helps.

It has been my experience that the combination of 32 bit floats, and 32 bit longs is suffiecnt for 99% of real world apps.

>Also on the subject of timers/counters, can we have them use at least 32-bit
>unsigned integers so that we do not have to chain them together either.
>Many PLCs are hampered by a +32767 limit on a timer preset (and a limited
>selection of units too -- only milliseconds or seconds for example).

I suggest 3 time bases. .01 .1 and 1 second. Given this 16 bit resolution will again cover 90% of the applications. Perhaps we could use the 32 bit longs here, but we would be making the timer data table structs almost double in size.
>
>Customised data types e.g., date, time, complex (3+2j or 3+2i -- I cannot
>imagine why, but why not) via some sort of structured programming (aka 1131)
>would be useful too.

I am in favor of adding (eventually) the equivalent of structs. I am reminded that one of the inventors of UNIX credits adding structs to C being the thing that allowed UNIX to be written. Having said this, I would rather not try for this in the first version of the system. We need to design something that we can accomplish in a reasonable length of time, or we will lose interest. Seeing something work is a key
factor in staying motivated on a project.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Sage, Pete (IndSys, GEFanuc, Albany) on 14 January, 2000 - 3:55 pm

Unless you synch the data on every write you will lose data if someone
switches the PC off. Syncing the data on every write will kill your
performance. A reasonable technique is to configure the shared memory as a
memory mapped file, this will give you persistence. Periodically you can
flush it to disk.
> -----Original Message-----
> From: Stan Brown [mailto:stanb@awod.com]
> Sent: Friday, January 14, 2000 03:47 PM
> To: linuxplc@linuxplc.org
> Subject: LinuxPLC: persistent data
> One of the basic concepts of a PLC is that the data table is retained
> upon program stop, whether that be manually stopping the scan, or the
> actual powering down of the controller.
>
> Has anyone put any thoughts into how we can handle this? In a real PLC
> is genuine battery backed up RAM, so their is no "save on power failure",
> we unfortunately don't have that luxury. Nor can we
> depend upon every
> installation having a UPS.
>
> Anyone know a way around this, that doesn't cause us to
> really spend a lot of time writing changing data table to the disk? Or are we going to
> have to have a task for this? If so, we need to look at some of the
> database projects, they have similar issues with recovery logs.
>
> --
> Stan Brown stanb@netcom.com
> 843-745-3154
> Westvaco
> Charleston SC.
> --
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Fri Jan 14 15:50:39 2000 "Sage, Pete (IndSys, GEFanuc, Albany)" wrote...
>
>Unless you synch the data on every write you will lose data if someone
>switches the PC off. Syncing the data on every write will kill your
>performance. A reasonable technique is to configure the shared memory as a
>memory mapped file, this will give you persistence. Periodically you can
>flush it to disk.

Well, I was thinking of a process whose job it is to scan the data tables, and write any changes it finds to the disk files.

I realize this is a performance issue, _but_ it is critical to the operation of the process, and it is a problem that has been solved by the database code writers, they can't lose data either. You would hate to have your savings deposit deducted from your checking account, but never credited to your savings account because of a computer crash, now wouldn't you :-)
--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Hurd, David L (GEA, 053698) on 14 January, 2000 - 7:23 pm

Stan,
As an acknowledgment of the non-AB programmers, could we leave off the file #. The letter in sufficient to identify the table. Most other PLC brands use this format.
Thanks
Dave Hurd
GE Appliances


> -----Original Message-----
> From: Stan Brown [SMTP:stanb@awod.com]
> Sent: Friday, January 14, 2000 1:28 PM
>
> OK, sounds like we are starting to come together on this :-)
>
> Let me put down a few thoughts as to the structure of the data table
> definition files.
>
> 1 Location, I propose that we put our config files in /etc/plc
>
> 2. Structure, I propose that a data table definition file look
> something
> like this:
>
> # Start Length I/O ? Logic Engine
> I0/0 16 Y
> O0/0 16 Y 1
>
> The fields define the name of the data table (more detail below)
>
> The size (in appropriate units) bits for I/O elements for everything
> else.
>
> Is this I/O (special rules apply here)
>
> For outputs, which logic engine has control of them. Other logic
> engines can read the values if required, but are forbidden to set
> them.
>
> Naming
>
> I propose to go with a style that the AB centric members of this
> list
> will recognize :-)
>
> [TYPE}{File No.]:{Element No.].[Subelemnt No.]
>
> Types are:
>
> I = Input (digital)
> O = Output (digital)
> B = Binary
> C = Counter
> T = Timer
> F = Float
> L = Long Int.
> R = File operation control
> P = Pid
> M = Message control
>
> some examples:
>
> I0/0 real digital input word 0 bit 0
> O0/0 real digital output word 0 bit 0
> N7:0 integer file 7 word 0
> T4:3.dn Timer file 4 element 3 done bit
>
> Comments?

> _______________________________________________
> LinuxPLC mailing list
> LinuxPLC@linuxplc.org
> http://linuxplc.org/mailman/listinfo/linuxplc

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Fri Jan 14 19:18:54 2000 "Hurd, David L (GEA, 053698)" wrote...
>
>Stan,
>As an acknowledgment of the non-AB programmers, could we leave off the file
>#. The letter in sufficient to identify the table. Most other PLC brands use
>this format.
>Thanks
>Dave Hurd
>GE Appliances

Do you mean leave of say the 7 in N7:0 ? If we do that we are limiting
ourselves to only 1 file of a given type of data! I use many files in
my programs, it's an excellent organizational tool. For example I might
have the following:

N400: Raw data
N401: Min scale
N402: Max scale
F400: Scaled data

Perhaps no the worlds best example, since many kinds of analog I/O will
hopefully be able to provide scaled data, but I think you get the idea.
Also note that there is a N400: and an F400: No need to limit a given
file number to only 1 type of data. These are of course separate memory
files.

Or am I misunderstanding your intent here?


--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Nick Schembri on 19 January, 2000 - 10:21 am

why? The part is never understood was the use of hard references to memory used by plcs.
I hated adding a meaningful comment to the N7:0/1. The logic will be interpreted into it's final form for the plc engine. Could the (i/o)/bit/ word operation be a set of in line
functions: plc(4XXXXX),plc (N400:1/0),plc(CNC_X_limit:1/1),
plc(CNC_Y_limitXXXXXX)

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Butler, Lawrence on 15 January, 2000 - 12:39 am

> -----Original Message-----
> From: Stan Brown [SMTP:stanb@awod.com]
<snip>
> Naming
>
> I propose to go with a style that the AB centric members of this
> list
> will recognize :-)
>
> [TYPE}{File No.]:{Element No.].[Subelemnt No.]
>
> Types are:
>
> I = Input (digital)
> O = Output (digital)
> B = Binary
> C = Counter
> T = Timer
> F = Float
> L = Long Int.
> R = File operation control
> P = Pid
> M = Message control
>
> some examples:
>
> I0/0 real digital input word 0 bit 0
> O0/0 real digital output word 0 bit 0
> N7:0 integer file 7 word 0
> T4:3.dn Timer file 4 element 3 done bit
>
> Comments?
<snip>

or modicon style:

0XXXXX logic coils (one bit) either mapped to i/o or not e.g.
000001, 000123

1XXXXX digital inputs (one bit) mapped e.g. 100001, 100105

3XXXXX input registers mapped e.g. 300001, 300450

4XXXXX output registers/ holding register e.g. 400003, 409999

Lawrence Butler

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Hurd, David L (GEA, 053698) on 15 January, 2000 - 1:13 am

In GE Fanuc and Modicon PLCs there is only one "file" for data, either %R or 4xxxx, so I'm not used to seeing multiple "files" set aside for the same type of data. My only concern was trying to
remember the file number for each file. If we are going to use a handle for the file why not use a mnemonic such as Raw_Data, etc. instead of using an arbitrary number?
Dave Hurd
GE Appliances


> -----Original Message-----
> From: Stan Brown [SMTP:stanb@awod.com]
> Sent: Friday, January 14, 2000 8:18 PM
>
> On Fri Jan 14 19:18:54 2000 "Hurd, David L (GEA, 053698)" wrote...
> >
> >Stan,
> >As an acknowledgment of the non-AB programmers, could we leave off the
> file
> >#. The letter in sufficient to identify the table. Most other PLC brands
> use this format. < <
>
> Do you mean leave of say the 7 in N7:0 ? If we do that we are
> limiting
> ourselves to only 1 file of a given type of data! I use many files
> in
> my programs, it's an excellent organizational tool. For example I
> might have the following:
>
> N400: Raw data
> N401: Min scale
> N402: Max scale
> F400: Scaled data
>
> Perhaps no the worlds best example, since many kinds of analog I/O will hopefully be able to provide scaled data, but I think you get the
> idea.
> Also note that there is a N400: and an F400: No need to limit a
> given file number to only 1 type of data. These are of course separate memory files.
>
> Or am I misunderstanding your intent here?
______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

> On Fri Jan 14 19:18:54 2000 "Hurd, David L (GEA, 053698)" wrote...
> >
> >Stan,
> >As an acknowledgment of the non-AB programmers, could we leave off the
> >file #. The letter in sufficient to identify the table. Most other PLC
> >brands use this format.

On Fri, Jan 14, 2000 at 08:17:43PM -0500, Stan Brown wrote:
> Do you mean leave of say the 7 in N7:0 ? If we do that we are
> limiting ourselves to only 1 file of a given type of data! I use
> many files in my programs, it's an excellent organizational tool.

I was going to have almost the opposite suggestion...

Have several pre-defined files (input, output, internal etc), and the other files referred to by number (or user-defined symbolic name). The type of each file depends on configuration, and we should probably allow mixed-type files (eg a file corresponding to each section of the machine).

That way most people would just use I1.1 C7; but if you wanted several files, you could have 7:1.1 or sorter:1.1


It is *not* a good idea to have the same number or name refer to two different things of different types, anyway, regardless of what C++ and Perl fans will tell you. Yes, it makes for cute hacks, but I didn't think that's what we were aiming for :-)

Jiri
--
Jiri Baum <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Phil Covington on 15 January, 2000 - 7:37 am

----- Original Message -----
From: "Butler, Lawrence" <butler.lawrence@syncrude.com>

> > -----Original Message-----
> > From: Stan Brown [SMTP:stanb@awod.com]
> >
> <snip>
> > Naming
> >
> > I propose to go with a style that the AB centric members of this list
> > will recognize :-)
> >
> > [TYPE}{File No.]:{Element No.].[Subelemnt No.]
> >
> > Types are:
> >
> > I = Input (digital)
> > O = Output (digital)
> > B = Binary
> > C = Counter
> > T = Timer
> > F = Float
> > L = Long Int.
> > R = File operation control
> > P = Pid
> > M = Message control
> >
> > some examples:
> >
> > I0/0 real digital input word 0 bit 0
> > O0/0 real digital output word 0 bit 0
> > N7:0 integer file 7 word 0
> > T4:3.dn Timer file 4 element 3 done bit
> >
> > Comments?
> <snip>
>
> or modicon style:
>
> 0XXXXX logic coils (one bit) either mapped to i/o or not e.g.
> 000001, 000123
>
> 1XXXXX digital inputs (one bit) mapped e.g. 100001, 100105
>
> 3XXXXX input registers mapped e.g. 300001, 300450
>
> 4XXXXX output registers/ holding register e.g. 400003, 409999
>
> Lawrence Butler

I vote for the AB style addressing... not that I prefer AB PLCs over others
though...

Phil Covington
vHMI



_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Sat Jan 15 03:27:07 2000 Jiri Baum wrote...
>
>
>It is *not* a good idea to have the same number or name refer to two
>different things of different types, anyway, regardless of what C++ and
>Perl fans will tell you. Yes, it makes for cute hacks, but I didn't think
>that's what we were aiming for :-)
>

I disagree, sort of F400:3 is _clearly_ not "the same thing" as N400:2. I have used 2 different types of PLC's that allow this (PLC-3 and PI), and have found it extremely useful. When I am working on a PLC5, that does not allow this, I find myself feeling very constrained.

The electricians I work with don't have any confusion whatsoever over this.

Or were you thinking that F400:3, and N400:3 would be the same thing, as in a C union?

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Sat Jan 15 01:09:04 2000 "Hurd, David L (GEA, 053698)" wrote...
>
>In GE Fanuc and Modicon PLCs there is only one "file" for data, either %R or
>4xxxx, so I'm not used to seeing multiple
>"files" set aside for the same type of data. My only concern was trying to
>remember the file number for each file.
>If we are going to use a handle for the file why not use a mnemonic such as
>Raw_Data, etc. instead of using an
>arbitrary number?

Hmm, haven't had to deal with this limitation since PLC-2 days :-)

Actually there could be many files. It's not unusual to have 100 - 200 different data table files on a medium sized project for me. I think the organization this allows is very important.

mnemonics are great, but I see them as part of the "documentation" side, rather than the run time side. Because of the required speed of
execution of the logic engine(s) I think sticking with real addresses is better. The documentation part of this, will of course be an important part of the project, but only the programming/editing/viewing engine(s) need to be concerned about it. And as they run an order of
magnitude slower (they only have to interface with us slow humans :-)) efficiency of execution is not so much an issue for them.


--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Sat Jan 15 00:37:41 2000 Butler, Lawrence wrote...
>
>
> or modicon style:
>
> 0XXXXX logic coils (one bit) either mapped to i/o or not e.g.
>000001, 000123
>
> 1XXXXX digital inputs (one bit) mapped e.g. 100001, 100105
>
> 3XXXXX input registers mapped e.g. 300001, 300450
>
> 4XXXXX output registers/ holding register e.g. 400003, 409999
>
> Lawrence Butler
>

I am really attached to I = input O = output, seems so logical.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Sun Jan 16 00:13:15 2000 Nick Schembri wrote...
>
>why? The part is never understood was the use of hard references to
>memory used by plcs.
>I hated adding a meaningful comment to the N7:0/1. The logic will be
>interpreted into it's final form for the
>plc engine. Could the (i/o)/bit/ word operation be a set of in line
>functions: plc(4XXXXX),plc (N400:1/0),plc(CNC_X_limit:1/1),
>plc(CNC_Y_limitXXXXXX)
>

For a first pass, I would strongly recommend sticking to something that is well established, and understood. The functionality that you desire can be added on in the edit/monitor task, and the hard copy documenter
task.

One of the reasons that Linux has succeeded IMHO is that it looks and feels like UNIX which is well understood, and accepted. I don;t think it would have taken off if it had started down a new (and better?) road initial-y.

Lets try to get something that looks and feels like an accepted system built first. This is not to say that we should not keep in mind
improvements that we would like to latter add, as we do the design.

However in this case, I think we can achieve what you want (mnemonic programming) as a part of the edit/monitor/document part of the project, without departing from a well understood standard way of doing things in the I/O scanner, logic engine parts of the system.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

Stan Brown:
> Let me put down a few thoughts as to the structure of the data table
> definition files.

> 1 Location, I propose that we put our config files in /etc/plc

Good. Better than the /etc/plc*.conf I was thinking of.

> 2. Structure, I propose that a data table definition file look something
> like this:

> # Start Length I/O ? Logic Engine
> I0/0 16 Y
> O0/0 16 Y 1

I'm not a big fan of fixed-width, I'd prefer either something-separated (colons? commas?) or rich syntax. (Rich syntax would be parsed by a
separate program, which would use the dynamic-reconfigure interface to pass it to the core.[1])

There's also a lot of fields missing from your description - for each point, you also need which device it's on and the address on that device,
and maybe also a human name (the configurer would strip the human name before passing the data to the core, but other programs would display it).

My suggestion would be something like:
input 21.3 [human name] => DEVID X1.4
input 21.4 [human name] => DEVID X1.7
output 15.3 [human name] => DEVID Y5.4
output 10.0 [human name] => DEVID Y3.4
500: 17.1 [human name] => DEVID Y3.4
(note: input is a synonym for I; DEVID would be replaced by a device ID)

For each device you need its ID, which driver to use, and any driver-dependent arguments (address, comms parameters, model number).

Eg:
driverID DEVID [human name] address 10.0.0.17 delay 7

Each driver should come with a file that defines what arguments are required or needed, and what ranges they should be in. This probably goes
into /usr/{local,}/lib/plc rather than /etc/plc

Eg (in file driverID.driver):
driver driverID
requires address IP [network address]
accepts delay 1<=int<=10 [frobnitzing time]
points /[XY]\d+\.\d+/


I don't mind whether we use these formats or something completely different; these were intended as a first draft and I myself would probably change most of it before the design was done.

We should have an idea how we will add extra fields or different-format lines when we need them. Fixed-width is rather limited in that regard.


> For outputs, which logic engine has control of them. Other logic engines
> can read the values if required, but are forbidden to set them.

How is control of an output handed from one module to another?

This isn't an easy question, but if we are going to ignore it and hope it'll go away, at least we should ignore it in such a way that somebody
later can come in and solve it.


Jiri

[1] Since we want dynamic changes, we might as well *only* have dynamic
changes; one less interface into the core.
--
Jiri Baum <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

Jiri Baum:
> >It is *not* a good idea to have the same number or name refer to two
> >different things of different types, anyway, regardless of what C++ and
> >Perl fans will tell you. Yes, it makes for cute hacks, but I didn't
> >think that's what we were aiming for :-)

Stan Brown:
> I disagree, sort of F400:3 is _clearly_ not "the same thing" as N400:2.

No, but it might be confusing to use them for unrelated things (or even related things).

> Or were you thinking that F400:3, and N400:3 would be the same thing, as
> in a C union?

No, no, I was thinking of C++ overloading or in Perl where $a and @a are different things (and $a[1] is a part of @a, while $a{1} is a part of %a,
which is yet a different thing; to quote the manual, "This may seem a bit weird, but that's okay, because it is weird.").

Even in English, many people find it confusing that the word "effect" has different meaning depending on whether it's used as a noun or a verb, and *everyone* finds it confusing that the verb "will" changes meaning from 1st to 2nd person. Not knowing what I'm talking about proves the point.

> I have used 2 different types of PLC's that allow this (PLC-3 and PI),
> and have found it extremely useful. When I am working on a PLC5, that
> does not allow this, I find myself feeling very constrained.

Can you give me an example where this would be useful? I'm doubtful, but I'm willing to be convinced...


Jiri
--
Jiri Baum <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Sun Jan 16 06:21:48 2000 Jiri Baum wrote...
>
>Stan Brown:
>> Let me put down a few thoughts as to the structure of the data table
>> definition files.
>
>> 1 Location, I propose that we put our config files in /etc/plc
>
>Good. Better than the /etc/plc*.conf I was thinking of.
>
>> 2. Structure, I propose that a data table definition file look something
>> like this:
>
>> # Start Length I/O ? Logic Engine
>> I0/0 16 Y
>> O0/0 16 Y 1
>
>I'm not a big fan of fixed-width, I'd prefer either something-separated
>(colons? commas?) or rich syntax. (Rich syntax would be parsed by a
>separate program, which would use the dynamic-reconfigure interface to pass
>it to the core.[1])

Hmm, let me clarify, it's not fixed width. The following are all
acceptable:

N7:0/0
N007:0/0
N7:000/0
N7:0/00

You get the idea. leading zeros are unnecessary, but tolerated. File types are 1 character, file no.s are max 3 digit, file word no.'s are also max 3 digit, and bits are 2 digit of course.

>There's also a lot of fields missing from your description - for each
>point, you also need which device it's on and the address on that device,
>and maybe also a human name (the configurer would strip the human name
>before passing the data to the core, but other programs would display it).

Nope, the mapping between physical point, and data table location is done in a configuration file for the I/O scanner tasks(s). The description of physical; I/O location varies way to much between vendors to fit into a standard one size fits all config file. So there
will be config files defined for each type of I/O module that will define this.

The human readable part is a function of the editor/viewer/documenter software, and need not clutter up the data table definition files.
Remember the data table definition files define far more than just real I/O. They define all memory as seen by the logic engine(s), timer
execution engines et all.

>My suggestion would be something like:
> input 21.3 [human name] => DEVID X1.4
> input 21.4 [human name] => DEVID X1.7
> output 15.3 [human name] => DEVID Y5.4
> output 10.0 [human name] => DEVID Y3.4
> 500: 17.1 [human name] => DEVID Y3.4
>(note: input is a synonym for I; DEVID would be replaced by a device ID)
>
>For each device you need its ID, which driver to use, and any
>driver-dependent arguments (address, comms parameters, model number).
>
>Eg:
> driverID DEVID [human name] address 10.0.0.17 delay 7
>
>Each driver should come with a file that defines what arguments are
>required or needed, and what ranges they should be in. This probably goes
>into /usr/{local,}/lib/plc rather than /etc/plc
>
>Eg (in file driverID.driver):
> driver driverID
> requires address IP [network address]
> accepts delay 1<=int<=10 [frobnitzing time]
> points /[XY]\d+\.\d+/
>

I see something like this as the config files for the I/O scanner
routines as mentioned above.

>
>I don't mind whether we use these formats or something completely
>different; these were intended as a first draft and I myself would probably
>change most of it before the design was done.
>
>We should have an idea how we will add extra fields or different-format
>lines when we need them. Fixed-width is rather limited in that regard.

Again the data tables themselves are limited by design for understandability, speed of execution, and ease of implantation. They
define the shared memory structures which will exist as a common ground for all the various co-operating processes, logic engines, I/O scanners, timer execution engines, counter execution engines, PID execution engines......

>> For outputs, which logic engine has control of them. Other logic engines
>> can read the values if required, but are forbidden to set them.
>
>How is control of an output handed from one module to another?

It isn't.


--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Sun Jan 16 05:17:36 2000 Jiri Baum wrote...
>
>Can you give me an example where this would be useful? I'm doubtful, but
>I'm willing to be convinced...

Absolutely:

N400: Raw analog data
F400: scaled data.

has a one to one mapping, so you can just look at, say word 15 in the raw data file, and see the scaled value in word 15 of the scaled data
file.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By R A Peterson on 16 January, 2000 - 12:20 pm

In a message dated 01/16/2000 10:51:44 AM Central Standard Time, stanb@awod.com writes:

<< On Sun Jan 16 05:17:36 2000 Jiri Baum wrote...
>
>Can you give me an example where this would be useful? I'm doubtful, but
>I'm willing to be convinced...

Absolutely:

N400: Raw analog data
F400: scaled data.

has a one to one mapping, so you can just look at, say word 15 in the raw data file, and see the scaled value in word 15 of the scaled data file. >>

I use them for alarm setpoints, alarm timers, and PVs. Then I can write a 2-3 rung RLL program that uses in direction and can do hundreds (or
thousands) of alarms.



_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Sun Jan 16 12:20:07 2000 R A Peterson wrote...
>
>I use them for alarm setpoints, alarm timers, and PVs. Then I can write a
>2-3 rung RLL program that uses in direction and can do hundreds (or
>thousands) of alarms. <

Ah pointers :-)


--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

I have been lurking and reading this data table config thread and I have
a few ideas that I would like to share.

1. I think that it may be better to not define a globally agreed data structure at this time. We have this block of shared memory, why not let the hardware device driver dictate its own memory structure. Each I/O device would document it's own memory block size and structure. This allows for all of the vareties of I/O that exist in the real world.

2. The logic execution program would also not need to have a globally agreed data structure. The designer of the logic program would use any
addressing scheme that they see desireable. This way, the logic is totally abstracted from the I/O.

3. The trick then becomes the program that maps the I/O data into logic program addresses. I think that Modicon calls this their "traffic
cop". This program would need to understand both the I/O structure and the logic program addressing. This is where the truly clever
programming would reside.

The application programmer would tell the program which I/O address would map to each program address. Maybe a setup file could be used?

4. I think at this time the most important thing is to develop a library of I/O drivers. We can initially use C or whatever to write programs, until higher level PLC logic engines can be developed. Many people will be perfectly happy to have industrial I/O to use in their C
programs.


Bill Sturm


Stan Brown wrote:
>
> OK, sounds like we are starting to come together on this :-)
>
> Let me put down a few thoughts as to the structure of the data table
> definition files.
>
> 1 Location, I propose that we put our config files in /etc/plc
>
> 2. Structure, I propose that a data table definition file look something
> like this:
>
> # Start Length I/O ? Logic Engine
> I0/0 16 Y
> O0/0 16 Y 1
>
> The fields define the name of the data table (more detail below)
>
> The size (in appropriate units) bits for I/O elements for everything
> else.
>
> Is this I/O (special rules apply here)
>
> For outputs, which logic engine has control of them. Other logic
> engines can read the values if required, but are forbidden to set them.
>
> Naming
>
> I propose to go with a style that the AB centric members of this list
> will recognize :-)
>
> [TYPE}{File No.]:{Element No.].[Subelemnt No.]
>
> Types are:
>
> I = Input (digital)
> O = Output (digital)
> B = Binary
> C = Counter
> T = Timer
> F = Float
> L = Long Int.
> R = File operation control
> P = Pid
> M = Message control
>
> some examples:
>
> I0/0 real digital input word 0 bit 0
> O0/0 real digital output word 0 bit 0
> N7:0 integer file 7 word 0
> T4:3.dn Timer file 4 element 3 done bit
>
> Comments?
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Phil Covington on 16 January, 2000 - 9:44 pm

Bill, you need to read some of the other recent threads! Much of this have
been discussed a nausium! :-)

Simon Martin is going to work on the Shared Memory Manager (your item 3).

Phil Covington
vHMI

----- Original Message -----
From: "Bill Sturm" <bsturm@gatecom.com>

> I have been lurking and reading this data table config thread and I have
> a few ideas that I would like to share.
>
> 1. I think that it may be better to not define a globally agreed data
> structure at this time. We have this block of shared memory, why not
> let the hardware device driver dictate its own memory structure. Each
> I/O device would document it's own memory block size and structure.
> This allows for all of the vareties of I/O that exist in the real world.
>
> 2. The logic execution program would also not need to have a globally
> agreed data structure. The designer of the logic program would use any
> addressing scheme that they see desireable. This way, the logic is
> totally abstracted from the I/O.
>
> 3. The trick then becomes the program that maps the I/O data into logic
> program addresses. I think that Modicon calls this their "traffic
> cop". This program would need to understand both the I/O structure and
> the logic program addressing. This is where the truly clever
> programming would reside.
>
> The application programmer would tell the program which I/O address
> would map to each program address. Maybe a setup file could be used?
>
> 4. I think at this time the most important thing is to develop a
> library of I/O drivers. We can initially use C or whatever to write
> programs, until higher level PLC logic engines can be developed. Many
> people will be perfectly happy to have industrial I/O to use in their C
> programs.
>



_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

[different type files with the same file number]

Jiri Baum:
> >Can you give me an example where this would be useful? I'm doubtful, but
> >I'm willing to be convinced...

Stan Brown:
> N400: Raw analog data
> F400: scaled data.

> has a one to one mapping, so you can just look at, say word 15 in the
> raw data file, and see the scaled value in word 15 of the scaled data
> file.

Sounds like the scheme I was vaguelly suggesting for timers...

Would you be happy with
400: Raw analog data
410: scaled data
with the types defined elsewhere?


Really, all of these ought to use structs. I don't think we should aim to implement structs in v.1.0, but we probably shouldn't implement too many klugey workarounds if we intend to implement structs eventually.

Your point about the persistence engine being more likely to consistently save adjacent points applies to this, too. [1]


Jiri
[1] Though maybe the persistence engine ought to have checks to ensure that
it can't load an inconsistent state.
--
Jiri Baum <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

stanb@awod.com:
> >I use them for alarm setpoints, alarm timers, and PVs. Then I can write
> >a 2-3 rung RLL program that uses in direction and can do hundreds (or
> >thousands) of alarms.

> Ah pointers :-)

Hmm, I wonder if we could avoid pointers (particularly pointer arithmetic) and provide good data types instead... Probably not, but it'd be nice.

Pointers seem to lead to data structures that would have to be called Byzantine if only the word didn't already have a technical meaning in
control...


Jiri
--
Jiri Baum <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

> >Stan Brown:
> >> 2. Structure, I propose that a data table definition file look something
> >> like this:

> >> # Start Length I/O ? Logic Engine
> >> I0/0 16 Y
> >> O0/0 16 Y 1

Jiri:
> >I'm not a big fan of fixed-width,

Stan Brown:
> Hmm, let me clarify, it's not fixed width. The following are all
> acceptable:

> N7:0/0
> N007:0/0
> N7:000/0
> N7:0/00

But is this below acceptable?

# Start Length I/O ? Logic Engine
I0/0 16 Y
O0/0 16 Y 1


> You get the idea. leading zeros are unnecessary, but tolerated.

Careful about that - some people interpret leading zeros as base-8.

> >There's also a lot of fields missing from your description - for each
> >point, you also need which device it's on and the address on that device,
> >and maybe also a human name (the configurer would strip the human name
> >before passing the data to the core, but other programs would display it).

> Nope, the mapping between physical point, and data table location is done
> in a configuration file for the I/O scanner tasks(s).

OK, no problem.

> The description of physical; I/O location varies way to much between
> vendors to fit into a standard one size fits all config file.

I was going to leave it the rest of the line, with any printable character allowed (ASCII 32-126). I should have made the examples reflect this.

> The human readable part is a function of the editor/viewer/documenter
> software, and need not clutter up the data table definition files.
> Remember the data table definition files define far more than just real
> I/O. They define all memory as seen by the logic engine(s), timer
> execution engines et all.

Yes, of course. I guess it's a one-big-file vs lots-of-little-files distinction, which isn't very important.

> >Each driver should come with a file that defines what arguments are
> >required or needed, and what ranges they should be in. This probably goes
> >into /usr/{local,}/lib/plc rather than /etc/plc

> >Eg (in file driverID.driver):
> > driver driverID
> > requires address IP [network address]
> > accepts delay 1<=int<=10 [frobnitzing time]
> > points /[XY]\d+\.\d+/


> I see something like this as the config files for the I/O scanner
> routines as mentioned above.

This is intended as a *driver* description - so that the config editor can ensure that the device specifications are acceptable to the driver.

> >We should have an idea how we will add extra fields or different-format
> >lines when we need them. Fixed-width is rather limited in that regard.

> Again the data tables themselves are limited by design for
> understandability, speed of execution, and ease of implantation.

I'd go for understandability at the expense of speed of execution - they're only read once at program start-up.

As for ease of implementation, I think I've been spoilt by Perl... (In Perl, you can match a string against a regular expression to extract stuff out of it.)

> They define the shared memory structures which will exist as a common
> ground for all the various co-operating processes, logic engines, I/O
> scanners, timer execution engines, counter execution engines, PID
> execution engines......

OK. In that case, all they need to be is a list of files - every file will have 1000 or 1024 points in it, regardless of how many of those are
actually used.

> >> For outputs, which logic engine has control of them. Other logic
> >> engines can read the values if required, but are forbidden to set
> >> them.

> >How is control of an output handed from one module to another?

> It isn't.

See my other post ("Exclusive outputs") and let me know if you're happy with that.


Jiri
--
Jiri Baum <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Mon Jan 17 00:42:45 2000 Jiri Baum wrote...
>
>> >Stan Brown:
>> >> 2. Structure, I propose that a data table definition file look something
>> >> like this:
>
>> >> # Start Length I/O ? Logic Engine
>> >> I0/0 16 Y
>> >> O0/0 16 Y 1
>
>Jiri:
>> >I'm not a big fan of fixed-width,
>
>Stan Brown:
>> Hmm, let me clarify, it's not fixed width. The following are all
>> acceptable:
>
>> N7:0/0
>> N007:0/0
>> N7:000/0
>> N7:0/00
>
>But is this below acceptable?
>
># Start Length I/O ? Logic Engine
>I0/0 16 Y
>O0/0 16 Y 1

Yes, why not? Real I/O and non I/O data table are _very_ different things, as I keep saying.

>> You get the idea. leading zeros are unnecessary, but tolerated.
>
>Careful about that - some people interpret leading zeros as base-8.

Not PLC application programmers. This brings up an interesting point. We have to be careful to remember the different way PLC application programmers look at things, versus C coders.

>> >There's also a lot of fields missing from your description - for each
>> >point, you also need which device it's on and the address on that device,
>> >and maybe also a human name (the configure-r would strip the human name
>> >before passing the data to the core, but other programs would display it).
>
>> Nope, the mapping between physical point, and data table location is done
>> in a configuration file for the I/O scanner tasks(s).
>
>OK, no problem.
>
>> The description of physical; I/O location varies way to much between
>> vendors to fit into a standard one size fits all config file.
>
>I was going to leave it the rest of the line, with any printable character
>allowed (ASCII 32-126). I should have made the examples reflect this.
>
>> The human readable part is a function of the editor/viewer/documenter
>> software, and need not clutter up the data table definition files.
>> Remember the data table definition files define far more than just real
>> I/O. They define all memory as seen by the logic engine(s), timer
>> execution engines et all.
>
>Yes, of course. I guess it's a one-big-file vs lots-of-little-files
>distinction, which isn't very important.

Actually, I consider that issue very important. IMHO it's one of the places where the *NIX way of doing things is much better than the
Microsoft way of doing things.

Typically in the *NIX world you have lot's of small ASCII config files. In the Microsoft world, you have one big binary config file.

I have actually seem HMI products seriously degraded, when the were ported to Microsoft OS's. Apparently their are serious issues in those OS's with having a lot of open file descriptors, where a lot appears to be more than 10 or so.

Please don't take this as an OS flame.
>
>> >Each driver should come with a file that defines what arguments are
>> >required or needed, and what ranges they should be in. This probably goes
>> >into /usr/{local,}/lib/plc rather than /etc/plc
>
>> >Eg (in file driverID.driver):
>> > driver driverID
>> > requires address IP [network address]
>> > accepts delay 1<=int<=10 [frobnitzing time]
>> > points /[XY]\d+\.\d+/
>
>
>> I see something like this as the config files for the I/O scanner
>> routines as mentioned above.
>
>This is intended as a *driver* description - so that the config editor can
>ensure that the device specifications are acceptable to the driver.

I don't see any reason that the data table editor, should care what is acceptable to the I/O scanner task, why do you?

>> >We should have an idea how we will add extra fields or different-format
>> >lines when we need them. Fixed-width is rather limited in that regard.
>
>> Again the data tables themselves are limited by design for
>> understandability, speed of execution, and ease of implantation.
>
>I'd go for understandability at the expense of speed of execution - they're
>only read once at program start-up.
>
>As for ease of implementation, I think I've been spoilt by Perl... (In
>Perl, you can match a string against a regular expression to extract stuff
>out of it.)
>
>> They define the shared memory structures which will exist as a common
>> ground for all the various co-operating processes, logic engines, I/O
>> scanners, timer execution engines, counter execution engines, PID
>> execution engines......
>
>OK. In that case, all they need to be is a list of files - every file will
>have 1000 or 1024 points in it, regardless of how many of those are
>actually used.

Careful here. Data table can be of type binary (bits) word (16 bit ints) or strcuts (3 16 bit words) or more types. See my earlier posting
on this.

>> >> For outputs, which logic engine has control of them. Other logic
>> >> engines can read the values if required, but are forbidden to set
>> >> them.
>
>> >How is control of an output handed from one module to another?
>
>> It isn't.
>
>See my other post ("Exclusive outputs") and let me know if you're happy
>with that.

Yes, I think we have come to a common ground on that.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Sun Jan 16 23:54:10 2000 Jiri Baum wrote...
>
>stanb@awod.com:
>> >I use them for alarm setpoints, alarm timers, and PVs. Then I can write
>> >a 2-3 rung RLL program that uses in direction and can do hundreds (or
>> >thousands) of alarms.
>
>> Ah pointers :-)
>
>Hmm, I wonder if we could avoid pointers (particularly pointer arithmetic)
>and provide good data types instead... Probably not, but it'd be nice.

Actually pointers (AKA indirect addressing) are a powerful, and fairly well established part of existing PLC code practices.
>
>Pointers seem to lead to data structures that would have to be called
>Byzantine if only the word didn't already have a technical meaning in
>control...
>
>
>Jiri
>--
>Jiri Baum <jiri@baum.com.au>
>On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
>perl script...
>
>_______________________________________________
>LinuxPLC mailing list
>LinuxPLC@linuxplc.org
>http://linuxplc.org/mailman/listinfo/linuxplc
>


--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--
Windows 98: n.
useless extension to a minor patch release for 32-bit extensions and
a graphical shell for a 16-bit patch to an 8-bit operating system
originally coded for a 4-bit microprocessor, written by a 2-bit
company that can't stand for 1 bit of competition.
-
(c) 2000 Stan Brown. Redistribution via the Microsoft Network is prohibited.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Sun Jan 16 23:39:50 2000 Jiri Baum wrote...
>
>[different type files with the same file number]
>
>Jiri Baum:
>> >Can you give me an example where this would be useful? I'm doubtful, but
>> >I'm willing to be convinced...
>
>Stan Brown:
>> N400: Raw analog data
>> F400: scaled data.
>
>> has a one to one mapping, so you can just look at, say word 15 in the
>> raw data file, and see the scaled value in word 15 of the scaled data
>> file.
>
>Sounds like the scheme I was vaguelly suggesting for timers...
>
>Would you be happy with
> 400: Raw analog data
> 410: scaled data
>with the types defined elsewhere?
>
>
>Really, all of these ought to use structs. I don't think we should aim to
>implement structs in v.1.0, but we probably shouldn't implement too many
>klugey workarounds if we intend to implement structs eventually.
>
>Your point about the persistence engine being more likely to consistently
>save adjacent points applies to this, too. [1]
>
>
>Jiri
>[1] Though maybe the persistence engine ought to have checks to ensure that
>it can't load an inconsistent state.
>--
>
I don't see how we could define a consistent state, sounds to deeply embedded in the application code to be handle by the PLC tasks themselves.

Or do you have something in mind here?


--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 17 January, 2000 - 9:55 am

This has a certain elegance, but it is no less simple to allocate;

N400: Raw analog data
F401: Scaled data

Which is what most of us are already used to doing.

If it can be done there is no reason not to do it (duplicate file numbers), I can think of one way of doing it in my program, the other way is easier
though (unique file numbers) as this way you can just define a two dimensional array or Vector object.


-----Original Message-----
From: linuxplc-admin@linuxplc.org [mailto:linuxplc-admin@linuxplc.org]On
Behalf Of Stan Brown

On Sun Jan 16 05:17:36 2000 Jiri Baum wrote...
>
>
>Can you give me an example where this would be useful? I'm doubtful, but
>I'm willing to be convinced...

Absolutely:

N400: Raw analog data
F400: scaled data.

has a one to one mapping, so you can just look at, say word 15 in the
raw data file, and see the scaled value in word 15 of the scaled data
file.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 17 January, 2000 - 9:55 am

<clip>
>I use them for alarm setpoints, alarm timers, and PVs. Then I can write a
>2-3 rung RLL program that uses in direction and can do hundreds (or
>thousands) of alarms.
</clip>

I do the same thing in PLC5, SLC(to a lesser extent), and Siemens S5. All of
which have unique file numbering.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 17 January, 2000 - 9:55 am

One reason is performance, the other is power.

1131-3 specifies the use and declaration of variables by variable name, although direct addressing is also allowed.

The point is that this is an application issue, dealt with purely by the high level development tools. It is one thing to reference the data by
variable names when you are drawing the ladder or SFC, it is another thing entirely to do it at PLC level.

The computer addresses memory numerically, to do other wise in the PLC virtual machine would mean an additional level of abstraction, e.g. the
numerical addresses referenced by a string, probably using some kind of hash table. Ultimately the memory architecture will come down to a numerical reference.

{My PLC (MyPLC there's a thought) will allow the option of referencing by variable name or direct address (as per 1131-3), of assigning an address to a variable name in the application program, or having the compiler assign the address to the variable at compile time. All options (hopefully)
covered.)

-----Original Message-----
From: linuxplc-admin@linuxplc.org [mailto:linuxplc-admin@linuxplc.org]On
Behalf Of Nick Schembri

why? The part is never understood was the use of hard references to memory used by plcs.
I hated adding a meaningful comment to the N7:0/1. ...<clip>

> Do you mean leave of say the 7 in N7:0 ? If we do that we are
> limiting
> ourselves to only 1 file of a given type of data! I use many
files
> in
> my programs, it's an excellent organizational tool. For example
I
> might
> have the following:
>
> N400: Raw data
> N401: Min scale
> N402: Max scale
> F400: Scaled data
>
> Perhaps no the worlds best example, since many kinds of analog
I/O
> will
> hopefully be able to provide scaled data, but I think you get
the
> idea.
> Also note that there is a N400: and an F400: No need to limit a
> given
> file number to only 1 type of data. These are of course separate

> memory
> files.
>
> Or am I misunderstanding your intent here?
>
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By David Wooden on 17 January, 2000 - 10:56 am

I know that this will sound strange to the PLC users here, but can't we leave that choice to the user level software? One of the advangages the PC has over the PLC is that it's not limited to predefined memory "files" or areas. If we define a structure such as:
struct MemArea {
char cName[40]; // Name of area
enum eType; // Memory type: 1=bool, 2= word, etc.
int iSize; // Size of memory area
}

The user could then call the memory area by whatever name best fits the usage;
instead of

N400: Raw data
N401: Min scale
N402: Max scale
F400: Scaled data

he / she could have:

RawData
MinScale
MaxScale
ScaledData

This could make life much easier to the user, who no longer has to keep track of
what file does what.

Just an opinion. (My own, not my employers or anyone else's.)

David Wooden
Omron Electronics, Inc.
1300 Basswood Road Suite 200
Schaumburg, IL 60173
(847) 884-7034
david_wooden@omron.com

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc







_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Mon Jan 17 10:55:25 2000 David Wooden wrote...
>
>I know that this will sound strange to the PLC users here, but can't we leave
>that choice to the user level software? ...<clip>

I believe that this abstraction belongs in the editing/viewing/documentation engine.


--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

I agree, this was the point I was trying to make in yesterdays post. The data structure is left up to the logic program and the I/O mapper converts from the actual I/O to the virtual I/O. Is this how the other members of the list envision the virtual I/O?

Bill Sturm



At 09:55 AM 1/17/2000 -0600, you wrote:
>
>
>I know that this will sound strange to the PLC users here, but can't we leave
>that choice to the user level software? ...<clip>

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

At 01:13 AM 1/17/2000 -0500, you wrote:
>
>From: "Phil Covington" <phil@philcovington.com>
>To: <linuxplc@linuxplc.org>
>Subject: Re: LinuxPLC: Data table config files
>Date: Sun, 16 Jan 2000 21:43:14 -0500
>charset="iso-8859-1"
>Reply-To: linuxplc@linuxplc.org
>
>Bill, you need to read some of the other recent threads! Much of this have >been discussed a nausium! :-)

I have read the other threads, every single one, and I still think that my point is valid. I would like to see the virtual data structure defined by the logic program. The I/O mapper would convert from actual I/O to the user structure. If this is how it is presently decided, then fine. I understand that it makes sense to pick some initial format to work with,
such as A-B, but I think it is important that the data format of the user logic program will remain flexible.

Bill Sturm

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Mon Jan 17 11:59:07 2000 Bill wrote...
>
>I agree, this was the point I was trying to make in yesterdays post. The
>data structure is left up to the logic program and the I/O mapper converts
>from the actual I/O to the virtual I/O. Is this how the other members of
>the list envision the virtual I/O?
>

In a word no :-)

Data table (I/O or not) is defined by data table config files.

These get mapped into shared memory segments. Logic engines, time engines, and I/O scanner engies co-operate by sharing these data table.

The I/O scanners map I/O as described by their underlying protocol to the I/O image tables, making reference to the appropriate force tables, as required.

These data tables are configure as type, file, word, bit sets.
It is the job of the programming/editing/documentation engine to provide any higher level of abstraction.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Mon Jan 17 12:07:57 2000 Bill wrote...
>
>At 01:13 AM 1/17/2000 -0500, you wrote:
>>
>>From: "Phil Covington" <phil@philcovington.com>
>>To: <linuxplc@linuxplc.org>
>>Subject: Re: LinuxPLC: Data table config files
>>Date: Sun, 16 Jan 2000 21:43:14 -0500
>>charset="iso-8859-1"
>>Reply-To: linuxplc@linuxplc.org
>>
>>Bill, you need to read some of the other recent threads! Much of this have
>>been discussed a nausium! :-)
>
>I have read the other threads, every single one, and I still think that my point is valid. I would like to see the virtual data structure defined by the logic program. ...<clip>

The long term plan that I am advocating will allow for user defined structures of the existing data types. These structures could be
implemented totally at the application program level, without any need to change the underlying code.

Will this meet your needs?

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Scott Cornwall on 17 January, 2000 - 2:58 pm

Stan Brown wrote:
> The long term plan that I am advocating will allow for user defined structures of the existing data types. These structures could be
implemented totally at the application program level, without any need to change the underlying code. <

Can you please explain how your "files", where each is of a single data
type, allows for this ?

Scott Cornwall
www.psc.fp.co.nz


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

Jiri Baum:
> >[1] Though maybe the persistence engine ought to have checks to ensure
> >that it can't load an inconsistent state.

Stan Brown:
> I don;t see how we could define a consistent state, sounds to
> deeply embedded in the application code to be handle by the PLC
> tasks themselves.

> Or do you have something in mind here?

Disallow partially-completed saves.

But you are right, "consistent state" is too strong a word for it.

Jiri
--
Jiri Baum <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

Jiri Baum:
> >This is intended as a *driver* description - so that the config editor
> >can ensure that the device specifications are acceptable to the driver.

Stan Brown:
> I don't see any reason that the data table editor, should care what is acceptable to the I/O scanner task, why do you? <

The editor for the I/O scanner config should care, so that it can warn the
user of at least the gross errors.


Jiri
--
Jiri Baum <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

Jiri Baum:
> >Hmm, I wonder if we could avoid pointers (particularly pointer arithmetic)
> >and provide good data types instead... Probably not, but it'd be nice.

Stan Brown:
> Actually pointers (AKA indirect addressing) are a powerful, and
> fairly well established part of existing PLC code practices.

I know they are powerful and well established. That doesn't mean they're a good idea, it just means we probably can't avoid them.


Jiri
--
Jiri Baum <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

At 01:35 PM 1/17/2000 -0500, you wrote:
>
> The long term plan that I am advocating will allow for user defined structures of the existing data types. These structures could be
implemented totally at the application program level, without any need to change the underlying code.
> Will this meet your needs? <

It sounds good to me.


Bill Sturm
Bill Sturm
Applied Grinding Technologies

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By David Wooden on 17 January, 2000 - 5:52 pm

"Stan Brown" <stanb@awod.com> on 01/17/2000 11:00:08 AM

>On Mon Jan 17 10:55:25 2000 David Wooden wrote...
>>I know that this will sound strange to the PLC users here, but can't we leave
>>that choice to the user level software? One of the advangages the PC has over
>>the PLC is that it's not limited to predefined memory "files" or areas. If we
>>define a structure such as:
>>struct MemArea {
>> char cName[40]; // Name of area
>> enum eType; // Memory type: 1=bool, 2= word, etc.
>> int iSize; // Size of memory area
>> }
>>
>>The user could then call the memory area by whatever name best fits the usage;
>>instead of
>>
>> N400: Raw data
>> N401: Min scale
>> N402: Max scale
>> F400: Scaled data
>>
>>he / she could have:
>>
>> RawData
>> MinScale
>> MaxScale
>> ScaledData
>>
>>This could make life much easier to the user, who no longer has to keep track
of
>>what file does what.
>>
>>Just an opinion. (My own, not my employers or anyone else's.)
>>
>
> I believe that this abstraction belongs in the
> editing/viewing/documentation engine.

OK. I won't argue with that. But by the same token, shouldn't the file based memory segmentation be left to the editing/viewing/ documentation as well? At the logic engine level, does the system care how memory is arranged? Why should our open source system be locked in to one of the largest proprietary hardware vendors' memory management scheme? I think that any segmentation of memory should be organized by the user in the language and format that best fits the
application.

Again, my opinion. (Not necessarily my employer's)

David Wooden
Omron Electronics, Inc.
1300 Basswood Road Suite 200
Schaumburg, IL 60173
(847) 884-7034
david_wooden@omron.com>

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Mon Jan 17 17:51:21 2000 David Wooden wrote...
>>
>> I believe that this abstraction belongs in the editing/viewing/documentation engine.<<
>
>OK. I won't argue with that. But by the same token, shouldn't the file based
>memory segmentation be left to the editing/viewing/ documentation as well? At
>the logic engine level, does the system care how memory is arranged? Why should
>our open source system be locked in to one of the largest proprietary hardware
>vendors' memory management scheme? I think that any segmentation of memory
>should be organized by the user in the language and format that best fits the
>application.
>

Efficiency, commonly understood, flexible.....


--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--
Windows 98: n.
useless extension to a minor patch release for 32-bit extensions and
a graphical shell for a 16-bit patch to an 8-bit operating system
originally coded for a 4-bit microprocessor, written by a 2-bit
company that can't stand for 1 bit of competition.
-
(c) 2000 Stan Brown. Redistribution via the Microsoft Network is prohibited.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Mon Jan 17 14:54:59 2000 Scott Cornwall wrote...
>
>> The long term plan that I am advocating will allow for user defined
>> structures of the existing data types. These structures could be
>> implemented totally at the application program level, without any
>>need to change the underlying code.
>
>Can you please explain how your "files", where each is of a single data
>type, allows for this ?

Good question. I was deferring this design until we had something going to start from, but it should be considered at this stage.

I am thinking that the application program might get a "declaration" section, where it created structs from existing files. But i have not fully thought this out yet, it's just a desire at this point.

Anyone got any suggestions here?

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Mon Jan 17 12:17:49 2000 Jiri Baum wrote...
>
>Jiri Baum:
>> >This is intended as a *driver* description - so that the config editor
>> >can ensure that the device specifications are acceptable to the driver.
>
>Stan Brown:
>> I don't see any reason that the data table editor, should care what
>> is acceptable to the I/O scanner task, why do you?
>
>The editor for the I/O scanner config should care, so that it can warn the
>user of at least the gross errors.
>
Agreed, although I think we are going to be editing config files with
text editors for quite a while.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 18 January, 2000 - 12:59 pm

> <snip>
> > Naming
> >
> > I propose to go with a style that the AB centric members of this list will recognize :-)
> >
> > [TYPE}{File No.]:{Element No.].[Subelemnt No.]
> >
> > Types are:
> >
> > I = Input (digital)
> > O = Output (digital)
> > B = Binary
> > C = Counter
> > T = Timer
> > F = Float
> > L = Long Int.
> > R = File operation control
> > P = Pid
> > M = Message control
> >
> > some examples:
> >
> > I0/0 real digital input word 0 bit 0
> > O0/0 real digital output word 0 bit 0
> > N7:0 integer file 7 word 0
> > T4:3.dn Timer file 4 element 3 done bit
> >
> > Comments?
> <snip>
>
> or modicon style:
>
> 0XXXXX logic coils (one bit) either mapped to i/o or not e.g.
> 000001, 000123
>
> 1XXXXX digital inputs (one bit) mapped e.g. 100001, 100105
>
> 3XXXXX input registers mapped e.g. 300001, 300450
>
> 4XXXXX output registers/ holding register e.g. 400003, 409999 <

I vote for the IEC61131 style of addressing


----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 Hässleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Dan Pierson on 18 January, 2000 - 1:04 pm

> From: Jiri Baum [mailto:jiri@baum.com.au]
> Subject: Re: LinuxPLC: Data table config files

> Stan Brown:
> > # Start Length I/O ? Logic Engine
> > I0/0 16 Y
> > O0/0 16 Y 1
>
> I'm not a big fan of fixed-width, I'd prefer either
> something-separated
> (colons? commas?) or rich syntax. (Rich syntax would be parsed by a
> separate program, which would use the dynamic-reconfigure
> interface to pass
> it to the core.[1])

Whitespace separated fields is very definitely the Linux/Unix convention. I'd advise sticking with it for all low level config files. Whether you align the columns or not is more a matter of whether you want to be able to read the file later :-)

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

David Wooden:
> OK. I won't argue with that. But by the same token, shouldn't the file based memory segmentation be left to the editing/viewing/ documentation as well? At the logic engine level, does the system care how memory is arranged? Why should our open source system be locked in to one of the largest proprietary hardware vendors' memory management scheme? I think that any segmentation of memory should be organized by the user in the language and format that best fits the application. <

i386-linux works on 4K VM pages.

It's probably a good idea to use that explicitly at least to some extent, as no doubt we'll find ourselves doing nasty tricks to the VM manager at
some time or another in the future.


Jiri
--
Jiri Baum <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Tue, Jan 18, 2000 at 01:04:00PM -0500, Dan Pierson wrote:
> > From: Jiri Baum [mailto:jiri@baum.com.au]
> > Subject: Re: LinuxPLC: Data table config files
>
> > Stan Brown:
> > > # Start Length I/O ? Logic Engine
> > > I0/0 16 Y
> > > O0/0 16 Y 1
> >
> > I'm not a big fan of fixed-width, I'd prefer either
> > something-separated
> > (colons? commas?) or rich syntax. (Rich syntax would be parsed by a
> > separate program, which would use the dynamic-reconfigure
> > interface to pass
> > it to the core.[1])
>
> Whitespace separated fields is very definitely the Linux/Unix convention.
> I'd advise sticking with it for all low level config files. Whether you
> align the columns or not is more a matter of whether you want to be able to
> read the file later :-)

I think the format(s) used in configuration files will be an important issue, and I'd like to suggest XML as a consideration. XML is a developing standard, and can be complicated, but the basic idea is simple, that of enclosing content within matching tags. It is (significantly) more verbose than many leaner formats, but does have practical advantages, including being amenable to manipulation using generic libraries and tools.

The information above could be represented in any number of ways, e.g.,

<datatable>
<start>I0/0</start>
<length>16</length>
<IO>Y</IO>
<LogicEngine>0</LogicEngine>
</datatable>

or using attributes,

<datatable start="I0/0" length="16" IO="Y" />
<datatable start="I0/0" length="16" IO="Y" engine="1" />


The config file format of choice can certainly be one of those religious areas, but I hope that XML is considered for the Linux PLC project's
data. (There is a simplified version of XML, SML, being hashed out that might actually be more appropriate for this purpose.)

--
Ken Irving
Trident Software
jkirving@mosquitonet.com


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Tue Jan 18 16:04:40 2000 Ken Irving wrote...
>
>I think the format(s) used in configuration files will be an important
>issue, and I'd like to suggest XML as a consideration. ...<clip>
>
>The information above could be represented in any number of ways, e.g.,
>
> <datatable>
> <start>I0/0</start>
> <length>16</length>
> <IO>Y</IO>
> <LogicEngine>0</LogicEngine>
> </datatable>
>
>or using attributes,
>
> <datatable start="I0/0" length="16" IO="Y" />
> <datatable start="I0/0" length="16" IO="Y" engine="1" />
>
>
>The config file format of choice can certainly be one of those religious
>areas, but I hope that XML is considered for the Linux PLC project's
>data. (There is a simplified version of XML, SML, being hashed out that
>might actually be more appropriate for this purpose.)

Could you please explain what benefits the extra editing, parsing complexity of this language would bring, over simple whitespace
delimited flat files?

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Tue Jan 18 13:04:00 2000 Dan Pierson wrote...
>
>> From: Jiri Baum [mailto:jiri@baum.com.au]
>> Subject: Re: LinuxPLC: Data table config files
>
>> Stan Brown:
>> > # Start Length I/O ? Logic Engine
>> > I0/0 16 Y
>> > O0/0 16 Y 1
>>
>> I'm not a big fan of fixed-width, I'd prefer either
>> something-separated
>> (colons? commas?) or rich syntax. (Rich syntax would be parsed by a
>> separate program, which would use the dynamic-reconfigure
>> interface to pass
>> it to the core.[1])
>
>Whitespace separated fields is very definitely the Linux/Unix convention.
>I'd advise sticking with it for all low level config files. Whether you align the columns or not is more a matter of whether you want to be able to read the file later :-) <

That is what I had in mind here, sorry if I was not clear.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--
Windows 98: n.
useless extension to a minor patch release for 32-bit extensions and
a graphical shell for a 16-bit patch to an 8-bit operating system
originally coded for a 4-bit microprocessor, written by a 2-bit
company that can't stand for 1 bit of competition.
-
(c) 2000 Stan Brown. Redistribution via the Microsoft Network is prohibited.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Tue, Jan 18, 2000 at 09:28:05PM -0500, Stan Brown wrote:
> On Tue Jan 18 16:04:40 2000 Ken Irving wrote...
> >
> >I think the format(s) used in configuration files will be an important
> >issue, and I'd like to suggest XML as a consideration. XML is a developing
> >standard, and can be complicated, but the basic idea is simple, that of
> >enclosing content within matching tags. It is (significantly) more verbose
> >than many leaner formats, but does have practical advantages, including being
> >amenable to manipulation using generic libraries and tools.
> >
> >The information above could be represented in any number of ways, e.g.,
> >
> > <datatable>
> > <start>I0/0</start>
> > <length>16</length>
> > <IO>Y</IO>
> > <LogicEngine>0</LogicEngine>
> > </datatable>
> >
> >or using attributes,
> >
> > <datatable start="I0/0" length="16" IO="Y" />
> > <datatable start="I0/0" length="16" IO="Y" engine="1" />
> >
> >
> >The config file format of choice can certainly be one of those religious
> >areas, but I hope that XML is considered for the Linux PLC project's
> >data. (There is a simplified version of XML, SML, being hashed out that
> >might actually be more appropriate for this purpose.)
>
> Could you please explain what benefits the extra editing, parsing complexity of this language would bring, over simple whitespace
delimited flat files? <

I mentioned a couple of benefits above. Another is that XML config files might tend to be more explicit in which parameters are being set, then if just the values are shown but not the parameter names. The examples given (previously) where a bit difficult to read on my mail reader due to the different handling of whitespace and vertical alignment.

Another is that XML *may* become much more widely used for other config file formats. It is (I understand) already used for some systems,
including Gnome (I don't currently use anything that uses XML in this way). This should in turn increase the availability of tools and libraries
for dealing with it.

"Simple whitespace delimited flat files" doesn't define the format, but relies on an application's parser to make sense of it. Each application
gets to choose its own file format, which is part of the fun of developing an application. I like making up data formats and figuring out how to
parse others as much as anybody, but while XML may take some of this fun away, I think there's an advantage in having a simple, unambiguous format.

XML simply defines the format, and says nothing of what the tags are or how they're used. It uses plain text, flat files, so there's not a huge
difference there.

It is more verbose, and probably no more clear to a human than other, simpler formats, but is very condusive to automated handling. This would probably include editors as well as parsers, neither of which would necessarily have to be coded specifically for this project.

I don't blame anyone for questioning how XML could be preferred over all or any of the different formats that are now used (and more all the time), but while it is relatively new, I think it has promise.

--
Ken Irving
Trident Software
jkirving@mosquitonet.com


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Mon, 17 Jan 2000, Bill Sturm wrote:

> I agree, this was the point I was trying to make in yesterdays post. The data structure is left up to the logic program and the I/O mapper converts from the actual I/O to the virtual I/O. Is this how the other members of the list envision the virtual I/O? <
>

Seems sensible to me.

Dave West E-Mail: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc