Control.com - Nerds in Control

As the North American Director of PLCopen I would like to receive as many thoughts as possible about what ideal PLC controller software would be. I plan to use this information to propose new PLCopen standards to improve IEC 61131.

I am asking for the thoughts, complaints, and ideas from control engineers to improve the IEC 6131 standard.

Standards always require input and ideas from users to improve them and have them broadly adopted. They also take time. Think about how long it took to get fieldbus standards where device from multiple vendors actually worked together on the same standard open network! The PLCopen organization is dedicated to improving the standard and users' are in the best position to recommend improvements.

The best example of this in the standardization of packaging controls using IEC 61131 and the PackSoft standards to standardize improve and simplify controls. PLCopen now has a standard set of function blocks that support this.

More user input is required to insure the standard continues to evolve and invite anyone to provide input. I will be compiling a report for the organization and anyone contributing will be provided a copy of the report. You can email or call me.

Bill Lydon
Director, PLCopen North America
A non-profit organization.
414-427-5853
blydon@plcopen-na.org


PLCopen Current Major Activities
Links provided for more information.

* Safety PLC Function Blocks
Textual introduction: http://plcopen.org/tc5.htm
Overview: http://plcopen.org/TC5/tc5_safety_overview.htm
Positioning against other standards: http://plcopen.org/TC5/tc5_safety_positioning.htm
The specification itself (.pdf): http://plcopen.org/forms/safety_dl_info.htm
Presentation: http://plcopen.org/TC5/plc_open_safety_pres_final.zip
BGIA improvement: http://plcopen.org/TC5/tc5_safety_v10_approved.htm
First PLCopen safety certification: http://plcopen.org/TC5/tc5_safety_certification.htm
Suppliers of Safety Certified Products: http://plcopen.org/TC5/safety_certification/compliance_suppliers_safet y.htm

* Motion
There has been a great deal of work in this area which is continuing. http://plcopen.org/TC2/Motion/tc2_motion_overview.htm

* Benchmarking
This is an important activity so that users can compare products from different vendors. http://plcopen.org/TC3/benchmarking.htm

XML
The PLCopen TC-6, XML standard is important because it is a way for users to easily share applications between multiple control vendors and work directly with simulation and CAD systems. The PLCopen XML standard enables the coupling of control applications to higher level tools such as simulation of the factory floor, and CAD tools. Applications interchange using XML between control vendor editors is finally a way to insure portability of applications between various control vendors products. XML is the software industry interchange standard for all of computing therefore it is the natural choice.
http://plcopen.org/tc6.htm

Bill,

Thank you for coming to the users to get this info. It is nice to know that someone wants to hear what we think, rather than just Rockwell, Siemens, Omron, etc.

I think one of the biggest steps that could be made is to require a standard file format, preferably XML based so that it is readable by user-built applications. A method of dealing with unrecognized extensions would have to be defined, or left up to the implementer of the various packages. With a standardized file format, however, it becomes much easier to cross-port
applications between systems. Also, users could create applications that may not be economically viable for the majors (CVS for ladder, anyone?).

--Joe Jansen

Joe,

Good ideas, keep them coming.

Thank You,

Bill Lydon
414-427-5853
blydon@PLCopen-NA.org

I think moving to XML for PLC programming would be a great move in control industry. This will also open up the huge oppotunity for 3rd party software vendors to write vendor independent Ladder Logic programming tools. Imagine a tool generating a PLC program which can produce the same result either in Siemens or Allen bradley. I know we got to deal with the hardware ramification too, but putting every thing in a standard way will certaily pave the path towards uniformity.

-Pankaj Gupta

In reply to Pankaj Gupta and Joe Jansen: PLCopen already *has* an XML format. Have a look at the end of Mr. Lydon's original message. He has a link to the documents for you.

However, note that XML is just a file formatting method. It's not magic. It's a tool that can be used between parties who want to inter-operate in an agreed fashion, but there is nothing about it that inherently makes what you are hoping for possible. It's not going to help you move programs between two different PLCs if the PLCs are incompatible. The parties have to work at making the systems compatible.

If you would like two good examples of this, consider SOAP, and consider Microsoft's new document formats. If you've ever tried to make two different devices talk to each other with SOAP and WSDL, you will probably found yourself hand crafting the XML packets to get the server to accept them. XML parser 'A' and XML parser 'B' have different ideas about what XML should look like (and of course you do all your testing against IIS-5, and find out that IIS-6 on the production server just spits it back out with a "server error").

If you want another wonderful example, consider Microsoft's new XML based document formats (the old "doc" and "xls" formats are now "obsolete"). They are just as closed, inscrutable, and proprietary as the old binary "doc" and "xls" formats (or even more so, as they are now encumbered with patents). But now they're "cool", because the formatting commands have angle brackets on the ends of them.

So yes, XML is a good tool to have in the software toolbox. But the wrench called "XML" needs a big long pipe called "good will and effort" over the end of it if it's going to do you any good.

Hello,
I think this is the key for standards themselves, too - you need good will and effort if it's going to do any good.

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.baum.com.au/~jiri

I agree. My initial idea was to require a standard file format. XML preferred, but the standard format was the key to what I was suggesting. This would require that at least a base set of commands would be entirely cross portable. If need be, define in the standard a list of instructions that must be supported as fully cross-compatible to comply. This would be updated somewhat regularly as technology advances.

--Joe Jansen

You mentioned the desire for a standrad XML format, and you can now get the PLCopen XML standard decuments for free. The PLCopen XML schemas and documentation as well as an introduction are available free to anyone on the internet at http://www.control-xml.com The downloadable files include a 156 page Explanation of the PLCopen XMLSchema, 58 page document on XML Formats for IEC 61131-3, and XML Schema files. A number of PLCopen member companies are supporting the XML standard including independent software suppliers 3-S, KW-Software, and KirchnerSoft.

You also might want to check out http://www.AutomationML.org for information on other open standards.

Bill Lydon
PLCopen North America
414-427-5853

I believe that there is presently a lack of trust in PLCOpen and a general cynicism about IEC-61131-3 because of a widespread belief that the standards process has been manipulated by the major vendors (see recent discussions here on this subject). I think if you want a genuine standard (which is something we really do need), you ought to first look at the process by which you arrive at it.

1) Everything should happen out in the open, and there should be no closed door meetings or backroom deals. All meeting minutes, discussions, and e-mails should be published on a public web site where everyone can read them (without being a member or having to register). The web site should permit public comment by anyone on the discussions. The software to run such a web site is quite common, so there is no new technology required to do this.

2) The resulting standard for each language should be a single standard with no options, levels, or vendor extensions. The decision of whether to Implement a particular language (IL, LAD, SFC, etc.) should be left up to each vendor, but all implementations should conform.

3) Standard function libraries should be defined, and should have to pass the same conformance criteria as the languages themselves.

4) Vendor extensions (to for example support special hardware features) should be restricted to separate optional extension libraries. Functions from these libraries should somehow be marked out as "non-standard" (perhaps by using a different naming convention).

5) A set of conformance tests should be created that everyone must pass to receive certification. This should be in the form of a freely available conformance software tool kit which everyone uses in their testing. Anyone (not just the vendors) must be free to repeat the same tests using the same toolkit on any product (made by anyone, member or not) and be free to publish the results.

