Too funny!!!... Yes, BACnet/LON

[codewriter]

BACnetTM, the standard communications protocol for the HVAC controls industry, is clearly becoming the accepted alternative to the proprietary communications solutions that to-date have dominated most HVAC controls installations.
............BACnet is an entirely non-proprietary system............................................ ....


............LONtalk is a proprietary technology developed by the Echelon Corporation and is the only LAN type that requires special development tools and a proprietary chip set to implement...................

[kwillmech]

Anybody come to mind? Anybody besides the orange giant that is.

[sysint]

Alerton spews this lie all the time.

Alerton has no problem lying about the industry and falsifying documentation to promote their proprietary bacnet lineup.

[ccnman]

The carrier ccn/alc product line is soon going full bacnet
i thought the reason for this is that bacnet is not proprietary.?

[sysint]

Carrier also had a couple wingnuts write some article like "interoperability and the internet".... anyway, those wingnuts stated the same old garbage about LON.

I can see why these companies want to lie about Lonworks. It's a device level open protocol. That puts a wrench in their ability to lock-up whole subsystems like they can do with their proprietary bacnet systems.

Same old fight - ASHRAE being a business and lying. OEM's laughing all the way to the bank with their proprietary subsystem installations and the customer holding the bag of big dollars for every proprietary bacnet system in their building.

..... so much for the ASHRAE code of ethics.

"i thought the reason for this is that bacnet is not proprietary"
bacnet allows for proprietary. It's written in the specification.
There is no common networking tool like Lonworks has.
Show me a peer to peer bacnet network.... it doesn't exist.
Show me an interoperable bacnet system on the device level....doesn't exist.
Show me how to swap an Alerton VAV with a ALC VAV controller....can't do it.
By contrast, in a Lonworks network all the "show me's" are possible.

bacnet is a lie. ASHRAE promotes the lie rather than taking a stand against the manufacturers distorting the concept. ASHRAE essentially promotes manufacturers business operations. Free advertising for the bacnet group. Customer gets the screw again.

[Edited by sysint on 10-31-2006 at 08:57 PM]

[codewriter]

http://www.hvacwebtech.com/bacnet.htm

[sysint]

See- they got their lying straight from Alerton.

[jhawk]

"Alerton has no problem lying about the industry and falsifying documentation to promote their proprietary bacnet lineup."

Sysint,

Can you give specific examples?

[sysint]

The Alerton "white paper".

They outright lied to those dumb dumbs at Frost/Sullivan and also lie about some pie in the sky requirement for a Neuron chipset in Lonworks.

Honeywell and Invensys wrote letters calling for a retraction of the false statements, of which Alerton never did.

They lie about bacnet interoperability.
Again, show me a like replacement strategy for Alerton VAV's with another "bacnet" manufacturer. How about a common networking tool? How about being honest about all the proprietary configuration software required from EACH vendor.
How about the conflict of interest of Mr. Swan touting his work with ASHRAE as a marketing tool from a supposeadly independant organization for the common good?

How about that spew about 'dual-sourcing'? What a piece of work that PDF is.

I also note they even talk about Modbus, but when it comes to the largest market leader Lonworks, they are silent. Which I understand because you can only lie so much. Once people investigate, their eyes get opened up.

[skrewt]

My philosophy is this:

"If you can't buy the parts and software at Wal-mart, it's proprietary".

simple as that.

[kwillmech]

To counter that: Would you want it sold at Wal-mart? What if you were the company marketing the product? I think many of the big players keep it "proprietary" because of quality control. Not to say the factory techs are the best but at least you know who is responsible for putting in the messed up systems. Look at Johnson Controls and Honeywell, almost anyone can become "Certified" and install their systems. How many times do you hear about one that wasn't installed correctly? I hear that a lot

[sysint]

I think many of the big players keep it "proprietary" because of quality control.

Hardly. It's about a continuing revenue stream and prevention of expansion by another vendor. These "big players" want to get a foot in the door and then punch out the owners with future additions and service.

It's more fiscal control than quality control.

That's why they love bacnet. Allows them their goal of fiscal control under the lie of ASHRAE and bacnet.

