HVAC-Talk: Heating, Air & Refrigeration Discussion banner
Cancel
Create thread New Forums

JC NAE LonWorks integration issue

Jump to Latest
21 - 40 of 60 Posts
#21 · (Edited)
phantomtech said:
As I stated if you go back and review all posts by Freddy-b about metasy I think other people will come to the same conclusion.

Yes I have seen you try to help on occasion between bashings.
I have even helped you in the past.

But i think you are not up to date on metasys since you left.

Many systems have issues and I think it would be better if we just tried to help each other.

I have worked on many different systems. Like some hate some but in the end they do what they were designed to do.

Any system is only as good as the programmer.

By the time I login to see if there is some help I can provide on metasys the posts have turned into the Freddy and Ninax Show and I have better things to do.
Click to expand...
That may be the case. But I have seen questions go unanswered for days and as soon as the "Freddy and Ninax show" starts, only then do you guys come out of the woodwork and try to help.

Also, I still see plenty NAE's to know that they have not been improved as dramatically as you guys make it out to be.

I don't rip out any other product that is 4 years old or less for not performing. The local branch guys are a joke, and from what I see in this forum ..its not just a local phenomenon.
 
Save
Like Like
#22 ·
phantomtech said:
I have worked on many different systems. Like some hate some but in the end they do what they were designed to do.
Click to expand...
This argument is getting old.
Let me put it this way once again.
Why pay more for a KIA than you would a Benz. But hey they both do what they were designed to do. Right?
 
Save
Like Like
#23 ·
Please someone correct me if i am wrong. The MCL tool and LN Builder can Bind from one Lon Controller to another with no problem. The problem project that JeffEW is referring to is that the sensors are on the N2 bus and the Lon Controllers that need the readings are of course on the Lon bus. The MCL Tool only looks at the NAE as a node only. There is no NV point info from the N2 bus?? The only NVs available from the NAE is : nvoTimeSet, nvoESUAstatus, nviStatus, nviAlarm. therfore there is no way I know of to BIND a point from the N2 trunk to the Lon Trunk. If there is let me know????
JCI explained to me that the way the NAE broadcasts to the Lon trunk is with a polled point not a bound point.
 
#29 ·
The one LON NAE job I worked on was a nightmare. It consisted of 4 NAEs and approximately 350 controllers. Granted we were working with an earlier version of MSEA which had some serious bugs in the LON side. I don't recommend it as a good or even OK LON solution but that's not the point of this post is it?

As was stated earlier, MCL-Tool is LNS based but the NAE is not. The LON network needs to be setup with MCL-Tool, Lonmaker, or some other LNS based network management tool to commission all the nodes, do any bindings on the LON network between nodes, etc. The NAE is just another node on the system. If the point in question resides on the N2 bus, then the NAE does not create an NV that can be bound to the target nvi in the traditional way through MCL-Tool or Lonmaker. However, I would think that if you setup a global data share object or a CS object writing the intended value to the target nvi in the NAE and setup the refresh timers to be within the Max Receive Time, then the target device would see the value being re-written within the specified time frame and would not go null on you. It may or may not work, I have never tried it. The particular site I did, I did all my global sharing through MCL-Tool because there were so many problems with the NAEs doing it.

BTW, this would not be a problem in AX, it would just work....
 
#32 ·
You need to bring in the nvi from the LON device. The NAE should automatically bring it in as an AO if it does not you need to change the point type to AO. Try autodiscover on the insert field point for that device it may find it for you. Once you have the nvi mapped in it is just a matter of linking it. You can do this several ways. 1) Create a global outdoor air humidity point with the sensor on the N2 trunk as master then place all of the NVI you want under the slaves list. 2) Use LCT and bring the N2 sensor in as an input and each of the NVI as outputs then just link them up. You may have to play with timings to match the NVI but I have not had do anytime it did this. Use this a lot to share outdoor temp when we have a majority N2 job and just need to integrate to several LON devices on the job. It does work that I promise you.
 