6) All documents, specifications, and test tool kits must be freely available and re-distributable. The "re-distributable" aspect is very important. If you simply mark a document "all rights reserved", legally it means that you are restricting ("reserving") the ability of people to share copies of it and are limiting availability of it. People won't trust documents if you can make the only "legal" version of them disappear at will by simply taking them off your web site. There are plenty of existing copyright licenses which allow re-distribution of documents without giving up your control over the content.

7) Test tool kits (see above) and any other standards certification related software must have a free license (such as the GPL or similar) which requires distribution of source code. This is the only way to prevent some vendors or test labs from taking the original versions and creating proprietary versions that nobody else can trust or reproduce.

The Internet has changed the way people communicate. There is more emphasis today on transparency and the free flow of information in both directions. If you are genuinely interested in user input, you should be looking at how to communicate with the community at large though the entire standards effort by establishing a process by which to engage people. I don't think a survey and a private report to a committee will take us in that direction.

Agreed. You point out fundamental problems of the standard that make it very problematic for development and productive use.
--
Best regards,
zyubin

Michael,

This is exactly the kind of input I want to hear.

I would also like thoughts, ideas, and needs the standards need to address.

The goal is to improve control industry software based on the needs of users. My intent is not to address issues yet but to build a meaningful list of them, clarify the goals, and then determine how to overcome obstacles and achieve the goals. I want to get as much input from people as possible.

Based on the thoughts and ideas from you and others I will put together a set of goals for PLCopen North America and then have them reviewed by users. If we can keep everyone focused on the overall goal we will be moving in the right direction.

I have been involved in a number of other open standards developments over the years and at times it can be a very non-linear process. It is worth the aggravation and effort as the standards become reality.

Thank you,

Bill Lydon
Managing Director, PLCopen North America
blydon@PLCopen-NA.org
414-427-5853

In reply to Bill Lydon, PLCopen North America: The classic book on IEC 61131-3 is "Programming Industrial Control Systems Using IEC 1131-3" by R.W. Lewis. In the first chapter it states "as the IEC standard is not explicit about compliance requirements, any PLC vendor can claim to be IEC 1131-3 compliant by simply implementing one or two simple language features."

The book then goes on to state that your organisation was founded to try to define compliance levels for the standard. This book was published over 10 years ago and I don't see us any closer to a useful standard today than we were then.

If you are looking for "goals", then a primary one should be to get rid of "conformity levels". Having 26 different "conformity level" options for data types alone (which can combine to give over 67 million different incompatible versions) makes the concept useless. An implementation should either be compliant or non-compliant, but not "compliant" in one of 67 million different ways.

If none of the vendors really want to support a standard, then let's not waste our time discussing one. If one or two want to play at being dog in the manger, then let's not grant them a fig leaf by claiming they support a useless standard. If the vendors are interested in having a genuine standard, then lets concentrate on filling in the holes in the existing one, and coming up with compliance tests that are open and whose results may be reproduced by anyone.

Michael - you make some good points. As the former PLCopen managing director, I understand what Bill is trying to accomplish, and the attitudes shown here during this thread says it all.

PLCopen cannot change the standard, but can add extensions which are allowed for, as you point out in Lewis's book.

As another poster indicated - the vendors do not want to be able to have their users transfer code. No more captive audience?? That's not going to work.

Lip service in North America is all IEC-61131 has ever gotten.

But there is a lot of good surrounding IEC - but I'm not sure that being a standard is one of them as such.

Another poster talked about lower wages for designers and programmers... that's for sure. No money in clicking a button to change hardware platforms.

XML will work for some things, but no one will ever give up their graphical file formats, and export them so that someone else can use them.

ST is the only one that it can work with, and PLCopen can benefit the users by creating a routine to do just that! And validate it.

Bill - the users need the guidance of PLCopen. Based on the history I would suggest that the only guidance PLCopen would or should get from the user community is from those who join and get on committees.

Management by open committee as we see here will gain no traction. Opinions and attitudes are far too wide.

And tell me if Siemens would want to have their software convertible to B&R... not on your life!

Cheers from: Jeremy Pollard, CET The Caring Canuckian! www[.]tsuonline.com

Control Design www[.]controldesignmag.com Manufacturing Automation www[.]automationmag.com

Hi,
Is that the sort of work you want anyway?
When I first started programming PLCs we used arcane languages on purpose built programmers, now a lot of it is with pretty IDEs and wizards, even my children can hack PLC code.

The work has always been more than hacking code and anyone who can look at a machine sequence or process and make the kit do the work, will always command good money.

Marc

In reply to Jeremy Pollard: I agree with your point that an open committee is unlikely to provide any clear answers. However, an open committee is not the same as an open and transparent process. An open process is intended to let people see how and why decisions were made. An open committee on the other hand is usually either a recipe for all talk and no action or else a means for the organiser to dictate what they want while pretending to listen to others.

If PLCOpen wants input, let them post their objectives, meeting minutes, e-mails, drafts, etc. on a web site, and let people comment on them. A simple way of trying this out would be to use an ordinary blog that allows reader comments. Each meeting minutes or draft document could be a blog entry. E-mails could be published as weekly entries. If PLCopen is looking for comment on a particular issue, make that a blog entry. If they have nothing to say, they can invite someone else to write an entry for them. When something significant and new is on the blog, they can post a message here announcing it (talk to the moderator about that first though).

I don't use blog software, so I can't recommend any one in particular. However, there are lots of standard hosted blogs, so you don't have to set up your own server. Perhaps some of the other readers have suitable suggestions, or can point to particular blogs as good examples.

I see that Mr. Lydon has set up a Google Groups discussion list (which seems to have generated one reply in six months). The problem with saying "tell me what you think" and then sitting back to listen, is that you'll either get a resounding silence or you will get a cacophony of unfocused discussion. Instead, you need to initiate a focused discussion, and the best way to do this is to present a topic and ask people to talk about it. The way we do this on the Automation List is people write in about a problem, and we discuss solutions to it. For PLCopen, the discussion spark and focus would be blog entries about things which they are doing, or which they think people are interested in.

I think that PLCopen has a useful role to play, and I am glad that they are looking for input. However, I think that this input must be given some focus if it is to lead anywhere.

Hi Michael. One reply in six months tells the story of the lack of passion, interest, and 'a who cares' index.

The sharing of info idea has been flown before, and in order to look and have input was a function of being a PLCopen member. No member, no lookie!

Same with input... the paid membership are the only ones who have input...

I have always stressed the need for user input since PLCopen is largely seen as a vendor driven association, for marketing purposes, and self-gain (of the vendors). Users need to be involved for success.

I would also suspect that the membership numbers have been stagnant for a few years as well certainly in North America and Europe. China and Japan are a different story...

If users want to be involved, then join. Not sure there's anything public for users to do.

You can sign up for their newsletter tho... which would give you a bit of insight, but not much.

In reply to Jeremy Pollard (on the subject of openness in PLCopen):

It makes for an interesting contrast to see how things are done in the world of free software (operating systems, web servers, databases, etc.). In that field, most of the new companies and organisations which are successful are ones which make a special effort at being transparent and open to everyone.

They call it "building a community". Instead of having "information gatekeepers" in charge of limiting communications, they have people who work to increase it. Some of the older proprietary companies try to "fake it" with expensive marketing campaigns, but they don't succeed.

So, there are successful models centred on openness for both organisations and companies. The thing that has really made it possible is the way the Internet has brought down the cost of communications while increasing the speed.

