H2-ECOM100 can communicate with a Yaskawa F7 through its CM090 Ethernet module using Modbus TCP when the drive’s register ranges and supported function codes fit the PLC’s RX/WX instruction limits. Trace the request from the PLC to the drive, then verify each layer before changing the register map.
Does the Ethernet path reach the CM090?
A Modbus request originates in the 205-series PLC program, passes through the H2-ECOM100 and the Ethernet network, and reaches the F7 through the CM090. A failure at any hop can look like a protocol problem, so begin with link and addressing readings.
- Check link/activity indications at the H2-ECOM100, CM090, and intervening switch or cabling. No link points to a physical connection, power, or interface issue; restore link before investigating Modbus.
- Read the configured IP settings at both endpoints and confirm the PLC is addressing the CM090’s current address. Check subnet compatibility and any router or VLAN path between them. A wrong destination or unreachable subnet means the request is not reaching the drive application.
- Check the module’s communication status and available diagnostics while issuing a controlled request. If no request or response is recorded at the PLC side, stay at the PLC/module and network path; if a request reaches the drive but receives an exception or no valid data, proceed to function-code and register checks.
Does the Modbus request use a supported function and range?
Sharing Modbus TCP does not by itself guarantee that a particular PLC instruction can access every drive object. The request’s function code and quantity must be supported by both the communication module’s RX/WX instruction path and the drive’s Modbus map.
| Reading to compare | What it tells you | Next check |
|---|---|---|
| Drive manual: register/object range and access type | Identifies the intended data and whether the access is a read or write | Match the operation to a supported Modbus function code |
| Drive manual: function-code support and permitted quantity | Defines the request the CM090 can process for that object | Compare with the H2-ECOM100 RX/WX limits for that function |
| PLC instruction: starting address and element count | Shows the actual requested span | Keep the full span inside both documented limits |
| PLC and drive diagnostics: response or exception | Separates a transport failure from an invalid request or data location | Correct the indicated address, function, or quantity, then retest |
Modbus defines large theoretical element ranges, but an instruction may support only a subset for a given function code. The relevant limit is not the protocol maximum in isolation: it is the intersection of the PLC instruction’s supported range and the drive’s documented range. Cross-check the Yaskawa drive manual against the H2-ECOM100 manual’s RX/WX restrictions before building a broad block transfer.
Do the PLC and drive agree on address interpretation?
Use the drive’s CM090 communication documentation to identify the exact register or object number, access type, and any address convention the drive uses. Then compare that with the address format expected by the PLC instruction. A reference number printed in a drive table and a zero-based protocol offset are not automatically interchangeable; apply only a conversion documented by the equipment manuals.
Test one known, documented item at a time. For a read, choose a value whose expected meaning and behavior are clear. For a write, use a controlled, nonhazardous test value and confirm the drive’s operating state and write permissions before issuing it. If the request completes but the value is implausible, investigate address offset, data width, word order, and scaling as specified by the manuals rather than treating the response as proof of correct mapping.
What should you change when a request fails?
Use the first failing layer to choose the correction. Do not change IP settings, function codes, and register offsets simultaneously; that removes the evidence needed to isolate the fault.
- If link or IP reachability fails, correct the cable/switch path or endpoint addressing, then repeat the same request.
- If the PLC reports a transport timeout, inspect communication status and the CM090 diagnostics. Confirm the target address and that the drive interface is reachable before changing the data map. Read configured timeout and retry settings from the PLC/module diagnostics; do not substitute guessed timing values.
- If the drive returns an exception or rejects the operation, compare its supported function code and object range with the RX/WX instruction limits. Reduce the requested quantity or split the transfer only when the manuals permit that arrangement.
- If a read succeeds with the wrong value, verify address convention, data format, and scaling against the Yaskawa map. If a write is rejected, check the documented write access and drive conditions before retrying.
The practical correction for an oversized or unsupported transfer is to request only the documented range that both sides accept, using the corresponding supported function. If the required drive data lies outside that overlap, the module/instruction combination cannot access it through that request; select a supported access method or revise the data requirement rather than issuing a larger block.
How do you verify the correction under operation?
After a successful isolated test, confirm that PLC values correspond to the documented drive items and update as expected. For writes, verify both the accepted PLC response and the resulting drive state or value; a network acknowledgment alone does not prove the intended control action occurred.
- Record the working destination address, function code, starting address, quantity, and expected data interpretation.
- Run the intended read/write sequence and monitor PLC communication status, drive diagnostics, and returned values.
- Repeat across the full required data range, checking each transfer remains within both manuals’ limits. Confirm the final monitored value at the drive matches the PLC’s intended command or readback.
What happens if the PLC and drive both support Modbus TCP?
What happens if both devices support Modbus TCP?
That establishes a common protocol, not a guaranteed match for every request. Confirm the CM090’s register map, function code, and range against the H2-ECOM100 RX/WX limits.
What happens if the PLC reads no response?
Check link, endpoint addressing, route, and communication diagnostics first. A transport timeout points to reachability or response-path checks before register offsets.
What happens if the drive returns an exception?
Compare the requested function code, start address, and quantity with the CM090 documentation and PLC instruction limits. Reduce or split the request only within documented limits.
What happens if a successful read gives the wrong value?
Check the address convention, data representation, and scaling in the drive map. Confirm one known item before expanding the transfer.
What happens if the corrected transfer works once?
Run the complete required range and monitor PLC status, drive diagnostics, and returned values; finish by confirming the final monitored drive value matches the PLC’s intended command or readback.