Fw: shared memory

My aim, in my logic engine, is to support all 1131 constructs and concepts. That however is way off in the future. And in any case the use of those constructs does not necessarily answer the original question, which was about how the logic engine would solve those constructs once compiled.

I do intend to support these constructs with a native, built in sub-system. In the mean time coding the SFC steps and transitions using the standard instruction set is easy, it is portable (I have personally implemented SFC graphs in AB SLC 5/03, Siemens S5, Omron and Mitsubishi Fx using virtually the same code). The step..end_step construct is NOT compatible with legacy systems.


> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Willy Smith
>
> Why don't you use the IL special constructs for SFC? These include:
>
> STEP...END_STEP
> TRANSITION...END_TRANSITION

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

Johan Bengtsson

Since they aren't. (the underlying principials are different) It is possible to "compile" a SFC program into ladder. It is possible but not any good practice or idea to convert a ladder program to SFC.

The reason a special SFC engine will work faster is that it don't have to evaluate as much as the ladder engine running a "compiled" SFC program.

/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, 25 Jan 2000 [email protected] wrote:

> We don't actually need it, but it will be written since it will execute faster and some people would like that. <

If the underlying principals are the same what would stop this optimised
SFC engine running a normal logic programme?


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Thu, 27 Jan 2000 [email protected] wrote:

> Since they aren't. (the underlying principials are different)
> It is possible to "compile" a SFC program into ladder.
> It is possible but not any good practice or idea to convert a ladder program to SFC.
>
> The reason a special SFC engine will work faster is that it
> don't have to evaluate as much as the ladder engine running a "compiled" SFC program.

Why does the ladder engine have to evaluate all of the programme when the SFC engine does not?
Surely this is simply a short comming on the ladder engine side. It seems to me that you are implying the SFC engine will handle conditional
evaluation / execution. Why is that not possible in a ladder engine?

If I have got this all wrong then please explain the fundamental differance between the two underlying principals. Ie. what is it your SFC
engine can do that the "ladder" engine can not?


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
 
J

Johan Bengtsson

I suppose you looked in the IEC61131-3 standard...

Well, this is just a textual representation of the same thing as can be drawn graphically and don't have anything to do with how it is actually implemented. (Compare this to LD/IL/FBD, it is just different representations of the same thing - implementation is a completely other thing)

LD and SFC is however not the same thing, true enough SFC can be converted or "compiled" into LD, "uncompiling" may however not be that easy.

I suggest leaving the topic for later, it is not a big issue and compiling SFC to ladder is a good first step once SFC is to be implemented, and this project have not really proceded far enough
even for that part yet.


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

Why don't you use the IL special constructs for SFC? These include:

STEP...END_STEP
TRANSITION...END_TRANSITION

Willy Smith

At 06:24 PM 1/26/00 -0000, you wrote:
>It probably would. The specialised bit a step-transition manager. I have a
>few ideas as to how it would work, but I don't really want to get into it
>yet.
>
>In the short term(?), I would code the SFC in ladder or IL.
>

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Dave West asked:
>Why does the ladder engine have to evaluate all of
>the programme when the SFC engine does not?
>Surely this is simply a short comming on the ladder
>engine side. It seems to me that you are implying
>the SFC engine will handle conditional evaluation /
>execution. Why is that not possible in a ladder engine?

First, a distinction must be made between typical IEC-1131 implementations of SFC and pure state languages. My understanding is that many of the
former simply compile SFC down to a least-common-denominator boolean representation -- in such a case there would be no real performance
distinction between SFC and ladder.

HOWEVER, a state engine (designed as such) could achieve significant performance advantages over SFC/LD. The reason is that ladder is a
combinatorial language, in which the output conditions are defined as a function of the input conditions, with no inherent knowledge of statefulness (except insofar as states are created through latches and other supplemental
constructs). Therefore, the entire program must typically be scanned at all times to keep the output conditions updated. This results in cycles being wasted on irrelevant sections of the program.

True state engines, OTOH, only execute that portion of the program relating to the *current* state (or "states", if multitasking is provided for). Think of this as similar to a CASE statement. Only those outputs relevant to the current state are affected, and only those inputs whose information is currently needed are queried. Again, there can be significant
performance gains through the avoidance of unnecessary I/O scanning.

You might guess that this has some fundamental consequences for system design, some of which were pointed out in earlier threads. However, I'm
content with the project proceeding down its current path for the sake of expedience, then looking at how it could be adapted to a state paradigm afterwards.

Ken Crater
[email protected]


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

Johan Bengtsson

A SFC program is made by several steps.
Only a few of these steps are active at the same time. Only the conditions on the transitions following active steps have to be considered, all other can be sorted out.

Properly implemented even the "skip this step - it is inactive" is unnecesary since a list of active steps is the only thing you really have to walk thru.

