Re: [foxboro] CP60 giving errors in smon_log and "*" coming in SMDH

We are using, what I would call, a "Hybrid" system here. We have CP60's
connected Spectrum, 100 and 200 series I/O. The CP60's connect via coax
to the back of a 6 port fiber hub. To connect to 100 series I/O we Tee
off the coax connection and extend the coax to Field Bus Isolators. To
connect to our integrated Spectrum I/O we use fiber from the front side
of the hub and connect to DCM10ef's. Finally, for our 200 series I/O we
connect via fiber from the hub to FCM10ef's. At first it can be
confusing, but once you work with it a bit it makes good sense.

To date we have had no problems with the coax side of our installations.
By the way, at our location we have 8 pairs of Fault Tolerant CP60's
connected to 16 fiber hubs. These are connected to 16 DCM10ef's, 8 FBI's
and 14 FCM's.
The main problems I have encountered here is with the twinax connections
between the DCM10ef's and the integrated UCM's. The terminals need to be
retightened on a period basis. As they loosen you begin to see more
errors on those particular stations.

So, I believe you have some options when it comes to eliminating the
coax. However, to eliminate it completely would require upgrading to
FCP's or ZCP's.

As you are all ready aware, the weak link in the coax system is at the
connection points. Did some at your site make up any of your own coax
jumpers or patch cables. If so, I would check those closely for any
flaws.
It could be a simple mechanical problem.

Well, hope this helps you in some way.

Jim Jenckes, CCST
Process Control Specialist
Tesoro Alaska Company
P.O. Box 3369
Kenai, AK 99611
907-776-3865
907-776-3863 Fax
=20
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Corey R Clingo
Sent: Wednesday, February 20, 2008 6:20 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] CP60 giving errors in smon_log and "*" coming in
SMDH

We have had this problem on several CP60s, on 100- and 200-series I/O
(not=20
mixed on any one CP).  Causes have included a bad 200-series FBM, a bad=20
200-series backplane, and a bad CP60, possibly exacerbated by the
software=20
issues Terry alluded to.  We have the issue right now on one CP (fully=20
upgraded with all software fixes) and I'm waiting on a partial plant=20
outage to force a CP primary swap to see if it is the CP this time.  If
it=20
is not, I'll be replacing every terminator and tee in the system, one by

one.  We have already installed the you-gotta-be-kidding-me isolated DIN

rail grounding kludge, though we weren't having problems at the time we=20
did that.

Foxboro made the unfortunate decision to use a coax copper fieldbus on
the=20
CP60.  I have had nothing but trouble with coax on every system I've
seen=20
it on, from cable TV to "thick" ethernet to Arcnet to Honeywell LCN and=20
now CP60 fieldbus.  The more taps/connections you have, the more
problems.=20
 Things like tees and terminators, which should be non-degrading,
passive=20
devices, can cause you problems a year or two after installation.  And=20
unlike Honeywell, Foxboro gives you almost no tools to diagnose these=20
kinds of issues.  I second Terry's comment about converting to fiber,
not=20
so much because of copper ethernet's susceptibility to noise, but
because=20
it reduces the number of coax connection points.  Unfortunately, all the

100-series I/O bridges (FBI10e, DCM10e) are coax-only I believe.


Corey Clingo
BASF Corporation






"Doucet, Terrence" <tdoucet@xxxxxxxxxxxxxxxxxx>=20
Sent by: foxboro-bounce@xxxxxxxxxxxxx
02/20/2008 07:56 AM
Please respond to
foxboro@xxxxxxxxxxxxx


To
<foxboro@xxxxxxxxxxxxx>
cc

Subject
Re: [foxboro] CP60 giving errors in smon_log and "*" coming in SMDH





Kashif,

