Data-acquisition choices balance speed and cost
A Control Design reader writes: What data-acquisition (DAQ) sampling rate is accepted for collecting data for troubleshooting purposes on manufacturing or test machines? And what sort of diagnostic tools can be used to gather that data?
Application considerations
Data-acquisition (DAQ) sampling rates will vary depending on the application. While faster rates can be better, there are many considerations to address before determining the best sample rate for a given application.
From the field or data source standpoint, these considerations include:
- How fast are changes at the device or process being measured?
- How fast does the sensor respond?
- How soon do you need to know about a specific event?
At the destination DAQ system, there are additional requirements impacting the sampling rate:
- Will the data storage amount need to be increased?
- Will a faster processor speed be required to maintain data throughput?
- Given the additional acquisition cost, why do we want to capture all that raw data?
These factors add to the raw data acquisition cost and must be evaluated before increasing the sample rate.
Regulatory requirements or system behavior modeling are just a few reasons identified by users for performing raw data acquisition. Further thought should be given as to what raw data is being collected and why it is being collected. For example, with some devices, the application may only need to know if the changes are above or below a specific set-point. Acquiring gigabytes of raw data is not logical or beneficial because it would require additional computing once stored to understand the initial objective, whether it is above or below a specific setpoint.
Figure 2: An embedded SQL client makes an easy connection directly to an SQL database.
Individuals establishing the system’s sample rates must have a good understanding of the specific process and device characteristics. Even though a voltage signal from an electronic circuit can change in a microsecond, the pump pressure it is monitoring may only vary over a time of a minute or so. In this case, there would be little reason for the DAQ sample rate to be much faster than 60 seconds; perhaps a sample rate of 30 seconds is better to indicate the fastest possible system changes.
Choosing the right diagnostic software to perform flexible DAQ is vital to achieving manufacturing floor and corporate C-suite goals. Human-machine-interface (HMI) software can play a role here.
HMI software has been used for many years as a diagnostic tool by monitoring and visualizing equipment and processes. Because of the close connection to industrial automation sensors and controllers, HMI software is also ideally located for supporting data acquisition, where it can acquire raw data from a source device and display, analyze, monitor or store it in a database, providing users with flexible options for establishing the DAQ sample rate on a case-by-case basis from any sources (Figure 1). This allows users to acquire many channels of measurement data from any available sensors and devices, aggregating the data so the information can be examined individually or in context together and enabling better data-driven decisions.
Marcia Gadbois
President and general manager / ADISRA / www.adisra.com
Product quality testing
Data sampling for testing a product for quality can be acceptable at a 1-second rate, but that isn’t true for troubleshooting or acceptance testing. Often sampling in 100-ms range is necessary to look for faults in a new system or a system that is failing for otherwise unexplained reasons. Depending on what you are testing, using a PLC system will give you less that 250-ms sampling rates that can be stored in text files for future use. Many products will allow your sampling in the 500-to-1,000-ms range with features to create and send reports to interested parties. This is helpful for QA type testing but isn’t truly diagnostic. If less-than-100-ms rates are needed, likely you will need to use a specific setup.
Mark Russell
Technical sales enablement specialist / Allied Electronics & Automation / www.alliedelec.com
Figure 3: The MQTT protocol can be used to efficiently share information from devices to the cloud.
Embedded functionality
When troubleshooting, the ideal is to get a sampling rate that is equal to the PLC scan, so that all changes in the logic are captured. In real time for monitoring, controllers with data trace functionality embedded can be used to gather the data for troubleshooting purposes. It is recommended to store this type of data in an SQL database to ensure it can be captured for long-term analysis or be incorporated from other systems. Then the data can be analyzed with a variety of applications for machine learning. An embedded SQL client can make it easy to connect directly to an SQL database without the need for additional hardware or middleware programming (Figure 2). Another useful tool for communicating data is the MQTT protocol, which can be used to share information from devices to the cloud in an efficient manner (Figure 3).
Carrie Lee
Product manager—controllers / Omron Automation Americas / www.automation.omron.com
