Aaon VCCX BACnet Integration

[controls21]

Ran into a VCCX2 controller on a new Aaon RTU. Just looking to pull points over BACnet into a Carrier iVu. It times out over and over. The controller is found during a network search, but points never pull.

I have the MAC address by itself to eliminate address conflicts, and the baud rate is 76800bps. Anyone run into this before?

[MaxBurn]

Results with a third party scanner?

This is a protonode like device with a network port right? Plug in and see how the device ID and other bacnet info in the web page is set up.

[patpinet]

Is the VCCX2 bacnet ready or you still need a fieldserver control in between.

In the older style board a external comm board was needed

[381engineer]

Ran into a VCCX2 controller on a new Aaon RTU. Just looking to pull points over BACnet into a Carrier iVu. It times out over and over. The controller is found during a network search, but points never pull.

I have the MAC address by itself to eliminate address conflicts, and the baud rate is 76800bps. Anyone run into this before?

Did a job recently with about 15 VCCx2 RTU and i had intermitent com problems until I landed the shield at each device. I also used 34800 buad.

[orion242]

485 needs a ground reference, be it 3-wire or 2-wire with common ground. Likely your issue.

Field servers getting sent to a site unconfigured will normally show up as a device with no points. If the device shows up with no points...comms are typicaly fine. Gateway/oem setup issue stinks at that point.

OP can see the device, but not points. Smells of a configured gateway.

[controls21]

Thanks for the replies everyone. Here's the weird thing, I can use BACnet Quick Test and pull all the points from the controller. Using the Carrier Field Assistant software, I can discover the controller but when I try to find the points (274 of them) after about 6 seconds of activity on the USB adapter it times out and fails.

I've been told by Aaon Tech Support that since this is the VCC-X2 model, the field server board is not needed anymore. This seems to point to Carrier/ALC software not talking with the Aaon controller. I can't change the comm speed from 76.8Kbps because lots of other devices are already on this comm bus with that speed. Also the 38.4k would halve the number of devices I could install before repeaters.

The wiring is tight, shield/drain is connected on all these. This one is a head-scratcher

[Balibe]

Is this your message ................

Starting discovery
Binding to device 130003...
Reading Object List (this may take a while)...
No response from device: 8:130003 Error: No response from: [DEV:130003 1303:10.9.2.3:47808:245] in 3 attempts at 4000 millis. Controller timeout.
No objects found.
Done in 15 seconds.

You can try to increase the communications retry in FA if your bus is busy. Will i-Vu find the controller and points? If not, you can try to increase the APDU retries in the driver properties.

FYI .... A third party device does not need to be scanned into Discovered Networks by i-Vu to bind and communicate, i-Vu will use the control program in the Link to bind the device and points. The message above is from an ALC OEM controller that we have no issues communicating with but i-Vu cannot generate a points list.

Since you know the points from Quick Test, create a snap program, map a few points and download to a Link. Since you are finding the device, the points should connect even if i-Vu cannot discover the points.

[controls21]

Balibe,
I see you've received the failure message too. Yeah that is the same I get. There are only 21 devices and 1400 feet on the bus so far, it doesn't look real busy. I added a repeater last week just to see what would happen with no change.

Think the issue I'm gonna run into is, I don't have a Plus, just a Standard i-Vu. Usually can get around that by pulling points in FieldAssistant and then just adding a program to a programmable controller.
I tried BACnet discovery on the Link and got "Failed to create null (xxxxx). Reject, missing required paramter" blah blah.

I'll definitely give your advice a shot, will be going back there this week. If ALC/Carrier ever wonder why Tridium has eaten up market share, they need to look at this stuff. Not that I think Tridium is the greatest, but it's too bad guys like you and I end up being tech support.

[MaxBurn]

Does your front end have bindings all the way down to the last router that is providing the MS/TP segment this AAON is on? I generally find that's where the issue is, if that router doesn't show bindings to the front end there is something wrong with the configuration and discovery will not work. WebCTRL and iVu gloss over a lot of things but all the BACnet routing, FDR/BBMD etc need to work for discovery to work. You can have a lot wrong and not even know it, I'm not even sure iVu uses dynamic bindings as newer versions of WebCTRL do.

But as has been said this isn't a requirement for the integration to work. As long as what's running the integration program with the bacnet:// URL in it can find and bind the AAON you are fine. Also as you have the BQT discovery you already have everything you need.

[unonut]

You can try to enable static bindings in iVu if its possible. I know WebCTRL so please translate software app name. Here the steps to do it in newer versions. (this used to be done with the click of a button in versions 4.1 and below.)

Shutdown WebCTRL
Open SiteBuilder then open site you are working on.

In the network tree right click on the system icon at the very top of the tree and go to properties. Next go to the advanced tab and select the checkbox to Enable network address translation. You should be able to leave the network at 0 and then put the server address in the available field. (put the actual static IP assigned to the physical WebCTRL server). Save system, close sitebuilder and start WebCTRL. Go to downloads and download parameters to all routers. This will change the binding to the server from a device instance to the actual IP address.
Do a network discovery and watch what comes up.
Also make sure you dont have duplicate device instances on the system. Remove the com from the lennox controller and do a scan. If that device instance shows up you have a problem.

BIG ALC TIP. Always do device discovery in WebCTRL. Find all your networks then all devices under each network. After this is done DO NOT DELETE THE DISCOVERED DEVICES. By doing this you now have all device instances and networks that are currently on the network. Now when you are working in site builder it will not allow you to duplicate any device instances this includes instances that were discovered. It will also automatically change device instance conflicts for devices that were clipped in. When it changes these instances during clipping imports make sure to download the modules that had changes right afterwards because the new instances do not go into affect until after and download has been completed. Hope this helped

[Cool breeze 38]

the standard doesn't have bacnet discovery. the plus and pro do, as does field assistant. you're taking the white usb adapter and going to an open controller on the rnet port and searching that way correct?
Bacnet discovery isn't done on the link. The link is a router that allows programs to be put on it for third party. No real difference then using a UC controller for the programs if you don't need routing.

Are you choosing the network the third party devices are on.( if there are more then one) hitting bacnet discovery. then doing the discovery on every device individually? just trying to see what you're actually doing.

Balibe,
I see you've received the failure message too. Yeah that is the same I get. There are only 21 devices and 1400 feet on the bus so far, it doesn't look real busy. I added a repeater last week just to see what would happen with no change.

Think the issue I'm gonna run into is, I don't have a Plus, just a Standard i-Vu. Usually can get around that by pulling points in FieldAssistant and then just adding a program to a programmable controller.
I tried BACnet discovery on the Link and got "Failed to create null (xxxxx). Reject, missing required paramter" blah blah.

I'll definitely give your advice a shot, will be going back there this week. If ALC/Carrier ever wonder why Tridium has eaten up market share, they need to look at this stuff. Not that I think Tridium is the greatest, but it's too bad guys like you and I end up being tech support.

[kunalpurohit91]

Good Morning
I have question rrgarding AAON vccx 2 controller and wantto get solution.
I am tring communicate on BACnet side. I am able to read all points I want but when I am trying to write , VCCX 2 goes in alarm mode of FAN prove failure. I am not able to understand why.

[kunalpurohit91]

Good Morning
I have question rrgarding AAON vccx 2 controller and wantto get solution.
I am tring communicate on BACnet side. I am able to read all points I want but when I am trying to write , VCCX 2 goes in alarm mode of FAN prove failure. I am not able to understand why.

[controls21]

I may have an idea. To start with, do you have the Aaon Service tool with SD card? It's actually from Watt Master and is part OE391-12.

If you do, plug up to the controller directly and use the handheld to change the exact same point you're trying from a PC or laptop. Does it still alarm?

I have found that even when Aaon says a point is writable in their VCCX-2 manual some just won't accept changes. Other points cause a conflict in the controller and it responds with an alarm.

I had a similar problem but my changes made the unit change mode from Cooling to fan only, and required a power cycle to go back to normal.

If it is possible, make your software changes at the rooftop unit so you can look at the screen and see exactly what point write causes the failure.

[xnigelx]

Hey guys. Long time following this forum first time posting. I saw this topic and it has been a pet peeves of mine. ALC discovery will not discover on AAON. I have a feeling it has something to do with segmentation that needs to be modified in the server.properties. We use YABE for discovery and after we get the list the integration itself works fine.

[controls21]

xnigelx, back in previous replies in this thread they covered your issue. I tried BACnet discovery with Carrier and had the problem you are experiencing. Since i-Vu is modeled after WebCTRL, the problem is the same. It looks like the ALC and Carrier product won't do an automatic BACnet discovery of the Aaon points, but third-party programs like YABE or BACnet Discovery Tool have no issue.

As long as you have the points list with the exact names that Aaon provides, you can manually create a control program to integrate. It would be nice if ALC or Carrier could automate the process and speed up our work.

[xnigelx]

xnigelx, back in previous replies in this thread they covered your issue. I tried BACnet discovery with Carrier and had the problem you are experiencing. Since i-Vu is modeled after WebCTRL, the problem is the same. It looks like the ALC and Carrier product won't do an automatic BACnet discovery of the Aaon points, but third-party programs like YABE or BACnet Discovery Tool have no issue.

As long as you have the points list with the exact names that Aaon provides, you can manually create a control program to integrate. It would be nice if ALC or Carrier could automate the process and speed up our work.

I've been in process of figuring out how to get it resolved. Problem is every AAON job we get end up being a rush job so I don't get much time to play. I probably just need to find a controller I can play with. I would be curious to see if the OFVI from ALC would have better luck as it uses a different discovery. Once we can figure out what WC/IVue do differently than 3rd party, it can be pushed to R&D for resolution.

Sorry I missed the early post.

[MaxBurn]

Come to think of it I did run across some AAON units that wouldn't discover in ALC a short while back. Same issue, controllers discovered fine and points would not discover. Thought I had a message about RPM vs single though? Thing is I just moved on to either BQT or YABE and got discovery there. Once I saw the controllers themselves had no issues binding to points on the AAON units I needed to move on. Thing is WebCTRL discovery doesn't actually matter at all, it's just a tool to help you find stuff.

[xnigelx]

Come to think of it I did run across some AAON units that wouldn't discover in ALC a short while back. Same issue, controllers discovered fine and points would not discover. Thought I had a message about RPM vs single though? Thing is I just moved on to either BQT or YABE and got discovery there. Once I saw the controllers themselves had no issues binding to points on the AAON units I needed to move on. Thing is WebCTRL discovery doesn't actually matter at all, it's just a tool to help you find stuff.

This is true but I am a glutton for information and I need to know WHY it is able to bind and read the values but not bind to discover. I am absolutely sure there is something in the system.properties that can be tweaked to make it work. Curious what Wireshark would look like.

[kchest4063]

This is true but I am a glutton for information and I need to know WHY it is able to bind and read the values but not bind to discover. I am absolutely sure there is something in the system.properties that can be tweaked to make it work. Curious what Wireshark would look like.

Were you ever able to find out anything about this?