Fw: shared memory

On Sat, 22 Jan 2000, Stan Brown wrote:

> On Sat Jan 22 06:21:08 2000 Dave West wrote...
> >
> >I don't see how this differs from any othe pure logic form (eg. ladder),
> >it's just a bunch of "if then else" statements or contact---contact---coil. Just a prettier way of displaying same.
> >
> >I will therefore assume a massive over simplification in your explanation
> >as you seem very strongly convinced that it will be better run by a special engine.
> >
> It helps to know how this is implemented. In an AB controller, each of
> those boxes is a program file, in addition to what he showed, there are
> transition steps. AS a result only a few of the total number of program
> files are being executed at any one time, instead of scanning all of
> them. You can achieve the same thing without SFC, but properly
> structuring your program.

OK, now I'm realy intrigued. Where can I get a book on this SFC stuff.


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

Exactly, but some of the people having class 3 machines as you call them will prefere the second method.

There are, besides that, other things than machines producing things controlled by PLC:s. For example traffic lights and elevators. Some of these belong to class 3 or even class 4.

/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]]
>
>Actually I don't. It would not really be needed to be able to run compiled C code.
>
>If I can write a program in C interpreting a logic byte code
>I can write a program in C doing the logic directly.
>The main differences (from my point of view) it that the
>former will be a lot easier to change online and the latter
>being somewhat faster. Changing the logic in the second way
>can be done by stopping the control application, recompile
>and start it again, this will not suit everybody but some
>people may use it because of the little additional extra
>speed. The door is open!
>
>I would prefere the first solution myself, but I am not the
>entire (or even a major part) of the target for this project.

Stopping the execution of a PLC in many applications is totally unacceptable. There are basically 3 classes of PLC application from this
point of view: ...<clip>

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

Johan Bengtsson

Ok, that is the fast solution then, in a mitsubishi PLC (at least the smaller ones) it is not done like this.


/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 Sat Jan 22 06:21:08 2000 Dave West wrote...
>
>I don't see how this differs from any othe pure logic form (eg. ladder),
>it's just a bunch of "if then else" statements or
>contact---contact---coil. Just a prettier way of displaying same.
>
>I will therefore assume a massive over simplification in your explanation
>as you seem very strongly convinced that it will be better run by a special engine.
>

It helps to know how this is implemented. In an AB controller, each of those boxes is a program file, in addition to what he showed, there are transition steps. AS a result only a few of the total number of program files are being executed at any one time, instead of scanning all of them. You can achieve the same thing without SFC, but properly structuring your program.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sat Jan 22 09:27:44 2000 Jiri Baum wrote...
>
> - the data segment shouldn't be executable, but I have a suspicion
> that it is (judging by comments in src/linux/mm/mmap.c)
> - shared libraries can be loaded on-demand (or we can call mmap
> ourselves)
> - full blown executable, as you write
>
>But you are right that this is a serious problem. On-line changes of
>compiled programs are decidedly non-trivial (unless you go for the simple
>"kill it at the end of a scan and let the new one rip").
>
>However, it may be acceptable as a trade-off: either you get on-line
>changes, or the efficiency of machine-native compilation, but not both.
>(But that would mean implementing both.)

On line changes are a basic requirement of a PLC.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sat Jan 22 17:36:59 2000 wrote...
>
>Exactly, but some of the people having class 3 machines
>as you call them will prefere the second method.
>
>There are, besides that, other things than machines producing
>things controlled by PLC:s. For example traffic lights and
>elevators. Some of these belong to class 3 or even class 4.
>

Those controlers fall into other classes IMHO. Dedicated special purpose, building automation, etc.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sat Jan 22 10:40:25 2000 Dave West wrote...
>
>OK, now I'm realy intrigued. Where can I get a book on this SFC stuff.<

Look at an AB PLC5 programming manual.

BTW, this stuff really does not apply very well to most systems that I am aware of. I have looked at it for several jobs, and ultimately found a show stopper on every one.

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

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

Johan Bengtsson

Do you have access to the IEC(6)1131-3 standard?
(it is not a teaching book but everything is outlined there) I do not have any better example written in english.

I can come and teach you :) (that is what I do for living)

You see most of the general idea in my (simplified) example before.

The program is divided into:
One or more sequenses

Each sequence is divided into a number of steps and between each step is a condition called transition.

A step is active until the following transition is true. To each step is a number of actions (possibly 0) connected, these actions are performed while the step is active. In its simplest for is an action an output to be set during that step. (If more than one step have a particular output as an action (quite common) they are ored together).

The flow can be divided into:
- mutually exclusive alternate branches
- parallel executed branches

It is possible to make alternate branches backwards.

At the end of the sequence it is restarted from the beginning.


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

<clip>
OK, now I'm realy intrigued. Where can I get a book on this SFC stuff.

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

Johan Bengtsson

Every step is assigned a memory (or if you call it flag or internal coil or whatever).

Consider this part of a sequence (somewhat simplified):

