As a long time PLC programmer I’ve come across many different types of PLC out there and perhaps too many to list. What I find interesting is that people tend to become attached to a particular brand or model of PLC and prefer it over all others. What’s interesting is that for most of those people the PLC hardware itself and its appearance, reliability and servicability make up only a very small part of their personal preference towards that PLC. It’s fair to say that most PLC hardware is manufactured by large scale manufacturers and with more and more products using standardised components that are mass produced the reliability of the PLC hardware far surpasses that of PLCs from 20 years ago.
What drives loyalty the most, interestingly, is the programming software and languages the PLC supports. There are two ways PLC software can be written - interpreted or compiled. From a programming convenience point of view, online editing and offsite works with minimal disruption to the end user during updating there is no doubt that interpreted is the better approach. Having said that compiled languages are generally easier to write in and have more efficient use of memory space than interpreted languages.
Beyond the interpreted/compiled differences it’s then down to programming languages. Things have come a long way in the last 10 years in particular as more and more vendors support IEC standardised languages and terminology for Statement List (also called Structured Text Language), Function Block Diagram and Ladder Logic. That said some manufacturers don’t follow it to the letter and still have their own subtle variants but largely PLC programming software today supports the big three language types for the commonly used PLCs. This makes it less of a differentiator to drive personal preference.
Finally it’s the programming software itself. The layout, the online help and the usability of the software. The problem seems to be that every manufacturer has their own naming ideas for different functions (the classic Siemens “Generate References” as opposed to the industry standard “Cross-References” for example) and this makes things difficult for the programmer trying to work on the next platform as the project requires.
By extension you could say that if a software manufacturer (not a PLC manufacturer) made a stand-alone set of PLC programming tools that were excellent, used common terminology and was able to write to the top 10 PLC types, they could potentially make a killing. Alas this seems unlikely as each PLC hardware manufacturer has its own proprietary communication system for sending data from the programming PC to the PLC. A single firmware update for the PLC and software update for the programming software and it’s back to square one for the all-in-one software package. Not to mention the threat of invalidated warranties I’m sure the PLC manufacturers would dangle in front of users not using their proprietary programming software. There’s another discussion for another time…