Today is...
Thursday, December 14, 2017
Welcome to Control.com, the global online
community of automation professionals.
Featured Video...
Featured Video
A demonstration of EtherCAT control of linear motors using the CTC EtherCAT master.
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive
Fw: shared memory
Ok gentleman, this is what I see as the basics for my assumed task. 1) SharedMemoryManager ...
By Simon Martin on 16 January, 2000 - 9:15 am

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.

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.

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.

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.

Questions:

Can each PLC Engine have its' own VirtualIO table that maps onto the global IO table?
What is the harm of more one process updating an output (apart from the programmers sanity)?
Any more ideas before I start coding?

Debian GNU User
Simon Martin
Project Manager
Isys
mailto: smartin@isys.cl

There is a chasm of carbon and silicon the software cannot bridge


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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

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

Oops, terminology clash! Terminology clash!

I'm using module to mean "logic engine or such other program".

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

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

I meant that - for the semaphore-protected outputs - there would be a relatively small number of semaphores, each of which would protect a whole section of the machine.

Permanently-owned outputs are permanently-owned, nothing to talk about there. (Permanently-owned points don't even have any performance penalty
relative to free-for-all writing.)


Jiri
--
Jiri Baum <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Phil Covington on 18 January, 2000 - 6:20 pm

Lets forget about "determinism" and talk about FAST (as Stan Brown defined it in another post as 35 ms scan times and under). The normal Linux kernel is not going to be able to give you a FAST PLC as defined above. So the question is what is a minimum scan time that people can live with? I am talking about scan times assuming a Ladder Logic Engine running. I would like to see sub 15 ms scan times... What about everyone else?

----- Original Message -----
From: "Mark Hutton" <mark.hutton@vogal.demon.co.uk>

> In my experience there is an argument (of sorts), not as big as the
> ladder/no ladder argument, amongst PLC programmers on this very point.
>
> Some of us make the program run as fast as possible by only scanning
> appropriate ladder, i.e. don't scan the lift logic if the lift is not in
> operation.
>
> Others scan everything in the hope of achieving more consistent scan
times.
>
> Even in the latter case PLC operation is not particularly deterministic
and
> scan times can very greatly depending on the state of an input. In most
> cases this does not affect the resulting application.
>
> RT would be a great option, but IMHO not necessarily for an early release.
>
> Of course, logic dictates that an understanding of the requirements of RTL
> is necessary to avoid painting ourselves into a corner over RT
> implementation at a later date.
>
> -----Original Message-----
> From: linuxplc-admin@linuxplc.org [mailto:linuxplc-admin@linuxplc.org]On
> Behalf Of Stan Brown
>
> On Mon Jan 17 19:33:41 2000 Curt Wuollet wrote...
> >
> >This is just the discussion I would like to see. Do we accomodate RTL or not.
> >If we need realtime we need to think this through.
> >cww
>
> I would like to get something out the door, without adding in the
> complexities of RTL.
>
> Hardware PLC's are not determininistic, they are just FAST. I have written
> a
> application where the response time is sub 90 msec. response time in
> this case includes the actual operation of 15KV power breakers, which
> have an operation type of 3 power line cycles (16.5 ms per cycle).
>
> So as you can see, the response can be kept in a reasonable range by a
> careful application programmer.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

-----Original Message-----
From: Phil Covington <phil@philcovington.com>
To: linuxplc@linuxplc.org <linuxplc@linuxplc.org>
Date: 19, January 2000 10:20
Subject: Re: Fw: LinuxPLC: Fw: shared memory

>Lets forget about "determinism" and talk about FAST (as Stan Brown defined
>it in another post as 35 ms scan times and under). The normal Linux kernel
>is not going to be able to give you a FAST PLC as defined above. So the
>question is what is a minimum scan time that people can live with? I am
>talking about scan times assuming a Ladder Logic Engine running. I would
>like to see sub 15 ms scan times... What about everyone else?


I think that a few issues are involved -

a) 35 ms does not look very fast, at least for a short program

b) 10 ms would be "medium fast" in my opinion

c) there is likely to be some "fixed overhead" regardless of length of
program - how much?

d) how much is speed affected by more complex processing

e) there should be some means for optimization - at least a "speed counter" - which would tell average scan time over last ten (?)scans and
longest scan time over configurable period


Petr

--
Petr Baum <petr@baum.com.au>




_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Tue Jan 18 07:47:09 2000 Jiri Baum wrote...
>
>Jiri Baum:
>> >I'm assuming that each semaphore would be used for many different
>> >points. Modules would hand over to each other whole sections of the
>> >machine (or the whole machine altogether).
>
>> >If two modules need to work on the same point at the same time, they
>> >should either communicate with each other, or use intermediate coils
>> >which are then explicitly ORed or ANDed together.
>
>Oops, terminology clash! Terminology clash!
>
>I'm using module to mean "logic engine or such other program".
>

Module in this context can be read as a peice of I/O hardware.

So how do we protect access to an individual output, or at a minimum to a whole output module?

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Mon Jan 17 16:40:53 2000 Curt Wuollet wrote...
>
>Stan Brown wrote:
>>
>> On Mon Jan 17 15:02:29 2000 Curt Wuollet wrote...
>> >
>> >Hi Stan,
>> >
>> >We're fortunate here in that the only concession we need to make to allow
>> >RTL in the future is to use memory accessable by both. Not using that type
>> >of memory excludes use of RTL unless we use fifos. Fifos are not a good
>> >fit for what we are doing. That's why I asked (indirectly) if all this
>> >magic will work with that type of memory. Real world, we will probably
>> >want it or need it. As long as we stay with that form we won't have to
>> >rewrite if we need RTL. We can stay in userland for now, indeed the
>> >driver I'm writing uses the kernel networking services and I'm not even
>> >gonna try to figure out how to do that from RTL. We can play around
>> >with the jiffy timer some, but really fast performance may require both.
>> >I was making this assumption initially, but, in the ensuing discussion
>> >I am hearing things that I'm not sure are doable this way. Maybe, but
>> >I'm not sure. Those who are writing code need to check this out.
>> >
>> I am afraid I have lost the point of this thread. What were you asking, relative to this?
>You were saying you wanted to get something out without the complexities
>of RTLinux. I am saying I agree, but, we want to preserve that option
>because we may need it. That requires that we stick with the original
>shared memory scheme. I'm not sure some of the things proposed are
>compatible with that. Since much of the detail is known only to the
>coder, they will need to check it out if we are to preserve that functionality. <

I am no longer certain that we can produce a useful project without resorting to some form of real time extension.

I _really_ hate this, as the design I was proposing would have worked on almost any flavor of *NIX. Something I was really wanting to accomplish.

While Linux is nice, when my stuff really just must stay up, I use FreeBSD.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 19 January, 2000 - 12:04 am

Stan Brown wrote:
>
> I am no longer certain that we can produce a useful project without resorting to some form of real time extension.<

I don't think it's as bad as all that, but it will take tight efficient programming to get the most out of the platform. If that isn't fast enough then we would want to try the utime and KURT for critical portions. There will always be things that simply can't be too fast and we have RTLinux for those. Pity RTL and KURT are at the moment, not compatible with each other.
There are POSIX real time facilities that should be checked out. If we can keep the chrome and tailfins out of the core, we should be competitive.

>
> I _really_ hate this, as the design I was proposing would have worked on almost any flavor of *NIX. Something I was really wanting to accomplish. <

I would prefer a "normal" non critical environment also, but, Linux is a general purpose OS. If I was aiming for a straight, all out PLC, I would start out with ECOS. I see this as a largely networked controller. The latency and speed of fieldbus IO may end up predominating the cycle time anyway.

> While Linux is nice, when my stuff really just must stay up, I use FreeBSD.

I like *BSD also, but their cathedral development turns me off.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Mon, 17 Jan 2000, Stan Brown wrote:

> On Mon Jan 17 12:37:41 2000 Jiri Baum wrote...
> >
> >Simon Martin:
> >> >> If a logic engine requests write permission for a point that another
> >> >> registered logic engine alread has write permission for then the
> >> >> request will fail.
> >
> >Jiri Baum:
> >> >I don't think we should be implementing this - we should make use of
> >> >semaphores if we need handover of outputs between modules. Semaphores
> >> >are the Right Thing for this job. No point re-inventing them.
> >
> >Stan Brown:
> >> Question, I am thinking of "ownership" of an output being
> >> implemented on a per point basis, as opposed to say an I/O scanner
> >> or a "rack' basis. Given this wouldn't we have a lot of semaphores
> >> to deal with here?
> >
> >I'm assuming that each semaphore would be used for many different points.
> >Modules would hand over to each other whole sections of the machine (or the
> >whole machine altogether).
> >
> >If two modules need to work on the same point at the same time, they should
> >either communicate with each other, or use intermediate coils which are
> >then explicitly ORed or ANDed together.
>
> I still don't think we are in synch here. I envision ownership of an
> output being permanent (for the life of the run time). It can only be
> changed which the system down. So it should be possible to arbitrarily
> assign a given output within a card to a given logic engine. Although I
> can see that this may not be feasible, and we may need to only allow
> assignments at the whole module level.
>
> In real PLC's it's done at the entire rack level, BTW>

