CCN Comfort Controller EEPROM replacement

[Wirelander]

I have inherited a job where the customer previously had a company replace the EEPROM chips in all his processors. This replacement was recommended to allow for the new daylight savings times to be updated. They claim that they have experienced com failures and processor lock-ups ever since. I have run bus diagnostics and not shown excessive traffic or data collisions or failed packets. Then for whatever reason, a controller will lock up and take the entire bus down. It is never the same processor. I have also experienced problems connecting out in the field with my laptop and usually have to disconnect the controllers from the bus to stop the com failures from interfering with whatever I am doing.
Has anyone seen problems from the EEPROM replacements?

[Balibe]

I have inherited a job where the customer previously had a company replace the EEPROM chips in all his processors.

To the best of my knowledge, there is no EEPROM replacement for a comfort controller. You can flash a comfort controller with a newer version.

This replacement was recommended to allow for the new daylight savings times to be updated.

You don’t need to update the flash to modify the daylights savings settings for Carrier devices. All you need to do is make the necessary changes in the time broadcaster. It is a table in which you modify the start/stop months, week & day.

They claim that they have experienced com failures and processor lock-ups ever since. I have run bus diagnostics and not shown excessive traffic or data collisions or failed packets. Then for whatever reason, a controller will lock up and take the entire bus down. It is never the same processor.

I don’t think excessive traffic would lockup a controller. What is your average data exchange? Do you have to do a ram flush or just cycle power to reset the controller? Your issue may have been present before the controller upgrade. The person upgrading may have done it in an attempt to resolve the controller lockups.

Not sure if this is your issue, but I had one site that had the same issue [which was a new install]. Different controllers would freeze and take the entire bus down. A power cycle would reset the controller. After a while, we found a line of code in BEST++ that was the issue. We had the same BEST++ program running in all the controllers. After we fixed the code, the problem went away.

I have also experienced problems connecting out in the field with my laptop and usually have to disconnect the controllers from the bus to stop the com failures from interfering with whatever I am doing.

This can be several issues. The common cause is your laptop is set to the same address as another computer on the bus. It can also be a weak port powered converter, especially if you don’t have a physical com port on the laptop.

I have a couple jobs with very long bus runs where the com drops in and out while working on with my laptop. On these I use a powered converter.

[Wirelander]

I was skeptical about the daylight savings changes being a reason to change chips. It would have been easier (and cheaper) just to change it at the time broadcaster.
There was replicated BEST++ programs running in every controller, but they were in the controllers before the chip change. I did find some lines that were missing in some of the programs between the version resident in the controller and the version stored in the customers original backup files. I think it may be worth while to examine every program.
Cycling the power resets the locked up controller.
The highest bus traffic was 25% before locking up. Once one of the modules freezes, the traffic shows data going to and from addresses that don't exist in the system.
As far as my serial connection goes, I am using the PCMCIA card from B&B to RS232 to B&B 9 pin to RJ-11 485 converter. It was good on 1000' length busses....but this system may be longer.
There are about 30 comfort controllers on the primary bus with 2 bridges that serve 10 - 15 comfort id boxes a piece.
Thanks for your input.

[Balibe]

There was replicated BEST++ programs running in every controller, but they were in the controllers before the chip change. I did find some lines that were missing in some of the programs between the version resident in the controller and the version stored in the customers original backup files. I think it may be worth while to examine every program.

Make sure the BEST++ have some delays, it could help. If they are non-critical apps, you can delay 60sec or more. If someone modified the BEST++ with a laptop remotely, the front-end won’t reflect these changes.

The highest bus traffic was 25% before locking up. Once one of the modules freezes, the traffic shows data going to and from addresses that don't exist in the system.

Looks like you have a lot of data exchange for your system. I have larger sites than this and my average doesn’t go above 7%. Typically I try to keep a site at 5% or less.

What is all the data exchange for? Do you have a DataCollect on the site. A DataCollect can hurt a bus if they are setup to collect too frequent.

As far as my serial connection goes, I am using the PCMCIA card from B&B to RS232 to B&B 9 pin to RJ-11 485 converter. It was good on 1000' length busses....but this system may be longer.

A PCMCIA doesn’t put out as much voltage as a true serial port. Something like 3v versus 5v. I use a B&B #485BAT3 when I have com in/out issues. Are you using a generic B&B converter or the Carrier specific one [#485CARLP9A]?

[Wirelander]

The BEST had delays but was the major cause of the traffic. The program is constantly looking at building kw and OAT to limit the amount of output pressure to PIU's to shed the reheat load. The program writes to the proportional term of the AO_RESET algorithms.

The Data collection module only has a couple of reports running. The points are polling at the default of once every 6 minutes. I had to ram flush it to get it to start collecting again.
I am using the Carrier recommended converter.
I am going back to the job later in the week and am going to halt some of the programs to see what effect it has on the system performance.