Can not connect to the DXR. I get a error code stating 

“Unable to initiate BACnet stack. Verify the IP address are valid and there is no IP address/UDP port conflict with another application that is now running” 

I do not have anything going in the back background, I turned off Zscaler and verified my IVP4 in the Ethernet properties is in Auto find for the IP address. 

------------------------------------------------------------------------------------------
Split from Connection Issue with ABT and DXR.

Hi,

IP address on engineering laptop must be set in same range as IP address on DXR controller.

If your DXR controler is in range 192.168.1.x your laptop must be set to 192.168.1.x range

Hope this helps,

BR,

 Hi,

as well as network mask must be set correctly. DGW it doesn't play a big role, if you you aren't connected via a router.

Otherwise, I'll recommend to close all programs, which use the BACnet port to avoid this problem. Or setup several IP addresses for same network adapter and then each program(ABT Site, ABT Pro, Yabe,etc.) can use own IP address. 

If nothing helps to you, then you can go to  the program & features in the control panel in the Windows and repair installation of the BT H7 Abstraction layer. See the attached picture. 

amk_

Hi,

IP address on engineering laptop must be set in same range as IP address on DXR controller.

If your DXR controler is in range 192.168.1.x your laptop must be set to 192.168.1.x range

Hope this helps,

BR,

I know this is a late reply, but I just solved this issue and noticed that the solution wasn't posted along with the only instance of the question. Hopefully this will help some Techs who just updated to ABT 5.1/5.2.

The Issue:

This is not an issue relating to IP addresses directly. If it were, the DXRs would simply not appear on the discovered side. This actually has to do with your UDP port configuration. In ABT site, startup tab, you can go to the connection manager and select UDP ports between 0xBAC0-0xBACF. If you select any ports other than 0xBAC0 while experiencing this issue it will likely work fine. However, it is not the port that most DXRs broadcast to by default so none will appear in your discovered panel. ABT will only throw the error in question whenever you try to discover on 0xBAC0. This issue persists after reboots and re-installs. 

The Solution:

To solve this issue, you have to kill the task that is parked on 0xBAC0. using "taskkill" within command prompt. Converting this Hexadecimal port number to Decimal returns 47808. Because you cannot kill a task from the port occupation alone, this requires two commands to be entered into command prompt. Open that up as administrator and type in:

netstat -ano | findstr :47808

This command uses netstat to list all known port occupations and uses a | with findstr to filter for only occupations pertaining to port 47808. it will show you a PID for that task as well over to the right of the returned value. You are going to note this PID. For your next command, Type in:

taskkill /PID *ThePIDinQuestion*

Of course, replace "ThePIDinQuestion" with the PID provided by the previous command, without the quotation marks around the PID. This will kill the task, allowing the process to be respawned by the ABT connection manager's internal process. Attempt a discovery again on 0xBAC0, it should work now. If this second command returns an error, re-open command prompt as administrator and re-attempt.

Speculation:

This issue is likely caused by the hardware abstraction layer's headless program detaching from the also headless Bacnet process that occupied port 47808. By being detached ABT is unable to command this program to start the discovery process. ABT attempts to spawn a new task occupying this port, however it returns an error as the "rouge" task is blocking port 47808, awaiting a proper ABT command that it will never receive due to the detachment. By ending this rouge process, you are freeing up the port and allowing ABT to launch a new HAL process to command that port. If this becomes a common issue with 5.1/5.2 it may be necessary to create and distribute a .bat file that completes the process for you to reduce the complexity for users fixing this error. This .bat file could even be triggered by ABT to spot correct this error upon detection.