As far as the "Walmart" comment - with Lonworks you can buy from Engenuity. That's as close to Walmart shopping the control industry has right now. Again, that would be what an open device level peer to peer protocol allows - something bacnet can't achieve because it's really not very "open".

[kwillmech]

Let's be fair though, there are LON devices that are less than desirable when it comes to integretion. Don't believe me then check out the xif file for a Data Aire computer room unit. Oooh how about the PresSura space pressure controls, another gem!

[lon man]

Are these devices LonMark certified?

[theoldman]

Lon and Bacnet won't matter when Obix smashes them both. With Obix, why would you ever need either one?

[sysint]

When you have bacnet out there screwing up the industry you will get your manufacturers that don't see the need to develop Lonworks DEVICES instead of INTERFACE. Or, make plugins for their devices. Don't buy their stuff.

That doesn't detract from the fact that Lonworks is still device level, and you can still read/write data at the device level. Your next unit or replacement unit doesn't need to be Dataaire if you don't like the interface. You can still use any manufacturers LON based network tool and commission the device. Very low impact cost -wise overall.

However, your next VAV controller in an existing Brand X (pick a name) bacnet system would defintely need to be Brand X. You also would need Brand X software to run Brand X. It is probable that you cannot talk directly with Brand Z unless Brand Z goes through a Brand Z supervisor box and then to a Brand X supervisor box. Or, even if you can talk directly to Brand Z, you still need Brand Z software....

Actually, there is more situations, but bacnet is such a mess I'll stop going on..... I think you get the point.

[sysint]

Originally posted by theoldman
Lon and Bacnet won't matter when Obix smashes them both. With Obix, why would you ever need either one?

Because you still need a protocol unless every device is connected to the Internet.

Obix is for interface in the enterprise. Obix smashes bacnet because bacnet is weak in the fieldbus level. Obix displaces bacnet at the supervisory level. Look no farther than to Tridium to see that.

[jhawk]

Sysint,

What exactly were Alerton's lies? Can you quote some and give links to their web page or something? I don't doubt that they are there, but surely you have something to back up your claim.

Thanks

[sysint]

Well Jhawk - my backup used to be right here on this website.
After Alerton spoon fed Frost and Sullivan their BS story on actual Lonworks units sold both Honeywell and Invensys wrote letters saying Alerton was full of #)($.

However, this site doesn't go back far enough.

So, notwithstanding Google, does anybody have a copy of those letters so Jhawk can see whereby Alerton promoted false documentation in it's own interests?

And after those letters are reposted to this site be sure to admit who was right.

TIA.

[nikko]

Sysint - Unfortunately I don't have a copy of those letters, but I certainly remember them.

jhawk - Alerton had a short period where they lobbed out shrapnel filled information grenades (BACnet/LON) and because it came from Alerton, publishers assumed the information was valid.

It wasn't and in fact much of the information bordered on slander and libel. The rest of the information was largely made-up and not credible. They came very close to getting in a world of trouble for it.

Several publications were red-faced for publishing the work without validating it and Frost and Sulivan lost a mountain of credibility for their lack of depth into their research for a study they published. In fact, F&S still have not recovered and I'm not sure they will. They certainly won't in my eyes and I've worked with them on several surveys since.

Most of this happened while Alerton was still an independant. Since the merger(s), they've been a lot less vocal however much of the old stuff is still around and gets regurgitated as gospel by the ignorant. It's a shame really - misinformation doesn't do anyone any good and in fact hurts the entire industry.

Nikko

[kwillmech]

Originally posted by lon man
Are these devices LonMark certified?

Of course not. It is unreal to limit yourself to Certified controllers. Even if they were all Certified it only dictates the minimum data points required to meet the specific profile.

[kontrolphreak]

When you have bacnet out there screwing up the industry you will get your manufacturers that don't see the need to develop Lonworks DEVICES instead of INTERFACE. Or, make plugins for their devices. Don't buy their stuff.

That doesn't detract from the fact that Lonworks is still device level, and you can still read/write data at the device level. Your next unit or replacement unit doesn't need to be Dataaire if you don't like the interface. You can still use any manufacturers LON based network tool and commission the device. Very low impact cost -wise overall.

