Click the little blue text to follow!
Practical Troubleshooting of PLC Instruction Tables in Data Acquisition
Last Friday, the newly installed automated production line in the workshop suddenly alarmed and stopped. Xiao Wang hurried over to find me. “Master Li, the main control computer shows no data, the program is still running but no production parameters are visible!” I put down my work and smiled, saying, “Don’t worry, let’s not mess around. First, let’s check the root of the PLC data acquisition issue.” Such faults may seem complex, but once you grasp the key points, they can be resolved in ten minutes.
PLC data acquisition is the foundation of factory informatization. No matter how advanced the MES system is, if the underlying data is inaccurate, everything above is just a castle in the air. After more than a decade of hands-on experience, I’ve found that many engineers have only a superficial understanding of PLC communication and data acquisition. Today, let’s discuss this topic.
Our workshop uses the Siemens S7-1200 series PLC, and data acquisition mainly relies on the Modbus TCP protocol. The first step is to check the communication status. I opened the instruction table monitoring interface of the main unit and found that all the data area flags were red.
“Look, Xiao Wang, the instruction table is the first checkpoint for checking data acquisition issues. Although it seems simple, it can quickly reveal the problem.” I pointed to the DB data block on the screen and said, “Let’s first check if the communication flags are set correctly.”
// Communication flag check
M100.0 // Communication heartbeat bit
DB20.DBX0.0 // Data valid bit
DB20.DBW2 // Error code area
In the past, I also made the rookie mistake of directly checking the communication lines or network settings when encountering problems, only to waste half a day and finally discover it was a problem with the program itself. Now, I habitually check a few key bits in the instruction table first, which saves time and effort.
“Master, with so much data in this instruction table, which ones should we look at?” Xiao Wang asked, scratching his head.
“Remember, data acquisition faults can be divided into three categories: communication faults, address mapping errors, and data conversion anomalies. Communication faults are the most intuitive, as the instruction table directly shows red alarms; address mapping requires checking the data area definitions; data conversion requires checking if the variable types are consistent.”
In the second step, we checked the data area definitions. Opening the PLC program, we found that after last week’s software upgrade, the data structure had been adjusted, but the address mapping in the OPC server had not been updated. Based on past experience, to avoid such issues, ensure the following three points are addressed:
// Common data area structure definition example
DB20.DBW0 // Status word: Bit0 communication normal, Bit1 data valid
DB20.DBW2 // Error code
DB20.DBD4 // Production count (DINT)
“Remember, after the structure of the DB data block changes, all related systems must be synchronized. This includes not only the upper computer but also HMI, data gateways, and edge computing devices. Last week’s upgrade failed to address this, resulting in a change in data structure while still using the old configuration for the acquisition address.”
I pulled out my notebook and flipped to the data area comparison table for the Siemens S7-1200, pointing to one page and saying, “Over the years, I’ve summarized a quick troubleshooting method: first check the key indicator lights, then check the communication status words, and finally check the physical connections and network. Many times, I’ve resolved issues in ten minutes using this method during emergency repairs at night.”
In the third step, we investigated data conversion issues. The production count in the on-site system used the DINT type (double integer), but the data acquisition system was configured as WORD type (16-bit unsigned integer). This type mismatch can easily lead to overflow with large data volumes.
“Xiao Wang, let me tell you about a personal experience. Once, the production count in the workshop inexplicably dropped by several thousand pieces, and the boss thought the workers were secretly reducing production! Later, we discovered it was due to a mismatch in data types causing high-order data loss, which resulted in the count overflowing and resetting after exceeding 65535. This incident teaches us that the choice of data type may seem trivial, but it has significant implications.”
We quickly modified the address mapping table in the OPC server, matching the incorrect addresses to the new data structure, and adjusted the data types. In less than 10 minutes, the system alarm was cleared, and data was displayed again on the production monitoring screen.
“Master, that was amazing! In the past, we would have to call the equipment manufacturer’s engineer to handle such faults, which would take at least half a day,” Xiao Wang said in admiration.
“Actually, it’s nothing special; it’s just a matter of experience. Remember what I said, when troubleshooting PLC data acquisition issues, the instruction table is the most important tool, as it contains all the clues to the faults. If you don’t believe me, try it in the future; with the instruction table, the efficiency of fault elimination can increase by more than five times.”
Xiao Wang nodded and diligently noted these key points in his notebook.
Over the years, I’ve trained many apprentices, and the most common thing I say is: PLC programming is not difficult; the challenge lies in knowing where to start when problems arise. Start with the instruction table, then refine the problem, and there’s basically no fault that can’t be resolved. No matter how complex the automation equipment in the factory is, the underlying logic is actually quite simple. As long as you master the method, you can handle it with ease.
