Production returns after assigning EtherNet/IP scanner ownership to a controller that supports implicit connections and using the BRX only in a role its installed software supports. Adapter capability lets another controller own BRX I/O; it does not let the BRX own distributed adapters.
Stop applying the usual quick fixes
Do not treat repeated explicit messages as implicit scanning. Explicit messaging can read or write selected objects on command, but implicit I/O establishes a cyclic producer-consumer connection for control data. Re-triggering messages adds application logic, response handling, timeout handling, and scheduling variability without turning the PLC into an implicit scanner.
Do not chase processor speed first. The BRX already supports Ethernet remote I/O using the Do-more I/O protocol, but performance on one protocol does not add the connection manager, configuration workflow, and cyclic ownership required to scan EtherNet/IP adapters.
Do not confuse an EDS file or an imported AOI with scanner capability. An EDS describes a device, while an AOI can package application logic and data handling. Neither creates the underlying implicit originator function in a controller that lacks it.
Check which device must own the connection
Read the intended architecture from the I/O drawings and controller configuration. Identify which controller must initiate and maintain cyclic connections to the field devices.
| Required behavior | EtherNet/IP role | Meaning for BRX |
|---|---|---|
| Another controller exchanges cyclic I/O with BRX | BRX acts as an adapter | The external scanner owns the connection; BRX exposes I/O data. |
| BRX exchanges cyclic I/O with distributed adapters | BRX acts as a scanner | BRX must contain explicit support for implicit scanner operation. |
| BRX sends individual object requests | Explicit-message client | This is message traffic, not cyclic I/O ownership. |
If another controller will remain the scanner, continue by checking the BRX adapter configuration. If the BRX must replace that controller and retain the existing EtherNet/IP adapters, check the installed BRX software capability next. If the requirement is only occasional configuration or status access, evaluate explicit messaging separately; do not classify it as the machine-control I/O path.
Read the capability of the installed release
Open the installed software documentation and firmware release notes. Search for an EtherNet/IP implicit scanner or originator feature, not merely EtherNet/IP support or implicit adapter support.
The documented configuration behind this issue had implicit adapter capability, while scanner capability was still described as planned for a later release. No software or firmware version was identified. A statement that the feature was planned is not an instruction to configure it in the installed release.
- If the installed release explicitly lists implicit scanner support, use its device-configuration workflow and continue to the connection checks.
- If it lists only implicit adapter support, the BRX cannot own the distributed adapters through that feature. Move scanner ownership to a supported controller.
- If the wording is unclear, stop here and ask AutomationDirect support whether the exact installed firmware and programming-software combination provides implicit scanner operation.
Check both controller firmware and programming software. A configuration editor may expose only the functions supported by its release, and downloading a project cannot manufacture a runtime service absent from the controller firmware.
Check the connection rather than the data values
When a supported scanner is present, inspect the scanner's connection diagnostics before troubleshooting mapped tags. Record whether the adapter connection is established, repeatedly reconnecting, or idle.
| Reading | Meaning | Next check |
|---|---|---|
| No configured connection | The device was not added as cyclic I/O, or this controller is not acting as scanner. | Return to the role and release-capability checks. |
| Connection attempt fails | The scanner can initiate connections, but the requested assemblies or connection properties do not match the adapter. | Compare the configured input, output, and configuration definitions with the device documentation. |
| Connection establishes, then drops | The path works initially but cannot maintain the negotiated cyclic exchange. | Check the scanner diagnostic buffer, adapter status, network path, and configured update behavior. |
| Connection remains established but application data is wrong | Transport is working; mapping, byte layout, or application interpretation is wrong. | Compare raw transferred data with the mapped program structure. |
Capture the first connection fault before cycling power. Later faults can be consequences of the first failure. If the scanner identifies an invalid connection definition, correct that definition instead of increasing application timeouts or adding repeated messages.
Choose the production-restoring architecture
Use the shortest supported branch that restores cyclic ownership:
- If an existing controller already scans the network, retain it as the EtherNet/IP scanner and configure the BRX as an adapter. Map only the data required between that scanner and the BRX application.
- If the BRX must be the machine controller but its installed release has no scanner function, add or retain a supported scanner. Treat any explicit-message workaround as temporary supervisory exchange, not replacement safety or time-critical I/O.
- If an installed BRX release explicitly supports implicit scanning, configure each adapter through that release's documented workflow. Take assembly definitions and connection properties from the adapter documentation; do not infer them from tag names.
- If changing the field network is acceptable, evaluate the BRX-supported remote-I/O architecture separately. A protocol change affects device compatibility, configuration, spares, and commissioning; it is not a checkbox substitute for EtherNet/IP scanning.
For a temporary explicit-message path, define stale-data detection and a controlled failure state in the application. A successful message proves only that one transaction completed; it does not prove a continuously owned I/O connection.
Commission the resolving branch and verify it
- Back up the running controller projects and record the current network and I/O mappings.
- Assign exactly one intended scanner to each adapter connection. Remove abandoned configurations that could compete for exclusive ownership.
- Configure the BRX as an adapter when an external controller is the scanner, or configure adapters under the BRX only when the installed release explicitly provides scanner capability.
- Place outputs in a safe commissioning state, download the configurations, and bring up one connection at a time.
- Confirm that every required connection reaches the established state and remains there without reconnecting.
- Force or stimulate each permitted input point and compare the physical state, raw network data, and application tag. Test outputs through the approved commissioning procedure.
- Interrupt the adapter or network path deliberately. Verify stale-data detection, output fallback, diagnostic indication, and clean reconnection.
- Remove temporary repetitive-message logic after cyclic I/O is proven, unless that messaging serves a separate configuration or diagnostic function.
Production is restored only when the selected scanner owns every required adapter, data changes arrive in the correct locations, and loss of communication drives the defined machine response. A ping or one successful explicit read does not complete this test.
FAQ
What happens if I configure a BRX adapter and expect it to scan remote I/O?
The connection direction is wrong. An external scanner can own the BRX adapter data, but adapter mode does not initiate cyclic connections to other adapters.
What happens if I replace implicit I/O with repeated explicit messages?
The PLC must schedule and supervise individual transactions, so data delivery follows message completion rather than an owned cyclic I/O connection. Add stale-data handling and use this only where the application can tolerate that behavior.
What happens if the EDS imports but the I/O connection still fails?
The device description did not prove that the controller can act as a scanner or that the connection definition is correct. Check scanner capability first, then compare the configured assemblies and connection properties with the adapter documentation.
When should I stop troubleshooting and call official support?
Stop when the installed release notes do not clearly identify implicit scanner support, or when a correctly defined connection repeatedly fails without a decisive diagnostic. Give AutomationDirect support the BRX firmware, programming-software release, adapter identity, connection configuration, and first recorded fault; do not keep production dependent on an unverified explicit-message substitute.