That primary platform will contain the motion control algorithms but could just as well perform the functions allocated to the PLC. Why are we permitting, or in some cases requiring, this added cost and complexity?
There are two reasons that I see that this occurs: one that serves the end user's perceived need and another that serves the machine builder's perceived need.
From the end users perspective, many customers are still of a mind that every machine must come with a PLC from their "preferred supplier". If a machine builder comes forward with a machine containing an integrated motion and logic controller from the likes of B&R, Beckhoff, or Yaskawa, the purchaser is likely to claim that the machine does not meet their spec which requires a Rockwell, Siemens or some other PLC. A work-around to this problem is for the machine builder to embed a primary controller that contains his software jewels in one controller (the swapping out of which in non-negotiable) and then to add a secondary controller, a PLC of whatever flavor the user prefers, to perform menial tasks that could just as well have been performed in the primary. This adds cost and complexity in exchange for an emotional "feel-good" for the buyer.
From the machine builder's perspective, there may be a concern about the user having access to the controller containing the proprietary control algorithms and safety controls built into the machine. In this case, even though the primary controller could perform all of the functions required, adding a secondary PLC increases the liklihood that the end user will only fiddle with the software they are most familiar with and not make any attempt to access the software in the primary controller. In this scenario we have added cost and complexity in exchange for a sense of security and reduced liability.
One may wonder out loud, however, if the end user doesn't intend to have access to the primary machine software, why does he care about what platform is in the machine? And if he does intend to access the primary software, will the two controller scenario really stop him? There are other ways of protecting that software in a one-controller design. I must also comment that it has been my observation that this two controller practice is much more common in the US than in other parts of the world.
My conclusion is that this is a PLC charade that, on the surface may look like a good idea, but really only adds cost and complexity to machines and makes US manufacturers less competitive.
Comments
This certainly describes a path to the perfect world for an equipment provider, but not the end user. I have yet to see equipment arrive that has everything the end user needs even at the time of delivery, let alone years down the road. Adding OEE capabilities, integrating with additional equipment (existing or future), Operator visualization and many other requirements for the end user cannot be incorporated into an equipment manufacturers standards.
Move along to spare parts and training on components not standard or familiar and you can have a recipe for disaster. I have performed code conversion for equipment manufacturers to help them bridge over to my requirements and have eliminated many vendors because they would not provide to the standards. I currently have one piece of B&R, predating me, that I cannot get source code for and the vendor is no longer in existence that I still need to replace with a standardized component. I certainly would not want that to be a "typical" situation.
So please Mr. Equipment Vendor, give me what "I" want and not what "you" want.
Posted by: David Kaylor on October 27, 2011
For many years, we've called this a "PLC-bo" as in placebo.
One answer is for activists to actively participate in PLCopen and the PackSoft committee of OMAC Packaging Workgroup to promote common look & feel of control software in the IEC 61131-3 environment.
Specify the functionality based on standards, and choose preferred suppliers, as Nestle has now done. No surprise that they have taken a leadership role in OMAC Packaging Workgroup!
Posted by: John Kowal on October 27, 2011
As controllers become more powerfull and smaller (commodity item), a complete rethink by companies is required to not only reduce costs, but also less complexity, less cube space utilized, less training, effective focused security, less engineering, less fabrication, less metal, less spares inventory, less convoluted safety layers that increase time to repair (really time to find the hiccup), less shipping, etc. I thought this is what green is all about. The time is now to do this. Yes, there are difficulties to overcome, but most of them are self-inflicted.
Posted by: Paul Zepf on October 27, 2011
Good word Keith!
Our company retrofits motion-centric control systems and we consistently replace packaging machine control systems consisting of a legacy PLC and motion controller with a PAC (Programmable Automation Controller that integrates PLC with motion).
It simplifies the system, the customer ends up with a much more maintainable system, and the cost is reduced.
By basing the application code on PLCOpen languages, the machine software is maintainable and open for changes as the customer's needs change.
Atle
Posted by: Atle Bjanes on October 27, 2011
Mr. Campbell,
As usual I think you really did knock this topic out of the park! However,
the change at the End User is slow and we still continue to add a menial PLC
to appease an End User in North America for a foreseeable future. (I hope
I'm wrong!)
I just wanted to send you a quick email to let you know the ELAU name may
have gone away in North America but the products and support are doing very
well within Schneider Electric! The ELAU products are now known as the
PacDrive offering within Schneider Electric and we have experienced exactly
what you describe in your article the last 6 years!
Please let me know if you have any questions or concerns and I look forward
to your next article!
Best Regards,
John Partin
(Formerly ELAU - District Sales Mgr.)
Posted by: John Partin on October 27, 2011
We are the folks that have to live through the years of life cycle of the machine�.The manufacturer�s job is pretty well done when the machine is crated for the loading dock As one of your posters said, it is rare indeed that a new machine will immediately meet all of the requirements, present and future. I believe that putting more than one PLC in a machine is not in the interest of the customer. In our plant, we have standardized on a single brand of PLC, and our technical team has become very competent with that brand. For that reason, it would be crazy to start bringing in a variety of controllers, just because the manufacturer prefers �another brand�. More expensive to buy? In our case, yes, but it�s worth it, as we the customer, now have control of the situation. We can modify and integrate to our hearts content without having to rely on shaky and expensive tech support from Europe or elsewhere. For folks that do not have on site technical resources to fall back on, the situation might dictate a different approach. Some time ago, we purchased a machine which had locked software in the motion controller. We learned big time on that one. All new machine programs must now NOT be password protected. We are also in the process of developing programming standards for new machines, which will make OUR life easier�.after all WE are the customer!
Posted by: Gerald Beaudoin on October 27, 2011
Mr. Campbell,
You raise some very interesting points in your essay. In our company, I am the guy that specifies machine builds or selects OEM machinery for installation at the facility, along with my colleagues at other facilities around the world.
The reason we like to see a PLC or controller we are familiar with can be summed up nicely by saying that we need to be able to troubleshoot the machine on site with our own maintenance personnel. We have made a significant investment in the professional development of our maintenance staff on the several platforms of PLC and drive systems in use at our facility. I can tell you from personal experience that when the �new 2 million dollar machine� is down and we can�t fix it because we have tracked the problem to the input side of a �black box� it puts us in a very bad position with management and our customers. It also seems more often than not that these failures take place at the most inconvenient times to be able to reach technical support (usually 2 AM). Additionally, none of our maintenance personnel can debug programming code.
I can think of no other time in my career when we have purchased machinery that does not work as specified so frequently. The embedded systems we are seeing these days are delicate and do not hold up over time in a 24/7 production environment. When it is determined the embedded system needs to be replaced we are at the mercy of the OEM who can charge whatever they want because the system is proprietary. The OEM can rest assured in knowing we are not interested in stealing your code, we want to be able to keep the machine running.
My advice to machine builders and OEMs that want to sell me a system that works exclusively on embedded controllers is:
1. Provide an intuitive interface or HMI that will assist us in solving the majority of problems likely to be encountered.
2. Provide documentation in the English language that is easy to understand and written for an individual with a high school education.
3. Avoid using customized parts (unless unavoidable) such as encoders that have long lead times for replacements.
4. Develop your equipment with the customer�s needs in mind, not the long term profitability of your after sale parts and service business.
Posted by: Bill Aman on October 27, 2011
I can't disgree your point, every manufacture has their own charactors for their business, I do know more than 3 manufacturers worked with PLC charade very well.
Posted by: Reymond on November 11, 2011
I agree in some cases, but not in most. I've done a lot of integration between robots, vision, PLC control, data collection/reporting, and OPS (Other People's Stuff) such as check weighers and a dozen other odds and ends. I've used a lot of PC based things, some should be allowed on a production floor and some shouldn't. Everyone will claim their world class thingamabob runs reliably on a PC. If it's running in Windows it's probably not all that reliable though. Some people (starting way back in the Dark Ages with Steeplechase and continuing forward) manipulate the Windows kernal so their software will continue running if Windows has crashed. That's just plain scary. Just what I want, a control system on board a run away train. Yikes.
You don't have to go reboot the PLC when it crashes and burns because it's been running the process non-stop the past 12 weeks on a noisy Ethernet network that's not segmented or shielded all that well. The reason of course is because it doesn't crash and burn. The next reason people still do this is that the number of people like me available to support systems, meaning a person that's programmed everything from mainframes to pc to server database systems, to Unix, in a structured language, or a structured text, plus with knowledge of control systems and their communications and programming.... well there are not a lot of us. There are a LOT more plc programmers. I've had the discussions with service departments where they wanted the decision making and control made in a plc as much as possible because they can support it, and they can't support the PC based system as well because they don't have IT skills in addition to PLC skills.
There are a lot of PLC programmers out there though.
Lastly, the PLC makes a great platform for a Data Concentrator. When you have a robot controller, a few vision controllers. a check weigher, a number of control processes making machine cycles run, and you want a global cop/brain watching everything and assembling records to ship OEE data off to a SQL database for analysis, and you want global alarming and annunciation... well there are other ways to do it, but the one that still seems most popular is to make the PLC the center of that complex universe. To have the PLC talk to all the other smart pieces in the big packaging line, because the PLC vendors generally make it easy to do that, and the PLC is darned reliable, and it doesn't really interfere with the functionality of the various processes taking place around it on those other platforms. The PLC will even tell you when you have to go reboot one of the Windows based items if you are clever enough in the handshaking.
I think I still like the PLC in the mix. It may be unnecessary from a purely minimalist perspective, but I believe more people will find it advantageous. If price is squeezing you terribly, then of course be frugal and go the other way. Greg
Posted by: Gregory Brasic on November 18, 2011
Your blog is good.give more information about this topic in future.Good luck.
Posted by: VISIONPACK shrink wrapping machines on May 8, 2012
I have a situation where a machine supplier refuses to give us the password for access to an Allen Bradly micro logix PLC. To me if a customer purchases a piece of equipment he is entitled to access the program for troubleshooting purposes. Does anyone know if there is any legal recourse that can be taken. I can erase the program and write a new one but this seems like a real waste of time.
Posted by: Bob Campbell on March 22, 2013