Exactly why I think this whole idea of ownership and more than one logic engine controlling a single I/O point is complete silliness. What happened to KISS. For the purposes of my description a logic engine is the equivelant to a PLC rack. and there should be one perlogic programme and it handles its own I/O which no other can access. If you want more than one logic engine on the same Linux box then simply
run another task with the same restrictions, it has it's own I/O that no other can access.
Some people keep talking about different logic engines running different languages. How daft does this sound to other system programmers out there. It sounds very misconcieved to me. Surely there will be only one logic engine that executes one programme in it's own internal instruction set
(Somewhat analogous of a CPU. A CPU does not run BASIC or C or RLL, it runs only it's own instruction set or machine code). Yes PLC manufacturers do make and sell different "processors" for different languages but does
that make it the correct thing to do? Surely the language (RLL, C, function block, etc) is a userland thing only and will be compiled by the
programming enviroment into and executable for the logic engine to process. Result: one logic engine and lots of languages for developing the
application (AKA KISS).


Dave West E-Mail: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Tue, 18 Jan 2000, Phil Covington wrote:

> Lets forget about "determinism" and talk about FAST (as Stan Brown defined
> it in another post as 35 ms scan times and under). The normal Linux kernel
> is not going to be able to give you a FAST PLC as defined above. So the
> question is what is a minimum scan time that people can live with? I am
> talking about scan times assuming a Ladder Logic Engine running. I would
> like to see sub 15 ms scan times... What about everyone else?

Why do most people keep refering to the logic engine as though it will run one particular language, as you said above "Ladder Logic Engine". If the logic engine is constructed in such a manner then it will simply be a high
level language interpretter and be so slow it will take half a day to do anything 8-). The logic engine should not interpret ladder, or BASIC or C or any other high level language. That is the job of a compiler. The logic engine should only interpret it's own internal instruction set (yet to be defined) similar to byte code or p-code or machine code. If the internal instruction set is carefully planned then it can do anything reasonably fast.

Dave West E-Mail: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Wed Jan 19 06:11:45 2000 Dave West wrote...
>
>On Tue, 18 Jan 2000, Phil Covington wrote:
>
>> Lets forget about "determinism" and talk about FAST (as Stan Brown defined
>> it in another post as 35 ms scan times and under). The normal Linux kernel
>> is not going to be able to give you a FAST PLC as defined above. So the
>> question is what is a minimum scan time that people can live with? I am
>> talking about scan times assuming a Ladder Logic Engine running. I would
>> like to see sub 15 ms scan times... What about everyone else?
>
>Why do most people keep refering to the logic engine as though it will run
>one particular language, as you said above "Ladder Logic Engine". If the
>logic engine is constructed in such a manner then it will simply be a high
>level language interpretter and be so slow it will take half a day to do
>anything 8-). The logic engine should not interpret ladder, or BASIC or C
>or any other high level language. That is the job of a compiler. The logic
>engine should only interpret it's own internal instruction set (yet to be
>defined) similar to byte code or p-code or machine code. If the internal
>instruction set is carefully planned then it can do anything reasonably
>fast.

This misses the basic point of a PLC. A PLC allows run time examination, and editing of the program statements, and data table. Thus it is inherently not a traditional compiled language. The closest thing to a compiled PLC I have ever seen is AB's PI. In theory it does compile the statements, but if it does, it's totally invisible to me as an application programmer.

Of course uncompiling might explain why backing mine up takes over an hour :-)

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Wed Jan 19 06:03:18 2000 Dave West wrote...
>
>Exactly why I think this whole idea of ownership and more than one logic
>engine controlling a single I/O point is complete silliness. What happened
>to KISS. For the purposes of my description a logic engine is the
>equivelant to a PLC rack. and there should be one perlogic programme and
>it handles its own I/O which no other can access.
>If you want more than one logic engine on the same Linux box then simply
>run another task with the same restrictions, it has it's own I/O that no
>other can access.
>Some people keep talking about different logic engines running different
>languages. How daft does this sound to other system programmers out there.
>It sounds very misconcieved to me. Surely there will be only one logic
>engine that executes one programme in it's own internal instruction set
>(Somewhat analogous of a CPU. A CPU does not run BASIC or C or RLL, it
>runs only it's own instruction set or machine code). Yes PLC manufacturers
>do make and sell different "processors" for different languages but does
>that make it the correct thing to do? Surely the language (RLL, C,
>function block, etc) is a userland thing only and will be compiled by the
>programming enviroment into and executable for the logic engine to
>process. Result: one logic engine and lots of languages for developing the
>application (AKA KISS).

How you use the project, as an application programmer is entirely up to you.

I have used PI's with multiple logic processors quite a bits, and would miss this functionality.

As for different logic engines running different languages in the same node, I can see many uses for this. Data handling is a very poor fit in ladder diagram, on the other hand ladder is the best way to do machine control. Take an automotive assembly plant selectivity system. Lots of conveyers, loft tables, elevators etc that need machine control, _and_ a huge amount of build data to be handled.

I would do this with 2 different logic engines running 2 different languages, given the choice.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Phil Covington on 19 January, 2000 - 8:15 am

Dave West wrote:

>On Tue, 18 Jan 2000, Phil Covington wrote:

>> Lets forget about "determinism" and talk about FAST (as Stan Brown defined
>> it in another post as 35 ms scan times and under). The normal Linux kernel
>> is not going to be able to give you a FAST PLC as defined above. So the
>> question is what is a minimum scan time that people can live with? I am
>> talking about scan times assuming a Ladder Logic Engine running. I would
>> like to see sub 15 ms scan times... What about everyone else?
>
>Why do most people keep refering to the logic engine as though it will run
>one particular language, as you said above "Ladder Logic Engine". If the
>logic engine is constructed in such a manner then it will simply be a high
>level language interpretter and be so slow it will take half a day to do
>anything 8-). The logic engine should not interpret ladder, or BASIC or C
>or any other high level language. That is the job of a compiler. The logic
>engine should only interpret it's own internal instruction set (yet to be
>defined) similar to byte code or p-code or machine code. If the internal
>instruction set is carefully planned then it can do anything reasonably
>fast.

Dave,

Drop the word "Ladder" and re-read my previous post. I am afraid you are missing the point. I don't care if you write the "Logic Engine" in
assembly language and the actual logic is hard coded, there are still problems with a periodic task running ( in user space) with the normal linux kernel. Your statement "If the internal instruction set is carefully planned then it can do anything reasonably fast" is meaningless in the context of scheduling issues with the normal
Linux kernel. This is an operating system issue.

I used the words "Ladder" and "scan" so that we could relate these OS issues to a real PLC. Replace the word "scan" with periodic task and the problems are the same.

Take a look at the thread "LinuxPLC: Real Time? Take Two"

Phil Covington
vHMI






_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

>The logic engine should not interpret ladder..."

I can't speak about Allen-Bradley. If you download a program from an Allen-Bradley PLC you will receive much more information about your program than you will from other brands. They seem to store a lot. Who knows if they interpret the Ladder, or the mnemonics, or op-code.

For other brands, when you download a Ladder to a PLC, the Ladder is first automatically converted to Mnemonics, which is then fed through an
Assembler to create the code pattern to be sent to the PLC. You are able to write the mnemonic direct if you wish. Like any Dos/Linux mnemonics text file sent through an Assembler, the result has no comments, only the bare essentials. Like a Dos/Linux assembler the result is a hex listing of op-codes that the microprocessor can understand. Like in Dos/Linux there is a one for one correspondence between the three characters "AND" as a written instruction in the Mnemonics style, and the one byte -call it a token, call it an op-code if you will. Likewise you would expect that "OR", "ANDLOAD", "ORLOAD" all have their own specific byte value or op-code. Just like x86 op-codes, you would expect some onebyte, some two byte, some multiple byte op-codes, and further like x86 op-codes you would expect some of the data to be packed as two or three or four nibbles or what ever the microprocessor's instruction list demands.

The key point here is that for brands other than Allen-Bradley, it is possible to glean that the PLC microprocessor Does operate on a piece of
code that has been downloaded to it from the Laptop's Ladder editor, - - - in the form of the microprocessor's op-code language - - -.
If the microprocessor is a 502,Z80,6809,68000,X86 or some custom made one, it could be expected to be fed by a program in its own op-code Hex pattern. If you were really mad keen you could hand code the Hex code (like you could x86) and transmit it to the PLC, but who is that mad.

Now, are we going to go that far that the LinuxPLC is going to run x86 op-codes. That is probably too big a jump at first.


Second topic of discussion:
> This misses the basic point of a PLC. A PLC allows run time examination,
> and editing of the program statements, and data table. Thus it is
> inherently not a traditional compiled language.

