A remote login works an HMI panel like a local one, and the start command arrives looking the same from either seat. Put remote users on their own account and drive that account's Disable Tag from the alarm bit: while the alarm is On the remote account is shut out, and when the alarm clears the account works again. The local account never touches the gate.
A remote login works an HMI panel like a local one: with remote access on, the user at the PC sees the same screen the operator at the machine sees, and the start command your PLC receives is the same bit either way. Nothing in that command says where it came from. So put the gate on the account, not on the command. Give remote users their own login, drive that account's Disable Tag from the alarm bit, and the alarm blocks the remote seat while the local seat keeps working. This page sets the gate up and gives you the four-case test, about 15 minutes with the machine safe, that shows it doing exactly that.
Why the gate goes on the account
Remote access hands the outside user the running screen, so there is no per-command origin to test at the panel. The documented hook is the account setup. Panels that expose remote access this way define user accounts in the project, and the remote access documentation for this class of panel gives three accounts, each with two optional tags: a Disable Tag and a Notification Tag. Both tags start Off. When a Disable Tag reads On, the account behind it loses access until the tag reads Off again.
That is an exact split. Gate the account only remote users hold, and the alarm shuts one seat. A shared login cannot make that split: one Disable Tag on a shared account takes both seats down together, which is the opposite of the job.
Two shortcuts fail, and it helps to see why. A timer started at the first start answers how long the process has run; the alarm can land anywhere in that window, so a timer locks remote users out during normal running or leaves them armed after an alarm outside the window. Dropping a network switch kills every device on the link for as long as it stays off, alarm or no alarm. The alarm bit is the condition that tracks the alarm.
What you need
- Two or more user accounts on the panel: one for local operators, one for remote users. The account setup gives you three; two are enough here.
- The alarm bit your existing alarm logic sets for the one alarm that must block remote starts, On while the alarm is active.
- One retentive gate bit in the PLC to carry the disable state.
- One more bit for the Notification Tag, if you want the PLC to see remote sessions.
- A safe way to force and clear the alarm during the test, agreed with the people who own the machine. Budget 15 minutes for the four cases: forcing each state for 60 s and checking both seats takes about 3 minutes per case.
- Remote access that already connects. If logins fail before you ever reach the alarm logic, work through test each step of HMI remote access port forwarding first.
Set up the gate
- Split the seats into accounts. Keep the local operator's account for the screen and put every remote user on the remote account. This is the same move as in HMI screen access control for a protected operator view: the account decides what a login may touch.
- Pick the alarm bit. Use the bit the alarm logic already sets for the specific alarm: one alarm in, one gate out.
- Write the gate in the PLC. Example names: the alarm bit
DOOR_OPENsets a retentive gate bitREMOTE_DISABLE;REMOTE_DISABLEresets whenDOOR_OPENclears, in series with a local acknowledge bit if the recovery procedure requires one. Both names are examples; keep your project's own tags. Keep the rung in the fast class of your program so the gate follows the alarm within one scan; at a 50 ms scan the gate lags the alarm by no more than 50 ms, which no remote user can work through. - Point the remote account's Disable Tag at
REMOTE_DISABLE. The panel watches that address and refuses the account while it reads On. A PLC address is the clean choice because the alarm already lives there. - Map the Notification Tag to the second bit so the PLC can watch for remote sessions.
- Repeat step 4 for every other account that can reach the machine remotely. One gated account next to one ungated remote account leaves the hole open.
- Download the project and run the test below before the shift that needs the gate. Leave 10 minutes between the download and the test so any late change to the project lands too.
Example
A bagging line has one alarm that must stop remote starts: guard door open in auto. The panel carries three accounts: OPERATOR and SUPERVISOR sit at the machine, SERVICE belongs to remote support. These account names are examples too. The line runs two 8 hour shifts, and remote support logs in about twice a week.
- Accounts on the panel: 3. Accounts that reach the machine from outside: 1, SERVICE.
- Logic: 1 alarm bit (
DOOR_OPEN) drives 1 gate bit (REMOTE_DISABLE). The rung is one line:REMOTE_DISABLE := DOOR_OPEN. At a 50 ms scan the gate follows the door within 50 ms. - The SERVICE account's Disable Tag points at
REMOTE_DISABLE; its Notification Tag points atSERVICE_ACTIVEfor the session log. - Accounts left untouched: 3 − 1 = 2, OPERATOR and SUPERVISOR.
- Test time: 4 cases, 60 s of forced alarm and 60 s of cleared alarm each, about 8 minutes with the machine held safe.
Result: guard door open, a remote SERVICE login is refused and OPERATOR still starts the line from the panel; door cleared, SERVICE is back within one scan of the door closing. The two local seats never saw a change. Four cases cover the whole test: 2 alarm states times 2 seats.
How to check it worked
Run the four cases with the machine in a safe state, the alarm forced and cleared by hand. Hold each state for 60 s, which is long enough to attempt a login, watch it fail, and try the other seat:
| Alarm | Seat | You should see |
|---|---|---|
| Forced On for 60 s | remote, SERVICE account | login or command refused |
| Forced On for 60 s | local, OPERATOR | start command runs as normal |
| Cleared for 60 s | remote, SERVICE | account works again |
| Cleared for 60 s | local, OPERATOR | unchanged |
Watch the Notification Tag bit while a remote session opens and closes: it should follow the session within a second or two, which confirms you mapped the right account. Then power the panel down for 30 s and back up with the alarm still forced, wait 1 minute for the panel to reload, and run the remote case again. What a panel keeps across a power off and a project download is its own list, and where HMI internal tag retention survives power off and download works through it.
The decision
The gate answers the question the panel leaves open: who is asking. It sits above the machine logic and polices one thing, the remote seat's ability to command. The permissive that refuses the start itself stays in the PLC, driven by the same alarm bit, so the output answers the same whichever seat the request came from. That rung is the safety line; the account gate is the access line.
Recommendation: put every remote user on one account, map its Disable Tag to a PLC gate bit set by the alarm and cleared by alarm-clear plus a local acknowledge, and pass the four-case test, 15 minutes with the machine safe, before the shift that needs it. Gate each additional remote-capable account the same way. When the remote seats sit on other sites, carry the connection over a VPN router set up for remote PLC and HMI access so the gate, and not the network, is what turns remote access away.
Questions
Can two alarms drive the same gate?
Yes. OR the alarm bits into the gate logic and any alarm on the list holds the remote account out until it clears. Keep the list short and deliberate: a gate fed by an alarm that latches for a whole 8 hour shift locks remote users out for that shift too. For a planned maintenance window, drive the same gate bit from a local acknowledge bit and leave the alarm list alone.
Does the gate survive a power cut?
It does if the gate bit lives in the PLC and the rung writes it every scan: the first scan after power-up re-drives it, so an alarm still active puts the gate straight back On. A gate kept only in panel memory is the version that gets lost, because a power off or a project download can clear it. The article on HMI internal tag retention lists what a panel keeps across both.
What is the Notification Tag for?
It is the second optional tag on each account, and it changes while that account is in remote use. Mapped to a PLC bit it gives you a session record without extra hardware: the PLC can log it or hold it in the alarm history. Put a remote-session line on the local screen too, so an operator who watches a refused remote start can see the gate, and not a dead panel, caused it.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.