Table of Contents
ToggleA single MSG block sitting quietly in a rung can move a recipe between two controllers, or it can silently freeze a scan, overwrite another message in flight, and leave a program acting on data that never actually arrived.
Understanding MSG Instructions in PLC Programming properly means knowing both the configuration mechanics and the failure modes that only show up once the system is running for real.
MSG Instructions in PLC Programming move data between controllers over a network rather than a local backplane, and getting the message type, triggering logic, and status bits right is what separates a reliable exchange from a hidden production headache.
That flexibility is also the catch, since an explicit message consumes scan time, a communication resource, and a chunk of program logic that has to track when it actually finished and whether it actually succeeded.

4 Message Types Behind MSG Instructions in PLC Programming
Picking the wrong type is one of the most common early mistakes, since a PLC5 typed read aimed at a modern ControlLogix tag simply fails rather than quietly falling back to something that works.
Configuring the Instruction: Tabs Worth Understanding
A mismatched data type between the Tag tab and the actual remote tag is one of the quieter configuration mistakes, since it can produce a completed message carrying garbled or truncated values instead of an outright error.
Status and Error Bits That Tell the Real Story
| Bit | What It Actually Means |
|---|---|
| EN (Enable) | The rung enabling the instruction is currently true |
| ST (Start) | The message has been accepted and handed off to the communication system |
| DN (Done) | The message completed successfully and the transfer is finished |
| ER (Error) | The message failed, with an accompanying error code explaining why |
| TO (Timeout) | The target device never responded within the configured time window |
| EW (Error Warning) | Marks that an error code is present and worth checking before retriggering |
A program that only checks DN and never checks ER or TO is effectively flying blind, since it treats a silently failed message the same way it treats one that actually succeeded.
Triggering Habits That Avoid Duplicate Sends
Connected vs Unconnected Messaging
Connected Messaging
Reserves a dedicated resource for the life of the message, giving more predictable timing at the cost of holding that resource open.
Unconnected Messaging
Shares a common message pool across the whole controller, using less overhead but competing with every other unconnected request in flight.
Choosing connected messaging for a frequent, time sensitive exchange and unconnected for an occasional one is usually the right split, rather than defaulting to whichever the wizard happens to suggest first.
Where MSG Instructions in PLC Programming Get Used on the Floor
Common Error Codes Worth Recognizing
When the ER bit sets, the instruction also reports a numeric error code, and recognizing the common ones saves a lot of guesswork during commissioning and troubleshooting.
| Error Code | What It Usually Points To |
|---|---|
| 16#0001 | Connection failure, often a wrong path or a device that is offline |
| 16#0004 | Invalid segment or path syntax entered on the Communication tab |
| 16#0005 | Path destination unknown, typically a wrong slot or IP address |
| 16#0203 | Connection timed out, matching a set TO bit on the instruction |
| 16#0301 | No available connection resources left in the controller's pool |
That last code is exactly why watching Cache Connections usage matters, since a controller that quietly runs out of connection resources starts failing brand new MSG instructions rather than the ones already established.
A program that logs the error code alongside a timestamp whenever ER sets gives a technician something concrete to search against, rather than a vague complaint that a message occasionally fails for no obvious reason.
Risks That Turn a Working MSG Instruction Into a Problem
None of these risks mean MSG instructions in PLC programming should be avoided, they mean the instruction deserves the same disciplined error checking given to any other communication path in the system.
A Practical Checklist Before Trusting an MSG Instruction in Production
A short commissioning review that walks through each of these points before a new MSG instruction goes live catches a surprising share of the problems that would otherwise surface months later as an intermittent nuisance.
Documentation Habits That Save the Next Troubleshooting Session
An MSG instruction rarely fails the day it is commissioned, it tends to fail months later when a network changes, a device gets swapped, or a controller firmware update shifts a default timeout somewhere in the path.
None of this documentation takes long to write the first time, and it consistently turns a multi hour troubleshooting session into a five minute check against a known path and a known configuration.
Watch: PLC Allen Bradley's MSG Instruction
MSG Instructions in PLC Programming Questions Engineers Ask
Related Articles on This Site
- Communication Protocols in PLC
- PLC Diagnostic Status Bits
- PLC Data Move Instructions
- Types of Allen Bradley PLCs
- PLC Fault Handling, Major and Minor Fault Codes
External References
What We Learn Today
- MSG Instructions in PLC Programming cover four main message types, from CIP Data Table Read/Write to legacy block transfer formats.
- Checking EN, DN, ER, and TO together is what separates a program that truly knows a message succeeded from one that only assumes it did.
- Real risks like message collision, stale data, and unauthenticated commands deserve the same review given to any other communication path.