However, your next VAV controller in an existing Brand X (pick a name) bacnet system would defintely need to be Brand X. You also would need Brand X software to run Brand X. It is probable that you cannot talk directly with Brand Z unless Brand Z goes through a Brand Z supervisor box and then to a Brand X supervisor box. Or, even if you can talk directly to Brand Z, you still need Brand Z software....

Actually, there is more situations, but bacnet is such a mess I'll stop going on..... I think you get the point.

The highlighted statement above is not the case with native BACnet controllers. We have multiply vendors BACnet controllers residing on the same MS/TP network and they all communicate peer to peer. Yes, you need each individual controllers software to set it up, but once set up they can all be seen and controlled by any of the front ends or controllers. But as long as the devices are native BACnet and are communicating at the same baud rate they can reside on the same RS-485 network (some BACnet vendors use ARCnet and these can't reside on a MS/TP network). Many BACnet operator workstations they will discover any BACnet devices added to an existing network automatically.
With LON at the application specific level you can use plug-ins to set up a LON controller from any, but most freely programmable LON controllers still need some type of vendor specific software to program them (t.a.c. needs Menta for example). The only LON system I'm aware of that has plug-ins for their freely programmable controllers is Distech (one of the most truly open systems on the market).

kontrol out

[kontrolphreak]

Carrier also had a couple wingnuts write some article like "interoperability and the internet".... anyway, those wingnuts stated the same old garbage about LON.

I can see why these companies want to lie about Lonworks. It's a device level open protocol. That puts a wrench in their ability to lock-up whole subsystems like they can do with their proprietary bacnet systems.

Same old fight - ASHRAE being a business and lying. OEM's laughing all the way to the bank with their proprietary subsystem installations and the customer holding the bag of big dollars for every proprietary bacnet system in their building.

..... so much for the ASHRAE code of ethics.

"i thought the reason for this is that bacnet is not proprietary"
bacnet allows for proprietary. It's written in the specification.
There is no common networking tool like Lonworks has.
Show me a peer to peer bacnet network.... it doesn't exist. Seen many BACnet MS/TP and BACnet IP networks that are peer to peer.
Show me an interoperable bacnet system on the device level....doesn't exist. Seen many BACnet MS/TP and BACnet IP networks that are interoperable.
Show me how to swap an Alerton VAV with a ALC VAV controller....can't do it. Bad Example. True, Alerton VAV reside on a MS/TP network and ALC resides on an ARC156 network now (just like a LON device on a FT-10 could not replace a LON device on a power line carrier network) and the old ALC VAV controllers resided under a UNI (resides on an ARC156 network) which was the "brains" where the program for the VAV resided.
By contrast, in a Lonworks network all the "show me's" are possible.

bacnet is a lie. ASHRAE promotes the lie rather than taking a stand against the manufacturers distorting the concept. ASHRAE essentially promotes manufacturers business operations. Free advertising for the bacnet group. Customer gets the screw again.

[Edited by sysint on 10-31-2006 at 08:57 PM]

My comments to the above are in bold italics.

kontrol out

[ctrlguy]

Seen many BACnet MS/TP and BACnet IP networks that are peer to peer. Examples, please. Is this common among all BacNET manufacturers?

[kontrolphreak]

I have seen ABB drive / SE6104 ALC controller (configured to MS/TP) / Delta DSC-T305 and a Alerton VAV controller residing on a Reliable Controls MS/TP network, using RC-Studio to adjust/control each device.
We also have a project with ABB drives and York Chillers residing on a Delta Controls network. Theses devices (7 drives and 2 chillers, didn't need their software to configure anything. We did need York's documentation as their BACnet points are only identified with numbers :confused: , but the ABB drives had all the points identified well and all came up with no downloading of xif files or any such deal. Just write some code using the BACnet points in the device and we where good to go) are on MS/TP networks under individual Delta System Managers (DSM-RTR) that are connected at the BACnet IP level. ORCAview being the front end.
We have had Delta Controls / Viaconics and Reliable Controls all on the same MS/TP network.
We have multiply projects that integrate Delta Controls to ALC at the BACnet IP level using a Tridium R2 front end.(ALC being controlled by Delta Controllers directly ie. peer to peer. Remove the Jace and it would still function).
We have integrated to Trane LON air handlers using a Tridium Jace, being controlled by a Delta ORCAview front end.
We have also integrated to Trane Chillers on a Delta Controls MS/TP network.
We have an Andover Continuum system under a Stefa Jace, being adjusted/controlled by Stefa and the Jace.

All these devices communicate peer to peer (except the LON to BACnet which relies on the Tridium Jace), if the front end is not present the devices will still communicate and function. With the Trane air handlers if the Jace dies no more worky.

I don't know if it is common among all BACnet vendors (I have only worked with ALC / Delta Controls / Reliable Controls / Alerton / Andover), but it can be done with native BACnet controllers/systems. ALC is one of the harder ones to integrate to.

kontrol out

[jimmyj]

Just what does "Native BACnet" mean??????????????????????

[kontrolphreak]

Just what does "Native BACnet" mean??????????????????????

It means that each controller uses the BACnet protocol as a communication standard at the controller level.

[leaflying]

Although MS/TP supports master/slave, all the controllers I've seen are master type, meaning they are all peer-to-peer.

Does someone actually know some MS/TP slave controllers?

[asdf;ljk]

Just what does "Native BACnet" mean??????????????????????

It means that each controller uses the BACnet protocol as a communication standard at the controller level.


I wish people would stop using that "Native BACnet" phrase. A controller either communicates via BACnet according to the standard or it doesn't. Period. There should be no need for the "Native" adjective. It's not even a term used in the BACnet standard. I believe it to be a phrase that people starting using in order to prevent system integrators and the like from going after top-to-bottom BACnet-specified projects with non-BACnet controllers and a BACnet gateway (like a Fieldserver box). While that is certainly an admirable intent, the phrase is very confusing.

You don't hear people using the phrase "Native LON" much.

[kontrolphreak]

It is like a county using a native language instead of a second language and an interpretor to talk to others. An example in LON would be the t.a.c. freely programmable controller that uses a Vista server, Vista points and Menta and "also speaks" limited LON SNVT's (limited to 15 nvo / 15 nvi unless you use a "supervisory" controller).

[asdf;ljk]

It is like a county using a native language instead of a second language and an interpretor to talk to others. An example in LON would be the t.a.c. freely programmable controller that uses a Vista server, Vista points and Menta and "also speaks" limited LON SNVT's (limited to 15 nvo / 15 nvi unless you use a "supervisory" controller).

Yeah, but whether or not a controller uses BACnet as its primary language should not affect its peer-to-peer capability, as was implied in a previous post. The BACnet BIBB's that a controller supports should not be dependent on whether it speaks BACnet as its primary (native) or secondary language.

By the way, I appreciated your post regarding your real-life experience with doing peer-to-peer BACnet integrations with different mfg controllers.

Although I'm not a champion of the BACnet protocol by any means (as some other user would claim me to be), I was getting a little frustrated at the comments from other users about BACnet peer-to-peer not being possible. It certainly is, as evidenced by your post.

[kontrolphreak]

On the other end of the spectrum I was working for an ALC dealer in 2001 when WebCTRL first came out and we did a job with ALC Exec 6 WebCTRL modules in the facility and a ALC Supervision packaged central plant that couldn't communicate to each other. :confused: I would guess this has been addressed now, but I haven't worked on the ALC side of things for the last 6 years.
I have done a successful ALC Supervison packaged central plant to a Trane system years ago as well. :D

[sysint]

.... Just write some code using the BACnet points in the device and we where good to go) are on MS/TP networks under individual Delta System Managers (DSM-RTR) that are connected at the BACnet IP level. ORCAview being the front end.
kontrol out Can you explain that better?

Yes, you need each individual controllers software to set it up, but once set up they can all be seen and controlled by any of the front ends or controllers.

You make it seem like you have an independent or common network tool.
You make it seem like all the variables are accessible by your front end.
You also make it seem like a bacnet MSTP can manage it's own traffic properly.

I find that hard to believe.

Also, if I've got a bunch of ALC VAV's I can easily have an Alerton programmable running the AHU and then later add a few Andover VAV's and not have to do any rewriting and they intercommunicate?

[shylock]

You make it seem like you have an independent or common network tool.
There is no common network tool in BACnet, because there is no separate binding process. Binding is just a part of programming.
For example, for Alerton you write in VisualLogic: 15:AI-1==>AV-2, which means "transfer analog input 1 in controller with address 15 to local controller' analog value (=variable) 2". After that Alerton controller does not care, if #15 is ALC, Andover or something else. It will work.


You make it seem like all the variables are accessible by your front end.
I see no way, how to "hide" variables. Front-end just requests Binary/Analog/Multistate Inputs/Outputs/Values and if controller has them, it will send them back.


You also make it seem like a bacnet MSTP can manage it's own traffic properly.
Could you explain this?

[kontrolphreak]

Can you explain that better?

Yes, you need each individual controllers software to set it up, but once set up they can all be seen and controlled by any of the front ends or controllers.

You make it seem like you have an independent or common network tool. Most BACnet OWS are "common network tools" if the device/controller is using the BACnet protocol on the same media (MS/TP, IP, etc.) at the same baud rate the OWS will be able to view/control BACnet points in the device. I haven't seen a OWS that can create BACnet points in another vendors controller. As I mentioned you will still need the vendor specific software to add/delete points or make programming changes in the device (sequence changes, adding another output etc.), but as long as the setpoints, outputs, schedules, etc. are BACnet points you will be able to change setpoints, control outputs, edit schedules etc.
You make it seem like all the variables are accessible by your front end. As long as they are BACnet points you will be able to see all of them at the OWS.
You also make it seem like a bacnet MSTP can manage it's own traffic properly. As long as all the controllers are uniquely addressed, communicating at the same baud rate and the rules of RS-485 are followed (lenght of buss, number of allowable controllers etc.) it manages it's own traffic. Some systems don't need any system data base changes as BACnet devices are discovered automatically (i.e. I don't need to go into my LNS or Vista database and tell it that a controller has been added and link any variables for control/display).

I find that hard to believe. Pay for your ticket to Vegas and I'll take you to some of the above mentioned projects to show you that it can and is done everyday.

Also, if I've got a bunch of ALC VAV's I can easily have an Alerton programmable running the AHU and then later add a few Andover VAV's and not have to do any rewriting and they intercommunicate? Once again not a good example as most ALC installations are ARCnet (the only BACnet vendor I know of that does this :confused: ) they can be configured as MS/TP but I haven't seen it done that often. But you could definitely add BACnet Andover VAV controllers to a BACtalk Alerton MS/TP trunk as long as the parameters that I have mentioned in my previous posts are set up and followed. Like I said in an earlier post when you talk about ALC (communicating on an ARC156 network) and other BACnet (communicating on a MS/TP network) vendors it is like you wanting to place a LON FT-10 device on a LON powerline carrier buss (same protocol different medias). And as I mentioned previously the older generation of ALC VAV controller were basically I/O cards on a sub-network ( I don't know the media or protocol) which programs resided in a UNI that resided on a ARCnet network, the new VAV controllers seem to reside on their ARC156 network or if configured (which as I said I haven't seen on any of the ALC projects I've been involved with) a MS/TP network.
If you want the new Andover VAV controllers to reset the DAT of the Alerton controlled AHU you would have to either reprogram the Alerton controller (with Alerton software) to look at the new Andover VAV controllers or have one of the Andover VAV boxes directly control the Alerton DAT setpoint and have it look at the other Alerton and Andover VAV controllers and do some type of logic (hi/lo select, average, load etc.).

My replies to the above are in bold italics.

kontrol out

[kontrolphreak]

Like shylock mentioned all you have to do is define the point that you want to control and what you want it to do in your code/logic/program and it will function.

VFD example

ABB VFD address 1001
Start/Stop variable = BV1
Speed variable = AV3
Status variable = BV13

BACnet controller address 2002
Weekly schedule = WS1
Static pressure PID = CON1

So in GCL (Delta Controls programming language) or CBAS (Reliable Controls programming language) your program would look something like this (I'm not a programmer so forgive my hack job at writing code):

IF 2002.WS1 IS ON THEN START 1001.BV1
ELSE STOP 1001.BV1
IF 1001.BV13 IS ON THEN 2002.CON1 = 1001.AV3
ELSE 1001.AV3=0

As you can see not that hard, the input for the duct static pressure and setpoint could reside in either the Delta controller or another BACnet device. With Delta and Reliable the points can either be viewed as the BACnet object identifier (2002.WS1) or that objects descriptor/name (AHU-1 Schedule) for ease of troubleshooting/reading code.
As shylock mentioned the program doesn't care who manufactured device 1001, as long as it can communicate to the device it can control/view/adjust the BACnet object/point.

kontrol out

[kontrolphreak]

I forgot to mention that 80% of our projects also have BACnet to MODbus integration (Veris Intercept power meters). We have a project that we will be starting up over summer that has 40+ GE power meters that will require BACnet to MODbus integration, that one should be fun being our first integration to the GE system. 160+ ground source heat pumps, 20+ make up air units, 50+ exhaust fans, some general miscellaneous control points and a central plant (pumps and a cooling tower) for the ground source wells all on a Delta Controls network with the GE MODbus integration. All this residing under a Tridium AX front end for alarming/trending/scheduling/etc. If I survive that one I'll post the results.

kontrol out

[sysint]

So-- by getting it straight it's down to this for me:


Binding is easier than writing programming for each datapoint. I wonder how you know the value ranges (ie if it's static pressure how do you know where the decimal point goes) Sounds like you still need documentation from the vendor.

No common Network tool so you still need OEM vendor to setup equipment.

MSTP is not as robust as a Lonworks fieldbus. Sounds like alot of user required setup as well.


Other than that it sounds like bacnet stuff is improving. Although, the bacnet message board has one guy in particular that complains regularly about the OEM's not providing consistency and enough conventionality for independant bacnet OWS. Plus, not too long ago on the same board there was some debate on how to present a light switch with dimming.

Why is that based on your commentary (do you think)?

[kontrolphreak]

sysint,
Could you please post a link to the BACnet message boards (sounds like a valuble resource that I could use).
Thanks.

kontrol out

[sysint]

It's the board on the bacnet site from Cornell. Go there and sign up.
Most of the time it's mundane but every once and awhile topics get going.

[nikko]

LON can be written into an application that's proprietary. Phast home automation equipmnt have done it for years - but they've never claimed to be open and use the technology because it works and suits their purpose. Just because it sayd LON doesn't mean it's automatically going to talk to any other LON widget out there.

BUT - as has been stated here before, if you have three requirements for your controllers and all controllers you choose meet these three, they'll interoperate:

1) LON
2) Lon Mark certified devices
3) LNS as a network database.

And #3 isn't even as important these days with Tridium getting better at handling LON devices.

As with all technology, it's up to you to do your homework. To have a blanket assumption that just because a device says LON it's going to work with all others is foolish. But it's sure a lot easier with LON than with any other technology out there today.

Nikko

[sysint]

Sounds like bacnet is really getting easy....

[nikko]

I think it's getting easier (which is a good thing), I think it's still a long ways from easy and it will never get to where LON is.

Nikko

[sysint]

I think it's getting easier (which is a good thing), I think it's still a long ways from easy and it will never get to where LON is.

Nikko

Nope--- you got it all wrong according to Kontrol-: "Pay for your ticket to Vegas and I'll take you to some of the above mentioned projects to show you that it can and is done everyday."

[shylock]

Plus, not too long ago on the same board there was some debate on how to present a light switch with dimming.

Not so long ago, I've seen some debate here on how to present simple binary value in LON (because snvt_switch is unnecessary complicated)...

Maybe there are things, that could be simple in LON and not so simple in BACnet (though I don't understand, why light dimmer is a problem -- it's just BV & AV). There are things, that are opposite (e.g. schedules -- LON should have something like BACnet' ones).

[kontrolphreak]

Quote:
Originally Posted by nikko View Post
I think it's getting easier (which is a good thing), I think it's still a long ways from easy and it will never get to where LON is.

Nikko
Nope--- you got it all wrong according to Kontrol-: "Pay for your ticket to Vegas and I'll take you to some of the above mentioned projects to show you that it can and is done everyday."

sysint,

Please don't be putting words in my mouth. I don't mention if it is hard or easy only that it can be and is done everyday. We find it easy with the products we use, another vendor might have all types of headaches with their system.
The offer stands, you want to pay for your ticket here, I'll even pick you up at the airport and drive you around town to the different projects.

kontrol out

[sysint]

Kontrol- relax--- it's an inside joke to Nikko. However, if you are doing it everyday, it's definitely getting easier because not too long ago it was near impossible to integrate on the fieldbus level with bacnet.

If I go to Vegas in the near future I wouldn't mind taking you up on looking into some of your sites. Thanks for the offer.

[kontrolphreak]

Sorry to jump all over your post, but it has been a stressfull Monday.
Integration is the least of my problems, babysitting our installers and project managers consumes about 60% of my time and then my boss b*tches about submittals/shop drawings and start-up/programming that doesn't get done.
I need another 6 week vacation already and it's only the second week of the year, man I can't wait for October/November and the Rugby World Cup in France.

kontrol out

[crab master]

Kontrolphreak - I'll might have to hit you up on that offer too. I am planning on going to Vegas for the Sportsmen's show next January. :D

[leaflying]

That's a very good offer. Does it have an expire date? :D



The offer stands, you want to pay for your ticket here, I'll even pick you up at the airport and drive you around town to the different projects.
kontrol out

[kontrolphreak]

Well, kinda. I'm looking at moving back to Australia if the yahoos I work for don't get off their *rse and get an acceptable contract in front of me in the next 2 months.

Crab Man,
You looking to come done to the SHOT show? I've made it every year I've been here but this year it is in Florida. How are things going up there? We shelved the t.a.c. Vista product (had a lot of issues, the final straw was when a customer wanted their web based solution and the factory told us to send the workstation to Texas :mad: so they could load / set it up). Using their Continuum line now (as well as a couple other BACnet lines). If you still have my number give me a call.

kontrol out

[crab master]

Yeah I plan on going to the shot show. Things are going good for the most part other than I was supposed to leave on vacation today, it was scheduled for Friday 1/5 and due to all the outstanding loose ends I won't be leaving till tomorrow, at least I hope! :mad: That's too bad about your experience with the Vista line, about all I've done is web based solutions with the xenta 511/527, but then most of our networks are under 60 controllers. We've got a school job coming up that will exceed that and we will be doing the workstation with webstation so I'll get more into that end of things. Anyway I'll give you a call in the near future and good to hear from you!

[drafty888]

Show me how to swap an Alerton VAV with a ALC VAV controller....can't do it. Bad Example. True, Alerton VAV reside on a MS/TP network and ALC resides on an ARC156 network now (just like a LON device on a FT-10 could not replace a LON device on a power line carrier network) and the old ALC VAV controllers resided under a UNI (resides on an ARC156 network) which was the "brains" where the program for the VAV resided.

[Edited by sysint on 10-31-2006 at 08:57 PM]
My comments to the above are in bold italics.

kontrol out[/B][/I].

kontrol out

To clarify, all ALC controllers can reside on *either* an ARC156 bus OR an MS/TP bus. To reside on an MS/TP bus it's as simple as moving a jumper on the ALC controller. So yes, you certainly could put an ALC controller on a bus segment with Alerton controllers.

ARC156 is the most publicized method because A) it's very fast, and B) ALC controllers all have an ARC156 co-processor to handle communications, freeing up the main CPU for speedier algorithm processing.

