Issue
References Guide and changes from release 1.3 to release 1.4.x and forward
Product Line
EcoStruxure Building Operation
Environment
StruxureWare Building Operation site with regards of release 1.3 to release 1.4.x
Cause
In release 1.3 and earlier the reference system was relaxed allowing for bindings to be created in ways that made the applications error prone.
In release 1.4 this is now being more strictly controlled, which will allow the system to:
- Help the user to not unintentionally create faulty combinations of references, resulting in bad/unpredictable application behavior and last man win situations
- Better understand and control how references will behave in copy/paste/move/delete situations.
- Improve performance in the system, e.g. the limitation of variable connectors is removed.
For the complete Reference Guide, please download the pdf from the Download Center
For instructions on how to upgrade an Automation Server and how to get the conversion log, See Upgrading Automation Servers from 1.3 to 1.4.
For explanations of the entries found in the conversion log, See AS Conversion Log Analysis.
Resolution
What has changed
There are 2 areas which have changed:
1. Rules
Programmatic control: A reference means that data is sent from A to B. In Release 1.3 it was possible to send data from A to B and from C to B. This gave a "last man win" situation. In Release 1.4 it is only possible to send data from exactly one source to a recipient. This means A to B and C to B is no longer allowed.
User control: This is where properties are displayed in graphics, watch windows and other client components. In release 1.3 it was possible to change a property that was programmatically controlled. This gave a "last man win" situation. In release 1.4 it is not possible to change a property as a user if this property is programmatically controlled by something else. The property will automatically be read only for the user.
Public signals: In release 1.3 and earlier, it was possible to programmatically control a public value in programs. Public signals are intended to be used for user control, while inputs are intended for programmatic control. In release 1.4 this is now changed to the following:
- Public signals in programs (FB/Script/Menta) can be referenced by user control - NOT by programmatic control
- Public signals intended for programmatic control must be changed to inputs and rebound.
This will give the following benefits:
- Public signals cannot be forced, while inputs can. If a user needs to take control of a programmatically controlled input, via e.g. graphics or watch window", he will force the signal and there will be no risk of a program overwriting the user value.
- As stated above - if an input is programmatically controlled, this will for the user be read only. However, force is still possible.
- There is no more risk for "last man wins" situation between user control and programmatic control. The system will remove any ambiguity with these new sets of rules.
Update: Release 1.4.1 and later version add the feature of binding to PVB/PVI/PVR back. But for Script, it still keeps the same.
LonWorks Local Node nvis: In release 1.3 it was possible to programmatically write to local node NVIs. These NVIs exist to receive data from the LonWorks network. This gave a "last man win" situation. In release 1.4 it is no longer possible to programmatically control local node NVIs.
2. Definitions
In release 1.3 a reference could be
a) relative
b) system absolute
c) server absolute
In release 1.4 a reference will be
a) "normal"
b) Locked
A reference created by the user will always be normal (which means relative). In the bindings view the user can then choose to "lock" a reference (which means server absolute). The references will behave identically until a copy/paste (or import/export) operation is done.
Upgrade
Upgrading from release 1.3 to release 1.4 will apply the new sets of rules. It is there for very important to read the log to understand if any existing references in release 1.3 will be impacted during the upgrade
For AS: In the Device Administrator the logs are available before the upgraded DB is deployed to the AS. It is up to the user to either examine the upgrade log, make changes in running release 1.3 and rerun the upgrade, or to make the changes after upgrade. It is recommended to do changes prior to upgrade to ensure a fully functional system directly after upgrade. Some warnings are benign and can be disregarded, please refer to release notes for more information.
IF an upgrade detects that references will be impacted, the user will be informed about this with a orange progress bar indication and a written information that the upgrade succeeded with warnings.
After upgrade, all invalid or unresolved references will be visible from WorkStation for further examination if needed.
