Data table

S

Thread Starter

Stan Brown

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 forpreset, 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
 
nick:
> >Some German prox switches are inverted. ( negative logic?)

Stan Brown:
> 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.

Hm, if the program specification just said "proximity switch" and nobody realized it's one of them weird ones until the program was written, it's probably safer to put in a force than to go back and change every single occurrence of that input with its inverse. The latter sounds error-prone.

It doesn't matter, anyway; the force table needs two bits per input, and there's no point wasting one of these combinations even if it will be
hardly ever used. Especially since these four are the *complete* set of one-bit operations.


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

Jiri Baum:
> >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 :)

Stan Brown:
> 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.

This one knew, too - the wiring diagram said N/O - just didn't know which of the three or four lugs sticking out of the sensor were the N/O contact. He could tell the N/C contact easily enough. He was asking which are the N/O, and got told not to worry and wire it N/C instead. (As it happened, wiring N/C contacts were better anyway - fail safer.)

Which is neither here nor there, I guess. "Never use inverts unless you have to" is good advice anyway.


[TIMERS]
> >> >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.

Well, the timer execution engine can be mapped into three files just as easily as into one... As long as the documentation doesn't get bogged down
into these details, it's just an implementation convenience that nobody will care about. In the config file you specify the "timer" file, and in
the program you ask for a timer. Who cares if the timer page is magically three files?

I suppose we could also have timers occupy four consecutive positions in a single file.


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
 
S
On Fri Jan 14 21:29:25 2000 Jiri Baum wrote...
>
>nick:
>> >Some German prox switches are inverted. ( negative logic?)
>
>Stan Brown:
>> 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.
>
>Hm, if the program specification just said "proximity switch" and nobody
>realized it's one of them weird ones until the program was written, it's
>probably safer to put in a force than to go back and change every single
>occurrence of that input with its inverse. The latter sounds error-prone.

NO, first of all the "program spec" is a set of drawings that show his, second it's not a casual decision. It involves failure modes, which
have a bearing on equipment, and personnel safety. It is (or should be) always carefully thought out. What happens when a wire fails? I don't want to push my stop button, and _not_ have the machine stop, because someone wired the stop button normally open!

Also. once again forces are very short lived things, only for testing, or emergencies, that should _never_ be left enable when you are not looking at the process/machine.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
On Fri Jan 14 21:05:58 2000 Jiri Baum wrote...
>
>I suppose we could also have timers occupy four consecutive positions in a
>single file.

Sounds good. Think about the retentive on power fail memory issue. This means we are more likely to get a consistent state of a timer, even if we don't get all data flused.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
> Hm, if the program specification just said "proximity switch" and nobody
> realized it's one of them weird ones until the program was written, it's
> probably safer to put in a force than to go back and change every single
> occurrence of that input with its inverse. The latter sounds error-prone.

No it is not an acceptable practice. It is just simplier for lazy programmers -- why not do a mass replace of the offending instructions?
Forcing is only used for troubleshooting. In operation PLCs do not run with bits forced as a normal condition.

Mark

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
>nick:
>> >Some German prox switches are inverted. ( negative logic?)

>Stan Brown:
>> 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.

Jiri Baum:
>Hm, if the program specification just said "proximity switch" and nobody
>realized it's one of them weird ones until the program was written, it's
>probably safer to put in a force than to go back and change every single
>occurrence of that input with its inverse. The latter sounds error-prone.

This is way many designers build an I/O map into the application i.e. map Input x to internal flag y. In this way if a different sense sensor is used
then the code only needs to be changed in one place.

Jiri Baum:
>It doesn't matter, anyway; the force table needs two bits per input, and
>there's no point wasting one of these combinations even if it will be
>hardly ever used. Especially since these four are the *complete* set of
>one-bit operations.

I think that some semantic clarification is required here. I can see the usefulness of a function that allows I/O to be inverted from a single configuration, but I have trouble relating that to the concept of a FORCE. The problem is a semantic one only, but I feel it requires clarification.

In my mind a force placed on an I/O point, forces that point to a static value and inhibits its dynamic behaviour.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
On Mon Jan 17 04:08:16 2000 Mark Hutton wrote...
>
>>nick:
>>> >Some German prox switches are inverted. ( negative logic?)
>
>>Stan Brown:
>>> 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.
>
>Jiri Baum:
>>Hm, if the program specification just said "proximity switch" and nobody
>>realized it's one of them weird ones until the program was written, it's
>>probably safer to put in a force than to go back and change every single
>>occurrence of that input with its inverse. The latter sounds error-prone.
>
>This is way many designers build an I/O map into the application i.e. map
>Input x to internal flag y. In this way if a different sense sensor is used
>then the code only needs to be changed in one place.
>
>Jiri Baum:
>>It doesn't matter, anyway; the force table needs two bits per input, and
>>there's no point wasting one of these combinations even if it will be
>>hardly ever used. Especially since these four are the *complete* set of
>>one-bit operations.
>
>I think that some semantic clarification is required here. I can see the
>usefulness of a function that allows I/O to be inverted from a single
>configuration, but I have trouble relating that to the concept of a FORCE.
>The problem is a semantic one only, but I feel it requires clarification.
>
>In my mind a force placed on an I/O point, forces that point to a static
>value and inhibits its dynamic behaviour.

