Delta ORCAview settings

[ControlsInMT]

Our IT dept claims they haven't changed anything, but ORCAview quit communicating. We run a Tridium front-end (R2 still) and I use the ORCAview to access the DSC panels for troubleshooting. The error I get is "Can not open comm port" or "100.DEV100: COMM TIMEOUT".

Using the UDP/IP on a local LAN segment, panels do not have a set IP address (just riding the wire).

Anyone have any guess? The help is greatly appreciated since I have contacted Delta twice and had no response.

[CE-TECH]

Is Tridium still communicating

[RyanT]

I'm not used to seeing controllers run on another network without udp/ip addressing. Are you running through a managed switch?

[berg2666]

You can not use UDP/IP and not have IP address, disable the udp ip driver and enable the ethernet driver

[RyanT]

I agree with Berg, except if you are riding their intranet, you may need to be all tcp/ip. Also, in the Bacnet object, you will see port numbers. These need to be configured correctly.

[D1G]

I can't imagine a network that wouldn't allow UDP/IP while allowing TCP/IP unless your device resided outside the perimeter firewall or possibly within the DMZ.

If it was working before but not now it is possible the IT folks may have knowingly or unknowingly changed some of the internal firewall rules (depending on what they're using) and are now blocking ports 47806-47808 (I think that covers all the "standard" BACnet/IP ports) which cover registered ports for BACnet traffic.

If you're trying to connect to a device on the same segment there is nothing the IT folks could have done to cause this. If you're not hopping over one of their switches or routers they essentially have zero control over your traffic once you're able to connect to the network.

It's possible you're on a managed switch and they've updated the MAC access, this would prevent you from accessing anything past the switch. If you're on a Windows box you can tracert the IP of the device you want to connect to and see where it stalls, assuming the CAM tables (or equivalent) are recent.

R/ D1G

[berg2666]

I have also read somewere that 47809 is included.

[berg2666]

Our IT dept claims they haven't changed anything, but ORCAview quit communicating. We run a Tridium front-end (R2 still) and I use the ORCAview to access the DSC panels for troubleshooting. The error I get is "Can not open comm port" or "100.DEV100: COMM TIMEOUT".

Using the UDP/IP on a local LAN segment, panels do not have a set IP address (just riding the wire).

Anyone have any guess? The help is greatly appreciated since I have contacted Delta twice and had no response.

Get the mac addresses of all the devices on your site and give them to the IT deptand tell them you need static IP's and reservations made in there system.

[berg2666]

Our IT dept claims they haven't changed anything, but ORCAview quit communicating. We run a Tridium front-end (R2 still) and I use the ORCAview to access the DSC panels for troubleshooting. The error I get is "Can not open comm port" or "100.DEV100: COMM TIMEOUT".

Using the UDP/IP on a local LAN segment, panels do not have a set IP address (just riding the wire).

Anyone have any guess? The help is greatly appreciated since I have contacted Delta twice and had no response.

Is the orcaview installed on the same computer as the tridium front end or on different computers. If different then you may have a port security issue going on.

[D1G]

I have also read somewere that 47809 is included.

You're right, some sites don't have it listed but I checked and it is a registered BACnet/IP port. I thought there were four but couldn't remember for sure.


ControlsInMT,

You can use telnet to see if those ports are being blocked or restricted on the IP network but to reiterate you're target must have an IP address. It's not possible to connect to a device over an IP network without one, how were you connecting to it before without an IP address? You can use the MAC address if you're on the same segment but UDP/IP still wouldn't work.

If you only had one BACnet device on the segment you could have used the broadcast IP and established communications but the DSC would still need an IP within that subnet otherwise it would just drop the packet unless it's promiscuous (which I highly doubt). In this highly unlikely event, it's possible the IT folks have blocked all traffic to xxx.xxx.xxx.255.

[ControlsInMT]

Thanks for all of the info. I had given all of the MAC addresses to the IT guys, but I will send them the list again. We do run through managed switches and I'll bet those wound up blocked.