If this can be done for things which are as deathly dull as databases and operating systems, then it ought to be possible for something as inherently interesting as automation. The fact that this forum / mailing list has been around for over 10 years certainly argues in favour of it.

Hi Michael,

I understand your plea for openness. One of the underlying assumptions in your plea is that open standards will be used by people with good intentions. It is an unfortunate fact of life that some people in this world don't have good intentions. How important is it for us to allow anyone with a modicum of knowledge to open a floodgate on a large dam, or perhaps manipulate an important valve in a city power plant? Some actions must be difficult to accomplish by the inherent design of the system. Building that security into an open system is a double edged sword. The open standard allows the entire world to find your security holes and therefore potentially allow you to fix them faster, but it allows the entire world to exploit them too.

Ken Stewart

Hogwash!
The worst security problems in the world are on closed systems. High security systems are auditable.

Regards
cww

In reply to Ken Stewart: Your comment is far off track for two reasons. One reason is that we are talking about the process used to discuss standardising the programming languages used to program PLCs. The connection between this and implementing the security in a process plant is not apparent to me.

Secondly, you are talking about "security by obscurity". You can look up details of this concept quite readily, but you will find that it is considered to be completely ineffective. Proper security systems do not depend upon secret protocols or algorithms. You will find that genuine modern computer security systems depend upon methods are are published, publicly available, and open for review.

Michael,

Here is my concern: where is the audit log? If someone breaks into a computer system and steals information or perhaps alters data, then that act is traceable. The caveat is that the wrongful act is traceable only on secure systems. Where is the audit log in a PLC? It doesn't exist. It doesn't even meet class D security standards (Orange Book, 1986).

If you have any illusions about secure operating systems, contact sources who monitor that stuff on a daily basis (McAfee, Symantec, SANS Institute, NIST, etc). If someone breaks into a PLC and causes damage, how do we track that? There are two goals in tracking intrusion. One goal is to punish the guilty; the other goal is learn from our mistakes in publishing faulty standards. My goal is the latter.

Ken Stewart

Ken - you raise an interesting point... I have wondered if the IEC-61131 'standard' should be a standard at all... but more a guideline.

It offers little from a standards point of view, but as a guideline that a vendors software can follow - there's a good fit.

The extensibility of the 'standard' and closed-door politics of vendors fails the user. Inherently it becomes closed again.

Things that make you go ummmmmmmmmmmmmm....

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

Control Design www[.]controldesignmag.com
Manufacturing Automation www[.]automationmag.com

In reply to Ken Stewart: I will repeat again, "security by obscurity" doesn't work. You will not find any proper modern security system that relies on it. "Faulty standards" are typically the result of incorporating proprietary security systems into a standard.

The reason why some proprietary security systems depend upon secret algorithms isn't to protect them from "hackers". It is to protect the companies which sell them from customers finding out how weak and shoddy they are.

Audit logs have nothing to do with security algorithms. They are used to find unsuccessful attempts at break-in, or break-ins by amateurs. Once a serious hacker has broken in, they would normally alter the logs so they leave no trace.

Finally, we are talking about open programming language standards. If you are suggesting that we should have a programming language standard that virtually nobody has seen, I would have to say that the IEC and PLCOpen have already beat you to this goal.

I'd like to disagree with Ken Stewart's statement that "we are talking about the process used to discuss standardising the programming languages used to program PLCs."

Why? I mean, not that it's unimportant, but I thought the question was what the standard should HAVE, not how to get there. In that vein, here's my wish list for PLC programming software:

1) Hiding the data model is far and away the most productive improvement PLCs have made. In other words, I no longer deal with register 40336 or N7:12. I just create an integer and go on with my life. Most modern high-end PLCs offer a hybrid approach, although some are still stuck in the dark ages. Siemens Step-7 comes to mind as an example that hasn't moved forward. RSLogix 5000 is a "pure" solution.


2) User defined data-types (UDT) is critical, including UDTs that contain UDTs, and arrays of UDTs that contain UDTs that contain arrays of UDTs.... you get the picture. Again, RSLogix 5000 gets this right. Modicon Concept tried but failed. Step-7 makes you think it will do it, but then you run into problems...


3) Array index by variable. Another critical feature. In Step-7, you can declare an array but it is useless; there's no way to say MyArray[MyInt]. Again, RSLogix does it right. Except that I'd also like to be able to say MyArray[2*MyInt+1].


4) Scoped variables. Nobody gets this one quite perfect, at least that I'm aware of. Step-7 allows me to have function-local variables, including typed input, output, and input/output parameters. But there is no way to scope variables to a SET of functions. In RSLogix 5000, you have global scope and "program" scope, allowing related functions to share variables, and those variables are hidden from functions in other “programs.” However, Logix has no concept of function-local, and doesn't typecheck input and output parameters. (The latest release of Logix adds some of this functionality, but if you use it you limit the use of the routine compared to "normal" routines.)


5) Calling functions/subroutines from functions/subroutines. Logix almost gets this right; you can call any routine from any routine, to any depth. You can even do recursion. But because of the aforementioned lack of function-local memory, recursion gets even weirder than normal. Step-7 will let you call a function from inside a function, but you can't pass a function-local value as a parameter, which is a SEVERE limitation, including preventing recursion. (Of course, recursion prevention is probably a good thing in general, but why the artificial limits?)


6) Automatic type conversion. Step-7 is absolutely EVIL in this regard. Why is a WORD different from and INT? Why can't I pass an INT to a FLOAT parameter? Logix (and C and Java and...) have no trouble with this concept.


7) Scheculed / periodic tasks. Haven't had a problem with this one in a while. Step-7 and Logix both have it, at least. It would be nice to formally declare it a requirement. The days of "one big ladder diagram" are over... or at least should be.


8) Conveniance functions. Akin to the C standard library, perhaps. Virtually all PLCs have math functions like square root and cosine, and of course motion functions have started to become de riguer. But where are hash tables? Dictionaries / maps? Sorted sets? Bounded queues and stacks? Quick sort / binary search? Logging? Time-stamping? Time/Date calculations?


9) Strings should be first class citizens, including functions for ASCII serial read/write communication. Most modern systems deal with strings, some far more elegantly than others. Logix comes close, but doesn't allow string literals in ladder. Plus, you have to declare a string type for each maximum size you want, which requires a download. That's not “first-class citizen” in my book.

-James Ingraham
Sage Automation, Inc.

Except for being compiled, A C implementation with good libraries and a "smart" IDE that let you mouse things into place and hid the glue code would answer all these and more. And I submit that it could be made easier to use than Step 7. Sounds like a 4GL for automation. Since the RLL "language" contains a very small number of tokens, this sort of thing should be very doable. :^) Place the token graphically, parse the tokens and generate the code. Simple. You could use all the native data types and I could write straight to the machine and skip all the GUI nonsense. Sounds like a plan. I'm only half joking, what folks can't seem to realize is that with Open tools and systems you _can_ do something like this. It's not even extraordinary, More like a college CS project. So, why labor with tools you don't like? Because you are wedded to proprietary hardware. Change platforms and the possibilities are endless. How do we get people to do it?

Regards
cww

I guess interest has waned in this topic, but I'd like to bring my 9-point list back up because I'm curious as to what other people think about my "requirements."

Did you think, "Man, this guy obviously hasn't seen XYZ's software, the most common in the world. It's like he's living in a cave!"

