Right-click Schedules 
under any BacnetDevice and select for this view, or use its view selector (Figure 39). This figure shows this view in “Learn mode” after a discover, with one schedule already exported.
Exported schedules and calendars are schedule export components 
, each “pointing” to a Niagara schedule component in the station. Events in an exported schedule (or calendar) are written
by Niagara (as a client-side operation) to the identified BACnet Schedule object in that BACnet device.
The BacnetNetwork’s Local Device also has a child Export Table, with a Bacnet Export Manager view that permits “exposing” Niagara schedule components in the station as either BACnet Schedule objects or Calendar objects.
However, this is a “server type” export, where exported components are made available to any networked BACnet device (and not written to specific objects in a BACnet device, to which we act as a client). See Niagara Bacnet Server Operation for more details.
The following sections provide more details about exporting to BACnet objects:
Starting in AX-3.1, there are two Add options when exporting to BACnet Schedule and Calendars, reflected in the drop-down control beside the button, as shown below:
-
Device — Data in the schedule that exists in the BACnet device is initially used, overwriting (initializing) the Niagara schedule. Essentially, this starts the same as if the schedule was imported.
-
Niagara — Data in the Niagara schedule overwrites data in the existing BACnet schedule when exported (how it originally worked in AX-3.0).
It is expected that the “Device” option may often be useful. After choosing an option and clicking , the dialog appears. The Add (and Edit) dialog for exporting to a BACnet object is shown in Figure 40.
The default name is the target BACnet object’s name, and you typically leave this at default. The most critical property is the Supervisor Ord (null by default).
In the Supervisor Ord property, click the open folder 
for a Select Ord popup dialog, in which you can navigate to find the source Niagara schedule or calendar in the station (Figure 41).
Another property of interest (to BACnet) is the “Priority For Writing” property, which defaults to priority 16. Set this as needed by the application in the BACnet device.
Finally, the default “Execution Time” (write synchronization) to the device’s BACnet object is at a continuous 5-minute “Interval”. If needed you can adjust this, or set to “Daily” or even “Manual” (whereby an from the Bacnet Schedule Export Manager is required).
When you click in the Add dialog to create the schedule export, the component is added to the database, and an attempt is made to write the (source)
Niagara configuration into the (target) BACnet Schedule or Calendar object. If successful, the status of the BacnetScheduleExport
component remains “ok,” and its row in the Database table of the export manager remains uncolored (white).
However, if any portion of the BACnet write failed, the BacnetScheduleExport has a “fault” status, and its row in the export manager’s Database table appears colored orange, as shown in Figure 42.
In the case of fault, access the BacnetScheduleExport properties and examine the Fault Cause, and if necessary adjust the Skip Writes property.
To access the property sheet of a BacnetScheduleExport component, right-click it from either the Nav side bar, or within the Database table of the export manager (as shown in Figure 43).
Included is a “Fault Cause” property that provides a text string description if a write operation failed to the target BACnet Schedule or Calendar object. For example:
“scheduleDefault::Property:Write Access Denied”.
In addition, a Skip Writes property lets you adjust which property types in a target BACnet Schedule object are written to, upon an export from a Niagara weekly schedule component.
Depending on the BACnet device’s implementation by vendor, some properties of its Schedule objects may be read-only. For example, a BACnet Schedule object may allow writes to its weekly schedule events, but not to its exception schedule (“Special Events” in Niagara), if they are read-only (or perhaps do not even exist). Or, the object’s “Priority_For_Writing” property may be read-only, or the object may not even have a weekly schedule or exception schedule (a Schedule must only have one or the other, it may have both).
To allow for this, a BacnetScheduleExport component provides a “Skip Writes” property in which you can specify the properties to be written upon an export from Niagara. From the property sheet, click the far-right side control for a popup Facets Editor, as shown in Figure 44.
As shown above, the default is to not skip writing any properties upon export (false for all), meaning that all property areas of the source Niagara schedule component are written to the target BACnet Schedule object. As needed, set any of these in the Facets Editor to true, such that Niagara does not attempt to write to them. This can allow an export without a fault (see Figure 42).
Skip Writes does not apply if exporting to a BACnet Calendar (from a CalendarSchedule).
The Skip Write property areas (facets) are:
-
scheduleDefault — Corresponds to “Default Output” of the source Niagara schedule.
-
weeklySchedule — Corresponds to the regular day-of-week events of the source Niagara schedule, as defined in its Weekly Scheduler view.
-
exceptionSchedule — Corresponds to all “Special Events” of the source Niagara schedule.
-
effectivePeriod — As defined by the “Effective Period” in the source Niagara schedule.
-
priorityForWriting — As defined by the “Priority For Writing” property in the BacnetScheduleExport component itself (instead of the source Niagara schedule).