Two M221 controllers can exchange the three required variables through the Modbus TCP I/O Scanner in the Ethernet configuration. Configure one controller as the scanner for the transfer and the other as the Modbus TCP endpoint. This removes the need to execute READ_VAR and WRITE_VAR blocks cyclically. A fiber segment does not change the application protocol; once the Ethernet link passes through the switches and optical path, Modbus TCP operates across it like any other Ethernet connection.
Communication approach selection
Before anything else, separate the requested network medium from the requested application protocol. “Ethernet/IP” can mean ordinary communication over Ethernet or the specific EtherNet/IP industrial protocol. The proposed M221 solution uses Modbus TCP over the Ethernet port, not an EtherNet/IP data exchange.
| Approach | Configuration method | PLC logic requirement | Best fit |
|---|---|---|---|
| Modbus TCP I/O Scanner | Define the remote controller and transfer in the Ethernet parameters | No cyclic READ_VAR or WRITE_VAR calls |
Fixed, repetitive exchange of the three variables |
READ_VAR/WRITE_VAR
|
Build communication requests in application logic | Request triggering, completion handling, error handling, and sequencing | Transfers that must be initiated conditionally or sequenced by the program |
Use the Modbus TCP I/O Scanner for this application. The data set is small and cyclic, and the scanner keeps transaction management outside the control logic. Use explicit communication blocks only when the application must control exactly when each request occurs.
Commissioning prerequisites
- Confirm the physical path. Check link indication at each M221 Ethernet interface and every industrial-switch port in the path. Verify the optical interfaces report a link across the fiber. Do not move on until all required links remain stable.
- Assign the Ethernet identities. Give each M221 a unique IP address compatible with the network design. Check for duplicate addresses before enabling cyclic traffic. Record which controller will initiate the exchange and which will hold the source data.
- Define the data direction. For a one-way transfer, identify one source M221 and one destination M221. If data must travel in both directions, define each direction separately rather than treating the exchange as an unspecified shared area.
- Define the three values. Record each variable’s data type, word length, source location, and destination location. Do not move on until both programs use the same layout.
- Confirm endpoint availability. The destination controller must accept the Modbus TCP operation selected in the scanner configuration. Its application must expose or map the required data area.
I/O Scanner configuration procedure
- Open the Ethernet parameters of the M221 selected to initiate communication and enable the Modbus TCP I/O Scanner.
- Add the other M221 as the remote device, using its configured IP address. Confirm that the address entered here matches the address actually loaded into the destination controller.
- Create a scanner entry for the required direction. Select the operation that matches the transfer: reading source data into the scanner controller or writing scanner-controller data into the destination.
- Enter the remote starting data location and a quantity large enough for all three variables. Base the quantity on Modbus register words, not merely on the number of application variables. A variable wider than one word occupies multiple consecutive words.
- Assign the local scanner data area that the M221 program will consume or produce. Keep this area separate from unrelated control data so that mapping errors are visible during commissioning.
- Set the scanner’s update and supervision options from the engineering tool according to the process response requirement and network loading. Use the displayed parameter names and permitted ranges; no timing value is established for this installation.
- Download the configuration to the initiating M221 and place the controller in the operating state required for scanner execution. Confirm that the scanner entry becomes active before testing application logic.
Three-variable data mapping
Most commissioning failures in a small exchange come from representation errors rather than the network. Build a mapping sheet before programming either controller.
| Mapping field | Required decision | Verification |
|---|---|---|
| Variable order | Place the three values in an agreed sequence | Both projects show the same order |
| Data width | Allocate the correct number of Modbus words per value | The total scanner quantity covers the complete layout |
| Data interpretation | Use matching signed, unsigned, bit-field, or floating-point handling | Known test patterns decode correctly |
| Read/write direction | Match the scanner operation to the controller that owns the source value | Changing the source changes only the intended destination |
| Application handoff | Copy or reference scanner data at a defined point in the scan | The control routine receives coherent values |
Multiword values require an agreed word order. Determine that order with a known test pattern rather than swapping words until a live process value appears plausible. Also prevent both controllers from writing the same destination words; assign one owner for each transferred value.
Ethernet and fiber mechanism
The I/O Scanner generates Modbus TCP requests over Ethernet. The remote M221 returns data or accepts written data according to the configured operation. Because the scanner repeats the transaction, the application receives cyclic data without constructing a new READ_VAR or WRITE_VAR request on every scan.
The described path—M221, industrial switch, optical infrastructure, and the reverse arrangement at the remote end—does not require a different Modbus configuration merely because part of the link is fiber. The switches or optical interfaces transport Ethernet frames across that segment. The splice enclosure provides fiber termination or joining; it does not replace the active optical Ethernet interfaces.
Troubleshoot the path in layers. First confirm copper and optical link state. Next test IP reachability using the diagnostics available in the engineering environment or network equipment. Then inspect the I/O Scanner entry and its communication status. Only after communication succeeds should the application’s data interpretation be investigated.
Verification and recurring faults
- Write three distinctive test values at the source. Choose patterns that expose swapped variables, truncated multiword values, and incorrect signed interpretation.
- Observe the scanner’s local data area online. Confirm that all words update and that the communication status remains healthy across repeated cycles.
- Verify the destination application variables independently. A healthy scanner status proves the transaction completed; it does not prove the program mapped the returned words correctly.
- Disconnect one network segment briefly during an approved test window. Confirm that the controller detects loss of communication and that the application drives dependent logic to its defined stale-data or fault state.
- Restore the link and confirm automatic data recovery without requiring a controller restart.
If the scanner remains faulted, check the remote IP address, duplicate addressing, selected read/write direction, remote starting location, requested quantity, and availability of the remote data area. If communication is healthy but values are wrong, check word offsets, data widths, word order, and the application copy logic. If errors appear only across the long path, inspect switch and optical-interface diagnostics before altering PLC code.
FAQ
Why does M221-to-M221 communication use Modbus TCP instead of EtherNet/IP?
The configured solution uses the M221 Modbus TCP I/O Scanner over Ethernet. EtherNet/IP is a distinct application protocol; an Ethernet cable or fiber path alone does not make the exchange EtherNet/IP.
Why does the M221 I/O Scanner remove READ_VAR and WRITE_VAR blocks?
The scanner schedules the configured cyclic Modbus TCP transaction in the Ethernet subsystem. The PLC program reads or writes the mapped scanner data area instead of managing READ_VAR and WRITE_VAR request sequencing.
Why does the scanner show healthy communication but wrong values?
A successful transaction can still use the wrong starting location, word count, variable order, data type, or multiword order. Test with distinctive known values and compare every mapped word on both controllers.
Why does the fiber link not require different PLC logic?
The active network equipment carries Ethernet frames over the optical segment, so Modbus TCP remains unchanged. Confirm link status at both optical interfaces and switches before investigating the scanner configuration.
How do I verify the final M221 Modbus TCP setup?
Change each of the three source variables one at a time, confirm the corresponding destination value and scanner status, test loss detection during an approved interruption, then restore the link and confirm that cyclic updates resume without restarting either controller.