Or maybe, "Dictionary functions in a PLC? What good will that do? The reason we program in ladder is that our maintenance techs can understand it. I start throwing red-black tree-based sorted containers in there, and they won't understand a thing!"

I'm particularly interested in hearing about the use of arrays, especially looping through an array. I've write most of my code this way, and sometimes my customers will insist I rewrite it and unroll the loop.

Any Logix programmers missing the days of PLC/5?

Any Unity programmers wishing they could go back to ModSoft?

Any Step-7 programmers that share my feeling that Step-7 is a German plot to set the US manufacturing industry back by 30 years?

-James Ingraham
Sage Automation, Inc.

James - you are a computer geek right?? Great list and most have been missing for some time ..
Some I would agree with and others would be a non-event for most developers.

Not to say that the features wouldn’t be useful, just that most wouldn’t use them. RSLogix, Step 7 and Concept are ALL IEC-61131 based/compliant. Yet they are so different.. thus my argument that 61131 should not be a standard as such.

I am preparing a tutorial for the ISA conference on IEC-61131, and need some feedback re the use of the word (or inference) 'standard' as it applies to the IEC-61131 'standard'.

Please respond on the list or to me personally - either works for me. Thx in advance

Cheers from: Jeremy Pollard, CET The Caring Canuckian! www[.]tsuonline.com

Control Design www[.]controldesign.com Manufacturing Automation www[.]automationmag.com

3 Red Pine Court, RR# 2 Shanty Bay, Ontario L0L 2L0 705.739.7155 Cell # 705.725.3579

To Jeremy Pollard:

Jeremy Pollard >Not to say that the features wouldn’t be useful, just that most wouldn’t use them. RSLogix, Step 7 and Concept are ALL IEC-61131 based/compliant. Yet they are so different.. thus my argument that 61131 should not be a standard as such.<

And it is the case for ALL brands.. and have a look at CoDeSys (Smart Software Solutions GmbH - http://www.3s-software.com/) It seems to me, their invention activity (free fly of creation) isn't limited by any rules or conception. Very interesting software, but it is very hard to say it is compliant (in common sense) with the IEC 61131-3 standard.

Jeremy Pollard >I am preparing a tutorial for the ISA conference on IEC-61131, and need some feedback re the use of the word (or inference) 'standard' as it applies to the IEC-61131 'standard'.<

In my opinion, we need to divide the standard on 5 parts and exclude any mention about PLC from the title and text (because of the misleading connotations).

--
Best regards,
zyubin

In reply to Jeremy Pollard: IEC 61131-3 attempts to describe a set of languages useful for programming automation systems. A "language standard" describes a language in enough detail that a conformant implementation of that language can be created by anyone.

Two "conformant implementations" of a standard should produce identical results. The best test of whether a standard adequately describes a language is the degree to which independent implementations of the standard are similar. The further the implementations diverge from each other while still conforming with the standard, the less useful the standard is.

Quite frankly, there is another approach to the "standards" problem which seems to work much better. That is, everyone contributes to a soft logic system which can run on embedded hardware or on PCs, and everyone simply uses that instead of writing their own. License the system under a GPL license to keep the big vendors from shafting the smaller ones as well as each other. Now everyone is compatible because everyone is using the same software.

Customers will still buy PLCs from their preferred vendors because they still need PLCs and they aren't going to build them in their basements (or maintenance shops). The customers though will be able to load ladder programs into their PLCs without having to rewrite them for each different model.

Where's the downside to this? I can't see one. Unless of course, the problem would be that everyone would actually really be compatible with everyone else, which is perhaps the opposite to what some of the vendors really want.

I have seen a lot of "trick" programs done and usually think it is better to KISS (keep it simple stupid). Hell I have written some programs that I cannot even figure out what I was doing... (short term memory loss).

Europeans tend to write in general in my experience, really well software programs. (IE Siemens), but Americans tend to want to see the "inerds". So using bit shifting, or shifting arrays, etc. confuses the end user.

Now I argue sometimes that if you write it so that it does not breaks, then who cares.

I say ladder survives because the end user wants it.

Dave

In reply to James Ingraham: I will address each of your original points in turn below.

On Friday 15 June 2007 22:08:25 The AList wrote:
<clip>
> 1) Hiding the data model is far and away the most productive
> improvement PLCs have made. In other words, I no longer deal
> with register 40336 or N7:12. I just create an integer and go on
> with my life. Most modern high-end PLCs offer a hybrid approach,
> although some are still stuck in the dark ages. Siemens Step-7
> comes to mind as an example that hasn't moved forward. RSLogix
> 5000 is a "pure" solution.

What you are describing is "symbolic addressing". Siemens Step-7 does this for most variables (although not all). A well written S7-300/400 program should have most data local to each function block (FB). You just create the variable, define the type, and let the Step-7 software decide where to put it. The exceptions are mainly timers and counters, which are global resources. "M" memory should only be used as sparingly as possible for global variables.

This might not be exactly what you want, but Step-7 (and the S7-300/400) certainly has hanged in this respect from Step-5 and the S5.

> 2) User defined data-types (UDT) is critical, including UDTs
> that contain UDTs, and arrays of UDTs that contain UDTs that
> contain arrays of UDTs.... you get the picture. Again, RSLogix
> 5000 gets this right. Modicon Concept tried but failed. Step-7
> makes you think it will do it, but then you run into problems...

Your description of your problems with Step-7 are a bit vague. I've used blocks of UDTs with Step-7 to store structured data.

> 3) Array index by variable. Another critical feature. In
> Step-7, you can declare an array but it is useless; there's no
> way to say MyArray[MyInt]. Again, RSLogix does it right. Except
> that I'd also like to be able to say MyArray[2*MyInt+1].

With Step-7 for the S7-300/400, you have to use pointers. They do make this very difficult, so you are best off to write an FC to wrap up and hide all the pointer handling. The S7-200 is completely different and comes with simple and useable indirect addressing instructions.

> 4) Scoped variables. Nobody gets this one quite perfect, at
> least that I'm aware of. Step-7 allows me to have function-local
> variables, including typed input, output, and input/output
> parameters. But there is no way to scope variables to a SET of
> functions. In RSLogix 5000, you have global scope and "program"
> scope, allowing related functions to share variables, and those
> variables are hidden from functions in other “programs.”
> However, Logix has no concept of function-local, and doesn't
> typecheck input and output parameters. (The latest release of
> Logix adds some of this functionality, but if you use it you
> limit the use of the routine compared to "normal" routines.)

The only sort of variable scoping that would do what you want and be understandable would be nested scoping. Most PLCs though don't support the concept of nested subroutines.

> 5) Calling functions/subroutines from functions/subroutines.
> Logix almost gets this right; you can call any routine from any
> routine, to any depth. You can even do recursion. But because
> of the aforementioned lack of function-local memory, recursion
> gets even weirder than normal. Step-7 will let you call a
> function from inside a function, but you can't pass a
> function-local value as a parameter, which is a SEVERE
> limitation, including preventing recursion. (Of course,
> recursion prevention is probably a good thing in general, but why
> the artificial limits?)

I very much doubt that you can call "to any depth", even when doing recursion. Your PLC will be using a call stack, and there will be a maximum depth to the call stack even if it isn't documented. There will be either some arbitrary limit, or the PLC will crash when the top of the stack runs into something else.

The Siemens S5 had a call depth of I believe somewhere between 7 and 10. I never ran into that limit in practise. I imagine the S7-300/400
also has a set limit, although it may be deeper.

