In the 3 H2-ECOM 250 and 18 H2-ECOM 06 installation, communication improved after the PLC traffic returned to TCP/IP, the module-number-to-IP mappings were restored, and the transfers were paced and correctly sequenced. The failure was not proof that H2-ECOM only supports master/slave communication or that eight RX/WX operations are a universal limit.
Stop swapping switches and protocols to chase speed
Several quick fixes made the startup failure worse because they changed network behavior before the PLC message pattern and configuration were understood.
- Replacing managed switches with unmanaged switches: this did not address request frequency, transfer sequencing, or addressing. In this installation, the switch change occurred alongside a change to IPX and removal of the IP mapping; a broadcast storm followed and disrupted facility systems. Do not treat an unmanaged switch as a remedy for overloaded PLC messaging.
- Changing TCP/IP traffic to IPX: this move did not restore reliable data transfer. The eventual working arrangement used IP, including for the SCADA data server.
- Removing the module-number-to-IP table: that table was useful for faster communications and network mapping. Restore the mapping when using the Ethernet modules; do not remove it based on advice intended for different hardware.
- Putting every RX/WX operation in every PLC scan: repeated requests can load the network faster than necessary, especially when many PLCs communicate at once. More operations per scan do not guarantee more current data.
- Assuming a fixed limit of five to eight operations: a slow result at that count calls for checking the logic, configuration, and request timing. It does not establish a universal H2-ECOM ceiling.
When a change coincides with a facility-wide broadcast storm or loss of business systems, disconnect the affected PLC network from the plant network and involve the network owner before reconnecting. Do not continue experimenting on a shared production network.
Separate peer-to-peer capability from the data-sharing design
Peer-to-peer means PLCs can initiate reads or writes to other PLCs; it does not mean every PLC must exchange every value with every other PLC on every scan. A central poll-and-publish arrangement is one valid architecture, but it is not the only one. Distributed peer-to-peer transfers are also possible, and a system can mix the two.
The traffic difference becomes substantial when every node sends requests to every other node. For 21 PLCs, a fully connected exchange pattern can require 21 × 20 = 420 requests for one complete cycle, using the scenario described in the installation. A central arrangement that reads data from 20 PLCs and writes it out to those 20 PLCs would require 20 + 20 = 40 requests per cycle in that same illustrative pattern. These are request-count comparisons, not a guaranteed throughput calculation; actual transfer time depends on the program, data blocks, network, and response behavior.
Central polling reduces distributed request traffic, but adds a workload and timing dependency at the central PLC. Its scan time can affect how quickly collected data is republished. Distributed transfers avoid that single coordinator, but excessive simultaneous requests increase contention and can trigger retries. Choose the architecture from the required data flow and update rate, not from the word “peer-to-peer.”
Map each value to a sender, receiver, and update need
Before changing hardware, list who needs which data and how fresh it must be. The key question is whether every PLC needs information from every other PLC, or whether a smaller set of values can be collected and forwarded.
| Pattern | Useful when | Primary tradeoff |
|---|---|---|
| Direct peer-to-peer reads or writes | Specific PLCs exchange event-based or limited data | Many independent requests can create contention |
| Central poll and publish | Many PLCs need shared data collected in one place | The central CPU and its scan time can bottleneck updates |
| Mixed arrangement | Some data is shared centrally while other transfers are direct | Requires a clear ownership and update plan to avoid duplicate traffic |
Group contiguous values into one block where the application permits. One transfer of ten memory values is more efficient than ten separate single-value transfers. Also identify whether data is needed every scan or can be refreshed periodically; the SCADA server in the reported setup polled about every 20 seconds, while PLC-to-PLC messaging had initially been triggered much more frequently.
Restore the IP configuration before tuning traffic
- Put the network path back into a known arrangement approved by the plant network owner. Do not reconnect an experimental PLC segment to the facility network while a broadcast storm or unexplained traffic remains.
- Configure the H2-ECOM modules for TCP/IP as required by the working application, and restore the module-number-to-IP mapping in NetEdit. Confirm the module's IP and mapping at each endpoint rather than relying on discovery alone.
- Keep the SCADA data-server connection on the same confirmed IP arrangement. Verify that PLC and SCADA traffic reaches the intended endpoints.
- Change only one factor at a time. Record the switch path, protocol, mappings, PLC logic, and observed transfer result so a working state can be restored if a test fails.
In the reported recovery, returning to IP and restoring the mapping accompanied a result of 0% collisions for the 18 reads. That observation is useful for this installation, not a promise that zero collisions means every application will meet its update deadline.
Sequence and pace RX/WX operations in PLC logic
The installation moved two words from each of 18 H2-ECOM 06 PLCs to one 250, then wrote two different words back to each 06. The 250's read operations initially worked, but writes produced no data when programmed as first attempted. The working adjustment placed RX operations in the individual 06 PLCs and timed them with a one-second bit, then modified the 250's RX sequencing to use odd bits of the index SR. The reported result was data transfer in about 1.5 seconds with 0% collisions.
Use that sequence as a troubleshooting clue, not a universal program template: the exact meaning of the index register, instruction behavior, and valid sequencing depend on the PLC program and module documentation. Confirm the read and write direction at both ends, source and destination addresses, word counts, trigger conditions, and completion/error handling in the project.
- Separate each operation's trigger from the continuous scan, unless the application genuinely requires scan-by-scan updates.
- Stagger requests rather than allowing all nodes to transmit simultaneously. The installation used timed triggering and adjusted the central PLC's RX sequencing.
- Test one data path at a time: first PLC-to-central reads, then central-to-PLC writes, then the complete set of nodes.
- Increase the number of active operations gradually while recording completion time, error status, and data correctness.
A timer can greatly reduce traffic when the process tolerates slower updates. For example, the troubleshooting guidance contrasted a 0.5-second communication interval with a 50-millisecond scan, which would issue one tenth as many requests as scan-triggered communication. Use the actual process update requirement and measured scan time to choose a period; those example values are not a prescribed setting.
Check the PC's NIC path when NetEdit discovery fails
A separate problem appeared after the boot loader was updated using NetEdit 3.6b: modules appeared only on the IPX tab, IPX link setup failed, and entering an IP address allowed an IP connection without returning a module list. A PC with two network interface cards was identified as a likely cause of unreliable discovery and software communication.
- Identify which NIC connects to the PLC network and which is unused for this task.
- Disable the unused NIC in the PC's network configuration, then reboot the PC.
- Reopen NetEdit and test discovery on the intended protocol and adapter. If a module responds when addressed directly by IP but does not appear in the list, treat discovery and endpoint communication as separate checks.
- Restore the second NIC only when needed, then retest with the adapter selection and routing path understood.
Successful direct IP access does not, by itself, show that the module list or broadcast discovery path works. Keep the PC attached only to the intended network while diagnosing discovery.
Verify transfers before returning the network to production
Prove both directions and the full node count under the intended plant configuration. A working read alone does not verify writes, and a clean collision count alone does not prove data is arriving correctly or on time.
- Confirm that each expected PLC is visible at its configured IP and module mapping.
- Confirm the correct two-word source and destination data for each transfer; check that values change at the expected end.
- Measure elapsed time from request trigger to valid updated data, then compare it with the process requirement.
- Observe PLC communication status and network error counters while increasing the node count. Stop adding traffic if errors rise, data becomes stale, or latency grows beyond the process limit.
- Check that SCADA polling at its configured interval does not coincide with unnecessary scan-triggered PLC messaging.
- Reconnect to the facility network only after the network owner approves the configuration and the segment shows no unexplained broadcast or traffic surge.
H2-ECOM PLC networking FAQ
Can H2-ECOM PLCs communicate peer to peer?
Yes. PLCs can initiate reads or writes to other PLCs; a master-polling arrangement is an architectural choice, not a required definition of peer-to-peer.
Does an H2-ECOM network have a five-to-eight RX/WX limit?
The reported installation progressed beyond that count, ultimately transferring data among 18 reads after timing and sequence changes. Set the operation count from measured latency, error status, and the application's update requirement rather than treating five to eight as a universal limit.
Can I use IPX instead of TCP/IP for H2-ECOM data?
The working arrangement described used TCP/IP and restored the module-number-to-IP table. If a configuration change causes discovery or traffic problems, return to the known IP setup and verify the mappings before testing other protocols.
Does a managed switch cause slow H2-ECOM transfers?
Not by itself. A managed switch can perform like an unmanaged one when configured to pass the traffic, or support traffic management; inspect its configuration and counters rather than replacing it as the first troubleshooting step.
When should I stop troubleshooting H2-ECOM communication?
Stop and isolate the PLC segment if the facility experiences a broadcast storm, broad network disruption, or unexplained traffic escalation. Escalate to AutomationDirect support and the plant network owner with the module configuration, PLC request sequence, switch path, PC NIC setup, and observed error and timing data.