Our device interacts on our test network without any noticeable issues. The token passing and PFM sequences appear to be correct.
VTS is used to communicate to our MSTP network using a Contemporary Controls IP to MS/TP adapter.
It can be discovered by other diagnostic tools, including Yet Another Bacnet Explorer, YABE.
However, when trying to join an existing network with approximately 35 nodes, it corrupts the network. It also cannot be discovered when solely connected to the Johnson controller.
When it is tested directly connected to a PC using a USB-RS485 adapter, it is not discovered by YABE, which appears to issue a WhoIs() which uses the default entire addressing range .
When our unit is on debug, and not connected to anything, it is initialized, then after a few seconds it continuously sends out PFMs thinking it is the SoleMaster. This action without any other nodes appears to be as expected
The dlmstp_init(), initializes the SoleMaster to false, as expected.
1) Have you heard of any other instances of devices not gracefully joining an existing network, and would you have any recommendations on a sequence of items to investigate or verify?
2) I see that the SilenceTimer is described as being a nominal 5 msec timer, but most of the timing parameters are defined in msec, and compares with SilenceTimer use the parameter directly. Do the timing parameters need to be adjusted to the actual time base of the SilenceTimer( div by 5)?
We have implemented a 1 msec timer, but could easily change it to 5.
3) It would seem that the issue may be some sort of timing issue, such as not waiting long enough when joining a network, or not waiting enough time after sending a PFM, as the network corruption issue might be caused by our unit transmitting PFMs when it shouldn't.
4) The Contempory Controls has a "lenient timing" option. In your experience with other actual devices that are deployed, are there certain parameters that must be strictly adhered to and are there others where a timing parameter may be relaxed to provide for higher probability of interoperability?
6) There are a number of timing parameters defined, but not referenced. Should all the paramters be explictly checked?
7) Our device does not respond to a WhoIs() request.
a) The following calls are made on startup
apdu_set_unconfirmed_handler(SERVICE_UNCONFIRMED_I_AM,handler_i_am_add);
apdu_set_unconfirmed_handler(SERVICE_UNCONFIRMED_WHO_IS,handler_who_is);
apdu_set_unconfirmed_handler(SERVICE_UNCONFIRMED_WHO_IS,handler_who_is_unicast);
b) Does the dcc_communication_disabled parameter need to be in a particular state for the stack to respond to the WhoIs() unconfirmed request?
8) Other details of the installation:
a) Ground loop on the reference line is not an issue
b) BMS controller is only about 25' away so termination issues on the RS485 is not an issue.
Thank you for any comments or suggestions to verify.
Jerry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Timing in your application is usually the culprit. The SilenceTimer resolution of 1ms is best. The dlmstp_receive() function should be called at least every 5ms or faster (1ms is better). If dlmstp_receive() (aka datalink_receive()) is called beyond 5ms, then the timing in the FSM (finite state machine) doesn't work correctly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
timing, Max_Master that is not high enough, slightly wrong baud rate. Use MS/TP capture utility to get an idea of the problem. mstpcap is compiled as a demo tool in the BACnet Protocol Stack library, and can be copied to the extcap folder of Wireshark 2.x to integrate with the Wireshark GUI.
Timing is adequate using 1m resolution, and should work fine with up to 5ms resolution. The constants and timing parameters should not need to be adjusted.
Most of the time the problem is because some vendors use the "strict" timing, which means that a device must start replying in 15ms and is considered late at 25ms. The joining happens with the Poll-For-Master and its reply, and that is allowed to be up to 100ms (on the waiting for response side) but could be as small as 25ms. The BACnet committee has discussed fixing this value (I don't recall the number we settled on).
Some vendors choose to make the timing on the "strict" side, whereas others use "lenient". It really depends on which products your devices have to work with. Most "lame" devices require a "lenient" timing as they are typically based on older microcontrollers or perhaps running a non-realtime OS.
n/a
No, not all the timing parameters are relevant to the C code on a particular platform, so all are not required to be referenced.
If your device doesn't join the Token passing, it cannot respond to a WhoIs request with an I-Am response. a) only one handler can be registered for calbacks, so remove the extra SERVICE_UNCONFIRMED_WHO_IS. b) yes, DCC communication must be enabled for a response to be formed (COMMUNICATION_ENABLE).
Although RS485 issues could be a problem (i.e. without a reference), it's hard to tell without a scope capture.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Our device interacts on our test network without any noticeable issues. The token passing and PFM sequences appear to be correct.
VTS is used to communicate to our MSTP network using a Contemporary Controls IP to MS/TP adapter.
It can be discovered by other diagnostic tools, including Yet Another Bacnet Explorer, YABE.
However, when trying to join an existing network with approximately 35 nodes, it corrupts the network. It also cannot be discovered when solely connected to the Johnson controller.
When it is tested directly connected to a PC using a USB-RS485 adapter, it is not discovered by YABE, which appears to issue a WhoIs() which uses the default entire addressing range .
When our unit is on debug, and not connected to anything, it is initialized, then after a few seconds it continuously sends out PFMs thinking it is the SoleMaster. This action without any other nodes appears to be as expected
The dlmstp_init(), initializes the SoleMaster to false, as expected.
1) Have you heard of any other instances of devices not gracefully joining an existing network, and would you have any recommendations on a sequence of items to investigate or verify?
2) I see that the SilenceTimer is described as being a nominal 5 msec timer, but most of the timing parameters are defined in msec, and compares with SilenceTimer use the parameter directly. Do the timing parameters need to be adjusted to the actual time base of the SilenceTimer( div by 5)?
We have implemented a 1 msec timer, but could easily change it to 5.
3) It would seem that the issue may be some sort of timing issue, such as not waiting long enough when joining a network, or not waiting enough time after sending a PFM, as the network corruption issue might be caused by our unit transmitting PFMs when it shouldn't.
4) The Contempory Controls has a "lenient timing" option. In your experience with other actual devices that are deployed, are there certain parameters that must be strictly adhered to and are there others where a timing parameter may be relaxed to provide for higher probability of interoperability?
6) There are a number of timing parameters defined, but not referenced. Should all the paramters be explictly checked?
7) Our device does not respond to a WhoIs() request.
a) The following calls are made on startup
apdu_set_unconfirmed_handler(SERVICE_UNCONFIRMED_I_AM,handler_i_am_add);
apdu_set_unconfirmed_handler(SERVICE_UNCONFIRMED_WHO_IS,handler_who_is);
apdu_set_unconfirmed_handler(SERVICE_UNCONFIRMED_WHO_IS,handler_who_is_unicast);
b) Does the dcc_communication_disabled parameter need to be in a particular state for the stack to respond to the WhoIs() unconfirmed request?
8) Other details of the installation:
a) Ground loop on the reference line is not an issue
b) BMS controller is only about 25' away so termination issues on the RS485 is not an issue.
Jerry
Timing in your application is usually the culprit. The SilenceTimer resolution of 1ms is best. The dlmstp_receive() function should be called at least every 5ms or faster (1ms is better). If dlmstp_receive() (aka datalink_receive()) is called beyond 5ms, then the timing in the FSM (finite state machine) doesn't work correctly.
OK, thanks, we'll take another look at the call frequency. Any comments on the other questions above?
Thanks a lot for the extended and fast reply, Steve!
Jerry