When you look at the Laptop, and monitor the on of states of the rungs, then you are never actually monitoring the rung. Again I can't speak for how Allen-Bradley does it, for other brands what actually happens is that a small message is sent to the PLC to enquire either about a single address, or the message may be stated so to ask for the status of a quantity of
addresses starting from address so and so. Scada packages or home made software can be written by following the communication protocol given in
manual by the PLC manufacturer. The Laptop with it Ladder monitor merely asks a dozen questions of the PLC if there are a dozen contact showing on
the screen. If it should happen that there is some nearness in the addresses, then the Ladder monitor might have some smarts which get it to
ask fewer questions to the PLC. The result is a good impersonation of a Ladder monitor that is monitoring the actual workings of the Ladder Logic. In fact there in no difference in degree of difficulty, for the Ladder monitor to ask for and display widely separated and unrelated "bits" as it would be for the questions to be asked about bits on a single rung. It gives the appearance of a separate/independent task/thread that answers questions about the value of particular bits from a data table, quite
separate it seems the logic engine. (Of course regardless of what multitasking is being emulated, there is but one microprocessor).


> On Wed Jan 19 06:11:45 2000 Dave West wrote...
> >
> >On Tue, 18 Jan 2000, Phil Covington wrote:
> >
> >> Lets forget about "determinism" and talk about FAST (as Stan Brown
defined
> >> it in another post as 35 ms scan times and under). The normal Linux
kernel
> >> is not going to be able to give you a FAST PLC as defined above. So the
> >> question is what is a minimum scan time that people can live with? I am
> >> talking about scan times assuming a Ladder Logic Engine running. I would
> >> like to see sub 15 ms scan times... What about everyone else?
> >
> >Why do most people keep refering to the logic engine as though it will run
> >one particular language, as you said above "Ladder Logic Engine". If the
> >logic engine is constructed in such a manner then it will simply be a high
> >level language interpretter and be so slow it will take half a day to do
> >anything 8-). The logic engine should not interpret ladder, or BASIC or C
> >or any other high level language. That is the job of a compiler. The logic
> >engine should only interpret it's own internal instruction set (yet to be
> >defined) similar to byte code or p-code or machine code. If the internal
> >instruction set is carefully planned then it can do anything reasonably fast.< <
>
> This misses the basic point of a PLC. A PLC allows run time examination,
> and editing of the program statements, and data table. Thus it is
> inherently not a traditional compiled language. The closest thing to a
> compiled PLC I have ever seen is AB's PI. In theory it does compile the
> statements, but if it does, it's totally invisible to me as an
application programmer.
>
> Of course uncompiling might explain why backing mine up takes over an
hour :-)
>
> --
> Stan Brown stanb@netcom.com
_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Hurd, David L (GEA, 053698) on 19 January, 2000 - 10:16 am

Phil and all,
The faster the better. The new PLC CPUs can produce scan times around 5 - 6 msec and there is a noticeable improvement in machine performance. I'd would set 20 msec as a reasonable maximum.
Dave Hurd
GE Appliances

> -----Original Message-----
> From: Phil Covington
>
> Lets forget about "determinism" and talk about FAST (as Stan Brown defined
> it in another post as 35 ms scan times and under). The normal Linux
> kernel
> is not going to be able to give you a FAST PLC as defined above. So the
> question is what is a minimum scan time that people can live with? I am
> talking about scan times assuming a Ladder Logic Engine running. I would
> like to see sub 15 ms scan times... What about everyone else?
>

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 19 January, 2000 - 11:11 am

This has been stated before, several times.

My vote (and my logic solver (let's see how many names we can find for the same thing)) is to interpret tokenised instruction list. My
complier/tokeniser is built in to the TCP/IP programming port - enabling consistent programming (using IL) from a text terminal.

Ladder, STL, FBD and other language support is provided by editors which save their output in IL. This works for Siemens, Omron, Mitsubishi and even AB to some extent.

The only other native support that may be required is for SFC states.

-----Original Message-----
From: linuxplc-admin@linuxplc.org [mailto:linuxplc-admin@linuxplc.org]On
Behalf Of Dave West

On Tue, 18 Jan 2000, Phil Covington wrote:

> Lets forget about "determinism" and talk about FAST (as Stan Brown defined
> it in another post as 35 ms scan times and under). The normal Linux kernel
> is not going to be able to give you a FAST PLC as defined above. So the
> question is what is a minimum scan time that people can live with? I am
> talking about scan times assuming a Ladder Logic Engine running. I would
> like to see sub 15 ms scan times... What about everyone else?


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 19 January, 2000 - 11:52 am

Actually, many PLC use compiled or tokenised code (even AB) when you work online with these systems , the terminal software translates the compiled
view to the original ladder diagram. Which is why, when going online to an SLC it uploads the program onto your PC, it then translates the compiled code back to ladder.


-----Original Message-----
From: linuxplc-admin@linuxplc.org [mailto:linuxplc-admin@linuxplc.org]On
Behalf Of Stan Brown

On Wed Jan 19 06:11:45 2000 Dave West wrote...
>
>On Tue, 18 Jan 2000, Phil Covington wrote:
>
>> Lets forget about "determinism" and talk about FAST (as Stan Brown defined
>> it in another post as 35 ms scan times and under). The normal Linux kernel
>> is not going to be able to give you a FAST PLC as defined above. So the
>> question is what is a minimum scan time that people can live with? I am
>> talking about scan times assuming a Ladder Logic Engine running. I would
>> like to see sub 15 ms scan times... What about everyone else?
>
>Why do most people keep refering to the logic engine as though it will run
>one particular language, as you said above "Ladder Logic Engine". ...<clip>
>

This misses the basic point of a PLC. A PLC allows run time examination, and editing of the program statements, and data table. Thus it is
inherently not a traditional compiled language. The closest thing to a compiled PLC I have ever seen is AB's PI. In theory it does compile the
statements, but if it does, it's totally invisible to me as an application programmer.

Of course uncompiling might explain why backing mine up takes over an hour :-)



_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 19 January, 2000 - 12:35 pm

>
>I think that a few issues are involved -
>
>a) 35 ms does not look very fast, at least for a short program
>
>b) 10 ms would be "medium fast" in my opinion
>
>c) there is likely to be some "fixed overhead" regardless of length of
>program - how much?

The schedulers granuality (10ms) is the big part here some multiple of this, depending on a lot of things about the process priority and to some degree the overall load of the computer.
I would make a rough guess about 20-30ms but in that time is the I/O mapper run and a fairly long ladder (or anything else) solved + some time left to all the other processes in the computer.

>d) how much is speed affected by more complex processing

As I said above I don't think it will be much for
small to medium programs, really large programs
is however going to need more time. A modern
processor like for example a pentium II @ 350MHz
could be executing about perhaps 4 000 000 assembler instructions in 10ms (yes they can execute two instructions at the same time)

>e) there should be some means for optimization - at least a "speed
>counter" - which would tell average scan time over last ten (?)scans and
>longest scan time over configurable period
>

A speed counter is the easy part.


/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: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 19 January, 2000 - 2:08 pm

