Click the blue text for more exciting information
Remote Monitoring Solutions for Industrial Automation Driven by PLC Function Block Diagrams
Just two days ago, I received a call; Old Li’s paper mill had another problem. He insisted on using that cheap domestic RTU for protocol conversion last time, and now, well, it keeps dropping connections every few days, data is flying away, and he’s come to me for help with a long face.These days, everyone wants to save money, but it ends up causing big problems! I rushed over to take a look, and sure enough, the communication was completely down, and everyone was dumbfounded.
Remote monitoring, to put it simply, is about getting on-site data to the upper-level system. Many people think it’s easy; just buy a cheap module and connect it, and that’s it.What a naive thought! I’ve been in this industry for 17 years, and I’ve dealt with at least 80 incidents of factory site disconnections, data anomalies, and unstable signals. It’s not that simple!
Back to the point, the key to industrial automation remote monitoring lies in three aspects: protocol matching, data structure design, and reliable communication. In 2018, I worked on a project at a power plant in Nanjing, where the Siemens S7-1500 was directly connected to the management network using a TCP module. The result? Major security risks! Later, I had to redo it, adding a layer of isolation. The boss was furious, but in the end, he accepted my solution, didn’t he?
The design of function blocks is the lifeblood of the entire monitoring solution, which many half-baked engineers simply do not understand. They always like to do things their own way, resulting in messy data blocks and tag names that are like guessing games. Last winter, I went to a parts factory to put out a fire; the kid’s function block design had variable names like A1, B2, and not a single comment. I spent a whole day just sorting out that pile of broken logic.
// The following is my commonly used communication diagnostic function block, capable of catching 90% of communication issues
FUNCTION_BLOCK CommDiag
VAR_INPUT
Enable: BOOL; // Enable signal
MsgTimeout: TIME := T#10S; // Timeout setting
END_VAR
VAR_OUTPUT
Status: BYTE; // 0=normal 1=disconnected 2=noise interference
LastError: DINT; // Error code, just use the old AB error code table
ReconnCount: INT; // Reconnection count statistics
END_VAR
You might ask why not use standard protocols like OPC UA? My friend,the ideal is beautiful, but reality is harsh. In 2022, at a steel plant in Hebei, a few clueless kids in the IT department insisted that OPC UA was the best. After two months, the system was as slow as a snail, and the CPU usage soared to 90%. I told them that this thing was too burdensome for on-site controllers, but they didn’t listen. In the end, didn’t they come back to me, all embarrassed, to redesign the solution?
Remote monitoring requires a balance. Too little data, and monitoring is incomplete; too much data, and bandwidth is insufficient.Don’t be foolish and upload all data points; that’s something only amateurs do. I usually start with data analysis: Class A key parameters are collected every 100ms, Class B process parameters every 1s, and Class C statistical parameters every 10s, processed in tiers. This way, the data volume is reduced by 80%, and system stability increases significantly.
By the way, there’s another thing. Speaking of function block design, the most annoying are those who don’t consider fault handling. Recently, I went to a shipyard in Qingdao, and in someone else’s PLC program, when communication was interrupted, there was no prompt at all. The system kept running, storing data to transmit later.This kind of brain-dead design is a time bomb! How do you know when communication will be restored? What if it takes a week to recover? The data would pile up like a mountain!
I’ve used the old Siemens S7-300/400 for over a decade, and the communication part is indeed stable. Although it’s a bit expensive, it can really withstand the test. Those who keep bragging about how much they save with Japanese PLCs have no idea what they’re talking about.I just want to ask you, if the system calls you in the middle of the night to say it’s disconnected, is it worth those few thousand bucks?
// This is my remote alarm module, connected to an SMS modem and WeChat push
FUNCTION_BLOCK AlarmNotify
VAR_INPUT
AlarmTrigger: BOOL; // Alarm trigger signal
AlarmCode: INT; // Alarm code
AlarmLevel: BYTE; // Alarm level: 1=notice 2=minor 3=serious 4=critical
END_VAR
VAR
SMSCmdBuf: STRING; // SMS command buffer
WeChatPushStt: BYTE; // WeChat push status
END_VAR
And those who always think they can modify on-site programs directly from the office, I just want to ask if your brains are soaked in water?Remote programming of PLCs is like performing surgery remotely; if something goes wrong, can you take responsibility? I have always advocated that remote monitoring systems should only be read-only; if writing is necessary, it must go through secondary confirmation and safety checks.
Speaking of remote monitoring, I must mention configuration software. Nowadays, there are so many industrial software solutions going to the cloud, each fancier than the last, but in practice, they’re a mess. I used to use KingView, then switched to Intouch, and later just wrote a simple one using HTML5+JS, which turned out to be the most practical. Connecting to the S7-1500 data blocks, just converting to JSON format is enough. These days, how many of those who keep talking about AI and big data really understand it?
Having done many monitoring systems, there’s oneimportant experience: always consider breakpoint resume. During the pandemic in 2020, a soda factory in Wuhan lost internet for three days, and when it was restored, all historical data was lost, rendering the traceability system useless. My monitoring solutions all include caching functionality, starting with 50,000 data points, enough to handle most disconnection scenarios.
Also, HMI interface design is a technical skill. I’ve seen too many flashy monitoring interfaces, with color combinations that look like a five-year-old did them, mixing important parameters with trivial ones,with no ergonomics at all, just adding chaos. I usually start with a sketch, pinpointing key parameters, using no more than four colors, and making warning information prominent. Don’t tell me about aesthetics; the guys in the control room need to see problems at a glance, not admire a piece of art!
Finally, to be honest, when making remote monitoring systems, protocols and communication devices are the foundation, function blocks are the framework, and HMI is the skin; all are indispensable.But the most important thing is to maintain it regularly. I’ve seen too many systems that cost hundreds of thousands to set up, only to be neglected, turning into scrap metal after two years. Spending money is easy, but maintaining a system is hard!
Just a little disagreement, and you’ll see me looking