Recursion is one of those concepts that is taught in computer science as the "elegant" way of solving many problems. And indeed, there are
problems for which a recursive solution works the best. However, in most practical software people avoid recursive algorithms because the
dangers and limitations.

> 6) Automatic type conversion. Step-7 is absolutely EVIL in this
> regard. Why is a WORD different from and INT? Why can't I pass
> an INT to a FLOAT parameter? Logix (and C and Java and...) have
> no trouble with this concept.

There are three trains of thought with regards to variable typing. There is weak typing, strong typing, and dynamic typing. Each has it's proponents, and each has its benefits and downfalls. The people who created the S7 evidently liked strong typing.

As for "why is a WORD different from and INT?". Well a WORD *is* different from an INT. A WORD is an unsigned basic unit of memory, while an INT is a signed integer number. Some people had the same attitude when they were writing 'C' or 'C++' programs, and their successors ended up painfully debugging the those same programs when
they were ported to a different architecture where the word, integer, and pointer sizes were different. The 32 bit to 64 bit x86 transition
was particularly painful for some people because of this.

> 7) Scheculed / periodic tasks. Haven't had a problem with this
> one in a while. Step-7 and Logix both have it, at least. It
> would be nice to formally declare it a requirement. The days of
> "one big ladder diagram" are over... or at least should be.

This of course is also one of those features which is used extensively in a few application areas, and almost never anywhere else.

> 8) Conveniance functions. Akin to the C standard library,
> perhaps. Virtually all PLCs have math functions like square root
> and cosine, and of course motion functions have started to become
> de riguer. But where are hash tables? Dictionaries / maps?
> Sorted sets? Bounded queues and stacks? Quick sort / binary
> search? Logging? Time-stamping? Time/Date calculations?

What you really want is to be able to call subroutines written in a modern scripting language which has those features. That is, you want at its simplest something analogous to a CGI call in a web server, or in a more complex case a call gateway to a parallel process running a different language.

Adding these features into ladder or IL would create a horrible monstrosity, much in the way that attempting to graft modern features onto Visual Basic did.

As well as the language features, you are going to want the libraries which play a large part in making these modern scripting languages so useful. It would be better to simply allow an existing computer programming language (such as Python) to be accessed from a ladder program. This should be possible if the "PLC" was a soft logic system, even if the soft logic system was running on embedded hardware.

> 9) Strings should be first class citizens, including functions
> for ASCII serial read/write communication. Most modern systems
> deal with strings, some far more elegantly than others. Logix
> comes close, but doesn't allow string literals in ladder. Plus,
> you have to declare a string type for each maximum size you want,
> which requires a download. That's not “first-class citizen” in
> my book. <

The string handling could be done by a call to a modern scripting language as described in the previous point. Or do you really relish handling unicode in ladder?

Thank you, Michael Griffin! Great responses, and exactly the kind of thing I was hoping for!!!

I've cut out a lot to decrese the length.

MG: "What you are describing is "symbolic addressing".

Yep.

MG: "Siemens Step-7 does this for most variables (although not all)."

News to me. More on this later.

MG: "A well written S7-300/400 program should have most data local to each function block (FB)."

Also true of a well written program in ANY language.

MG: "You just create the variable, define the type, and let the Step-7 software decide where to put it."

Ah, but you're still exposed to WHERE it put it, within that function block. This is what I meant above when I was snarky about S-7 using symbolic addressing for most variables. So input, output, input/output, and local variables still have an offset from 0, and you can address those (with Lxxx, I think, though it's been a little while since I tried it.) True that local variables are much easer to deal with than globals.

Unfortunately, as I mentioned before, there is no way to share a variable amonst seveval FBs/FCs, so you have to resort to globals, since you can't pass a local variable to an FC inside an FC.

MG: "Your description of your problems with Step-7 are a bit vague."

Guilty as charged. The biggest problem I had was in making changes to an existing UDT, though I've forgotten some of the details now. Also, my "..." there was an attempt to lead into my point about array indexing.

MG: "With Step-7 for the S7-300/400, you have to use pointers."

I'm sure this is possible. My only access to Siemens technical support is through my local distributor. Within about 8 hours I had vastly out-run their expertise. By luck, I ran into some extremely competent Step-7 programmers on a job I was on for a while, and picked up a few things from them. However, only one of them knew how to use pointers, and he played with for five minutes before giving up and saying it was possible but he didn't have time to figure it out for me. So right now I can't do it at all.

MG: "The S7-200 is completely different and comes with simple and useable indirect addressing instructions."

Okay, I really DIDN'T know that. I've only worked with S7-300.

MG: "The only sort of variable scoping that would do what you want and be understandable would be nested scoping. Most PLCs though don't support the concept of nested subroutines."

I don't understand your answer, which makes me think I didn't write my initial point clearly. In pure Siemens language, let me try it this way:
Imagine being able to take a group of FCs and creating a new data table that only those FCs could access. Only FCs within that group could call others within that group. This is exactly what Logix does. But Logix DOESN'T have the local variables that Step-7 does.

MG: "I very much doubt that you can call [nested subroutines] 'to any depth', even when doing recursion."

Okay, okay, an exaggeration. I am prone to hyperbole. But 32 or 64 or some other number is essetially infinity in this case.

MG: "The Siemens S5 had a call depth of I believe somewhere between 7 and 10. I never ran into that limit in practise."

Yeah, in practice I doubt I've hit ten either.

MG: "In most practical software people avoid recursive algorithms because the dangers and limitations."

I don't actually WANT recursion. In fact, I was shocked when Logix let me. I was just pointing out that calling sub-routines from within sub-routines is a requirement for me on a PLC, perhaps with a bit of hyperbole thrown.

MG: "There is weak typing, strong typing, and dynamic typing. Each has it's proponents, and each has its benefits and downfalls. The people who created the S7 evidently liked strong typing."

S7 is beyond strong typing. I can't think of any other language so strict in it's conversions. Which backfires horribly, because I end up "casting" by accessing the memory directly.

MG: "As for "why is a WORD different from and INT?". Well a WORD *is* different from an INT. A WORD is an unsigned basic unit of memory, while an INT is a signed integer number."

Logix (and Java) solve this problem by not having an unsigned type and not allowing you to get a "basic unit of memory."

MG: "Some people had the same attitude when they were writing 'C' or 'C++' programs, and their successors ended up painfully debugging the those same programs when they were ported to a different architecture where the word, integer, and pointer sizes were different."

Yes. That's why Java defined the type sizes, and why any C/C++ programmer who works for me gets 40 lashes if he doesn't use the C99 type definitions.

Still, surely one should be able to compare a floating point number to an integer? Or a counter value to an integer?

Actually, disagreement is one of the things I was looking for. So my list of things *I* want in a PLC programming language inclues being able to pass an int when a float is expected, but others want a compile timer error. Fair enough.

MB: "[Scheculed / periodic tasks] of course is also one of those features which is used extensively in a few application areas, and almost never anywhere else."

Wow. That's surprising to me. Again, this kind of thing is why I wanted people to respond. I've only dealt with a few Siemens systems, but they all had one of those OBxx set to some time value or another to do SOMETHING. I guess my "pure" software background leads me towards ALWAY using scheduled tasks because I find it easier to think about.

JI: Conveniance functions.
MG: "What you really want is to be able to call subroutines written in a modern scripting language which has those features."

