Knowledge Base
cancel
Showing results for 
Search instead for 
Did you mean: 

SmartStruxure Building Operation - Binding to a Graphic, what is the correct method?

Issue

Binding to a Graphic, what is the correct method?

Environment

Bindings

Graphics

Cause

On page 497 in the manual "Technical reference guide 04-12006-01-en" 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?

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 in our region 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.

Tags (1)
Labels (1)
Version history
Revision #:
1 of 1
Last update:
‎2018-09-06 10:48 AM
Updated by: