PLC Capabilities? Which are considered the "best" and why?

I know many have preferences as to the PLC of their choosing. There is also the comfort factor based on level of experience with certain brands.

But being as objective as possible, what PLC's does this group consider to be in the top 5 based on the tools it offers to accomplish the variety of challenging applications we run into in our careers? I know of specific cases where a large company has a standard PLC brand. An application arises where the best that PLC manufacturer has to offer (in hardware and engineering support) just cannot pull it off. This opens the door to other players and one of these other manufacturers is able to handle the application successfully. The reasons for this could range from sheer processing speed capability to actual programming tools available from one and not the other.

Of course there are so many applications that could be successfully handled by most PLC's on the market. But some applications separate the men from the boys.

Anyone have an opinion?

Best PLC

Take a look at the PLC review section on this site. The best PLC for the Job depends on the requirments of the project. The ROI also plays a part. Return on investment is now being pounded into our heads. Managment wants us to plan on a very limited budget. For plain horse-power best....we will argue about that here till the cows come home .. True objectivity is very rare in this world. We have 2 AB CX PLCs that Just "idle", processing logs at over 450 feet per minute. Each handles many process loops. Is this the best PLC? Not in my opinion. My objectivity is clouded.... I like Modicon.

The PLC review list does not contain many of the best on the market. As far as AB goes, I don't even put them in the discussion. It is bar none the best marketed product, it is reliable or it would not be as successful as it is, and will do the job in the majority of applications. But when it comes to really challenging applications, I know of specific examples where AB's best and brightest could not get it done. And that is not necessarily a bad thing as having the fastest car on the block is not their objective. There are brands that are cost effective and are feasible solutions for simple applications ranging to the very difficult ones. And I too would favor Modicon over AB. What features certain brands have that others don't is something that can be compared objectively. How each software package drives and looks would have many different preferences. But if a long integer is 32 bits to one PLC, and 64 bits to another, then that is a real difference.

Also, this is not attempt to attack or put down any brands, just a discussion to bring to the surface some of the neat features that some brands offer that we all can't be aware of merely from experience.

Here is my list of features that make the "real difference"
1. User defined function blocks (this is a must have), despite others insistance a subroutine is not the same.
2. User defined data types
3. Full range of IEC languages and a real conformance to the standard
4. Communications capabilities, it must have a full range of industry standard comms available (ie it should be able to talk to other brands easily with a number of choices, not just profibus)
5. Ethernet capabilities should include inbuilt web servers (this makes diagnostics & setup easy), even better if it is capable of user downloadable web pages.
6. A programming package that works across the full range, with a common language across the range (IEC)
7. A programming package that includes a decent simulation tool
8. A programming package that saves the program as a single file

I'm sure there are lots of other things, these are just the ones that I can think of at the moment that annoy me when using different brands. I too favour Modicon with UnityPro

swhite65 said:

Anyone have an opinion?

Click to expand...

Everyone has one. You certainly do.

Bruce99 mentions the key points of ROI and requirements. I think ROI alone is enough if you consider life time costs as part of the investment.

As far as AB goes, I don't even put them in the discussion.

Click to expand...

That is closed minded and you didn't say why.

An application arises where the best that PLC manufacturer has to offer (in hardware and engineering support) just cannot pull it off.

But some applications separate the men from the boys.

Click to expand...

Something prompted you to make this post. What applications are you referring to?

The reasons for this could range from sheer processing speed capability to actual programming tools available from one and not the other.

Click to expand...

Sometimes it is the programmer or the wrong application for a PLC. I see this way too often. I have also seen cases where the machine was flawed so that there was no way the machine could be controlled in a satisfactory way.

I know of specific examples where AB's best and brightest could not get it done.

Click to expand...

So what happened? I have seen cases where over zealous salesmen over sale a product too. To be more specific I have seen people try to use the PLC PID to do motion control or pressure control. My company makes motion controllers, not PLCs, so we get called after someone has tried and failed to do the job with the PLC.

It is hard to make a generic product like a PLC do all jobs well. It is hard to make a motion controller for that matter that can do all jobs well. Once I put a feature in a product that the next guy does not need that product is no longer optimal. Everything is a compromise.

But if a long integer is 32 bits to one PLC, and 64 bits to another, then that is a real difference.

Click to expand...

What would you do with 64 bit integers? Count the national debt, stars or grains of sand on the beaches? I can represent bit boards or sets of pieces in a chess program. That is just what the world needs, a chess playing PLC