I think you have resolved this. I can see a flag in the config file for the I/O scanner module that would allow inversion of a digital input (and output ?) on a per point basis.

This should _not_ be confused with forces though.

Can we agree on this?

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

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

R A Peterson

In a message dated 01/17/2000 03:28:35 AM Central Standard Time,
[email protected] writes:

<< >Hm, if the program specification just said "proximity switch" and nobody
>realized it's one of them weird ones until the program was written, it's
>probably safer to put in a force than to go back and change every single
>occurrence of that input with its inverse. The latter sounds error-prone.

This is way many designers build an I/O map into the application i.e. map Input x to internal flag y. In this way if a different sense sensor is used
then the code only needs to be changed in one place.
>>

I generally do this. A biffer like this has a lot of advantages. It is particularly helpful when the customer allows the people wiring the machine to wire the I/O to the most convenient j-box rather then the j-box ith the I/O in it that have been pre-assigned to that I/O.

:)


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Mark Hutton:
> >I think that some semantic clarification is required here. I can see the
> >usefulness of a function that allows I/O to be inverted from a single
> >configuration, but I have trouble relating that to the concept of a FORCE.
> >The problem is a semantic one only, but I feel it requires clarification.

> >In my mind a force placed on an I/O point, forces that point to a static
> >value and inhibits its dynamic behaviour.

Stan Brown:
> Y think you have resolved this. I can see a flag in the config file
> for the I/O scanner module that would allow inversion of a digital
> input (and output ?) on a per point basis.

> This should _not_ be confused with forces though.

> Can we agree on this?

OK.

I just replaced "force table" with "inversion and force table" in my draft
smm.h documentation. Is that a better phrase?


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 12:12:37 2000 Jiri Baum wrote...

>I just replaced "force table" with "inversion and force table" in my draft
>smm.h documentation. Is that a better phrase?

Are you clear that they are 2 different tables? forces can be enabled, and disabled. I see no reason to allow this for an inversion table. Come to think of it I see no reason for an inversion table. can't we do that in the I/O scanner config files?

--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Jiri Baum:
> >I just replaced "force table" with "inversion and force table" in my
> >draft smm.h documentation. Is that a better phrase?

Stan Brown:
> Are you clear that they are 2 different tables? forces can be
> enabled, and disabled. I see no reason to allow this for an
> inversion table. Come to think of it I see no reason for an
> inversion table. can't we do that in the I/O scanner config files?

The SMM will handle it as one table (or rather two tables: force-on and invert). Whatever is providing the table to the SMM will combine it from the force table and the inversion table.

It's convenient to combine the two, because a force table needs two bits to record the three possibilities (normal, force-on, force-off). Once we have two bits, we have to assign some meaning to the fourth possibility, and inversion is the obvious one.


The user interface will have to be clear on what it means to force an inverted point.


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 06:25:10 2000 Jiri Baum wrote...
>
...
>The SMM will handle it as one table (or rather two tables: force-on and
>invert). Whatever is providing the table to the SMM will combine it from
>the force table and the inversion table.
>
>It's convenient to combine the two, because a force table needs two bits to
>record the three possibilities (normal, force-on, force-off). Once we have
>two bits, we have to assign some meaning to the fourth possibility, and
>inversion is the obvious one.
>
>The user interface will have to be clear on what it means to force an
>inverted point.

This is exactly why I did not want to do this. Forces have a very specific meaning in PLC's. Being able to invert an in0put is a _very_
different function. Mixing the 2 is "a bad idea" (tm).

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Wed, 19 Jan 2000, Gerry Hagberg wrote:

> As an A-B eccentric, I support the developing concensus to use a
> PLC5-like structure. Don't forget about the S (status) section.
>
> I'm unsure of the architecture some people have in mind, but in my mind,
> there is one and only one data table per physical PLC.
>
> It seems to me that the whole issue of policing access to the data table
> is an unnecessary complication. There is no protection of the sort being
> discussed in A-B PLC's. You can write to any section of the data table
> from anywhere. The only (optional) protection is over access from
> another PLC (e.g. via data highway). This is also a 'freedom' issue as
> in 'free' software - people may do things because of incompetence or
> cleverness but we shouldn't assume that it must be incompetence simply
> because it may be contrary to personal beliefs or philosophies.
>
> Gerry

I keep trying to say the same thing here. One logic engine with one set of I/O is the equivelant of one PLC and should behave in a similar manner as per what can write to the I/O. As far as access via another "PLC" is concerned, I think it should still never be able to access this "PLC'S" I/O but can set a "network" device which this "PLC" can read and the programmer can add to the logic if he wishes using explicit AND, OR etc as suggested by someone else.

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
 
