Originally posted by tombc How do you make links between points within one panel to another point in a different panel with bacnet.
What controllers are you using ? I have controllers from several different manufactuers that are communicating with each other.
From my expierience these controllers use a global controller to map points across the network. You have to have access to the DDC program. Bacnet uses AI (analog in),BI (binary in),AV (analog variable), and BV (binary variable) points . So for example even though the AI resides on one controller it would be mapped to an AV point that the other controler would call for from the global controller. Here's an example of Alertons transfer gates.Your best bet is obtain a programers manual for your product.
It really depends on the system that you are using. If I get a chiller controller that supports BACnet, and I want to use the points from that, then I use the tools of the vendor of the primary system to map the points in. A BACnet controller is usually profiled by giving you a list of BACnet objects (AV's, BI's, trends, schedules, etc) and a device ID or address, and you must set up client reads / writes to access a point at address xx, object yyy. Again, this setup is usually through tools of the primary vendor. A global controller is not a requirement for all systems. That option usually exists for getting access to different network media, or converting a BACnet world into a proprietary one.
The points are not "bound" as they are in a LonWorks environment, and is one of the main integration differences between LonWorks and BACnet, as far as I can tell. The answer lies within the documentation (you hope) of the system that you are using to pull in the BACnet systems. This can actually be an advantage if you are in love with a vendors systems and toolset.
The chiller and VAV should be able to go to any of the shown locations - mostly dictated by the media of the devices.
In that network diagram, there are two levels of IP network shown. Typically, you would have another media as the peer-to-peer - something such as MSTP or ARCnet. Each one of those network segments has a unique assigned network number. Each device has a unique MAC address for the network it is on (usually settable on the device).
Once the device's residence is established, the device is reachable through BACnet, and a workstation or controller wishing to do client reads/writes to/from that device is programmed appropriately to access "some object in some device on some network", and the linkage should be complete. Where the client reads / writes are executed from (workstation, controller, or combination) is determined by different vendors, and defined by vendor's tools.
I think I'm getting this.... so you are saying even though I plug that Alerton VAV where shown, none of the ALC stuff recognizes it. I may need a BTI on the primary network to map out points and use the Alerton configuration tool to set it up.
You can place the Alerton VAV, and address it, and it will participate minimally in the network segment that it is on. If it is an MSTP slave, it sits, awaiting a request, if it is an MSTP master, it jumps in and minimally joins the network. It is also sitting there full of BACnet objects. Sort of like a LonWorks device does in a LonWorks world.
Assuming ALC is your primary system, it is up to the programmer of the ALC system to use the ALC tools to interface to the BACnet objects of the Alerton VAV. There is no further requirement for Alerton hardware in this configuration. For example, Alerton may have a space temperature as BACnet Object AI 1. Somewhere, somehow, the ALC system must be told "read BACnet Object AI 1 of that device", and it will obtain the value. The opposite for setpoints - "write to BACnet Object AV 7 of that device" to modify the value. Whether that client read/write request comes from the front end, a controller, or a gateway is determined by the system designer and vendor's products.
Vendors may provide some degree of auto-discovery of devices and points that can assist, but that is not a given.
To me, this does not seem that different from a LonWorks device in that when the LonWorks device is powered up, he really does not know who he is, or how and where his points are to be used. No one is really aware of his existence. He relies on a network tool to tell him who he is (addressing parallel to BACnet) and to obtain information about what he is from either uploads or files (auto-discovery, or points lists as BACnet parallels). Of course, there are probably variations of auto-discovery, auto-instantiation that simply installations of vendor's equipment, but I do not think that is universal LonWorks behavior. At the point where the device has been commissioned onto the network, with LonWorks and BACnet, the points are simply there, unused. With LonWorks, you use the concept of binding through network tools to establish the relationship between points. In the ALC example, you would use ALC tools to set up read / write requests to the objects of Alerton. It is a little confusing when trying to compare it to LonWorks because you are setting up client data reads/writes somewhere in the primary system - not bindings. Once the value is read into the primary system, it may be displayed or used in control algorithms.
So the primary differences are that in LON I bind directly and datapoints are defined as to what there are (typically) such as nvoSpaceTemp or nciSetpoints.
In the BACnet world, this doesn't exist as I need to have the manufacturer tool to know what the AI actually is.
Another difference would be that BACnet has no "common" network commissioning tool and doesn't generate a "common" database that can be used by multiple vendors or created by multiple vendors.
From your description it also sounds like there is master/slave arrangements which also doesn't exist in LON controllers. That being the case I would think that there would be an ALC device that manages VAV boxes and an AHU controller that would in turn accept the Alerton VAV at that level?
It is true that LonWorks network variables are more likely to indicate the use of the data if a vendor chooses to do it (and most do). If names such as nviSwitch01, nviAnalog1, ... are used, you only know that it is a switch or one of the AI's, not what it is used for. If you have someting like nvoSetpoint and nviSetpoint in the same controller, you still need documentation to describe the uses of such data.
In BACnet, you rely on published information and/or units/descriptors/names (BACnet properties of objects) of the point to know the use of the data.
You are right in that you do not get a database or commissioning tool that is usable by another vendor. Both of those are usually from the vendor of the primary system. Even if a standard database engine is used, it would be of limited value to another vendor. One of questions I have always had of LonWorks systems though is that for something other than the most off the shelf "profiled" jobs, how free from a vendor are you really? Are you down to just a handful of companies at that point? Don't the front ends still tend to be products of the vendors, such that if the vendor is replaced, someone else must modify/import front end work?
Really, the big protection that I see from either system is the preservation of hardware and avoiding installation should one decide their vendor is no longer the one. If you have a bunch of devices that are BACnet or LonWorks, you still have field devices that may be integrated readily into another system. If you used BACnet or LonWorks RTU's, chillers, and VAV's, you would likely have to remap into the front end of a new vendor (more likely with BACnet), but that is much better than the previous approach of accepting the old vendor or replacing all of the hardware with new.
You have master and slave devices for MSTP, but they are not what you typically think of as a master and slave. Slave devices have limited functionality in that they are not able to initiate data requests, only answer them. Master devices may initiate requests as well as responding to them. It would be possible to have two devices, one slave, one master, that had nearly identical functionality. It is also entirely possible to have an AHU and multiple VAV's on the same network segment, all having MSTP master type controllers. If you wanted to use outside air temp in a slave type controller, a write from somewhere is required to write the outside air temp to the slave. A master could be configured to read the outside air temp from another device.
For other than the "most off the shelf" stuff you can still import anything. The programmables can be more problematic. Companies like Circon and Distech provide plugins for their programming language, while others don't. However, you can use Manufacturer A VAV's pretty easily with Manufacturer B's programmable and there are no architecture considerations. I wouldn't describe the pool of LNS only companies as huge, but really how many BACnet only companies are there? ALC/Alerton/Reliable... -maybe I'm missing one or two. Everyone else has mixed lines, including Delta. (access control) You can still utilize a common network tool and go shopping for what product you like to use from hundreds of manufacturers.
The front ends are interchangeable. (LNS) They even use the common netowrking files. So, no oftentimes you don't modify much of anything.
Lonworks doesn't have master/slave. Everything talks both ways. I could see if the device level network wasn't overly robust this comes in handy to limit netowrk traffic.
I agree that anything now is better than before. Thanks for the information.
Originally posted by sysint
I wouldn't describe the pool of LNS only companies as huge, but really how many BACnet only companies are there? ALC/Alerton/Reliable... -maybe I'm missing one or two.
Actually sysint there are currently around 60 companys. Not all of them are bacnet only. I'm sure each still support their propietary line. bacnet vendors
Brnaul gave a great explaination and it was very articulate. Id like to support his statement that a bacnet chiller can reside on any part of the lan with a graphic of my trane chillers communicating on the IP lan with a bacnet front end. The only reason you are seeing NR values is because this PC is not connected to the network when I captured the pic if it was connected you would see real time values.