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?

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

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

 

I have one:
Adding more possible parameters after the first version is set and the possibility to have default values for some parameters is easier with a more complex format. If that is enough reason is another matter and I would probably say no.

/Johan Bengtsson

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


-----Original Message-----
From: MIME :[email protected] [SMTP:MIME :[email protected]]

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?


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

 

On Tue, Jan 18, 2000 at 09:30:50PM -0500, Stan Brown wrote:
> 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.

No worries.

Whitespace-separated is OK.


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