Fw: shared memory

On Mon, Jan 24, 2000 at 02:42:23PM +0000, Dave West wrote:
> On Mon, 24 Jan 2000, Jiri Baum wrote:
...
> > 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.
...
> 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?

In a plant-control situation, yes.

However, it should be written so that it can run on the same computer, sharing the I/O drivers etc. Basically, make it interface to the same
shared memory manager.

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
--
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 Tue Jan 25 04:56:57 2000 Dave West wrote...
>
>> 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? <

Hard to sat at this early point. Perhaps this could be handled by a translator front end in the programing/editing/documentation package.
Perhaps it would be best handled by a specila version of the logic engine.

Can anyone that has actually deployed SFC based application code comment on this?

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


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

> On Mon, Jan 24, 2000 at 02:42:23PM +0000, Dave West wrote:
> > On Mon, 24 Jan 2000, Jiri Baum wrote:
> ...
> > > 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.
> ...
> > 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?
>
> In a plant-control situation, yes.
> However, it should be written so that it can run on the same computer,
> sharing the I/O drivers etc. Basically, make it interface to the same shared memory manager.
>
> One advantage of linuxPLC over commercial systems should be that the
> engineer can take it home and use it to run his model railway.

I agree with everything 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
 
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? Lets please try to get the PLC side of this project to at least a demo
stage, before we go to far afield with HMI's and simulators. These 2 are really full blown projects in themselves.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
I have already posted you a reply on the list.

The standard is available from British Standards (for a price).

The best resources are at http://www.plcopen.org amongst others.

Somebody on the list mentioned that the Allen Bradley site (www.ab.com) also had some info (they gave a url).

Where are you based? May be I could loan you my copy, or give you a quick tutorial.

I was thinking that may be the UK based list members might get together for a 'technical info exchange' or seminar (p*ss up). Any takers?

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

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>


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sun Jan 16 10:11:30 2000 Simon Martin wrote...
>
>Ok gentleman, this is what I see as the basics for my assumed task.
>
>1) SharedMemoryManager
>
>This process creates the SharedMemory space. The memory space is allocated
>taking into account all the memory specified by the VirtualIO configuration
>files. I can ignore the PhysicalIO configuration files as these must be
>mapped into the VirtualIO map for them to be used, providing independance of
>the PLC Engines from the IO configuration itself.

I think this is exactly what I have been saying. Sounds right.

>The SharedMemoryManager is responsible for data persistence. All registers
>in the VirtualIO map must have a persistance priority assigned to them
>(something like critical, important, normal) allowing flexibility in the
>volume of data to be written.

I was thinking this might be a separate task, but I like where you are
headed with this. Let's do it.
>
>2) VirtualIO configuration
>
>The VirtualIO are the IO points available to the PLC Engines. At the start
>of a scan the PLC Engine will request a copy of the Input data, at the end
>of a scan the PLC Engine will submit it's output data. The
>SharedMemoryManager is responsible for extracting/merging this data.

Why does the shared memory manager task need to do this? I envision the logic engines, having access to this shared memory, protected by a semaphore lock. Think about it this way, other pieces of the puzzle, such as timer execution processes, counter execution processes, PID execution processes, need access to this same data table space. It may eventually become a point of contention (bottle-necking). So why not
have the tasks that need it access it directly, again protected as necessary by a semaphore lock.

Now I think we should have library routines to do this, so that the writers of the processes (modules) don;t have to reinvent the wheel, and use this critical shared resource in a consistent way.

>The VirtualIO would be defined by something like
>
><io type> <element> . <sub element> <tag> <description>
>
>A PLC Engine may request the current value of a single IO point, or a set of
>IO points, or the next updated value of an IO point/set of IO points.

The tag. description information goes into the documentation database. The reasons for this will be clear, when we start talking about the programming/editing/documentation engines. Trust me please on this, I have been involved with the writing of several f these, and it's a whole other subject, may even require that we adopt a database, such as Postgess.

>Questions:
>
>Can each PLC Engine have its' own VirtualIO table that maps onto the global
>IO table?

I don't see reason for this, do you.

>What is the harm of more one process updating an output (apart from the
>programmers sanity)?

If you are talking non I/O data table, it's OK, of bad practice. If you are talking real Outputs, it's just basically unacceptable. Do we need to have a vote on this> It seems to be the only point we are not close toa agreement on.

Sounds like we are close to writing real code ere!

