We have adapted your 0.8.2 port of a PIC18f6720 to a PIC87J60 running @ 25 MHz. The port is functioning, but the response to reads or writes are sometimes sluggish (reply between immediate to 5 secs) or sometimes it does not respond at all..
The test setup uses VTS via a Contemporary Controls BACnet I/P to MS/TP router to send Object Access Read Property or Write Property to various Analog Values, or Analog Inputs.
Do you have any comments on areas where the response could be improved or reasons that could be slowing down the reply?
Adding calls to dlmstp_task() in the main loop does not seem to change the response. It does seem that there are a lot of MSTP_Packets, when a breakpoint is set in dlmstp_task just before the call to npdu_handler().
Thanks for any comments, hints, or recomendations. (A hotter processor, no doubt would be better, but that won't occur right away)
Jerry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The dlmstp_task() is expected to be called about every 1 to 5 milliseconds, not to exceed 5 milliseconds between calls. If your main loop includes delays that makes the time between dlmstp_task() calls exceed 5 milliseconds, then the dlmstp_task() will not function correctly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another possible problem: The WDTPS in the example code is configured for 128, which may not be appropriate for your application or processor. If the WDTPS is too short, the device will reset, causing Token passing restart.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Putting the dlmstp_task() in a 4 ms interrupt actually make the intermittent replies totally stop.
The WDTPS is set for 2 seconds, so this is not an issue.
There could be pilot error in that a lot of code has been commented out due to the limited rsources, but the portion of the stack does respond, just not reliably in a timely fashion. It is curious that the calling of the dlmstp_task() caused the response to stop?????
Is there any suggestions you can think of?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So if a Master/Slave implementation is desired, so it can send out I-am, periodically for discovery, would the receive ring buffer messages have to be parsed so that they could be directed to either the master or slave function based on the message content?
Is there one of the port examples that support both master and slave?
The current PIC port does respond to read and write requests, just not always in a timely fashion. Is the master state machine in a state that prevents answering the requests until it is done with whatever it needs to do? .
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the library, Master and Slave are based solely on the MAC Address (split at 127), although Slaves can be part of the Master MAC range.
if ((This_Station > 127) && (This_Station < 255)) {
MSTP_Slave_Node_FSM();
} else if (This_Station <= 127) {
while (MSTP_Master_Node_FSM()) {
/* do nothing while some states fast transition */
};
}
There are several examples of Master and Slave node state machines in the library - search for a function named MSTP_Slave_Node_FSM() in all the files.
Certain MS/TP frames carrying the ReadProperty request (Data-Expecting-Reply) are given more time to respond (up to 255ms, not to exceed 300ms). But the state machine, as written, is non-blocking and simply keeps checking the timer or queue to know whether to respond with data or with a reply-postponed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So if I want to have master functionality with a single MAC, then it looks like I should stay with the PIC port and try to determine where the stall is occuring, correct?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Steve,
The test circuit I use has our test device and an off-the shelf BACnet I/P to MSTP router, and VTS to send object interaction. After inspecting the traffic, both devices are continually Polling For Master. They are interacting as expected by passing the tokens back and forth. The Npoll parameter is 50, so it seems there should be some quiet time so that a response could get through. Reducing the Max Master parameter does increase the response, but we need it to be the default 127, and have no control of the assigned MAC address, as it is intended to be in enterprise networks.
The attached serial log shows the traffic along with time stamps, which has been edited to make it more readable and to add comments.
Debugging our device shows that the SoleMaster parameter was being triggered when it should not have been, which I think, leads to the continual PFM. The setting of the SoleMaster may be a timing issue or something, but I see that the commercial device also does this, and not just intermittently.
From the capture, it looks like the second Token gets sent because the time to hear traffic has expired. So either the MS/TP state machine is not getting called often enough, or the timer is going too fast. My guess is on the former.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We have adapted your 0.8.2 port of a PIC18f6720 to a PIC87J60 running @ 25 MHz. The port is functioning, but the response to reads or writes are sometimes sluggish (reply between immediate to 5 secs) or sometimes it does not respond at all..
The test setup uses VTS via a Contemporary Controls BACnet I/P to MS/TP router to send Object Access Read Property or Write Property to various Analog Values, or Analog Inputs.
Do you have any comments on areas where the response could be improved or reasons that could be slowing down the reply?
Adding calls to dlmstp_task() in the main loop does not seem to change the response. It does seem that there are a lot of MSTP_Packets, when a breakpoint is set in dlmstp_task just before the call to npdu_handler().
Thanks for any comments, hints, or recomendations. (A hotter processor, no doubt would be better, but that won't occur right away)
Jerry
The dlmstp_task() is expected to be called about every 1 to 5 milliseconds, not to exceed 5 milliseconds between calls. If your main loop includes delays that makes the time between dlmstp_task() calls exceed 5 milliseconds, then the dlmstp_task() will not function correctly.
Another possible problem: The WDTPS in the example code is configured for 128, which may not be appropriate for your application or processor. If the WDTPS is too short, the device will reset, causing Token passing restart.
Ok, thanks for the comments. I can see that the task is being starved.
Your tireless work is appreciated by me as well as countless others!
Jerry
Putting the dlmstp_task() in a 4 ms interrupt actually make the intermittent replies totally stop.
The WDTPS is set for 2 seconds, so this is not an issue.
There could be pilot error in that a lot of code has been commented out due to the limited rsources, but the portion of the stack does respond, just not reliably in a timely fashion. It is curious that the calling of the dlmstp_task() caused the response to stop?????
Is there any suggestions you can think of?
You would probably need to decouple the MS/TP from the BACnet application processing if you are running from a 4ms interrupt. See this thread for info:
https://sourceforge.net/p/bacnet/discussion/402140/thread/03c38b12/#6926
So if a Master/Slave implementation is desired, so it can send out I-am, periodically for discovery, would the receive ring buffer messages have to be parsed so that they could be directed to either the master or slave function based on the message content?
Is there one of the port examples that support both master and slave?
The current PIC port does respond to read and write requests, just not always in a timely fashion. Is the master state machine in a state that prevents answering the requests until it is done with whatever it needs to do? .
In the library, Master and Slave are based solely on the MAC Address (split at 127), although Slaves can be part of the Master MAC range.
if ((This_Station > 127) && (This_Station < 255)) { MSTP_Slave_Node_FSM(); } else if (This_Station <= 127) { while (MSTP_Master_Node_FSM()) { /* do nothing while some states fast transition */ }; }There are several examples of Master and Slave node state machines in the library - search for a function named MSTP_Slave_Node_FSM() in all the files.
Certain MS/TP frames carrying the ReadProperty request (Data-Expecting-Reply) are given more time to respond (up to 255ms, not to exceed 300ms). But the state machine, as written, is non-blocking and simply keeps checking the timer or queue to know whether to respond with data or with a reply-postponed.
So if I want to have master functionality with a single MAC, then it looks like I should stay with the PIC port and try to determine where the stall is occuring, correct?
Yes, finding the stall would be important if you want to remain a Master Node device.
Hi Steve,
The test circuit I use has our test device and an off-the shelf BACnet I/P to MSTP router, and VTS to send object interaction. After inspecting the traffic, both devices are continually Polling For Master. They are interacting as expected by passing the tokens back and forth. The Npoll parameter is 50, so it seems there should be some quiet time so that a response could get through. Reducing the Max Master parameter does increase the response, but we need it to be the default 127, and have no control of the assigned MAC address, as it is intended to be in enterprise networks.
The attached serial log shows the traffic along with time stamps, which has been edited to make it more readable and to add comments.
Debugging our device shows that the SoleMaster parameter was being triggered when it should not have been, which I think, leads to the continual PFM. The setting of the SoleMaster may be a timing issue or something, but I see that the commercial device also does this, and not just intermittently.
From the capture, it looks like the second Token gets sent because the time to hear traffic has expired. So either the MS/TP state machine is not getting called often enough, or the timer is going too fast. My guess is on the former.
OK, thanks for looking at it. I will have to get our the scope to see the timing better. This is a pretty tight spec!