Communication Parameters

UNINTENDED EQUIPMENT OPERATION

Do not change these protocol parameters, except on the advice of Technical Support for this product.

Failure to follow these instructions can result in death, serious injury, or equipment damage.

Parameter

Allowable Values

Default Values

Description

[DNPR]StartupStaggerDelay

0 to 30000 ms

0

Time between allowing the first unit on each port to come online at startup. This is to avoid large amounts of startup traffic.

[DNPR]MaxDNPTimeOuts

[<unit>]MaxTimeOuts

0 to 65535

1

Number of unit timeouts before returning a ‘unit offline’ reply.

Unit timeouts can result from both the I/O server requests and driver polls (timeouts may result from the I/O server request or driver poll). Refer also to parameter
[DNPR]RapidOfflineDetectionDefault.

[DNPR]
RapidOfflineDetectionDefault

[<unit>]RapidOfflineDetection

0 – Rapid detection is disable

1 – Rapid detection is enable

1

If RapidOfflineDetectionDefault is set to 0 (false), then a unit will only be placed offline due to a detected communication breakdown during regular polling requests.

Unsuccessful I/O server requests (e.g. Tag Writes), will not be taken into account when determining a units online status.

This parameter allows the driver to be configured to either provide rapid detection of offline status, or to provide a consistent interval of time before a unit is marked as offline.

[DNPR]MinorIINSelectErrorFilter

Refer to description

0x0000

This parameter allows the user to turn on the ability of the driver to generate a driver error (CDNP_ERR_IIN_ERROR) to notify the user of several IIN (Internal indications bits) errors.

These IIN errors are normally not considered serious, however in some circumstances, the IIN errors may need to be treated as if the unit is not operating correctly. Any combination of the following IIN errors can be detected by OR-ing the selected IIN error bits together to create the MinorIINSelectErrorFilter value.

It should be noted that the errors are only notified under certain conditions. The conditions are noted in the Driver Specific errors section.

The IIN bit errors that can be OR-ed together for selection purposes are shown below. The meanings of the terms are also described in the Driver-specific errors section.

BAD_FUNCTION_IIN 0x0001
OBJECT_UNKNOWN_IIN 0x0002
OUT_OF_RANGE_IIN 0x0004
BUFFER_OVFL 0x0008
EXECUTING_IIN 0x0010
CONFIG_IIN 0x0020
LOCAL_IIN 0x2000
TROUBLE_IIN 0x4000

0x0000 means the error filter is off.

Be reminded that the user can define tags to determine the status of the IIN flags returned from the device. Be reminded also that CDNP_ERR_IIN_ERROR is a severe level driver error and will force the unit offline and generate #COMs on the screen.

[DNPR]MinorIINSelectFilter

Refer to description

0xFFFF

This parameter allows the user to turn on the ability of the driver to generate a driver error (CDNP_WARN_IIN_ERROR) to notify the user of several IIN (Internal indications bits) errors.

These IIN errors are normally not considered serious. Any combination of the following IIN errors can be detected by OR-ing the selected IIN error bits together to create the MinorIINSelectFilter value.

It should be noted that the errors are only notified under certain conditions. The conditions are noted in the Driver Specific errors section. The IIN bit errors that can be OR-ed together for selection purposes are shown below. The meanings of the terms are also described in the Driver-specific Errors section.

BAD_FUNCTION_IIN 0x0001
OBJECT_UNKNOWN_IIN 0x0002
OUT_OF_RANGE_IIN 0x0004
BUFFER_OVFL 0x0008
EXECUTING_IIN 0x0010
CONFIG_IIN 0x0020
LOCAL_IIN 0x2000
TROUBLE_IIN 0x4000

Note that the user can define tags to determine the status of the IIN flags returned from the device. Note also that CDNP_WARN_IIN_ERROR will not generate any #COMs on the screen.

[DNPR]DataLinkConfirmDefault

[<unit>]DataLinkConfirm

0 - Off

1 - Sometimes (Multiframe only)

2 - On

0

Default Data Link Confirm mode.

[DNPR]
DataLinkNoRetriesOnControlsDefault

[<unit>]
DataLinkNoRetriesOnControls

1 - There are no data link layer retries when sending control messages such as direct operate, or select/operate.

0 - Normal retries apply.

0

Data Link retries on controls.Note: The data link layer will only retry if data link layer confirmations are used, see DataLinkConfirmDefault.

[DNPR]DataLinkRetriesDefault

[<unit>]DataLinkRetries

0 to 255

3

Default number of attempts to retransmit after a data link timeout.

This parameter is only relevant if Data Link confirmation is enabled (see parameter [DNPR] DataLinkConfirmDefault).

Note: This parameter is ignored if the application function code is from 2 to 6 (Control requests) and data link retries are disabled for these function codes (see parameter [DNPR]DataLink
NoRetriesOnControlsDefault).

[DNPR]DataLinkTimeOutDefault

[<unit>]DataLinkTimeOut

0 to 65,535 (ms)

2000 ms

Default waiting period since last frame for a data link confirm –only if confirm requested.

[DNPR]DataLinkFrameSize

28 to 292

292

For DNP devices that have small data link layer frames, then for the same size application layer buffer, more data link layer frames will be produced.

The library that the DNPR driver utilizes was previously assuming that the DNP device would have a maximum data link layer frame size of 292 bytes, and an application layer fragment maximum size of 2048 bytes. This combination would result in a maximum of 9 frames per fragment.

The library has been modified such that it will allow up to 64 frames per fragment, however the main practical restriction introduced is that the resulting application layer data from the combined frames will not overflow the application layer buffer.

Now DNP devices with maximum data link layer frame size of less than 292 bytes are also supported.

Similarly, the INI parameter
[DNPR]DataLinkFrameSize allows the specification of the Max data link layer transmit frame size.

The default value is 292 bytes. The parameter value is upper limited to 292 bytes, and lower limited to 28 bytes.

[DNPR]TransDelay

0 to 65,535 (ms)

0 ms

Transmission Delay for use in RS485 networks.

[<unit>]AppLayerTimeOut

0 to 2,000,000,000
(ms)

[<unit>]Timeout + [<unit>]
TimeoutExtension (ms)

Waiting period for application layer response.

It is recommended that this should be set to approximately 10 times the DataLinkTimeOut to allow for confirms and link layer resets that may happen as part of a successful application layer transaction.

There is no need to allow for the number of frames or fragments that are sent as part of an integrity poll, as the timeout gets reset when each frame of each response fragment is received.

The timer is also reset when a data link layer transaction times out.