Data Types

R
In a message dated 01/16/2000 10:51:44 AM Central Standard Time, [email protected] 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
[email protected]
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
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
P

Phil Covington

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

> 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
[email protected]
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 <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
[email protected]:
> >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 <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
> >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 <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

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


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sun Jan 16 23:54:10 2000 Jiri Baum wrote...
>
>[email protected]:
>> >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 <[email protected]>
>On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
>perl script...
>
>_______________________________________________
>LinuxPLC mailing list
>[email protected]
>http://linuxplc.org/mailman/listinfo/linuxplc
>


--
Stan Brown [email protected] 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
[email protected]
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 [email protected] 843-745-3154
Westvaco
Charleston SC.

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

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







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

_______________________________________________
LinuxPLC mailing list
[email protected]
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
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
At 01:13 AM 1/17/2000 -0500, you wrote:
>
>From: "Phil Covington" <[email protected]>
>To: <[email protected]>
>Subject: Re: LinuxPLC: Data table config files
>Date: Sun, 16 Jan 2000 21:43:14 -0500
>charset="iso-8859-1"
>Reply-To: [email protected]
>
>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
[email protected]
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 [email protected] 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
[email protected]
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" <[email protected]>
>>To: <[email protected]>
>>Subject: Re: LinuxPLC: Data table config files
>>Date: Sun, 16 Jan 2000 21:43:14 -0500
>>charset="iso-8859-1"
>>Reply-To: [email protected]
>>
>>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 [email protected] 843-745-3154
Westvaco
Charleston SC.

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

Scott Cornwall

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