|
+-----+
| %M0 |
+-----+
|
+ %I0
|
+-----+
| %M1 |
+-----+
|
+ %I1
|
+-----+
| %M2 |
+-----+
|



The step in the middle (%M1) above will be coded something basically like this (variants exist):

| |
| %M0 %I0 %M2 %M1 |
+--[ ]----[ ]---+---[/]------( )---+
| | |
| %M1 | |
+--[ ]----------+ |
| |

Function:
If previous step is active (%M0) and the transition expression is true: activate the step (%M1). The step is self-holding until the next step is activated. Usually this is coded backwards to prevent two steps from being active at the same scan.

This is repeated for each step with slight variations depending on if it is the first/last step or there is branches and so on.

At the end there is a lot of OR statements combining the actions (not shown here) for each step to the correct output.


/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 Sat Jan 22 17:47:50 2000 wrote...
>
>Ok, that is the fast solution then, in a mitsubishi PLC (at least the smaller ones) it is not done like this.<

Out of curiosity, how is it done there?

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

Johan Bengtsson

You are absolutely right. Used for some systems SFC is just great, but most systems will definitely NOT benefit from this. It heavily
depends on how the machine is working.

A traffic light is an example of something more easily programmed in SFC. An elevator is definitely more easily programmed without.


/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
 
On Sat Jan 22 20:35:56 2000 wrote...
>
>The step in the middle (%M1) above will be coded something basically
>like this (variants exist):
>
>| |
>| %M0 %I0 %M2 %M1 |
>+--[ ]----[ ]---+---[/]------( )---+
>| | |
>| %M1 | |
>+--[ ]----------+ |
>| |
>
>Function:
>If previous step is active (%M0) and the transition
>expression is true: activate the step (%M1).
>The step is self-holding until the next step is activated.
>Usually this is coded backwards to prevent two steps from being active at the same scan.
>
>This is repeated for each step with slight variations depending
>on if it is the first/last step or there is branches and so on.
>
>At the end there is a lot of OR statements combining the actions
>(not shown here) for each step to the correct output.

OK so it does resolve to ladder, when all is said and done. This is like AB. However this scheme does not break it into multiple files
(subroutines). It just depends on the "first prove the rung false" optimization which I mentioned in another thread.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sat, Jan 22, 2000 at 09:47:22AM +0000, Dave West wrote:
> Something we all seem to have missed about compiling to native machine
> language is it is non portable.

I don't think that's a big concern in this context; there will be so many other reasons why a given program is non-portable that being compiled will be the least of them.

After all, you can always recompile.

> The programming tool needs to know what kind of processor the PLC is
> running on and therefore should be disregarded entirely.

So? It also needs to know what kind of machine it'll be running, which is likely to be a bigger bar to portability than being compiled for a
particular processor.


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 Fri, Jan 21, 2000 at 03:11:37PM +0000, Dave West wrote:
> On Fri, 21 Jan 2000, Jiri Baum wrote:
...
> > [*] Yes, HMI will probably blow out the scan times. But the linuxPLC
> > core can also serve as a linuxHMI core - you just don't give it any
> > critical tasks and load the HMI thing.

> What has the HMI got to do with the logic engine aprt from querying it
> for data from time to time?

Well, I was thinking that if you want a HMI, you just rip out the logic engine and substitute a pretty screen. Observe:

> Scheduler, a programme that sequences the execution of tasks (we could call it PLCsched).<

You'll need that too.

> Input scanner, a programme to scan the physical input devices and make a
> copy in a data table (say PLCIscan).

You'll need that too.

> Logic engine, a programme to scan the machine logic (say PLCengine).<

That's the bit you don't need.

> Output scanner, a programme to take an output data table and pass the
> values on to real output drivers (say PLCOscan).

You'll need that too (it'll be setting internal flags in the PLC rather than real outputs, but the principle is the same).

> Communication handler, a programme to handle requests for data from other
> programmes EG. HMI or monitor programme or logic compiler (say PLCcomm).

You may need that too.

As you can see, once the linuxPLC exists, you have a lot of code that can be re-used for a linuxHMI, most of it without any change.

The other advantage of having the HMI module run against the same core is that gives the implementor the choice of running the HMI on the same box or a different one.


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 Sat, Jan 22, 2000 at 11:38:22AM -0500, Stan Brown wrote:
> On Sat Jan 22 09:27:44 2000 Jiri Baum wrote...

> >However, it may be acceptable as a trade-off: either you get on-line
> >changes, or the efficiency of machine-native compilation, but not both.
> >(But that would mean implementing both.)

> On line changes are a basic requirement of a PLC.

I said it's a *trade-off*.

However, if you insist on having both on-line changes *and* the efficiency of machine-native compilation, I suggest you go write it.

Really.

I mean it - it would be a wonderful feature, and it would be useful widely beyond the PLC world.


