Bidirectional Tag Binding Writes Only on Client-Side Changes

On this v7.7.4 project, almost every component whose data property is bound to a tag has Bidirectional checked. That includes labels, numeric displays, and input fields, and most of the tags are OPC tags. On display-only components the checkbox has no practical effect, because nothing on the client can change that property. On input components it is a live write path to the controller. There is no project-wide switch to turn it off. You fix it per component, and you can also block writes further down the chain at the tag, the driver, or the PLC.

Why does the binding dialog show Bidirectional on components that only display values?

A tag binding always reads: when the tag value changes, the component property updates. With Bidirectional enabled, the binding also watches the property. If the property changes from any source other than the tag itself, the binding writes the new value back to the tag. For an OPC tag, that write goes through the driver to the controller address.

A label or numeric display has no user edit path, so its bound property only changes when the tag pushes a new value. That update is not echoed back as a write. The flag stays dormant.

Editing the property in the Designer is a different case. When the Designer's communication mode is read-only, any attempt to write to the bound tag is rejected and an error pops up. That error shows the write path exists and the Designer is blocking it. It is not a fault in the binding.

Check before moving on: open the binding dialog on one display component and on one input component. Confirm that both show the same tag path and the same Bidirectional state. What separates them is whether the client can change the property.

Which components can actually push a value to the PLC?

Sort the screen by edit path, not by component family. The table below separates harmless bindings from real write paths.

Check: list every input-type component on each window, and mark which ones are meant to be operator write points. Everything else on that list is a candidate for clearing Bidirectional.

How do I turn Bidirectional off on the components that need it?

v7.7.4 has no master setting for bidirectional binding. The only global lever is putting the client into a read-only state for a user. That blocks every write, including the setpoints you want, and it shows error messages whenever the operator touches a bound input. Use per-component edits for anything finer than that.

1. Open the window in the Designer and select the input component.
2. Open the binding on the data property (value, text, selected state, and so on).
3. Clear the Bidirectional checkbox and click OK.
4. Repeat for each unintended write point from your list.
5. Save and publish the project so clients pick up the change.

Two approaches both work: clear the flag on every component, or only on inputs. Clearing it only on inputs is faster and covers the actual risk. Clearing it everywhere makes the project self-documenting, because an engineer can then read any binding and know that a checked flag means an intended write. On a large project, do inputs first and clean up display components as you touch those windows.

Check: in a client session, type a value into a cleared input field and commit it. The tag value in the tag browser must not change, and the field should revert to the tag value on the next update.

Where else can a write be stopped: tag, driver, or controller?

A binding write only reaches the process if every layer below it accepts it. That gives you defense in depth even when a component is misconfigured.

If the controller does not grant write permission, a bidirectional binding cannot change the PLC value, even when the client or Designer is in read/write mode. That makes the controller setting the strongest backstop for monitoring-only data. It is also the least visible from the SCADA side.

When a write fails, you can tell a binding fault from a tag or permission fault by the tag's state:

• Binding fault: the tag's quality stays good while the write fails.
• Tag or permission fault: the write attempt shows a failure or error quality on the tag.

Check: for each OPC tag that must never be written from SCADA, confirm read-only access at one or more layers below the component. Record which layer it is.

What makes a display component write unexpectedly?

The dormant-flag argument depends on the property changing only from the tag. It breaks in these cases:

• Scripts: a script that sets a bound property (on window open, a button, a timer, or a property-change handler) triggers a write through the bidirectional binding.
• Chained bindings: another binding or a custom property that feeds the same property can do the same.
• Templates and copied components: copying a setpoint entry field to make a display clone carries the checked flag into a place nobody expects writes.
• Designer read/write mode: editing a bound property while the Designer is in read/write mode writes to the live PLC.

Check: search the window and project scripts for assignments to bound properties. For each hit, either clear Bidirectional on that binding or confirm the write is intended.

How do I prove no unintended write reaches the controller?

1. Put the Designer in read-only communication mode and edit a bound display property. The write must be rejected with an error, and the tag must not change.
2. In a runtime client, exercise every input component you cleared. The tag value must stay unchanged in the tag browser.
3. Exercise every intended setpoint input. The tag value and the PLC register must both update to the entered value.
4. For protected tags, force a write from a test input or a script. Confirm the tag, driver, or PLC layer rejects it and the PLC value is unchanged in the programming software.
5. Trigger each script that touches bound properties. Confirm no unexpected value changes appear at the controller.

FAQ