Practical Dangers of Using MSG Instructions in PLC Programming

Key Takeaways

• Blocking MSGs increase PLC scan time and cause task jitter
• Stale data from MSGs can drive decisions on outdated values
• MSG completion bits are nondeterministic, breaking timing‑critical logic
• Shared MSG blocks cause data collisions and overwrite errors
• Lack of authentication makes MSGs a security vulnerability

Pulse Analysis

Message (MSG) instructions have become a go‑to tool for PLC engineers seeking fast, flexible communication across Ethernet, DeviceNet, or Profibus networks. Their appeal lies in a single‑block call that can read or write remote tags without wiring changes. However, the underlying protocol handling often spans multiple scans, meaning a "non‑blocking" MSG still taxes the processor each cycle while awaiting a reply. In high‑speed or heavily loaded controllers this hidden CPU load can elongate scan times, introduce jitter, and erode deterministic performance that many safety‑critical applications depend on.

Beyond timing, MSGs can silently feed stale or partial data into control logic. Without explicit timestamps or validity flags, a PLC may act on a value that was retrieved minutes earlier, leading to erroneous set‑points or missed alarms. The completion bit, which many programmers treat as a reliable trigger, is inherently nondeterministic due to network congestion, routing delays, and CPU load fluctuations. When multiple MSG blocks share control structures or destination tags, collisions and out‑of‑order replies become common, corrupting data and forcing engineers to implement cumbersome arbitration schemes. Redundancy scenarios amplify these issues; a primary controller that fails mid‑message leaves the standby with an incomplete transaction, potentially skipping critical updates.

Security concerns round out the risk profile. MSG instructions grant unrestricted read/write access once they reach the target device, lacking authentication, intent verification, or granular access control. In environments where laptops, HMIs, and gateways frequently connect to the control network, a misconfigured MSG can unintentionally overwrite safety parameters or change operating modes without any audit trail. Best practices now recommend limiting MSG usage, encapsulating communications in vetted protocols (e.g., OPC UA with TLS), and adding explicit validation and logging around every remote write. By treating MSGs as privileged operations rather than routine calls, plants can preserve deterministic control while mitigating both reliability and cyber‑security threats.