#33 ·
Dave thanks for the reply. I did transfer the point as a global share. I did not however play with timing. I believe the global point refresh time for the N2 side is default at 2min. The Lon point has the refresh set at 0 sec. The Equip Manu. told me the heartbeat on his side of the Lon picture is set for 10 min. There is a nvi point as well as a nvo point that is echoed from the nvi. As I send the value down to the nvi point I see no change on the nvo.
The equip manu. tells me it has to be a bound point. I dont think the NAE actually binds the point.

Just thought I mention this is not my first NAE to Lon integration. I have been successful in the past. See my previous post.

http://hvac-talk.com/vbb/showthread.php?t=172497&highlight=humidifier
 
#34 ·
If I understand you right then the nvi is not internally bound to the nvo on the controller itself. If that is the case then you could try to bind it from LN-Builder.
 
#35 ·
I am not sure what you need the NVO for. If you are just telling the LON device what the humidity is then no real reason for the nvo if the nvi is accepting it then the controller should also be accepting it. The only reason for the use of NVO would be if you want to again map that humidity to another device on the LON trunks nvi. If the device is accepting the sensor and working under control than it is not an issue.
 
#37 ·
You could use LN builder and bind the two points just select the niv choose connect and then target the nvo. This will bind the two points and you should see the same data at the NAE level on both points. The real problem is that should should be happening in the controller itself unless the manufacturer does not actually bind the points inside the controllers logic. Do you have a way to test and see if the device is actually getting the proper data on the nvi other than the nvo. For example the operation should show it input is correct. If it is not getting the data then the problem is that the point is not a true nvi as it should be. By the way I never intended to insult you or question you skills if that is how you took any of my earlier posts. Typically the manufacturer binds the same nvi and nvo points internally but seems this one does not.
 
#38 ·
No offence taken, only stating the fact that I have done it before with success and covered all the basic setup needs.
I have tested the device as much as possible with reading the product lit. It does not seem to be receiving the value. I also have been in contact with there programming personnel. I am not sure if they in fact have bound the point internally, but they are shipping me a new controller to be tested tommorrow. Not sure of the differences. I will post my results as I find them.
 
#40 ·
I was going to..

Actually, I was going to respond, but the topic got way of track. JeffEW only had 2 posts, and neither was asking about N2 anything.

No the NAE doesn't bind. You set up your network with any LNS based tool, add the NAE as a node (to get the right DSN), and then map the devices/points in using autodiscover/manual/point schedules. Yes, you need the resource files because it doesn't know about the LonWorks Types and Import folders - it's not LNS based and doesn't need an LNS database.

In any case, it's a glorified web server (Display+iLON1000). The NAE is not a tool, it's a device just like a thermostat as far as LON goes. Can a thermostat do binding? No.

Whoever told JeffEW that it wouldn't work is just well....wrong. I do it every day, and whatever you do - do NOT do any type of 'bindings (Non-LNS type) through the LCT or internal to the NAE. That would make the operation of the system depend on the NAE being up. Can anyone says Delta 1000? Uggg

The point is to keep everything fully functional without a front-end/NAE/Tridium etc. We know how reliable IP is..

MCLTools: Dead product, but still available (not supported)
LNBuilder: Will do what you need - graphical programming for the programmables soon to be released.

JeffEW: Did you sort out your answer? For future reference: If your building system can be installed and commissioned using an LNS database, then it'll work in the NAE. The NAE can only belong on one domain, multiple domains need to go through multiple NAEs back to the ADX front-end.

poochz
 
Save
Like Like
21 - 40 of 60 Posts
You have insufficient privileges to reply here.
About this Discussion
59 Replies
17 Participants
Last post:
beer30
HVAC-Talk: Heating, Air & Refrigeration Discussion
posts
5M
members
275K
Since
2000
The #1 HVACR Community
Full Forum Listing
Explore Our Forums
AOP Residential HVAC/Refrigeration(Beenthere Zone) General Discussion Tech to Tech Chat - Residential Controls Refrigeration & Ice Making