Data Types

A

Thread Starter

August Albert

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
[email protected]
Singapore


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

August Albert

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
[email protected]
Singapore


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
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
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
At 08:59 PM 1/7/2000 -0500, you wrote:
>From: Mark Bayern <[email protected]>

>> * 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
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
Bill wrote:
>
> At 08:59 PM 1/7/2000 -0500, you wrote:
> >Date: Fri, 07 Jan 2000 16:50:16 -0600
> >From: Mark Bayern <[email protected]>
> >Organization: MLB Electronics, Inc.
> >To: [email protected]
> >Subject: Re: LinuxPLC: Data Types
> >Reply-To: [email protected]
> >
> >> * 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
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S

Simon Martin

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: [email protected]

----- Original Message -----
From: Bill
To: [email protected]
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
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
P

Phil Covington

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

Phil Covington
vHMI

----- Original Message -----
From: "Stan Brown" <[email protected]>
To: "Linux PLC list" <[email protected]>
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 [email protected]
843-745-3154
> Westvaco
> Charleston SC.

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

Nick Busigin

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... [email protected]

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



_______________________________________________
LinuxPLC mailing list
[email protected]
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
<[email protected]>
_______________________________________________
LinuxPLC mailing list
[email protected]
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
[email protected]
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 [email protected] 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 [email protected] 843-745-3154
Westvaco
Charleston SC.

LinuxPLC mailing list
[email protected]
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 [email protected] 843-745-3154
Westvaco
Charleston SC.
--
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
P

Phil Covington

----- Original Message -----
From: "Stan Brown" <[email protected]>

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

There is a chasm of carbon and silicon the software cannot bridge
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
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 [email protected] 843-745-3154
Westvaco
Charleston SC.
--
_______________________________________________
LinuxPLC mailing list
[email protected]
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 [email protected] 843-745-3154
Westvaco
Charleston SC.
--
_______________________________________________
LinuxPLC mailing list
[email protected]
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 [email protected] 843-745-3154
Westvaco
Charleston SC.
-
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top