Click the blue text to follow!
Simplified Maintenance Strategies for Smart Home Human-Machine Interface Design Using PLC Function Block Diagrams
Last week, Xiao Zhang graduated from school and came to our factory for an internship. He was assigned to debug the human-machine interface of the smart home control system. After a whole day of work and modifying the program, things got more chaotic, and even the basic lighting control had issues. I couldn’t watch it any longer, so I called him aside and said: “Young man, the PLC human-machine interface is not something you can just change at will; it requires a methodical approach.”
Function block programming is more suitable for complex interface design than traditional ladder diagrams. This is the first lesson I have learned from over ten years of work experience. Many seasoned workers are accustomed to using ladder diagrams, but in projects like human-machine interfaces that require frequent modifications, the advantages of function blocks become apparent.
I remember last year we took on a smart control project for a villa, where the owner frequently changed requirements. If we had used ladder diagrams, it would have taken half a day just to clarify the logical relationships. After using function blocks, modifications became much simpler. It’s like building with blocks; you can change any piece without affecting the overall structure.
Xiao Wang, don’t think that just because I’m older, I haven’t kept up with new technologies. In the smart home system, functions like temperature control, lighting, and security can all be encapsulated into independent function blocks. Each function block acts like a little assistant, responsible for specific tasks without interfering with each other.
FB_RoomControl(
rTemp := rRoomTemp, // Room temperature input
bLightOn := bLightStatus, // Light status
bWindowOpen := bWindowSensor // Window status
);
Assigning a unique identifier to each function block is particularly important. Just like every employee in a factory has an employee number, otherwise, it becomes hard to distinguish who is who when there are many. We are accustomed to using the naming convention “FB_Area_Function” so that it is clear what this piece of code does at a glance.
FB_LivingRoom_Light();
FB_Kitchen_AirCondition();
FB_MasterBedroom_Curtain();
Xiao Wang often made mistakes when he first started learning because of the chaotic function block calls. I taught him a trick: draw a block diagram! First, sketch out the relationships between the function blocks of the entire system on paper, showing which module calls which, and what the inputs and outputs are. This is much clearer than looking directly at the code.
Last month, Mr. Zhang’s smart system was being modified, and he requested that the living room lights automatically adjust based on outdoor brightness. If we had used the old method, we would have had to redo the entire program. With function blocks, I only needed to add a light sensor function block and connect its output to the input of the lighting control block, and it was done in half an hour.
Variable grouping management is key to improving maintenance efficiency. In our factory, we have a rule that global variables and local variables must be strictly separated. Global variables are prefixed with “G_” and local variables with “L_”. At first, it seemed cumbersome, but after a while, it proved to be very worthwhile. When a system has issues, just by looking at the variable names, you can tell how extensive the impact is.
This year, just before the Spring Festival, we had a villa project that was rushed. Five of us were modifying the same system simultaneously. If it weren’t for the good variable management done beforehand, it would have been a complete mess. Everyone modified their own modules without any conflicts.
// Global temperature setting variable
G_rTempSetPoint := 25.5;
// Local light status variable
L_bLightStatus := TRUE;
Decoupling human-machine interface elements from PLC variables allows for more flexible modifications. What does this mean? It means that the buttons and displays on the interface should not be directly bound to the internal PLC variables, but rather go through intermediate variables. This way, if the interface changes, the underlying program does not need to be modified; if the program is adjusted, the interface can remain unchanged.
I remember one night shift, an owner suddenly requested to change the temperature display on the touchscreen from Celsius to Fahrenheit. If we had used the old method, we would have had to modify several pieces of code. I used a data conversion function block as an intermediary layer, changing just one formula, and the display immediately switched to Fahrenheit without altering the underlying control logic.
By the way, there are also tips for testing. After each modification, run it on an offline simulator first. We have an unwritten rule in our factory: for every function modified, at least three operating conditions must be tested. Normal operation, extreme conditions, and fault states must all be covered. This may seem time-consuming, but it actually saves a lot of trouble during on-site debugging.
Xiao Wang, if you learn these techniques, you will avoid many detours. PLC function blocks are not some esoteric technology; the key is to apply them flexibly. Think more about the system structure and less about individual instructions. Consider how the various modules cooperate, and don’t get bogged down in how to implement a single function. Those seasoned workers in the factory may seem to not understand new technologies, but they have a strong system thinking ability, which is worth learning from.
When you have time, I will teach you some debugging tips; that is the real hard skill!