Luciano Rottava da Silva

Hello Steve, Thank you very much for the quick reply and the explanation. Was busy testing my implementation; think got it right. Again, lack of a deeper understanding about the protocol itself. Having a Priority_Array is probably required when there are several controllers, in different levels, trying to access a common resource. After I understood that, things click in place. Regards, Luciano.

Hello, I am in the stage of implementing the final properties for the supported (AI, AO, AV, BI, BO and BV) BACnet objects in my product. Stack, MSTP, is running perfectly fine! I am already able to read and write pretty much everything using Yabe, for instance. Most of the properties are there already, my only uncertainty is related to the properties Priority Array and Relinquish Default. I'm trying to model all objects as structs, as found in the excellent examples supplied along. For instance,...

Hi Steve, Glad to help, even with a tiny fix. And congrats for this fantastic stack, quality is top-notch! Regards, Luciano.

Hello, Today, I think I have found the problem; and it's indeed related to the destination address. Inside 'dlmstp.c' file there's a call to a function named 'MSTP_Create_Frame()'. One of the arguments of this funcion is the destination address. But it turns out this argument, 'packet.address.mac[0]', is a local variable initialized to null. In the end, replies are always addressed to macid 0. Simply replacing this argument by 'pkt->address.mac[0]' fixed the issue, and the properties of my device...

Hello, Today, I think I have found the problem; and it's indeed related to the destination address. Inside 'dlmstp.c' file there's a call to a function called 'MSTP_Create_Frame()'. One of the arguments of this funcion is the destination address. But it turns out this argument, 'packet.address.mac[0]', is a local variable initialized to null. In the end, replies are always addressed to macid 0. Simply replacing this argument by 'pkt->address.mac[0]' fixed the issue, and the properties of my device...

Hello, Today, I think I have found the problem; and it's indeed related to the destination address. Inside 'dlmstp.c' file there's a call to a function called 'MSTP_Create_Frame()'. One of the arguments of this funcion is the destination address. But it turns out this argument, 'packet.address.mac[0]', is a local variable initialized to null. In the end, replies are always addressed to macid 0. Simply replacing this argument by 'pkt->address.mac[0]' fixed the issue, and the properties of my device...

Hello everyone, I'm stuck for a week with an issue which I haven't found the cause yet. When I launch Yabe (or Banks) clients (set to Id 1) in order to scan the network and identify all equipment, my MS/TP device (Id 5) is correctly found. However, whenever I try to read the properties, device answers correctly but to the wrong address (always 0 rather than 1). Wireshark and Saleae logs show this behaviour clearly. Chain of events is happening normally: bacnet_task() -> npdu_handler() -> apdu_handler()...

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;...