Route barcode scan data to tags by view with a session property

Three views in one HMI project, each with its own scan button, and every decoded string lands in the same tag. When the barcodes are near-identical, no amount of post-processing can tell you which view produced which string. Stop trying to separate the scans by content and carry the view's identity alongside the payload instead. Set a custom session property to the view's key just before each scan — or attach the key as context on the Scan Barcode action — then read it in the Barcode Scanned session event and write the string into the tag that key selects. This guide walks through the property, the event script, the action-context alternative, a three-view test, and the ordering mistakes that quietly send a scan to the wrong station.

What you need

• An HMI project where scanning is session-level: each view carries a Scan Barcode action, and the project exposes a session-level Barcode Scanned event in its Session Events configuration.
• One custom session property: activeScanView, type string, initial value "". Empty means no view has armed a scan.
• Three destination tags, one per view — internal tags or controller paths. The routing table in step 3 only holds paths, so either kind works.
• Script write access from the session event to those tags.

Session properties are scoped per client, not global: every open client carries its own copy, the same rule that keeps a scanner session property per user instead of shared. Two tablets scanning in parallel therefore never overwrite each other's view key.

Why content cannot tell the views apart

The built-in scan-to-tag binding writes whatever the scanner returns into one fixed tag. It never knows which view fired the scan, and three near-identical strings in one tag are indistinguishable afterwards. So route by origin, not content. The view already knows which station it belongs to before the camera starts looking, and that fact is free. The decoded string is never modified — only its destination changes — which keeps the payload exactly what the scanner returned.

Step 1: add the custom session property

1. Open the project's session properties and add a custom property named activeScanView, type string, default "".
2. Keep the default empty: an empty key is the unarmed state, and the event script treats it as nothing to route.
3. Choose short, stable keys — viewA, viewB, viewC — because the same strings must appear in the routing table and in every scan button's write.

The name is yours to pick; the platform's manual demonstrates the same pattern with a session property called scannerInput that a session event updates. What matters is that one session-scoped string holds the armed view.

Step 2: write the view name before each scan

1. On each view, open the event chain that triggers the scan — normally the scan button's press event.
2. Add a step that writes activeScanView with that view's key: viewA on view A, viewB on view B, and so on.
3. Keep the property write and the Scan Barcode action in the same chain, write first: the key must be in place before the scan starts.
4. If one shared view template serves several pages, read the page's URL parameter for the key instead of hardcoding it.

Order is the whole trick. A property write that lands after the scan action leaves the previous view's key armed, and the string goes to the wrong tag with no error anywhere.

Step 3: route the string in the Barcode Scanned event

1. Open the project's Session Events and add a script to the Barcode Scanned event.
2. Check the platform's scripting documentation for your release: it shows the exact names the Barcode Scanned event passes to the script and how to read them. Confirm those names before you paste the body below.
3. Use the script below as the routing body: barcode and context are the payload names, activeScanView the property from step 2, and tagWrite stands in for your platform's tag-write call.

# Barcode Scanned session event
# barcode        : str, decoded string, '' when nothing decoded
# context        : dict, key/value pairs attached to the Scan Barcode action
# activeScanView : str, session property from step 2, '' when unarmed

TAG_PATHS = {   # dict: view key -> destination tag path (str)
    'viewA': '[default]Line1/StationA/lastScan',
    'viewB': '[default]Line1/StationB/lastScan',
    'viewC': '[default]Line1/StationC/lastScan',
}

viewKey = context.get('view', '')   # str: action context wins
if viewKey == '':
    viewKey = activeScanView        # str: session property is the fallback

if viewKey in TAG_PATHS and barcode != '':
    tagWrite(TAG_PATHS[viewKey], barcode)   # tag write; 1000 ms timeout is ample

Keep both guards: an unknown key or an empty string writes nothing, and no update beats a wrong update. Two related patterns drop straight into this event. Keep any write-back non-recursive, as in scan event handling without recursive updates. And if the destination PLC clears the string one scan cycle later, latch it on the pulse, as in scan string disappears after one PLC scan.

Alternative: context on the Scan Barcode action

The session event can also read static key/value pairs attached to the Scan Barcode action itself. On each view, open the action's configuration and add one pair — key view, value viewA — then repeat per view. The event reads the context first and needs no session property at all.

Keep the property read as the fallback even when every action carries context, so a view that loses its key/value pair still routes instead of dropping the scan.

Test the routing

1. Arm view A and scan a test code, for example LOT-4501-A.
2. Check that Line1/StationA/lastScan holds LOT-4501-A, while StationB/lastScan and StationC/lastScan keep their previous values — empty on a fresh project.
3. Repeat on views B and C with LOT-4502-B and LOT-4503-C.
4. Scan a second code from view A and confirm only StationA/lastScan changes.
5. Write "" into activeScanView from a test button, scan again, and confirm nothing is written anywhere.

Write a scan timestamp next to each routed string. A fresh timestamp on a stale value is the signature of a misroute, and per-station timing data is worth keeping anyway — the scan timestamps per workstation pattern gives you the tag layout.

Common mistakes

• Property written after the scan action: the string routes on the previous key. Fix — write first, scan second, same chain.
• View key kept in a view-local property: the Barcode Scanned event is session-level and cannot read it. Fix — session property or action context.
• Shared scan action with no context and nothing armed: every scan lands in the unknown-key branch and nothing is written. Fix — URL parameter or per-action context.
• Empty results written through: a failed scan wipes a good lot number. Fix — keep the empty-string guard.
• Back-to-back scans in one session: the second scan re-arms while the first event is still running. Fix — disable the trigger until the event completes, or queue the reads the way a PLC barcode handshake queues every scan.

When the scan comes from a line-side reader

None of this applies to hardware scanners. A fixed reader delivers the decoded string over Ethernet or serial, the HMI session event never fires, and routing belongs in the PLC: a station number travelling with each read selects the destination — the same origin-not-content idea in ladder logic. Wire the reader as a TCP server with the PLC as the client, pick the physical link from the scanner input methods to a PLC, then split the string into lot and part fields before it reaches the tags. If part of the plant runs a different HMI, the same context-scoping trick exists there: the tag prefix property for picture windows scopes tag addressing to a window instead of a session.

For stations that read a code printed on the part, a fixed code reader sends the decoded string straight to the controller. The MV-ID3013PM-12M-WBN has a 12 mm focal length and a Fast Ethernet interface.

Dense or small codes need more pixels: the LS-CRD-0028 captures 2560 x 2048 frames at 30 fps, up to 60 codes/s, through an 8 mm lens.

Bench checks that read at 60-120 mm fit the LS-CRD-0047 over USB.

When one view must inspect the part as well as read the code, smart cameras run the inspection on the device, and glare on shiny labels is usually a lighting problem — code reader accessories carry the light boards and polarizing covers that clean it up.

The decision

Route by origin, not content. Arm the view with a session property or an action-context key, route in the Barcode Scanned event, keep the empty-string and unknown-key guards on the write, and add a timestamp so a misroute shows itself. When scans come from line-side hardware instead of the HMI client, move the same origin-not-content routing into the PLC. To pick hardware for that path, start from the camera finder or configure a station around a reader; more read-path patterns sit on the code-reading topic page.