That is decidedly NOT what I want. Right now, in just about any PLC, there is a cosine function. I also want a sort function. (Actually, Logix has this.) And I want this to be a standard set of library functions, akin to the C Standard Library, the C++ Standard Template Library, and the java.* class library.

MB: "It would be better to simply allow an existing computer programming language (such as Python) to be accessed from a ladder program. This should be possible if the "PLC" was a soft logic system, even if the soft logic system was running on embedded hardware. "

Many systems let you do this, actually. SoftLogix, the PC-based version of ControlLogix, allows arbitrary DLL calls. So do many other "soft PLC" packages, which I assume includes Siemens. Siemens and some others also let you compile C code to call from ladder, even on "actual" PLC hardware. But again that's not what I want. And I'm not sure I agree with "better" either. I try to use individual, add, subtract, multiply, and divide blocks, instead of the Logix "Compute" block that allows you to type out an equation. This is essentially a "script." But it's generally harder for a maintenance guy to figure out at 3 in the morning.

MG: "Do you really relish handling unicode in ladder?"

Well, no, but I would damn sure like to be able to move a string literal into a string variable on a rung of ladder, much like I currently move an integer literal into an integer variable.

Good stuff! Somebody else jump in! The water's great! So the's hyperbole! I have more hyperbole than ANYONE ELSE ON EARTH!!! :-)

-James Ingraham
Sage Automation, Inc.

Michael..
I would suggest that the world of automation, being a very small cog in a big wheel, has a heavy support load, as well as big development costs which need to be funded. Thus the cost of most things..

While the 'community' may want to have openness, they are not willing to participate at the cost of business.

Thus the lack of any significant progress on the sharing of program structures from hardware vendor to hardware vendor .. IMHO - it will never
happen

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

Control Design www[.]controldesignmag.com
Manufacturing Automation www[.]automationmag.com

3 Red Pine Court, RR# 2 Shanty Bay, Ontario L0L 2L0
705.739.7155 Cell # 705.725.3579

In reply to Jeremy Pollard: I think we need to keep in mind what we are talking about here. We are talking about the process used to develop a better defined language standard. That doesn't involve actual product development or support.

I mentioned how things are done openly in many parts of the computer software world as an example of how this can occur. Yes, open collaboration can extend to the actual products as well, but that is a different story. A lot of discussion is actually centred around how existing systems should change in order to work together better. There is no reason why this can't happen with PLC standards as well.

I have given some suggestions in previous messages on how an open discussion could be conducted, so I won't go over that ground again. However, I would like to take the opportunity to point out that one of the major advantages of an open process is that it tends to take much of the market politics out of the discussion so that it can concentrate on the technical merits. When everyone can a party being obstructive for no good reason, it tends to cause the participants to modify their behaviour for the better.

As for whether the vendors *want* any progress in this field, well I would have to agree that you are likely correct on this for the larger ones at least. For the smaller vendors, they have more to gain than lose from this, so I don't see this as being a completely lost cause.

I will point out that in the computer world, large vendors such as Microsoft or Oracle can be just as obstructive about standards as any of the major automation vendors. That doesn't stop the rest of the industry from working together and making progress though.

I would suggest Michael, that due to the low volume in our biz, that smaller firms do not have the resources to carve the future. They may want to, but the big guns have much of the influence. In conversations I have had with smaller vendors, they are fighting to keep moving forward. Open source would be wonderful for them since it would improve their ability to make dough. But won't happen.

And a GM or someone of considerable clout would have to champion the cause - they did that with ODVA and Devicenet, and Controlnet. They tried to do it with IEC, and failed.

It has been abandoned as a cause.

Good effort tho!! :)

Cheers from: Jeremy Pollard, CET The Caring Canuckian! www[.]tsuonline.com

What we really need is for a couple dozen large automation users to get together and say they simply won't buy system that are crippled by incompatibility and proprietary excess. They don't need to specify what they will buy, that gets to be a nightmare and a path to failure.

They should simply state what they expect and let the vendors sort it out. It could be a simple test. I can put any PLC in this spot and it must run these programs without change and any PLCs A and B must connect to this ordinary Ethernet switch, and A and B must communicate and exchange these data. Simply what people might reasonably expect from all the advertising BS they've thrown around.

This is exactly what they are afraid of.

Regards
cww

Certain companies did that in the early days. OMAC was formed... and is still active, especially in the packaging arena. Normal control doesn't
benefit from the same involvement.

Ken Crater - host of this list - had a lab start up to test compatibility between devices, who SAY they are compatible. It's not around anymore...

Seems like it's Don't Care thing again...

Associations like PLCopen should provide the compatibility testing (as they do for the compliance levels), but who really cares if a product is IEC compliant?

You can't move the code anyway, and the interface is different albeit more the same than Rockwell vs. GE.

More importantly - does Siemens ST work in Rockwell's ControlLogix platform? i.e. copy and paste...

Will never get consensus or anyone to champion the fight... but the results of compatibility is what all are looking for.

I suggested such a task force for PLCopen in 2002. Wonder what people are afraid of?

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

Control Design www[.]controldesignmag.com
Manufacturing Automation www[.]automationmag.com
Supporting Cystic Fibrosis www[.]theoryanproject.org

In reply to Curt Wuollet: Expectations were supposed to be address by the IEC and compatibility was supposed to be addressed by PLCOpen. The problem that customers have in attempting to set the agenda is that they can only buy what is available for sale. This means that they can tilt the balance, but only a small bit at a time.

The real battle at this time though is not the language details, but the network "bus" that connects the CPU to the I/O, drives, MMI, and other devices. This is taking the central place in the scheme of things that the PLC "rack" once held. Whoever controls the bus, controls the industry. This is why all the various industry alliances are all vying to call themselves "open" while actually opening nothing.

If the major automation users that you mention want to influence things, then what they need to do is to get together and insist that they won't use a new Ethernet based network that isn't genuinely open. They should also make it clear that being open doesn't mean just tacking the word "open" onto the name of a private club. They could then pick one common genuinely open bus (or one for simple general I/O, and one for motion control and safety) and make it a requirement for all of their purchases.

Once the bus has been pried open, customers have more leverage to influence language standards because they aren't locked in by their installed hardware base.

In reply to Michael Griffin:

Regardless of the bus and hardware architecture, how can you have a piece of equipment with perfect IO but having software that weighs down the programmer? People will eventually go to home grown or community grown solutions if the industry doesn't supply a structured programming solution that begins to approach the power of C/C++ with a RTOS, and IEC 61131 is not cutting it (IEC is still based on a traditional PLC scan which makes doing sequence programming in structured text useless if you have to wait on IO, etc).

Case and Point, I develop using Epson RC+ with their robots and I can make changes, write, and rewrite code all day very quickly using their language (misture of VB and C like syntax). Their environment is a dedicated simplified (to the user) RTOS with up to 32 tasks executing at a 2ms clock. I'm running not only the robot but a sub-processing machine that has 7 simultaneously executing stations operating on parts that are in a rotary turntable. Doing the equivalent code using IEC 61131 would be a nightmare, but people do it because in some applications there isn't anything much better short of developing your own controller, which has maintenance nightmares.

If I could have Epson-like software in a PLC like package with a high speed backplane and flexible IO including high performance motion, I would buy it in a heartbeat and not look back! Why has nobody done this yet? Does the industry really think that the users are too stupid to use RTOS like features with structured programming in a PLC package?