>Some people keep talking about different logic engines running different
>languages. How daft does this sound to other system programmers out there.
>It sounds very misconcieved to me. Surely there will be only one logic
>engine that executes one programme in it's own internal instruction set
>(Somewhat analogous of a CPU. A CPU does not run BASIC or C or RLL, it
>runs only it's own instruction set or machine code). Yes PLC manufacturers
>do make and sell different "processors" for different languages but does
>that make it the correct thing to do? Surely the language (RLL, C,
>function block, etc) is a userland thing only and will be compiled by the
>programming enviroment into and executable for the logic engine to
>process. Result: one logic engine and lots of languages for developing the
>application (AKA KISS).

I do not agree!

Everything in ladder (LD) of function block (FBD) is translateable to and from instruction list (IL) possibly also structured text (ST) but I am not entirely that sure here. Grafcet (SFC) is easily translateable to the oter languages but not
as easily translated back (it is possible but not if anyone have made some certain changes)

All this is easily solved by the same logic solver from some kind of byte code, and this will be really fast

However, translating SFC to the same byte code will work, but it would be a *lot* faster to run this from another logic solver specially written for SFC.

Calcualting a PID loop could also be done from the samy byte code but that one would also be a *lot* faster if compiled (from C) to the processors own machine code handling the complete PID algorithm just reading and writing the I/O:s etc.

Result: some logic engines and some other engines for solving non logic stuff (for example PID loops, fuzzy logic, whatever) and a lot more languages for developing applications.

Some people even want to make programs in C and compile them to run directly against the global memory (or whatever)

If what you really thought was something like "compile everything to pure machine code and let the processor just run" that would definitely be the fastest but probably not the most practical thing to do.


/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: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Wed Jan 19 08:12:52 2000 Phil Covington wrote...
>
>Drop the word "Ladder" and re-read my previous post. I am afraid you are
>missing the point. I don't care if you write the "Logic Engine" in
>assembly language and the actual logic is hard coded, there are still
>problems with a periodic task running ( in user space) with the normal linux
>kernel. Your statement "If the internal instruction set is carefully
>planned then it can do anything reasonably
>fast" is meaningless in the context of scheduling issues with the normal
>Linux kernel. This is an operating system issue.
>
>I used the words "Ladder" and "scan" so that we could relate these OS issues
>to a real PLC. Replace the word "scan" with periodic task and the problems
>are the same.
>
>Take a look at the thread "LinuxPLC: Real Time? Take Two"
>


Are you asying we can't get to an _average_ scan time in the 10's of milliseconds with the standard scheduler? Or are you concerned that some scans may be long? If so by about how much?

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Phil Covington on 19 January, 2000 - 10:11 pm

----- Original Message -----
From: "Stan Brown" <stanb@awod.com>

<snip>

> Are you asying we can't get to an _average_ scan time in the 10's of
> milliseconds with the standard scheduler? Or are you concerned that
> some scans may be long? If so by about how much?
>
> --

Unfortunately I am saying that even with the POSIX soft realtime support in the normal linux kernel you are not going to see scan times under 20 ms on an unloaded system. With increasing system load the scans will be even longer by an unpredictable amount and will jump around all over the place (jitter).

Phil Covington
vHMI



_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Wed Jan 19 22:10:18 2000 Phil Covington wrote...
>
>----- Original Message -----
>From: "Stan Brown" <stanb@awod.com>
>
><snip>
>
>> Are you asying we can't get to an _average_ scan time in the 10's of
>> milliseconds with the standard scheduler? Or are you concerned that
>> some scans may be long? If so by about how much?
>>
>> --
>
>Unfortunately I am saying that even with the POSIX soft realtime support in
>the normal linux kernel you are not going to see scan times under 20 ms on
>an unloaded system. With increasing system load the scans will be even
>longer by an unpredictable amount and will jump around all over the place (jitter). <

Hmm, wasn't there a second choice in the realtime flavors that used POSIX calls?

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Phil Covington on 19 January, 2000 - 10:48 pm

----- Original Message -----
From: "Stan Brown" <stanb@awod.com>

<snip>

> Hmm, wasn't there a second choice in the realtime flavors that used
> POSIX calls?

RTAI is based on RTLinux and adds a POSIX style API... In Ver 2.0 of RTLinux, NMT adopted a POSIX style API like RTAI. Version 2 also supports
SMP

Version 1 of RTLinux runs with the Linux 2.0 kernel. Version 2 of RTLinux runs with the Linux 2.2 kernel.

Phil Covington
vHMI


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Tue, Jan 18, 2000 at 09:45:00PM -0500, Stan Brown wrote:
> On Tue Jan 18 07:47:09 2000 Jiri Baum wrote...
> >
> >Jiri Baum:
> >> >I'm assuming that each semaphore would be used for many different
> >> >points. Modules would hand over to each other whole sections of the
> >> >machine (or the whole machine altogether).
> >
> >> >If two modules need to work on the same point at the same time, they
> >> >should either communicate with each other, or use intermediate coils
> >> >which are then explicitly ORed or ANDed together.
> >
> >Oops, terminology clash! Terminology clash!
> >
> >I'm using module to mean "logic engine or such other program".
> >
>
> Module in this context can be read as a peice of I/O hardware.
>
> So how do we protect access to an individual output, or at a minimum to
> a whole output module?

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

A given semaphore can protect any number of outputs.

Jiri
--
Jiri Baum <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Wed, Jan 19, 2000 at 11:03:18AM +0000, Dave West wrote:
> Some people keep talking about different logic engines running different
> languages. How daft does this sound to other system programmers out there.
> It sounds very misconcieved to me.

That's because it's poor terminology.

There may be one thing that's properly a logic engine, another thing written in C doing FFTs or something, and maybe even an HMI [*].

Now, try inventing a word that covers all of those :-)

(I tried using the word "module", but some people took that as "I/O module" rather than the software kind. It can also mean kernel module, so maybe it isn't such a good word anyway.)


[*] 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.


Jiri
--
Jiri Baum <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 3 February, 2000 - 4:00 pm

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

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


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Thu, Jan 20, 2000 at 01:29:49AM +1030, LouisKriek wrote:
> Now, are we going to go that far that the LinuxPLC is going to run x86
> op-codes. That is probably too big a jump at first.

It's not a big jump at all - just output C code (with appropriate #line directives) and call gcc.

I've got a Perl script somewhere that I wrote in an afternoon that can translate the text-version of ladder (non-structured) like that. I'll post
it if there's interest (or check it into the CVS).

Jiri
--
Jiri Baum <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Thu Jan 20 20:31:24 2000 Jiri Baum wrote...
>
>On Thu, Jan 20, 2000 at 01:29:49AM +1030, LouisKriek wrote:
>> Now, are we going to go that far that the LinuxPLC is going to run x86
>> op-codes. That is probably too big a jump at first.
>
>It's not a big jump at all - just output C code (with appropriate #line
>directives) and call gcc.
>
>I've got a Perl script somewhere that I wrote in an afternoon that can
>translate the text-version of ladder (non-structured) like that. I'll post
>it if there's interest (or check it into the CVS).
>

I think he meant too big a jump for user acceptance.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Thu Jan 20 19:40:46 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.

Actually I am much more likely to deploy a Linux HMI first before a Linux PLC. However IMHO that's a whole separate project.

Lets not get so much stuff on our plate, that we never produce a system at all.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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? I have a Factory Link application with about 50K, come to think of it. Never mind, should not be a problem.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

From: Jiri Baum <jiri@baum.com.au>

>That's because it's poor terminology.
>
>There may be one thing that's properly a logic engine, another thing
>written in C doing FFTs or something, and maybe even an HMI [*].
>
>Now, try inventing a word that covers all of those :-)
>
>(I tried using the word "module", but some people took that as "I/O module"
>rather than the software kind. It can also mean kernel module, so maybe it
>isn't such a good word anyway.)
>


How about using the word "task" to represent independently operating software "parts"?

Ron Davis
Ron.Davis@synchrony.com


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Wed, 19 Jan 2000, Phil Covington wrote:
<clip>
> Dave,
>
> Drop the word "Ladder" and re-read my previous post. I am afraid you are
> missing the point. I don't care if you write the "Logic Engine" in
> assembly language and the actual logic is hard coded, there are still
> problems with a periodic task running ( in user space) with the normal linux
> kernel. Your statement "If the internal instruction set is carefully
> planned then it can do anything reasonably
> fast" is meaningless in the context of scheduling issues with the normal
> Linux kernel. This is an operating system issue.
>
> I used the words "Ladder" and "scan" so that we could relate these OS issues
> to a real PLC. Replace the word "scan" with periodic task and the problems
> are the same.
>
> Take a look at the thread "LinuxPLC: Real Time? Take Two" <

Sorry, I picked the wrong message to try and make my point. I agree entirely with what you are trying to say regarding how long it takes the
logic engine to process it's instruction programme once. Yes it can take a relatively long time due to scheduling and as such I think the logic engine may probably end up being some sort of real time task. However, I think the arguments for or against real time are pointless at this stage. Although not trivial to port a task to real time it will be far easier to write things as normal linux tasks and get the logic sorted then optimise for speed and convert what needs to be converted to real time (around about version 2.0).

To explain my original point a little further: A lot of people are confusing issues in the logic engine area with statements like "it must run ladder" or "it would be nice if it ran C". Such statements are confusing many people on the list as to what does what, when and where. I would like everyone to think more carefully about what the logic engine will do and understand that it will have no knowledge of ladder, C, BASIC,
or any other language that describes a logical processing sequence. Just for clarity of thought 8-)


Dave West E-Mail: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

Saved me the job of explaining some of the more basic principles. Thanks.

Oh and his point about monitoring makes it all the more obvious that a real PLC compiles the programme into some internal instruction set for
what is most likely an emulated machine.

On Thu, 20 Jan 2000, LouisKriek wrote:

