A dynamic text object cannot receive text; it shows whatever string its assigned tag holds. Bind the next screen's object to one selected-account string tag and give each radio choice an event that writes its own returned string into that tag before the screen change.
Selecting an account on one screen and showing it on the next trips a lot of first HMI projects, because the step that looks obvious, assigning text to the display, is the one the software refuses.
A dynamic text object has no value of its own. It shows whatever string its assigned tag holds at that moment. The fix is a data path, not a property edit: create one selected-account string tag, point the next screen's dynamic text object at that tag, and let each radio choice's event write its own returned string into it. The events database already writes tag values, so every piece exists; the job is to aim every write at the one tag the next screen reads. This page walks the path for the common case, up to 3 accounts returned for a validated PIN, and gives the checks that separate a binding problem from a mapping problem.
Why the display ignores your event write
A dynamic text object is a viewer, not a destination. It draws the string currently stored in the string tag assigned to it, and nothing else. Writing an event value to some other tag leaves the display untouched, because the object never looks at that tag.
The radio button's caption is the second trap. The text printed beside a choice tells the operator what the choice means; the selection value tells the project which choice was made. Those are different data, and the caption is not automatically available as a string to copy. The strings worth writing are the account strings the database query returned through the panel's web server, because those are what the next screen is meant to show.
If your buttons are static and all you need is a label that follows a saved value, that is the simpler case covered by show a saved name on an HMI screen when buttons are static.
What each symptom points to
- The next screen is blank after a valid selection. The write landed in a tag the object is not bound to, most often one of the source account tags. Panel-local tags start blank, so a tag that was never written has nothing to show.
- An account shows, but the wrong one. The choice-to-account mapping is off: one choice's event writes another choice's string. The binding is fine; fix the mapping.
- The display never changes, not even once. The object is most likely bound to a numeric selection tag. The object needs a string tag; a numeric value written where a string belongs shows nothing.
- The last transaction's account still shows on a new PIN entry. The selected-account tag was never cleared. Clear or overwrite it when the new transaction starts.
One selected-account string tag for the next screen
Create one string tag to represent the selected account and assign that tag to the dynamic text object on the destination screen. Keep the returned account strings in their own tags, separate from this one, so the choices hold their values while the selection moves.
Decide where the tag lives. A panel-local tag keeps the whole transfer inside the panel project, and for a value only the display reads, local is the simpler choice. A PLC-backed string makes the choice visible to PLC logic and adds the PLC to the data path; confirm its address and data type in the project before any event writes to it, and never point the write at an unrelated PLC tag.
Write the string from each choice's own event
Open the events database and give each radio choice its own event that writes that choice's returned account string into the selected-account tag. Three choices mean 3 events, each with 1 string write. Writing on the selection event itself puts the string in the tag before any navigation can run, so the order of the write and the screen change stops mattering. If the project forces both actions into 1 event chain, put the write first and test the transition separately.
If the radio control offers only a numeric selection value, map each valid code to its matching account string in the PLC and keep that PLC-facing value in a tag of its own. The display object still needs the string, so the string write has to happen somewhere; a numeric code written into the display's tag shows nothing. The screen change itself can come from a button or from a PLC condition, and the condition-driven case is worked through in event triggered screen change on an HMI when a PLC alarm bit turns on.
Example: carrying 1 of 3 returned accounts to the confirmation screen
Inputs, and where each comes from:
- 3 account strings returned with the validated PIN, through the panel's web server from the SQL database. The setup allows up to 3 accounts per PIN; ACCT-1042 is the example string for the first returned account.
- 3 radio choices on the selection screen, 1 per returned account.
- 1 selected-account string tag, panel-local.
- 2 screens: the selection screen and the confirmation screen.
The rule in words: the confirmation screen's dynamic text object shows the string its assigned tag holds and accepts no direct write, so each choice's event must write its own returned string into the one tag the object reads.
The arithmetic: 3 choices with 1 event each give 3 × 1 = 3 event writes, all aimed at the same 1 tag. The confirmation screen carries 1 dynamic text object bound to that 1 tag and receives 0 writes of its own. Selecting choice 1 runs 1 event, puts ACCT-1042 into the tag, and the confirmation screen then shows ACCT-1042. Selecting choice 3 instead overwrites the tag with the third returned string, and the same screen shows that string.
The result: 3 writers, 1 tag, 1 reader. The object shows whatever the tag holds, which is the last selection made.
Size the confirmation text for where the operator reads it. The FHWA planning figure of 30 ft of viewing distance per inch of capital letter height, or the safer 20 ft per inch, applies here too: an account read from 10 ft needs capitals about 0.33 in tall at the safe ratio, which most panel text objects meet at their default sizes.
The decision, with its check: bind the confirmation object to the selected-account tag. If all 3 events fire and the screen still shows blank, exactly 2 links can be wrong: the events write into a different tag, or the object is bound to a different tag. Check the event targets first, then the object's tag assignment; those are the only 2 places the string can fail to arrive.
Check it before you rely on it
Check the write and the binding separately. The events database shows which tag each event targets; the object's configuration shows which tag it is bound to. Then select each choice in turn: with 3 choices that is 3 selections, and the confirmation screen must show exactly the chosen account each time. Finish by starting a new PIN entry and confirming the selected-account tag was cleared, so the second transaction cannot inherit the first one's account.
Startup and PLC-backed tags
Panel-local tags start blank, so events fill them and the first transaction sets the value. Do not use panel startup to write PLC tags: the write can run before the PLC is ready, and the value can be lost or overwritten. When the PLC needs initial values, write that logic in the PLC.
If PLC logic must act on the chosen account, gate that logic so it runs only while the confirmation screen is up; run PLC logic only on the HMI current screen number tag shows the screen-number gating pattern.
The decision
Recommendation: bind the confirmation screen's dynamic text object to one panel-local selected-account string tag, and give each radio choice its own event in the events database that writes that choice's returned string into the tag. Use this pattern whenever the radio control can fire one event per choice and write a string, which covers the common case of up to 3 accounts returned for a validated PIN. Fall back to a numeric selection code mapped in the PLC only when the control offers no string write, and keep that PLC-facing tag separate from the display text. Clear the selected-account tag when each new transaction starts.
More fixes for tag and event problems on machine and control screens sit in the shop-floor screen articles.
Questions
What happens when the query returns fewer than 3 accounts?
Fill each visible choice from its own returned string and disable or hide the choices that have no account behind them, so an empty string cannot be written into the selected-account tag. Enable a choice only after its returned data is in place. If the interface gives no ready signal, build the readiness condition from the status information it does provide instead of waiting a fixed delay.
Does the selected-account string tag need to live in the PLC?
No. A panel-local tag keeps the whole transfer inside the panel project, and panel-local tags start blank, which suits a value only the display reads. Map the account to a PLC-backed string only when PLC logic must act on the choice, and then define that tag and its data type separately from the display text.
Can two screens show the same selected account?
Yes. Every dynamic text object bound to the selected-account tag shows whatever the tag holds, so a second screen can reuse the tag with no extra writes. Clear or overwrite the tag when a new transaction starts so a previous account cannot appear on either screen.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.