On Wed Jan 19 06:20:49 2000 Dave West wrote...
>
>On Wed, 19 Jan 2000, Gerry Hagberg wrote:
>
>> As an A-B eccentric, I support the developing concensus to use a PLC5-like structure. Don't forget about the S (status) section. ...<clip> <<

>I keep trying to say the same thing here. One logic engine with one set of
>I/O is the equivelant of one PLC and should behave in a similar manner as
>per what can write to the I/O. As far as access via another "PLC" is
>concerned, I think it should still never be able to access this "PLC'S"
>I/O but can set a "network" device which this "PLC" can read and the
>programmer can add to the logic if he wishes using explicit AND, OR etc as
>suggested by someone else.

Think of multiple logic engines (processors) which can share data. This allows for having a dedicated logic engine for say each major section of a transfer line. These logic engines can then share information, such as the details of a assembly moving down the line.

This is really on a tiny extension from the ControlNet processors which can share I/O.

However this "protection" started out as a "master" for the outputs only, and has grown a bit generic for my taste, but then in practice it
may prove to be useful.

Let's try it and see how it works.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Wed Jan 19 05:01:19 2000 Gerry Hagberg wrote...
>
>As an A-B eccentric, I support the developing concensus to use a PLC5-like structure. Don't forget about the S (status) section. <

That should be intersting! Some things like date/time I/O status make sense there, however we have a very different set of other things to go there. Can this wait until 2.0 ?
>
>I'm unsure of the architecture some people have in mind, but in my mind, there is one and only one data table per physical PLC. <
>
>It seems to me that the whole issue of policing access to the data table
>is an unnecessary complication. There is no protection of the sort being
>discussed in A-B PLC's. You can write to any section of the data table
>from anywhere. The only (optional) protection is over access from
>another PLC (e.g. via data highway). This is also a 'freedom' issue as
>in 'free' software - people may do things because of incompetence or
>cleverness but we shouldn't assume that it must be incompetence simply
>because it may be contrary to personal beliefs or philosophies. <

I addressed this in another post.

--
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
 
M
There are two points to consider here (actually a good deal more, but I'm going to cover two).

Firstly, the PLC data table is local to each PLC. All data global to the system itself is treated as I/O by the PLC (logic engine).

The issue is complicated by the fact that there is no physical PLC, but certainly each virtual machine should have it's own data table (and will do any way). How you handle multitasking within a PLC virtual machine in this context is debatable, but I would suggest that it depends on how you handle the I/O update in this event.

I would suggest that if options are available, that the default case is the safest one (i.e.completely locked).



-----Original Message-----
From: [email protected] [mailto:[email protected]]On
Behalf Of Gerry Hagberg

Hi all,

As an A-B eccentric, I support the developing concensus to use a PLC5-like structure. Don't forget about the S (status) section.

I'm unsure of the architecture some people have in mind, but in my mind, there is one and only one data table per physical PLC. ...
<clip>

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Wed, Jan 19, 2000 at 06:52:38AM -0500, Stan Brown wrote:
> Think of multiple logic engines (processors) which can share data.
> This allows for having a dedicated logic engine for say each major
> section of a transfer line. These logic engines can then share
> information, such as the details of a assembly moving down the
> line.

Another use is to have a high priority logic engine doing the control, and a slow-running C-program doing fuzzy logic or FFT or something. Every now and then the C program updates some internal coil or data register that tweaks the functioning of the control process.

A third use is to have one program for running the machine in automatic mode, and another for manual mode or maintenance mode. For that, though,
you need a semaphore-based protection mechanism.


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 Wed, Jan 19, 2000 at 11:01:19PM +1300, Gerry Hagberg wrote:
> It seems to me that the whole issue of policing access to the data table
> is an unnecessary complication. There is no protection of the sort being
> discussed in A-B PLC's. You can write to any section of the data table
> from anywhere. The only (optional) protection is over access from another
> PLC (e.g. via data highway).

It's not that big a problem, and to some extent it will *simplify* implementation.

Consider: if you have two logic engines (or, say, a logic engine and a PID solver), and they each have their own private copy of the I/O/D/* tables,
how do you merge them together? You either have to keep track of who wrote what, or you keep track of who's allowed to write what. The latter option definitely sounds preferable - you get protection basically for free.

> This is also a 'freedom' issue as in 'free' software - people may do
> things because of incompetence or cleverness but we shouldn't assume that
> it must be incompetence simply because it may be contrary to personal
> beliefs or philosophies.

Sometimes cleverness is just a more dangerous version of incompetence :)

(Yes, I can imagine situations where you might want two more-or-less separate programs to run the machine, but then you probably do want
semaphore-protected outputs. Either one runs it, or the other - never both at the same time.)


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
 
Top