I have a spec question. One of the uses for T_usage_timeout is to specify the maximum amount of time to wait for a remote node to begin sending after passing it the token. However, the spec is not clear in my opinion. It specifies this value as 20 milliseconds, but then goes on to state "Implementations may use larger values for this timeout, not to exceed 100 milliseconds." Well, which is it?
The reason I am asking is that we have a router that is taking up to 53 milliseconds to respond after receiving the token in certain cases. Our dlmstp implementation has a T_usage_timout of 50 ms, so we're getting collisions on the bus in those cases since we timeout and attempt to talk at the same time the router is transmitting.
With the spec being fuzzy, it is not clear where the problem is. Are we the problem since we're not allowing the full 100 ms for a response?
Note that the router is definitely out-of-spec since it violates the T_usage_delay specification of 15 ms.
--Randy
Last edit: Randy Yates 2017-04-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The BACnet spec is fuzzy for Tusage_timeout, and yes, it results in MS/TP devices failing to communicate, required a site adjustable Tusage_timeout value. The BACnet MS/TP working group had a proposal (DMF-008) in 2004 to change the standard, but this proposal has only recently gained consensus in committee. It is recently completed a public review (I don't know the current status): http://www.bacnet.org/Addenda/Add-135-2016bm-ppr1-draft-3_chair_approved.pdf
Note: this will only affect BACnet MS/TP devices developed after this change becomes official and for vendors implementing this version of the standard in their product. For the near future, an adjustable Tusage_timeout is advised.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a spec question. One of the uses for T_usage_timeout is to specify the maximum amount of time to wait for a remote node to begin sending after passing it the token. However, the spec is not clear in my opinion. It specifies this value as 20 milliseconds, but then goes on to state "Implementations may use larger values for this timeout, not to exceed 100 milliseconds." Well, which is it?
The reason I am asking is that we have a router that is taking up to 53 milliseconds to respond after receiving the token in certain cases. Our dlmstp implementation has a T_usage_timout of 50 ms, so we're getting collisions on the bus in those cases since we timeout and attempt to talk at the same time the router is transmitting.
With the spec being fuzzy, it is not clear where the problem is. Are we the problem since we're not allowing the full 100 ms for a response?
Note that the router is definitely out-of-spec since it violates the T_usage_delay specification of 15 ms.
--Randy
Last edit: Randy Yates 2017-04-13
PS: My statements are based on version 135-2016 of the spec.
The BACnet spec is fuzzy for Tusage_timeout, and yes, it results in MS/TP devices failing to communicate, required a site adjustable Tusage_timeout value. The BACnet MS/TP working group had a proposal (DMF-008) in 2004 to change the standard, but this proposal has only recently gained consensus in committee. It is recently completed a public review (I don't know the current status):
http://www.bacnet.org/Addenda/Add-135-2016bm-ppr1-draft-3_chair_approved.pdf
Note: this will only affect BACnet MS/TP devices developed after this change becomes official and for vendors implementing this version of the standard in their product. For the near future, an adjustable Tusage_timeout is advised.