Ideal PLC Programming Language and Software

  • Thread starter Bill Lydon, PLCopen North America
  • Start date
B

Thread Starter

Bill Lydon, PLCopen North America

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
[email protected]


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_safety.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
 
J
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
 
M

Michael Griffin

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

Dennis Patterson

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

Vladimir Zyubin

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

Bill Lydon, PLCopen North America

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
[email protected]
414-427-5853
 
P

Pankaj Gupta

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
 
M

Michael Griffin

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

Michael Griffin

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

Jeremy Pollard

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

Marc Sinclair

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
 
M

Michael Griffin

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

William Sturm

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

Jeremy Pollard

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

Michael Griffin

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