DCS's are exactly what they sound like - physically distributed along the machine. Classic architecture has all control wiring terminated in a common MCC cabinet (usually) somewhat centerally located. All drives, relays, etc... are mounted in this cabinet, close to the PLC. Distributed architecture has several, smaller PLC's in smaller cabinets with their associated drives and other devices located all along the machine, each responsible for controlling a small section. Each small PLC communicates with the others via any one of a number of network protocols (ControlNet, DeviceNet, etc...) allowing them to work together seamlessly. The programming can be a little more complicated to account for all of the cross-communication, but the reduction in wire runs can account for considerable cost savings and greatly reduced maintenance. Some companies are starting to market hardened PLC's and drives that can be mounted "on-machine" and eliminate the need for enclosures. Otherwise, all the hardware is the same in both architectures. Does that answer your questions?
Thanks for the outline on DCS. You are, however, miles a head of me. I need a sketch outlining the layout of a typical DCS system. I then need detailed eleborations on the particular components, and their functions, that make up the DCS. Take it that I need training from first principles. I understand the PLC. But how are they layed out and how do they communicate. What is the industrial terminology regarding these, e.g. FCU, Profibus,, DataServers, Switches, etc. Please help.
I have not forgotten about you. I'm under a deadline and haven't had time to put a decent sketch together for you. I'll try to get something posted in the next few days. In the meanwhile, I'm rather suprised no one else has jumped in on this...
Okay - let's start with a baseline. Here is a greatly simplified classical architecture:
Heavy lines represent power feeds (normally 3PH), thin lines are control wiring. I left off the power feed to the enclosure. Does all of this make sense to you?
__________________
Aequam memento rebus in arduis servare mentem.
Thanks for the starting point. Yes, it makes sense. We are feeding our motors (Single/3 Phase supply) and we have controls sensors (Speed, temperature, Current, Voltage) from the Motors. We have signals to the motor switches, etc for control. May I have the source of this information which looks at the basic Block diagram of a DCS and expounds on the details of each such component that makes up the DCS. Thanks.
Okay then, here is a simple schematic of a distributed system:
Note the reduced size of each PLC chassis and the addition of a communications module in each. The dotted line represents communication wiring. Type of communication wiring and communication protocols vary with manufacturer. As you can see, the potential reduction in wiring runs is huge and the savings can easily offset the added cost of additional (smaller) PLC's and enclosures. Depending on the machine process, additional programming requirements to get the PLC's to talk correctly (exchange the proper information at the proper time) can be fairly minor to extensive.
Now, here comes the curveball. There is another type of DCS that uses "distributed I/O". In that system, the architecture would look very similar to the above diagram, however, all but one of the PLC's would be replaced with a remote I/O block. Think of it as a device that has the communications card and I/O card combined into one unit (but no processor). Cost savings can be had by only needing one full PLC and one unified program. One would think that this would be the way to go, but here's the rub: device response time is much (much being a very relative term, usually measured in a few hundred micro-seconds) slower. This is due to the fact that commands to the I/O blocks are sent over the communication protocol and not in the PLC's backplane. In some processes, the delay in response time can be crippling.
Does this get you in the direction you were looking for? I know you were asking about some specifics on devices and communications protocols, but that can vary greatly by manufacturer. (And quite frankly, I'm not an electrical engineer, I'm a machine designer who has picked up enough of this to understand how to take advantage of it in the mechanical design.) My suggestion is if you have an understanding of what I have shown here, and an idea of where you want to apply it in your facility, sit down with your supplier and talk about the details. They know their equipment far better than I.
Good Luck!
__________________
Aequam memento rebus in arduis servare mentem.