Issue
Binding to a Graphic, what is the correct method?
Product Line
EcoStruxure Building Operation
Environment
- Bindings
- Graphics
Cause
In the chapter "Binding Templates - Binding Values Using a Binding Template" in the "EcoStruxure Building Operation - Technical Reference Guide" it states "When creating bindings, follow the recommended general guidelines: create binding between Inputs and Outputs only, and do not create binding to Public Signals".
Does that mean that you should not bind constants used in e.g. curve block or time delays or outputs from expression blocks to a graphic?
Does that mean that you should not bind constants used in e.g. curve block or time delays or outputs from expression blocks to a graphic?
Resolution
Bindings from public signals to graphics is appropriate.
When dealing with directional bindings (i.e. in from a schedule, out to an alarm, in from or out to another program, etc.), it's best to bind to input blocks or output blocks. Graphics bindings are a different animal, though. Among other things, they are bi-directional and only affect the system when the graphic is displayed. They also exist to give the user access and control to values throughout the system (rather than to control routine data flow).
Our primary reason for communicating this best practice is to help with the binding process. Programs will operate with un-bound points, but we're encouraging users to simplify the binding process by relying on just inputs and outputs to interconnect a program with other logic and alarms. In this way, you can visually scan the list of inputs and outputs to see which points still need to be bound. Since most programs typically have a much longer list of public signals, it's easier to overlook a missed public signal binding. Missed graphics bindings should be easier to catch but bindings to another program or alarm may be difficult to identify.
