Fw: shared memory

On Sun Jan 16 23:06:39 2000 Jiri Baum wrote...
>
>Simon Martin:
>> Given the vehemence of Stan Brown's mail about multiple processes using
>> the same IO point I have decided that each Logic Engine will register
>> with the SharedMemoryManager, handing it the definition of the points it
>> will require and the permissions it requests.
>
>I suggest we put this in the configuration file - see my other post on this
>("Exclusive outputs").

Right, you and I agree on this being in the I/O data table config file.

>> If a logic engine requests write permission for a point that another
>> registered logic engine alread has write permission for then the request
>> will fail.
>
>I don't think we should be implementing this - we should make use of
>semaphores if we need handover of outputs between modules. Semaphores are
>the Right Thing for this job. No point re-inventing them.

Question, I am thinking of "ownership" of an output being implemented on a per point basis, as opposed to say an I/O scanner or a "rack'
basis. Given this wouldn't we have a lot of semaphores to deal with here?

>Where outputs are simply assigned to a single module, no point going to all
>that trouble, of course.
>
>> The IO use will be one of the required outputs for each Logic Engine
>> Compiler. With respect this, I am developing a cross compiler at the
>> moment for one of my customers. Once this is done (and I have finished
>> the SharedMemoryManager) I would like to get involved in the Ladder Logic
>> Compiler.
>
>I'm working on a draft of the C interface between the Logic Engine and the
>SMM. I'll post the .h file in the next couple of days.

Great!
>
>(I think this interface should be "public", so that people who don't
>want/like/need the Logic Engine can just write straight C.)

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
I am writing a logic engine, see my earlier posts, which may or may not fit in with the project as a whole (it's Java based and some list members have stated an aversion to Java).

I expect that there will be several logic engines which will compete.

I will have a system specification and outline before the end of the week, code should follow shortly.

This is a project that I have been working on for a while, the Linux PLC project has inspired me to bring it forward.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Alan Locke:
> If on the other hand this is meant as multiple logic engines running for
> different purposes (say one engine running ladder logic, maybe another
> doing data collection, maybe another running a DNC or recipe download
> process, and maybe even another for HMI), I suspect that there would be
> real problems in having multiple logic engines trying to control an
> output, whether there is a semiphore lock involved or not.

One purpose that I imagine would be quite feasible would be if the whole machine can be in several modes - eg production mode (fully automatic) and maintenance mode (manual with safety interlocks).

At that point, it might make sense to have completely separate programs for the two modes, and hand control of the machine to one or the other as appropriate. Some of the safety interlocks would probably be shared.

This can be done quite easily with a single semaphore controlling the bulk of the outputs.

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
 
M
Jiri Baum:
> >(I tried using the word "module", but some people took that as "I/O
> >module" rather than the software kind. It can also mean kernel module,
> >so maybe it isn't such a good word anyway.)

That is their problem not yours. A module can be anything, software, hardware, graphic. You can have an LEM or a command module (you wont get to
walk on the moon and get home again if you don't have both).


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
-----Original Message-----
From: Jiri Baum <[email protected]>

>In most applications, each point will be written only by one task, and that
>task must be specified in advance in the config file. That is the normal
>state of affairs that you are describing.
>
>However, in some applications it may be advantageous to allow the write
>right for certain points to pass from one task to another. To enable this,
>the core only needs to be able to associate write access with particular
>end-user semaphores, as well as particular tasks.
>
>In any case, this would be a rarely-used option.
>
Okay! I understand those who need to allow only one task to "control" an output or other point.
But now how can a monitor program make on-line changes to the shared memory when the various tasks "own" them all?

How about granting exclusive write privledge to a point by one task -OR- permitting global write privledge by all tasks. The shared memory could contain a mix of exclusive and global write privledged points.

With the exception of inputs, most PLCs I've worked with allow global write privledges to all memory.

Ron Davis
[email protected]



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

Johan Bengtsson

>>In most applications, each point will be written only by one task, and that
>>task must be specified in advance in the config file. That is the normal
>>state of affairs that you are describing.
>>
>>However, in some applications it may be advantageous to allow the write
>>right for certain points to pass from one task to another. To enable this,
>>the core only needs to be able to associate write access with particular
>>end-user semaphores, as well as particular tasks.
>>
>>In any case, this would be a rarely-used option.
>>
>Okay! I understand those who need to allow only one task to "control" an output or other point.
>But now how can a monitor program make on-line changes to the shared memory when
>the various tasks "own" them all?

The monitor program may own some points in order to change the action of the control program if that is what you are thinking about.

>How about granting exclusive write privledge to a point by one task -OR- permitting global write privledge by all tasks. The shared memory could contain a mix of exclusive and global write privledged points.
>

For most points would more than one writer just mess everything up since the "ordinary" writer will put a new value in at the end of the next "scan" and the "casual" writer:s value will be
lost almost imediately. A write on change method could (theoretically) be used, but then the "ordinary" writer would not attempt to change the point for an uncertan time, it could be a long time or almost imediately. There may be points where this would be useful but quite rarely.

It may be useful, but can, as I see it, be put in the WDTL basket.

What you are thinking of may be the thing discussed as "forces".

>With the exception of inputs, most PLCs I've worked with allow global write privledges to
>all memory.

They allow it, and if you are not doing exaclty what you are thinking you will get yourself quite a mess.


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



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

Darryl L. Palmer

First of all I have to admit that I haven't used KURT that much and I wanted to know if this was correct. With RTL you can have real-time
applications running while "normal" linux programs are. With KURT you mainly have two modes of operation, real-time and normal. When you are in real-time mode all resources are dedicated to executing real-time applications. So does this mean if we go for KURT then it can no longer work as a normal workstation without switching out of real-time mode? Which has the consequence of not being able to use the softPLC computer for other tasks such as a database engine, XServer client, etc.


Darryl Palmer
Cleveland State University

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

Darryl L. Palmer

I am not stating that it is wise to use the softPLC as a program panel. But now with people going crazy for the big "C", Connectivity, does this mean that the softPLC will at some time have to utilize other services like CORBA, OPC (well at least COM since MS released it to the OSF), or even populating a remote database? If these issues came up we should have the opportunity to use available software on the softPLC device. If we select to go with KURT it could have some implications long past version 1.0 of the software.

Darryl Palmer
Cleveland State University

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

Actually right and wrong. RTLinux actually runs Linux as a process and intercepts interrupts.
It only affects normal operations for the duration of the scheduled task, then turns control
back to Linux. This is hard realtime.
KURT, I believe, simply plays with scheduling to run time critical tasks at high priority, but
they are interruptable. This is soft or firm realtime.

In either case the machine switches in and out of realtime mode often enough where the machine is usable for "normal" tasks, it simply goes all out on the realtime tasks for .a tiny interval (in human terms). Since Linux is constantly switching tasks anyway, the disruption is minimal. That is, provided the real time task completes on time. The RTLinux scheme is very close to what Steeplechase does with NT. They have
NT as the least priority task of an iRMX (if I recall correctly) RTOS. That's why they say that even if NT crashes, life goes on, although I don't know how you'd fix it.

Regards,

Curt Wuollet


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Ken Irving:
> Just to toss out a way to look at this, a lot of (file or device) locking
> schemes require cooperation or good-neighborliness, and can be trivially
> (though perhaps dangerously) overruled by a process with high enough
> permissions.

> Enforcing permissions is probably much more difficult than trusting each
> process or logic engine to comply with cooperative locks.

Enforcing permissions is the easy bit.

The hard bit is acquiring and releasing locks, but we can ignore that for now. Refer people to the semop page and pretend that'll do.

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
 
Oops, seems like we started on the same thing at about the same time...

I've got an smm.h file that defines an interface between the SMM and the Logic Engine(s) and also between the SMM and I/O drivers.

Here's the documentation file I've written for it:
----
smm.h
=====

This is the interface used by both the I/O drivers, and the Logic Engines and other modules. To avoid confusion, the two views of the interface are explained separately below. However, they use the same function calls.


Common parts
------------

Each file must be opened with open_plc_file() before use, and it should be closed with close_plc_file() at program termination.

Files are referred to by number. There are several pre-defined files (input, output, coil etc) at numbers 9xx. It is strongly suggested that
these be used for the purposes indicated by their names.

The SMM makes no distinction between types of files. Each file consists of 1024 16-bit unsigned integers, which may be accessed alternately as
individual bits or whole integers.

(Note: this makes each file half an i386-linux page.)

(Should I allow access to it as a flat 2K of memory?)

The SMM will enforce write-exclusion: either static (one module owns a point/subpoint for life) or dynamic (using semaphores). It also deals with inversion and force tables.


Front-end interface
-------------------

The scan-solve loop:
- a full scan is effected by calling refresh() on each file
- the solve logic can use plc_get() to read inputs and coils and plc_set() to write outputs and coils; these work on the module's private copy of the files.

An immediate output / coil-write is achieved by calling plc_set() as normal, followed by refresh_point() or refresh_subpoint().

An immediate input / coil-read is achieved by calling refresh_point() or refresh_subpoint(); the new value will be available via plc_get().


Back-end interface
------------------

Loop independently:
- update with the linuxPLC core by calling refresh() on each file
- use plc_get() to read outputs and plc_set() to write inputs; these work on a private copy of the points.

Depending on the communications discipline, it may be useful to call refresh() more often, or refresh_point() / refresh_subpoint() at
appropriate times.


Real-time considerations
------------------------

The functions open_plc_file and close_plc_file are not real-time.

Only the refresh* and plc_get*/set* functions are intended for real-time use.
----

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
 
Simon Martin:
> >> If a logic engine requests write permission for a point that another registered logic engine alread has write permission for then the request will fail. << <

Jiri Baum:
> >I don't think we should be implementing this - we should make use of semaphores if we need handover of outputs between modules. Semaphores
are the Right Thing for this job. No point re-inventing them.< <

Stan Brown:
> Question, I am thinking of "ownership" of an output being implemented on a per point basis, as opposed to say an I/O scanner or a "rack' basis. Given this wouldn't we have a lot of semaphores to deal with here? <

I'm assuming that each semaphore would be used for many different points. Modules would hand over to each other whole sections of the machine (or the whole machine altogether).

If two modules need to work on the same point at the same time, they should either communicate with each other, or use intermediate coils which are then explicitly ORed or ANDed together.

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
 
I still don't think we are in synch here. I envision ownership of an output being permanent (for the life of the run time). It can only be
changed which the system down. So it should be possible to arbitrarily assign a given output within a card to a given logic engine. Although I
can see that this may not be feasible, and we may need to only allow assignments at the whole module level.

In real PLC's it's done at the entire rack level, BTW.

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

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