Picking a PLC

Disclaimer: I am not posting this to insult or belittle anybody. I just think it is sometimes we get the horse before the cart. I am using my experience to write this and I bet there are things I am missing. I hope others can add to this.

When picking a PLC brand to me means a lot. If I can not get good support on a brand I will try to avoid using it.

Next deciding factor is what am I going to be using the PLC for.

For me this breaks down into Communication, I/O abilities, expansion abilities, physical size, scan speeds, and form factor.

Communication: Do I need Ethernet capabilities, Profibus, DeviceNet, Modbus, etc.. Do I need serial for special I/O.. What kind of com speeds do I need?

I/O abilities: Do I need analog, discreet, what voltages will I be working with in my I/O. How many do I need?

Expansion Abilities: Do I need to be able to expand at a later date, will I need to expand into remote I/O.

Physical Size: Do I need something compact. Are their limitations on the cabinet size I can use for my PLC?

Scan Speed: Once I write my program will it run fast enough. Do I need interrupts? If I need interrupts, how many.

Form Factor: How easy will this thing be to wire up, how much space will I need to allocate to get my wiring in and out of my PLC?

All of this information can be found in the PLC’s manual. By finding this information you should get a feel for how well written the manual is. This adds into how well I think the system will be supported. If I feel the manual is poorly written then I know I am going to have surprises.


Once I know the hardware will work I move on to the programming. To me programming is highly subjective. Some (myself included) are more comfortable writing in ladder, others prefer text style. If you pick a PLC that is programmed in a language your not comfortable with you need to factor this in.

I have worked with a lot of different types of PLC’s over the years. Some I liked better than others. The main thing is can the PLC do what you need it to do. If the hardware is not up to the task, no amount of programing will fix it. That is where the above criteria comes into play.

I am sure there are other things to consider, this just my start list. Hopefully others will add to this list.

I would think simplicity of system for maintainence personnel.
When a system does fail, will the plant people be able to diagnose the problem and get the system back up and running fairly fast. You can design a system with profibus throughout but what happens when one of the nodes fail, will they be able to get it working again. Some plants have highly qualified people while others not so much.

At a job recently the programmer decided to save the design company a few bucks and go with what I call a Wally World special. Every thing else in the plant is A-B. Well the unit failed after a couple of months and the programmer had since taken a job elsewhere. After numerous phone calls and lots of man hours they did finally talk the orignal programmer into coming in and helping them fix it. How much did they really save by going to brand X.

What I am saying is use the KISS principle if possible.