Dave West wrote:
>Anyway the question remains the same. Do we want two different logic
>engines to be directly capable of modifying the same real outputs without
>regard for each other.

I can imagine that there would be some types of end user applications that could take advantage of multiple logic engines being able to write to an output, but I believe that most industrial control types would end up using multiple tasks running in one logic engine in such applications
anyway. Two logic engines controlling the same entity (output) sure doesn't fit well with encapsulation concepts either. How about such a feature be tabled for now and be addressed again for future releases if the desire is still out there?

Alan Locke



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

 

On Thu, 27 Jan 2000, Alan Locke wrote:

> Dave West wrote:
> >Anyway the question remains the same. Do we want two different logic
> >engines to be directly capable of modifying the same real outputs without
> >regard for each other.
>
> I can imagine that there would be some types of end user applications that
> could take advantage of multiple logic engines being able to write to an
> output, but I believe that most industrial control types would end up using
> multiple tasks running in one logic engine in such applications
> anyway. Two logic engines controlling the same entity (output) sure doesn't
> fit well with encapsulation concepts either. How about such a feature be
> tabled for now and be addressed again for future releases if the desire is
> still out there?
>
> Alan Locke

Thank you for your agreement.


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 Tue, Jan 25, 2000 at 11:07:07AM +0000, Dave West wrote:

> Did you read the next part? All that functionallity should be via a well
> defined communication medium. The same functions in the library can be
> used to allow data transfer over ethernet, provide access for the
> monitoring tools and provide data transfer to a HMI or whatever else may
> want read only access.

I think we both mean the same thing, we just aren't expressing ourselves very well...

I'm assuming that this well-defined communication medium is the SMM area.


> > > If an engine doesn't know it exists it can't access it accidently or
> > > on purpose. If one engine needs to access data from another it shuld
> > > do so via a defined communication medium / protocol and the
> > > operator/programmer will handle it in the logic programme.

> > Which are - to a first approximation - the internal coils. Each point
> > is assigned to a particular task to write, any other task can access it
> > read-only.

> And all internal coils belong to one logic engine and one logic engine
> only and are not writable by any other process at all via any mechanism.

But they are readable to any other process.

> If you disagree can you explain which othere processes would require to
> write to an internal coil (other than the one logic engine that is, in
> effect, using it for a state indication).

Only the owner of an internal coil may write to it.

I've been proposing that (as an option - remember what the kitten said) it should be possible to configure a point to be owned by a semaphore, so that whichever logic engine holds the semaphore, controls the point.

But I'm quite happy for you never to use that feature.

> > By convention, points assigned to an IO driver to write are called
> > "physical inputs"; points that an IO driver reads are called "physical
> > outputs". All other points are called "internal coils/data". But this
> > is just a convention - as far as the SMM is concerned, tasks is tasks
> > and bits is bits.

> Never mentioned, disagreed with or questioned this in any way shape or form. Did I? <

I think I was just trying to make myself clear, and overdid it a bit... Better than the other way, I thought - sorry if it sounded too obvious.

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

 

> > Dave West:
> > > I don't see the point in this. Why would one want the same hardware
> > > to run 2 programmes? It is of no use for reliability, if the
> > > hardware fails both programmes die. Why would anyone want 2
> > > different sets of logic to control the same equipment?

Jiri Baum:
> > Because it's used for two different purposes, or in two different ways?

Dave West:
> Then the different sets of logic are mutually exclusive and should not be
> running at the same time. Still no reason for different "logic engines"
> to be aware of the same I/O.

OK, example 1:

The machine is divided into sections, and there's one logic engine per section. At some boundaries, though, there is a bit of an overlap.

Section A grabs a semaphore and puts a product into the overlapping area. Then it releases the semaphore and signals Section B. Section B then grabs the semaphore, takes the product, and releases the semaphore.

Actually, in this case there would be two or three semaphores: one to protect the outputs, the other one or two to handle the bounded buffer
problem (sorry, it's too late for me to think if one is enough). Or else you can have the first semaphore protect an internal coil that says
"product/no product".


Example 2:

Several work areas (in a single cell) are serviced by one robotic arm. Whenever a work area needs the robotic arm, it grabs a semaphore and then has exclusive access to it. When it's finished, it releases the semaphore.

Note: this probably wouldn't be sharing physical outputs but rather the data-table area into which requests are written. The principle is the same,
though.

Note: in the above, I've been throwing around the word "grab" carelessly. Keep in mind that grabbing a semaphore involves either sleeping on it or busy-waiting on it.

> > > Maybe the shuttle does but that is a specific, dedicated and original
> > > application and wouldn't use something as "un-reliable" as a PLC
> > > anyway .

> > No, that's something different - that's redundancy. Nothing to do with
> > this.

> Even more weight to my point.
> Jiri, do you understand what I am trying to say here?

I think so...

> I can see no reason for multiple semaphores or anything else for
> controlling ownership of I/O points. I think it is simply some ones over
> excitement at a new project getting away with them.

Can we agree on "We'll Do That Later"?

(Or, "You Want It, You Write It"?)

> All I/O is described in config files. The config file should describe
> this I/O as read or write. Every logic engine uses different I/O config
> files. The logic engine that can control the Output is told about it's
> write address no other engine has this information in the config file and
> thus cannot contend for control of the output. End of problem, 500 lines
> of code saved and easier to understand IMHO.

It's probably better to have one set of I/O files, so that all the logic engines use the same names for the same points. Otherwise the programmer is likely to be very confused very soon.

The config files specify which single task has write rights to the point; whether it's an I/O driver (for inputs) or a particular logic engine or other program. All other tasks may access the point read-only.

Dynamic ownership should slot into that scheme neatly enough to be made an option.


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