Yes, you can add an RF receiver to a PLC-controlled machine. For a few on/off commands, isolated relay contacts into spare digital inputs are often the simplest interface. The receiver supplies the operator's request; the PLC still decides whether the machine can act on it.
The part worth checking carefully is what the PLC actually receives. A relay click is not an input signal. An input signal is not permission to run. And a start request that was rejected a moment ago should not quietly become a valid start when a guard closes or a fault clears.
Before choosing the receiver, settle three things: the electrical input circuit, the duration of each command, and what the program does with that command in every operating state. Those decisions save more work than adding radio range later.
Start with the PLC input drawing, not the receiver supply label
A receiver marked “12–24 V” tells you something about its power supply. It does not tell you whether its outputs are dry contacts, switched supply voltage, or transistors. These are different interfaces.
With an isolated dry contact, COM and NO act as a switch. They do not generate 24 V. You can power the receiver from one suitable supply and use its isolated contact to switch the PLC's input circuit, provided the contact ratings and the actual board isolation allow it. Do not join supply negatives just because both devices use DC.
For a 24 V DC sinking input group whose common is connected to 0 V, a typical single-channel circuit is:
PLC input supply +24 V → receiver relay COM → NO → PLC input I0.0
PLC input-group common → the same input supply 0 V
Closing the contact completes the input current path. This example applies only to that input arrangement. A sourcing input group uses a different circuit, and terminal names vary by manufacturer. Follow the drawing for the exact input module. AutomationDirect explains the distinction in its sinking and sourcing input guidance.
A transistor output needs another check: output polarity, leakage current, on-state voltage drop and the input's switching thresholds. “It switches 24 V” is not enough information. If those specifications are missing, choose a documented interface rather than experimenting at the PLC terminals.
Check whether the contact is suitable for a small input current
A PLC input is a light electrical load. That sounds easy, but a relay advertised for high-current loads is not automatically a good signal relay. Check the contact manufacturer's minimum applicable load as well as its maximum switching rating. Omron's relay contact guidance explains why low-load reliability needs its own check; minimum-load figures are reference values, so confirm suitability under the intended operating conditions.
If the PLC input draws less than the contact's specified minimum load, ask for a contact intended for low-level switching or a suitable interface stage. Do not add an improvised resistor just to make the relay “work harder.” It changes current, heat and fault behavior without fixing the specification gap.
On a multi-channel receiver, also check whether the COM terminals are genuinely separate. Shared commons can limit which input groups or supplies you can connect. Draw the complete circuit before landing the wires.
A short pulse can disappear before the program sees it
The receiver can close its relay correctly while the PLC misses the command. The input filter may reject a brief pulse, or the pulse may fall between input updates. Watching the input online is useful, but a slowly refreshing watch window can miss it too.
Choose the output pulse using the input filter, module update time and the worst-case interval at which the relevant task reads the input. Leave a margin. A pulse that happens to work with an idle PLC on the bench has not proved it will work while the production program is busy.
Some PLCs offer pulse-catch or interrupt features. They can help with short signals, but they are not a cure for every timing problem. For example, the CLICK PLC pulse-catch documentation describes capturing pulses shorter than a scan, while Siemens notes that S7-1200 pulse catch operates after the input filter. A pulse removed by the filter is already gone.
For an ordinary start request, a documented, adequately long pulse is usually easier to commission than a very short pulse with clever recovery logic. Hold-to-run control is a separate case: its release and link-loss timing must be designed around the machine, not stretched merely to make the input easier to read.
Define what one button press means
For a discrete start command, I would normally use a fresh rising edge from a conditioned input to create one request. Keeping the input high should not create a new start on every PLC scan.
That still leaves contact bounce and receiver behavior to consider. Does a held button produce one continuous closure, repeated closures, or a fixed pulse? Does the output briefly drop during an RF interruption? An edge detector alone will treat each new low-to-high transition as another event. Confirm the waveform, then apply the filtering and rearming rules appropriate to that function.
Where practical, give Start and Stop separate commands. A single toggle button makes the next action depend on a state the operator may not be able to see. Two labelled requests are easier to understand and diagnose. An ordinary wireless Stop remains an operating command; it does not replace the machine's safety stop system.
Do not keep a rejected start waiting in memory
Consider this sequence: the operator presses Start while a guard is open. The program stores the request. The guard closes ten seconds later, the permissive becomes true, and the machine starts without another button press.
The radio delivered the command correctly. The problem is the lifetime of that command in the PLC.
For an ordinary operator-initiated start, my default is to accept the fresh request only when the machine is in the intended mode and its required conditions are satisfied. If they are not, reject the request and show the reason where feedback is available. Require another deliberate press after the condition is corrected. A process that genuinely needs queued requests should define that behavior explicitly.
The command path should be clear:
RF output → electrical input → input conditioning → fresh command event → mode and permissive checks → machine sequence
Keep the raw input, the accepted request and the machine state as separate signals. During a service call, that lets you distinguish “the PLC did not see the button” from “the PLC saw it and refused the action.”
A held input must not become a fresh start after a restart
Test what happens if the receiver output is already on when the PLC enters RUN. Some edge-detection implementations can produce an event during initialization. A retained request or receiver toggle state can create another route to an unintended start.
For discrete start functions, require the command input to return to its inactive state before arming it for a new press after power-up, mode changes or fault recovery. Clear obsolete requests deliberately. Check the actual startup behavior of the PLC instructions you use; do not assume all edge detectors initialize alike.
This is ordinary command handling. It does not establish a safety function. If machine risk reduction depends on wireless stopping or enabling, that requires an appropriately designed and validated safety architecture.
Test the awkward cases before the receiver goes into the cabinet
First prove the electrical input with machine motion prevented through the machine's intended commissioning method. Then test the complete command sequence under controlled conditions. Record what the receiver output, PLC input and accepted-command bit each do.
Tap and hold: a quick press is detected; a held Start does not generate repeated requests.
Press when not ready: the request is rejected, and restoring the permissive does not start the machine.
Change modes: selecting Remote with Start already held does not create a new start.
Restart separately: cycle receiver power, then PLC power, and check for spurious input transitions or retained commands.
Interrupt the link: confirm the documented output behavior and the machine's response, especially for hold-to-run functions.
Run under real conditions: repeat the tests with the full PLC program, cabinet closed and other equipment operating.
Finish with a channel schedule: remote button, receiver output, PLC address, output mode, pulse duration and command meaning. Write down the startup and link-loss behavior beside it. The next engineer should be able to replace a receiver without guessing what “Channel 2” was supposed to do.
What to confirm before ordering
Send the supplier the exact PLC input-module number and wiring drawing, the number of commands, and whether each function is a pulse, maintained state or hold-to-run request. Ask for the output circuit, contact minimum load, shared-common arrangement, timing and power-recovery behavior.
If you need machine status back at the handset, specify where that status comes from. A receiver acknowledging an RF packet does not prove that the PLC accepted the request or that the machine moved.
A good wireless retrofit leaves the machine's decisions easy to follow. The operator presses a button, the input is recognized, the program accepts or rejects a fresh request, and the reason is visible. Once that path is sound, the radio becomes a straightforward interface rather than a mysterious extra controller.