31 Oktober 2012

POWER WIRING
Figures 1 through 3 show examples of DC power distribution. Figure 1 shows how a DC power source and distribution panel should be connected to various components of an INFI 90 system. Refer to Notes for Figure 1 for an explanation of Figure 1.Figure 2 shows how to connect and ground a two-line DC source. Figure 3 shows how to connect DC common bus bars on multiple cabinets. Refer to Notes for Figure 3 for an explanation of Figure 3.
Refer to ANSI/NFPA 70, National Electrical Code or CSA Standard C22.1, Canadian Electrical Code for information on conductor size requirements of DC power wiring, equipment grounding conductors and DC grounding conductors. Grounding electrode conductors should be the same size as the largest conductor feeding the applicable source. Minimum conductor sizing should be increased one size for every increment of 30.5 meters (100 feet) greater than 30.5 meters (100 feet). All conductors should be stranded, insulated copper.
DC power requires three insulated conductors that are within the same cord, cable, conduit or raceway. These conductors will be a positive conductor, negative conductor and an equipment grounding conductor. The positive conductor can be any color except those used by the negative and grounding conductor. All power wiring must be checked prior to applying power to any of the Bailey system components. In addition, verify that the wiring for all AC receptacles used to supply power to peripheral INFI 90 equipment is correct.
All PCU cabinets, OIS consoles and OIS driver cabinets have terminal blocks for connecting power. Each powered PCU cabinet has a power entry panel at the top of the cabinet. Power conductors connect to the power entry panel through compression type terminal blocks. The console monitors, printers and engineering work stations have plugs for ordinary grounded AC receptacles. The AC receptacles must share the same ground that the cabinets use. Each unit comes with a 1.8 meters (six feet) line cord that has a standard three­prong plug. Refer to the product instruction that accompanies each unit for more information on connecting power to that particular unit.Notes for Figure 1

For personnel safety, follow the grounding guidelines contained in this instruction. They comply with Section 10 of the Canadian Electrical Code Part 1 (C22.1) and Article 250 of the National Electrical Code.

The system power source must be dedicated for the INFI 90 system and associated equipment. The AC system power source must not supply power for air conditioning, convenience outlets, lighting, or other plant equipment.

Safety ground conductor size must be equal to or greater than the size of the power conductors connected to the secondary wiring. Increase one (1) wire size for every 30.5 meters (100 feet) of safety conductor length if the length is greater that 30.5 meters (100 feet).

All devices that make up part of the INFI 90 system (i.e., OIS consoles, printers, work stations, etc.), and are in a common area, should be powered from and grounded through the same power distribution panel. Power remote equipment through a dedicated power source. Do not power or ground other systems through the INFI 90 power and grounding system.

Size the breakers according to the load requirements and conductor size.

Connect structural steel within 1.8 meters (6 feet) of the system to the building ground system to insure that the potential difference between the system chassis and nearby structural steel is less than 30 Vrms.

If conductors that carry signals to and from the INFI 90 system pass through conduit, bond and ground the conduit to the local system ground using an equipment grounding conductor.

Do not use conduit as an equipment grounding conductor; use a separate wire that is insulated and properly sized.

Install ground fault detector at the distribution panel if source is floating (ungrounded).<12> Connect the system power source to the local building grounding electrode system. The grounding electrode system must have an impedance of five ohms or less to the earth. Bond the grounding electrode system to the existing building service ground system through a grounding electrode conductor.12>

Connect the cabinet DC common bus bar to the system dedicated DC common. The dedicated DC common must be bonded to a grounding electrode that is part of the existing local building grounding electrode system. Connect one end of the DC electrode conductor to the isolated DC common bus bar. Exothermically weld the other end of the DC electrode conductor to the electrode. The building grounding electrode and the DC grounding electrode must reference a common ground location. The DC common electrode conductor should be a 4/0 insulated conductor minimum.

Connect the DC common bus bar of additional cabinet assemblies within the same location to the main system cabinet isolated DC common bus bar (in a star pattern).

Ground I/O wiring shields at one end only. Terminate all I/O wiring shields at the side bus bars within the system cabinet, except those shields containing grounded thermocouples or grounded RTD elements. Ground the shields of thermocouples or grounded RTD elements at the sensor.

