Michael Griffin wrote:>
> Something which really hasn't been mentioned too much is that
>if a variety of different hardware ran the same "soft logic" system the end
>customer would be able to separate the issue of what hardware to use from
>what software to use.

At the Instruction List level, most of the major PLC's appear to offer much the same capabilities, even though their architectures differ (S7 is based on a 2-register model, etc). There appears to have been no effort to define a standard for PLC's at this level (similar to JAVA bytecodes or Microsoft's Common Language Infrastructure, but doing so could provide a common target language for all configuration tools, Ladder, FB, SFC's, etc. The extra step of translating this common instruction set into each manufacturers own code
should be fast and easy to optimise for each hardware platform, though the ideal would be for different firmware which would interpret the standard language directly.

Both IEC61131 and IEC61499 do not define any standard target platform, and so instead of being able to use any configuration package of choice, we now have a proliferation of 'IEC-61131 compatible' programming tools, each usable only with one hardware platform, and each with its own version of Ladder, etc.

At the PC level, MS CLI is generating a lot of interest, with the MONO project aiming to host this on a Linux platform. A parallel effort for PLC's would appear to be very worthwhile. What are the technical difficulties? What machine instructions do current PLC's work with? At what level are the individual programming languages such as STL translated or interpreted?
What debugging/monitoring API's are used? Is any of this made available?

I am aware of the LinuxPLC project, but unless some common approach is taken, it would seem to offer Yet Another Learning Curve even if it is totally successful.

Hywel Thomas

CONTROL SPECIALISTS LTD, UK

 

At 15:24 01/11/01 -0000, Hywel Thomas wrote:
<clip>
>Both IEC61131 and IEC61499 do not define any standard target platform,
>and so instead of being able to use any configuration package of
>choice, we now have a proliferation of 'IEC-61131 compatible'
>programming tools, each usable only with one hardware platform, and
>each with its own version of Ladder, etc.

IEC61131 seems to have been a waste of effort despite the hard work put into it. It takes a genuine will of all parties concerned to make different products compatible. I don't think that will was there. It doesn't say much for a standard when one manufacturer can bring out two completely different product lines, and call them both "IEC61131 compatible".

<clip>
>I am aware of the LinuxPLC project, but unless some common approach is
>taken, it would seem to offer Yet Aother Learning Curve even if it is
>totally successful.

I think the LinuxPLC is taking a different approach. Instead of defining a standard to allow different implementations to become compatible, it is rather proposing to simply have only one implementation with anyone
being free to use it. In this way it can become a "defacto" standard.
I suspect that it would actually take less effort to simply create the LinuxPLC, than it would to create a useful PLC standard which all the major companies would agree to and comply with.


**********************
Michael Griffin
London, Ont. Canada
**********************

 

Hi Micheal. Hywel

I hope all parties agree I am qualified and justified to expound on this topic:^)

The approach we will most likely be taking is to provide a function set common to most implimentations so that porting to LPLC will be
relatively painless.

For example Generic Ladder Logic that would have features common to the popular flavors yet not necessarily duplicating any one set. Those specific features that are important to an individual can be added (best) or requested (perhaps).

I'm not really sure what to do with the IEC standards but it seems the same approach would be wise.

The reason I say that we will most likely do it this way is that if anyone were to contribute an entire clone of their favorite, we would very likely use that. This lets those with interest and
resources steer the direction to some extent while contributing to the common good.

I agree that commonality is simply not on the horizon from the major vendors. It seems that they must even implement standards in a non-standard way or with proprietary extentions. Our working world would be a much better place if they were to compete on compliance with what few standards there are, rather than product
differentiation.

I firmly believe that the MAT/LPLC project is the most powerful, efficient way of promoting change that is good for the industry even if we never achieve major market share. Since we are entirely
community supported, if we generate large amounts of interest for standards based, common sense, cross-platform, Open solutions, it would surely be good business for vendors to move in that
direction. It is unfortunate that many people see this as some sort of a negative, distructive, threat. I see it as the only effective way to break the deadlock and move things towards a more
customer oriented paradigm and higher volume model. The major vendors cannot do this as it would be disadvantageous to make the first move. We can start there as we have no legacy or installed base to worry about. And worst case, if they don't follow, you will still have an Open choice, and I can work with OSS prodcuts.

Regards

cww

 

Just a couple remarks:

Thomas:
You are absoluteluy right... Unfortunately, there is no such a thing as independent research activity... All user have to make decentralized
researches on the topic. Yes, there are articles about misuse of the standard(IEC61131-3)... but alas, for the english-customers they are either not available thru mainstream media or written in non-english "characters"... ... :-(

--
Best regards,
Vladimir mailto:[email protected]

 

Curt,
What I'm suggesting is not that LPLC implements a particular flavour of the IEC61131 tools, but that each language (Ladder, FB, SFC, etc) produces output for the same Virtual PLC engine, and that some consideration needs to be given to what features this VPLC needs. I know it's early days yet, but the first LPLC StepLadder compiler
produces 'C', while the beginnings of the graphical ladder editor interprets the ladder diagram itself (I think - please correct me if
I've got this wrong). If the IEC standards had defined a VPLC, we could now be be using RS-Logix or other favourite editor to produce code that would run on the LinuxPLC or hardware platform of choice. I have used the CADEPA package (from Famic-Eurilor) extensively (ICI in the UK standardised on this at one stage) which has a 'back-end' for all the popular PLC's, so I guess that they compile to an intermediate code which can then be converted efficiently to the
others. Before having a go at something along these lines myself, I'm just wondering if there is any experience out there of this approach.


Hywel Thomas

Control Specialists Ltd, UK

 

>What I'm suggesting is not that LPLC implements a particular flavour
>of the IEC61131 tools, but that each language (Ladder, FB, SFC, etc)
>produces output for the same Virtual PLC engine, and that some
>consideration needs to be given to what features this VPLC needs. I
>know it's early days yet, but the first LPLC StepLadder compiler
>produces 'C', while the beginnings of the graphical ladder editor
>interprets the ladder diagram itself (I think - please correct me if
>I've got this wrong). If the IEC standards had defined a VPLC, we
>could now be be using RS-Logix or other favourite editor to produce
>code that would run on the LinuxPLC or hardware platform of choice.
<clip>

I didn't understand you the first time - but now I see what you mean. Yes, a standard softlogic system can be based on a virtual machine
(PLC). When I first read about IEC 1131-3 (as it was known then) several years ago, I had assumed that this was going to be their approach.
Unfortunately, this is not what happened in the end. Instead each manufacturer tweaked their existing system as little as possible and called
it "IEC 1131".

Virtually every PLC that I have worked with seems to have some sort of machine architecture. This is implicit in having bits, words, timers, counters, etc. to manipulate. The question though becomes one of how detailed the definition of this architecture should be. This in turn is related to what programming languages are to be defined. Lower level languages (e.g. instruction list) require more detail of the underlying machine to be revealed in order for someone to work with it. Higher level languages are less sensitive to this.

In the computer science field however, there are two software systems that are (were) particularly well known for being portable. Both of these (UCSD p-system and Java) took the approach of creating a virtual machine. The virtual machines of these systems were well defined enough that in both cases people were able to actually implement the "virtual machine"
in hardware as well as software. This is also the approach taken by several conventional PLC designs.

I think this method (a detailed virtual machine) has a lot of promise. A virtual machine offers lots of opportunity for hardware/software,
and size/performance trade offs in different applications.
However, I think that the system should still design in direct support for higher level concepts (e.g. subroutines and step and transition
structures for sequential function charts) rather than being too concerned with maintaining the purity of the virtual machine concept.

I haven't been examining the work in progress of the LPLC. What is the goal here? Is there any particular reason to take a different approach? Also, does anyone know if there were ever any serious proposals made for a virtual machine architecture for the original IEC 61131 standard?


**********************
Michael Griffin
London, Ont. Canada
**********************

 

Sorry If I missed the "jist" of this. I've got it now. We had talked about an IL approach which would be much like this with the interpreter determining the feature set. We decided separate solvers would be a good first pass. Your VPLC could be one of these and developed in parallel with the dedicated single language solvers. I'd be interested in what this would look like.


Regards

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned
Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.

 

I am not sure it would actually be desireable really. Does it matter if the code interpreting what you have entered are different for
different languages? as long as the language is the same and you can move it around as you like (on a source code level, ie at the ladder, FB, SFC, etc level). Consider for example ladder and SFC. While it is possible to convert SFC to ladder and execute it as ladder it would be much more efficient to execute it as SFC. Ladder, FB and IL is directly convertable to each other and should be if anyone cares to implement it, but SFC and structured text is somewhat more tricky to convert without making the code less efficient than necesary to execute, and in those cases you can not alwas make a useful conversion in both directions (at least not for SFC).

And since you can mix languages (ie have a main SFC program excuting other programs written in other languages at it's different steps) then
each language can be used for what it is good at.

/Johan Bengtsson

----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

 

> What I'm suggesting is not that LPLC implements a particular flavour
> of the IEC61131 tools, but that each language (Ladder, FB, SFC, etc)
> produces output for the same Virtual PLC engine, and that some
> consideration needs to be given to what features this VPLC needs. I
> know it's early days yet, but the first LPLC StepLadder compiler
> produces 'C', while the beginnings of the graphical ladder editor
> interprets the ladder diagram itself (I think - please correct me if
> I've got this wrong).

If I understand this thread correctly, you're talking about defining a supported instruction set for the MAT PLC; what flavors of contacts and
coils are supported, what Special Function Blocks are available, etc.

I don't think that's necessary. It's software, unconstrained by an underlying physical PLC architecture. Every conceivable instruction can
be supported, if somebody's interested enough to code for it. Treat it like the extensible programming language that it is; define a standard
mechanism for adding an instruction to the interpreter, and implement the entire of the basic instruction set using that mechanism. The only difference between a positive transition sensing contact and a latched 'set' coil is the subroutine in the interpreter that's executed when one is encountered in a rung, the data structure used to manage its current state information, the symbol that's used to represent it in a diagram, and the rules governing its placement in a ladder. (Note that the latter two of these four components are meaningful only to the GUI ladder editor / monitor, not the runtime executive.)

Essentially, *all* ladder instructions are user-defined special function blocks; the system just happens to ship with a set (or several sets) of
instructions that people already know. In fact, there's no reason why the MAT PLC shouldn't have a ladder instruction set for each of the RLL
flavors defined by the major PLC vendors. After all, if the idea is to get people to adopt MAT PLC in production environments, it pays to reduce the difficulty of the learning curve; I'd imagine people would be quicker to adopt the MAT PLC if their existing programs and programming skills transfer unchanged. Also, there is presumably value in each of the instructions supported by the proprietary PLCs, and somebody out there would like them implemented. It's open source; each instruction (set) gets added when it becomes sufficiently worth someone's while. (Actually, that's true even for closed proprietary commercial software. It's just that "worth someone's while" is measured differently.)

So my suggestion is to start with the basic handful of coils and contacts and timers, and concentrate on making the RLL interpreter an
easily extensible language that hard-codes only the file format for a program, and the rules for ladder traversal and I/O updates.

Regards,

Greg Goodman
Chiron Consulting

 

Greg Goodman <[email protected]> writes:

> I don't think that's necessary. It's software, unconstrained by an
> underlying physical PLC architecture. Every conceivable instruction can

Sort of. There does need to be enough of an architecure to support inter-opcode communication. Stack based, virtual register set, etc. Personally, I'd suggest stack based because that's a lot easier to use.

> be supported, if somebody's interested enough to code for it. Treat it
> like the extensible programming language that it is; define a standard
> mechanism for adding an instruction to the interpreter, and implement
> the entire of the basic instruction set using that mechanism. The only

MAT folks might look at Vmgen, "A Generator for Efficient Virtual Machines". It's GPL'd (important to the MAT project) and available at
http://www.compang.tuwien.ac.at/anton/vmgen/.

Here's a bit of top level description from the web site:

Vmgen generates much of the code for efficient virtual machine (VM) interpreters from simple descriptions of the VM instructions. It
generates code for executing VM instructions (with optional tracing), for generating VM code, for disassembling VM code, and for profiling
VM instruction sequences. A VM instruction description looks like this:

add ( i1 i2 -- i )
i = i1+i2;

Vmgen supports several techniques for writing efficient interpreters:
virtual machine interpreters, threaded code, combining VM instructions into superinstructions, keeping the top-of-stack in a register, scheduling the dispatch of the next VM instruction, and a couple of minor optimizations. Interpreters created with vmgen usually are faster than competing interpreters and are typically only a factor of 2-10 slower than the code generateed by native-code compilers.

Vmgen has special support for stack-based VMs (but it can also be used to advantage when implementing a register-based VM).

Dan Pierson

 

Something is doing the interpreting though. Why have a different interpreter for each language (IL, LAD, FBD)? And how would you do that? If
you have a rung of ladder followed by a rung of IL, how would you route those to different interpreters? Also, what if you want to toggle between FBD and ladder modes?
Using different interpreters also has a lot of potential for bugs. Each interpreter may do something slightly different to equivalent concepts for each language.
Also, the LAD and FBD are not stored in memory as a bunch of lines and boxes. Rather, you would need to use some sort of coded representation. Why not just use a common set of codes for all of them then (excluding SFC) and interpret that?


>Consider for example ladder and SFC. While it is
>possible to convert SFC to ladder and execute it as ladder it would
>be much more efficient to execute it as SFC.
>Ladder, FB and IL is directly convertable to each other and should be
>if anyone cares to implement it, but SFC and structured text is somewhat
>more tricky to convert without making the code less efficient than
>necesary to execute, and in those cases you can not alwas make a useful
>conversion in both directions (at least not for SFC).

I believe there was a discussion here on this subject a while ago. However, this is worth reiterating. I don't see ladder and SFC as directly comparable. SFC is more a way of organising a program, rather than the detailed program itself. Inside each SFC step, there has to be some way of specifying what the step (or transition) *does*. In other words, you could have ladder logic (or IL, or FBD) inside each SFC step.
In this sense, an SFC step is closer to a subroutine than a language instruction. The difference between an SFC step (transition) and a
conventional subroutine is that the SFC transition guides the flow of execution, while a subroutine is a static concept. Both though, can be containers for instructions.

>And since you can mix languages (ie have a main SFC program excuting
>other programs written in other languages at it's different steps) then
>each language can be used for what it is good at.
<clip>
What is more, I think you could use the regular ladder (or IL, or FBD) editor to edit the contents of each SFC step or transition. This means the user who is familiar with the ladder (etc.) editor has fewer new things to learn when starting to use the SFC system. The SFC editor would only worry about the relationships between the steps, and not what is going on inside them.

**********************
Michael Griffin
London, Ont. Canada
**********************

 

Actually I think FBD and LD (and IL, at least to some degree) is nothing but different ways to show the same information. That means the interpreter for those languages are best kept the same (as it is the same data to interpret anyway).

That doesn't mean you need to specify that the underlying code have to be the same on all systems, just that it should be interchangeable
at source level.

/Johan Bengtsson

----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

 

Hi Micheal

Michael Griffin wrote:
>
> At 10:29 06/11/01 -0500, Johan Bengtsson wrote:
> <clip>
> >I am not sure it would actually be desireable really. Does it matter
> >if the code interpreting what you have entered are different for
> >different languages? as long as the language is the same and you can
> >move it around as you like (on a source code level, ie at the ladder,
> >FB, SFC, etc level).
>
> Something is doing the interpreting though. Why have a different
> interpreter for each language (IL, LAD, FBD)? And how would you do that?

We are not interpreting but translating to C and compiling.


If
> you have a rung of ladder followed by a rung of IL, how would you route
> those to different interpreters? Also, what if you want to toggle between
> FBD and ladder modes?

Synchronize through the map. Both have access to points.

> Using different interpreters also has a lot of potential for bugs.
> Each interpreter may do something slightly different to equivalent concepts
> for each language.
> Also, the LAD and FBD are not stored in memory as a bunch of lines
> and boxes. Rather, you would need to use some sort of coded representation.
> Why not just use a common set of codes for all of them then (excluding SFC)
> and interpret that?

We do, the C library.
>
> >Consider for example ladder and SFC. While it is
> >possible to convert SFC to ladder and execute it as ladder it would
> >be much more efficient to execute it as SFC.
> >Ladder, FB and IL is directly convertable to each other and should be
> >if anyone cares to implement it, but SFC and structured text is somewhat
> >more tricky to convert without making the code less efficient than
> >necesary to execute, and in those cases you can not alwas make a useful
> >conversion in both directions (at least not for SFC).
>
> I believe there was a discussion here on this subject a while ago.
> However, this is worth reiterating. I don't see ladder and SFC as directly
> comparable. SFC is more a way of organising a program, rather than the
> detailed program itself. Inside each SFC step, there has to be some way of
> specifying what the step (or transition) *does*. In other words, you could
> have ladder logic (or IL, or FBD) inside each SFC step.
> In this sense, an SFC step is closer to a subroutine than a language
> instruction. The difference between an SFC step (transition) and a
> conventional subroutine is that the SFC transition guides the flow of
> execution, while a subroutine is a static concept. Both though, can be
> containers for instructions.
>
> >And since you can mix languages (ie have a main SFC program excuting
> >other programs written in other languages at it's different steps) then
> >each language can be used for what it is good at.
> <clip>
> What is more, I think you could use the regular ladder (or IL, or
> FBD) editor to edit the contents of each SFC step or transition. This means
> the user who is familiar with the ladder (etc.) editor has fewer new things
> to learn when starting to use the SFC system. The SFC editor would only
> worry about the relationships between the steps, and not what is going on
> inside them.

All of this is Open for anyone to implement, If you can code it and it works, I'll see it gets in the archive. This is where keeping the solver
modular is of value. If someone comes up with a great idea, it can plug right in. As I've remarked before, there is more than enough talent
reading this to make the best solution in the industry without question. We are providing the vehicle. All we need is your help and we all gain.
Wouldn't it be great to have the system _you've_ wanted?

Regards


cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned
Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.

 

>cww wrote:
>I agree that commonality is simply not on the horizon from the
>major vendors. It seems that they must even implement standards
>in a non-standard way or with proprietary extentions.

Yes, but that shouldn't prevent future OpenSource programming tools being used with their hardware. Our customers select their hardware PLC platforms based on reliability, cost, or whatever, and we typically have to deal with
S7, SLC500, Modicon, etc. Realistically, I don't see this changing for a long time, and when the LinuxPLC comes along, it will have to compete in
just the same way.

However, we are able to use a common SFC programming package that has a back-end for all of these platforms, so we don't need to learn Graph7, Concept or whatever. Its not ideal - new drivers and bug fixes are slow to appear, etc and its not OpenSource. If a considerable amount of effort is to go into producing Ladder editors, SFC tools, etc, I would like to be able to use these with my clients' choice of hardware as well. Targeting each of these on a common IL level seems one way of making this translation easier - and the skills required for generating graphical SFC editors is somewhat different to that for translating one IL language to another,
reverse-engineering download protocols, etc.

For standard PLC functions, the IL requirements are fairly straightforward, but whether a register/stack-based architecture like S7 (eg LD src1, LD src2, ADD, T dest) or a memory-based one like SLC500 (ADD src1,src2,dest) is best for translation I don't know (but would like to). Many thanks for all other comments, and the reference to VMGEN.

Hywel Thomas

Control Specialists Ltd, UK

 

> From: "H.W.Thomas" <[email protected]>
>
> >cww wrote:
> >I agree that commonality is simply not on the horizon from the
> >major vendors. It seems that they must even implement standards
> >in a non-standard way or with proprietary extentions.
>
> Yes, but that shouldn't prevent future OpenSource programming tools being
> used with their hardware. Our customers select their hardware PLC platforms
> based on reliability, cost, or whatever, and we typically have to deal with
> S7, SLC500, Modicon, etc. Realistically, I don't see this changing for a
> long time, and when the LinuxPLC comes along, it will have to compete in
> just the same way.

It does prevent future OpenSource programming tools being used with their hardware. The protocols are closed and recent legislation will
get you a long visit to Club Fed for reverse engineering them. The primary reason for closed protocols is to prevent competition. Now with UCITA, DMCA, and SSSCA, they won't even have to bother to sue you they can simply have you arrested. They now have the ultimate in lock-in/lock-out anticompetition tools. State sponsered software facism.

> However, we are able to use a common SFC programming package that has a
> back-end for all of these platforms, so we don't need to learn Graph7,
> Concept or whatever. Its not ideal - new drivers and bug fixes are slow to
> appear, etc and its not OpenSource. If a considerable amount of effort is
> to go into producing Ladder editors, SFC tools, etc, I would like to be able
> to use these with my clients' choice of hardware as well. Targeting each of
> these on a common IL level seems one way of making this translation easier -
> and the skills required for generating graphical SFC editors is somewhat
> different to that for translating one IL language to another,
> reverse-engineering download protocols, etc.

See above. If you want to use proprietary platforms you will probably be stuck with their tools as well. This is the purpose of proprietary
platforms and won't change as long as everyone blindly accepts it.

> For standard PLC functions, the IL requirements are fairly straightforward,
> but whether a register/stack-based architecture like S7 (eg LD src1, LD
> src2, ADD, T dest) or a memory-based one like SLC500 (ADD src1,src2,dest)
> is best for translation I don't know (but would like to). Many thanks for
> all other comments, and the reference to VMGEN.

Don't get me wrong, the idea of having a common IL for the HLLs is one that I have been pushing since the start. It's simply fantasy to expect
any cooperation from the majors. They are busy suing each other for much smaller transgressions than trying to hijack their hardware.

Regards

cww
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned
Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive
Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to
Linux.

 

I am not sure it would actually be desireable really. Does it matter if the code interpreting what you have entered are different for different languages? as long as the language is the same and you can move it around as you like (on
a source code level, ie at the ladder, FB, SFC, etc level). Consider for example ladder and SFC. While it is possible to convert SFC to ladder and
execute it as ladder it would be much more efficient to execute it as SFC. Ladder, FB and IL is directly convertable to each other and should be if anyone cares to implement it, but SFC and structured text is somewhat more tricky to
convert without making the code less efficient than necesary to execute, and in those cases you can not alwas make a useful conversion in both directions (at least not for SFC).

And since you can mix languages (ie have a main SFC program excuting other programs written in other languages at it's different steps) then each language can be used for what it is good at.

/Johan Bengtsson
----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------