Re: [foxboro] Triconex & Foxboro Questions
- From: "Pablo Lioi" <plioi@xxxxxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Fri, 10 Aug 2007 19:54:30 +0200
Tom,
We have 2 small I/A-Triconex systems and a medium-size one with redundant
ACMinterfaces (3 separate systems).
In the small systems we have several peer-to-peer links between the ACM and
some GW30 processors. These systems are installed in off-shore oil &gas
platforms. The problem we have here is that when we have a power failure and
the system de-energizes, upon restart peer-to-peer conections are broken.
Theonly way to restore these connections is checkpointing all the
processors.Sometimes there is no tech personnel available at the platforms,
so we implemented some screen buttons that allow the platform operator to
checkpoint the processors one by one. A work-around, but not a clean
solution.
In the medium-size system we had a different problem: repetitive "Nodebus
Cable" alarms, slow communications,foxview timeouts, and sometimes complete
loss of communications, only restored after recycling power to the system.
Foxboro personnel reinstalled the system completely (AW and WP's), applied
the latest quickfixes and processor images, etc. AND PULLED OUT ONE OF THE
ACM's, LEAVING ONLY ONE IN OPERATION. After this we never had the timeouts
again and the number of "Nodebus Cable" alarms went down dramatically.
According to my information, the redundancy functions of the ACM are
implemented not through the Triconex backplane but through the I/A node,
which might be the source of the problem. We never pushed the second ACM
backin place, so you may argue that I cannot be sure this was the cause of
our problems. OK, but I cannot risk having to stop the plant again so that a
Foxboro product starts communicating with another Foxboro product again.
We have been using the ACM's for the last 3 years.
As regards as Triconex modules failures:
I've had field-related module "failures". But when you replace a module and
the new module never fails again, and the old one does, you know for sure
that the problem is in the module.
I've had failures in HDAI modules, SDI modules, one 3006 processor and
several ENHANCED ISOLATED ANALOG INPUT modules. In all cases, the error
description doesn't help much (for example, "Sanity test failed" or "Integer
value (something I don't remember)"), I couldn't find any further detail in
the manuals and the only recommended action is "replace module".
Tired of these failures, I decided to have a look inside the module with the
highest failure rate: the 3703E ENHANCED ISOLATED ANALOG INPUT module. To my
surprise, I found that it only has 3 A/D converters multiplexed for the 16
channels. (Previouly I had been convinced that they had 3 A/D per channel).
For each A/D converter they have one DC/DC power supply and apparently, one
of them was broken, so all channels are affected.
I also found other things. For example, it looks as if the PCB had some
mistake in 8 trails connecting 8 pins of 2 IC's. So they cut the trails in
the PCB and connected the ICs with small isolated wires (and after that
gluedthe cables to the IC's and motherboard so that they don't move).
Regards
Pablo Lioi
----------------------------------------------------------------------------
From: <tom.vandewater@xxxxxxxxxxxxxx>
Reply-To: foxboro@xxxxxxxxxxxxx
To: <foxboro@xxxxxxxxxxxxx>
Subject: Re: [foxboro] Triconex &Foxboro Questions
Date: Fri, 10 Aug 2007 08:40:13 -0400
>Pablo,
>I'm interested to hear what kind of problems you are having with
>the ACM modules/Foxguard interface. Is it mostly associated with
>keeping them redundant? That has always seemed to be Foxboro's problem.
>Their redundancy schemes have, at times, created more problems than they
>are worth. We have been using ACM/Foxguard in a single mode for over 5
>years in our plant and they have been extremely reliable. We have felt
>no need to make them redundant. Are other Triconex modules actually
>failing? If so, is there a particular module that is repetitively
>failing? We have found that the I/O cards can give an error when field
>devices are disconnected or failed. The errors were cryptic and at
>first we thought it was a problem with the card but later understood it
>was the card complaining about a bad I/O point. We are using five
>TRICON's to provide SIS protection for most of our plant and so far they
>seem very reliable. How long have you been using the ACM's?
>You said:
>"The GW30 solution is not so clean as the ACM, but it works, as long as
>you keep your database size within certain limits. The best solution
>should be the FCP/FDSI combination, but we are starting this system now,
>so I don't have much experience yet."
>I think as you dig into the configuration of the FDSI FBM231 or
>FBM232 you will find it to be even more complicated and tedious as the
>GW30. Like the GW30 interface, the FDSI doesn't give you any System
>Monitor diagnostics as the Foxguard does. It may be possible to map
>some of that status information but it is there by default with the ACM
>interface. It should be known that the analog input blocks in the FDSI
>are RIN's with no alarming or conditioning capability. For alarms you
>have to add another block. The AIN blocks in the ACM/Foxguard interface
>are connected directly to the point number of an I/O module, exactly
>like connecting to a point on an FBM. The RIN blocks are connected to a
>TRICON alias that adheres to Modbus mapping but the output of the RIN
>must then be sent to an AIN block if you want to do any alarming or
>special signal conditioning.
>I had big hopes for the FDSI interfaces but so far they are more
>of a kludge than they are worth. I think Foxboro will hear the message
>and improve the interface over time. As for us, we are waiting for that
>time.
>
>Tom VandeWater
>Control Systems Developer/Analyst
>Dow Corning Corporation
>Carrollton, KY USA
>
>-----Original Message-----
>From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
>On Behalf Of Pablo Lioi
>Sent: Friday, August 10, 2007 7:37 AM
>To: foxboro@xxxxxxxxxxxxx
>Subject: Re: [foxboro] Triconex &Foxboro Questions
>
>=20
>
>George,=20
>
>We have 5 Triconex/Foxboro systems in our plants.=20
>
>In 3 of them, communication is accomplished via redundant ACM modules,
>an
>older system is communicating via redundant GW30 processors and a new
>one
>with a FCP/FDSI combination.=20
>
>My advise: stay away from the ACM - It will make your life miserable, no
>matter what Foxboro says, specially if you go to the redundant solution.
>The
>GW30 solution is not so clean as the ACM, but it works, as long as you
>keep
>your database size within certain limits. The best solution should be
>the
>FCP/FDSI combination, but we are starting this system now, so I don't
>have
>much experience yet.=20
>
>And make sure you buy some spare Triconex modules. It is my experience
>that
>they have a higher failure rate than any other PLC I know (don't worry -
>yourplant will keep running and you will be able to replace the module
>with
>ahealthy one using the spare slot, as long as the module is a TMR one).=20
>
>Regards=20
>
>Pablo Lioi
>
>------------------------------------------------------------------------
>----
>FREE pop-up blocking with the new MSN Toolbar MSN Toolbar[1] Get it now!
>
>
>--- Links ---
> 1 http://g.msn.com/8HMBEN/2755??PS=3D47575
>=20
>=20
>_______________________________________________________________________
>This mailing list is neither sponsored nor endorsed by Invensys Process
>Systems (formerly The Foxboro Company). Use the info you obtain here at
>your own risks. Read http://www.thecassandraproject.org/disclaimer.html
>=20
>foxboro mailing list: //www.freelists.org/list/foxboro
>to subscribe: =
>mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
>to unsubscribe: =
>mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
>=20
>
>
>_______________________________________________________________________
>This mailing list is neither sponsored nor endorsed by Invensys Process
>Systems (formerly The Foxboro Company). Use the info you obtain here at
>your own risks. Read http://www.thecassandraproject.org/disclaimer.html
>
>foxboro mailing list: //www.freelists.org/list/foxboro
>to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
>to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
>
----------------------------------------------------------------------------
Don't just search. Find. MSN Search[1] Check out the new MSN Search!
--- Links ---
1 http://g.msn.com/8HMBEN/2749??PS=47575
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
