The panel shows stale current values, a message error, or a command that reacts too slowly to behave like I/O. Start here: a MicroLogix 1400 can issue EtherNet/IP explicit messages, but it is not an EtherNet/IP I/O scanner. A successful MSG instruction does not create a cyclic remote-I/O connection.
Identify the communication model first
Determine whether the application needs occasional data access or deterministic I/O control. Explicit messaging is a request-and-response transaction. The controller initiates each read or write, waits for the reply, and shares its Ethernet resources with programming, HMI, and network traffic.
| Panel or program symptom | Likely cause |
|---|---|
| Values never update and every message fails | Wrong service, object, instance, attribute, route, or destination size |
| Values update during light traffic but become slow during online work | Explicit messages are competing with programming, HMI, or browsing traffic |
| A read works, but implicit I/O cannot be established | The MicroLogix 1400 is not an EtherNet/IP I/O scanner |
| The first returned word is valid but following words appear unused | The device returns a fixed-length buffer containing one useful value |
Attribute 10 returns the wrong item |
A hexadecimal field was entered as decimal; decimal 10 selects , or attribute 16 |
If the process needs a maintained I/O connection, predictable update behavior, connection supervision, or device-defined fail action, stop. Select a controller and architecture that support the device as EtherNet/IP I/O. More MSG instructions will not add scanner capability.
Check which object the target exposes
Read the target device manual before opening the message configuration. Find the documented interface that accepts explicit requests. The useful path may be a PCCC Object, Assembly Object, Register Object, or a vendor-specific CIP object.
- If the device documents PCCC access, test that path first.
- If it documents a CIP object, record the service, class, instance, attribute, response data type, and response length.
- If it documents only implicit assemblies for an I/O scanner, the MicroLogix 1400 cannot consume those assemblies as cyclic EtherNet/IP I/O.
- If control requires a command-timeout parameter, obtain its identifier and valid value from the device manual. Do not infer them from another product.
Assembly data can contain blocks of status and command words, but the presence of an Assembly Object does not turn the controller into an I/O scanner. Explicit access to an object remains polled message traffic.
Choose PCCC before vendor-specific CIP when available
For a Benshaw MXD3 Ethernet communications board, the simpler documented approach is PCCC mode. Configure the transaction as a PLC-5-style read and address the board's mapped files. The cited current values are at N62:1, N63:1, and N64:1.
The same board exposes those currents through CIP Generic messaging:
- Service: Get Attribute Single,
0x0E - Class:
0x69 - Instance:
1 - Attributes:
0x0A, , and - Returned value:
UINT, a 16-bit unsigned word
Enter every CIP field using the radix expected by the configuration dialog. Attribute 10 decimal is 0x0A. Entering requests attribute 16 and returns a different item or an error.
These object numbers and file addresses apply to the Benshaw MXD3 board. For another device, take every path element from that device's manual. Copying the Benshaw values into generic distributed I/O is a configuration error, not a diagnostic test.
Validate the local data table and response length
Point the local Data Table Address at a word element, not a bit. An address such as N7:1 is structurally suitable; an individual bit below that element is not. Match the destination capacity to the full response rather than only the useful field.
The Benshaw CIP attribute read returns 30 bytes even though the desired value occupies the first word. A 30-byte response requires 15 integer words because each integer word holds 2 bytes. Reserve that complete buffer, then use the first word as the returned UINT.
Do not set the receiving area to one word merely because the application consumes one value. That can produce a size error or truncate the reply. Keep each message's buffer separate while commissioning so one response cannot overwrite another.
Create and assign an Extended Routing Information data file when the message configuration requires it. Verify the active Ethernet channel in the MicroLogix 1400 channel configuration instead of copying a channel number from a MicroLogix 1100 example.
Run one read through the decision tree
- Start with one read-only transaction. Select PCCC when the device documents a PCCC mapping. Otherwise select CIP Generic and enter the documented service and object path.
- Trigger the message once. If it completes, inspect the entire destination buffer and compare the first useful word with the device's local display or another known reading.
- If the message errors immediately, inspect syntax first. Check hexadecimal entry, class, instance, attribute, route, destination element type, and destination capacity. Changing timers or repeatedly retriggering the rung wastes time when the object path is wrong.
- If the message remains pending, test communications. Confirm that the configured target address reaches the intended device and that another message is not monopolizing the controller's message resources.
- If the data is correct only under light traffic, measure update behavior while online programming and the HMI are active. Added Ethernet activity can delay explicit transactions because these messages share the controller port.
- Only after reads are stable, evaluate writes. Use the device's documented write service and command format. Add application interlocks, feedback validation, loss-of-communication handling, and a device-side timeout where the product provides one.
Verify the resolving branch under real load
A completed message bit alone is not proof of a workable control link. Verify the data and its update behavior:
- Compare each returned value with the target device's local indication.
- Confirm that
0x0A, , and return the three intended currents on the Benshaw MXD3 board. - Interpret the first word as unsigned data when the device declares
UINT. - Exercise online programming, active HMI displays, and normal network browsing while observing message completion and stale-data detection.
- Remove the Ethernet cable during a controlled test and verify that the application rejects stale feedback and moves commands to the designed state.
- Prove that a failed or delayed explicit write cannot leave an uncontrolled command active.
If message completion or update time changes enough to violate the process requirement, the resolving branch is an architecture change to native EtherNet/IP I/O scanning. Tuning the message trigger cannot give explicit traffic the behavior of an implicit I/O connection.
FAQ
Why does a MicroLogix 1400 MSG work but remote I/O still fail?
The controller supports explicit request-and-response messaging but does not operate as an EtherNet/IP I/O scanner. A successful object read therefore does not establish a cyclic I/O connection.
Why does CIP attribute 10 return the wrong value?
The configuration uses hexadecimal object fields. Enter attribute 10 as 0x0A; entering requests attribute 16.
Why does MicroLogix 1400 explicit messaging become unreliable?
Programming sessions, HMI scanning, network browsing, and other messages share the Ethernet port and can delay explicit transactions. Stop when the measured behavior violates the required update or fault-response time, when the device manual does not define the required object, or when control cannot be made fail-safe; escalate with the controller program, message status, full object path, destination layout, device make and model, and network test results through the manufacturer's official support channel.