Even if ladder is implementing a "rung is already false" optimization it will have to check each rung. Each step, active or inactive, gives you one or two rungs depending on how it is coded.


Let's skip this discussion for now, it is too early to implement it anyway. I'll show you all later....


/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 Thu, 27 Jan 2000 [email protected] wrote:

> Since they aren't. (the underlying principials are different)
> It is possible to "compile" a SFC program into ladder.
> It is possible but not any good practice or idea to convert a ladder program to SFC.
>
> The reason a special SFC engine will work faster is that it
> don't have to evaluate as much as the ladder engine running a "compiled" SFC program.

Why does the ladder engine have to evaluate all of the programme when the SFC engine does not?
Surely this is simply a short comming on the ladder engine side. It seems to me that you are implying the SFC engine will handle conditional
evaluation / execution. Why is that not possible in a ladder engine?
If I have got this all wrong then please explain the fundamental
differance between the two underlying principals. Ie. what is it your SFC
engine can do that the "ladder" engine can not?

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Ken, is of course correct. However, the ladder solution can be optimised in the same way that SFC's are done in the PLC5. The logic which controls the state of the machine would have to run constantly, but the logic that represented each step only needs to run when the step is active.

A dedicated engine will come, just not yet.

Think big start small - or to put it another way, achievable short term goals.



> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Ken Crater
>
> Dave West asked:
> >Why does the ladder engine have to evaluate all of
> >the programme when the SFC engine does not?
> >Surely this is simply a short comming on the ladder
> >engine side. It seems to me that you are implying
> >the SFC engine will handle conditional evaluation /
> >execution. Why is that not possible in a ladder engine?
>
> First, a distinction must be made between typical IEC-1131 implementations
> of SFC and pure state languages. ...<clip>


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
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. Presumably the active logic engines will be installed by a clued-in systems integrator,
and it might be sufficient to _warn_ if one process/engine configures an output that is already "owned" by another process/engine.

From this standpoint, it might perhaps be sufficient to include a bit or count of "owners" in each output point, and not have to identify the actual engine. I could imagine some scenarios where a separate process might want to override an output, e.g., for a safety override of some sort, although this would perhaps better be handled in by the logic in a single engine.

I am admittedly behind in keeping up with this list, and can't say I follow the ins and outs of these low level I/O design issues, but offer
these thoughts in the spirit of brainstorming.

--
Ken Irving
Trident Software
[email protected]


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
I'm based in Uttoxeter, Staffordshire. Very close to Alton Towers and JCB actually.
I love the idea of the p*ss... erm ... seminar. I'm up for it but I think we should hold off for a while untill we have some code to discuss.

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 07:10:34AM -0500, Stan Brown wrote:
> On Tue Jan 25 06:00:04 2000 Jiri Baum wrote...

> >One advantage of linuxPLC over commercial systems should be that the
> >engineer can take it home and use it to run his model railway.

> Jiri, are you planing on writing a process/machine simulator?

I'm not sure exactly how this relates to what I wrote, but just in case it does, I'd like to clarify that I meant that the engineer would take it home, wire it up to the cheapest relay I/O available, and write a stepladder/SFC/C program that runs his model railway the same way the
stepladder program at work runs a machine.

The implication being that we shouldn't do anything to prevent the logic engine, the HMI (if any), the programming environment and Netscape or Doom running on the same machine, at the same time.


That said, though, support for a machine simulator is not really a big or separate project. All you do is replace the I/O drivers with another logic engine (see, there *is* a point in having two) and you can run your program
without the real machine there, for debugging or for fun.

(More usefully, you can run your program without the real machine existing at all, running what-if scenarios to assess the effect of various design
decisions on throughput.)


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
 
Mark Hutton:
> Ken, is of course correct. However, the ladder solution can be optimised
> in the same way that SFC's are done in the PLC5. The logic which controls
> the state of the machine would have to run constantly, but the logic that
> represented each step only needs to run when the step is active.

> A dedicated engine will come, just not yet.

Alternatively, a ladder program can be thought of as an SFC with just one state.

BTW, maybe an aggressively-optimizing ladder compiler wouldn't do too badly either - split the program in half on its most-significant pre-condition, then recurse. But you have to do flow analysis first...

(If you want to respond to this last paragraph, please change the subject.)

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 17:58:06 2000 Ken Irving wrote...
>
>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. Presumably the
>active logic engines will be installed by a clued-in systems integrator,
>and it might be sufficient to _warn_ if one process/engine configures an
>output that is already "owned" by another process/engine.

To me, it seems oh so simple for a common set of library routines, that is the shared memory data table access library to simply have the concept of "owner" of each output. This owner would be a small integer representing the logic engine, that was defined in the data table definabtion files. The logic engines would then write to the output data table, using these routines.