Happy hacking!

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 Sat, Jan 22, 2000 at 09:10:40AM -0500, Stan Brown wrote:
> On Sat Jan 22 15:04:28 2000 wrote...
...
> >Changing the logic in the second way can be done by stopping the control
> >application, recompile and start it again, this will not suit everybody
> >but some people may use it because of the little additional extra speed.
> >The door is open!

> >I would prefere the first solution myself, but I am not the entire (or
> >even a major part) of the target for this project.

> Stopping the execution of a PLC in many applications is totally
> unacceptable.

Perhaps - don't forget that this stoppage would be in the sub-second range. With a little care, it can be reduced even further.

(Basically, this would involve having the new version do its loading and initialization at low priority, and blocking when it is completely ready to run. Then, at the end of a scan, you promote the new version, demote the old one to low priority, switch over all the map access rights and run on.)

However, all this applies to stepladder-style programming. Anything with program flow (state language, subroutines) can't be handed over like this, and gets a lot more complicated very quickly.


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 Fri, Jan 21, 2000 at 08:57:37AM -0500, Stan Brown wrote:
> On Thu Jan 20 18:50:15 2000 Jiri Baum wrote...

> >Individual outputs would be assigned either to a specific logic engine,
> >or a specific semaphore.

> >A given semaphore can protect any number of outputs.


> Any thoughts on the issue of number of semaphores that are reasonable? <

No idea.

I was thinking of sub-dozen, with each protecting a whole chunk of the machine.

> I have a Factory Link application with about 50K, come to think of
> it. Never mind, should not be a problem.

Probably the limiting factor won't be the possible number of semaphores but the time-cost of combining their map permissions at each scan.

(If the OS can't give us enough semaphores, we can always implement our own using one OS semaphore. But I'd rather not.)


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 23 09:50:21 2000 Jiri Baum wrote...
>
>On Sat, Jan 22, 2000 at 09:10:40AM -0500, Stan Brown wrote:
>> On Sat Jan 22 15:04:28 2000 wrote...
>...
>> >Changing the logic in the second way can be done by stopping the control
>> >application, recompile and start it again, this will not suit everybody
>> >but some people may use it because of the little additional extra speed.
>> >The door is open!
>
>> >I would prefere the first solution myself, but I am not the entire (or
>> >even a major part) of the target for this project.
>
>> Stopping the execution of a PLC in many applications is totally unacceptable.
>
>Perhaps - don't forget that this stoppage would be in the sub-second range. With a little care, it can be reduced even further.<

I can live with this kind of delay. As a mater of fact it may be inherent in doing this at all.

However, that is not what I read into this suggestion. I read the idea of shutting down, getting a cup of coffee, waiting for the compile, inserting and starting back up.


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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sun Jan 23 09:26:38 2000 Jiri Baum wrote...
>
>On Sat, Jan 22, 2000 at 11:38:22AM -0500, Stan Brown wrote:
>> On Sat Jan 22 09:27:44 2000 Jiri Baum wrote...
>
>> >However, it may be acceptable as a trade-off: either you get on-line
>> >changes, or the efficiency of machine-native compilation, but not both.
>> >(But that would mean implementing both.)
>
>> On line changes are a basic requirement of a PLC.
>
>I said it's a *trade-off*.
>
>However, if you insist on having both on-line changes *and* the efficiency of machine-native compilation, I suggest you go write it. >
>Really.<

Jiri, the existing hardware based PLC's have this. That is our target market, right?

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


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

Scott Cornwall

> > >However, it may be acceptable as a trade-off: either you get on-line changes, or the efficiency of machine-native compilation, but not both.
> > >(But that would mean implementing both.)
>
> > On line changes are a basic requirement of a PLC.

Online changes are a basic requirement, and some PLCs use machine-native compilation. The two features are not mutually exclusive.

Scott Cornwall
www.psc.fp.co.nz


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
I believe the point is that every PLC that I know runs either complied or interpreted tokens. I do not know of any PLC that 'runs' ladder logic. Yet
still _MOST_ allow online editing and monitoring.

This is as much to do with the programming software as the PLC.



-----Original Message-----
From: [email protected] [mailto:[email protected]]On
Behalf Of Stan Brown

On Fri Jan 21 10:31:58 2000 Dave West wrote...
>
>On Fri, 21 Jan 2000, Ron Davis wrote:
>
>> To me, one main feature of PLCs that separate them from other computer-based systems is their ability to support "on-line programming." Support for this feature needs to be considered at this early stage in the design. Talk of
>> "compiled" code worries me that this is not being considered.
>
>You've got me here Ron. Why does "compiled" code make you believe that
>on-line programming will not be possible. If you are talking about code
>compiled to x86 machine language that is executed directly by the CPU then
>I can see your concerns, however, it is still not impossible, your linux
>or Windoze box does it every day. If you are talking about code compiled
>to run on our virtual machine (the logic engine) then how do you see there
>being any dificulty after all a real PLC does it.

I don't know about Ron, but I for one would be willing to accept any technology that accomplished what he is asking for.

I do agree with him that this is basic non negotiable functionality, even in version 1.0

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