The foundational product of any automated system is going to be the controller, whether it’s based on PLCs, PACs or PCs (or a combination of these). Reliability is obviously important here, as it has to perform for years to come. Selection criteria include how easy the controller is to program, functionality, quality and ease of maintenance. With specifying a controller, we recommend looking at the following:
Beware Over or Under Specification
If a controller is chosen too early in the design phase of a project, it could add unnecessarily to the cost as it could be over specified. Waiting to select the controller further down the line in the design process makes a lot of sense. Also look out for UNDER specifying a controller, as this could lead to additional purchases required, or delays in the schedule.
Pre-testing your controller choice
Bench testing a controller to know it’s capabilities in advance can save a lot of unnecessary effort down the line. Certainly if you’re asking a controller to do something that you’ve not undertaken before, then undertaking a bench test is better than finding out half way through the project that it just isn’t up to the job required.
Avoid ‘Canned Code’ for your PLC controller
If you’re looking at maintaining and upgrading a system for years to come (and you should be,) then ensure that the programmers have as much input into the structure, classifications and terminology of the code as possible. It’s normal to be ironing out bugs in, and making changes to a new control system and you’ll find that the facility will be on it’s feet much quicker when you’re fully in control of the coding on the new system.
Making sure the systems talk
Communications is key when you’re specifying a PLC. Although things have improved and standardised with ODVA, some sophisticated sensors or peripherals can still present a problem. It’s really important to choose a PLC that has all the device type communications modules. Most PLCs on the market are able to communicate on device buses, but not all can work with every type of Ethernet. Doing your research here can save a lot of problems down the line.
The importance of the Human Machine Interface first
It is best practice to ensure that you start with the HMI (Human Machine Interface) – writing your programming code first may mean that you’ve got to re-write it when you realise it won’t necessarily do what it is required to do to make management easy and efficient, (and even enjoyable), to use.
It is good practice to keep a software configuration control document up to date, so that you have to hand summaries all programmable/tunable parameters. This will be particularly useful with disaster recovery/cyber security issues.