Sedona Framework network components and child components are found in the
sedonanet
palette — for SedonaNetwork
jen6lp
palette - for SedonaJen6lpNetwork
Table 1 compares the palette for each module, as opened in Workbench.
As with most other NiagaraAX drivers, you typically do not need to work from a module’s palette. Instead, the various Sedona
manager views simplify component creation, enforcing proper component hierarchy. A possible exception is use of the two “ChopanTargetPoints”
in a SedonaJen6lpNetwork, which are “convenience” components that can be useful when making “target points” in the JACE to
receive read-only values from a Jennic-based device, via CHoPAN.
More differences and similarities between the two Sedona Framework network types are provided below:
From the property sheet of either type of Sedona Framework network, you have access to all the major network-level properties and container slots. See Table 2.
As shown in Table 2, the SedonaJen6lpNetwork (right) has many more properties than the SedonaNetwork (left). Most of these are for the Jennic 802.15.4 configuration of the Sedona Jennic option card in the host JACE controller, for operation as the “Jennic coordinator” for the network.
The SedonaJen6lpNetwork also has “Pan Info” related properties, as do its child SedonaJen6lpDevice components, providing “diagnostic” data useful for troubleshooting wireless Jennic communications.
Currently, the SedonaJen6lpNetwork is also the only Sedona Framework network to use “CHoPAN”, reflected by the “ChopanServer” container slot in the network’s property sheet. Child SedonaJen6lpDevice components also have a related “Chopan virtual” components. CHoPAN is a lightweight “sessionless” protocol that allows data sharing between devices (and the JACE), without requiring the session-based Sox protocol.
Both Sedona Framework networks have a default “device manager” view for adding and managing child devices. Both networks also have an available “Sedona Device User Manager” view and “Sedona Manifest Manager” view. The SedonaJen6lpNetwork also provides a “Pan Sheet” view for graphically representing the Jennic wireless network’s node (tree) hierarchy, including all current “Pan Info” data for the JenNet network.
For more details on properties, actions, and views of Sedona Framework network components, see:
Device types differ between the two Sedona Framework networks—each network has only one valid device type:
SedonaDevice — for SedonaNetwork
SedonaJen6lpDevice — for SedonaJen6lpNetwork
You cannot put one device type into the opposite network type.
As shown in Table 3, the SedonaJen6lpDevice (right) has more properties than the SedonaDevice (left).
Most additional properties of a SedonaJen6lpNetwork relate to its Jennic 802.15.4 operation, including “Pan Info” and “Maintenance Mode” data. The “Chopan Virtual Gateway” is for modeling the Chopan client interface in the Jennic-based device.
In addition to the standard “Ping” action on the SedonaDevice, a SedonaJen6lpDevice also has “Pan Info” actions and a “Request Maintenance Mode” action.
For more details on properties, actions, and views of Sedona device components, see:
Regardless of Sedona network type, any Sedona device component has an important device extension: Points, for adding/managing Sedona proxy and action points. The Sedona Point Manager view on any device’s Points extension has a a “learn” mode that allows either online or offline point discovery.
Sedona proxy points (and action points) work in the same manner regardless of network type. Although Sedona proxy points in SedonaJen6lp device can use “Chopan” as an alternative to Sox polling or event messaging for updates to the JACE station, the efficiencies provided may mean more with wireless (Jennic) devices that it would with Ethernet/IP capable devices.
Sox gateway access and Sedona Tools access (as well as Sox tunneling) to any networked Sedona Framework device works in the same manner regardless of a device’s Sedona Framework network type. This allows “native” Sedona Framework app programming and/or device provisioning. However, if you are accessing a hibernating[1] Jennic-based device in a SedonaJennic6lpNetwork, you must make a “maintenance mode” request (action) on that device to allow Sox access.
For more details on these topics common among Sedona Framework networks, see:
[1] Sedona Framework support for hibernating devices (typically battery powered devices) is not widely available in the current Sedona Framework TXS release. However, the SedonaJen6lpNetwork driver in the NiagaraAX station is “ready” for such device support, including “maintenance mode” operation.
Copyright © 2000-2014 Tridium Inc. All rights reserved.