Editor’s Note: IEC 61131-3 is a programming standard that emerged not long ago from the International Electrotechnical Commission, an international standards and conformity assessment body for all fields of electrotechnology. Packaging World brought together on a conference call three thought leaders from three different sectors of the packaging community—machine builder, academia, and machine buyer—to discuss the potential impact that IEC Standard 61131-3 could have on how packaging machinery is designed, manufactured, and maintained. Read what Joe Faust, electrical engineering manager at Douglas Machine; Ken Ryan, director of the Center for Automation and Motion Control at Alexandria Technical College; and Rick Van Dyke, senior group manager at Frito-Lay, have to say on this important issue of packaging machinery programming.
PW: Is interest in or demand for IEC 61131-3 something that’s happening at the end-user level, or is it something the machine builders are talking more about?
Faust: To be honest, we’re talking about it more than our end-user customers. We see it as a benefit to us more than anything else right now. As for our customers, I don’t know if it’s because we’re on the leading edge and they’re following or they’re just pushing back because of inexperience with it. But I do see some resistance.
PW: Is company size a factor?
Faust: It’s not a company size issue. The only thing I can think of is it’s a training issue. With all of the machines we’ve shipped recently to customers big and small, they all seem to ask for additional training from us about our programming and how we code things. But the knowledge they’re seeking is at a programming level more fundamental than IEC 61131-3.
PW: When you speak of benefits to you as a machine builder, if we were to list two or three of those, what would they be in order of priority?
Faust: The biggest thing would be a standardized code base. The benefit is that machines that are not necessarily identical, or that are programmed by multiple programmers, can wind up with very similar-looking code. I mean, as a standardization for us and for our service people, that really benefits the whole company. Things look the same and feel the same. Personal preferences are gone. There’s no re-doing of work. Once it’s done, it’s done.
PW: Other benefits?
Faust: Well, once past the initial investment, there is an ongoing savings when you’re dealing with tried and true tested code. This is similar to the whole OMAC message. The first machine programmed with IEC 61131-3 might include a delay or an added cost. But subsequent machines come down in cost pretty quickly. We’re even beginning to standardize certain mechanical features from machine to machine, and the ability to do that is driven by the software side. It’s a fundamental change in our approach to machine design. In the past, we’d look at a customer need and decide on a programming approach that began more or less with a blank sheet of paper. But now we rely more on standardized modules that can be applied to a new project because that code is already done. The program becomes a major part of design
development.
PW: Ken, what are you hearing about IEC 61131-3 where training is concerned?
Ryan: With software shouldering an ever bigger portion of the whole machine building process, we’re seeing an increase in the demand for training in that area. Speaking of software, I think Joe’s comments just now about how software is driving machine design is clear evidence that a prediction made about 10 years ago in a study out of the University of Munich has come true. The study observed that packaging machinery at the time was about 80% mechanics and 20% electrical and software, and it predicted that in 10 years those numbers would trade places. Joe’s description of the shift at Douglas suggests that the prediction was pretty accurate. Now that we’ve reached that stage of development, the next step is to develop that same look and feel Joe mentioned. For an OEM like Douglas, greater reliance on a standard like IEC 61131-3 removes some of the personality-driven code idiosyncrasies and lets the OEMs get down to what they’re really all about, which is designing a better, more functional machine, one that’s modular both mechanically and in its code.
PW: Would greater reliance on this kind of standardized programming boost the cause of interoperability, so that it would be easier to install new packaging lines where machines from multiple builders are involved?
Faust: So far it hasn’t. Achieving greater interoperability among varied machines has been more of a platform-based problem, where one vendor uses one control platform and another uses a different one. Synchronizing such machines is not easy. What’s missing is a network interface that’s common.
PW: Is "network interface" the same as "communications protocol?"
Faust: Yes, whether it’s Ethernet, or Profibus, or Ethercat, or SERCOS III. We can’t always connect the Ethernet to the Profibus interface, for example.
PW: I thought by now there was more agreement on communications protocols and the ability to freely move information along one or another.
Faust: Some information exchange happens slowly, some happens at a medium rate, and some has to happen at a very fast update rate. In that last category there has been little progress where commonality of network interface is concerned. The slow and medium stuff, there is some connectivity there through a third-party interface, but for the very high-speed stuff, I haven’t found anything yet that will connect two dissimilar systems at servo update rates.
Ryan: IEC 61131-3 focuses on bringing standardization, based on modular reusable components, to programming. But no matter how good we get at modular programming, if we have non-standardized platforms that can’t talk to one another, we still have a problem. The good news is that we are seeing some progress. Standards are emerging. Some are competitive, but if you compare the number of bus protocols that were around in the 90s to the number that have some degree of ascendancy today, it’s only a handful.
PW: At the last Pack Expo in Chicago, the OMAC booth had some displays that showed signs of improvement along the lines that Ken was just talking about. Joe, did you see any progress there?
Faust: There is a certain amount of interoperability happening, for example, at the SERCOS or Ethernet level. But I think everybody is kind of waiting to see what happens with Ethernet--where motion control is over copper rather than over fiber optics and the use of unique networks--before they say they have some really good connectivity there. Certainly there is some noise immunity you get with fiber optics, but with Ethernet comes more standardization and access to off-the-shelf components. There are pluses and minuses to each. We could have a four-hour discussion about that alone.
Van Dyke: True. I mean, fiber optics is great. But if you’ve got to have a proprietary network built just for that, then that’s probably not so good. But getting back to IEC 61131-3, like any move in the direction of greater standardization, it’s a positive thing. What worries me a bit is when I see the software on some systems getting bigger and bigger and more involved. End users probably have varying degrees of staff available, and at some end user companies they may or may not have the personnel to cope with that kind of detail. Some end users may be able to have an engineering staff where they can develop a clear point of view about PLC or control programming standards. Other end users may have a staff that can barely find time to buy equipment and get it installed, much less worry about the language inside.
PW: If there are end-user benefits to IEC 61131-3, Rick, are they right down at the plant-floor level, or is more at the supervisory or MES or ERP level?
Van Dyke: It wouldn’t be at the ERP level. That’s where PackML or ISA 95 standards come into play. IEC 61131-3 is more about the programming software for machines, so the only people that are going to see it are people that get "inside" the programming software for machines. That’s going to be controls engineers maybe, or it might be the plant maintenance folks who are trying to diagnose a problem or add a little bit of logic or something.
Ryan: I see a number of benefits for the maintenance technician. Number one is that the adoption of sequential function chart as a language for top-level sequencing of a machine makes it easier for a maintenance technician to be able to go in and look specifically at what was being processed at that particular point in time and begin to hone their troubleshooting down from a monolithic block of code to a specific subset of code that is pertinent at that particular point. I think we expose maintenance technicians to an awful lot of code unnecessarily. Instead, we should concentrate on building bulletproof modular functionality that we know works well in a specific way. And then we only expose maintenance technicians to the interface necessary to use that functionality. So now all of a sudden we’ve got a technician that sees a function block that says, "If you provide me with these four pieces of specific information, I will give you these two pieces of output information only. You have no reason to go inside this code to see how I accomplish this. You know that if I don’t give you this output it’s because you didn’t get one of these four inputs correctly or in the right time." If implemented correctly, IEC 61131-3 has the potential to greatly decrease the maintenance technician’s time-to-solution. And that’s one aspect where I think it is going to make a difference.
Van Dyke: I would agree it would be better to have maintenance technicians spending more time solving functional problems and less time looking at code. But I’m not sure the IEC 61131-3 standard, so far at least, has tried to take that on. I think it is more of the Make2Pack and PackML standards that are doing a better job of encouraging that approach or defining things to be structured in that way.
Ryan: I don’t disagree with you. Make2Pack and PackML have brought a number of improvements to the programming of packaging machinery. But I do think IEC 61131-3 is helpful in the way it limits the language set and standardizes the implementation of that language set. What we need now are best practices that can be widely shared.
PW: Who is working on the best practices?
Faust: No one.
Ryan: ISA 88.5 is an attempt to do some of that.
Van Dyke: Efforts are underway. There’s PLC Open, Make2Pack, Pac Soft. But are the efforts coordinated enough? I think it’s really complicated. It’s a tough thing to solve.
PW: Getting back to IEC 61131-3 specifically, sometimes it seems that certain controls technology providers wave it around like it’s a silver bullet.
Van Dyke: I think they’re overselling it. I’ve gotten into some of it and it can be horrendous. You know, the complexity to it versus some other things that I’ve worked on that were all just pure ladder logic. I mean it really comes down to how well the program is structured to meet your particular application needs. There needs to be a good, coordinated effort to bring to fruition all the things that the technology providers are talking about. And the technology providers aren’t really driving that proactively.
Ryan: I think what we haven’t been able to do correctly is implement IEC 61131-3 in a way that leverages its benefits. One area where that is taking place more visibly is with machines that go into an FDA-validated environment. We work with the likes of medical device makers like Boston Scientific and Medtronics, where they are now going through the same automation renaissance that consumer packaged goods companies went through ten years ago. We’re seeing tremendous advantage to them in having reusable code that can be validated and locked. Once they validate that with FDA, it’s much easier to validate a second machine that uses components of that previous code.
PW: Any final thoughts?
Ryan: From an educator’s standpoint, I guess my final remark is that we should keep in mind that standardization like this is beneficial not only from a machine builder’s standpoint. Standardizing on these languages and how they’re implemented certainly makes it easier for us to have a training mission across multiple different disciplines.
Van Dyke: That’s a good point.
Faust: From the OEM perspective, broader acceptance of a standard like this makes our lives easier. It means we can concentrate more on the low-level programming that’s really unique to our machine, the kind of things that establish our position in the marketplace.
