Understanding the Roles of Data Loggers, RTUs, PLCs, and PACs

通过 Jacob Davis | 更新: 02/28/2018 | 评论: 1

搜索博客


订阅博客

出现新文章时获得邮件。选择您感兴趣的主题。


Area / Application

Product Category

Activity

输入您的邮箱地址:



推荐文章

您是否想了解一个主题更多?请让我们知道。

Leave this field empty

A datalogger, RTU, PLC, and PAC

Now and then, someone will ask if a Campbell Scientific data logger can be used in place of a PLC (programmable logic controller) or an RTU (remote terminal unit). Admittedly, it is not a simple question to answer. The capabilities of modern PLCs, RTUs, and data loggers often overlap, making it difficult to classify a device strictly as one of the three. To make this less confusing, I will describe these three roles conceptually, as well as how Campbell Scientific data loggers can fill these roles. In addition, I will briefly describe PACs (programmable automation controllers), which you may have heard of.

What is a data logger?

A data logger is a device that can perform measurements and store time-stamped data. An internal clock is the primary input to determine when to make the measurements. Other criteria, such as a measured value, may trigger the data storage. A user can retrieve logged data from the device, as well as review data from the past.

Our focus has always been to create hardware that can reliably make accurate measurements—even in extreme environments. Because Campbell Scientific data loggers need to operate autonomously without user interaction for extended periods, they run a custom real-time operating system with a flexible programming language. (Please note that data loggers from other manufacturers may not have all the same features.) To avoid confusion, for this discussion, I will simply refer to the CR1000X Measurement and Control Datalogger. The CR1000X possesses an accurate clock, makes reliable analog measurements, logs the data, and is designed for low power consumption.

What is a PLC (programmable logic controller)?

The focus of a PLC is on operating simple control loops. It reads sensors but only holds the current set of readings. A PLC can make a quick response with a control output. The device must be reliable and operate in a predicable manner. Standardized programming languages for PLCs are logic based.  Communication is back to a client, which could be directly to a SCADA computer or to an RTU. Some PLCs are very simple process controllers with one input and one output. Other PLCs are rack-mounted modular installations with hundreds of channels.

The CR1000X often can fill the role of a PLC. Control loops are possible using the CRBasic programming language, meaning that a trained SCADA engineer would need to learn CRBasic and use it instead of the standard PLC languages. The CR1000X is fast enough for many control applications. Some parallel control applications would require more speed.

What is an RTU (remote terminal unit)?

An RTU reads inputs (such as from sensors), has programmable logic to change outputs based on inputs, and reports back to a client controller. The client controller is traditionally a computer running SCADA (supervisory control and data acquisition) client software. Programming languages for RTUs allow for more flexibility than on a PLC. Typically, an RTU can continue its operation, even in the event of communication loss back to the client. Some RTUs are small integrated units with a few channels, and other RTUs are rack-mounted units with hundreds of channels.

The CR1000X easily fits the role of an RTU. It supports Modbus and DNP3 standard protocols often used for communication to RTUs. One concern, however, is to check the needed signal levels of the sensors and outputs. Industrial applications often use large voltages or current loops for noise immunity. The CR1000X may need TIMs (terminal input modules) or SDMs (synchronous devices for measurement) to fill the application’s needs. Expansion modules, such as SDMs and CDMs (Campbell distributed modules), can increase the number of inputs and outputs.

What is a PAC (programmable automation controller)?

Some new industrial devices are being classified as PACs. The term basically means a PLC with enough programming capability to take the place of a SCADA PC. With its ability to be a Modbus client device, the CR1000X closely fits the definition of a PAC. The CR1000X, however, lacks the support of other common industrial protocols.

Price Comparison

There is a large variety of PLC and RTU models. As such, there is a very large price range. The CR1000X is more affordable than some of these units. What really matters, however, is whether the device you use has the features you need for your application. When you only need a simple process controller, a small PLC is much more affordable than a CR1000X. If you need multiple analog channels and communication flexibility, a CR1000X can be very price competitive.

Additional Features in Campbell Data Loggers

There are some additional features in Campbell Scientific data loggers not found in traditional PLCs, RTUs, or PACs. These features may solve problems you can't with other devices. Some notable features are low power consumption, remote telemetry options, and greater sensor compatibility. If you encounter a problem you can't solve with a PLC, RTU, or PAC, look into a Campbell data logger.

Conclusion

I hope this article has clarified some of the differences between the various data acquisition and control roles. The CR1000X is a very capable and versatile data logger, able to fill many measurement and control roles. Other Campbell Scientific data loggers, such as the CR300 and CR6, also have this flexibility. Please share below your experience using Campbell Scientific equipment in roles other than just data logging.


分享该文章



关于作者

jacob davis Jacob Davis is the Director of Client Services and Support at Campbell Scientific, Inc. He works with the worldwide technical support teams. His specialties include serial communications and advanced data logger programming. Jacob has a master’s degree in hydrology and worked with large irrigation projects before coming to Campbell Scientific, Inc.

查看该作者的所有文章


建议

rlwoell | 02/28/2018 at 08:38 AM

I use a variety of data loggers from CSI, but mostly CR1000's and CR9000's.  (I started out with 21x's, 23x's and 10x's.)  When engineers or managers ask me if I can perform a certain task with a data logger, I tell them if they can describe with a flow chart what they want done, I can program a logger to do it.

The beauty of using a data logger for running a test is that if the test shuts down for some reason you can have a history of the measurements.  That will help you diagnose the cause of the shutdown and maybe prevent it from happening in the future.  This is important for tests that need to run unattended 24/7.  Add a voice synthesized modem to initiate "help" calls and you have a system that will deliver maximum up time.

Please log in or register to comment.