PLC Vs RTU

C

Thread Starter

C S Chandrasekhar

Just wanted a basic clarification.

When should an RTU be used and when a PLC needs to be used for data acquisition/control/automation system. Though the
question looks basic, require some enlightenment on this.

Please pass on the relevant info if this is already/frequently asked.

Thanks in advance.

Regards

Chandrasekhar C S
 
A

Al Pawlowski, PE

This is the kind of question that can go on and on. However, I will put in my (experienced) 2 cents.

IMO RTU's should are almost always a more cost-effective (its always based on total cost right?) solution for data acquisition and remote control. How could it be otherwise, since they are made for the purpose. There are some inexpensive PLC's these days, but RTU's often include the
auxiliary features required, like display, battery back-up support (not just memory), more reasonably priced analog I/O, cheap development
software and low-power operation features.

If the application is mostly sequential/logic type control (lots of discrete vs analog I/O) and data acquisition is just a side operation, a PLC can be a better choice.

That said, there are always the "familiarity with equipment" and stocked spare parts questions. A key feature of most designs is effective system
support. This can be done by having inexpensive functionally replaceable blocks (usually the advantage of RTU's) or by limiting your component
choice to a small group from a large stable supplier and building up a lot of experience with those components (usually the PLC advantage).
Both situations can work. Which you choose depends on your philosophy and circurmstances.
 
R

R A Peterson

Chandrasekhar C S writes:

<< When should an RTU be used and when a PLC needs to be used
for data acquisition/control/automation system. Though the
question looks basic, require some enlightenment on this. ... >>

Well, a good thing to start with is exactly what is an RTU versus a PLC. A few years ago I would consider an RTU to be a data collector and a PLC to be a controller with the capability of also collecting data. Some RTUs have speciallized functions for recording and collecting data that make it more appropriate for those types of applications. If you want to control something then use a PLC.

In todays world though, the line is blurred. Look at the application and the cost and make an intelligent decision. I think you will find there is not as much difference between the two anymore.
 
R
I would say that PLC should be used when ever you need control decision ability at the site of the I/O. In an RTU system the Master or Brain is not
at the site of the I/O and if you lose your communication Link to the Brain the Remote site or RTU does not have the ability to make a control
decision. Hope this helps a little.
 
R

Robert Phillips

I agree 100% Al. We just evaluated upgrading 13 year old Modbus type RTUs. Coming from a PLC background, I tried very hard to justify plc's but was never able to come close to less than $800 per rtu for:
8 digital in
8 digital out
4 analog in
internal radio modem
Modbus protocol

While the I/O was no problem, PLC's with modbus and radio modem was!

Robert Phillips
Cypress Water Purification
Wichita Falls, Tx
 
A

Al Pawlowski

This may be true in your industry, but Remote Telemetry Unit's have been capable of, and doing, independent control since the days when I started in mine (water/wastewater).

In fact, a SCADA/Telemetry manufacturer I once worked for even had programmable, microprocessor based RTU's in late 1975 which predates the first PLC I can remember.

Even given a certain amount of functional overlap between the two, the real difference is that RTU's came from, and are designed be most cost effective in, SCADA/Telemetry applications. Whereas, PLC's came from, and are designed to be most cost effective in, sequential logic control applications with high discrete I/O point counts.
 
N

Nicholas Lock

To further blur this, some "RTUs" now do have sophisticated stand-alone local control capability, in addition to the communications processing which traditionally distinguished RTUs from PLCs. (So it's a three-way blur: PLC - RTU - DCS)

Kingfisher Series II 'telemetry' for example, is being used in diverse (local) control applications in water, gas, power, broadcasting and general process control applications. It is programmed as a PLC, acts as a PLC, looks like a PLC, and is often used as a PLC. Specialist software modules are used to add routines such as AGA gas flow calculations to the math capabilities.

It doesn't fit all applications - for example I/O scanning faster than 50mSec may not be a good idea. (Although we can do pulse counting & SOE
recording to 1mSec)

Why do we continue to call it an RTU? Because it is distinguished from traditional PLCs by its tremendous communications processing capabilities.
Up to 16 comms ports, multiple protocols, event-driven comms and logging, redundant communications paths and media, etc.

And, many customers do prefer to segregate 'control' and 'communications'. In these scenarios, a PLC will do the control, a Kingfisher RTU will communicate. They are linked via a serial port or Ethernet (usually talking
the PLC's native protocol, otherwise Modbus)

Sorry if this sounds too much like a commercial!


regards,
Nicholas Lock
Manager, Systems Engineering
Action Controls Pty Ltd (Kingfisher telemetry)
[email protected]
Tel: (+61 3) 9535 6200
Fax: (+61 3) 9562 8470

www.action-controls.com.au (Australia)
www.atsionline.com (USA Distributor)
 
R

Robert Lockert

The RTU of today competes very well with a PLC as far as capability, reliability etc. are concerned. The distinction I like to make is in the modularity of the configuration.

A typical brick style RTU/PLC is still an RTU (in my mind) because a component failure more or less requires the replacement of the entire unit. If you blow an I/O card or Com port on a PLC you can usually replace the card and resume operation with the existing program still in place.

Of course the cost of this modularity is often twice the cost of an equally capable RTU. A complete, programmed spare RTU on the shelf is often a viable solution.

Regards,

Bob Lockert
Blocke Communications
Calgary, Canada
 
A

Albert Phair

Further again (its a four way blur)

We distinguish a sophisticated stand-alone unit with local control ability and stand alone capability by calling it an RPU (remote programmable unit). This keeps the distinction between a PLC, RTU, DCS and RPU controllable.

Sometimes you do not require the features of one type of unit to accomplish all of your tasks and one or a combination of the four types may be
acceptable. Ken's open systems objective should allow us all to mix and match - this I will wait and see (although I'm all for it).

All units have their place be it speed, control, security, safety, etc. The type of unit used is dependant on the specifications of the project and the requirements of the user.

Dennis Phair
[email protected]
 
A
I am working on a project that involves connecting a Koyo D2-250 with a Ritron radio using modbus. Any suggestion on the pinout from the seven pin RS 485 to the RS232C?
 
D

Dennis Sieracki

Aaron,

There is no direct way to connect the RS-485 to the RS-232. You must purchase an RS-232 to RS-485 converter. There are a number of companies that offer them, i.e. Omega Engineering, etc.

Dennis Sieracki
Ritron, Inc.
 
M

M. Atay TUGAL

RTUs and PLCs are getting closer in terms of being a programmable controller. But RTUs are designed for communication needs with other stations.

Best Regards,

M. Atay TUGAL
SYS-INC
Ankara, Turkey
 
Top