>
>>From this standpoint, it might perhaps be sufficient to include a bit or
>count of "owners" in each output point, and not have to identify the
>actual engine. I could imagine some scenarios where a separate process
>might want to override an output, e.g., for a safety override of some
>sort, although this would perhaps better be handled in by the logic in
>a single engine.

You trust the newbie application coders more than I do :) I remember when I "new better than the rest of the world" :)
>
>I am admittedly behind in keeping up with this list, and can't say I
>follow the ins and outs of these low level I/O design issues, but offer
>these thoughts in the spirit of brainstorming.

Brainstorming is how we keep this project moving forward.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Some of this conversation may stem from different perceptions of "logic engine".

If this is meant as a different logic engine for each ladder task (maybe ladder program file is a better term), I could understand an argument for
multiple logic engines having control of an output for such things as (this gives me shivers to think of it happening though) a real output bit being used with OTL (output latch) and OTU (output unlatch) across multiple rungs across
multiple ladder program files.

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.

If logic engine refers to the latter description, I entirely agree with Stan's earlier position of having the shared memory manager refusing to set an output bit if it comes from the wrong logic engine. If another logic engine wanted to change an output that it doesn't control, it should be required to exercise a method of the ladder object of the logic engine that does control the output bit.

Alan Locke
Control Engineer, Boeing

"My opinions are my own and not necessarily those of my employer"

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
My thinking on this was more of the nature of your second case.

I envision e logic engine being the equivalent of a PLC, thus executing all the ladder, and all the subroutines associated with it.

I guess I envision the separate logic engines as being more like separate ControlNet processors, as opposed to multiple logic processors in a PI. The razor to slice this against, is whether the logic engine program is viewed as one entity, by the programming/editing/documentation engine, or not.

That is if you can enter the program and search for occurrences of the output (as you can in a PI with multiple logic processors), then I am happy. If you have to attach to a different "PLC: as you would in a distributed ControlNet system, I'm not.

Sorry about the AB references, but I think you will understand. If anyone doesn't understand what I am saying here, speak up, and I will elaborate.


--
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 18:22:43 2000 Alan Locke wrote...
> >...
> >If logic engine refers to the latter description, I entirely agree with Stan's
> >earlier position of having the shared memory manager refusing to set an output
> >bit if it comes from the wrong logic engine. If another logic engine wanted to
> >change an output that it doesn't control, it should be required to exercise a
> >method of the ladder object of the logic engine that does control the output bit. < <

I have to agree with most of what's been said. I've always felt that each output should only be written by one process, and have dealt with systems where this was not the case :-(, so I would not advocate this being allowed, necessarily.

On the other hand, I'd like to see the different components of the system be as simple and uninformed as they can be, and if the ownership/locking thing doesn't have to be handled by the actual output module, so much the better (if such is feasible ;-).

If a use-count was incremented when an application program (for a logic engine) linked to an output, then another such program could just fail to load/compile if the programmer tried to write the same output in another place. The problem might thus be better handled at a higher
level; at the device driver level the Linux PLC systems programmer (you guys) could just observe a "don't do that" rule. But the application
(ladder, whatever) programmer would simply not be given the option.

--
Ken Irving
Trident Software
[email protected]

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
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").

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

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.

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


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
 
Jiri Baum:
> > > >Individual outputs would be assigned either to a specific logic
> > > >engine, or a specific semaphore.
...

Dave West:
> I am still strugling to understand the rationale here. Surely we only
> need one semaphore for each shared memory area. So we only need one,
> maybe two (Input table and Output table), ok 3 internal data table.

> I fail to see why we would need one for every input or output or
> combination and range thereof.

There would only be one semaphore for the shared memory area. I'm talking about a separate thing, though.

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.

Does that make more sense?

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
 
Jan Krabbenbos:
> How about just an I/O simulator? Could be handy for testing if you don't
> have the I/O available at home. Especially when the Logic Engine has to
> be tested for correct working after someone build it. The I/O simulator
> is nothing else than a (graphic or text) user interface to the shared
> memory. In combination with some special testing PLC programs it could be
> used for checking of the correct functioning of the Logic Engine .

An automatic I/O simulator can be made simply by commenting out all the I/O drivers in the config and substituting a second logic engine.

But having a manual interface to the shared memory would also be very good. (Shouldn't be any problem.)


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
 
That exactly where I (for one) am headed. By defining the logic engine that a given output belongs to (in the I/O config files), then the only application programmer issue, is. (S)he has to declare the "id" of a given logic engine, at declaration time. I envision that there will be
a small config file required for each logic engine, actually probably for each task in the system.

This cofig file would be used by the master scheduler task to start up the appropriate processes. The scheduler may also need to watch over these process at run time, to proved an appropriate response if one of them stops running unexpectedly, and perhaps even if it runs overtime.


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

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