> >The logic engine should not interpret ladder..."
>
> I can't speak about Allen-Bradley. If you download a program from an
> Allen-Bradley PLC you will receive much more information about your program
> than you will from other brands. They seem to store a lot. Who knows if
> they interpret the Ladder, or the mnemonics, or op-code.
>
> For other brands, when you download a Ladder to a PLC, the Ladder is first
> automatically converted to Mnemonics, which is then fed through an
> Assembler to create the code pattern to be sent to the PLC. You are able to
> write the mnemonic direct if you wish. Like any Dos/Linux mnemonics text
> file sent through an Assembler, the result has no comments, only the bare
> essentials. Like a Dos/Linux assembler the result is a hex listing of
> op-codes that the microprocessor can understand. Like in Dos/Linux there
> is a one for one correspondence between the three characters "AND" as a
> written instruction in the Mnemonics style, and the one byte -call it a
> token, call it an op-code if you will. Likewise you would expect that
> "OR", "ANDLOAD", "ORLOAD" all have their own specific byte value or
> op-code. Just like x86 op-codes, you would expect some onebyte, some two
> byte, some multiple byte op-codes, and further like x86 op-codes you would
> expect some of the data to be packed as two or three or four nibbles or
> what ever the microprocessor's instruction list demands.
>
> The key point here is that for brands other than Allen-Bradley, it is
> possible to glean that the PLC microprocessor Does operate on a piece of
> code that has been downloaded to it from the Laptop's Ladder editor,
> - - - in the form of the microprocessor's op-code language - - -.
> If the microprocessor is a 6502,Z80,6809,68000,X86 or some custom made one,
> it could be expected to be fed by a program in its own op-code Hex pattern.
> If you were really mad keen you could hand code the Hex code (like you
> could x86) and transmit it to the PLC, but who is that mad.
>
> Now, are we going to go that far that the LinuxPLC is going to run x86
> op-codes. That is probably too big a jump at first.
>
>
> Second topic of discussion:
> > This misses the basic point of a PLC. A PLC allows run time examination,
> > and editing of the program statements, and data table. Thus it is
> > inherently not a traditional compiled language.
>
> When you look at the Laptop, and monitor the on of states of the rungs,
> then you are never actually monitoring the rung. Again I can't speak for
> how Allen-Bradley does it, for other brands what actually happens is that a
> small message is sent to the PLC to enquire either about a single address,
> or the message may be stated so to ask for the status of a quantity of
> addresses starting from address so and so. Scada packages or home made
> software can be written by following the communication protocol given in
> manual by the PLC manufacturer. The Laptop with it Ladder monitor merely
> asks a dozen questions of the PLC if there are a dozen contact showing on
> the screen. If it should happen that there is some nearness in the
> addresses, then the Ladder monitor might have some smarts which get it to
> ask fewer questions to the PLC. The result is a good impersonation of a
> Ladder monitor that is monitoring the actual workings of the Ladder Logic.
> In fact there in no difference in degree of difficulty, for the Ladder
> monitor to ask for and display widely separated and unrelated "bits" as it
> would be for the questions to be asked about bits on a single rung.
> It gives the appearance of a separate/independent task/thread that answers
> questions about the value of particular bits from a data table, quite
> separate it seems the logic engine. (Of course regardless of what
> multitasking is being emulated, there is but one microprocessor).

Dave West E-Mail: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

So is it time to decide on some - - very limited - - specifications for the
first LinuxPLC.
Just do PLC alone, Leave HMI till later.
Treat it as only a practice_run, version 0.0000000000000000000000000001
;-)
This is our "throw away", or a "tutorial" version.

Here is a simple specification that everyone will recognise or is familiar with:
Just a small 10in,8out shoe-box plc only doing bit banging relays, timers, counter with no retentivity yet (IL not yet LD). 1K instructions max.
Something like a SLC503. Leave the HMI till latter, for just use whatever AB software you already have to download and monitor. Or pick on a brand that we know is not popular but is extremely easy to simulate, and the HMI is cheap.

We can argue, and produce a better specification while we are leering by doing the simple thing.
For most of us, there are an awful lot of things to learn just doing this much. Not many of us have many compilers designs to our name.

If we eventually decide to make the LinuxPLC be a (6)1131 compliant device, we are going to have to become competent in a lot of computer science, by
starting simple first. I suggest that we -do- the "very simple" version first almost right now, and simultaneously hold discussions about the best
architecture that the first real LinuxPLC. Learn to make the first real LinuxPLC, by doing, on the "too simple", "throw-away", "getting started",
version.


Yes/No/Maybe/Never/Good/Bad/Indifferent?

<clip>
Lets not get so much stuff on our plate, that we never produce a system at all.

--
Stan Brown stanb@netcom.com

<clip>


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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.

Ron Davis
Ron.Davis@synchrony.com




_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Fri, 21 Jan 2000, Jiri Baum wrote:

> On Wed, Jan 19, 2000 at 11:03:18AM +0000, Dave West wrote:
> > Some people keep talking about different logic engines running different
> > languages. How daft does this sound to other system programmers out there.
> > It sounds very misconcieved to me.
>
> That's because it's poor terminology.
>
> There may be one thing that's properly a logic engine, another thing
> written in C doing FFTs or something, and maybe even an HMI [*].
>
> Now, try inventing a word that covers all of those :-)
>
> (I tried using the word "module", but some people took that as "I/O module"
> rather than the software kind. It can also mean kernel module, so maybe it
> isn't such a good word anyway.)
>
> [*] 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?

As for the poor terminology why do can't we give things names and use them. In my opinion we should have the following items:

Scheduler, a programme that sequences the execution of tasks (we could call it PLCsched).
Input scanner, a programme to scan the physical input devices and make a copy in a data table (say PLCIscan).
Logic engine, a programme to scan the machine logic (say PLCengine).
Output scanner, a programme to take an output data table and pass the values on to real output drivers (say PLCOscan).
Communication handler, a programme to handle requests for data from other programmes EG. HMI or monitor programme or logic compiler (say PLCcomm).

Agreed each of these is a software module that makes up the entire PLC system but the HMI, monitor programme and logic compilers are not. They are tools for accessing the system.

Any way I think we are spending too much time discussing terminology simply because most of us (myself included) are lazy typists and try to
describe something in as few key strokes as possible 8-)


Dave West E-Mail: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Fri, 21 Jan 2000, Jiri Baum wrote:

> On Thu, Jan 20, 2000 at 01:29:49AM +1030, LouisKriek wrote:
> > Now, are we going to go that far that the LinuxPLC is going to run x86
> > op-codes. That is probably too big a jump at first.
>
> It's not a big jump at all - just output C code (with appropriate #line
> directives) and call gcc.
>
> I've got a Perl script somewhere that I wrote in an afternoon that can
> translate the text-version of ladder (non-structured) like that. I'll post
> it if there's interest (or check it into the CVS).

I struggle to see how we could impliment this. Consider the following. the PLC is running and we want to upload a programme from a remote
device as we would with a real PLC. Our soft PLC accepts the programme as data and writes it into a data segment as defined by the Linux kernel
(Code segments are not writable). How do we then tell the kernel that the data segment should now become a code segment and it can schedule it for
execution. Unless there is a system call to do this it will simply cause a SEGFLT. As far as I know only the kernel can do this and thus for us to do it we would have to write the soft PLC as a kernel module. Alternatively we could compile to a real full blown elf executable and run that but that opens a whole new can of worms.

If someone has more insight as to how this loading of executable code modules can be done from a user process could they let me know as I don't.


Dave West E-Mail: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Fri Jan 21 10:00:11 2000 LouisKriek wrote...
>
>So is it time to decide on some - - very limited - - specifications for the
>first LinuxPLC.
>Just do PLC alone, Leave HMI till later.
>Treat it as only a practice_run, version 0.0000000000000000000000000001
>;-)
>
>Yes/No/Maybe/Never/Good/Bad/Indifferent?
>

Yes.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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.


Dave West E-Mail: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Fri Jan 21 09:32:11 2000 Ron Davis wrote...
>
>From: Jiri Baum <jiri@baum.com.au>
>Date: Friday, January 21, 2000 3:00 AM
>Subject: Re: Fw: LinuxPLC: Fw: shared memory
>
>>That's because it's poor terminology.
>>
>>There may be one thing that's properly a logic engine, another thing
>>written in C doing FFTs or something, and maybe even an HMI [*].
>>
>>Now, try inventing a word that covers all of those :-)
>>
>>(I tried using the word "module", but some people took that as "I/O module"
>>rather than the software kind. It can also mean kernel module, so maybe it
>>isn't such a good word anyway.)
>
>How about using the word "task" to represent independently operating software "parts"?

Task is good since it could be a process or a thread.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

I was reading some of the information about (6)1131-3 and the newer 61499 drafts, available from the ab ftp site someone mentioned recently on this
list. I have been reading so much from there, that I have lost track of excactly where I saw it. Sorry I can't be sure of the documents name. I do clearly remember that the word "task" has a paragraph explaining how it is to be understood, sorry I can't remember enough to go into print about it, but it caught my eye because it allows me to think about a super fast way but unorthodox way of doing the logic solver. This note is only to say, be aware of that the IEC wants to put a very specific meaning to the word "task".
Enough for now.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Fri Jan 21 10:11:37 2000 Dave West wrote...
>
>What has the HMI got to do with the logic engine aprt from querying it for
>data from time to time?

Absolutely correct. And once again, I think the HMI is a big enough project (or 2 projects) all it's own.

>As for the poor terminology why do can't we give things names and use
>them. In my opinion we should have the following items:
>
>Scheduler, a programme that sequences the execution of tasks (we could
>call it PLCsched).

Agreed,

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

Agreed, but we need multiple ones of these. If only to support different brands of hardware.

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

Agreed, but again, we need to allow for multiple ones of these, for instance to process different languages.

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

I think this can be combined with the input scanner.

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

Probably at some point in time. I am not certain we need this for V1.0

Additional tasks as I see them:

Timer execution task(s)
Counter execution task(s).
PID execution task(s).
Motion control execution task(s).
Editor/monitor/documentation package.

>Any way I think we are spending too much time discussing terminology
>simply because most of us (myself included) are lazy typists and try to
>describe something in as few key strokes as possible 8-)

