Click the blue text for more exciting information
Enhancing Flexibility in IoT Applications through Object-Oriented Programming in PLCs
To be honest, I have never understood why so many people think that PLC programming must use ladder diagrams. What era are we in, still drawing relay logic? After nearly 20 years in this field, those who can only draw ladder diagrams are truly rigid in their thinking. Last year at a dyeing factory in Suzhou, I used Siemens S7-1500 to create an object-oriented control system, which improved efficiency several times and made maintenance much simpler.
What are the advantages of object-oriented programming? It’s simple: high code reuse and clear structure. The traditional PLC programming with those cumbersome FB blocks and a plethora of variables means that changing one thing can affect everything. Every time we hire a new person, they look completely confused at the old code, and training them is quite a hassle. In the 2018 project at a chemical plant, the foreign equipment had hundreds of FB blocks with chaotic naming, and debugging nearly drove me crazy.
In the summer of 2021, I started experimenting with object-oriented programming on the Siemens platform. At first, it was quite a hassle, and it felt a bit cumbersome. Goodness, this TFA programming software sometimes lags terribly, taking several minutes to compile. I even doubted whether my computer was too outdated… Later, I switched to a machine with 16GB of RAM, and it improved a bit.
Speaking of IoT applications, object-oriented programming is truly advantageous. Just think about it, a factory with dozens or hundreds of sensors, would you program each one individually? With object-oriented programming, you can handle it all with a single class and instantiate it. In the project I did at the paper mill, the number of temperature sensors expanded from over 30 to more than 100, and I didn’t change a single line of code; I just increased the number of instances, and the boss was amazed. The traditional method would require copying dozens of FB blocks and changing parameters dozens of times.
FUNCTION_BLOCK SensorClass
VAR_INPUT
RawValue : REAL; // Sensor raw value
Status : BOOL; // Sensor status
END_VAR
VAR_OUTPUT
ProcessedValue : REAL; // Processed value
Alarm : BOOL; // Alarm status
END_VAR
VAR
Threshold : REAL := 85.5; // Default threshold, can be overridden
END_VAR
// Main processing logic
ProcessedValue := RawValue * 1.05; // Increase by 5% for calibration
Alarm := ProcessedValue > Threshold AND Status; // Trigger alarm only when the sensor is normal
Look at this simple example, a sensor class instantiated 100 times results in 100 sensors, each of which can be configured with its own threshold. Previously, I would have had to manually copy and paste the FB block 100 times and then name each one, which was incredibly tedious.
Another benefit is inheritance. Last year, I took on a renovation project at an automotive parts factory. Their original system was an old AB PLC, and the programming style was chaotic. Without hesitation, I used Siemens S7-1500 to create an object-oriented renovation, directly deriving four different types from the basic sensor class. My friend, if there was a problem on the line, I only had to modify it once in the base class, and all derived classes would update. Isn’t that great? Moreover, it integrates perfectly with IoT platforms, ensuring data structure consistency and making packaging and unpackaging much easier.
Those PLC training institutions online always talk about how simple ladder diagrams are and how difficult ST language is.That’s nonsense! ST language is ten times more efficient than ladder diagrams. Don’t even get me started on domestic PLCs; their programming software often malfunctions, and if you lose power right after finishing the program, it’s all gone, which is infuriating. Siemens and AB are still reliable; they may be a bit expensive, but their industrial stability is truly commendable.
The biggest pitfall in IoT projects is protocol conversion and communication timeout issues. In last year’s project, I implemented a simple jitter compensation algorithm within a class method and instantiated it on critical devices. The effect was immediate, preventing frequent false alarms. The traditional method would require copying this logic hundreds of times, and modifying it would be a painful experience. Sometimes the entire system’s performance bottleneck lies here, causing severe control delays.
Speaking of interfaces, object-oriented programming is truly convenient; once you define the interface, you can change the underlying implementation at will. A few months ago, I went to an electronics factory in Guangdong to help them upgrade their equipment. Using object-oriented refactoring, the original broken system required three days of downtime, but I only needed four hours this time, and the boss was so pleased that he gave me a bonus on the spot.
Honestly, the biggest advantage of object-oriented programming in PLCs for IoT applications is flexibility. System expansion and maintenance are incomparably better than traditional methods. However, it does require a higher skill level from programmers; older electrical engineers might not accept this programming style and get overwhelmed by concepts like classes and inheritance. The younger people I train learn quickly, probably because they have studied languages like C# and Java in college.
In summary, on-site practical experience has shown me that object-oriented programming can significantly improve development efficiency and system stability in IoT applications. Those who are still using traditional hard coding methods will eventually be eliminated. Don’t talk to me about Industry 4.0; if you can’t even use object-oriented programming, how can you discuss digital twins? First, master the basics before moving on.
Let’s keep watching