I personally believe that Dealing with tasks, Mutual exclusions (MUTEX), and variable scope are much easier to understand than trying to debug a problem with a complicated ladder structure of similar complexity. I think that some people are just used to dealing with ladder problems and are putting up with it. Someone in the industry just needs the guts to do something completely different and trust that users will start to use it if it is available.

Currently I am using the Epson products (for robot machines) and Mitsubishi PLCs running IEC-Developer, programming mainly in ladder (non robot machines). The mitsu platform I use ladder function blocks to abstract common routines into libraries I have written. There is so much potential there, but it is fairly untapped.

My $0.02

~Ken

Moin Mr. Emmons,
moin all,

FYI, the IEC 61131-3 also includes Sequential Function Chart (SFC) in a textual form for the ST language (and all others). Usually SFC is regarded as the 5th IEC 61131 language by its own. Nevertheless, the standard clearly says that SFC is a "common element" of the other 4 languages. And it also tells how SFC in ST (or IL or...) should work.

This textual form of the SFC is rarely implemented. But it indeed can make sequential programming in ST much easier. http://www.61131.com to try out yourself.

Best regards,
Friedrich Haase

Ingenieurbüro Dr. Friedrich Haase Consulting - Automatisierungstechnik web http://www.61131.com/

Moin Mr Friedrich,

I am new to ST prorgamming and find it hard to find some example program in ST. I have found a few from PLCOpen and from 61131.com. But they are quite insufficent. Could someone please help me with some programs, it would great.

warm regards
hari

In reply to Ken Emmons Jr.: IEC 61131-3 does have a "structured text" (ST) language. The syntax is more similar to Pascal rather than C, but the ST language is there. I am not aware of any direct support in the ST language for multi-threading, but there isn't any reason why it couldn't be added (there are many examples of this in other computer programming languages). I suspect though that most ST implementations simply compile the ST to IL (instruction list) and the typical PLC is NOT a real-time platform.

The real problem with IEC 61131-3 is that it doesn't define things closely enough to produce a worthwhile standard. As noted previously in this discussion, just about any PLC can call itself "IEC compliant". PLCOpen has tried to deal with this via "compliance levels", but there are so many of these levels and options that it didn't really solve anything.

My point about the network I/O "bus" was that with the traditional PLC, the software, CPU, and I/O have been inextricably linked together. A genuinely open "bus" would separate the software and CPU from the I/O, allowing options such as you desire to exist. While at present it is theoretically possible to build such an open system, the market is so fragmented with proprietary (or pseudo-proprietary) network systems that is it difficult for systems such as you describe to exist outside of niche markets.

In response to Michael Griffin:

I have used Structured Text before, and have not found anyone who really supports it natively in a high performance round robin RTOS like fashion, as you suggested. Most replies from automation vendors are something like this:

"Structured text is great for doing calculations."

Then I ask: "What happens when you wait on an input in a while loop"

"Well, it depends; if you wait long enough, you'll trip the watchdog timer".

Which, as you know, means the structured text language must complete any while loops in one scan time.

So really, to me, the IEC specification dances around implementation because it does not want to break the pre-existing infrastructure of the PLC, which is natively executing the manufacturer's instructions, and everything is compiled down from that. I think Rockwell is the exception where their compiler actually will generate better code than an old ladder Instruction languages, but they really don't support multithreading in the RTOS fashion.

While I still don't agree that the bus architecture is key to improving the software design, I do believe that a truly open bus can open doors to the future. Having a high performance open bus (that you don't have to pay ridiculous money for the specs) *could* potentially allow a startup company to solve the software issues by implementing a magic black box with a few communication ports and some kick@$$ software. Maybe this is the future.

~Ken

I think what you up against is what PLCs are made for. The intent was and is to provide a simple way to implement a large percentage of industrial control tasks. And they do that fairly well. Not as well as in the past, but they do cover a lot of the scope of industrial control where you need mostly logic, mediocre analog, and very limited networking. Most are reasonably approachable and usable by those who are not programmers as such, but use the programmability as a means toward the end of making something happen.

From a sophisticated computer engineering viewpoint they are Pathetic Little Computers and anything that can be done with them can be done far more elegantly, efficiently and in volume, inexpensively with a custom design and software written for the purpose. That is what a lot of embedded computing is about.

If one had the access, you could certainly throw away the firmware and software that make the microprocessor and assorted logic a PLC and run whatever pleases you that the available resources permit. In fact you can now buy "bare" PLCs where you can roll your own system software. Some look like a PC as far as programming is concerned and they would seem ideal for what you are talking about. They do tend to be pretty spendy compared to most PLCs but are also usually far more powerful to accommodate an actual OS or RTOS rather than a small runtime executive. I have kept an eye on these as potential containers for a Linux PLC.

But far from the software weighing the programmer down on commercial offerings, I think it's much the other way around. The majority of people who do things with PLCs seem to _like_ RLL and adamantly resist any change.

It's a very pragmatic way of doing things and has several practical advantages that most proposed replacements simply don't. This is coming from someone who would much rather write C to solve certain problems and would love to have the facilities of an OS (Linux) at my beck and call. I can, and have, controlled machines both ways and find them somewhat complimentary. Anything I can do with say, a Micrologix standalone is probably not a candidate for anything else as a practical matter.

A large PLC system that requires coprocessors and a lot of auxiliary equipment probably is. A sorting conveyor system may be done either way. If it requires a dozen serial bar code readers and an interface to enterprise software, PC control will probably be a lot cheaper and easier. Many systems now include a PC anyway. These would obviously warrant a look at doing the whole thing with the PC.

Anything with lots of analog or video or networking or computation is really outside the PLC scope and gets far more expensive and the performance is really abysmal compared to using a PC or other general class computer. And I am familiar with several large systems where the PLC paradigm was stretched and abused to the point where all the practical advantages were lost.

The cost of using PLCs beyond their no-brainer scope can be astonishing and it would almost certainly be cheaper and easier to do with other computers and more appropriate software. And in many cases it would be as easy to diagnose, repair, and expand. A really large PLC program with vast portions written in IL and spread among several processors is often more complex and inscrutable than a well structured C program to do the same job on a single large processor. PLCs are great where they are at their best. Outside that envelope there really is no comparable packaged product (DCS excepted)

My choice would be PC control with Linux with the soft realtime and scheduling enhancements and cooperating processes. It's a very good choice and you can do multithreading and scale to meet any conceivable need. But, run of the mill, mostly logic applications will be done with RLL for the foreseeable future.

Regards
cww

Thx Curt ... interesting insight...

Cheers from: Jeremy Pollard, CET The Caring Canuckian!

The only thing PLC Open needs to address our needs is obvious and totally lacking. That is: An interest in being truly Open. They want to be the single entity to _control_ the "openness".

That is, also obviously, exactly the same as a single company maintaining control if the motives are the same, which it seems they are. The ideas of maintaining absolute control and opening something are contradictory and mutually exclusive. That's why every automation entity I've seen with OPEN in it's name can safely be taken to mean the opposite. That's not to say that even industry consortia could not actually Open something, merely that, so far, it is _not_ their intent. To understand their intent is reasonably easy, simply follow what you have to do to implement.

The licensing and compliance requirements are, the epitome of closed and make the use of Open in the name unethical and misleading at best. And it is ridiculous to call anything that depends on patented hardware or software Open. Or closed or single sourced software. To use the word Open as a marketing gimmick for these is fraudulent.