--
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 10:40:56 2000 Phil Covington wrote...
>
>As I see it, coding the Logic Engines is going to be the most difficult
>part. Without a logic engine this project isn't much more that what has
>already been done with projects like NIST's EMC, NASA's Airborne Laser
>System, or the Triton ETD Project to name a few. There many examples of
>driver code and how to use shared memory to draw from. The graphical
>display of Ladder Logic will be a challenge in itself.
>

Sounds good.

The ladder display code, is actually pretty trivial. Just uses ASCII characters, and a simple curses program.

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


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
I shall start with what I've got. At the moment I'm in the administration phase, setting up CVS to point to the main repository, etc. I hope to start work on the code tomorrow (I have already looked up a few things to set the ball rolling and have a fairly good idea on what's going to happen).

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

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.

Debian GNU User
Simon Martin
Project Manager
Isys
mailto: [email protected]

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
R
Many years ago I worked for a company that had its own PLC. It was programmed ladder style but used mnemonics instead of RLL for programming. I
was assigned the task of attempting to create a RLL translator from the mnemonics so a RLL printoiut could be made. i managed to get it to work pretty well, but ran out of memory in the Kaypro II we were using at the time and could never make it wrok completely. The task was abandoned soon thereafter. I don't recall exactly why.

:)

Some things were just never meant to be.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
>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. 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 still don't think we see eye to eye on this. As I see it the "owner" logic engine for a given output is defined in the data table
configuration files. Given that the shared memory manager, should simply refuse to set an output bit (real I/O again) if the request comes from the wrong logic engine.

The reason that I feel this way is, this limitation only applies to real outputs. The config files will be where this information is
stored. The logic engines should not be burdened with the overhead you are imposing. A given logic engine should be able to read any data table location it desires.

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

Again, I am not certain I like burdening the logic engine(s) this way.


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

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

Johan Bengtsson

I am not really sure you have the efficiency of pure machine code in a PLC. Some kind of interpreter (from some kind of byte code) is what I would guess. It will be fast enough for absolutely the most people, the people not happy with the speed of the interperter will be easily counted. (You won't need a 32 bit counter for that :) )


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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Great, Simon!

We'll all be tuned in better with something to actually look at. Since I am actually writing code for a driver at this time, and I haven't achieved a complete meeting of the minds, please let me know ASAP what I should be coding to. I had a clear idea at one time, but, you guys have gone well beyond that while I had my head down. That kind of thing is best designed by one and refined by many. I can keep going in parallel for a while.

Curt Wuollet.

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

Johan Bengtsson

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


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

> On Mon Jan 24 04:12:43 2000 Mark Hutton wrote...
<clip>...
> >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?



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

Johan Bengtsson

It is easy enough to convert it to ladder but I think it would be even easier to make a special logic engine for it, and it would be faster. No need to rush on this however and both ways will surely be supported evntually

/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 Jan 25 04:56:57 2000 Dave West wrote...
>
>> 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?
>

Hard to sat at this early point. Perhaps this could behadled by a translator front end in the programing/editing/documentation package.
Perhaps it would be best handled by a specila version of the logic engine.

Can anyone that has actually deployed SFC based application code comment on this?


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

Jan Krabbenbos

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? Lets
> please try to get the PLC side of this project to at least a demo
> stage, before we go to far afield with HMI's and simulators. These 2
> are really full blown protects in themselves.
>

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 .

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

Dave West wrote:
>
> On Mon, 24 Jan 2000, Stan Brown wrote:
> > On Mon Jan 24 04:12:43 2000 Mark Hutton wrote...
<clip>
> > 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?

I think it is easier to make a generator that takes Grafcet/SFCs and converts it into instruction list of ladder. The PLC programming
environment could take this task.

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 Tue Jan 25 04:56:57 2000 Dave West wrote...
> >
> >> 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?
>
> Hard to sat at this early point. Perhaps this could be handled by a
> translator front end in the programing/editing/documentation package.
> Perhaps it would be best handled by a specila version of the logic engine.
>
> Can anyone that has actually deployed SFC based application code comment on this?<

I should read the replies first :)

I have used state transition diagrams, SFC and/or Grafcet to model processes and implemented it with instruction list code. As I see it,
Grafcet/SFC could be a graphical representation of the process to control, where the resulting PLC code is generated into ladder or instruction list for 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
 
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?


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

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Dave West
>
> 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
 
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
 
Top