Guilty as charged :-(

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Fri Jan 21 10:07:29 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.
>

A must have feature. Even for V 1.0.

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Wed, 19 Jan 2000 johan.bengtsson@pol.se wrote:

> >Some people keep talking about different logic engines running different
> >languages. How daft does this sound to other system programmers out there.
> >It sounds very misconcieved to me. Surely there will be only one logic
> >engine that executes one programme in it's own internal instruction set
> >(Somewhat analogous of a CPU. A CPU does not run BASIC or C or RLL, it
> >runs only it's own instruction set or machine code). Yes PLC manufacturers
> >do make and sell different "processors" for different languages but does
> >that make it the correct thing to do? Surely the language (RLL, C,
> >function block, etc) is a userland thing only and will be compiled by the
> >programming enviroment into and executable for the logic engine to
> >process. Result: one logic engine and lots of languages for developing the
> >application (AKA KISS).
>
> I do not agree!
>
> Everything in ladder (LD) of function block (FBD) is translateable
> to and from instruction list (IL) possibly also structured text
> (ST) but I am not entirely that sure here.
> Grafcet (SFC) is easily translateable to the oter languages but not
> as easily translated back (it is possible but not if anyone have
> made some certain changes)
>
> All this is easily solved by the same logic solver from some kind
> of byte code, and this will be really fast
>
> However, translating SFC to the same byte code will work, but it
> would be a *lot* faster to run this from another logic solver
> specially written for SFC.

Ok, since I don't know what SFC is I will, provisionally, conceed this point for this language. Although I don't see why a special SFC engine would be faster. If it were then the SFC compiler to the traditional byte code is crap!!! or rather the optimiser. I suppose it may be that the byte code doesn't support the correct operations in which case we add the correct operations. I just can not see why a special engine would be a LOT faster.

Still without knowledge of SFC I can argue no further and must conceed.

> Calcualting a PID loop could also be done from the samy byte code
> but that one would also be a *lot* faster if compiled (from C) to
> the processors own machine code handling the complete PID algorithm
> just reading and writing the I/O:s etc.

This is not a logic engine it is I/O implemented in software. The logic engine tells the PID engine some data and the PID engine does whatever it needs to. Basically the logic engine Outputs data to a software device.

Unless you mean the PID engine reads it's own data and does it's own thing in which case it is a controller in it's own right and only communicates with the logic engine for go / stop type data via the provided communication mechanisms.

> Result: some logic engines and some other engines for solving non
> logic stuff (for example PID loops, fuzzy logic, whatever) and a
> lot more languages for developing applications.

Languages for developing applications has got nothing to do with what a logic engine executes.

> Some people even want to make programs in C and compile them to run directly against the global
> memory (or whatever)
>
> If what you really thought was something like "compile everything
> to pure machine code and let the processor just run" that would
> definitely be the fastest but probably not the
> most practical thing to do.

See my other post on this. I don't think this is viable at all.


Dave West E-Mail: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Phil Covington on 21 January, 2000 - 2:32 pm

Simon:

While the details can be argued ad infinitum, I think that it is important that we get some code in our hands to look at before interest is lost in
this project. What you have outlined looks good to me, so I say go for it! It will probably take a few iterations, but someone has to get it started.

To All:

So far, from reading the messages here, we seem to have the following people actually coding or volunteering to code certain parts:

1. Drivers: Curt Wuollet -Modbus/TCP , Mark Bayern - Modbus or ProMux, possibly Ron Gage ? - AB Ethernet. I would like to work on Ethernet/PLC
Direct I/O and hacking the GE Ethernet stuff similar to what Ron is doing with AB.

2. Shared Memory (Virtual Memory) Management: Simon Martin

3. Logic Engines: Any volunteers?

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.

Comments?

Phil Covington
vHMI

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By R A Peterson on 25 January, 2000 - 12:59 pm

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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 3 February, 2000 - 11:36 am

I am writing a logic engine, see my earlier posts, which may or may not fit in with the project as a whole (it's Java based and some list members have stated an aversion to Java).

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

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

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

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Fri Jan 21 12:49:16 2000 Dave West wrote...
>
>> Calcualting a PID loop could also be done from the samy byte code
>> but that one would also be a *lot* faster if compiled (from C) to
>> the processors own machine code handling the complete PID algorithm
>> just reading and writing the I/O:s etc.
>
>This is not a logic engine it is I/O implemented in software. The logic
>engine tells the PID engine some data and the PID engine does whatever it
>needs to. Basically the logic engine Outputs data to a software device.

Right, the PID execution engine reads data from the appropriate data table file(s) and outputs the results to the appropriate files. By
doing it this way, if the PID execution engine really needs to deal directly with I/O, it can, by being so configures. however as I see it, the far more common application will be for the data table to be simply an interface to a login engine, which will then move data to/from the I/O data tables.

>Unless you mean the PID engine reads it's own data and does it's own thing
>in which case it is a controller in it's own right and only communicates
>with the logic engine for go / stop type data
> via the provided communication mechanisms.
>
>> Result: some logic engines and some other engines for solving non
>> logic stuff (for example PID loops, fuzzy logic, whatever) and a
>> lot more languages for developing applications.
>
>Languages for developing applications has got nothing to do with what a
>logic engine executes.

Fair enough. As long as this is transparent to the application programmer in _all_ ways. He/she should _never_ need to know that it is not their code that is actually being executed.

>> Some people even want to make programs in C and compile them to run directly against the global memory (or whatever)
>>
>> If what you really thought was something like "compile everything
>> to pure machine code and let the processor just run" that would
>> definitely be the fastest but probably not the most practical thing to do. <<
>
>See my other post on this. I don't think this is viable at all.<

i wouldn't do it either, but as long as they use the shared memory access routines we supply, then they should be able to do it. Now
whether they can get any users to accept it, thats a whole different question.


--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

-----Original Message-----
From: Dave West <davew@hoagy.demon.co.uk>
>
>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 was only concerned about code compiled directly to native machine language.

Ron Davis
Ron.Davis@synchrony.com



_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 21 January, 2000 - 5:34 pm

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.


/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: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Fri Jan 21 23:39:15 2000 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.

Are we building a PLC, or some sort of computer based home automation cotroler?

This is _BASIC_ PLC functionality!

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 21 January, 2000 - 6:23 pm

>> However, translating SFC to the same byte code will work, but it
>> would be a *lot* faster to run this from another logic solver
>> specially written for SFC.
>
>Ok, since I don't know what SFC is I will, provisionally, conceed this
>point for this language. Although I don't see why a special SFC engine
>would be faster. If it were then the SFC compiler to the traditional byte
>code is crap!!! or rather the optimiser. I suppose it may be that the
>byte code doesn't support the correct operations in which case we add the
>correct operations. I just can not see why a special engine would be a LOT
>faster.
>
>Still without knowledge of SFC I can argue no further and must conceed.

SFC is the same as Grafcet. If you (or anyone else) still do not know it it is a kind of "flow" chart.

You define the whole operation as some series of steps and conditions similar to this:
Consider you want to open a door:

+============+
||go to door||
+============+
|
+ at the door
|
+---------------+
|check if locked|
+---------------+
|
+--*-----------------------+
| |
+ locked + not locked
| |
+--------+ |
|find key| |
+--------+ |
| |
+ key found |
| |
+--------+ |
| unlock | |
+--------+ |
| |
+ door unlocked |
| |
+--+-----------------------+
|
+-------+
|open it|
+-------+
|


In a "normal" PLC every piece of tjis is evaluated every scan this is really not necesary since only a small number of steps
are active at once (in the example only one, but more than one can be active at the same time in other circumstances)

By only evaluating the conditions following active steps the amount of time could be drastically reduced.

>> Calcualting a PID loop could also be done from the samy byte code
>> but that one would also be a *lot* faster if compiled (from C) to
>> the processors own machine code handling the complete PID algorithm
>> just reading and writing the I/O:s etc.
>
>This is not a logic engine it is I/O implemented in software. The logic
>engine tells the PID engine some data and the PID engine does whatever it
>needs to. Basically the logic engine Outputs data to a software device.
>
>Unless you mean the PID engine reads it's own data and does it's own thing
>in which case it is a controller in it's own right and only communicates
>with the logic engine for go / stop type data via the provided
>communication mechanisms.

In some cases (in real PLC:S) this is done using the byte code for that particular PLC, not something necesary (but still possible) in the byte code used by "our" logic engine.

>> Result: some logic engines and some other engines for solving non
>> logic stuff (for example PID loops, fuzzy logic, whatever) and a
>> lot more languages for developing applications.
>
>Languages for developing applications has got nothing to do with what a
>logic engine executes.

Correct.

>> Some people even want to make programs in C and compile them to run directly against the global memory (or whatever)
>>
>> If what you really thought was something like "compile everything
>> to pure machine code and let the processor just run" that would
>> definitely be the fastest but probably not the most practical thing to do.
>
>See my other post on this. I don't think this is viable at all.

Perhaps not to you, but others may like it and there is really nothing stopping them from doing that (and should not be)

/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: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------



_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 21 January, 2000 - 7:55 pm

yes and yes and yes!

It is going to be a PLC, a computer based general controller AMD it will have the ability to online changes.


/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: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------


-----Original Message-----
From: MIME :stanb@awod.com [SMTP:MIME :stanb@awod.com]

Are we building a PLC, or some sort of computer based home automation controler?

This is _BASIC_ PLC functionaality!

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Fri, 21 Jan 2000, Stan Brown wrote:

> On Fri Jan 21 12:49:16 2000 Dave West wrote...
> >
> >> Calcualting a PID loop could also be done from the samy byte code
> >> but that one would also be a *lot* faster if compiled (from C) to
> >> the processors own machine code handling the complete PID algorithm
> >> just reading and writing the I/O:s etc.
> >
> >This is not a logic engine it is I/O implemented in software. The logic
> >engine tells the PID engine some data and the PID engine does whatever it
> >needs to. Basically the logic engine Outputs data to a software device.
>
> Right, the PID execution engine reads data from the appropriate data
> table file(s) and outputs the results to the appropriate files. By
> doing it this way, if the PID execution engine really needs to deal
> directly with I/O, it can, by being so configures. however as I see
> it, the far more common application will be for the data table to be
> simply an interface to a login engine, which will then move data
> to/from the I/O data tables.

Agreed.

> >Unless you mean the PID engine reads it's own data and does it's own thing
> >in which case it is a controller in it's own right and only communicates
> >with the logic engine for go / stop type data via the provided communication mechanisms.
> >
> >> Result: some logic engines and some other engines for solving non
> >> logic stuff (for example PID loops, fuzzy logic, whatever) and a lot more languages for developing applications.
> >
> >Languages for developing applications has got nothing to do with what a logic engine executes.
>
> Fair enough. As long as this is transparent to the application
> programmer in _all_ ways. He/she should _never_ need to know that it
> is not their code that is actually being executed.

Ohhh, absolutely!!!
It will be documented though.

<clip>

Dave West E-Mail: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Fri, 21 Jan 2000, Ron Davis wrote:

> -----Original Message-----
> From: Dave West <davew@hoagy.demon.co.uk>
> >
> >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 was only concerned about code compiled directly to native machine language. <

OK.

Something we all seem to have missed about compiling to native machine language is it is non portable. The programming tool needs to know what
kind of processor the PLC is running on and therefore should be disregarded entirely. Well for the immediate future anyway.

Dave West E-Mail: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Sat, 22 Jan 2000 johan.bengtsson@pol.se wrote:

<clip>
> You define the whole operation as some series of steps
> and conditions similar to this:
> Consider you want to open a door:
>
> +============+
> ||go to door||
> +============+
> |
> + at the door
> |
> +---------------+
> |check if locked|
> +---------------+
> |
> +--*-----------------------+
> | |
> + locked + not locked
> | |
> +--------+ |
> |find key| |
> +--------+ |
> | |
> + key found |
> | |
> +--------+ |
> | unlock | |
> +--------+ |
> | |
> + door unlocked |
> | |
> +--+-----------------------+
> |
> +-------+
> |open it|
> +-------+
> |

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.

> In a "normal" PLC every piece of tjis is evaluated every scan
> this is really not necesary since only a small number of steps
> are active at once (in the example only one, but more than one
> can be active at the same time in other circumstances)
>
> By only evaluating the conditions following active steps the
> amount of time could be drastically reduced.
>
> >>
> >> Calcualting a PID loop could also be done from the samy byte code
> >> but that one would also be a *lot* faster if compiled (from C) to
> >> the processors own machine code handling the complete PID algorithm
> >> just reading and writing the I/O:s etc.
> >
> >This is not a logic engine it is I/O implemented in software. The logic
> >engine tells the PID engine some data and the PID engine does whatever it
> >needs to. Basically the logic engine Outputs data to a software device.
> >
> >Unless you mean the PID engine reads it's own data and does it's own thing
> >in which case it is a controller in it's own right and only communicates
> >with the logic engine for go / stop type data via the provided
> >communication mechanisms.
>
> In some cases (in real PLC:S) this is done using the byte code for that particular PLC, not something necesary (but still possible) in the byte code used by "our" logic engine. <

Yes, I have implimented PID using ladder which was converted to byte code by the programming tool. Specifically MEDOC on a Mitsubishi A1SJH PLC. Not fast but good enough for the job.
I don't recomend this aproach though, I would have used a proper device (software or hardware) had it been available at a reasonable price at the
time.

> >> Result: some logic engines and some other engines for solving non logic stuff (for example PID loops, fuzzy logic, whatever) and a lot more languages for developing applications.<< <
> >
> >Languages for developing applications has got nothing to do with what a
> >logic engine executes.
>
> Correct.

I know 8-)

> >> Some people even want to make programs in C and compile them
> >> to run directly against the global memory (or whatever)
> >>
> >> If what you really thought was something like "compile everything
> >> to pure machine code and let the processor just run" that would
> >> definitely be the fastest but probably not the most practical thing
> >> to do.
> >
> >See my other post on this. I don't think this is viable at all.
>
> Perhaps not to you, but others may like it and there is
> really nothing stopping them from doing that (and should
> not be)

Hmm, You seem to know a way of getting a userland process to load data
(machine executable binary) over a communication link and run it in the
same process context. Please enlighten us.

>
>
> /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: johan.bengtsson@pol.se
> Internet: http://www.pol.se/
> ----------------------------------------

Dave West E-Mail: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 22 January, 2000 - 8:31 am

>> >> Some people even want to make programs in C and compile them
>> >> to run directly against the global memory (or whatever)
>> >>
>> >> If what you really thought was something like "compile everything
>> >> to pure machine code and let the processor just run" that would
>> >> definitely be the fastest but probably not the most practical thing to do.
>> >
>> >See my other post on this. I don't think this is viable at all.
>>
>> Perhaps not to you, but others may like it and there is
>> really nothing stopping them from doing that (and should
>> not be)
>
>Hmm, You seem to know a way of getting a userland process to load data
>(machine executable binary) over a communication link and run it in the
>same process context. Please enlighten us.

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.


/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: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Sat Jan 22 15:04:28 2000 wrote...
>
>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:

1. Continuo (process plant, power generation etc0. We might be able to shut it down, say once every 18 months or so.

2. Semi continuous (auto assembly line) can shutdown on weekends or maybe 3rd shift.

3. machine control. cab stop for short periods of these at the completion of a cycle.

I presently have mostly class 1 and 2 applications. I do work pretty hard on the class one apps to provide some sort of manual fail over
backup (free standing PID CMA stations), and motor start, and motor stop outputs, with local pushbuttons). This allows me to put the PLC in
program to create new data table files (something I want to be able to do online for ours) for short periods of time.

Obviously these are not hard and fast classes, but the lines between them blur. For instance my paper machines run 24x7 with a shutdown about every 3 weeks, so they fall somewhere between class 2 and 1.


--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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.


--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Sat Jan 22 04:47:22 2000 Dave West wrote...
>
>Something we all seem to have missed about compiling to native machine
>language is it is non portable. The programming tool needs to know what
>kind of processor the PLC is running on and therefore should be
>disregarded entirely. Well for the immediate future anyway.

A very good point. I for one want to be able to run this on X86, and PA-RISC.
--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Fri, Jan 21, 2000 at 03:23:37PM +0000, Dave West wrote:
> On Fri, 21 Jan 2000, Jiri Baum wrote:
>
> > On Thu, Jan 20, 2000 at 01:29:49AM +1030, LouisKriek wrote:
> > > Now, are we going to go that far that the LinuxPLC is going to run
> > > x86 op-codes. That is probably too big a jump at first.
> >
> > It's not a big jump at all - just output C code (with appropriate #line
> > directives) and call gcc.
...
> I struggle to see how we could impliment this. Consider the following.
> the PLC is running and we want to upload a programme from a remote device
> as we would with a real PLC. Our soft PLC accepts the programme as data
> and writes it into a data segment as defined by the Linux kernel (Code
> segments are not writable). How do we then tell the kernel that the data
> segment should now become a code segment and it can schedule it for
> execution.

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

Jiri
--
Jiri Baum <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

<clip>
> >Hmm, You seem to know a way of getting a userland process to load data
> >(machine executable binary) over a communication link and run it in the
> >same process context. Please enlighten us.
>
> 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!

Hmm, well, erm, Ok. I suppose it's reasonable if not very elegant.


Dave West E-Mail: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Sun, 23 Jan 2000, Jiri Baum wrote:

> On Fri, Jan 21, 2000 at 03:23:37PM +0000, Dave West wrote:
> > On Fri, 21 Jan 2000, Jiri Baum wrote:
> >
> > > On Thu, Jan 20, 2000 at 01:29:49AM +1030, LouisKriek wrote:
> > > > Now, are we going to go that far that the LinuxPLC is going to run
> > > > x86 op-codes. That is probably too big a jump at first.
> > >
> > > It's not a big jump at all - just output C code (with appropriate #line
> > > directives) and call gcc.
> ...
> > I struggle to see how we could impliment this. Consider the following.
> > the PLC is running and we want to upload a programme from a remote device
> > as we would with a real PLC. Our soft PLC accepts the programme as data
> > and writes it into a data segment as defined by the Linux kernel (Code
> > segments are not writable). How do we then tell the kernel that the data
> > segment should now become a code segment and it can schedule it for
> > execution.
>
> - 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.)