The INFI­NET/Plant Loop cable that Bailey provides with the system connects all conductors to the system on each end. The system design allows the cable shield to connect to the termination unit at both ends without creating a ground loop. Do not allow the metal connectors on the coax cable to make contact with the cabinet frame.

It is permissible to use a different AC power source for a remote OIS console, printer and associated equipment. The source must satisfy the AC power distribution and system grounding requirements specified by Bailey, and both the OIS console and printer must be grounded to the same power source. All devices that communicate to the remote OIS console through an RS­232­C interface must use an isolating short haul modem (or other isolation device) unless those devices are powered and grounded through the same power source that serves the remote OIS console.

Equipment communicating with the Bailey system via an RS­232­C link must use an isolating device (i.e., an isolating short haul modem) if they are not powered and grounded through the same power source.Notes for Figure 3

Every cabinet must be tied to the system safety ground through an equipment grounding conductor. The equipment grounding conductor for nonpowered cabinets must connect to a powered cabinet that has a connection to the safety ground at the power source.

This ground connection is internal to the power entry panel. Bolts are provided to make this connection.

Notice that the DC common bus bars of all nonpowered cabinets connect in a star pattern to the DC bus bar of the cabinet supplying their I/O power. Likewise, all the DC common bus bars in powered cabinets connect in a star pattern to the DC bus bar of the powered cabinet that is closest to the DC grounding electrode (cabinet 4). The DC bus bar of the cabinet that is closest to the DC grounding electrode connects to the DC electrode through a DC grounding electrode conductor.

Hi! Anybody help us on the list of Bailey Infi90 system limitations? we need to come up with a list of Bailey Infi90 system limitations from technical points (not commercial) for migration justification.Limitations such as; Communication speed, CPU Memory, PID control, ACP etc...Thanks in advance..Could you describe your current system? that might help a little.The existing Bailey ifi90 has the complete redundent configuration; (NW, PCU, PS)the modules on the rack shows;INNIS01INNPM01INNIS01INNPM01IMMFP12IMMFP12IMFBS01IMFBS01IMDS102IMDSO04INICT01with IEPAS02 etc....The Console type is OIS42,Hope this information will help..Wow, you have a very old INFI90 system. There have been new enhancements in the communication system and in the speed/capacity of the controllers. Also I can see you still use the old OIS42's which are based in obsolete DEC computers. You can justify an upgrade based in just obsolescence and availability of the hardware which I think is no longer being supplied by ABB(who now owns the Bailey techonology) or DEC (which was bought by Compaq which also was acquired by HP). Critical issues, the way I see it, are the console system and the old power supply system. Next critical issues are controllers and the communication system (NIS/NPM based). So you may think in an upgrade plan replacing first the consoles and the power supply system (which may be replaced by ABB's new MPSIII), and then go for the replacement of the controllers and comm system.

You may choose to go with ABB and migrate your system to a new 800xa system which may use most of the existing application. Also you may consider to go to a different system from a different supplier and reengineer the whole application which might be costly.I have exactly the same control system in my plant. Last year we upgraded to MPS3 power supply as the old power supply unit is very costly in terms of spares and unreliable during thunderstorm season. As for the OIS, nothing much were able to be done except for the replacement of the old crt to lcd screens. As a backup, PGP from ABB were installed in case all 4 ois fail at the same time. Now i have 1 OIS down which I need to replace the CPU (thx god I still have 1 new left ;) )during the outage next month.I know this is a thread revival but I was told by an ABB rep that they will be providing support until 2025. So you need to talk to your local rep to get an upgrade path if you want to stick with your infi-90.ABB formally announced a few years ago that the Harmony/Infi90 system will remain in the "active" phase through at least 2015, transitioning to the "classic" phase through at least 2025, and finally transitioning to the "obsolete" phase. I have also read that ABB attempts to have a minimum classic and obsolete phase duration of at least 7 years. That puts us to 2032 if my math is right.

My understanding of the phases, based on reading and discussions with ABB personnel (not just sales and marketing...) is this:

Active - Fully available including large new complete engineered systems. Ongoing training classes available. R&D monies allocated for new stuff.

Classic - Fully available to maintain and expand existing systems. R&D not spent to add more capabilities, but limited to allow for new parts to be available. This would include development of engineering software applications to run on current computer operating systems.

Obsolete - New modules available as supplier sub component parts are available. Repair/refurbishment when not. No R&D.

Keep in mind that while a system is "active" or "classic", components, such as an MFP12, can be made "obsolete" due to supplier parts availability. However, there is generally a pretty clean direct replacement (BRC300 or 400 in the MFP case.) I know that some items, like Block IO, are not a simple plug and play replacement. The OIS path is also complex. But my experience-based observation is that they have done as good or better than other suppliers in this regard. Again, these are my experienced based observations as a customer.

So, enough advertisement and back to the thread.

Is your MFP12/OIS42 system "old school" as my son would say, or are you running at a huge risk? I would say no based on the discussion above.

Are you in the position to evaluate your options and create/update a 5 and 10 year plan? Obviously so due to your questions.

However, the original line of questioning ("tell me what the CPU memory specifications are on my Infi90 system so I can justify a new one") is quite ridiculous. That may sound harsh, but I'm trying to save your career. Let's face it - every day there is something better. To go before management of a company and tell them that we need a new one because the old one is old is asking for trouble, in most organizations anyway.

Consider this question. The Infi90 has X memory, Y speed, etc. It worked when it was installed, and it works today. Are you saying that it won't work tomorrow because of X and Y? That makes no logical sense.

What is your real fear? What are your real issues? Write them down, think about them. Ask others on this forum. Then ask the OEM what they can do for you. But consider a 5 and 10 year plan. Then talk to other suppliers and see what they can do for you. At that point you will be informed, and in turn make an informed recommendation to your company.

Not that you are doing this...but it amazes me when someone rips and replaces an Infi90 system when a simple power supply/controller/HMI upgrade (at say 20% of the rip and replace cost) can get them another 15 years of operation. Another variation of a bad decision is to put in a brand X HMI on a Harmony/Infi90 without having the rest of the plan in place. Note that I did not say that putting in a 3rd party HMI is bad. If you put in a brand X HMI, and save $100,000 when compared to ABB (just to pull a number out of the air) that is ok. But if 5 years later you give brand X a no-bid contract to replace all of the controls you have just lost your savings times 10 or more. That is really bad. Think things all of the way through.

What if ABB could, over time to levelize your cash flow if needed, convert one or two controllers at a time from Harmony to 800xA, retaining your Harmony IO. That means that you don't rework any IO, any field cables, any associated drawings, not to mention lost production. What if they could take the Harmony logic drawings and convert that proven control strategy to the new controller such that you don't even need to tune. What is the cost difference to a rip and replace?

If you go that route, it would behoove you to get the ABB costs up front before you commit. The natural behavior of any supplier will be to take some advantage of any possible situation.apologies for hijacking this thread. I need some help from Bailey INFI 90 experts. I need to know if I can achieve modbus communication from another system to the Bailey INFI 90 system. What will be required on the INFI 90 side?You have options:

1. Set up an MFC/MFP/BRC (controller) as a Foreign Device Interface (FDI) running with a Modbus master application. The controller will require a termination unit with serial ports. Both RS232 and RS485 are available in this configuration, although if you want redundant ports RS232 is the only option. Redundancy at the controller level is optional as well. The Modbus mapping ends up running in an "NBS" file, executing in the same controller with a traditional "CFG" files. Within the CFG file are function blocks that expose the Modbus reads to individual block numbers. You can write from any block number.

2. If you don't mind the "Microsoft factor" or increased security issues (real or perceived) you can use one of many OPC applications (third party and ABB) that can read/write to the system via an ICT. You will also need one of the many available OPC Modbus drivers and connect the two. Of course this type of interface is open to many additional protocols, not just Modbus.

3. As a variation to item 2, if you have a Process Portal A based HMI on top of the Infi90, this is based on OPC so some of the software mentioned in item 2 is already in place. If the purpose of the interface includes presenting unaltered data on the HMI, you can go direct and bypass the property transfer into the Infi90 controller world. You can, if needed, send a subset of tags to Infi90 and the remainder/all to the HMI.

