Click the blue text to follow!

Old Li Talks About PLC Function Block Programming: Making Devices “Understand Each Other”

A few days ago, Xiao Wang asked me: “Old Li, why can’t our new Siemens PLC connect with that Japanese Mitsubishi one? I followed the manual, but it seems like the devices can’t ‘understand’ each other.” I couldn’t help but laugh: “Isn’t this just a ‘language barrier’ between devices? If you don’t understand the interconnectivity of function block programming, this will indeed take some effort.”

Function blocks (FB) are the “universal building blocks” in PLC programming, which can package a bunch of complex logic into a simple module, just like we package various electronic components into a circuit board. Over the past twenty years, my experience in different factories has taught me that different brands of PLCs can communicate, but they need a ‘translator’.

I remember last year when we modified a beverage filling line. The original control system used Siemens S7-300, and later we expanded it with Mitsubishi’s FX series to control the new packaging unit. The two systems were speaking different languages, like two foreigners meeting each other, exchanging glances without knowing what the other wanted to do.

Data mapping is the key technology to connect devices. How to do it specifically? Let me draw a simple diagram for you: first, determine the physical layer for communication on both sides (commonly used are Ethernet or serial ports), and then establish the mapping relationship of the data areas. You can imagine that both sides have a little notebook, where Device A writes “start signal” on the first page, and Device B knows to read this signal from the third page of its own notebook.

Here is a basic communication setup code:

// Siemens S7 communication block configuration example

DATA_BLOCK "Transfer_DB"
{
    UDT_1 : ARRAY [0..31] OF BYTE; // Communication data buffer
    Status : WORD;  // Communication status word
}

In actual factory applications, there was an incident that left a deep impression on me. One night shift, the filling line suddenly stopped, and the alarm displayed “communication failure”. Engineer Xiao Zhang fiddled with the program for a long time, checked all the network cable interfaces, but couldn’t find the problem. Later, I asked him to check the data parity settings, and it turned out that the parity settings on both sides were inconsistent, just like two people speaking the same language but one with a northern accent and the other with a southern accent, which sounded awkward.

The Modbus protocol is the “common language” for communication between industrial devices, and almost all brands support it. It is like a secret language agreed upon by industrial devices; when I say “01”, you must respond with “03”. The rules are simple and clear. Regardless of which brand’s PLC it is, as long as communication follows these rules, they will surely understand each other.

// Modbus read example

MB_CLIENT.MB_ADDR := 1;  // Slave address
MB_CLIENT.MODE := 0;      // Read function
MB_CLIENT.DATA_ADDR := 1000;  // Starting address
MB_CLIENT.DATA_LEN := 10;    // Read length

However, there is a pitfall when using Modbus, which is the address mapping issue. Once, I went to a water plant to debug the system, and they were using a combination of Schneider and ABB, where the address offsets were different. It was like two people agreeing to meet, one waiting in room 101 while the other went to room 201, so naturally, they couldn’t meet.

After working for so many years, I found thatOPC UA servers are the ultimate weapon for heterogeneous system integration. It is like giving all brands of devices a standard interface; everyone connects to this interface, and naturally, they communicate. Today’s smart factories can even push on-site data to the cloud, allowing executives in the headquarters to see the production status of various workshops from their offices.

// OPC UA server configuration snippet

<opc:StructuredType Name="ServerCapabilities">
    <opc:Field Name="MaxArrayLength" TypeName="opc:UInt32"/>
    <opc:Field Name="MaxStringLength" TypeName="opc:UInt32"/>
</opc:StructuredType>

I remember a paper mill where the original DCS system and the later added PLC system were incompatible, making the entire production line feel “dissected”. Operators had to run back and forth between two control rooms. Later, we integrated the two systems using OPC UA, and all the data from both systems was consolidated onto one large screen, allowing operators to monitor everything from just one screen.

Young folks, remember that communication between different brand PLCs is not about how “smart” they are, but about how you make them “understand” each other’s language. Just like people from two countries communicating, if the language is not understood, a translator can be called. Function block programming is about writing this “translation program”, translating the language of Device A into instructions that Device B can understand.

In actual work, I suggest you first draw a data mapping table for the two systems with pen and paper, clarifying which signals need to be interconnected, and then start programming. This can avoid the hassle of making changes later. As the old saying goes: “Sharpening the axe does not delay the work of cutting wood”; spending more time on planning in the early stages will make implementation smoother.

While the concept of “interconnectivity” among factory devices sounds grand, in practice, it is just about making them understand each other’s words and know what the other wants to do. As long as you grasp these basic principles, whether it’s communication between two PLCs or the integration of an entire smart factory, it is merely a matter of “scale”; the essence is the same.