Doesn't bear thinking about yet does it.

Dave West E-Mail: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 22 January, 2000 - 11:36 am

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: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------


-----Original Message-----
From: MIME :stanb@awod.com [SMTP:MIME :stanb@awod.com]
>
>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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 22 January, 2000 - 11:36 am

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: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------


-----Original Message-----
From: MIME :stanb@awod.com [SMTP:MIME :stanb@awod.com]

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
LinuxPLC@linuxplc.org
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 stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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?
--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 22 January, 2000 - 1:08 pm

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: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------


-----Original Message-----
From: MIME :davew@hoagy.demon.co.uk [SMTP:MIME :davew@hoagy.demon.co.uk]

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

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 22 January, 2000 - 2:40 pm

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: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------


-----Original Message-----
From: MIME :stanb@awod.com [SMTP:MIME :stanb@awod.com]

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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 22 January, 2000 - 2:41 pm

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: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Scott Cornwall on 23 January, 2000 - 5:59 pm

> > >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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 24 January, 2000 - 4:22 am

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: linuxplc-admin@linuxplc.org [mailto:linuxplc-admin@linuxplc.org]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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 24 January, 2000 - 4:22 am

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: linuxplc-admin@linuxplc.org [mailto:linuxplc-admin@linuxplc.org]On
Behalf Of johan.bengtsson@pol.se

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
LinuxPLC@linuxplc.org
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 stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 24 January, 2000 - 8:20 am

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: linuxplc-admin@linuxplc.org [mailto:linuxplc-admin@linuxplc.org]On
Behalf Of johan.bengtsson@pol.se

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
LinuxPLC@linuxplc.org
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
Ron.Davis@synchrony.com



