Page 1 of 2 12 LastLast
Results 1 to 20 of 23

Thread: JCI N2-1 Network Pooling problems NEED HELP!!!

  1. #1
    Join Date
    Oct 2018
    Posts
    14
    Post Likes

    JCI N2-1 Network Pooling problems NEED HELP!!!

    Hi All,

    Looking for some help on a project that behind on.

    My company integrated to a JCI building to provide a front end for the customer, but we are running into polling issues on the N2-1 bus.

    The building has a few NAEs with a FC and a N2-1 bus on each. Since the integration the FC bus has been polling fine but the VAVs on the N2-1 bus will not update their points.

    When I look at the diagnostics tab for the N2-1 network, all the stats and metrics report zero, but I'm not sure if this means anything or not.

    Not sure where to continue troubleshooting from here, can someone provide some direction as to where to look next?

  2. #2
    Join Date
    May 2006
    Posts
    816
    Post Likes
    Quote Originally Posted by TylerAnderson74 View Post
    Hi All,

    Looking for some help on a project that behind on.

    My company integrated to a JCI building to provide a front end for the customer, but we are running into polling issues on the N2-1 bus.

    The building has a few NAEs with a FC and a N2-1 bus on each. Since the integration the FC bus has been polling fine but the VAVs on the N2-1 bus will not update their points.

    When I look at the diagnostics tab for the N2-1 network, all the stats and metrics report zero, but I'm not sure if this means anything or not.

    Not sure where to continue troubleshooting from here, can someone provide some direction as to where to look next?

    What version is the NAE's -- older firmware had issues with N2 updating.

    Transmits Per Minute -- represents how many N2 messages the NxE is sending out on the N2 trunk. In the N2 environment the NxE initiates all communications. The N2 devices are basically slave devices that answer when questioned. Doubling this number would provide a good estimate of the total number of N2 messages per minute. 1100 transmits per minute is the recommended maximum for a 9600 baud N2 trunk.

    HP Point Scan Time or Higher Priority Point Scan Time -- represents how long it takes the NxE to poll for updates for Mapper objects that have object engine signups in the NxE. The object engine will request signups for Mapper objects that have extensions like Alarm, COV Trend (0 sec. sample interval), Totalization or objects used in logic features like Interlocks, LCT, and Global Data shares for example. High Priority points are scanned 15 times more frequently than Low Priority polled objects. This value is how many seconds to make it completely through the list of HP Mapper objects. Depending on the number of objects on the HP list this value may be much lower (more than 15 times shorter) than the LP Point scan time. If you know how to or have the Snapshot focus tab (Expert Mode) enabled, it has an attribute exposed called Priority 1 Poll Items. This is how many objects are in the HP Point Scan List.

    LP Point Scan Time or Lower Priority Point Scan Time -- represents how long it takes to update all of the other N2 points that have Mapper objects. If there are a lot of N2 points mapped that fall into this group, the time can be quite large. As the name implies these points will be updated in between performing any of the Poll Scan, HP Point Scan, or Commands that the NxE needs to send out on the trunk. Again If you know how to or have the Snapshot focus tab (Expert Mode) enabled, it has an attribute exposed called Priority 2 Poll Items. This is how many objects are in the LP Point Scan List.

    Poll Scan Time is how long it takes to check and see if all the N2 devices are online. Every 4th message (worst case) will be a poll scan message, so this value will be dependent on the number of devices that must be scanned and the number of messages that need to be sent between poll messages. Poll Scan messages are only sent to the addresses the NxE has devices configured on. The scan starts at the lowest address and increments to the highest address. There are two different poll messages; an Online poll and Offline poll. Statistics are collected for the number of each type under the Statistics at the top of the Diagnostic tab. Offline Poll messages take 4 times longer to complete because they have to timeout. Any more than a few N2 devices that are mapped, but offline, can cause the Poll Scan Time to increase significantly. The reply from the N2 devices can indicate if the controller has COV notifications to pass along.

    Count is the number of N2 objects from this Trunk that have a Mapper object in the NxE. The total number of N2 points that need to be periodically checked so that the Mapper objects can be updated. In order for the NxE to maintain the expected performance, it is recommended this number not exceed 1000.

    Queue Used Curr is the number of command messages waiting to be transmitted by the NxE on the N2 Trunk. This number should remain below 3 for proper updating of the N2 Mapper objects. If this number is greater than 3, no Point Scans are being performed.

    Queue Used Max is the maximum number of messages that have been in the Queue since the Statistics were last cleared. This could be since the last reboot of the NxE or since the last clear statistics command was issued on the N2 trunk object. This number is more useful if the statistics are cleared and then latched after a known time interval; for example, if the statistics are cleared and then latched 10 minutes later. This attribute would provide the worst case during that 10 minutes. If the Queue Used Most and Queue Used Curr are the same number and greater then 3, the NxE is unable to successfully get messages out on to the trunk. This could likely be a physical issue with the trunk. Perhaps a controller has gone bad and is affecting the trunk electrically or maybe a broken/shorted wire on the trunk.

    Priority 1 Poll Items is the number of Points in the HP Point Scan List. As mentioned above under the HP Point Scan Time this is the number of N2 mapper objects that need to be updated most frequently.

    Priority 2 Poll Items is the number of Points in the LP Point Scan List. This value represents all the remaining N2 mapper objects not included in the HP Point Scan list. Typically this will be the larger of the Poll Items values. If N2 Points are mapped unnecessary this number can be quite large. Since these points already have a lower priority, a larger number of them simply takes longer to check all of them once.

  3. Likes JCIman, TylerAnderson74 liked this post.
  4. #3
    Join Date
    May 2006
    Posts
    816
    Post Likes
    Quote Originally Posted by integrator View Post
    What version is the NAE's -- older firmware had issues with N2 updating.

    Transmits Per Minute -- represents how many N2 messages the NxE is sending out on the N2 trunk. In the N2 environment the NxE initiates all communications. The N2 devices are basically slave devices that answer when questioned. Doubling this number would provide a good estimate of the total number of N2 messages per minute. 1100 transmits per minute is the recommended maximum for a 9600 baud N2 trunk.

    HP Point Scan Time or Higher Priority Point Scan Time -- represents how long it takes the NxE to poll for updates for Mapper objects that have object engine signups in the NxE. The object engine will request signups for Mapper objects that have extensions like Alarm, COV Trend (0 sec. sample interval), Totalization or objects used in logic features like Interlocks, LCT, and Global Data shares for example. High Priority points are scanned 15 times more frequently than Low Priority polled objects. This value is how many seconds to make it completely through the list of HP Mapper objects. Depending on the number of objects on the HP list this value may be much lower (more than 15 times shorter) than the LP Point scan time. If you know how to or have the Snapshot focus tab (Expert Mode) enabled, it has an attribute exposed called Priority 1 Poll Items. This is how many objects are in the HP Point Scan List.

    LP Point Scan Time or Lower Priority Point Scan Time -- represents how long it takes to update all of the other N2 points that have Mapper objects. If there are a lot of N2 points mapped that fall into this group, the time can be quite large. As the name implies these points will be updated in between performing any of the Poll Scan, HP Point Scan, or Commands that the NxE needs to send out on the trunk. Again If you know how to or have the Snapshot focus tab (Expert Mode) enabled, it has an attribute exposed called Priority 2 Poll Items. This is how many objects are in the LP Point Scan List.

    Poll Scan Time is how long it takes to check and see if all the N2 devices are online. Every 4th message (worst case) will be a poll scan message, so this value will be dependent on the number of devices that must be scanned and the number of messages that need to be sent between poll messages. Poll Scan messages are only sent to the addresses the NxE has devices configured on. The scan starts at the lowest address and increments to the highest address. There are two different poll messages; an Online poll and Offline poll. Statistics are collected for the number of each type under the Statistics at the top of the Diagnostic tab. Offline Poll messages take 4 times longer to complete because they have to timeout. Any more than a few N2 devices that are mapped, but offline, can cause the Poll Scan Time to increase significantly. The reply from the N2 devices can indicate if the controller has COV notifications to pass along.

    Count is the number of N2 objects from this Trunk that have a Mapper object in the NxE. The total number of N2 points that need to be periodically checked so that the Mapper objects can be updated. In order for the NxE to maintain the expected performance, it is recommended this number not exceed 1000.

    Queue Used Curr is the number of command messages waiting to be transmitted by the NxE on the N2 Trunk. This number should remain below 3 for proper updating of the N2 Mapper objects. If this number is greater than 3, no Point Scans are being performed.

    Queue Used Max is the maximum number of messages that have been in the Queue since the Statistics were last cleared. This could be since the last reboot of the NxE or since the last clear statistics command was issued on the N2 trunk object. This number is more useful if the statistics are cleared and then latched after a known time interval; for example, if the statistics are cleared and then latched 10 minutes later. This attribute would provide the worst case during that 10 minutes. If the Queue Used Most and Queue Used Curr are the same number and greater then 3, the NxE is unable to successfully get messages out on to the trunk. This could likely be a physical issue with the trunk. Perhaps a controller has gone bad and is affecting the trunk electrically or maybe a broken/shorted wire on the trunk.

    Priority 1 Poll Items is the number of Points in the HP Point Scan List. As mentioned above under the HP Point Scan Time this is the number of N2 mapper objects that need to be updated most frequently.

    Priority 2 Poll Items is the number of Points in the LP Point Scan List. This value represents all the remaining N2 mapper objects not included in the HP Point Scan list. Typically this will be the larger of the Poll Items values. If N2 Points are mapped unnecessary this number can be quite large. Since these points already have a lower priority, a larger number of them simply takes longer to check all of them once.

    Forgot to mention, if you can determine a set of objects not updating, add a trend to these points from the NAE and see if it starts to update. These objects with trends will be placed on the HP list.

  5. Likes numbawunfela, TylerAnderson74 liked this post.
  6. #4
    Join Date
    Apr 2014
    Posts
    655
    Post Likes
    Look for interlocks that have the recommend interval set to 0.

  7. Likes TylerAnderson74 liked this post.
  8. #5
    Join Date
    Oct 2018
    Posts
    14
    Post Likes
    Thread Starter
    @Integrator
    The NAE is an MS-NAE5510-3 and version 28 with firmware version 9.0.0.4256

    Thanks for the description on the metrics and stats. It really shed some light on what I'm looking at. The other issue I'm having is that all my stats/metrics are still zero and are not updating. I reset the NEA and saw the points update then but the airflow, for example, has not updated since. Is there a reason as to why I'm not seeing any stats? I also just added a trend to an airflow point and haven't seen it update but it may be to soon to judge. Are there any other tabs/settings I should be paying attention to?

    @JCIman
    The NAE I'm working on now does not have any interlocks

  9. #6
    Join Date
    Oct 2018
    Posts
    14
    Post Likes
    Thread Starter
    UPDATE:
    I was able to run the latch stats command and found that many VMAs came back with an error. The error said "Controller revision is less that C05". Does anyone know what this error means?

    Also read something in a manual that said that if my UDP port is 0 I wouldn't be able to write to certain points. Can anybody shed some light on this?

  10. #7
    Join Date
    Apr 2014
    Posts
    655
    Post Likes
    Quote Originally Posted by TylerAnderson74 View Post
    UPDATE:
    I was able to run the latch stats command and found that many VMAs came back with an error. The error said "Controller revision is less that C05". Does anyone know what this error means?

    Also read something in a manual that said that if my UDP port is 0 I wouldn't be able to write to certain points. Can anybody shed some light on this?
    The error refers to the firmware in the VMA. I don't recall what the latest firmware is, but you can update it to the latest (probably still 15 years old) with HVAC Pro version 8.08b.

  11. Likes TylerAnderson74 liked this post.
  12. #8
    Join Date
    Oct 2018
    Posts
    14
    Post Likes
    Thread Starter
    Does this mean that the VMAs need to be updated in order to poll their points?

  13. #9
    Join Date
    Apr 2014
    Posts
    655
    Post Likes
    Quote Originally Posted by TylerAnderson74 View Post
    Does this mean that the VMAs need to be updated in order to poll their points?
    Well...I don't know. I would upgrade them and see what happens. Were they polling until you added the FC trunk? Was there a Metasys upgrade in there too?
    In the past whenever I have seen N2 points not polling it has been some type of defective logic in the NAE causing to to drag down.
    I would definitely want get the firmware up to the latest to rule that out as a cause.

  14. Likes TylerAnderson74 liked this post.
  15. #10
    Join Date
    Oct 2018
    Posts
    14
    Post Likes
    Thread Starter
    Yes, they were polling after the FC bus was added. We really saw a difference in poll time after we started to write to some points for commissioning purposes. Could writing to these points be causing polling issues? How could I tell if so?

  16. #11
    Join Date
    Apr 2014
    Posts
    655
    Post Likes
    Quote Originally Posted by TylerAnderson74 View Post
    Yes, they were polling after the FC bus was added. We really saw a difference in poll time after we started to write to some points for commissioning purposes. Could writing to these points be causing polling issues? How could I tell if so?
    I would get rid of the logic that is writing the points and see what happens. If the writes are failing ang retrying, I could envision that causing the Q filling up.
    Also, put it in the expert mode and you will have more info to look at.
    There should be a document floating around this site somewhere explaining how to put it in the expert mode. Basically putting a text file on your workstation... pretty easy.
    I wouldn't be able to get the firmware thing out of my mind until I upgraded them.

  17. Likes numbawunfela liked this post.
  18. #12
    Join Date
    Sep 2007
    Location
    Kenilworth NJ
    Posts
    2,625
    Post Likes
    Quote Originally Posted by JCIman View Post
    Also, put it in the expert mode and you will have more info to look at.
    Basically putting a text file on your workstation... pretty easy.
    I wouldn't be able to get the firmware thing out of my mind until I upgraded them.
    x2 and x2 and x2
    The firmware thing on the old N2 devices is reliable (not like the FECsthat sometimes just die) but SUPER SLOW.... like start it and go to lunch for a few controllers, or start it when you leave and come back tomorrow to check on it for a full trunk kind of slow.
    You are going brand spanking new to super duper old, be glad you only need to upgrade firmware.....
    Hmmmm....smells like numbatwo to me.

  19. #13
    Join Date
    Sep 2007
    Location
    Kenilworth NJ
    Posts
    2,625
    Post Likes
    Quote Originally Posted by TylerAnderson74 View Post
    Yes, they were polling after the FC bus was added. We really saw a difference in poll time after we started to write to some points for commissioning purposes.
    That would be a red flag for me. You need to be nice to these great grandpa controllers!
    Hmmmm....smells like numbatwo to me.

  20. #14
    Join Date
    Oct 2018
    Posts
    14
    Post Likes
    Thread Starter
    Update:

    I booted up Metasys in expert mode and compared this NAE with another NAE that has about a third of the devices on the N2 bus. The "queue used curr" for the problem NAE is at 283 and the other NAE is at 9. The second NAE is polling the points just fine.

    Could the NAE with polling issue just be overload? Can I tune the N2 bus to get more consistent polling?

  21. #15
    Join Date
    Apr 2014
    Posts
    655
    Post Likes
    How many mapped objects are on the N2 trunk? The best practice was to keep that to 1000 or less. Of course, rules are meant to be broken, but more than 1500, and even I would start to worry

  22. #16
    Join Date
    Oct 2018
    Posts
    14
    Post Likes
    Thread Starter
    The count says 1289 objects. Is there any way to optimize this bus? Would deleting some of the points in each device and/or tuning the "poll delay" and "retries" settings help?

  23. #17
    Join Date
    Apr 2014
    Posts
    655
    Post Likes
    Quote Originally Posted by TylerAnderson74 View Post
    The count says 1289 objects. Is there any way to optimize this bus? Would deleting some of the points in each device and/or tuning the "poll delay" and "retries" settings help?
    1289 isn’t too bad. I don’t think there is any uninformed you can do since it’s flat out not polling. Go back and work on ruling out the logic writing to the points (since it worked before that), upgrade the firmware, and see what you come up with.

  24. #18
    Join Date
    May 2006
    Posts
    816
    Post Likes
    Quote Originally Posted by JCIman View Post
    1289 isn’t too bad. I don’t think there is any uninformed you can do since it’s flat out not polling. Go back and work on ruling out the logic writing to the points (since it worked before that), upgrade the firmware, and see what you come up with.


    The attribute 'Queue Used Curr' is the number of commands currently backed up in the N2 communication buffer. When this number is greater than 3 the N2 communications handler will "stop sending polling requests". The N2 communications handler gives priority to Poll Scans (online and offline poll messages) HP Point Scan and outbound commands. LP Point Scans are postponed until the higher priority messages have been sent.

    I found an old document stating to check and do the following to correct the issue;

    If the Queue Used Curr is greater than 3, here are some ideas to identify the source of excessive command on the N2 trunk:
    - Check Interlock, Multiple Command and Optimal Start object, which have a Send OK attribute. You can easily check to see if the commands from these objects are getting sent.
    - N2 controller objects have an attribute called 'Local Control'. This attribute must be false for the supervisory controller to command the object.
    - Check the release of the N2 controllers. DX-9100 controllers should be at release 7.0.5a. Controllers configured with HVACPro should be at Version 8.08b.


    As JCIman says, reduce the commands and In theory this should start the polling request again.

  25. #19
    Join Date
    Sep 2007
    Location
    Kenilworth NJ
    Posts
    2,625
    Post Likes
    Quote Originally Posted by TylerAnderson74 View Post
    The error said "Controller revision is less that C05".
    And
    Quote Originally Posted by integrator View Post
    - Check the release of the N2 controllers.... Controllers configured with HVACPro should be at Version 8.08b.
    The rev 8.08b HVACPro will correspond to a firmware that is C05. So it is code for 'Update the firmware'. Just some Wikipedia style disambiguation....
    Hmmmm....smells like numbatwo to me.

  26. #20
    Join Date
    Oct 2018
    Posts
    14
    Post Likes
    Thread Starter
    Update:

    I tried adjusting the COV values on a few points in each in VAV, tuned a "SharedTemp" program in the NAE, disabled "local control" in points we will be writing to for commissioning, and then reset the NAE. The "Queue Used Curr" decreased from ~300 to ~200. Seams like this helped, but we may need to adjust the COV values further to optimize polling.

    Seems like I'm moving in the right direction, do you guys have any thoughts on this?

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •