Yes. You can usually keep the existing wired buttons when adding an RF remote. The part that needs thought is what happens when someone at the panel and someone holding the remote both try to operate the machine.
My starting point is simple: decide who is allowed to request movement before deciding where the receiver wires go. A relay contact can imitate a pushbutton perfectly and still give the machine the wrong operating behavior.
The awkward case is rarely the first successful remote start. It is the operator turning the selector to REMOTE while a radio output is already on. If that starts the machine immediately, the selector has quietly become a start button.
Keeping both controls does not mean enabling both at once
For a simple light, accepting commands from either location may be exactly what you want. For equipment with movement, separate LOCAL and REMOTE authority is often easier to explain, operate and troubleshoot. The right choice depends on the machine and its operating procedure.
Write down three things for each mode: which source can start an action, which commands can stop it, and what happens when the mode changes. “Local overrides remote” is not detailed enough. Does it cancel a running action, block the next start, or transfer a maintained run request? Those are different behaviors.
There is a useful manufacturer example here: Schneider Electric’s TeSys T guidance on control channels describes selection between local and remote sources, with one source active at a time. That is a feature of that controller, not something to assume every RF receiver provides.
A parallel START contact cannot decide who is in charge
An isolated receiver contact across an existing START button may be a suitable electrical interface. It also means either contact can request a start unless something else gates those requests.
Turning the handset off does not automatically establish local authority. A receiver output might be latched, another paired transmitter might still operate it, or the machine controller might already have stored the request. Check the actual output mode and the downstream logic.
With a PLC, keep the panel request and radio request separate where practical, then apply the chosen mode in the control logic. With relay logic, the selector and contacts need to implement the same operating rules. Neither approach should create a route around existing permissives or protective functions.
For the electrical interface itself, see adding a wireless remote to an existing machine. Here, the important question is what a valid input is allowed to do.
The held-button test exposes a weak handover
Consider this sequence: the machine is in LOCAL, the remote RUN button is held down, and someone selects REMOTE. A basic arrangement that simply enables the radio input may start immediately. The same problem can occur with a latched receiver relay even after the operator releases the handset button.
For a retrofit intended to stop before changing control source, I would specify a handover that requires the incoming commands to return to their defined inactive state, followed by a deliberate new start or enable action. Selecting REMOTE grants permission to operate; it does not itself request movement.
Example handover sequence — control behavior, not a wiring diagram
LOCAL active → mode change requested → machine reaches its defined stopped condition → incoming radio commands confirmed inactive → REMOTE ready → fresh operator command accepted
“Inactive” needs a precise definition. It may mean a released momentary contact, all motion controls in neutral, or a protocol state confirmed by the receiver. A toggle output that remains on cannot meet a neutral requirement just because the physical button has been released.
Hetronic’s NOVA manual, section 6.1, gives a product-specific example of deliberate enable behavior: neutral controls and a Start action are part of establishing radio control. It is a useful design reference, not evidence that a basic relay receiver has that function.
Some processes need transfer while running. That is a separate control design involving the run state, speed or position reference, and process conditions. Do not apply a stop-before-transfer sequence blindly to a process where stopping creates another hazard.
Work out STOP separately from START
A mode selector should not casually disable a stop function that the machine’s design requires to remain available. Make a separate list of normal stop commands and safety functions, then check their behavior in every mode.
Also check what happens after a stop is released or reset. If a maintained radio RUN request is still present, can it restart the machine? For a design that requires a fresh start, clearing the stop condition must not be enough.
An ordinary RF STOP button and a safety-rated emergency-stop system are different functions. Keep the existing safety architecture under the machine designer’s control; a LOCAL/OFF/REMOTE selector is not an energy-isolation device for maintenance.
Use a short acceptance list instead of “priority as usual”
For a machine specified to stop before handover, the following makes a useful starting point. Agree the expected results with the machine designer before testing, and run the initial logic checks with hazardous outputs safely inhibited.
LOCAL selected: panel commands operate as specified; radio start and direction commands cannot initiate movement.
REMOTE selected: radio commands operate as specified; panel start commands behave according to the agreed authority rule.
Command held during transfer: changing the selector does not turn an already-active input into a fresh start.
Conflicting commands: simultaneous panel and radio requests produce the documented result, including opposite directions.
Stop and reset: required stop functions remain effective, and resetting them does not bypass the fresh-start requirement.
Radio or receiver power lost: the machine follows its specified loss-of-control response; it does not silently grant control to the other station.
Power restored: the selected mode, stored requests and receiver output state produce the documented restart behavior.
Check the sequence at more than one point. First observe the receiver outputs. Then observe the controller’s accepted command. Finally verify the machine response under a controlled commissioning procedure. A relay changing state only proves that one part of the chain worked.
Make the active control source obvious
The person at the panel should not have to press START to discover that the machine is in REMOTE. Label the selector clearly and, where useful, show which source the controller has actually accepted.
A lamp wired only to the selector may show the requested mode while the controller is still waiting for neutral inputs. If that distinction exists, show “REMOTE selected” and “REMOTE ready” separately, or use another indication that operators can understand. Otherwise a correct handover delay can look like a faulty remote.
Leave the next technician a short description of the sequence: source selection, neutral condition, enable action, stop response and power-recovery behavior. That information is usually more useful during a service call than another page listing the radio frequency and nominal range.
What to settle before choosing the receiver
Bring the control drawing and a plain-language description of one complete operating cycle. Specify whether outputs are pulses or maintained states, whether a latched command can be cleared, and whether the machine needs an explicit radio-ready signal.
My preference is to keep authority and restart decisions in the machine control system whenever it can support them. The radio then supplies identifiable requests, and the machine decides when to accept them. It leaves fewer surprises when a handset is replaced, a battery dies, or an operator changes stations halfway through a job.
Keeping the wired buttons is usually straightforward. Making the handover predictable is the part worth spending time on.