Ignition Badge Login Works via sendMessage and switchUser

The setup: a barcode reader on the floor is wired to the PLC. A badge scan updates an OPC tag. The Vision client at the station sits on a guest screen and never logs in, or the wrong client logs in, or every client logs in at once.

The badge number is not the hard part. Mapping it to a username and password is a lookup. The hard part is getting a value that exists on the gateway to act on one specific client session.

Skip the Fixes That Never Reach the Right Client

These are the usual first attempts. Each one fails for a specific reason.

• Calling system.security.switchUser from a gateway tag change script. That is not the fault location. switchUser acts on a running Vision client's session. A gateway script has no client and no session to switch.
• Binding or scripting on the badge tag inside the client. Every running client of the project subscribes to that tag. One scan logs in every station that has the window open, including the office.
• Using system.util.retarget. Retarget moves a client to a different project. It does not change who is logged in, and it does not solve routing. You still need to pick the one client that should react.
• Relying on auto-login alone. Auto-login gets the client to a guest screen. It does nothing when a scan arrives.

Retarget only makes sense if the reader is attached directly to the workstation and you deliberately split a login project from the real project. With the reader on the PLC, drop it.

Understand Why the Scan Never Reaches the Workstation

The badge data path ends at the gateway. The PLC updates a tag, the gateway's OPC subscription sees the change, and that is where the data stops.

User switching lives in client scope. To bridge the two, the gateway must push a message out to clients, and the correct client must decide the message is for it. The mechanism:

1. A gateway tag change event script fires on the badge tag.
2. The script calls system.util.sendMessage() to broadcast to running Vision clients of the project.
3. A client-side message handler in every client receives it and checks whether it is the target station.
4. Only the matching client runs system.security.validateUser and then system.security.switchUser.

Two hard limits come with this design:

• A workstation not running a Vision client cannot be touched. Nothing is listening.
• A workstation running a different project will not receive the message. sendMessage targets one project.

Check These Before Writing Any Script

Start here. Most failures trace to one of these, not to the script.

Also decide how the gateway identifies the station. If there is one reader per station, use one badge tag per reader and map each tag to a workstation hostname. If multiple readers share one tag, have the PLC write a station ID alongside the badge number.

Build the Badge-to-Client Login Path

1. Create a guest user with access only to a login window. Configure the project to auto-login as that user and open the window with a "Scan badge to log in" label.
2. Have the PLC present the badge number on a tag, plus either a station ID tag or one tag per reader. Program the PLC to clear the badge value after a short hold, or add a scan counter, so repeat scans produce a change.
3. Add a gateway tag change event script on the badge tag(s). Ignore the initial subscription event and bad quality. Send only the badge and station, not credentials.
4. Create a client message handler (named badgeLogin below) in the Vision project.
5. In the handler, drop the message unless the station matches this workstation. Then resolve credentials, validate, and switch.

Gateway tag change script (adapt names to your project):

Client message handler badgeLogin:

station = payload.get("station")
if station != system.net.getHostName():
    return

# lookupCredentials is your own function: badge -> (user, password)
user, pw = shared.badge.lookupCredentials(payload["badge"])
if user and system.security.validateUser(user, pw):
    system.security.switchUser(user, pw)  # add the args your version's reference requires
else:
    system.gui.warningBox("Badge not recognized")

Check the switchUser argument list in the scripting reference for your Ignition version. If it requires a component event, have the handler write the pending badge to a client tag and let a component on the login window perform the switch from its own event.

Verify the Login Lands on the Right Screen

1. Open two clients of the project on different workstations. Scan at station A.
2. Confirm only station A leaves the guest screen. Station B must stay on the login window.
3. On station A, print system.security.getUsername() in the script console and confirm it matches the badge owner.
4. Scan the same badge twice in a row. The second scan must still trigger. If it does not, fix the PLC clear or counter.
5. Scan an unknown badge. Station A must reject it and stay on guest.
6. Check the gateway logs for script errors from the tag change event, and the client diagnostics console for handler errors.

Avoid the Traps That Break Badge Login in Production

• Passwords in the broadcast. Every client of the project receives the payload before filtering. Send the badge ID only and resolve credentials inside the target client or from a gateway-side store.
• Badge equals password. Anyone holding a copy of the badge number can log in. Treat badge login as a convenience factor and scope roles accordingly.
• Hostname drift. A renamed or reimaged PC silently stops matching. Keep the reader-to-hostname map in one place, not hard-coded per script.
• Initial change events. Without the initialChange guard, a gateway restart re-broadcasts the last badge and logs someone in unattended.
• No logout path. Pair the login with an inactivity timeout or a logout scan that switches back to the guest user.

FAQ