Data Types

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

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

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

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

Johan Bengtsson

> <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: [email protected]
Internet: http://www.pol.se/
----------------------------------------


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
D
> From: Jiri Baum [mailto:[email protected]]
> 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
[email protected]
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 <[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 Tue, Jan 18, 2000 at 01:04:00PM -0500, Dan Pierson wrote:
> > From: Jiri Baum [mailto:[email protected]]
> > 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
[email protected]


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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Tue Jan 18 13:04:00 2000 Dan Pierson wrote...
>
>> From: Jiri Baum [mailto:[email protected]]
>> 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 [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 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
[email protected]


_______________________________________________
LinuxPLC mailing list
[email protected]
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: [email protected]
Semiras Projects Ltd. PGP public key available on request.


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

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