_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Jan Krabbenbos on 24 January, 2000 - 4:08 pm

> >
> > 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: jan.krabbenbos@wxs.nl
www : http://www.krabbenbos.com

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Jan Krabbenbos on 24 January, 2000 - 4:09 pm

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: jan.krabbenbos@wxs.nl www : http://www.krabbenbos.com

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 24 January, 2000 - 4:55 pm

johan.bengtsson@pol.se 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
LinuxPLC@linuxplc.org
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 stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Sat, 22 Jan 2000 johan.bengtsson@pol.se 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: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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 <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 25 January, 2000 - 7:30 am

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: linuxplc-admin@linuxplc.org [mailto:linuxplc-admin@linuxplc.org]On
Behalf Of Dave West

On Sat, 22 Jan 2000 johan.bengtsson@pol.se 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
LinuxPLC@linuxplc.org
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: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Simon Martin on 25 January, 2000 - 11:30 am

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: smartin@isys.cl

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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
jkirving@mosquitonet.com


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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
LinuxPLC@linuxplc.org
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 stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Simon Martin on 3 February, 2000 - 9:51 am

Hi Stan,

This is the view I have as well, but not just running different ladders, but also running different languages.

Debian GNU User
Simon Martin
Project Manager
Isys
mailto: smartin@isys.cl


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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
jkirving@mosquitonet.com

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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

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

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

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

Jiri
--
Jiri Baum <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

Ken Irving:
> Just to toss out a way to look at this, a lot of (file or device) locking
> schemes require cooperation or good-neighborliness, and can be trivially
> (though perhaps dangerously) overruled by a process with high enough
> permissions.

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

Enforcing permissions is the easy bit.

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

Jiri
--
Jiri Baum <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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

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

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

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

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

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

Agreed.
--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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

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

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

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

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

Jiri
--
Jiri Baum <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

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

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

--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

Oops, seems like we started on the same thing at about the same time...

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

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

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


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

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

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

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

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

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

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


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

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

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

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


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

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

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


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

The functions open_plc_file and close_plc_file are not real-time.

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

Jiri
--
Jiri Baum <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 25 January, 2000 - 2:23 pm

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: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------


-----Original Message-----
From: MIME :stanb@awod.com [SMTP:MIME :stanb@awod.com]
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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 25 January, 2000 - 3:30 pm

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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 25 January, 2000 - 3:43 pm

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: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------


-----Original Message-----
From: MIME :davew@hoagy.demon.co.uk [SMTP:MIME :davew@hoagy.demon.co.uk]

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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 25 January, 2000 - 3:44 pm

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: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------


-----Original Message-----
From: MIME :stanb@awod.com [SMTP:MIME :stanb@awod.com]

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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Jan Krabbenbos on 25 January, 2000 - 6:13 pm

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: jan.krabbenbos@wxs.nl www : http://www.krabbenbos.com

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Jan Krabbenbos on 25 January, 2000 - 6:13 pm

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: jan.krabbenbos@wxs.nl www : http://www.krabbenbos.com


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Jan Krabbenbos on 25 January, 2000 - 6:13 pm

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: jan.krabbenbos@wxs.nl www : http://www.krabbenbos.com


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Tue, 25 Jan 2000 johan.bengtsson@pol.se 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: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 26 January, 2000 - 1:21 pm

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: linuxplc-admin@linuxplc.org [mailto:linuxplc-admin@linuxplc.org]On
> Behalf Of Dave West
>
> On Tue, 25 Jan 2000 johan.bengtsson@pol.se 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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Willy Smith on 26 January, 2000 - 2:50 pm

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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 26 January, 2000 - 3:25 pm

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: linuxplc-admin@linuxplc.org [mailto:linuxplc-admin@linuxplc.org]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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 27 January, 2000 - 6:23 am

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: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------


-----Original Message-----
From: MIME :davew@hoagy.demon.co.uk [SMTP:MIME :davew@hoagy.demon.co.uk]

On Tue, 25 Jan 2000 johan.bengtsson@pol.se 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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

On Thu, 27 Jan 2000 johan.bengtsson@pol.se 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: davew@hoagy.demon.co.uk
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 27 January, 2000 - 10:52 am

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: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------


-----Original Message-----
From: MIME :numatico@sol.racsa.co.cr [SMTP:MIME :numatico@sol.racsa.co.cr]

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
LinuxPLC@linuxplc.org
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
ken@control.com


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 27 January, 2000 - 11:56 am

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: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------


-----Original Message-----
From: MIME :davew@hoagy.demon.co.uk [SMTP:MIME :davew@hoagy.demon.co.uk]
On Thu, 27 Jan 2000 johan.bengtsson@pol.se 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
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Rick Jafrate on 27 January, 2000 - 12:10 pm

Rick Jafrate wrote:
>
> Bully!
>
> rickj
>
> Ken Crater wrote:
> >
> > Dave West asked:
---- snip ----

So there is no confusion ...

Bully as in the Teddy Roosevelt sense.
Right On! Yes Way! etc...

regards

Rick Jafrate
Mitek

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Mark Hutton on 27 January, 2000 - 1:48 pm

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: linuxplc-admin@linuxplc.org [mailto:linuxplc-admin@linuxplc.org]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
LinuxPLC@linuxplc.org
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 <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
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 <jiri@baum.com.au>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

-----Original Message-----
From: Jiri Baum <jiri@baum.com.au>

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

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

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

Ron Davis
Ron.Davis@synchrony.com



_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Johan Bengtsson on 5 February, 2000 - 11:52 am

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

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

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

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

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

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

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

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


/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: johan.bengtsson@pol.se
Internet: http://www.pol.se/
----------------------------------------



_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Darryl L. Palmer on 7 February, 2000 - 4:53 pm

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


Darryl Palmer
Cleveland State University

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

Program panel? I think I am geting a real distate for RTL for this project.


--
Stan Brown stanb@netcom.com 843-745-3154
Westvaco
Charleston SC.
--

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Darryl L. Palmer on 7 February, 2000 - 4:56 pm

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

Darryl Palmer
Cleveland State University

_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc

By Curt Wuollet on 7 February, 2000 - 4:59 pm

Hi Darryl

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

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

Regards,

Curt Wuollet


_______________________________________________
LinuxPLC mailing list
LinuxPLC@linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc