Fw: shared memory

M
The SFC/Grafcet is less a programming language and more a means of specifying sequences of operations. It is IMHO, beneficial as a means to
understanding ALL sequential processing (as in machine control), and is also useful in continuous control, particularly in batching (SP88), but also in higher level specification.

SFCs, to my mind can be translated to ladder (and hence to IL) and in fact many PLCs (TSX7, Omron, Mitsubishi) have special LAD or IL instructions to
allow implementation (I don't use these special instructions). For the future, a specific SFC engine could easily be written. This engine need only consist of two lists of tasks, steps and transitions, anda 'scheduler' or switcher.

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

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.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Mon Jan 24 04:12:43 2000 Mark Hutton wrote...
>
>The SFC/Grafcet is less a programming language and more a means of
>specifying sequences of operations. It is IMHO, beneficial as a means to
>understanding ALL sequential processing (as in machine control), and is also
>useful in continuous control, particularly in batching (SP88), but also in
>higher level specification.
>
>SFCs, to my mind can be translated to ladder (and hence to IL) and in fact
>many PLCs (TSX7, Omron, Mitsubishi) have special LAD or IL instructions to
>allow implementation (I don't use these special instructions). For the
>future, a specific SFC engine could easily be written. This engine need only
>consist of two lists of tasks, steps and transitions, anda 'scheduler' or
>switcher.
>

An excellent analysis. The underlying code for SFC's in AB is also ladder.

I like your plan for this.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Mon Jan 24 03:25:25 2000 Mark Hutton wrote...
>
>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.
>

I think we have a terminology difference here, and that's all. I contend that AB controllers execute the code as written, For example -||- is stored as an opcode, with the data table address it references encoded
in it. As a matter of fact it can be one of (at least) 2 opcodes, based upon high high in memory the referenced data table point is ( the lower
ones are more compact, taking less storage, and executing faster).
Still it must visit every instruction as it scans. In some cases, if it has already proven the rung false, then it is merely checking to see if the instruction is an output, or output start branch, or end of rung marker.

I believe that we can be a little more efficient than this by storing the locations of output start branches, outputs that must be
manipulated even if the rung is false (eg -()- ) and end of rungs.

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

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

This is my preferred, PLC independant method of implementing SFC's.

The problem here is that you have two mutually exclusive steps active at the
same time %M1 and %M2.

This is what I do.
|
| Step1 Trans1 Step1
+------] [---+-----] [----------+------(R)---
| |
| | Step 2
| +------(S)---
|
| Step1 (trans conditions) Trans1
+------] [-------. . -] [----] [. . .------( )--
|
|

Of course, this can be implemented in a number of ways, but you get the
picture.

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

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

..<clip>


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Jiri Baum wrote:
>
>(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,

Why should this be hard with state logic? Just maintain the current state (or step) during the changeover and then pick back up.

I do see where languages that hold in a loop or wait in a subroutine can get impossibly complicated switching over on the fly.

Ron Davis
[email protected]



_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Mon, 24 Jan 2000, Jiri Baum wrote:

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


I think I see your point here.
I thought you were refering to the PLC controlling the plant and that the HMI would slow it right down. But what you actually mean is we take great chuncks of the PLC code and use it to write a seperate HMI. This seperate HMI will process I/O at a slower rate. Yes?


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 Mon, 24 Jan 2000, Jiri Baum wrote:

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

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.

In another post I gave reasoning for this but I will repeat it here for clarity.

Any single I/O point should be described to one and only one PLC core/engine. If more than one core runs on a computer they should have
seperate and unique configurations. In this manner no two cores can access the same I/O point directly and all problems go away.
If an aplication calls for more than one core to affect the state of an output or more than one core requires knowledge of an input then the
application designer/engineer/programmer should pass this information around by wiring or logic in the application programme via a communication
medium be it a software driver, physical cable or other.

I have as of yet seen no sound reasoning why more than one core should be able to access the same physical I/O but I have seen many good reasons to
forbid it entirely.


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

Do they Stan? I've never heard of it but then a PLC running native compiled machine language is not something I'd wan't to do because non of
my staff would be able to understand it even if they had the source in BASIC. Ladder is about there lot and thats pushing it for some.


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 Mon Jan 24 09:58:05 2000 Dave West wrote...
>
>Do they Stan? I've never heard of it but then a PLC running native
>compiled machine language is not something I'd wan't to do because non of
>my staff would be able to understand it even if they had the source in
>BASIC. Ladder is about there lot and thats pushing it for some.
>

This is turning into a terminology issue. The AB PLC's execute the ladder instructions as a series of opcodes. Embedded in these opcodes are the data table references. See my earlier post on this.

These opcodes are native machine code for an AISC. Often in early processor releases, there are problems with the ASIC, and some subset of these opcodes will be processed as microcode by an onboard microprocessor. These particular instructions will then be an order of magnitude slower than the ones executed by the ASIC.

Does this make it clear?

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Mon Jan 24 09:55:05 2000 Dave West wrote...
>
>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.
>
>In another post I gave reasoning for this but I will repeat it here for clarity.
>
>Any single I/O point should be described to one and only one PLC
>core/engine. If more than one core runs on a computer they should have
>seperate and unique configurations. In this manner no two cores can access
>the same I/O point directly and all problems go away.
>If an aplication calls for more than one core to affect the state of an
>output or more than one core requires knowledge of an input then the
>application designer/engineer/programmer should pass this information
>around by wiring or logic in the application programme via a communication
>medium be it a software driver, physical cable or other.
>
>I have as of yet seen no sound reasoning why more than one core should be
>able to access the same physical I/O but I have seen many good reasons to
>forbid it entirely.
>

Well, we could choose to limit our project in this way, but I would prefer not to,

Let me give you a real world analogy. AB ControlNet processors can share a ControlNet network, such that all the I/O on that network is
visible to each independent processor. All can examine inputs, and _examine_ outputs. As far as controlling outputs, outputs must be declared to be "owned" by a processor at network cnfiguration time.

AB's granularity is, I believe, at the entire rack level.

I think that it makes sense for us to have multiple logic engines, where required. They might, for instance run different application
languages.

Another, albeit somewhat more tightly coupled example, is multiple logic processors in a PI, and I believe ControLogix racks can have
multiple logic processors, also.

Do you see where I am coming from now?



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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Mon Jan 24 09:40:10 2000 Ron Davis wrote...
>
>Jiri Baum wrote:
>>
>>(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,
>
>Why should this be hard with state logic? Just maintain the current state
>(or step) during the changeover
>and then pick back up.
>
>I do see where languages that hold in a loop or wait in a subroutine can get
>impossibly complicated
>switching over on the fly.

It's really a question of how long you can freeze the state of the outputs during this transition. Existing controllers do this in the sub millisecond range. Then there is the question of how you get the outputs turned off, if this swap over fails.

It's pretty non-trivial.

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

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

Jan Krabbenbos

> >
> > Jiri, the existing hardware based PLC's have this. That is our target
> > market, right?
>
> Do they Stan? I've never heard of it but then a PLC running native
> compiled machine language is not something I'd wan't to do because non of
> my staff would be able to understand it even if they had the source in
> BASIC. Ladder is about there lot and thats pushing it for some.

For what I know: some PLCs use native code (mostly for performance reasons). But for the engineer maintaining the program or writing and
testing a program: he still sees the ladder or the other language he's creating his program in. The Siemens PLC S7 uses this approach. Parts of
or the whole program written in ladder, instruction list or whatever is compiled to native machine code, and afterwards it is transferred to the PLC.

Greetings,
Jan


Jan Krabbenbos
e-mail: [email protected]
www : http://www.krabbenbos.com

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

Jan Krabbenbos

Stan Brown wrote:
>
> On Mon Jan 24 09:58:05 2000 Dave West wrote...
> >
> >Do they Stan? I've never heard of it but then a PLC running native
> >compiled machine language is not something I'd wan't to do because non of
> >my staff would be able to understand it even if they had the source in
> >BASIC. Ladder is about there lot and thats pushing it for some.
>
> This is turning into a terminology issue. The AB PLC's execute the
> ladder instructions as a series of opcodes. Embedded in these opcodes
> are the data table references. See my earlier post on this.

Siemens S5 PLCs do use opcode and operand codes. There are booklets where they give the instructions and the necessary parameters and at the end the opcodes are printed. If you know how, you can change the opcode in physical memory! Siemens and also other companies have used this method to make code 'invisible' for the common user, to create vendor library functions.

> These opcodes are native machine code for an AISC. Often in early
> processor releases, there are problems with the ASIC, and some
> subset of these opcodes will be processed as microcode by an
> onboard microprocessor. These particular instructions will then be
> an order of magnitude slower than the ones executed by the ASIC.
>
> Does this make it clear?
--
Greetings,
Jan

/\ Jan Krabbenbos
e-mail: [email protected] www : http://www.krabbenbos.com

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

> There is another point about this, both ways will probably
> be supported eventually.
> Online changes will be needed by some users, but not everybody.
> I think it would be a lot easier to support that with a byte
> coded "sub-language" and a fast interpreter for the byte code
> than compiled C. Compiled C will of course be faster on the other hand.

Using an intermediate language or p-code also allow mixed mode programming, ladder with function blocks, without much trouble

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Mon Jan 24 15:28:23 2000 Jan Krabbenbos wrote...
>
>Siemens S5 PLCs do use opcode and operand codes. There are booklets
>where they give the instructions and the necessary parameters and at the
>end the opcodes are printed.
>If you know how, you can change the opcode in physical memory! Siemens
>and also other companies have used this method to make code 'invisible'
>for the common user, to create vendor library functions.

In the olden days of AB PLC-3's (Hey we still have some), you could do this also, used to be a standard demo trick, to change a coil from N. O to N. C from teh front panel keypad, using extended addressing, while the customer watched it happen on teh programing terminal (no programing software in those days.

But I digress.


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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Mon, Jan 24, 2000 at 09:40:10AM -0500, Ron Davis wrote:
> Jiri Baum wrote:

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

> Why should this be hard with state logic? Just maintain the current state
> (or step) during the changeover and then pick back up.

> I do see where languages that hold in a loop or wait in a subroutine can
> get impossibly complicated switching over on the fly.

That's what I meant.

With a state language, you have to make provision for handing the state over (easy if it's in the data table, I suppose, but you still have to make
provision for it). The more state information there is, and the more complicated it is, the harder it is to hand over. Especially if eg some
subroutines no longer exist in the new version.


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, 24 Jan 2000, Stan Brown wrote:

> On Mon Jan 24 09:58:05 2000 Dave West wrote...
> >
> >Do they Stan? I've never heard of it but then a PLC running native
> >compiled machine language is not something I'd wan't to do because non of
> >my staff would be able to understand it even if they had the source in
> >BASIC. Ladder is about there lot and thats pushing it for some.
>
> This is turning into a terminology issue. The AB PLC's execute the
> ladder instructions as a series of opcodes. Embedded in these opcodes
> are the data table references. See my earlier post on this.
>
> These opcodes are native machine code for an AISC. Often in early
> processor releases, there are problems with the ASIC, and some
> subset of these opcodes will be processed as microcode by an
> onboard microprocessor. These particular instructions will then be
> an order of magnitude slower than the ones executed by the ASIC.
>
> Does this make it clear?

Now I see what your saying and I didn't know that. I assumed they all had a CPU that ran a token interpretter (basically emulating the ASIC you mentioned). I learn something new every day.


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 Mon, 24 Jan 2000, Stan Brown wrote:

> On Mon Jan 24 09:55:05 2000 Dave West wrote...
> >
> >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.
> >
> >In another post I gave reasoning for this but I will repeat it here for clarity.
> >
> >Any single I/O point should be described to one and only one PLC
> >core/engine. If more than one core runs on a computer they should have
> >seperate and unique configurations. In this manner no two cores can access
> >the same I/O point directly and all problems go away.
> >If an aplication calls for more than one core to affect the state of an
> >output or more than one core requires knowledge of an input then the
> >application designer/engineer/programmer should pass this information
> >around by wiring or logic in the application programme via a communication
> >medium be it a software driver, physical cable or other.
> >
> >I have as of yet seen no sound reasoning why more than one core should be
> >able to access the same physical I/O but I have seen many good reasons to
> >forbid it entirely.
>
> Well, we could choose to limit our project in this way, but I would prefer not to,
>
> Let me give you a real world analogy. AB ControlNet processors can share
> a ControlNet network, such that all the I/O on that network is
> visible to each independent processor. All can examine inputs, and
> _examine_ outputs. As far as controlling outputs, outputs must be
> declared to be "owned" by a processor at network configuration time.

OK, I can live with this. It saves on application programme "steps" and is not unreasonable.
As you say an output must be declared as "owned" well surely that could be implicit by the fact that no other logic core has the output device
control register described in it's config file thus the one that does have it owns it. No need for messy ownership flags.

> AB's granularity is, I believe, at the entire rack level.
>
> I think that it makes sense for us to have multiple logic engines,
> where required. They might, for instance run different application languages.

I'm not going in to that languages thing again (yet).

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

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

Anybody know where to get this in the UK or from the net?

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

Hmmmmm, now I am beggining to realise why you think it would be better with a seperate logic engine. It may be or it may not? Hmm.
I need to get the full story on this from the standard and give it some thought.


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 Mon, 24 Jan 2000, Stan Brown wrote:

> On Mon Jan 24 04:12:43 2000 Mark Hutton wrote...
> >
> >The SFC/Grafcet is less a programming language and more a means of
> >specifying sequences of operations. It is IMHO, beneficial as a means to
> >understanding ALL sequential processing (as in machine control), and is also
> >useful in continuous control, particularly in batching (SP88), but also in
> >higher level specification.
> >
> >SFCs, to my mind can be translated to ladder (and hence to IL) and in fact
> >many PLCs (TSX7, Omron, Mitsubishi) have special LAD or IL instructions to
> >allow implementation (I don't use these special instructions). For the
> >future, a specific SFC engine could easily be written. This engine need only
> >consist of two lists of tasks, steps and transitions, anda 'scheduler' or
> >switcher.

> An excellent analasys. The underlying code for SFC's in AB is alos ladder.
>
> I like your plan for this.

So, we certainly do not need a special engine for it then?


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
 
Top