Hi everyone, when I set the address via the DIP switch everything goes well from address 0 to 12 then when I try from 13 and up the device still send an Iam and I see the device appearing into the address list of YABE then when i clich on him it hang and say couldn't fetch objects.
I am trying to figure out where it could act like it but I did not found anything suspicious in the code.
Thanks in advance and have an happy new year !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there a BACnet/IP to MS/TP router between YABE and BDK? Is there a capture of the MS/TP packets that can indicate why there isn't any discovery at MAC=13 or higher?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Steve, No I have no router its in direct connection via the usb to serial chip integrated into the arduino board, as you can see in YABE both address is detected as a device but when the address is more than 13 then YABE is hanging and then showing an error saying Couldn't fetch objects.
If you need more data just ask and i'll do my best to give it to you !
Thanks you for the help and have a nice day.
Hi Steve, I have fixed the issue finally the problem wasn't into the stack it was in the YABE settings the max master was set to 12 so everytime i was trying to send request to the # 13 and up the yabe was never sending the request for object list then it was saying that error -_-
Thanks you for the help !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello guys,
I am facing a very similar situation to this one, except that in my case YABE settings are very standard, with max master set to 127. My device is found correctly (359005 - 5), but then the same error message appears (screenshots attached). I have also a direct connection between the device and the USB-rs485 converter to the PC running the YABE. And while YABE is running, I constantly see exchange of token telegrams between both devices along with poll-for-master. In terms of software architecture, have a timer firing every 1ms and a bacnet_task() also being called every 1ms.
I'm using the 'stm32f4xx' port as an example, and my Object_Table[] is as simple as it can gets. I am aiming to get basic information from Object Device (i.e., "working") before moving forward with the additional objects.
Appreciate ideas to search for in order to fix this issue?
v1.3.5 enabled MS/TP extended frames, by default, for APDU up to 1476 bytes #592. It's likely that the router or client you are testing with is not MS/TP extended frames compatible. A Wireshark capture of the MS/TP might be informative.
Please change MAX_APDU=480 (in config.h file or in Makefile or project file or ...) to see if that makes a difference. The extended frames only happens when the packet exceeds 480 bytes (and object-list is often larger than 480 bytes with a lot of objects).
I'll plan to revert the MAX_APDU in the examples to use default of MAX_APDU=480 so that behavior of MS/TP is to not use the new MS/TP extended frames for large packets.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Followed your advice and changed MAX_APDU to 480. Compiled and loaded the new firmware. Powered up my device (address 5) and after a couple of seconds, launched Yabe (address 1). Attached screenshot and Wireshark log.
There is a "Malformed Packet" sent by my device every time a ReadProperty is requested (starting at line 1180). There is also that "Reply Postponed" which doesn't seem quite right.
Managed to find the (part of) issue with the Reply to ReadProperty. I am using stack version 1.3.5. Inside "bacnet/basic/service/h_rp.c" file, function "handler_read_property()", the call to function "npdu_encode_pdu()" was not returning to "npdu_len" variable, staying with the default value of -1, and always leading to an error response. A diff of this file to the very latest code base, 1.3.7, proved that, and that was the only change.
So now my device replies BUT not to the correct address; it should, of course, reply to 0x01 (figure attached). I am wondering if it's worth update whole stack to 1.3.7 in order to fix this and other bugs that were iron out.
Yes, I would recommend that you update to the latest version of the BACnet Stack library.
Between the new features in the BACnet standard and bug fixes and refactoring and mods for new use cases, there is always something new or fixed in the latest release.
We do our best to not break API, but that is sometimes hard when the original architect (me!) wasn't as forward thinking about where this little project would be used and how software engineeting has changed over the past 20 years.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi everyone, when I set the address via the DIP switch everything goes well from address 0 to 12 then when I try from 13 and up the device still send an Iam and I see the device appearing into the address list of YABE then when i clich on him it hang and say couldn't fetch objects.
I am trying to figure out where it could act like it but I did not found anything suspicious in the code.
Thanks in advance and have an happy new year !
Is there a BACnet/IP to MS/TP router between YABE and BDK? Is there a capture of the MS/TP packets that can indicate why there isn't any discovery at MAC=13 or higher?
Hi Steve, No I have no router its in direct connection via the usb to serial chip integrated into the arduino board, as you can see in YABE both address is detected as a device but when the address is more than 13 then YABE is hanging and then showing an error saying Couldn't fetch objects.
If you need more data just ask and i'll do my best to give it to you !
Thanks you for the help and have a nice day.
Hi Steve, I have fixed the issue finally the problem wasn't into the stack it was in the YABE settings the max master was set to 12 so everytime i was trying to send request to the # 13 and up the yabe was never sending the request for object list then it was saying that error -_-
Thanks you for the help !
Hello guys,
I am facing a very similar situation to this one, except that in my case YABE settings are very standard, with max master set to 127. My device is found correctly (359005 - 5), but then the same error message appears (screenshots attached). I have also a direct connection between the device and the USB-rs485 converter to the PC running the YABE. And while YABE is running, I constantly see exchange of token telegrams between both devices along with poll-for-master. In terms of software architecture, have a timer firing every 1ms and a bacnet_task() also being called every 1ms.
I'm using the 'stm32f4xx' port as an example, and my Object_Table[] is as simple as it can gets. I am aiming to get basic information from Object Device (i.e., "working") before moving forward with the additional objects.
Appreciate ideas to search for in order to fix this issue?
Best Regards,
Luciano.
Last edit: Luciano Rottava da Silva 2024-06-28
Reference: https://github.com/bacnet-stack/bacnet-stack/issues/671
v1.3.5 enabled MS/TP extended frames, by default, for APDU up to 1476 bytes #592. It's likely that the router or client you are testing with is not MS/TP extended frames compatible. A Wireshark capture of the MS/TP might be informative.
Please change MAX_APDU=480 (in config.h file or in Makefile or project file or ...) to see if that makes a difference. The extended frames only happens when the packet exceeds 480 bytes (and object-list is often larger than 480 bytes with a lot of objects).
I'll plan to revert the MAX_APDU in the examples to use default of MAX_APDU=480 so that behavior of MS/TP is to not use the new MS/TP extended frames for large packets.
Hi Steve,
Followed your advice and changed MAX_APDU to 480. Compiled and loaded the new firmware. Powered up my device (address 5) and after a couple of seconds, launched Yabe (address 1). Attached screenshot and Wireshark log.
There is a "Malformed Packet" sent by my device every time a ReadProperty is requested (starting at line 1180). There is also that "Reply Postponed" which doesn't seem quite right.
Hi Steve,
Managed to find the (part of) issue with the Reply to ReadProperty. I am using stack version 1.3.5. Inside "bacnet/basic/service/h_rp.c" file, function "handler_read_property()", the call to function "npdu_encode_pdu()" was not returning to "npdu_len" variable, staying with the default value of -1, and always leading to an error response. A diff of this file to the very latest code base, 1.3.7, proved that, and that was the only change.
So now my device replies BUT not to the correct address; it should, of course, reply to 0x01 (figure attached). I am wondering if it's worth update whole stack to 1.3.7 in order to fix this and other bugs that were iron out.
Thank you,
Luciano.
Yes, I would recommend that you update to the latest version of the BACnet Stack library.
Between the new features in the BACnet standard and bug fixes and refactoring and mods for new use cases, there is always something new or fixed in the latest release.
We do our best to not break API, but that is sometimes hard when the original architect (me!) wasn't as forward thinking about where this little project would be used and how software engineeting has changed over the past 20 years.