Data Types

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

THINK BIG, Start Small.

(This one's for Simon :)

If you knew Suse like I know Suse ........
_______________________________________________
LinuxPLC mailing list
[email protected]
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 [email protected] 843-745-3154
Westvaco
Charleston SC.
--
_______________________________________________
LinuxPLC mailing list
[email protected]
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 [email protected] 843-745-3154
Westvaco
Charleston SC.
--
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S

Sage, Pete (IndSys, GEFanuc, Albany)

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:[email protected]]
> Sent: Friday, January 14, 2000 03:47 PM
> To: [email protected]
> 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 [email protected]
> 843-745-3154
> Westvaco
> Charleston SC.
> --
_______________________________________________
LinuxPLC mailing list
[email protected]
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 [email protected] 843-745-3154
Westvaco
Charleston SC.
--
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
H

Hurd, David L (GEA, 053698)

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

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

Butler, Lawrence

> -----Original Message-----
> From: Stan Brown [SMTP:[email protected]]
<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
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
H

Hurd, David L (GEA, 053698)

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

Phil Covington

----- Original Message -----
From: "Butler, Lawrence" <[email protected]>

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

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

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

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

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

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

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