Re: [foxboro] FW: CP40A FT Double Failure
- From: "tjvandew@xxxxxxxxx" <tjvandew@xxxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Fri, 03 Oct 2008 06:04:20 -1000
Andrew,
I am going on memory here but I know I have seen this error before
in my past life at Dow Corning. I'm almost positive it is associated
with the nodebus/Ethernet communication side of things and not the
fieldbus. FTXSS refers to the X-bus FT connector installed behind the
two CP's. Z-Bus communication passes between the two FT CP's via the
front mounted paddle. Ever since CP-30's both are used to keep the pair
Fault Tolerant. From my perspective, only improper evaluation of the X
and Z bus should cause both CP's to quit communicating on the nodebus at
the same time. One or the other of them should have stayed up to carry
on the control of your process. I have a few questions:
What was the front light status of the two CP's after they failed?
Were both CP's Red-Dead, (Red light only on both)?
Was one still green and the other Red light only?
Were both CP's Red/Green Dead, (Red and Green light on both)?
Did you replace one or both CP-40's?
Did the process shutdown simultaneously with the failure?
Do you rely on peer-to-peer between this FT CP and others to accomplish
control?
Do you have a software watch dog that shuts down the process in a CP if
you lose peer-to-peer?
I think my experience was that both CP's were still green but not
communicating on the nodebus but that is from a foggy memory of the
past. We suspected that process control within the CP was till
executing but without nodebus communication to workstation consoles or
system monitor we were unable to verify. The fieldbus isolator lights
connected to the CP's fieldbus were still flashing and that was our clue
that at least one of the CP's was still talking to the fieldbus. We did
not have a software watchdog to shutdown the process on loss of
peer-to-peer communication, (nodebus), with other CP's.
I'm not sure if this is helpful but I don't think both CP's should
fail if one can't communicate with the other across the X/Z bus. That
would kinda defeat the purpose of having Fault Tolerant CP's.
Tom VandeWater
Control Conversions Inc.
Kapolei, Hawaii
andrew.roberts@xxxxxxxxxxxxxx wrote:
> Thanks Terry
>
> I've had a look and since I replaced the CP40A a week ago we've had 40 over
> runs.
>
> With regards the installation this hasn't been touched in a long time - all
> the connectors seemed ok when I replaced the CP40A when they failed.
>
> The loading is about 42% and the total control cycle (% of BPC) is below 50%
> for each cycle
>
> I'll check the fieldbus connections and let you know
>
>
> thanks for your time
>
>
>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
> Behalf Of Doucet, Terrence
> Sent: 03 October 2008 15:24
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] FW: CP40A FT Double Failure
>
> Andrew,
>
> The seven items to check for a "persistent" problem are relatively simple for
> you to check.
>
> The items listed for "transient" problems are not so easy. What is your
> fieldbus load per the station display? Do you regularly get Compound Proc.
> Overruns? The CP40A has likely been in service a long time, is this the
> first such incident? (Thus transient)
>
> Have there been any changes on or near (other equipment added or modified)
> the fieldbus wires in the last little while?
>
> Describe the fieldbus from one terminating resistor to the other resistor.
> You might want to verify that every single connection on the fieldbus is
> tight.
>
> Terry Doucet, Eng.
>
>
> Object : [foxboro] FW: CP40A FT Double Failure
>
>
>
>> A few days ago I had a FT CP40A fail at the same time which caused a
>> plant trip. There was no dump file created so hard to find out what
>> happened.
>>
>> The message that came back on system monitor was:
>>
>> 2008-09-26 21:35:06 34CP05 Error Protocol FTXSS 000005 SSB
>> Input/Output miscompare 00006C073731
>>
>> The details of the CP are:
>> CP Image:QF2001869
>> FT CP40 - P0960JA
>> REV 0D on both
>> There are no dump files under /usr/fox/sysmgm/softmgr/dump
>>
>>
>> As anyone had a double failure like this on their sites or as anyone
>> had this error - on the foxboro web site it says the error could be
>> because of the following - but I've checked the installation and all
>> looks fine.
>>
>>
>> Transient problems with noisy or overloaded nodebus can be fixed by
>> reboot. More persistent problems are caused by:
>> 1. the module not tightly screwed into SSB rack
>> 2. elevator assembly not fully engaged
>> 3. cable and connectors are bad with loose connections
>> 4. cable is damaged by crush or too tight bend radius
>> 5. The X-bus connector is bad or not seated properly
>> 6. The Z-bus connector is bad or not seated properly
>> 7. One of the CP-fault tolerant modules is bad. First replace the
>> shadow then replace the primary. This response lists the root causes
>> of SSB miscompares.
>>
>> Any suggestions or information on other people who have had a double
>> failure would be appreciated - trying to find out how common this is
>> for a site investigation
>>
>>
>> Thanks
>> Andrew
>> Andrew Roberts,
>>
>
>
> _______________________________________________________________________
> 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
>
>
>
>
> _______________________________________________________________________
> 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
>
>
>
_______________________________________________________________________
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:
