Last edited by sysint; 12-13-2007 at 07:11 PM.
"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.
Originally Posted by control$
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!
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?
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.
Originally Posted by adrianfromoz
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.
“.. 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.
If it is a device, it's datapoints are available. Period. If it's a programmable and the setpoints are incased in the program, since LNS Lonworks is a peer to peer network of individual controllers, you can get rid of the single device. For instance, I can easily use a Circon or a Honeywell controller to run Distech VAV's. The VAV's are Lonmark so even the variable NAMES and TYPES are consistent.
Originally Posted by orion242
As far as not getting the LNS database you can recover or recommission and configure most (if not all) devices (I've yet to have a problem with a working device). So you aren't totally screwed by crawling back to the original equipment vendor.
Further, the front end isn't even necessary. It's simply another device so you can use your own.
In all bacnet networks I've seen to date each vendor who has equipment invariably holds the keys to their configuration software. (multiple phone calls) Additionally, I have yet to see a complete subsystem with differing vendors.... ALC controller with Alerton boxes configured by ALC..... it doesn't happen. That's how the ASHRAE bacnetter good 'ol boy network keeps everybody in $$$$. The illusion of open.
I'll go further-- we have a vendor we had been using. They designed a LON product we installed on a project. It failed completely. They had internal problems with the devices. The end of the story is that they did an end-around with settling with the customer on removal of the product with an NDA and left us holding the bag on the product declaring "no problem". So, I made the decision to cut them off as we had hundreds of hours chasing our tails on nothing, not to mention removal and reconfiguring the structure of the network. (found out just last week they think they found their issue...)
However, I can still config their existing controllers with other software and can replace their front ends with a choice of other software. When their controllers die I can get an alternate, with most of the ASC's functionally similar.
If this was a bacnet vendor, this would be significantly more difficult if not impossible.
Hey ctrlguy. I'll try to keep my spell check on. This was a thread on exposed bacnet points. Not another let's bash bacnet. Sorry if I hit a soft spot, but someone has to point out the bravo sierra.
This deffiently helps me with what i need to do to go forward with this contractor. Pretty much you guys helped me confirm what i thought. Which is if you want to get technical he doesnt have to supply setpoints if its not called for it. But on a user level what is the point of integrating to a company that you get no control of.
So i need to go forward and start hitting the people who designed and who pay him to get this to be a useable product for the customer.