The most "open" thing I've seen so far is modbus.org and they are still gingerly feeling their way along. I have to do some silly clickthroughs, but I can actually read the specs and write an implementation for any hardware without their blessing and with some small confidence I won't get a cease and desist order for my effort. Not really Open, but enough to be useful. The others, IMHO, cross over the line as deliberately misusing the word Open. Not a popular view with the vendors perhaps, but it is eminently defensible. They should accept it as input from someone who has experience striving to achieve openness and maximize utility to the public.

Regards
cww

Great dialog guys. Open is as Open does...

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

In reply to Curt Wuollet: It would be interesting to see if we can compile a list of automation organisations that use the term "open" in either their name or their self-description. Here's my list:

PLCOpen - We've discussed this here.

OPC - They claim "OPC is open connectivity via open standards." Specifications are available to members only.

If we look at the major Ethernet based industrial protocols:

ODVA (Open Device Net Vendors Association) - Covers Devicenet, Ethernet/IP, CompoNet. You must be a paid-up member of the organisation to use the specs.

PI (Profibus and Profinet) - They claim "Profinet is open and non-proprietary, and may be freely used by anyone, even non-PI companies". However, all the specification documents are restricted to members only.

EtherCAT - They claim "EtherCAT is the open real-time Ethernet network". Specifications are available to members only.

PowerLink - "The open association in the field of deterministic real-time ethernet". They claim "ETHERNET Powerlink is an open protocol. It can be used by anybody without license costs or obligations." Specs are 250 EUR for non-members, but there don't seem to be any obvious restrictions (I haven't read the fine print though).

Modbus-IDA - You mention these as being the most "open" of any you have dealt with. The specs are readily available, as most people are aware.

So, most organisations seem to believe that "open" means "keep out." The exceptions seem to be Modbus and perhaps PowerLink. Does anyone have any other examples they would like to mention?

Well done Michael. We will add to the list... just having my Wheaties. :)

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

This reminds me of a few years ago when I had an idea to develop some simple products using a popular motion bus standard. If I recall correctly, the silicon was available at a reasonable price from a third party. The problem was that the specifications and certification process made the cost of developing a prototype way too costly for a hobby business. I couldn't have made my money back unless I charged huge amounts for the product, which of course I was trying to avoid.

Bill

There is no membership cost. A membership is required to get detailed specs for EtherCAT - necessary to manage compatibility. The ETG (EtherCAT Technology Group) is huge, by far the largest of its kind.

If any readers are at the Hannover fair next week, check out the EtherCAT booth. The performance and number of interoperating devices is far beyond anything you can imagine.

Robert B. Trask, PE
Los Angeles, CA

In reply to Robert B. Trask, PE: Compatibility is something that you would normally handle through trademark. That is, permission to use a trademark
name or logo (e.g. EtherCAT) would normally depend upon having that product pass a conformance test. Restricting availability of specifications does
nothing to manage compatibility - that is just a form of "security by obscurity".

The EtherCAT organisation also claims their network is covered by patents, although they do not specify what those patents might be.

I've begun to hear some buzz about powerlink, I'll have to look into it if you can get any information for free :^).

The really galling part of all this is that these folks obviously know that customers want "open". They wouldn't throw the word around if they didn't think it valuable and something to be desired.

But, the founders list usually includes the stalwarts of proprietary excess and they clearly don't want to actually, really, open anything. I don't have a philosophical problem with that, I guess, they can run their businesses as they see fit. It causes huge numbers of practical problems, but they can be judged by that. My issue is that they intend to fool people into believing that their stuff is now Open and quite often succeed. I can't count the number of
times someone has called Windows open or told me that they are using OpenXXX or XXXOpen and asked
why they can't simply hook things together. And their anger is totally misdirected when you acquaint them with reality.

I really try not to waste time with the deluded anymore. It's like teaching a pig to sing. It
wastes your time and _really_ annoys the pig. The only thing that seems to work is simply to show what can be done with a truly Open system and then explain what you have to buy, license, and track and who you are completely dependent on, to do it with proprietary products if it can be done at all. People will accept the systems that let you do the job if you let Open sell itself.

It is one of my most puzzling questions why people so fiercely defend their malefactors.

Regards
cww

In reply to Curt Wuollet: From what little I have read about Powerlink, it seems to be mainly oriented towards motion control (servos and VSDs). It does do digital and analogue I/O as well, but the main emphasis is motion control.

Powerlink supposedly does real time multi-axis coordinated motion control using standard unmodified Ethernet. I imagine that to do this though, you would need to be working with an RTOS that is capable of keeping up with this. It can't do this with as many axes as Profinet (which doesn't use standard Ethernet for this), but the range it is capable of would probably cover 99% of all real world applications (and 100% of any that I have dealt with). They are apparently working on a new version that will incorporate hardware timing to extend the capabilities in this area (hopefully this will remain an optional feature).

Ethernet-Powerlink seems to be cooperating with CAN-Open, and it appears that Powerlink will be the Ethenet network of choice for many current CAN-Open vendors.

If you wish to talk to the Powerlink people, you might discuss if it would be possible for you to write a GPL'd driver (or module or whatever you want to call it) that is intended for people who want to do PC based control with servo drives (as opposed to deeply embedded applications which link multiple drives together). In this case, you many need only a small part of the spec.

Another party you might want to talk to is Baldor. The "technical specs" document for their "MicroFlex e100 ETHERNET Powerlink AC Servo Drive" has a fairly good overview of Powerlink. Baldor also has "Active-X" controls which are intended to allow PC applications to talk to the drives to perform certain simple actions. I don't know if the protocol in this case is based on Powerlink, or if it is a separate Baldor-only protocol.

Just a thought, the PC industry has had standardized hardware for some time and it hasn't affected their wages as far as I can see. You write programs in C or Basic or whatever, and they run on most any PC.

Bill

I've been programming PLCs for 25 years now. I'm waiting for the day when a PLC is a generic of the shelf item, where all items cards/bases/processors are standardized like PCs.

Once you have chosen your off the shelf processor and cards, you can than download the programming OS of your choice.

All of this has I am sure a very noble intent. However, companies are in business to make money. An open 1131-3 standard would not really be intheir best interests. Take A-B for example, just about for every piece of hardware you buy, there are corresponding software packages. I would very much like to see a standard, but it is pretty much an exercise in futility. I have used most of the supposedly IEC 61131 compatible platforms. They most usually comply to most of the standards.

I personally like Unity by Scheider. It is Object Oriented, and if used properly can assist in deployment.

If we were stuck with only 100% compliant solutions, where would the innovators go?
I have been programming PLC's for over 25 years, if you know what you are doing, moving from one type to another is NOT difficult.

Look at C++. It is a standard, the same for C. But do all compilers that are compatible work the same way?

The WORST caveat for a simple single unified programming protocol?????

WE ALL SEE OUR WAGES DROP DRASTICALLY!!!

First off, i agree with most post to this already, As I am a programmer myself for multiple platforms the most annoying thing I see is communications protocols. The industry needs to pick a safe, fast, reliable, and open protocol. Such as ethernet tcp ip.

A few companies adopted this and i think its going very good, considering the wiring and equipment cost is low and not much of a design head ache. schneider for one has taken this initiative very far.

As for the programming language itself, I think its fine the way it is. Every company has their own interface and design, which what makes competition the way it is and how it should be. (may the best designer win) IEC and 984LL is still the same, its just a different feel from one software to the next.