PUP-specific network slots

In addition to Common PupNetwork slots, the PupNetwork contains key PUP configuration properties that enable it to operate on the PUP network, as follows:

Unit Number

The PupNetwork behaves as a master or peer device on the PUP network, and as such must have an address in order to send and receive directed messages from the network. This is the address.
Token Pass Config

A container for all properties that govern how the driver handles token passing. See the next section Token Pass Config.
Peer List

This is a dynamic list of devices which require the token to be passed to them. Whenever the driver determines it is time to pass the token to a device on the network, it selects the device from this list which has not possessed the token in the longest amount of time (that is, the “oldest”).
Allow Time Sync Broadcast

If set to true, then time sync messages will be broadcast to address 65535 at an interval determined by the next property “Time Sync Frequency.” The time broadcast is the local time of the platform the driver is running on, and the “holiday” bit is set according the following property “Holiday.”
Time Sync Frequency

The frequency at which the time sync messages are broadcast, if enabled.
Dispatch Entries

Diagnostic only.
Holiday

The time sync message includes a bit for “Holiday.” The “Sync Time” action on the PupNetwork will set or reset this bit in PUP controllers based on the value of this property. This is a linkable property that can be set from a schedule object or some other component.
Device Type Files

Specifies an ord to the XML-formatted file that is referenced when doing online “Discovers” of PUP devices and proxy points. The file describes device types, channel names, channel search ranges, and so forth. By default, the ord points to the deviceTypes.xml file included within the aapup.jar.

If needed, you can unzip and edit/modify this file—and then copy the modified file back onto JACEs running the PUP driver (typically under the station directory), where you can point to it with this PupNetwork property. For more details, see Modifying DeviceTypes.xml.

Token Pass Config

In the PupNetwork property sheet, click to expand this container to access child properties (Figure 3).

Figure 3. Token Pass Config properties of PupNetwork

Token Pass Config properties include the following:

Token Passing Enabled

Select either enabled or disabled from the drop-down menu. If token passing is disabled, then the PUP driver becomes a strict PUP Master, and all devices on the network should be configured as slaves. If token passing is enabled, then tokens are passed based on the values of the remaining Token Pass Config properties, as described below.
Pass to Down Devices

Normally set to false, this property governs whether or not the driver attempts to pass the token to devices that were previously marked as non-responsive. Since a token pass does not expect an explicit response from the device being passed the token, the token will have to be recovered if the device is still not responsive (see the related properties “Token Recovery”, “Token Recovery Timeout” and “Token Recovery Count”).
Peer Type

(Read-only) The PUP driver is always considered a “Full Admin”. This cannot be changed.
Token Recovery

Enables or disables token recovery.

If Token Recovery is enabled, verify that no other device on the network is configured as a Full Administrator, with token recovery enabled. To do this, see attributes “TP” and “ER” in the system channel (channel FF00) of every device.
Token Recovery Timeout

The amount of time the driver will wait with no detected PUP traffic, before declaring the token dropped. Any valid PUP message detected (sent or received by any device on the network) resets this timeout.

Typically, this is set to about 1 second. This is the amount of time that no network traffic is detected AFTER PASSING THE TOKEN. As an example, if we pass the token from the JACE (Niagara aapup driver) to unit 50, and unit 50 then initiates and talks to other units for 5 second before passing the token back to us, this is OK since we are looking for “idle” time before saying a token is dead. As long as unit 50 does not stop talking for more than 1 sec (or whatever period we have this property configured to), we won't attempt to recover the token. Note that it would be OK for unit 50 to pass the token on to someone else—we just look for idle time on the comm line.
Token Recovery Count

The number of times the token has had to be recovered. This count is reset at startup, or may be reset by invoking the “Reset Token Recovery Count” action (right-click on “Token Pass Config”, and select “Actions”).
Pass Token On Transaction Count

If enabled, then a count of up to “Transactions Per Token” transactions can be sent before the token is passed to a device on the PUP trunk.

The “Pass Token on Timeout”/ “Time Per Token” properties may cause a token pass faster than this if enabled and the timeout expires before this number of messages is reached. In the case where both “Pass Token on Transaction Count” and “Pass Token on Timeout” are enabled, only one of the two conditions must be satisfied to pass the token.
Transactions Per Token

The maximum number of transactions that can be transmitted to the bus by the PUP driver, before the token is passed to the next available peer. This count does not include retries (for example, if this property is set to 2, and the “Retry Count” property is set to 3, then up to eight messages [2*(1+3)=8] may be sent in an attempt to deliver up to 2 transactions).
Pass Token On Timeout

If enabled, then transactions may be sent until the timer expires, at which point the token will be passed. This guarantees that the PUP driver does not “monopolize” the token for extended periods of time, even if there are no messages to send.

It is recommended you set this to “true” and adjust the “Time Per Token” property to an appropriate value. The reason for this is that if you pass the token only on transaction count, you run the risk if you have no points subscribed, the only transactions you'd be sending are the “ping” messages, and these are typically on the order of minutes, so it can take quite a while for the transaction count to be hit.
Time Per Token

The time allowed for token ownership before the token must be passed. The timer is started whenever the token is recovered, or whenever the token is received from a device on the PUP network.

If “Pass Token on Transaction Count” and “Pass Token on Timeout” are both enabled, it is recommended to set this value slightly longer than the time it would take to send “Transactions per Token” transactions. In the case where both “Pass Token on Transaction Count” and “Pass Token on Timeout” are enabled, only one of the two conditions must be satisfied to pass the token.
Token Snoop

This is a diagnostic display which shows recent activity pertinent to token passing. This display is 8 lines long—usually long enough to diagnose token problems, especially when coupled with the next property. A new snoop line is started every time the token ownership is obtained by the driver (that is, whenever the token is passed from a device on the network to driver’s unit number).

Figure 4. Example Token Snoop

There are 3 basic types of events shown (see Figure 4 above):
- [1>79][79>1]
  
  Items in square brackets indicate a token pass from one device to another. In this example, device 1 (the driver) passed a token to device 79, and device 79 sent the token back to unit 1.
- [1>5385]<65535><11403><11403><11403><65535>[5385>1]
  
  Items in angle brackets (like <65535> in this example, represent destination addresses of messages sent from other devices on the network. In this example, you can see that device 1 passed the token to device 5385, which in turn broadcast a message (to address 65535), sent 3 messages to device address 11403, broadcast a second message (to address 65535), and then sent the token back to address 1.
- If you see any “!” embedded in the list, it most likely means someone else on the network is recovering the token. The exclamation point will appear on both sides of the unit number which incorrectly tried to pass a token.
  
  Token recovery events are denoted by the text “recover” in the display.
Log Snoop On Token Recovery

If set to “true” then every time there is a “recover” event, the “Token Snoop” data is pushed to the Pup Log. This is a valuable tool to diagnose token passing issues.