[SOLVED] Problems communicating with MS/TP using the bacnet-stack-1.0.0 apps example

Problems communicating with MS/TP using the bacnet-stack-1.0.0 apps example

I use the server example in apps to simulate BACNET MS/TP SERVER, by modifying the environment variable to set the baud rate 38400, MAC address 0x78. The operation effect is as follows：

/var/user/app/device_supervisor # ./bacserv 20000
BACnet Server Demo
BACnet Stack Version 1.0.0
BACnet Device ID: 20000
Max APDU: 480
pyh defined MSTP
MS/TP Interface: /dev/ttyO3
RS485: Initializing /dev/ttyO3 at Baud Rate 38400=success!
MS/TP MAC: 78
MS/TP Max_Master: 7F
MS/TP Max_Info_Frames: 1

I use the readprop example in apps to simulate the BACNET MS/TP CLIENT, by modifying the environment variable to set the baud rate of 38400, MAC address 0x79, The operation effect is as follows：

root@pyhao-VirtualBox:~/pyhao/tmp/bacnet-stack-1.0.0-yuan/apps/readprop# ./bacrp_mstp_x86 20000 0 0 85 --mac 78
pyh defined MSTP
MS/TP Interface: /dev/ttyS1
RS485: Initializing /dev/ttyS1 at Baud Rate 38400=success!
MS/TP MAC: 79
MS/TP Max_Master: 7F
MS/TP Max_Info_Frames: 10
pyh send read req
pyh Send_Read_Property_Request_Address
pyh dlmstp_send_pdu
pyh Ringbuf_Data_Put
pyh bytes_sent = 13
pyh pdu len = 0
pyh pdu len = 0
pyh pdu len = 0
pyh pdu len = 0
pyh pdu len = 0
pyh pdu len = 0
pyh pdu len = 0

bacnet-stack-1.0.0-yuan/apps/readprop/main.c
        /* returns 0 bytes on timeout */
        pdu_len = datalink_receive(&src, &Rx_Buf[0], MAX_MPDU, timeout);
        printf("pyh pdu len = %d\n", pdu_len);

As shown above, when I ran the client program I did not read the value of the property, and the server did not print anything, I was sure that my connection was okay because I used rs485.c for the 485 test and sent and received data normally.

The same way I used bacnet/ip to communicate normally, but it didn't work in mstp mode, I searched for some materials, but it didn't help me with the problem I was having

Solution

The issue has been resolved for the following reasons: At that time, it was judged that there was no problem in the environment, only verified that the message sent from the gateway was sent, and the virtual machine could receive it, but after troubleshooting today, it was found that the virtual machine could not receive the message gateway, and the problem was solved after replacing the serial port cable