Drafty888

[nikko]

To clarify, ......
ARC156 is the most publicized method because A) it's very fast, and B) ALC controllers all have an ARC156 co-processor to handle communications, freeing up the main CPU for speedier algorithm processing.
Drafty888

SO ALC advertises itself as open BACnet and spews the rhetoric and toots the marketing horn and leads the self righteous BACNeteers into committee after committee , but sure enough it's quicker/faster/friendlier AND cheaper to install their stuff as proprietary. Hmmm...

There's nothing like being committed to Open Systems. You GO BACnet!

Nikko

[drafty888]

SO ALC advertises itself as open BACnet and spews the rhetoric and toots the marketing horn and leads the self righteous BACNeteers into committee after committee , but sure enough it's quicker/faster/friendlier AND cheaper to install their stuff as proprietary. Hmmm...

There's nothing like being committed to Open Systems. You GO BACnet!

Nikko

I wouldn't have any problem being associated with a "quicker/faster/friendlier" product, "open" or not because perhaps to 80-90% of customers in my area, that plus good vendor support are the two keys to the kingdom...

drafty888

[leaflying]

ARCnet IS part of BACnet standard. It's not common simply because of its cost.

[kontrolphreak]

To clarify, all ALC controllers can reside on *either* an ARC156 bus OR an MS/TP bus. To reside on an MS/TP bus it's as simple as moving a jumper on the ALC controller. So yes, you certainly could put an ALC controller on a bus segment with Alerton controllers.

