-
N2 Bus troubleshooting (RS485)
Greetings all
Thank you for the site and the opportunity to collaborate with other proffessionals.
I have been working with N2 networks in the HVAC industry for about 5 years now, and have some experience, however I am SURE there are a lot of things I am missing.
Has anyone got any advice on troubleshooting a network that goes online/offline totally intermittently, with no apparent obvious external influences, like network cables running on top of heavy current lines?
I wish to monitor the RS485 signal more closely. We are using Johnson Controls controllers.
Thank you kindly
-
-
yep
the retaining screws fall out of the VMAs then the damper shaft stays in position while the VMA rotates around the shaft ...and this pulls the comms wires out.
also, if you ever got a JCI controller wet around the comms terminals...watch the network fall over intermittently.
Even years after it has dried out and is apparently working fine 99% of the time
not joking...serious.
1 + 1 = 3 ( *** for very large values of 1)
...everybody wants a box of chocolates and long stemmed rose
Be brave. You cannot get eaten by an imaginary tiger.
-
Post Likes - 1 Likes, 0 Dislikes
-
Do you have the N2 Troubleshooting Guide, FAN 636.3?
Sent you an email
If you can't fix it with JB Weld, Duct Tape, and Ty Wire it has to be replaced.
No good deed goes unpunished.
If you want to take off friday to go fishing then make sure you train your helper right.
-
Good day Andrew,
There are a number of things that can cause the issues you are describing:
a. Less than optimum Cable Used
JCI provided very little guidance on what cable should be used and so Technicians and installers effectively used whatever they had on hand or was inexpensive. Since the N2 bus is relatively slow in communication speed (9600 Baud) the system "could" tolerate incorrect cables... However, at times improper cable will bit back. Low Capacitive (i.e. 21 pf / foot) and cable rated for communications (i.e. a cable that specs a Characteristic Impedance, Zo, anywhere from 100 to 200 ohms).
b. Cable Length.
RS-485 is spec'd at 4000 feet at data rates less than 100K Baud... However, this distance assumes correct cabling and unit loading is within spec (i.e. no more than 32 unit loads). In correct cabling will cause data integrity issues as the cable length increases...
c. Too many devices on the cable
Again JCI dropped the ball big time on this. The RS485 spec clearly states no more than 32 unit load devices on the cable. Any more then the system starts to lose its noise immunity... and so data packets can become corrupted, etc... leading to multiple retries, etc. then eventually the device is flagged as offline... then it reconnects... so online, etc.
Older JCI field devices used older style RS-485 transceivers that are only rated at one unit load... Newer devices and some third party N2 devices use 1/4 or 1/8 unit load devices and so more devices can be connected.
d. Is the "Ref" connected?
RS-485 is designed for a reference lead to be connected. Although RS485 is a differential signalling protocol the reference lead is necessary to ensure that the RS485 bus signals (A,B... or in JCI terms N2+, N2-) are within the electrical specs of the device's RS485 transceiver. (You can do a search for more info on this).
e. Duplicated N2 Addresses...
f. Memory corruption issue within the Supervisory Controller
Older NCM-350's had issues with their battery backup that would actually corrupt their memory causing issues like this. To fix this a full upload of the NCM would be necessary. Earlier versions of the Tridium N2driver had issues too...So, ensure your supervisory's firmware, etc is up to date.
As for determining the exact cause... Unless it is something obvious one would need an oscilloscope, a good understanding of the low level details of the N2 communication protocol, and a RS485 bus sniffer.
Cheers,
Sam
-
The only thing I can add is a brute force approach to making things better. Most repeaters not only amplify the signals but they also clean up noise, etc. You can get mega-hours into troubleshooting one of these N2 buses if you want to get down to the root cause. Adding repeaters at the right places can help make the network more reliable and more tolerant of the problems that might exist. I've seen N2 networks where you could not get to the N2 bus because of asbestos contamination but adding a repeater at the head end cleaned up the signal enough to get reliable operations.
-
Originally Posted by
MatrixTransform
yep
the retaining screws fall out of the VMAs then the damper shaft stays in position while the VMA rotates around the shaft ...and this pulls the comms wires out.
also, if you ever got a JCI controller wet around the comms terminals...watch the network fall over intermittently.
Even years after it has dried out and is apparently working fine 99% of the time
not joking...serious.
Interesting, and scary! I've seen a bit of water damage at the site in question, perhaps that's a big contributing factor.
Thank you for your reply!
-
Originally Posted by
desert guy
Do you have the N2 Troubleshooting Guide, FAN 636.3?
Sent you an email
Hi Chris... Thank you, yes, I appreciate it greatly. I will go through it and try out all the methods to find the problem.
-
Hi Sam
Thank you for your comprehensive reply!
a,b,c should be ok, d: I have disconnected the Ref wire and saw no major change in the networks online/offline activity, however I will reconnect that and check through the many other options I have received through this forum.
e: no duplicates, f: we're using MOXA's to get onto the net and then a recently updated NAE as the master controller, so that ought to be ok...
Thank you SOOO much again for your comprehensive reply, I really appreciate it.
-
Originally Posted by
steves4
The only thing I can add is a brute force approach to making things better. Most repeaters not only amplify the signals but they also clean up noise, etc. You can get mega-hours into troubleshooting one of these N2 buses if you want to get down to the root cause. Adding repeaters at the right places can help make the network more reliable and more tolerant of the problems that might exist. I've seen N2 networks where you could not get to the N2 bus because of asbestos contamination but adding a repeater at the head end cleaned up the signal enough to get reliable operations.
Thank you Steve! I will give that a bash as well, I like the theory and it makes perfect sense. I think there is noise interference and that may help solve it. Much appreciated!!
-
Originally Posted by
Andrew Taljaard
Hi Sam
Thank you for your comprehensive reply!
a,b,c should be ok, d: I have disconnected the Ref wire and saw no major change in the networks online/offline activity, however I will reconnect that and check through the many other options I have received through this forum.
e: no duplicates, f: we're using MOXA's to get onto the net and then a recently updated NAE as the master controller, so that ought to be ok...
Thank you SOOO much again for your comprehensive reply, I really appreciate it.
Good day Andrew,
You are most welcome!
Can you explain which MOXA device you are using and how it is integrated into the system? I am unclear how you are integrating this in your network.
As for the NAE as the supervisory... NAEs tend to have a higher Poll frequency than the older Supervisory controllers and as correct cabling is even more important. Adding to this, JCI's own N2 field devices violated their own N2 timing spec and so with the NAE's faster poll rate these older field devices would "stumble" causing all sorts of issues. To combat this JCI released firmware updates to allow for some adjustability of the poll rate, but also the poll rate would automatically throttle back for polling older field devices.
Cheers,
Sam
-
Originally Posted by
Andrew Taljaard
Thank you Steve! I will give that a bash as well, I like the theory and it makes perfect sense. I think there is noise interference and that may help solve it. Much appreciated!!
Good day again Andrew,
Just a comment about noise... If proper cable is used electrical noise is a non issue simply because RS485 is a differential signaling protocol... in other words the background noise will appear as common mode noise... noise on both signal wires ... and so when the RS485 transceiver does its thing (i.e. subtracts the voltage ... differential... between the two wires) the noise signal will cancel out! In order for this to work correctly, correct cabling is needed. In fact even less than optimum cabling will still work, however, at a minimum it has to be twisted-pair (the twisted-pair helps keep the electrical noise as common mode).
The other component to noise immunity is the bus loading. As I mentioned earlier having more than 32 unit load devices will start lowering the overall differential voltages. RS485 spec's that a valid differential signal to be greater than or less than 200 mV! In other words any differential voltage that is between -200 mV and +200 mV will be indeterminate resulting in incorrect data extraction (ultimately packet corruption, etc). The Bus repeaters will help this, as it will reduce the bus loading, etc and therefore allow the signal/differential voltages to be higher. The negative side to repeaters is that they add timing delays between the repeater connected buses...
Cheers,
Sam
-
Originally Posted by
s2sam
Good day Andrew,
You are most welcome!
Can you explain which MOXA device you are using and how it is integrated into the system? I am unclear how you are integrating this in your network.
As for the NAE as the supervisory... NAEs tend to have a higher Poll frequency than the older Supervisory controllers and as correct cabling is even more important. Adding to this, JCI's own N2 field devices violated their own N2 timing spec and so with the NAE's faster poll rate these older field devices would "stumble" causing all sorts of issues. To combat this JCI released firmware updates to allow for some adjustability of the poll rate, but also the poll rate would automatically throttle back for polling older field devices.
Cheers,
Sam
Hey Sam
I'm using an N-Port 5100 Series RS485/Ethernet adaptor. One master, and several slaves. The site is hostile to new cable runs due to the layout of the buildings and the actual buildings themselves. There are also lots of isolated buildings which would require a tremendous amount of trenching to supply a 4 core, 2 pair twisted cable to them, hardly worth it financially, and perhaps environmentally. Fortunately some of these buildings have a network point, hence we are tapping into the Universities network, via the MOXA adaptor, and then reconverting the signal back to RS485, and essentially extending the N2 network cable via the ethernet adaptor.
The most annoying part is the NEW BUILDINGS which are consistently not setup for the BMS network cable! I wish the architect and consultant and everyone involved would sit around the same table at least once, to make sure there is a cable route supplied for the BMS network. Often these buildings have extensive restrictions on them like, no trunking whatsoever, and basically no external cable runs anywhere, making it impossible to get the controllers online without some alternative method.
I have not installed any patches or upgrades on the NAE, perhaps that is a consideration... I'll definitely look into that. We used Mylar cable, 4 core, (2 pairs twisted) with the shield.
Thanks
-
Originally Posted by
s2sam
Good day again Andrew,
Just a comment about noise... If proper cable is used electrical noise is a non issue simply because RS485 is a differential signaling protocol... in other words the background noise will appear as common mode noise... noise on both signal wires ... and so when the RS485 transceiver does its thing (i.e. subtracts the voltage ... differential... between the two wires) the noise signal will cancel out! In order for this to work correctly, correct cabling is needed. In fact even less than optimum cabling will still work, however, at a minimum it has to be twisted-pair (the twisted-pair helps keep the electrical noise as common mode).
The other component to noise immunity is the bus loading. As I mentioned earlier having more than 32 unit load devices will start lowering the overall differential voltages. RS485 spec's that a valid differential signal to be greater than or less than 200 mV! In other words any differential voltage that is between -200 mV and +200 mV will be indeterminate resulting in incorrect data extraction (ultimately packet corruption, etc). The Bus repeaters will help this, as it will reduce the bus loading, etc and therefore allow the signal/differential voltages to be higher. The negative side to repeaters is that they add timing delays between the repeater connected buses...
Cheers,
Sam
That's interesting and makes sense... Yes, we definitely use twisted pair, usually two twisted pairs, Red/Blue/Yellow/Green with a shield.
We have less than ten devices on this particular network, so I don't suspect heavy bus loading. I'm going to take a run through the site making some measurements on the N2 line, now that I have some more helpful information, thanks to Chris elsewhere on this post who provided me with a very comprehensive guide.
Thanks again for the input, I really appreciate it.
-
Originally Posted by
Andrew Taljaard
Hey Sam
I'm using an N-Port 5100 Series RS485/Ethernet adaptor. One master, and several slaves. The site is hostile to new cable runs due to the layout of the buildings and the actual buildings themselves. There are also lots of isolated buildings which would require a tremendous amount of trenching to supply a 4 core, 2 pair twisted cable to them, hardly worth it financially, and perhaps environmentally. Fortunately some of these buildings have a network point, hence we are tapping into the Universities network, via the MOXA adaptor, and then reconverting the signal back to RS485, and essentially extending the N2 network cable via the ethernet adaptor.
The most annoying part is the NEW BUILDINGS which are consistently not setup for the BMS network cable! I wish the architect and consultant and everyone involved would sit around the same table at least once, to make sure there is a cable route supplied for the BMS network. Often these buildings have extensive restrictions on them like, no trunking whatsoever, and basically no external cable runs anywhere, making it impossible to get the controllers online without some alternative method.
I have not installed any patches or upgrades on the NAE, perhaps that is a consideration... I'll definitely look into that. We used Mylar cable, 4 core, (2 pairs twisted) with the shield.
Thanks
Good day Andrew,
Thank you for your explanation! In fact that is why you are having the issues you are. Using off the shelf Ethernet to RS485 converters with the N2 bus will simply not work consistently or reliability. The reason for this is that Ethernet is non deterministic protocol and so it has variable Packet delays (from milliseconds to seconds), no guarantee of packet delivery (i.e. it can drop packets), and no guarantee of packet ordering (packets may arrive out of sending order). JCI's N2 Bus is a Master-Slave bus with very specific timing requirements and so if the slave does not respond within the maximum allowed time, the Supervisory will flag the device as offline... then once the device comes back online, the Supervisory will re-intitalize the device again, etc... the result is that the bus thorough put will drop a lot... and you will get almost consistent offline and online situations.
To overcome this issue I developed a N2 to Ethernet Convertor (S2N2E) for JCI and their customers. The device is actually very intelligent and overcomes all of the Ethernet nuances (well within reason) so that you can extend the N2 via Ethernet (or even the Internet if one wanted). In fact the device can accommodate packet losses and delays up to 9 seconds (not sustained).
If you wish more details, etc on our S2N2E you can find my contact details within my Profile page.
Cheers,
Sam
-
Andrew,
It sounds like you are using the MOXA devices to extend the N2 bus over the Ethernet infrastructure. Correct?
One of the things that we found out (actually reinforced what we already knew) was that even through the N2 bus only runs at 9600 BD, Half Duplex it is notoriously sensitive to timing. We tested with Ethernet Serial Servers from multiple manufacturers and consistently saw the same kinds of problems as you are experiencing. When we added support for Ethernet Serial Servers to our S4 Open: BACnet-N2 Router we needed to have the N2 Router control one end of the connection (the master end) and use serial servers only as slaves. That gave us complete control over the timing issues. I believe that Sam also has some devices that were specifically designed to extend the N2 bus over Ethernet that takes care of the timing issues.
-
Originally Posted by
s2sam
Good day Andrew,
Thank you for your explanation! In fact that is why you are having the issues you are. Using off the shelf Ethernet to RS485 converters with the N2 bus will simply not work consistently or reliability. The reason for this is that Ethernet is non deterministic protocol and so it has variable Packet delays (from milliseconds to seconds), no guarantee of packet delivery (i.e. it can drop packets), and no guarantee of packet ordering (packets may arrive out of sending order). JCI's N2 Bus is a Master-Slave bus with very specific timing requirements and so if the slave does not respond within the maximum allowed time, the Supervisory will flag the device as offline... then once the device comes back online, the Supervisory will re-intitalize the device again, etc... the result is that the bus thorough put will drop a lot... and you will get almost consistent offline and online situations.
To overcome this issue I developed a N2 to Ethernet Convertor (S2N2E) for JCI and their customers. The device is actually very intelligent and overcomes all of the Ethernet nuances (well within reason) so that you can extend the N2 via Ethernet (or even the Internet if one wanted). In fact the device can accommodate packet losses and delays up to 9 seconds (not sustained).
If you wish more details, etc on our S2N2E you can find my contact details within my Profile page.
Cheers,
Sam
Thanks Sam! My team leader just said to me: Find another solution Andrew! - We have SO MANY MOXA 5130's in the field now... I was trying to convince myself and him last week that the moxa's were SOMEHOW majorly responsible for the online/offline state, and your reply just made me start to really believe it based on some facts.
I requested friendship through your profile page, couldn't see any other means of communicating other than this thread.
Please would you send me some details. I would like to at worst start using your product for new installations if its viable.
Thank you kindly.
Andrew
-
Originally Posted by
Andrew Taljaard
Thanks Sam! My team leader just said to me: Find another solution Andrew! - We have SO MANY MOXA 5130's in the field now... I was trying to convince myself and him last week that the moxa's were SOMEHOW majorly responsible for the online/offline state, and your reply just made me start to really believe it based on some facts.
I requested friendship through your profile page, couldn't see any other means of communicating other than this thread.
Please would you send me some details. I would like to at worst start using your product for new installations if its viable.
Thank you kindly.
Andrew
Good day Andrew,
You are most welcome!
The issues (or charms to some) with Ethernet, etc are well known and creates havoc with protocols that are sensitive to timing. Remember that the N2 bus was designed as a Master/Slave Protocol and so the Master assumes that the Slave will respond within a very tight timing window...Ethernet, by its very nature, cannot guarantee packet response timing or delivery, as it is a Collision based protocol and so packet timing is inherently variable. In order to use Ethernet properly the higher level software must take these factors into account, which was never designed into the N2 Protocols.
My contact details are within my profile and are on the "About Me" page, but perhaps since you are a new user you have no visibility to this info. As a consequence, I found your contact details within your profile and sent you some information and my contact information.
Cheers,
Sam
-
Originally Posted by
s2sam
Good day Andrew,
You are most welcome!
The issues (or charms to some) with Ethernet, etc are well known and creates havoc with protocols that are sensitive to timing. Remember that the N2 bus was designed as a Master/Slave Protocol and so the Master assumes that the Slave will respond within a very tight timing window...Ethernet, by its very nature, cannot guarantee packet response timing or delivery, as it is a Collision based protocol and so packet timing is inherently variable. In order to use Ethernet properly the higher level software must take these factors into account, which was never designed into the N2 Protocols.
My contact details are within my profile and are on the "About Me" page, but perhaps since you are a new user you have no visibility to this info. As a consequence, I found your contact details within your profile and sent you some information and my contact information.
Cheers,
Sam
Hi Sam
I have reviewed your product and it looks awesome. It is comparatively a little bit pricey though, and we have already installed quite a few MOXA's which we need to now look at replacing. I have been offered a Lantronix USD1100 for about $180, by our JCI distributor in Jhb who has used this successfully in other parts of the country on JCI equipment, and because we have so many to replace (12), we are going to try that option first with a pair to see if they give us the solution we need. The Lantronix does have many more configuration options than the MOXA's including shaping and timing of the packets...
Thank you kindly... I will let you know how the installation goes when we get them in.
-
Originally Posted by
Andrew Taljaard
Hi Sam
I have reviewed your product and it looks awesome. It is comparatively a little bit pricey though, and we have already installed quite a few MOXA's which we need to now look at replacing. I have been offered a Lantronix USD1100 for about $180, by our JCI distributor in Jhb who has used this successfully in other parts of the country on JCI equipment, and because we have so many to replace (12), we are going to try that option first with a pair to see if they give us the solution we need. The Lantronix does have many more configuration options than the MOXA's including shaping and timing of the packets...
Thank you kindly... I will let you know how the installation goes when we get them in.
Lantronix UDS1100 is what I meant, not USD1100...
-
Originally Posted by
Andrew Taljaard
Hi Sam
I have reviewed your product and it looks awesome. It is comparatively a little bit pricey though, and we have already installed quite a few MOXA's which we need to now look at replacing. I have been offered a Lantronix USD1100 for about $180, by our JCI distributor in Jhb who has used this successfully in other parts of the country on JCI equipment, and because we have so many to replace (12), we are going to try that option first with a pair to see if they give us the solution we need. The Lantronix does have many more configuration options than the MOXA's including shaping and timing of the packets...
Thank you kindly... I will let you know how the installation goes when we get them in.
Good day Andrew,
Lantronix makes some excellent products and in fact was the manufacturer of JCI's Ethernet N2 Bus Extender (SECVT) used with the NAE 5500 series. Reviews of the SECVT were mixed and a few years ago JCI abruptly discontinued the product. I believe that our S2N2E is still currently the only listed solution within JCI's own internal Corporate solution database for Ethernet/N2 applications.
As for pricing... as with everything, pricing is dependent upon volume. Lantronix devices are generic devices and so cater to a much larger market than our S2N2E. The S2N2E is designed specifically for Ethernet to N2 applications and so its market is significantly smaller which means it will cost more. Adding to this there are additional support costs that we have to account for that Lantronix does not. If you contact Lantronix about a N2 bus issue their support personnel issue will have no idea about N2, its timing, its nuances, etc and so on... Lantronix support will be confined to their product only.
In regards to Lantronix's devices or any generic Ethernet to RS485 devices...These devices do not and will not take into account all of the nuances and idiosyncrasies of JCI's N2 bus. Although the N2 Bus is electrically a RS485 bus (which is generic), it is the actual protocol and its timing requirements that are not generic... and it is these elements that create problems with generic Ethernet convertors. In other words there is no magic formula or Ethernet configuration settings that can overcome the N2 Bus's nuances... Fundamentally you have a master-slave communication protocol that must conform to deterministic response timing... of which Ethernet is not. Remember Ethernet is a non deterministic collision based protocol and so its packet latency is variable, etc. Ethernet Switches, etc helps tremendously, but you have to carefully architect your Ethernet network to ensure reduce latencies, etc. Remember you have to do the following:
Supervisory <-> RS485 to Ethernet Gateway <-> Ethernet Transmission <-> Ethernet to RS485 Gateway <-> Field Device
... and you need to do this twice... Supervisory to the Field device and a response Packet from Field device to Supervisory. Technically the response time has to be under 10 milliseconds. In reality the Supervisory will wait longer, but 10 milliseconds is the spec. To do this process deterministically and within spec is a challenge especially if the Gateway's packeting and extraction is inefficient, or if Ethernet packets are lost and/or a collision occurs. Can generic Ethernet to RS485 devices work? In some cases they can... but this is very site and application specific. As an example, JCI's SIS Department in San Diego qualified some devices to be used on some larger JCI Customer locations. Their internal testing worked well and so they deployed over 100 devices only to have them fail when placed onto in a real World customer Network (during peak Ethernet usage the system would get off-lines).
With all that being said, you need to do what you think best and perhaps the Lantronix device will work for your application. You will never know until you try.
Cheers,
Sam