I have one FX40 with about 3 DX9100 and about 25 VMAs (VAV boxes), every few seconds I get a ping failed then few seconds later ping success alarm message in the alarm console.
I have not worked with N2 bus much but I am pretty sure the bus is good and it is a setting in FX40 that needs adjusting, I just don't know where and what.
It is also only the VMAs that are causing this message, almost all of them, none from the DXs.
I looked at the ping settings but need guidance as to which one to start tweaking.
I have got what i believe are default values (I say default because I have inherited this job) of:
Under JciN2Netwrok property sheet I have
ping delay = 00.400s
response timeout = 00.0250s
Inter Message Delay = 00.002s
Ping interval is hidden by default in FX40, when I look at it though, it is set to 5 min, but I know the driver is pinging devices much faster than that if the occurance of ping fail/success message is any indication.
yes, those are the default numbers. I have never had to tweak them though.
Do you have a ****load of errors in the station director window? Resources low due to these errors?
If you are positive its not the bus.
Try this first.
I have seen VMAs do quirky **** and this cleared it up, try reinstalling the jci jars in platform software manager. this has cleared up my mystery error vma issues. Not sure why or how the initial problems were created , but this worked for me.
Looks like they have installed a profanity filter for words you hear on Local TV!
Maybe we can have a milk break and nap time too if we're good!
Last edited by freddy-b; 12-11-2007 at 12:18 AM.
I am using a non-JCI workbench.
Can I just transfer out the JCI jars out of the jace to my PC's module directory, and then reinstall them that way?
If not, can you send me any distribution file set that installs the jci jars?
Yes. with file transfer wizard
JCI came out with a new "jcin2" jar file a few weeks ago. Send me your email address if you need it. Its supposed to improve communications with VMA's and TEC's. They also told me to use an end-of-line resistor.
Thanks, email is in my profile, or amigoneeds at yahoo dot com
Why the resistor? whats the logic behind that?All ASC's self terminate.
Originally Posted by ddcfreek
I have poor FX40 N2 performance, including slow updating, intermittent comm loss, random alarms, and points randomly commanded to zero.Cause:Poor N2 performance has been traced to multiple causes; all standard N2 troubleshooting items.
Originally Posted by freddy-b
Solution:Perform the standard N2 troubleshooting (e.g. check the maximum bus length, be sure there are EOLs where applicable, ensure the correct polarity, etc.).
NOTE: The FX Controllers are not self-terminating. Therefore, be sure to install 220 ohm end-of-line resistors (EOLs) as specified in ASC and N2 Bus Networking and Troubleshooting Guide Technical Bulletin, LIT-6363003, N2 EOL Termination section.
Details:Additionally, check the following items unique to FX40 N2 networks:
1) Observe the recommended maximum 1000 point limit per FX40 (this is the sum of all N2, LON, BACnet and Niagara points, see SDB 040522066005465: "How do I count the current number of points defined in an FX40?"
2) Ensure that the FX40 is running the latest jciN2.jar file. This can be determined by opening the Software Manager in FX Workbench Pro - all software modules in an FX40 v1.2 should be at 3.0.106 (for FX40 v1.0 or 1.1, jciN2.jar should be 126.96.36.199).
This version of the jciN2.jar file incorporates features that demonstrably improve communications to TEC, DX9100 and VMA controllers.
Internal Notes FSC Only: In response to some complaints of poor N2 performance, Steve Michals has produced an updated jciN2.jar 188.8.131.52 which incorporates the following new features:
- modified handling of negative acknowledge (NAK) errors which are common with TECs; the updated behavior is more consistent with N2 driver behavior in NAE and N30.
- immediate read-back of values following an adjust command (instead of waiting for the entire poll cycle to read a point's value); this is in response to user complaints that setpoint adjustments are not promptly reflected in the graphic or text screens of the FX40
3) On projects with N2 TECs, communication was improved by the addition of a 0.047 microF capacitor at each end of the N2. In instances where the typical 220 EOL resistor is already in place on the N2, these capacitors would be wired in parallel with the EOL.
See the Product Update PU 07-07: Compatibility Issues Related to TEC21xx Series N2 Networked Thermostats Communicating with a Supervisory Controller.
Why does this work? Somewhere around mid-2006, there was a production change to the TEC N2 circuit. TECs from this production batch sometimes generate an N2 noise spike that can negatively affect N2 communication. The capacitors act to dampen out this noise to yield cleaner N2 communication.
4) On projects with VMA controllers...
a) Ensure that the VMAs are upgraded to the latest firmware C04.
b) Edit the temperature change-of-value (COV) increments to at least 1 DegF.
c) Because VMA controllers impose a greater polling load on the N2 bus than traditional N2Open devices (such as the UNT, VAV and AHU controllers), count each VMA as being equivalent to 2 ASCs when engineering an FX40 N2 network. E.g., an FX40 N2 network comprised of 30 UNTs and 35 VMAs would represent 30 + (2 x 35) = 100 controllers - the recommended maximum.
5) On projects with traditional ASCs (i.e. UNT, VAV, AHU, DX9100), reload controllers using the latest version of HVAC Pro 8.08. With DX9100 reload controllers using the GX-9100 Programming Tool version 7.04 or newer.
6) Free up FX40 memory by reducing the number of internal database backups to zero. We have feedback that some random behaviors (such as false alarms, points going to zero) are drastically reduced by this strategy.
I found that out myself too. I tend to get alot of misinformation from JCI...
Most of that sounds alot like typical JCI babble when they dont know and guess just to say something.
And this statement is truly the most disturbing line in the whole thing.
"the updated behavior is more consistent with N2 driver behavior in NAE and N30."
God help us all!!!!!!!!!!!!
Thanks for the info!
Did you or anyone else come up with a fix for these problems?
I too am having poor FX40 N2 performance with the TEC Network Thermostat on a job that was installed in 2007.
The Dx9100's VMA's, Unts all are communicating fine on the N2 bus.
But all the TEC Thermostat points are slow at updating, intermittent comm loss, random alarms, and points randomly commanding to different values (from auto to on etc.. , & Various Sensors & Setpoints values randomly go from a their normal value to show -1 DegF?
Johnson is telling me to add end of line resistor on the last TEC. But the TEC literature states they are just like most ACS controllers and already have self terminating resistors built into them. Did you ever come up with a resolution to all the problems you were having on you project. See Attachment for details
Originally Posted by Chet1508
Good day Chet,
There could be a number of other issues at work here. A few questions:
1. What are you static N2 bus voltages (static meaning no supervisory or in your case the FX-40 connected) ?
2. What is the total number of N2 devices are on the bus?
3. What brand and model of N2 wiring are you using?
4. Can you confirm that the N2 Ref wire is connected to all devices including your FX?
5. Lastly, have you "scoped" the N2 bus to ensure no AC (60Hz, etc) noise is on the N2 bus?