There are pros and cons to each approach. I highly recommend having a technical discussion with ABB. There are some pretty new (1 yr) products that they have introduced in this space that I have not used yet (I've got all three mentioned above.) Look at all your options before deciding.Item 2 can be easily tried using evaluation products. As pointed out you will need a modbus OPC server (Kepware has a few of these), Infi 90 OPC server and bridging software to link the two servers together (RoviSys Infi 90 OPC server and BridgeMaster products can be evaluated at no cost).This is easily accomplished by using a Modbus OPC server and Infi 90 OPC server with bridging software to link the two OPC servers together. The RoviSys OPC90 Server and BridgeMaster software products can be used for the INFI 90 side.Refer to John's post (25 Jan 2011) and of all three options he outlines, I've found the first one to be the simplest and most reliable. Depending on what Infi90 'tools' you have on hand, you can use a simple DOS program known as GPI02 or the more up-to-date version of it that partners with the 'Composer' Toolset, which is what appears to be the FDI John is talking about. (If you are using the old 'Wintools' or even older SCAD you must use the GPI02, which partners with the .cfg file produced by those.

In both cases a .NBS file is downloaded together with the normal .cfg file to the module running the interface.

I have also worked with OPC interfaces on Conductor NT and although it works OK, you will also need a third party OPC server to connect to the ABB OPC database.

I cannot comment on the OPC with PPB as I haven't worked with OPC on that type of console, however of the two I have used, the GPI02 or FDI which runs a .NBS (a C language simple script that connects your foreign device to special Bailey function codes via an RS232 link) is BY FAR the more reliable of the two options.

Note that the .NBS file can only be saved in your Composer or Wintools project and downloaded (say in the event the module failed and you don't have redundant pair); it cannot be opened and edited. You can only edit the actual script with the GPI02 program or the FDI, then when you download it together with the module configuration (the function codes); the updated .NBS file is then replaced in the module.

ABB would no doubt have a few more options available now, so as John has suggested: you would be well advised to discuss it with them first.I cannot comment on the OPC with PPB as I haven't worked with OPC on that type of console

I worked at a site that had multiple ABB OPC servers set up to allow communication between DeltaV controllers and ABB PPB and it worked fine. I also set up a couple of OPC servers to allow communication to Matrikon's Alarm Manager and Control Performance Monitor. It is very easy to install but setting up DCOM will do your head in. It's a nightmare to set up if you don't have all servers on the same domain, but you can make it work (I suggest using OPC Tunneler from Matrikon)I need a little bit guidance regarding saving .NBS file from IMMFP01 using composer. Can you please tell me how can I save .NBS file from IMMFP01 on composer? What options of Composer should I use to do so?Hope you would help me.Looking forward for your swift response.Just to reassure Harsha and to add weight to John's comments regarding the various phases from 'active' to obsolete etc., you can simply browse this entire site and look for posts about Bailey Infi90 / ABB Harmony and after a while, one thing will become apparent: You will notice that there is relatively very little posted about these systems! This should tell you something...

Not that I am biased of course :)...

I've been working with these systems for about 27 years now, since the very early Network 90 and its classic NOIU01 / 02 console, right up to the present, with the 800 xa series and am currently engaged at a power station that uses 'classic' Infi90 (that's INNIS01 INNIS11 / INNPM01/11 and IMMFP02/12 controllers and Symphony power system). We have an ABB (Italy) Power Generation Portal (PGP v 3.2) HMI, which was chosen over PPB or CNT or other HMI products simply because it was the only console available that could use the SODG displays that were used on the former OIS43 consoles. (We still have one of those in service, but is only used as the time synch master and for a backup if the entire PGP has to be taken off line).

I have worked with other DCS products and a number of 'generic' HMI's and still maintain that nothing even comes close to the Bailey / ABB systems in terms of their ability to be easily upgraded - backward compatibility and support of what would otherwise be very 'old' system components. The actual DCS hardware is VERY reliable and I've worked with systems that have been 'online' continuously for more than 20 years without a single glitch over that period!

From what you've said about your system (and to back up John's comments), you really only need to concern yourself at this stage with the HMI's and maybe the cabinet power systems, the rest of it should keep your plant running for many more years yet!

Since you are upgrading OIS4xx consoles, you should consider the PGP as a replacement as the SODG displays from your OIS42 will go straight into this console with minor tidying up required. Any other HMI will require the graphics to be built 'from scratch' again and if your system is a large one (such as ours with over 2000 displays), that could mean months even YEARS of extra work!Seems you are closely involved in the Harmony system. Maybe you can tell me: how does the recent launch and promotion of "Symphony Plus" fit into this ABB strategy? What is new about this? Is it still Bailey?Symphony Plus (S+) is simply the next moniker in the Bailey Net90-Infi90-Symphony/Harmony naming scheme. As with all name changes there are some commensurate new products released, and this time around is no different in that regard. However, anyone that has this DCS "line" should realize that this new investment brings our trusted friend back for many years to come. The previously promised 2015 transfer from active to classic with support to 2025 is now indefinite. I suppose that promise was broken in a good way. Thus one can argue that this is the most important name change yet (realizing of course that the name is just skin deep, the real importance is the investment and continued commitment.)

As to the pieces and parts, starting at the HMI level, S+ adds "S+ Operations" (PGP - Power Generation Portal) as an alternative to the 800xA based PPA system. Both are available. As with any decision, there are pros and cons to both.

Moving to communications, the current NIS/NPM remain, but new models released over the last 2 years or so have significant capability improvements. But as is often the case ABB does a best in class job of letting you replace such things in pairs as long as firmware throughout the loop is at an appropriate level. For those that are running out of parts of old parts, if they become unobtainable, this is a good way to kick some free one pair at a time if you can't fund a wholesale upgrade.

There is a new processor with S+, the BRC410 I believe, with a built in Ethernet port. The initial function is for Modbus, but it does provide an open door for more, N'est-ce pas? I wonder what else they can do with that port... Moving from MFC/MFP or older BRC's to the current can be done in pairs like discussed above.

For interfaces to computers, the IET800 is the long awaited Ethernet CIU.

At the IO level, rack IO (all models I think are now upgraded to surface mount) are still available and viable, as well as S800 IO.

At the power supply level, the MPSIII is current.

Composer 5.1 is the new release with S+, and I believe is Windows 7 32 bit compatible.

As you can see I'm pretty darn happy with our stuff, some installed in 1983 and the latest installed in 2008, and some to be installed soon.

It's pretty cool to have a cabinet with many 1983 based rack IO modules, a 1997 MPSII power supply, some 1999 MFP02's, some BRCs, remote S800 IO, on Composer 5.0 and a PPA HMI, all circa 2007.

Since S+ Operations (aka PGP) is new to me, I have not done any detailed comparison. My understanding is that ABB needed a lower cost HMI solution (compared to the 800xA PPA HMI) for Harmony applications, and this could help in that regard, even with the PPA system projects reaching a pretty good level of optimization and loaded on hardware now being deployed in a significantly smaller footprint by means of using virtual servers. If I were to do such a comparison, I would visit sites to compare features of both systems along with end user satisfaction. Another concern for me is that a lower cost solution often means less of the good stuff that I am used to (but that does not have to be the case).

From a technical standpoint, my understanding is that the S+ Operations is close to the OIS architecture, with each computer (Windows based) capable of acting as a server with its own ICT's. One of the pros is reliability when you have multiple independent servers. One of the cons is keeping the databases and files synchronized between them. The PPA Harmony Connect uses pretty much the same interface computer software (SQL server based database) as Process Portal B and Conductor NT from what I hear. One of the pros here is one database and one set of files to manage. One of the cons is that many feel that the system is "too complex".

>What about 800xA in power? I thought they wanted to migrate all?

What we want and what we get are often not in alignment, and ABB has lost a lot of HMI business to "third parties". Having attended the recent Automation and Power World conference in April, I can say that there is no shortage of 800xA PPA HMI's on top of Harmony systems in Power and other industries. However, there may be as many or more that have gone another direction. More than likely, for the systems that have not yet done an HMI upgrade, S+ Operations will provide ABB another tool to retain a higher percentage of their installed base than with PPA alone. Those two HMI options coupled with the fact that the controls hardware (processors, communications, IO's) are NOT obsolete (in spite of some of the innuendo from others) means that customers can avoid the "rip and replace" method of upgrades.

For those that start small with a third party HMI upgrade, thinking that they are saving money, tend to not think 5 to 10 years down the road when they (or their successor) hands a blank check to someone to finish the job and replace the PCU cabinets that they are convinced are obsolete. Such a waste. I suppose that company executives and boards of directors are not the only ones subject to a "quarter mentality".In case it could be interesting someone... we have developed applications allowing ABB legacy consoles migration to the new 800xA (VB and PG2 new graphic builder). The migration is 100% guaranteed error free and can be done ON-LINE. We support all legacy consoles versions for MCS, OIS, PCV, CONDUCTOR and PPB. Every dynamic symbols and graphic are perfectly replicated. The migration include taglist, alarm management and historical trend replication. Additional options such as operator keyboard, advanced Harmony popup, Navigation Display Panels, and improved 3D replication is also available.We have many successful major systems completed in North/South America, Europe and Asia...http://www.control.com

