Sedona Framework networks: quick comparison

Sedona Framework network components and child components are found in the

Table 1 compares the palette for each module, as opened in Workbench.

Table 1. Palettes for modules sedonanet (left) and jen6lp (right)






NoteAs 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:

Sedona Framework network component differences

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.

Table 2. Property sheet for SedonaNetwork (left) and SedonaJen6lpNetwork (right)






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:

Sedona device component differences

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).

Table 3. Property sheet for SedonaDevice (left) and SedonaJen6lpDevice (right)






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:

Similarities in Sedona Framework network types

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.