Issue
Changing ElecTypes on points on a Continuum BACnet controller after the system is saved into the BACnet side can cause major database mismatch problems, COV failures, deletion of EventEnrollment points and graphic points. (Updated 10/27/08)
Environment
Continuum BACnet
Cause
Continuum delete the defaults BACnet object type "AnalogValue" in the database and create a new BinaryValue or vice versa.
Resolution
In a continuum BACnet system, the Continuum BACnet controller creates a BACnet point for every Continuum point that is created on the Infinity side. For instance if you create an InfinityNumeric it defaults as a BACnet object type "AnalogValue" and creates that point in that class in the controller. If that controller is then saved into the BACnet side through Cyberstation it will create that point in the Continuum database under the AnalogValue class. If you then program other controllers to use that point, a COV subscription will be created to the controller owning that point.
If you later remember that you wanted this point to be a digital point so you change the BACnet object Type to a BinaryValue. What then happens is the controller changes the class the point belongs to in the BACnet side. When the controller is saved into the BACnet side, Continuum will delete the AnalogValue Bacnet point in the database and create a new BinaryValue point in it's place with a new Object ID in the Continuum database. This creates several problems.
The first issue will be that any COV subscriptions for this point will now fail, because the Plain English program that was referencing the point will still try to subscribe to the AnalogValue point, but it is now a BinaryValue point. Data Sharing will stop.
The second issue will be that the Save on the BACnet side will find a duplicate point in a different class and it will delete the older AnalogValue point and create a new BinaryValue point. During this process it will also create this point in the BACnet database with the "Full Name" of the object the same as it's Alias. Because the system needs to keep the Infinity side and BACnet side in sync, it will replace the full name on the infinity point with the Alias.
Further issues such as this point being used in a graphic, an EventEnrollment, a report, etc.. Will be deleted from these objects because it is now a different point and will have to be reattached to these objects. To avoid these issues You should first disable the BACnet preference "Automatically save new BACnet devices to Database". This will stop automatic database synchronization on the BACnet side when you are creating, deleting and changing points during the site commissioning and programming.
Secondly you should create points with the correct BACnet object type before referencing them in a data sharing program.
Third you should only save the points into the BACnet side after you have completed the correct point configurations in all classes (Inputs, outputs, numerics, etc).
Finally, if after the system configuration and programming is completed, if you need to change a BACnet object type, you should first delete the point from the BACnet side of the database, change and save the point back to the controller, and then recompile any Plain English programs in any other controllers that were referencing that point for a COV subscription. The controller can then be saved back into the BACnet side. If that BACnet point was used in a graphic, or an EventEnrollment it will also need to be reattached.
