I don't do that much work with PLC equipment so I'm basically a rookie at application and installation. With that being the case:
QUESTION: Do PLCs often serve as redundant devices? Can one be a "master" with another the "slave"? One more, are PLCs ever used for "pilot duty" enabling other pieces of electrical equipment to function; i.e. start/stop?
While I agree with the majority of the posters that there is no one correct answer, I would recommend that the original questioner follow up on the idea presented in the article by Doug Huffman. A lot of the major PLC manufacturers have a number of options for redundant processors and / or power supplies, depending upon what the most likely failure mode in the plant is. These can go so far as to include hot redundancy that will automatically keep everything running when one fails. The cheap and easy course of action (if you can live with some downtime while a tech. takes care of the problem) is just having a spare / programmed processor stored in the cabinet. I have seen that done with a bit of success as well.
"When your only tool is a hammer... all your problems start to look like nails"...
Don't make PLCs your only tool (solution to everything)...
My simplest observations:
- for building automation ... distributed controls (PLC, Custom or specifically made for the application - but for multiple customers/sites) .. the wiring architecture is likely more important than the pieces involved. Unless mutiple campuses are involved (10,000+ I/O points).. then other issues become dominate (software architecture).
- for process automation ... too many variables - depends
- for machine controls.. product volume drives the answer (most of the time). What has changed recently, the volume for custom or semi-custom has a much lower threshold than in the past. I can often make a case for custom solution with volumes of less than 50 units / year. In this environment, having a single (easy to trouble shoot) control board can make field maintenance become a driving factor.
- everything else.. depends
My point: be aware of the ALL the options and DON'T ASSUME TOO MUCH.
The costs for each hardware option are changing all the time.
There is a cost to maintaining the software for each option and the assumptions for this cost are changing also. In some systems, a PLC can demand a full time software effort (constantly changing environment). This MAY be better handled with Custom configurable software than custom PLC software. Reason: configuration changes on some software will not require regression testing before being put into place. Just depends.
I'd agree with the idea of there is no simple answer for this. It always depends on the nature of the application. You always have to consider things such as I/O counts, cycle times, physical sizes and areas, failure risks, BUDGET, etc. High-end PLC's can run multiple control sequences concurrently, you can mount multiple CPU's on a single rack, and I/O networking is a very convenients means for wiring and sharing I/O.
For failure, even if you partition areas of an operation into multiple PLC's, failure of a critical PLC can still hamstring the entire operation. You still have to plan for operating with a critical failure until the failure can be repaired. So, you always need a full analysis of the risks. There will always be the situation that you didn't think of, but you should be prepared for the one you do think of
For my 'tastes', for a simple standalone application where failure is an incovenience (think, say an automated car wash), use the single cheapest controller that will work, with standard wiring.
For larger applications, always plan for the future by leaving cabinet space and power capacity for additional PLC's (possibly by at least leaving panel space for a new rack). I/O networking (Ethernet/IP, ProfiNet, etc.) make adding I/O much easier... Also, plan for ethernet access to operations from MES, management, etc. Once plants get a taste for data, they always want more...
In many instances it is better to have multiple PLCs, especially if the process exists in multiple blocks that are not interwoven. In the brick making example, one controller for mixing, one for forming and handling green product, one for running the kiln and kiln conveyer system, and one for handling the logistics of unloding and storage. On top of other advantages, simpler programming and the ability to run the individual processes manually are major benefits. In addition, if a connon PLC type was selected for all the sections, one spare could provide complete backup capability for a lower cost.
Of course, designing the hand-shake between controllers would be an extra task, but the effort would not be as much as the advantage gained.
Given the nature of multi-tasking operating systems and more advanced hardware, I expect the devil is in the details. What types of tasks must be managed from one platform? What are the overall hardware and processing resources required, etc. for the complete set of tasks. I think normally one question is how complicated the application software becomes in terms of maintainability and expandability into the future. Interesting question.
Rich, in an application like PLCs it is probably better to opt for multiple units. This allows the modification of different parts of a plant without affecting others. PLCs will probably not be the major cost driver.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.