What Is a CIP MSG Instruction?
When a controller needs to read or write something that is not in its cyclic I/O - a diagnostic, a configuration parameter, a value in a device it does not scan - the tool is a MSG instruction. It is the practical, in-program face of CIP explicit messaging. This page explains what a MSG instruction is, how it is constructed from a service and an object path, and how it behaves differently from I/O.
CIP MSG Instruction in one line: A CIP MSG instruction is a controller instruction that sends an explicit CIP message - a read or write to a specific object in a target device - on demand rather than cyclically. It is built from a service, an object path (class, instance, attribute), and a target, and it executes when its rung enables it and its previous instance has completed.
How a MSG Instruction Is Built
A MSG instruction is CIP explicit messaging expressed in controller logic. At its core it specifies a service - read or write, or a more specific CIP service - and a path to the target object: the class, instance, and attribute described in the CIP object model. It names the target device, points at a source or destination tag for the data, and the controller assembles all of that into a CIP explicit request. In this sense a MSG instruction is just a friendly wrapper around the class/instance/attribute/service addressing that CIP uses everywhere.
The instruction executes on demand, not continuously. It fires when its rung is enabled and its previous execution has finished, sends the request, and sets a done or error bit when the response returns. It is asynchronous to the program scan: the answer arrives some time after the request, not necessarily within the same scan, so logic must wait for the done bit rather than assuming a fresh value is present immediately. This is the defining behavioral difference from I/O.
A MSG instruction can run connected or unconnected. A connected MSG opens a Class 3 connection and reuses it for repeated executions, which is efficient for a value read regularly. An unconnected MSG sends via the UCMM with no persistent connection, suitable for a genuine one-shot. Choosing between them is the same trade as connected versus unconnected messaging - reuse a connection for repeated access, go unconnected for the occasional.
MSG Instructions Versus Cyclic I/O
The MSG instruction and cyclic I/O are the two ways a controller gets data, and they are not interchangeable. I/O moves a pre-agreed assembly automatically every RPI, low-overhead and continuous. A MSG moves an arbitrary object on demand, higher-overhead per exchange and only when triggered. The rule is to use I/O for the fast, continuous, control-relevant data and MSG for the occasional reads and writes that do not justify a permanent I/O connection - the split laid out in implicit versus explicit messaging.
The classic misuse is a bank of MSG instructions polling values that change fast, effectively rebuilding cyclic I/O out of explicit messages. It works at low rates and then overwhelms the device and the network's explicit-message capacity as the rate climbs, because explicit traffic does not scale like implicit I/O. If a value must be continuous and timely, it belongs in the assembly and the I/O connection; a MSG loop is the wrong shape for that job.
MSG Instructions in the System
In practice, MSG instructions are how a controller reaches data that no assembly carries: reading a device's fault counters for a maintenance display, writing a configuration parameter during commissioning, or exchanging an occasional command with a peer controller. Each of those is a legitimate on-demand need, and the MSG instruction handles it without dedicating an I/O connection to data that rarely changes.
The values a MSG reads become ordinary controller tags, and from there a monitoring platform such as Merobix reads them like any other tag; SCADA does not issue MSG instructions itself. So when a maintenance value appears in SCADA that clearly is not part of the fast I/O - a device diagnostic, a firmware revision - a MSG instruction in the controller is usually how it got there. Diagnosing a stuck or erroring MSG (a wrong path, an exhausted connection pool) is a controller-side task, read against the CIP general status codes the instruction returns.
Frequently Asked Questions
What does a MSG instruction do?
It sends a CIP explicit message - a read or write to a specific object in a target device - on demand from controller logic. You specify a service, an object path of class, instance, and attribute, the target device, and a data tag. It executes when its rung enables it, then sets a done or error bit when the response returns, reaching data that cyclic I/O does not carry.
How is a MSG instruction different from I/O?
I/O moves a pre-agreed assembly automatically every RPI, continuously and with low overhead. A MSG instruction moves an arbitrary object on demand, only when triggered, with higher per-exchange overhead and asynchronous completion. Use I/O for fast continuous data and MSG for occasional reads and writes. Polling fast data with a bank of MSG instructions overwhelms the device as the rate climbs.
Should a MSG instruction be connected or unconnected?
Connected for repeated access - it opens a Class 3 connection and reuses it, which is efficient for a value read regularly. Unconnected for a genuine one-shot - it sends via the UCMM with no persistent connection. Using unconnected for a steady stream of reads wastes effort, while leaking connected MSGs can exhaust the device's connection pool, so match the mode to how often the message runs.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.