We know that for communication between various industrial topologies in PLC programming, various types of instructions are available. One such instruction is a message instruction. It is available with different names in corresponding communication protocols. With this code, you can read and write data from other devices very reliably and efficiently.
MSG Instructions in PLC Programming
But in practical conditions, it is also to be noted that they can become a risk if not handled carefully. In this post, we will see some practical and field-level dangers of using message instructions over industrial communication protocols.
Scan time blocking and task jitter
This is the very first issue that occurs due to the use of message instructions. In many PLC’s, explicit messaging is handled over multiple scans and is not instantaneous, which can impact task timing if not controlled. How they affect depends on the PLC platform. Let us understand this simply in a way that message instructions are either non-blocking or blocking.
In the case of non-blocking, when the network block becomes true, a request is sent to the device for data. The PLC does not stop there and continues its task within the scan time allocated to it. But until the reply comes back for a successful communication, the PLC till then must check that in every scan for update, handle timeouts, manage retrieves, update status bits, and copy data when ready. So even though the message instruction is non-blocking, it consumes CPU time every scan while active. With this, if the network is slow or the device is still busy or multiple such message instructions exist, then the current scan time keeps changing or increasing.
In case of blocking, the message instruction waits for data transfer, and the program execution is paused or delayed if not received. Due to this, the scan time starts to increase more and causes task jitter.
Silent use of stale or invalid data
PLC often uses data from message instructions without knowing whether it is fresh, complete, or even valid. Stale data means data was read earlier, communication later failed, the value in tag did not change and the PLC continues using the old value. This means the logic did not detect any error or fault or warning. So, that logic is now still using the old data present in its variable.
When a programmer designs message instructions and writes in such a way without considering the current time stamp or data valid status, then the logic continues working with the old data. Due to the triggering nature of message instructions, they can leave old or partial data in memory, causing the PLC to make decisions using incorrect information without any obvious fault.
Loss of determinism
The output bit of the message instruction is completely unpredictable. So, writing a logic based on the completion of this bit is risky for plant operations. The instruction is non-deterministic in nature due to packet routing, switch queues, CPU load changes, and other traffic interferences.
So, assuming that the instruction will finish within one scan or before the next step is dangerous for operation. This affects the order and timing of events inside the logic. Message instructions thus introduce unpredictable completion timing, making any timing dependent logic unreliable and intermittent.
Message collision and data overwrite problems
If multiple message instructions share the same control structure, tag or path, then issues occur in functioning. For example, if two instructions use the same control block name, then the status bits get mixed or the data gets copied for both the blocks or worst case, the blocks will not execute at all.
In the second case, if both the blocks use the same destination tag, then there will be no data reliability. If multiple message blocks to the same device are triggered at the same time, then data collision will occur as some data will be missed, replies arrive out of order, or data will come in the wrong values.
Redundancy and switch over
In redundancy or switchover cases, major issues happen in message instructions. Let us consider a scenario where the primary system is running along with the message instruction. And now the primary system fails in between the execution. Due to this, as now a complete new secondary system has taken over, retry never happens and data is lost, as it is executed for the first time now.
The secondary system will now send the same message again and the remote device will be required to respond to get a new request midway. This causes unintended actions in communication now. Due to this, the control bits inside the message block will also show wrong values for the first few scans.
Security exposure
MSG instructions introduce a subtle but serious security and integrity risk in industrial control systems because they allow powerful read and write access across controllers and devices with very limited built-in safeguards. In most PLC platforms, an MSG is trusted implicitly once it reaches the destination, as there is no native authentication, intent validation, or granular access control at the instruction level.
As a result, a misconfigured or copied MSG can unintentionally write incorrect values, overwrite critical tags, or change operating modes without any obvious fault or traceability. This risk is amplified in real plants where laptops, HMIs, gateways, and temporary test systems are frequently connected to the control network, increasing the chance of accidental or unauthorized interactions.
Unlike implicit I/O connections, which are structured, ownership-controlled, and easier to segment, MSGs are flexible and therefore harder to constrain, making them a common source of unintended control actions rather than deliberate cyberattacks. Without explicit validation, logging, and operating-mode restrictions, MSG write operations effectively act as remote control commands, which is capable of altering process behavior silently and leaving engineers with no clear audit trail when something goes wrong.
In this way, we saw the practical problems of using message instructions in PLC programming.