As far as AB goes, I don't even put them in the discussion.

Click to expand...

Just another AB bashing thread, make comments without stating details to clarify the application or if any plc was used for the application.

A PLC is a tool or component, nothing more, it is up to the person designing the system to determine which tool(s) or component(s) are the most appropriate for their application(s).

There are numerous brands to choose from that offer different models etc appropriate for varying applications, what is used may be decided on different variables i.e. cost, familiarity (company or indivual), ease of use (could be related to familiarity, memory, number of I/O, added capabilities, and much much more; which is too numerous to list.

They all basically do the same thing, some more then others but that happens with the same brand. I do not see how any brand could be left out of thought or a discussion pertaining to plc's. To do so, in my opinion, would be unprofessional in that it would not offer all the available options, features, and future capabilities that may be appropriate for an application.

The budget have to decide, for a small project any cheap PLC is the "best one", and for a demanding marine environment we need stuff with proper certificates etc. so a more expensive and advanced PLC are sometimes the "best one". I dont think there is a multipurpose PLC that is both cheap, fast, easy to program and have all neccesary certificates... Im now looking at Siemens LOGO for small projects, it have buttons so can be programmed without pc.

GeoffC said:

Here is my list of features that make the "real difference"
1. User defined function blocks (this is a must have), despite others insistance a subroutine is not the same.
2. User defined data types
3. Full range of IEC languages and a real conformance to the standard
4. Communications capabilities, it must have a full range of industry standard comms available (ie it should be able to talk to other brands easily with a number of choices, not just profibus)
5. Ethernet capabilities should include inbuilt web servers (this makes diagnostics & setup easy), even better if it is capable of user downloadable web pages.
6. A programming package that works across the full range, with a common language across the range (IEC)
7. A programming package that includes a decent simulation tool
8. A programming package that saves the program as a single file

I'm sure there are lots of other things, these are just the ones that I can think of at the moment that annoy me when using different brands. I too favour Modicon with UnityPro

Click to expand...

The original question did not specify the application field but definitely what you describe will be overkill in lots of applications.
What is your typical application, GeoffC?

Also, ranking software package may give totally different results than comparing the hardware.
Anyways, the question itself is senseless, IMO.
Like what is the best car or the best weapon.
Specify the application, high-speed and networking requirements, budget tightness, possibility to purchase new soft and time to learn it, customer requirements, etc and we'll can talk seriously.

rsdoran said:

Just another AB bashing thread, make comments without stating details to clarify the application or if any plc was used for the application.

A PLC is a tool or component, nothing more, it is up to the person designing the system to determine which tool(s) or component(s) are the most appropriate for their application(s).

There are numerous brands to choose from that offer different models etc appropriate for varying applications, what is used may be decided on different variables i.e. cost, familiarity (company or indivual), ease of use (could be related to familiarity, memory, number of I/O, added capabilities, and much much more; which is too numerous to list.

They all basically do the same thing, some more then others but that happens with the same brand. I do not see how any brand could be left out of thought or a discussion pertaining to plc's. To do so, in my opinion, would be unprofessional in that it would not offer all the available options, features, and future capabilities that may be appropriate for an application.

Click to expand...

I didn't take the post as AB bashing at all. It sounded that he was saying that AB is very well marketed at reliable, but it may not be best for all applications, just as every other PLC on the market.

Hi Peter. Next version AB are including a 64 bit integer. Called a LINT. Apparently it was required because some standard got changed. I think the ODVA changed the way time was calculated. It now has to be in milliseconds from 1970 so there the Lint is required.
Regards Alan

Alan Case said:

Hi Peter. Next version AB are including a 64 bit integer. Called a LINT. Apparently it was required because some standard got changed. I think the ODVA changed the way time was calculated. It now has to be in milliseconds from 1970 so there the Lint is required.
Regards Alan

Click to expand...

Hello Alan / Peter,
If you think LINT is a big number, try getting your heads round Omrons 64 bit floating point(LREAL).
-1.79769313486231e+308 to -2.22507385850721e-308,
0,
+2.22507385850721e-308 to +1.79769313486231e+308

Now that's a BIG (or small) number!!!

Yes, some standard was changed I have been informed by several PLC sales companies but none of them can tell me which one.

LINT I hear came out of Europe and so did double floating point maths - 64 bits.

The thing I absolutely loave about LINT (long integer - 64 bit) is that you can specify a long integer when monitoring and watch it in binary thus watching a 64 bit input or output card in one line of 1's and 0's. Very handy.

I really cannot think of anywhere else I would use it but I am sure someone will.

I look at software first and foremost because it can save me a heap of time.

User defined function blocks (this is a must have), despite others insistance a subroutine is not the same.

Click to expand...

That is an IEC requirement.

User defined data types

Click to expand...

I presume you refer to being able to data type a channel according to IEC data types.

Full range of IEC languages and a real conformance to the standard

Click to expand...

Could not give a hoot about any other IEC languages other than ladder, FB and STL - is I ever require it. Mechanical people tend to like the others.

Communications capabilities, it must have a full range of industry standard comms available (ie it should be able to talk to other brands easily with a number of choices, not just profibus)

Click to expand...

Prefer Device Net and serial communications are the most imporatant of all in my view. There must be a cery simple and effective way to write serial protocols quite frankly as they are the most common. The serial card should also have a "trace" function on each port to save mucking about with serial analyseres. Much easier to trace the messages in the card and then upload to the software and have a good look at send and receive messages when trouble shooting.

Ethernet capabilities should include inbuilt web servers (this makes diagnostics & setup easy), even better if it is capable of user downloadable web pages.

Click to expand...

Much prefer a proprietary netwrok that works much better than Ethernet. Ethernet is good for SCADA. Could not give a hoot about web pages - if the PLC software is any good.

6. A programming package that works across the full range, with a common language across the range (IEC)
7. A programming package that includes a decent simulation tool
8. A programming package that saves the program as a single file

Click to expand...

ABSOLUTELY!!! Could not agree more. The file does not want to take up a full memory stick either. I have a full program for a power station with 9 networked PLCs, comments, symbols etc etc - the whole deal - and the file is only 500 odd k!!! That is efficient.

Had a break for dinner.

I too favour Modicon with UnityPro

Click to expand...

Had a good look and told the Schneider rep to come back when he had some good software. It is relative though, what one person loves another dislikes to the same degree. I disliked most the lack of use of function keys. I do not use a mouse very much at all with PLC software, Excell or any other program that has good short cut keys.

Quite often the customer specifies what he wants. That then becomes the best PLC for the job unless you can convince him, on technical and not emotive grounds, that his choice may not be suitable.

One other area where I agree is that I definately want the same software for all PLCs in the range. This includes top end down to shoe box PLCs. I cannot be bothered with software that has several flavours for the same brand of "current" PLCs. That is an absolute pain in the tail.

If the PLC is older than 1994 or 5, it does not bother me much as they are very old projects and it will take time to get one's head around them anyway, but 2 or 3 sets of different software for current models is, quite frankly, ridiculous. After all the software writes a binary file to the PLC so there is really no excuse for more than one software package in this day and age.

ranking software package may give totally different results than comparing the hardware

Click to expand...

Sergei it is the software to a large extent that determines the functionality of the plc, so I always look at both.

and Bob

That is an IEC requirement

Click to expand...

just because it is an IEC requirement does not mean that all plc are capable of this, in fact only a few do it well.

I presume you refer to being able to data type a channel according to IEC data types

Click to expand...

no, a user defined data type involves making a complex type from a set of elemental types, eg define a pump type with Booleans for commands & status, integers for speed and current, etc. so adding a single tag totally defines the device.

Could not give a hoot about any other IEC languages other than ladder, FB and STL

Click to expand...

I agree that these are all that are normally required, but it must have at least all of these.

Ethernet is good for SCADA

Click to expand...

in my view it is essential for SCADA, personally I use it for almost everything (seperate network for I/O of course). And a web page for a remote I/O device makes configuration & diagnostics a breeze.

I can't believe your analysis of software comes down to the number of shortcut keys. Personally I prefer point & click, drag & drop for data entry. but even so using user defined functions & types means there is a lot less data entry anyway. Once you have a library of functions a program can be put together very quickly (even without shortcut keys), for example to add a pump to program would involve a single function and setting the i/o for that function to the real i/o, thats it, a fully tested device which includes scada interface, alarms, status, control, hour meters, etc, etc.
Most new software involves more than having a look to fully appreciate it's capabilities.

I wish people could make up their minds.

Many processors have today have 64 bit floating point. We too have 64 bit floating point but we haven't implemented it because no one else does and it is not good to force people use use formats their PLCs don't support. There was a thread recently where someone had to jump through hoops to get their single precision floating point converted to a double precision floating point. I think that was on a different forum though.

Supporting 64 integers isn't a difficult problem. It just means that there must be a LINT version of all the instructions. That isn't a problem if the CPU can support all the instructions in hardware. It will take a lot of screen space to display one though. This is good to know.

BTW, if you only had 64 bit integers would it make any difference to you? At this time our 32 bit DSP only has 32 bit integers and no one seems to mind.

I agree with BobB about being able to get things done without having to take my hands off the key board to move a mouse. Mice are for beginners. Power users type in equation directly like on RSLogix.

I don't agree with BobB about Ethernet. Ethernet is the way to go to move large amounts of data around. I don't see where proprietory networks can do that. We have just increased the speed of the Ethernet on our new product so we can respond to a Ethernet packet in less than a millisecond. On the www.mrplc.com the EN2T was announced which is a faster version of the ENBT card. Ethernet rules.

Alan, you must be back from a startup somewhere remote. We haven't heard from you in a while.

in my view it is essential for SCADA, personally I use it for almost everything (seperate network for I/O of course).

Click to expand...

I use a proprietary network for peer to peer exclusively. The biggest problem with Ethernet, apart from collisions, is that IT want to own it. They do not want to own proprietary networks because they do not understand them. The network I use is token ring based and if the network controller sees more traffic it issues more tokens. If the network controller is turned off, the next card takes over. If I use fibre it is a ring network and can tolerate a break. If the client wants super security I use 2 cards per PLC with fibre optic. The fibre is then run by a different route in the building. By the way, the standard network only runs at 750kbaud over a twisted pair. I have a job with a network card in the PC, Citect SCADA and 9 PLCs. Citect reports over 15,000 digital reads per second and 140 word reads per second. That is in addition to 600 words of data peer to peer. The network scan time never goes over 22 milliseconds. It also cheaper than Ethernet in the PLCs. The speed is fine for me and my projects and it is absolutely reliable. IT run the other way - that is good.

A friend of mine works for a company where there are a multitude of Siemens PLCs running on Ethernet. IT change the setup in the switches, and how the network is run, without consulting with him and the Citecet SCADA system, over 110,000 tags, cannot find the PLCs. This happens regularly. Anything he really needs and does not want them to touch he has to run on Profibus to keep their little fingers out.

And a web page for a remote I/O device makes configuration & diagnostics a breeze.

Click to expand...

The network I use allows me to fire into any PLC and check out the I/O table, set up network (sometimes Ethernet), start and stop PLCs, chnage the configuration of serial ports, downloads serial protocols to the serial cards, whatever I wish to do. The only time I ever use a web server is if there is no other way to access and setup a device. Most remote I/O I use are Device Net. This would be way too slow for Peter, and probably the proprietary network would also be the case, but it is horses for courses. I regularly set up devices over Device Net and also using Modbus RTU. I also regularly use Windows hyperterminal for setting up devices.

I can't believe your analysis of software comes down to the number of shortcut keys. Personally I prefer point & click, drag & drop for data entry.

Click to expand...

It is a very important requirement of the software I choose. It is far quicker than drag and drop and one does not finish up with RSI from clicking a darn mouse. If I remember correctly, Peter also raised the point in a previous thread that he uses the short cut keys in Excel. So do I, and Word as well. I absolutely hate drag and drop and the pain I get when using it for hours on end in my wrist. For someone developing code short cut keys are the only way to go. Faster and less painful. I always reckoned drag and drop was good for "factory fiddlers".

Unfortunately a library of FBs is fairly useless to me except for the bvery occassional job. If there are 20 alarm routines, for example, then there will be ten different type. Takes too long to write 10 FBs for twenty alarms. Much quicker to copy and paste and modify.

I might add that I had this discussion with my Schneider rep. We both sat down at our computers and wrote twenty different alarm routines. I did it my way and he used drag and drop. I finished 10 minutes in front of him. That was ten minutes I could spend on something else. In fact, I wrote half a control routine for a diesel generator while he was finishing off. He went away with his tail between his legs.

I do not have the time or patience to fiddle about with drag and drop with my PLC software, or Excel, or Word or any other software. If there are shortcut keys I learn them and use them. Saves me heaps of time and as I work for myself, time is absolutely more dollars in the pocket.