PFC100 Modbus TCP communication succeeds only when the client reaches the controller, requests the holding-register object, and targets an address mapped to the intended PLC variable. Treat %IW, %MW, and the Modbus register address as separate namespaces until the controller configuration explicitly connects them.
Which path must the request follow?
Follow the packet from the client PLC to the PFC100. The client creates a Modbus TCP request, sends it through the Ethernet path to the configured PFC100 IP endpoint, and asks for one or more holding registers. The PFC100 protocol service then translates the requested Modbus address through its configured mapping and returns the mapped data.
| Path element | Required setting | Proof before continuing |
|---|---|---|
| Client PLC | PFC100 destination IP, configured TCP port, holding-register operation, start address, and quantity | The client attempts a connection to the expected endpoint |
| Ethernet path | Compatible addressing, link, switching, and routing | The PFC100 IP address is reachable from the client network |
| PFC100 service | Modbus TCP server enabled and listening on the same port used by the client | A TCP connection opens without timeout or refusal |
| Register map | Requested holding-register range mapped to PLC data | A known test word is returned at the expected address |
Layer one first: confirm link indicators, cable integrity, switch-port state, and network addressing before changing register definitions. The completion check is a successful TCP connection from the client side; register troubleshooting starts only after that check passes.
Why is no Modbus slave ID shown?
A direct Modbus TCP exchange identifies the server primarily by its IP endpoint. The serial concept commonly called slave ID is carried in Modbus TCP as a unit identifier, but it is especially relevant when a TCP-to-serial gateway must select one downstream serial device. A direct PLC-to-PLC connection may therefore expose no commissioning field labeled slave ID.
Do not substitute an arbitrary ID merely to populate the client configuration. First determine whether the client requires a unit-identifier value, ignores it for direct Ethernet targets, or uses it only when routing through a gateway. Read that behavior in the client instruction or communication-channel documentation. If a gateway exists, configure the identifier required by the downstream device; if the PFC100 is the direct endpoint, use the client setting intended for a direct Modbus TCP server.
The proof is not the appearance of an ID field. The proof is that the PFC100 accepts the TCP request and returns either register data or a protocol exception instead of a connection timeout.
Does %IW mean a holding register?
%IW denotes an input-word area in the PLC runtime namespace, while %MW denotes a memory-word area. A holding register is an addressable Modbus data object. The server mapping, not the percent-address prefix alone, determines which PLC data appears as holding-register data.
| Notation or object | Role | Access implication |
|---|---|---|
%IW |
PLC input-word location | Often represents input-oriented process data; write behavior depends on the runtime and mapping |
%MW |
PLC memory-word location | Often suits application-owned exchange storage, subject to the project’s memory model |
| Holding register | Modbus word object | The server may expose it for reading and writing according to its configuration |
| Modbus address | Protocol-side register selector | Must resolve through the configured map to the intended PLC word |
If the goal is bidirectional PLC exchange, use an application-owned word area that the project can read and write, then map that area to holding registers. Use %IW only when the configured server map intentionally sources the required value from the input image. Prove the choice by changing the PLC-side test word and observing the corresponding holding register.
How should the holding-register map be defined?
Build one small, explicit mapping before allocating the production range. Keep three values visible: the client’s requested address, the PFC100 mapping offset, and the PLC variable receiving or supplying the data. Address notation differs among clients: one interface may display a human-readable register reference while another expects a zero-based offset. An off-by-one mismatch can return the adjacent word even though the connection is healthy.
- Create or select one writable PLC word reserved for communication testing. Do not reuse a live input or output value.
- Assign a recognizable test pattern to that word.
- Configure the PFC100 Modbus mapping so one holding-register entry points to the test word.
- Configure the client for a holding-register read using the corresponding start address and a quantity of one word.
- If the value is shifted by exactly one register, compare the client’s displayed reference with the offset expected by the PFC100 mapping. Correct one side only.
- After the single word works, extend the map in a documented contiguous range.
The check is exact agreement between the test word in the PFC100 application and the one-word client response at the documented address.
How do read and write directions affect the mapping?
Separate protocol direction from PLC process-image terminology. During a holding-register read, the client reads and the PFC100 supplies data. During a holding-register write, the client supplies data and the PFC100 stores it in the mapped destination. Calling a location “input” or “output” without naming the viewpoint causes commissioning errors.
| Transaction | Network source | Network destination | Required PLC behavior |
|---|---|---|---|
| Client reads holding register | PFC100 mapped word | Client receive variable | The application updates the source word before the request |
| Client writes holding register | Client transmit variable | PFC100 mapped word | The application permits the mapped destination to change |
A continuously executing PLC assignment can overwrite a received value immediately after a successful Modbus write. Likewise, mapping a read request to an input-image location may expose real I/O data rather than an application exchange word. Search the application for every writer to the mapped destination. The check is to write a new test pattern from the client, stop forcing or overwriting logic, and confirm that the mapped PLC word retains the received value.
How is the complete exchange verified?
Verify one layer at a time and record the first layer that fails. A timeout points toward addressing, link, routing, port, service state, or connection handling. A protocol exception means the request reached the server but its operation, address, or quantity was rejected. A valid response containing the wrong word points toward address-base, offset, mapping, byte-order, or application-update problems.
- Confirm physical link and IP reachability.
- Confirm that the client opens a TCP connection to the configured PFC100 endpoint.
- Read one mapped holding register and compare it with a known PLC test word.
- Change the PLC test word and repeat the read to prove that the value is live rather than stale.
- If writes are required, write a different pattern from the client and observe the mapped PFC100 word.
- Test patterns that make both bytes distinguishable, then compare byte order before applying numeric scaling or type conversion.
- Expand the request to the planned range and confirm that the first and last mapped words land in the documented variables.
The exchange passes only when a PLC-side change reaches the expected client variable and, where configured, a client-side write reaches and remains in the expected PFC100 variable.
FAQ
How do I configure a PFC100 as a Modbus TCP slave?
Enable its Modbus TCP server, map an application-owned PLC word to a holding register, and point the client at the PFC100 IP endpoint and configured TCP port. Prove the setup with a one-word read before expanding the range.
How do I choose between %IW and %MW for holding registers?
Choose the PLC location based on ownership and write direction, not its name. For application exchange data, map a writable application-owned word such as the project’s intended %MW location; use %IW only when the server must publish that input-word data.
How do I verify the Modbus register offset?
Map one test word, request one holding register, and compare the returned value with the PLC variable. Then test the neighboring address only if the expected pattern is absent; final verification is an exact match at the documented address after the PLC value changes.