TAC Info

[joey791]

Im going look at a job tommorrow that we are taking over, the installing contractor refuses to give any info whatsoever, does anyone have a default password for a TAC system, any help would be greatly appreciated.

[digital freq]

Yeah, PM me or leave an email address. I'll send em to ya.
I think it might go against the rules to post em here.

[joey791]

digital, I shot boss an email to release my email to you


I really appreciate the help

[sysint]

Use discover and upload the database.

[joey791]

Sys havent been to the job yet, there is a chance there is no computer onsite, but only a keypad interface, wont be sure until tommorrow

[jimmyj]

"Discover" and prey! alot!

[sysint]

.... at least you can do it.

[jimmyj]

If it were BACnet the lack of an LNS DB would not be an issue. This is the main flaw with an LNS system, it is database reliant. Where BACnet uses no such DB. No you cant re-configure the BACnet devices of manufacture-X unless you have their tool BUT if you "DISCOVER" an LNS DB even echelon states this is not a flawless operation with the potential to break bindings. So when your done and you think you are god and launch your plug-in, you better pray! Did we not just talk about how TAC uses some sort of AUTO-BIND funtion that you stated does NOT show up in LNS? What do you think would happen with these and devices like this if you did the DISCOVER and then recomissioned?

[joey791]

Only keypad on site, we were able to guess the password on it and get in, thanks for all the help

[sysint]

Jimmy - some interesting points.

However, is the potential problem with the TAC devices the fault of LNS or wouldn't you agree it's more the fault of the TAC implementation?

And, on the possibility of the bindings being lost, really, how hard would it be to figure it all out when you have all the devices and the variables?

About the plugins, are you saying you won't be able to realize a binding or not?

A deployed LNS system is not database reliant. You can pull the database and walk away. You also don't need any GC's or BCU's with databases. BACnet by contrast is dependant on not only multiple databases and setup software(s), but also the associated hardware as "binding" isn't really possible directly device to device. There is even questions as to whether multiple manufacturers devices can reside on the same wire.

[jimmyj]

No the lon system does not need it to operate BUT the LNS front end sure does. And as for the plug-in launching the plug-in aside even after you do the Discovery I assume LNS requires you to do a recomission of the network, so once this step is done the only bindings left are the ones LM "DISCOVERED" Where does a BACnet system use a DB? It is a read, write, master, slave service based system. All devices have a unique device number and on any one individual segment a node number.

[sysint]

Originally posted by jimmyj
No the lon system does not need it to operate BUT the LNS front end sure does. Entirely incorrect. See information on the ilon100.


Where does a BACnet system use a DB? It is a read, write, master, slave service based system. All devices have a unique device number and on any one individual segment a node number. Each individual subsystem has a database setup tool. Many GC's have a database. Are you saying your BCU doesn't? Hence some of the problems with BACnet on the address restrictions and having multiple vendors on the same wire. Are you saying that that LON method of addressing is inferior?

Then you probably don't like MAC addressing either.

LNS allows for site database creation that can be passed to other applications that everything about the particular site with multiple vendors products.

No other control system has that ability.

[jimmyj]

Well you are correct the iLon100 or 1000 has no DB BUT to configure it you sure need an LNS based tool and for an LNS based tool you need a LNS DB!
As for a BACnet global controler I would not call it a DB as I would call it the controlers application. Does not a Lon router have a routing table? Are we to call that a DB?

As for the addressing scheme of Lon, I think its great, the fact that you dont have to set a dip swith or rotory sw for node address is great, logical routing of packets ect. however I would like to see a one time Echelon added royalty fee to the initial cost of the neuron chip to do away with this whole credit business.

[jimmyj]

To correct myself the Trane BCU is a gateway and I would expect to call it's application a DB as I would call a Field Server's application a DB.
However I would not call an application in a BACnet node that uses the same protocol but resides on two subnets like 802.3 and MS/TP a DB. I guess this would be technically a Bridge, like an iLon600?

[sysint]

Well you are correct the iLon100 or 1000 has no DB BUT to configure it you sure need an LNS based tool and for an LNS based tool you need a LNS DB!

Correct. And that's anyones software you like to use with that LNS database. Circon, Distech, Honeywell, etc......

How about that Trane database? - Can I bring it up in Circon, Distech, Honeywell or anyone elses software? Answer to that is simple... NO.

How about configuring any BACnet Alerton, Andover, Delta or ALC products? Not only may they not work together, they each need their own software tools.

So, that LNS database you keep harping about is a great idea compared to handling multiple software, devices with no interoperability or a measure of interchangeability. You simply send it off to the next application.

I set up sites with different manufacturers products for power, lighting, CCTV, HVAC and access controls and everything speaks the same language with no problems. And, whenever I feel like changing out the "front end" I simply find a package I like and pass the LNS database. No issues.

BACnet companies, Trane and "Waterfall" Frameworks are all simply dead ends of price gouging proprietary solution.

I'm done with that.

[jimmyj]

I'm done too!

[jimmyj]

I guess my point is this, when going to a new building with an exiting DDC system if it is Lon and has an existing DB on site on the local work station, you are usually ok. If there is no work station and the owner has no such LNS DB then you must "Discover" the DB and then most liklly re-work it! After that it's all yours.

If it is a BACnet system, then you choose the work station flavor of your choice, AL, Alerton, Andover, Reliable, Tridium ect. and you can add your own BACnet subnet and bring the existing ones in using the Who is service. If its Tridium you are using then use Lon when you add to the facility.

No you cant change the BACnet devices on the existing system or re-configure them without there tool, but you did not have to re-work anything. So leave it alone! but most of all explain it to the owner! Am I Harping now or Tooting?

[sysint]

Gastrointestinal problems aside, you still have the OEM connection with the OEM problems so the customer really has nothing, no freedom. Only subsystem add-ons.

Add an access controller to that existing installation and you have to add a whole new subsystem rather than simply installing another controller to the existing wire.

Or, maybe you don't like your existing TAC vav's and want to replace them perodically with Distech. Can't do that with the BACnetter solution.

[smokies]

One true problem with going into an existing BACnet system is that you can see points but not configuration or the programming of the other manufacturers stuff. If you send a data point to another manufacturer you assume what that point is going to used for. The person that programmed or configured that other BACnet controller may have a different way of doing things and throws in some limits or custom crap that you don't know about. At least with the LON theory I can see and/or change the other Manufacturers programming or configuration if I need to. I hate relying on other contractors.

Don't get me wrong jimmyj I really like Trane controls.I like the way they dummy up alot of things. You also have to like their applications like area control, CPC, VAS, etc. I've never lost a database and they way their BCU makes my life easier in alot of issues. All the LON issues we have had have been easily resolved, mainly because of the good support qwe get from St. Paul. Webserver - never had a problem, its easy and the graphics are pretty flexible and look good once you get use the the little corks. I work for an applied system contractor and put in alot of controls. I hope to continue to install and program Trane controls for many years to come.

However that being said we also are looking some LON LNS lines because we are seeing it so much. It gives opportuites because if we learn one we can service many. I'm slowly learning LNS LON and I its pretty powerful if installed properly. With some good teachers like LB outthere I'll beable to amake sure I'm installing it properly.

[jimmyj]

IMO, It seems that BACnet is best suited for OEM manufacturers that have application spacific and well documented control routines, like in RTU's and Chillers ect. That way you need no DB when networking them together and need not comission them just set there address and such, where Lon is best suited for the main network and its areas. One point I would like to add is that the much disscussed "Discover" funtion is a LonMaker thing, I have both HW's CARE-5.0 and Distec's LonWatcher and both of them can not do a network "discover".