I had checked out the current stack on the PIC18 port and it compiled on C18 without any errors. I am unable to discover this device over an RS485 network using a Niagara Jensys controller or using CAS BACNet explorer on windows (via a USB to RS485 converter). Other than the serial settings like baud-rate what else have to configured for a device discovery to work.
The code is continuously transmitting data, so not sure how it can be discovered by other devices when its always holding the line. Even a slave device would have worked for me, but after reading the mailing list archive I realize the current MSTP port only works in server mode. That should be fine as long as I am able to discover the device and read a couple of points from it using other BACnet controllers.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
BACnet MS/TP depends on several settings.
1) Baud Rate: all nodes must be set at the same baud rate (9600, 19200, 38400, 57600, 76800, or 115200).
2) MS/TP MAC Address: all nodes must have unique MAC addresses, and master nodes must be in the range of 0-127.
3) Max_Master: must be large enough that all MS/TP MAC addresses are within it. If unsure, set to 127.
4) Correct RS-485 Bias, A+/B- polarity, ground reference, termination, and cabling (impedance and capacitance).
An MS/TP master node will continuously transmit (after it listens for a minimum amount of silence on the wire) a Poll-For-Master frame to each MAC Address (up to its Max_Master) as it tries to find a neighbor to whom it can pass a Token frame.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Steve, thanks for the response. I had come across your blog which explains using wireshark for Bacnet network analysis (its been a great help), and like you mentioned it is indeed doing a poll for master. I had set the address above 127 hoping that would make it act like a slave node, but soon found out that MSTP_Slave_Node_FSM implemented in the Linux port is not present in the C18 port. Did you face any issues porting this functionality to C18. I have a JohnsonControls thermostat with me which I am able to discover on our BACNet MSTP network (we use a Jensys controller). The thermostat does not do a poll for master , it only responds when it receives a poll for master with destination address matching its MAC. This was the behavior I was trying to emulate with the C18 port. I read on the forum that MSTP slave node has several issues regarding discovery. Is it possible to use the C18 port as a Master Node itself but disable sending Poll for Master or is it better to port the MSTP_SLAVE_Node_FSM from linux. Please let me know your thoughts.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On the Johnson thermostat, does it always answer the poll for master?
1) If it does, is it replying with the normal Reply to PFM?
2) If so, it should be passed the token, and if so, what does it do when it receives the token? The other masters that I see on a test network are trying twice to send the token, then proceed to poll the next station.if the receiving station does not either use the token or pass the token.
3) The other scenario is that it only answers during a "configuration" period, where it behaves as a master to allow the discovery, then reverts to being a slave after that, the question then, does the Jensys controller maintain the binding of the MAC address to this unit by the repetitive polling for the actual points, of say analog value or does the thermostat periodically enter the master mode to refresh its MAC by replying?
4) If the thermostat has its Max master set to 0, it would still have to receive and pass the token, which requires a lot of bandwidth on a network with just a few tokens.
5) Once the thermostat replies to the PFM, does the controller direct other 'data expecting reply' frames for all the other device information? and if so what?
6) The manual configuration of the supervisory controller provided for adding the various data objects, such as AV and AI, so the actual device may not be required to respond to sending a device list. The question is what are the minimum amount of data that allows the discovery to occur?
Steve,
If you have any comments, please add them.
Thanks for any information.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have not ported the MS/TP Slave Node code to all the possible ports in the BACnet Stack at the moment. My goal was to encourage MS/TP Master nodes, as they are more useful.
Any BACnet Device that responds to Poll-For-Master is a Master node, and it should emit Poll-For-Master messages itself when alone or when the token drops or when a maintenance Poll-For-Master is necessary. However, if the Max_Master property is configured to be zero, the device would not Poll-For-Master.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is the exact scenario that I am trying to solve. It appears that the controller that is trying to discover our device uses the dynamic device binding, using the Instance ID to discover the MAC. The controller configuration application does not have any means to just manually load in a static MAC address. With only 127 MAC addresses on a given MSTP branch and the masters doing PFMs continually, it seems like a special PFM reply from a slave would be quite an efficient method in the discovery process. This reply would be interpreted by the polling master as a slave, and not pass the token to it.
I read your article "Improving BACnet MS/TP" where you talked about this issue and referred to a slave proxy device. Is the only way then to discover a slave?
How do, say the thermostats that are advertised as slaves, get discovered? On the network, it appeared to answer a Who-is.
Are these devices acting as a master for a startup period of time to get discovered then revert to being a slave after say a minute or so? That could be a scenario to save bandwidth for small micros.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is a standard method specified to find the slaves (either manual binding or automatic discovery), and an MS/TP router that includes the slave proxy feature will emit an I-Am on behalf of the slave as an answer to Who-Is.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This particular network, as with many others has really only 1 supervisory controller with a lot of other masters that really used as slave devices. This controller uses the dynamic binding and has no method to just write a MAC address. So is the only way to get onto this network is to add a device that can be a slave proxy? Seems a real waste.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As I've stated before, my goal was to encourage development of MS/TP Master nodes, as they are more useful. MS/TP Slave nodes are much simpler and easier to implement (i.e. can fit into existing code space) for those with existing Modbus implementations, but they lack the ability to be discovered via broadcasts.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Steve,
The supervisory controller setup for manual discovery sends out a unicast Who-Is, so if a slave supports the I-am, this could be the method that the discovery gets the MAC address.
I can't thank you enough for your replies.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The Unicast Who-Is would already include the slave MAC address, so the Slave would already have to be discovered. The slave proxy discovery uses a unicast ReadProperty (which all devices must support) to the Device object (which all devices must support).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had checked out the current stack on the PIC18 port and it compiled on C18 without any errors. I am unable to discover this device over an RS485 network using a Niagara Jensys controller or using CAS BACNet explorer on windows (via a USB to RS485 converter). Other than the serial settings like baud-rate what else have to configured for a device discovery to work.
The code is continuously transmitting data, so not sure how it can be discovered by other devices when its always holding the line. Even a slave device would have worked for me, but after reading the mailing list archive I realize the current MSTP port only works in server mode. That should be fine as long as I am able to discover the device and read a couple of points from it using other BACnet controllers.
BACnet MS/TP depends on several settings.
1) Baud Rate: all nodes must be set at the same baud rate (9600, 19200, 38400, 57600, 76800, or 115200).
2) MS/TP MAC Address: all nodes must have unique MAC addresses, and master nodes must be in the range of 0-127.
3) Max_Master: must be large enough that all MS/TP MAC addresses are within it. If unsure, set to 127.
4) Correct RS-485 Bias, A+/B- polarity, ground reference, termination, and cabling (impedance and capacitance).
An MS/TP master node will continuously transmit (after it listens for a minimum amount of silence on the wire) a Poll-For-Master frame to each MAC Address (up to its Max_Master) as it tries to find a neighbor to whom it can pass a Token frame.
Steve, thanks for the response. I had come across your blog which explains using wireshark for Bacnet network analysis (its been a great help), and like you mentioned it is indeed doing a poll for master. I had set the address above 127 hoping that would make it act like a slave node, but soon found out that MSTP_Slave_Node_FSM implemented in the Linux port is not present in the C18 port. Did you face any issues porting this functionality to C18. I have a JohnsonControls thermostat with me which I am able to discover on our BACNet MSTP network (we use a Jensys controller). The thermostat does not do a poll for master , it only responds when it receives a poll for master with destination address matching its MAC. This was the behavior I was trying to emulate with the C18 port. I read on the forum that MSTP slave node has several issues regarding discovery. Is it possible to use the C18 port as a Master Node itself but disable sending Poll for Master or is it better to port the MSTP_SLAVE_Node_FSM from linux. Please let me know your thoughts.
Vj2411,
On the Johnson thermostat, does it always answer the poll for master?
1) If it does, is it replying with the normal Reply to PFM?
2) If so, it should be passed the token, and if so, what does it do when it receives the token? The other masters that I see on a test network are trying twice to send the token, then proceed to poll the next station.if the receiving station does not either use the token or pass the token.
3) The other scenario is that it only answers during a "configuration" period, where it behaves as a master to allow the discovery, then reverts to being a slave after that, the question then, does the Jensys controller maintain the binding of the MAC address to this unit by the repetitive polling for the actual points, of say analog value or does the thermostat periodically enter the master mode to refresh its MAC by replying?
4) If the thermostat has its Max master set to 0, it would still have to receive and pass the token, which requires a lot of bandwidth on a network with just a few tokens.
5) Once the thermostat replies to the PFM, does the controller direct other 'data expecting reply' frames for all the other device information? and if so what?
6) The manual configuration of the supervisory controller provided for adding the various data objects, such as AV and AI, so the actual device may not be required to respond to sending a device list. The question is what are the minimum amount of data that allows the discovery to occur?
Steve,
If you have any comments, please add them.
Thanks for any information.
I have not ported the MS/TP Slave Node code to all the possible ports in the BACnet Stack at the moment. My goal was to encourage MS/TP Master nodes, as they are more useful.
Any BACnet Device that responds to Poll-For-Master is a Master node, and it should emit Poll-For-Master messages itself when alone or when the token drops or when a maintenance Poll-For-Master is necessary. However, if the Max_Master property is configured to be zero, the device would not Poll-For-Master.
Hi Steve,
This is the exact scenario that I am trying to solve. It appears that the controller that is trying to discover our device uses the dynamic device binding, using the Instance ID to discover the MAC. The controller configuration application does not have any means to just manually load in a static MAC address. With only 127 MAC addresses on a given MSTP branch and the masters doing PFMs continually, it seems like a special PFM reply from a slave would be quite an efficient method in the discovery process. This reply would be interpreted by the polling master as a slave, and not pass the token to it.
I read your article "Improving BACnet MS/TP" where you talked about this issue and referred to a slave proxy device. Is the only way then to discover a slave?
How do, say the thermostats that are advertised as slaves, get discovered? On the network, it appeared to answer a Who-is.
Are these devices acting as a master for a startup period of time to get discovered then revert to being a slave after say a minute or so? That could be a scenario to save bandwidth for small micros.
MS/TP slave proxy was added into the BACnet standard around 2004:
http://www.bacnet.org/Addenda/Add-2001-135a.pdf
There is a standard method specified to find the slaves (either manual binding or automatic discovery), and an MS/TP router that includes the slave proxy feature will emit an I-Am on behalf of the slave as an answer to Who-Is.
This particular network, as with many others has really only 1 supervisory controller with a lot of other masters that really used as slave devices. This controller uses the dynamic binding and has no method to just write a MAC address. So is the only way to get onto this network is to add a device that can be a slave proxy? Seems a real waste.
As I've stated before, my goal was to encourage development of MS/TP Master nodes, as they are more useful. MS/TP Slave nodes are much simpler and easier to implement (i.e. can fit into existing code space) for those with existing Modbus implementations, but they lack the ability to be discovered via broadcasts.
Steve,
The supervisory controller setup for manual discovery sends out a unicast Who-Is, so if a slave supports the I-am, this could be the method that the discovery gets the MAC address.
I can't thank you enough for your replies.
The Unicast Who-Is would already include the slave MAC address, so the Slave would already have to be discovered. The slave proxy discovery uses a unicast ReadProperty (which all devices must support) to the Device object (which all devices must support).