The reported control path starts at the HMISTU655, crosses an Ethernet network using Modbus TCP, and terminates at the Altivar 61. A second operator station can join that path, but network commands must remain separate from emergency stopping and other protective functions. Follow the packet: verify the physical interfaces, identify the active command owner, map each register, and define the drive response to lost communication before changing the application.
Which remote-control architecture fits the station?
| Approach | Control path | Advantages | Constraints |
|---|---|---|---|
| Hardwired controls | Buttons and potentiometer to drive terminals; drive outputs to lamps | No Ethernet dependency; simple fault tracing | The existing application may own start, stop, and status through communications. Only the frequency-reference terminals are reported unused; confirm every required terminal and command mode. |
PR200 over Modbus TCP |
Remote buttons → controller → Ethernet interface → cabinet network → drive/application | Supports command logic, status indication, and a network frequency reference | Requires register mapping, command arbitration, communication-loss logic, cabinet network access, and software changes. The programming environment was reported as immature. |
PR110(8/4) with TCP/IP interface |
Remote I/O → compact controller → TCP/IP interface → Modbus TCP network | Potentially sufficient for two buttons and two lamps | Available I/O, Modbus function support, data formats, update behavior, and hazardous-area installation still require confirmation. |
| Direct RS-485 connection | Remote controller → RS-485 segment → compatible Modbus server | Avoids an Ethernet-to-serial conversion stage when a usable serial server exists | The reported drive/HMI path is Ethernet. Do not select RS-485 until inspection identifies the actual serial port, protocol role, and accessible register map. |
| Wireless or tablet interface | Wireless device → interface module → controller/network | Can add monitoring, trends, and logging | Wireless equipment, power sources, enclosure, and installation method must be approved for the classified location. It adds dependencies without solving the command-ownership problem. |
For this installation, use a small controller on the existing Modbus TCP path if the remote station must reproduce HMI commands and indications. Use the unused drive analog input for the potentiometer only if the drive can select that reference without creating ambiguous ownership. Keep protective stopping in a separately validated circuit rather than treating a Modbus stop bit as a safety function.
Where can the command packet stop?
The sender is the remote controller. The first hop is its Ethernet port or external Ethernet interface. The packet then passes through any cabinet switch or concentrator and reaches either the drive or an intermediate application that owns the drive command. A successful Ethernet link proves only layer one and part of layer two; it does not prove that the destination accepts the requested Modbus function or permits the addressed register to be written.
| Path field | Value to establish | Failure indicated |
|---|---|---|
| Remote address | Controller IP address and subnet settings from its configuration | Duplicate address or wrong subnet prevents reliable delivery |
| Destination address | Actual server IP from the running HMI project or packet trace | Packets reach the wrong device or no device |
| TCP service port | Configured port in both endpoints | Connection rejection or timeout |
| Protocol role | Remote controller as client; destination as server | Two clients cannot exchange requests directly |
| Register | Documented command, status, reference, and actual-frequency addresses | Exceptions, ignored writes, or unrelated data changes |
| Data representation | Function, width, signedness, byte/word order, and scaling | Wrong frequency or invalid status interpretation |
| Update timing | Configured polling, command refresh, timeout, and retry values | Stale lamps, delayed commands, or nuisance communication faults |
There is a specific ambiguity to resolve: the installation is described as an Ethernet Modbus TCP connection between the HMISTU655 and Altivar 61, while the panel's Ethernet capability was questioned. Inspect the installed connectors and cable destinations, then open the HMI communications configuration. A switch, gateway, or different physical path may sit between the visible devices.
What must be checked before changing software?
Layer one first. Record the complete installed route rather than designing from the schematic alone.
- Inspect the
HMISTU655,Altivar 61, switches, converters, cable types, link indicators, and terminal usage. Trace both ends of every communications cable. - Back up the HMI, drive, and cabinet-control configurations. Extract the configured device addresses, protocol roles, register definitions, scaling, and communication-loss actions.
- Determine which device currently writes run, stop, and frequency reference. Read-only monitoring may be shared; multiple writers to the same command word or reference create race conditions.
- Test network reachability from the proposed connection point. Then observe Modbus requests and responses while operating the existing HMI to identify the true destination and transaction sequence.
- Check the drive's selected command and reference channels in every operating mode. Confirm whether terminal inputs, the analog input, and network commands can coexist or require explicit source selection.
- Review the hazardous-area design for the entire remote assembly: enclosure, operators, display, controller, terminals, cable entries, wiring method, power supply, and any required interface protection. Component approval alone does not approve the assembled station.
How should command ownership be designed?
Assign one control arbiter. The cleanest arrangement is for the existing cabinet application to receive remote requests and decide whether to forward them to the drive. That preserves local/remote selection, permissives, faults, and interlocks in one state machine. Direct writes from both the HMI and remote controller to the drive should be avoided because the last write wins without preserving operator intent.
| Signal | Recommended handling | Bad result to prevent |
|---|---|---|
| Start | Send a request that the arbiter accepts only when remote mode and all permissives are active | Restart after communications recover or after another station issues stop |
| Stop | Make stop dominant in the control state machine; retain a separate protective stop path where required | A network or software fault blocking the only stop command |
| Run lamp | Drive from confirmed running status, not the commanded start bit | Lamp indicates running while the motor has not started |
| Fault lamp | Drive from the actual fault/status data used by the cabinet application | Communication loss displayed as healthy equipment |
| Frequency reference | Select one active source at a time and apply the documented scaling and limits | Competing analog and network references |
| Frequency display | Read actual output frequency rather than echoing the requested reference | Displayed value hides limiting, ramping, or a stopped drive |
How is the recommended Modbus solution implemented?
- Create an I/O list for start, stop, run, fault, frequency reference, actual frequency, remote-mode status, communications health, and every permissive that affects acceptance.
- Choose the controller only after checking its hazardous-area installation method, physical I/O count, Ethernet arrangement, Modbus TCP client capability, data-type handling, and required diagnostics. The
PR200is viable in principle; the smallerPR110(8/4)option may be adequate when the confirmed I/O and protocol requirements fit. - Connect the controller to the verified Ethernet segment. Add a managed connection point or concentrator only if the existing topology lacks a suitable port; adding hardware does not by itself require changing drive logic.
- Implement explicit command arbitration in the cabinet application. Define local/remote selection, stop priority, start acceptance, reset behavior, and the state retained after power restoration or communication recovery.
- Map Modbus items from the actual project and drive documentation. Configure each address, function, width, byte order, access direction, and scale. Do not derive addresses from signal names.
- Add a changing heartbeat or transaction-age monitor. When communication becomes stale, remove the run request, invalidate the remote reference, indicate a communications fault, and require a deliberate new start after recovery.
- If using the external potentiometer, wire it to the confirmed unused analog-reference terminals and configure source selection so it cannot compete with the Modbus reference. If using Modbus for adjustment, apply bounds in both the remote controller and command arbiter.
- Drive the lamps and separate frequency indicator from returned status values. Treat a request timeout, exception response, or stale value as invalid data rather than preserving a healthy indication indefinitely.
How is operation verified without hiding failures?
- With motor operation inhibited, prove every button transition, lamp state, reference value, register direction, and scale at both ends.
- Verify that local and remote stations cannot alternate ownership unexpectedly. Issue conflicting requests and confirm that the selected mode and stop priority determine the result.
- Disconnect Ethernet at each hop: remote controller, interface, cabinet switch or concentrator, and destination. Confirm the configured fail response, communications alarm, extinguished run indication, and blocked automatic restart.
- Test destination loss and malformed or rejected writes separately from cable loss. The controller must distinguish valid data from a live Ethernet link with failed Modbus transactions.
- Run through minimum, intermediate, and maximum permitted references. Compare the transmitted reference, accepted reference, and actual frequency indication during stop, acceleration, steady operation, and fault.
- Restore power and communications in different orders. Confirm that no retained command starts the pump until the operator issues a new valid request.
FAQ
How do I connect a remote panel to an Altivar 61 already controlled by an HMI?
Connect a Modbus TCP-capable controller to the verified cabinet Ethernet segment, but route its requests through one command arbiter. Copy addresses, data formats, scaling, and write permissions from the running project and drive documentation.
How do I use an external potentiometer with Modbus control?
Wire it only to the confirmed unused analog-reference terminals, then configure an explicit reference-source selection. Permit either the analog reference or the Modbus reference at one time, never both as competing writers.
How do I prove the remote pump controls fail safely?
Break communication at every network hop and confirm that the run request drops, remote reference becomes invalid, a communication fault appears, and recovery does not restart the pump. Finish by issuing a deliberate new start and verifying commanded state, drive status, and actual-frequency feedback agree.