1. As Kevin points out, there are fixes to various CP60 fieldbus =3D
problems so you need to know everything about your hardware (firmware) =
=3D
in the CP (fault tolerant?)and the FBM's and the FCM's and in copper to
=3D
fibre converters, etc. I believe that there were comments on this site =
=3D
about problems with the HART modules so you need to check that out too.
=3D
Document everything and then check with Foxboro Field Service and ensure
=3D
that every module is at the latest eeprom for your IA version.


2. The copper Ethernet standard is a 1 Volt p-p signal. This is much =3D
lower than the 11 V p-p signal of the legacy fieldbus so stray noise has
=3D
a greater chance to kill your Ethernet signals. Although not =3D
specifically prohibited in Foxboro documentation, copper Ethernet is not
=3D
recommended to go outside an industrial enclosure. See ISA documents.  =
=3D
So if you have copper, outside your main enclosure, you likely need to =
=3D
re-think that and get fibre-optic cables. Verify that you do not violate
=3D
the length of cable specifications.  Make certain that you're A and your
=3D
B fieldbusses are identical. Verify that all copper connectors are =3D
tightly connected to the Ethernet cable shields. Inspect all copper =3D
cables to ensure that they are not coiled and that there are no bumps or
=3D
dents in the insulation. (Sometimes cables can be pinched in a door and
=3D
the insulation is destroyed. Coiled cables are noise traps!) If fibre =
=3D
optic cable is part of your buss, check all for broken connectors. =3D
Verify that any coiled fibre is greater than the minimum coil diameter =
=3D
(likely 15-20 cm). If the Black-Box copper to fibre converter is part of
=3D
your bus, verify (check with a tool) that the copper shield is properly
=3D
grounded.  Take a few minutes and watch the flashing led's to see if =3D
error led's or fault led's are flashing. Check that copper busses are =
=3D
terminated at each physical end and that the resistor is the correct =3D
value.=3D20

Some of this testing may require that you run Fieldbus A only, while you
=3D
test Bus B, and vice-versa. So make sure that Bus A is correctly =3D
identified from start to end. Same check for Bus B since crossed cables
=3D
can be a problem. Can you run a single fieldbus (only) without errors? =
=3D
If yes, let them run that way for a time when you can stay close by the
=3D
system. Check the led's for errors and faults.

A lot of this testing may not be possible on a running process, so you =
=3D
need to be the judge of that. Schedule the testing at the next process =
=3D
shut-down.

3. The STATION display for the CP60 will give you the fieldbus load =3D
(scan). This should be less than 65 and you must not have CP overruns =
=3D
(LBUG_STA:STATION.CUMOVR). IF either of these is a problem, fix them by
=3D
slowing down those ECB's that you can and make tough choices to get =3D
these two items in order.

There are some other parameters that can be read (omgets or put them on
=3D
a display)  STATION.PIOE1R  STATION.PIOEFT  and  STATION.PIOEGB. Report
=3D
these values while running Bus A, then switch to run Bus B and report =
=3D
the values. Compute the counts per hour here so that you know the rate =
=3D
of these counters for each fieldbus.

Terry Doucet



Objet=3DA0: Re: [foxboro] CP60 giving errors in smon_log and "*" coming =
in
=3D
SMDH

Instead of attaching, why don't you put the smon_log files the email?

Also, what CP60 module revision, firmware and software image are you
running?  Do you have PLB blocks in use in the CP60s?

Regards,

Kevin FitzGerrell

On Wed, Feb 20, 2008 at 4:17 PM, Kashif Ijaz <kashifijaz93@xxxxxxxxxxx>
=3D
wrote:
> The CP60 installed at our site are continuously giving erros in =3D
'smon_log' and there is '*' as unacknowledged faults in SMDH.  I have =
=3D
heard these are some inherent noise with CP60s. I have had similar =3D
problems at many sites and have troubleshooted on grounding and ferrite
=3D
cores. Even if we fix all things still the errors are coming.  I am =3D
attaching the smon_log, If anyone can suggest any line of action, Please
=3D
recommend. Regards, Kashif IjazINTECH Process Automation




=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:             http://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:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: