Ashrae BACnet question

[scrooloose]

To be considered BACnet compliant, is there a list that states what points have to be shown per unit?

Does the standard just state that if you have a analog output that you must provide these points. Or does it state that if you have a AHU or RTU that you provide setpoints, inputs, outputs etc..

Specifically i have a contractor that states they will not provide setpoints for RTUs and VAVs because the standard does not state they have to. They will only provide status of the points, ie Supply Air Temp, %cool, %heat, etc..

So does the BACnet standard state they have to specifically allow setpoints to be seen and adjusted?

[dapper]

I guess it all depends on what your relationship is with the contractor. Are you the customer? If so, I would find another contractor after you call the controls manufacturer and tell them why.
If you are not the customer than it would all depend on what is spec'ed for the job. If setpoints were left out of the spec than someone should take that up with the engineer. I can't imagine what the 'standard' has to do with anything unless there was something in the job spec that said that the control contractor should only follow the BACnet standard.
Has the contractor mentioned how much he will charge each time the setpoints need to be changed? I can't imagine that it will be cheap. Frankly, it is this kind of thing that gives control contractors a bad name. Need I state the obvious association here as well.

[sysint]

....Need I state the obvious association here as well.

Absolutely.

[scrooloose]

I only mentioned the standard because that is what he has told us, that since setpoints arent a ashrae BACnet standard he doesnt feel he has to reprogram his controllers to show setpoints. So i ask to see if he is just pulling this out of his ass so he doesnt have to do the work or if it is stated by ashrae that this doesnt need to be included in bacnet points.

Im sure you have seen job spec's as bad as i have, like "provide ddc controls" well that leaves everything wide open.

[drafty888]

well, your contractor IS right. bacnet does not mandate that the contractor expose setpoints on the ms/tp bus. as i understand it, to be a bacnet compliant device the device must utilize a certain number of bacnet "objects".

but neither does it mandate that you tie your shoes correctly, button your shirts starting with the bottom button, or provide your customer a complete system, etc. you get my point. these things are a mix of common sense deployment, adherence to a job specification, sometimes political posturing, relationship building with you the customer and on and on.

[dapper]

If the guy had any clue what he was doing it I cant imagine it would take any more than a few minutes to 'reprogram' the controllers to show setpoints. Personally I dont think the BACnet standard has anything to do with it. It sounds like he has done this for 'job security'.
The customer should do whatever is required to get rid of this contractor. Personally, I would raise a lot of hell with the manufacturer. This system belongs to the customer, not the contractor but he is making it so it 'belongs' to him. I would not pay for this job without the ability to change setpoints. If he wants the system to belong to him then make him pay for it.

[amigo]

he doesnt feel he has to reprogram his controllers to show setpoints.

You have to be kidding dude, not show setpoints, geez.

It is like buying a car and not getting the keys.
Don't pay a cent to this guy, if you can, hire someone else to fix it right.

[PaulDiglio]

I work for a design firm and we recently specified McQuay unit ventilators for a high school with BacNet compliant controllers. Our specifications included that all points on the Micro-Tech II McQuay controller be made available at the OWS (Operator Work Station).

The McQuay literature gives a list of the RO (read only) and R/W (read write) points for all their packaged controllers.

The automation contractor, who installed an Alerton system, did not bring all the points forward as specified. We needed to issue a directive that he comply with the contract specifications in order to provide our client full information. If you do not have specifications or an approved shop drawing, you might be out of luck.

BacNet is simply a protocol standard that allows controllers of different manufacturers to talk to each other, thereby allowing fair competition down the road.

BacNet defines object properties, so that the headend of the automation system can send and receive data to individual controllers. Each point is defined by some type of network address, type, states, ect in order to conform to the protocol. BacNet is complex and I have only a rudimentary knowledge of it. I would check the manufacturers website to see if there is technical information there listing BacNet available objects for the equipment you are concerned about to see if those points can be made available at the OWS.

[osiyo]

As others have mentioned, this really has nothing to do with BacNet standards, or any other BAS control protocol. It's simply a matter that your contractor is either trying to collect maximum bucks with minimum work, and/or he's trying to ensure you have to make a lot of service calls to him so he can collect additional revenue from you .... forever.

Where I work, we install BacNet, Lon, Tridium, and some propritary protocol systems. With any of them, what the customer/user sees and has access to is something we determine during installation and programming.

Now with some things, we really don't want to put them on a customer's control/monitor screen simply because they're items that the vast majority of customers would not understand anyway. And any attempted change they made to such settings would most likely result in system failure or faulty operation. For example, we typically do not show on the "front end" such items as numbers used for a particular PID loop integral or derivative setting. Usually don't bother to show the value of an input filter. Etc. Most customers have no clue how to use such numbers, nor the effect they have upon the system. Not to mention, it'd just be confusing and tedious for day to day operations. As there would be endless cluttered screens to navigate through to get to the item you DID (as a customer/user) actually want to see.

For instance, a simple VAV terminal unit. Typically we'll show cooling and heating setpoints, setup/setback values, occupied/unoccupied mode, min and max design air flows, current actual air flow, zone temp, discharge air temp, reheat status, damper motor status, Current VAV operational mode, and scheduling info ... if applicable for that job. (Some customers want individual schedules for all or some VAVs, others simply want all VAVs associated with a particular air handler to follow the air handler's schedule.)

That's about it for a VAV. That's pretty much all that'd actually be useful to a customer, and we can get it all on a single, easily viewable, uncluttered screen. Now, if someone wanted us to actually put ALL the control points and configuration data available within that VAV controller on graphic screens on the front end ... GAD ... we could do it but for one VAV controller of a type we commonly use ... that'd be approx 1250 pieces of info we'd need to display ... for every VAV. Most of which would be just useless waste of time and space on the front end as they're not things the customer would want to know or know what to do with if they saw em and could change em.

But certainly we display and allow changes to the first group of items I mentioned. (Well, some of em are read only)

If a customer demands it, even if it's not in the jobs specs to start with, we'll customize things and show em whatever they want. Tho, if it's my project, I have been known to make a customer sign a release statement if customer is wanting access to and the ability to change certain control parameters that I strongly disagree with. And I've told some such customers that if I'm later called because something is not working right, and I find that customer has changed those control parameters I urged em not to mess with ... I WILL be billing customer for my time as I won't consider the call a warranty call.

Chuckle, in other words, fine if customer changes ordinary setpoints and such, but leave things they don't understand alone.

Just trying to give you the idea that ... YES ... most control contractors will leave stuff off your control screens. In fact, they leave off far more than they show. BUT ... everyone I know allows customer access to the commonly needed setpoints, scheduling info, etc. Now, they may lockout access to changing it to a limited few who have correct password if that's what is requested by owner/whoever writes the check. That's common. But I think this is the first time I've ever heard of a controls contractor who wouldn't allow owner to have access to setpoints at all.

Personally, I think you've got a contractor who is trying to rook you. Unless, we're talking about setpoints that are equipment/life safety related.

[sysint]

I work for a design firm and we recently specified McQuay unit ventilators for a high school with BacNet compliant controllers.

BacNet is simply a protocol standard that allows controllers of different manufacturers to talk to each other, thereby allowing fair competition down the road.

BacNet defines object properties, so that the headend of the automation system can send and receive data to individual controllers. Each point is defined by some type of network address, type, states, ect in order to conform to the protocol. ....

.. MAY allow controllers to talk. Not always. Couldn't restrict setpoints on the LON controllers.... you would have them. Further, you wouldn't need the installing contractor to "fix" it. You would do it on your own or have somebody else do it. If it is a programmable and somebody is "rooking" you, tear it out and use somebody else's and backcharge them.

This is one of the two primary reasons I don't go with backwardnet. You part with freedom on the SYSTEM LEVEL. Maybe some day that will change.... just not today or in the foreseeable future.

You would think ASHRAE would look out for the customer by allowing these specification "engineers" to cut and paste their bacnet spec and have the common items in there.... I suppose "all the points" is the easy out.

[ThinkingARB]

Welcome to the gray area of BACnet compliance!

The simple and heavy handed answer is to make the contractor provide the BACnet PICS, (Protocol Implementation Conformance Statement) or the BIBBS, (BACnet Interoperability Building Blocks) statements for ALL of his BACnet devices. This will help you figure out what points are available to read and write to or if the equipment even the objects you may be looking for.

I hate to say it but by showing all available objects it will also show if the contractor is trying to avoid the point mapping, (we all know contractors do everything in the specs).

The documents will also show the LEVEL of BACnet compliance. For example at the field level rarely is there access to scheduling objects, however at the enterprise level it's almost a given. The level of compliance has always been the method of weeding out suppliers that want to put BACnet on their sales aids vs. the ones that can give you true BACnet communications.

[tlp261]

Considering that BACnet is an ASHRAE invention, yoiu might think that consulting engineers would have a clue about what specifying "BACnet compliant" really means. Wrong. Very very few understand BACnet or know that while it's a great way to communicate between systems at an Ethernet level, the exact requirements and points for read/write have to be called out, or it isn't worth crap. SOme BACnet suppliers should be ashamed of their efforts.

[sysint]

Specifying engineers and consultants revolve around lunch, dinner, drinks and a few handshakes..... after that they get their cut and paste-able data that they can toss together in a "specification".

To me that's the biggest reason for an owner to have a peer to peer network with replacement possibilities for each individual controller with another vendors product.

If you are unable to accomplish that, then you are in for trouble or in other words, that's bacnet.

It's easy for me to see why the Army guys did a Lonworks specification. It's something they can get some standards written so their ASC's are all similar and their front ends and programmables can be changed. Further, you can specify variable names and types for programmables and general operations for those variables that allow the individual vendors some latitude on programming and still deliver the variables the spec calls for.

I can tell you if I were an owner and the stinking setpoints weren't available, I'd give the contractor a very short time period to rectify the situation or they would find no check in the mail and their stuff on ebay or the trash can with a letter back to the manufacturer.

[sysint]

....

[control$]

"If you are unable to accomplish that, then you are in for trouble or in other words, that's bacnet. "

Just because YOU can't do that doesn't me everyone can't do that. Keep you limited skills to your lon threads.

[ctrlguy]

"If you are unable to accomplish that, then you are in for trouble or in other words, that's bacnet. "

Just because YOU can't do that doesn't me everyone can't do that. Keep you limited skills to your lon threads.

Your statement would carry more weight if it actually addressed the substance of the argument, rather than attacking the person who made it. Also, if it appeared you could write in English.

[adrianfromoz]

Hi there,

The BACnet standard does not address what is to be made available but how it is made available. This is both a strength and a weakness of the standard. It was meant to allow maximum flexibility in implementation but obviously also allows poor contractor to duck and weave!

It seems that your problem is likely to be a specification issue. Check to see what BACnet objects and services the system is meant to support. Almost certainly the setpoints will exist as a Analog Object and I would expect that in 99% of cases the specification will require these object to be interrogated and set I would imagine as this is a pretty basic requirement of any system claiming to be open!

Regards
adrianfromoz

[asdf;ljk]

The BACnet standard does not specify a "functional profile" like the LON standard does. As adrian points out, this can be viewed as a strength or weakness, depending on your point of view.

But regardless of protocol, why in the h*ll would they not expose the setpoints? What is the point of networking it then?

[GSavage]

Hi there,

The BACnet standard does not address what is to be made available but how it is made available. This is both a strength and a weakness of the standard. It was meant to allow maximum flexibility in implementation but obviously also allows poor contractor to duck and weave!

It seems that your problem is likely to be a specification issue. Check to see what BACnet objects and services the system is meant to support. Almost certainly the setpoints will exist as a Analog Object and I would expect that in 99% of cases the specification will require these object to be interrogated and set I would imagine as this is a pretty basic requirement of any system claiming to be open!

Regards
adrianfromoz

I agree with adrianfromoz - even the aplication specific controller should be able to support analog values. If this project is via a contract and you have a consultant who has designed this, take your concerns to him and let him deal with the contractor or nobody gets paid. I sure the "control" guy will be in shortly to fix his attempt to extort you when all the other trades are not paid because of him.

BACNet is a protocol - not a device, not a chip on a circuit board. It is not and never will be "plug and play". It is a set of guidlines which manufacturers must "interpret" in order to produce a device which is BACNet. To make an informed decision whether or not a bacnet device will suit your needs, you need to know what services the installed device supports - your best resource for this is most likely the bacnet testing lab report on the specific device. In my opinion, if its not listed on BTL, its not bacnet.

[orion242]

“.. MAY allow controllers to talk. Not always. Couldn't restrict setpoints on the LON controllers.... you would have them. Further, you wouldn't need the installing contractor to "fix" it. You would do it on your own or have somebody else do it. If it is a programmable and somebody is "rooking" you, tear it out and use somebody else's and backcharge them.

This is one of the two primary reasons I don't go with backwardnet.”


How is this any different that a programmable lon controller without SNVTs linked to its setpoints, or a contractor not supplying the customer with the LNS database?


>tear it out and use somebody else's and backcharge them.

You can be in this same boat with any “open” system or closed system. I fail to see how lon is any more open the bacnet. If a contractor wants to screw you, there is plenty of opportunity with both.