TAC Help

[amigo]

I need to integrate with some Aaon AHU units that have:
xenta 401
xenta 302

Now,
1.I think I need Menta to program/modify these units, is this right?
2. Can Menta be lunched as an LNS plugin?
3. If it is a standalone software, can anyone buy Menta, or do I need to be authorized dealer?
4. Menta is what is used to construct the XIF for Xenta modules, is this correct?
5. Can anyone share any user guides?
6. What is used to configure Xenta OP? or does it get code from xenta 401/302 automatically.

Thanks.

[Freeze Stat]

http://www.tac.se/docnet/

Try this link for documentation. You will need the Menta to program the 300/400 series, and to build the menus for the OP. Should be able to purchase through TAC. I haven't worked with the Aaon OEM controllers. I assumed they were shipping fully programmed. I am not aware of a Menta plug-in, XIFs are generated in Menta.

[crab master]

When you say "integrate with Aon units" are you saying a contractor prior to you installed the devices or was it shipped like that from the factory? The reason I ask is depending on the type of network that was used and programming you may be able to "integrate" with the existing system with the LNS database. If those 300 and 400 series controllers are mainly passing SNVTS to communicate you should be able to use the existing setup to add VAV's or other Lon controllers without getting into Menta or Vista. The only thing is that if Vista is the HMI I am pretty sure you won't see the new data. My understanding is there is a retail price to customers through TAC that want to buy direct. Call them and ask. Also the 300 series and 401 are LonMark certified.

http://www.lonmark.org/products/prod_search.cfm
scroll down to plant controllers

http://www2.tac.com/Navigate?node=1442
some more TAC info

[amigo]

Thanks guys.
Aaon units are new and being shipped with OEM controls. I assume they will be fully programmed at the factory.
I guess now I need to ask the supplier for Xifs to see what they are exposing and go from there.

Docs link is very helpful.

[jimmyj]

What Lon tool are you using? You should be able to create your devices and then "get service pin" and then "upload the XIF and the current config from the device. Then download the device and the only thing changed in the devices current config is your subnet/node configuration and any bindings you added (the factory has no bindings configured as most RTU's are stand alone), yes/no/maybe?

[amigo]

Interesting comments jj. I probably will use a combination of tools. Lonmaker, then circon's VI or Distech's Lonwatcher 3 if it comes out in time.
Now from the brief run through I did on the user guides, it seems the I/O expansion modules (which supplier says will be used on these RTUs) for xenta 300/400 sit on the comm bus like any other node and menta and OP make bindings to these to make it all work. So may next question is:
1. When I want to put these nodes in my database and the managment tool (Lonmaker) comes along after Menta has made these bindings and changes the subnet/node addresses how do expansion cards and main modules and OP all recover from this situation. Do I have to make the bindings again? Or am I seeing this all wrong?

[sysint]

Amigo- the expansion I/O's on the programmables will not show in the LNS database as devices.. From what I understand they are on the LON and that's about it. Whether or not you can upload the XIF and get to them as part of the main controller is another story. -I'll ask around.

I did load up the plugins for the rtu control into a LNS database with no problems so with the ASC's you should be good.

[jimmyj]

Hey Sys, Amigo,
What Lon mechinisum would allow the I/O modules to operate on a Lon bus with no chance of a Subnet node ID conflict?

Amigo,
There is an Echelon doc for "discovering" an existing LNS or otherwise Lon network and it's bindings with LonMaker. BUT, the document states it is not flawless and "most" bindings will be discovered. Soooo, I would be very interested to know how you make out on this one.
Your senario is by definition the type of integration hurtles we will face more and more.

[sysint]

LON is a full 7 layer OSI protocol.

I've run API and LNS together (others have too - access control).

Anyway - we aren't talking BACnet here, LON is a full 7 layer OSI.

[keyser_soze]

The number of layers is irrelevant, as the OSI model is simply that: a model of a network stack.

The number of layers has no bearing on interoperability or technological superiority.

For example, TCP/IP is typically described with 4 layers, and I would dare say it is the most interoperable networking protocol on the planet, and kicks LonTalk's ass in terms of performance.

[jimmyj]

Sys,
If you are refering to "foreign frame" or "building management funtion" both reserved for manufacturer X to use the Lon to communicate on, would not the neuron chip STILL need a proper Domain/Subnet/Node number?

[jimmyj]

Unless they are using neuron ID addressing?

[sysint]

Originally posted by keyser_soze
The number of layers is irrelevant, as the OSI model is simply that: a model of a network stack.

The number of layers has no bearing on interoperability or technological superiority.

For example, TCP/IP is typically described with 4 layers, and I would dare say it is the most interoperable networking protocol on the planet, and kicks LonTalk's ass in terms of performance.

Disengenious at best.

TCP/IP by itself does no kicking of anything. Just like BACnet itself does no kicking of anything.

What about packet duplication, routing, and authentication?

Perhaps your talking about TCP/IP over Ethernet in terms of performance. Many things determine performance, so maybe you should investigate further. As far as network loading, a Lonworks network kicks Ethernet's butt as an Ethernet network is shot at 40% of capacity because of collisions. Lonworks is 94%.

I would say also in regards to Lonworks, what would stop someone from making a faster LON network than currently? Really nothing.

[keyser_soze]

A typical Ethernet network has 100 Mbit/sec capacity, so 40% capacity = 40 Mbit/sec

A typical LonTalk network has 78 kbit/sec capacity, so 94% capacity = 73.32 kbit/sec

Thats 545 times more capacity by my calculations.

I can also buy my 100 Mbit/sec Ethernet card for less than a PCLTA 20 or the Loytec equivalent.

[sysint]

Well - go with the 78K Forget about the 1.25 twisted. Not to mention further....

Anyway, why aren't there TCP/IP controllers everywhere? (as long as you are talking costs) Why are people using MS/TP BACnet anymore?

Try again.

What about packet duplication, routing, and authentication?



[Edited by sysint on 06-11-2005 at 05:30 PM]

[keyser_soze]

I believe wiring costs are more of an issue when it comes to running TCP/IP over Ethernet to each individual controller.

As well, my understanding is that BACnet MS/TP is just a glorified multidrop RS-484 system, which is dirt cheap to implement. (in my mind, it doesn't even really qualify as a networking protocol)

[keyser_soze]

What about packet duplication, routing, and authentication?

Packet duplication:

In TCP/IP this is handled by the TCP layer (although the IP layer is unreliable in this regard). TCP protects against data loss, data corruption, packet reordering and data duplication by adding checksums and sequence numbers to transmitted data and, on the receiving side, sending back packets that acknowledge the receipt of data.

Routing:

In TCP/IP it seems like companies like Cisco have this handled.

Authentication:

In TCP/IP authentication is typically handled at the application layer (e.g. like when you use a web page to manage your bank account).

[sysint]

Again Keyser, you aren't being straight.

There is no guaranteed mechanism that your messages get through via TCP/IP. Most often nobody cares as they simply hit "reload". Things are quite different in a control network.

A full TCP/IP implemenation in a controller is cost prohibitive. It isn't the wire. That's why Echelon came out with the Neuron and BACnet still uses MS/TP. It's really an inexpensive solution.

Although, we will see what IPng brings..

[keyser_soze]

You sir, are also not being straight.

There is also no guaranteed mechanism that your messages get through with LonTalk.

On a reasonably loaded network, messages get lost all the time, but it doesn't matter because most devices implement retries and some basic sanity checks at the application layer.

Yes, TCP/IP is still slightly more expensive to implement than LonTalk, but that will change.

And no, I never claimed that TCP/IP was appropriate for control networking.

I said that:

- the number of layers in the stack is irrelevant
- that TCP/IP is very interoperable
- I get a lot more bang for my buck in terms of performance

[amigo]

jj, there are LON mechanism/softwares that allow manual allocation of subnet and node address, and yes they are dangerous if you do not plan carefully. And when it comes to integrating with LNS, the job becomes rather tricky.
From what I have found/read so far all programmable TAC controllers implement such manual addressing for their expansion modules. So as long as there are expansion modules involved, integrating into an existing database seems not that easy.
If they are single controllers with no expansion cards then no problem.
sys, it is true that TAC recommends not to commission expansion modules with an LNS tool or anyother LON tool after they have been programmed because that breaks their custom bindings to the main controller. Not too user friendly for a real integration job.
I will know more when I actually do it.

[sysint]

Originally posted by keyser_soze
You sir, are also not being straight.

There is also no guaranteed mechanism that your messages get through with LonTalk. -you better do some more reading on it. Your response is incorrect. It's a primary reason that the newer trains have their brakes running LON. It's also the reason some fire manufacturers run LON in their product.

.....Yes, TCP/IP is still slightly more expensive to implement than LonTalk, but that will change.I've been hearing this for years...

And no, I never claimed that TCP/IP was appropriate for control networking. it is the "controls" forum.

I said that:
- the number of layers in the stack is irrelevant
- that TCP/IP is very interoperable
- I get a lot more bang for my buck in terms of performance

The layers in the stack are relevant. That's why MS/TP BACnet gets it's butt kicked by LON. TCP/IP is interoperable, and many people use it. However, I don't see where the "bang for the buck" is in control networks. Front ends are a different story.

My apologies Amigo - hope that TAC stuff goes well with you.

[jimmyj]

Amigo,
There is a device that can realy help in situations like this, it is the Loytec L-proxy and it allows sharing of data across domains and can be used to save address entries. I have not been able to configure it with LonWatcher, but I believe you can configure dynamic NV's in the device and then have them "POLL" for data from the source controller therfore saving an address entry in the source device. Not sure if this helps you though as you would still have to commision the source device. My thought was the TAC devices must have the same domain/subnet/node ID if they are all programmed on an assembly line, which brings up another point, are these devices designed from the factory to network together?

[amigo]

Thanks jj, I agree, L-Proxy is a nice device.
I was trying to avoid extra cost and setup time on this project but we will see.
And yeah apparently these TAC devices are setup to be networked, the quirky thing is that the main module like 401 assigns some manual addressing to its expansion I/O modules (this all happens by Menta from what I have read.)
so when LNS comes along and wants to assign automatic addressing then the fun starts.
another fun day in exciting life of an si.

[jomi]

By default TAC wiht his Menta tools uses no SVNT-s in communication between Xenta 401,302 CPU-s and I/O mudules but explicit messages.
I had connect LON analysator software to TAC system, no SNVT-s at all in any device was defined, only explicit messages are for communication.

[jd 07]

http://www.orioncontrols.com/ These are the factory installed controllers on AAon free software and easy set up.