30 Oktober 2012

We are using INFI90 DCS in a power plant and we got 4 MFP02 processor modules. These modules goes to fault mode after working for a while.This fault occurs like written below:

Power LED must be normally green but when fault occurs Power LED goes to blinking mode.

MFP02 LED 7 and 8 also turns red. Except these 2 of them there is no Fault LED indication in front panel.

All MFP02 modules have same fault at same time.

We tried to run modules after clearing the memory and downloading the program of modules and we got same fault.

We tried to run modules after loading only configuration and resetting the module and we got same fault.

We checked all electrical connections and we have no abnormality in connections.

We tried to run modules from configuration mode when the module memories are empty and we got same fault.

These faults are not periodically, sometimes it takes 10 mins to go faulty mode or sometimes it takes 1 hour.

I need help about this issue urgently.

Best Regards,SerhanThe status LED is a two-color (red and green) LED. It shows the MFP module operating condition. There are four possible operating conditions:

Off: No power is being supplied to the MFP module. The status LED is momentarily off when the microprocessor initializes on start-up.Solid Green: The MFP module is in execute mode.

Flashing Green: The MFP module is in execute mode but there is an NVRAM checksum error, or the MFP module is in configure or error mode.Solid Red: The MFP module diagnostics have detected a hardware failure, configuration problem, etc. and have stopped the module.Additionally, LEDs 1 through 8 will illuminate in a certain combination to display the error code.

LED's 7 & 8 both Red indicate a Primary module, so based on your stated conditions I can only assume that the module is in Configure mode. Why is another story !Sounds like you might be experiencing a Power Fail Interrupt (PFI). Do you have any communication modules (LIM/BIM, NIS/NPM) or ICT modules? During a PFI those would most likely red light also.

Check all bus voltages (5/15/-15/24) and reply back with values. Since the problem is intermittent, you should probably install a recorder to find out what bus(ses) you are having a problem with.

What type of power supply system and what power supply modules do you have?

How old are the power supplies?we are now having the same problem MFP02. We think is about 5 V p-p voltage drop. It must be just like john's say PFI.

Our plant 15 years oldMeasure the 5V bus value in the PCU cabinet. Use DC Common as the reference. The safest place to do so on an MPSII based system is on the front of the IPMON module - less chance of inducing a short.

The next discussion is based on the MPSII power system, there might be some differences with other systems but you should be able to figure that out.

If less than 5V, at the next opportunity to shut the cabinet down, (1) remove the large cables that connect the power supply with the vertical power bus bar, (2) cut the heat shrink cable off, filling crimped connector with solder, and reapplying heat shrink insulation, (3) reinstalling making sure that you have the proper tooth washers and appropriate torque. As an option to (1) and (2) you can procure new cables from ABB, they are available.

There was at one point in time a bad batch of cables with out of specification crimping, resulting in an abnormally high voltage drop. Loose connections due to vibration over time can also result in a voltage drop that can result in a PFI.

We've got a couple of hundred PCU cabinets and check the various voltages every couple of years, taking corrective action as needed. I can say that in the 10-15 year time frame these things need some attention, even if it is tightening connections. The only problems that we have found have been with the 5V bus, but we still check +15, -15, and 24 also.

Another thing to consider is refreshing the capacitors in the power supply modules. New power supply modules for the MPSII systems are still available from ABB. You can also have your supplies refurbished.

We have had some PFI's occur due to faulty IPSYS01 power supplies, even though they are in a 2N configuration. Running power supplies to end of life can be a matter of saving money now, but causing loss of production later. I believe that the ABB MPSII manual states that an expected life of an IPSYS01 power supply module is 7 or 8 years.We had found temporary solution for voltage drop at 5V. I had supplied 5V 55A externally. After this operation nvrams aren't been erased and blinking green (while system working) matter isn't happen.

But differently from these problems now I am having another problem; while system working normally then suddenly some of the relays opens and closes haphazardly this continue until restart. Some time this occurs after restart, some times 7 hours later, some times 3 month later. What could cause to this? Do you have any idea?http://www.control.com