Sourcing for a PLC to fit ?


Thread Starter


I'll like to know what are check list needed to source for a PLC that fits ones application. What are the general criteria and selection basis to be aware or beware off ?
1) Technical features. Does it have the features you need?

2) Price. How much does it cost in the configuration you will be using?

3) Hidden costs. How much does the programming software and cables (or adapters) cost? This can be several times the cost of the PLC itself.

4) Spare parts. How long would it take to get any replacement parts?

5) Communications capabilities. If you think you may wish to be able to communicate with the PLC from other systems, then does it support some sort of open communications protocol? This question is a big can of worms because when most vendors call their protocol "open" they really just mean they will allow it to be used with systems from selected business partners but not anyone else. If this factor matters to you then ask about it in a reply and I can elaborate on it.
Thanks for the info. Yes, pls kindly elaborate more abt the "openess" and integration complications that arises from it. I'll like to avoid these hidden cost especially before we finalize/spec-in on a PLC system.

James Ingraham

M Griffin had a good list, but I'll add one more to the criteria; market share. i.e. how easy is it to find someone who knows how a particular brand works. In the US, Allen-Bradley is king. In Europe, Siemens is the most common. In Japan it's Mitsubishi. Ignoring the larger market concerns, how about the specific facility the PLC will go into. Even in the US, I'd hate to put an A-B into an all-Siemens shop.

-James Ingraham
Sage Automation, Inc.
I will start by defining "open" as meaning that anyone can implement the protocol. When I say that, I mean that anyone can download the protocol specs and automatically receive the right to implement them without signing a contract with the vendor.

None of the automation vendors makes everything, so they all allow some degree of interoperability with other hardware. However, they usually limit whose those "partners" are and what they can do because they don't want too much direct competition with their own core products.

That may not affect you, until the day you need to do something and find out there is no way to accomplish it because it wasn't part of the vendor's marketing plan. For some people, this isn't a problem. If their favoured vendor doesn't provide a way to do something, then they just don't do it.

I would put the modern Ethernet protocols into four groups:

1) Modbus/TPC. According to the market share data that I've seen, this is the most widely used. It is a genuinely open protocol and many people have implemented it independently.

2) AB Ethernet/IP. If you use AB PLCs, then you use Ethernet/IP, and visa versa. Availability of specifications and licensing are tightly controlled.

3) Profinet. The market share data that I've seen puts this in a very distant third place. Profinet is to Siemens what Ethernet/IP is to AB. Again, it is tightly controlled.

4) There are many others, such as Ethercat and Powerlink, but none of them has seen widespread use.

Modbus/TCP is a single fairly simple protocol (unlike Ethernet/IP or Profinet, which are more like collections of protocols sold under a common brand name). It works fine for supervisory coordination, but it won't do things like real time motion control. If you need that, then you need a different protocol. On the other hand, I don't seen any reason why you would want the same protocol for motion control as you use for supervisory control (in fact, I wouldn't choose to even put those two functions together on the same network).

If you need to connect an HMI or SCADA system to a PLC via Ethernet, then you can often use a protocol driver that has an OPC interface. However, OPC drivers tend to be expensive, slow, and complex, so they're not a panacea.

If you are using a very low cost PLC, then it may not have Ethernet as an option. If all you have to work with is an RS-232 or RS-485 port, then you probably want to stick with Modbus/RTU. Again, Modbus/RTU is an open protocol and widely supported.

What most people do however, is they pick a brand of PLC and then accept whatever protocol comes with it. If the protocol is proprietary, then that makes it more difficult to switch to a different brand later because then the new systems won't talk to the old systems (which of course is why the major vendors don't want to use a common protocol).
In reply to James Ingraham: I've seen companies who have switched brands (e.g. from AB to Siemens), and it really wasn't a problem for the maintenance personnel. If a company is hiring someone on the basis of whether they "know" a particular PLC, then they are hiring people on the wrong basis. If you already have any experience at all, you can generally learn everything you need to know about a new PLC in a few days. Most electricians that I know are pretty smart, and learning new things is something they have to do all the time anyway.

New brands of PLC tend to be more of a problem for the business people than it is for the technical people. Every new model means either carrying more spare parts, or it means taking a risk by not having spare parts. Most maintenance departments are under continuous pressure to reduce their inventory, not increase it.

Another big issue is the programming software. Software from the big vendors tends to be expensive, and that is often an ongoing expense because of annual fees. I've seen companies rip brand new major brand PLCs out of new OEM machines, toss them in the garbage, and install a different one because it was cheaper to do that than to buy the programming software just for that one PLC.

In this situation, "brand" alone doesn't tell you much. You need to know specific CPU and I/O card models and ordering options.

curt wuollet

That, and at the last place I worked, I couldn't get them to pay any attention to what was inside as far as maintainability. I think they bought new machines based on bright colors and what was the shiniest at the show. That made being the automation and controls guy interesting to say the least. Not only did you have to beg for horrendously expensive new tools all the time and keep all that Windows crap straight, but the downtime was your fault when you were down to chasing IO lights with no software or docs. And they _believed_ that you don't need it, the vendor will take care of everything. Until they don't. While it's great experience working with a dozen or so brands of PLCs and controllers, the difficulty was highly under appreciated. Until Now :^)