There are 2 types of BACnet service: unconfirmed and confirmed. The sender(client) of confirmed service request will wait for reply until timeout expires.
Usually there are no side effect of excess message delay for unconfirmed service. For confirmed service request or reply, excess message delay will result in poor network performance, because the service reply will be dropped by client due to timeout.
Furthermore, too late reply for confirmed service will cause application logic wrong. Each confirmed service request has a invokeID, the reply message carries same invokeID. The value range of invokeID is 0~255. On a busy client, the invokeID will be exhausted and re-used soon. if the invokeID of a delayed confirmed service reply is re-used by another service, the reply will be regarded as replying to later one. For exmaple:
- Client send WriteProperty service A to device X object Y property Z. The invokeID is 0. The request or reply messages is delayed.
- Client waits until timeout expires. Service A fails so invokeID 0 is reclaimed.
- Client send WriteProperty service B to device X object U property V. The invokeID 0 is chosed.
- Reply for service A is arrived, because its invokeID is same as service B, client believes that service B success.
For high speed data link type as Ethernet or IP, the message delay is neglect-able, but for MSTP, there are several possible reasons for excess message delay:
- Signal noise.
- Incorrect/improper device configuration(baudrate, max-master, max_info_frames)
- Excess traffic.
- Slow device
To avoid invokeID conflict and improve network performance, BACRouter with firmware version >=2.0 implements message delay guarantee of 10 seconds (It is changed to 6 seconds from v4.17 respecting BACnet default APDU_Timeout). Messages which could not be sent within the delay will be dropped by BACRouter.