ARC156 is the most publicized method because A) it's very fast, and B) ALC controllers all have an ARC156 co-processor to handle communications, freeing up the main CPU for speedier algorithm processing.

Drafty888

The question was if you could put a Alerton VAV on an ALC network, not the otherway round and as I tried to explian this wouldn't work in most ALC installations as ever one I have seen is running on an ARC156 network and most of the older VAV networks are U-net (protocol, media and buad rate unknown to me). Yes the newer ALC boards can run on an MS/TP network, but this seems to be a one way replacement to install ALC boards on another vendors MS/TP network.

Like I also explained and it was confirmed to me again this weekend when I visited with the ALC dealer I used to work for in California, Exec B controllers (none WebCTRL) can't reside on a EXEC 6 network (WebCTRL). Both speak BACnet and reside on ARC156 networks.

I Like ALC and lean towards BACnet solutions, but they all (BACnet, Lon, Propriety) have issues, quirks and limitations. Find what works for you and go with.

kontrol out

[control$]

The U-Line is bacnet-MS/TP. The move by ALC to make the unitary controls both Arcnet/MSTP was smart. It's faster then the older U-line and of course slower lon type controls.

[control$]

"Like I also explained and it was confirmed to me again this weekend when I visited with the ALC dealer I used to work for in California, Exec B controllers (none WebCTRL) can't reside on a EXEC 6 network (WebCTRL). Both speak BACnet and reside on ARC156 networks."

Not a correct statement.
Exec B = WebCTRL Exec 6 = Supervison.
Currently you can put an Exec B module on a Exec 6 system.

You would just need to add a LGR.

[kontrolphreak]

control$

You are correct on the different firmwares connected at the IP level is possible, what I was trying to convey is that they couldn't reside on the same ARCnet or MS/TP network.

Are you positive about Unet being BACnet MS/TP? All my experience with them were that they were I/O boards and all the programming resided in the UNI (which used to only reside on a ARC156 network, but I guess now can either reside on a ARC156 or MS/TP network). If you were to add another BACnet MS/TP controller on the Unet line, you are telling me that this controller would show up in Supervision or WebCTRL (after being added with either SiteBuilber or EDB)? Would you have to create the points for the said controller in one of the FB's in the UNI?

kontrol out

[control$]

Exec 6 and Exec B can reside on the same Arcnet wire. But you need to add a LGR (MELGR) to make it happen. (Guess it's cheating but it works).

U-net=MS/TP. A UNI is a Arcnet to MS/TP router. The program does reside in the UNI for U-line controls. But the UNI is more flexable then that. You can just as easy add a (ZN,SE,LGR,LGR,MELGR, exc.) or third party (Season Four, Petra, Deschamps, Liebert, exc.) to that same bus.
Example. A bus with (1) UNI32 with say (30) u-line controls. You can then add another MS/TP control (ZN,SE,LGR,LGE,MELGR) or third party to that same wire.