Re: [foxboro] CP40 to CP60 Fieldbus upgrade
- From: tom.vandewater@xxxxxxxxxxxxxx
- To: foxboro@xxxxxxxxxxxxx
- Date: Wed, 28 Jan 2004 17:30:36 -0500
If you are running sequences in one CP that are getting or setting
values in another CP that will create the problems you describe. gets and
sets work differently than peer to peer parameter connections that use an
object manager table. Gets or sets within the same CP are not a problem
because they access the values from local memory but a get or set across CP
boundaries from a sequence has the same effect as a WAIT statement because
the sequence has to wait while a nodebus or possibly carrierband
communication transaction takes place before it can proceed to the next
statement.
If you have multiple actions that you want to take place and are
using gets or sets back to back in the sequence code it will really slow the
sequence down. To avoid that issue, you can make what we call "hard"
connections from the sequence input or output parameters, (BI0001-24,
BO0001-16, RI0001-15, RO0001-15) to appropriate parameters of the blocks in
the other CP. This creates a permanent object manager table in both the
source and sink CP memory. The sequence then reads/gets the values from the
other CP via its local memory resident object manager and writes/sets values
that its object manager table will pass to the remote CP whenever the change
delta is met. It is important that you understand block change deltas when
making peer to peer "hard" connections but if you can connect in this
fashion instead of using gets/sets it will make a world of difference in how
fast your sequences run.
If this isn't your problem you may be experiencing nodebus switching
issues in such a way that CP1 thinks "A" is bad and begins transmitting on
"B" nodebus and CP2 is transmitting on "A" nodebus. They should both be
able to listen on either bus but it doesn't seem to really work well that
way. You may not be able to see any nodebus failure messages from SMDH that
lets you know what is going on. We experienced that with nodes that were
using nodebus extenders in conjunction with high bursts of AW traffic. The
nodebus extenders sent jamming signals when they experienced collisions and
it appeared that the CP-60's timed out and switched to the other bus before
the jamming stopped. We recently eliminated all nodebus extenders or
replaced them with NCNI's and our problems went away. Other symptoms we saw
with nodebus extenders were high 802.3 MAC Resets and FT modules going non
FT, especially FT CBLAN modules.
I hope one of these conditions explains your problem and you are
able to fix it. At any rate, let all of us know what the final solution is.
Thanks,
Tom VandeWater
Control Systems Developer/Analyst
Dow Corning Corp.
Carrollton, KY USA
P.S. I'd be very interested in knowing what the fieldbus scan loading as
viewed through the CP60 Station block is for the one that has 68 devices on
the fieldbus all communicating via one set of DCM's.
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx
[mailto:foxboro-bounce@xxxxxxxxxxxxx]On Behalf Of spersico
Sent: Wednesday, January 28, 2004 11:23 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] CP40 to CP60 Fieldbus upgrade
Anyone experienced a CP DELAY problem on new 60 h/w ???
I 've replaceded a single CP40A with a 60 with a single couple of DCM10e.
I've about 68 devices on fieldbus (6 CORIOLIS, 12 HTG, and rest of Y-FBM
divided into 3 FBI).
Many SEQ on CP. While the total loading still be the same (or quite better)
i'm experiencing an horrible CP DELAY in comunication to devices on other CP
fieldbus.
This problem start every time i make a compilation on seq or simply an
operation on ICC and grow up with time.
The strange thing is that SEQ manage valve, pumps and other on own fieldbus
normally while the same operation on other CP is slooooooow !!!!!
Planned to change h/w rev of CP (now a G)
Other CP 60 with less FBM but same n° of SEQ run normally (REV L & M)
Try to think about CSIZE/CSPACE params
Suggestions ????
tom.vandewater@xxxxxxxxxxxxxx scrive:
> FYI,
> We used 5 CP60's to replace 19 CP10's and 7 CP30's communicating
> with a "bunch" of 100 series, (legacy), FBM's. We used one set of
> DCM's/CP60 and combined the seperate fieldbusses by attaching multiple
> legacy FBI's in series with the DCM using the old twisted pair "twinax".
> The most 100 series FBM's that we have communicating to a CP60 via one set
> of DCM's is 57. The fieldbus scan loading as viewed through the CP60
> Station block is 60%, which is a lot higher than I really want but the
> Control loading, Cont. + Seq. is less than 10% and the station idle time
is
> still 79%!! I am not experiencing any processor overruns so the CP60 can
> really get with it compared to the old stations.
> If you have more than 60 legacy FBM's and think you will want to
> expand I/O on the CP in the future, I would suggest replacing the FBI's
with
> FBI10E's. You could put in multiple DCM's to connect to the FBI's in each
> fieldbus enclosure but it is cleaner just using the FBI10E to replace both
> DCM's and legacy FBI's. This will reduce your fieldbus scan loading
> considerably. We have one CP60 that communicates to 96 legacy FBM's via 6
> FBI10E segments and nine 200 series FBM's via 3 FCM fieldbus segments and
> the fieldbus scan loading is only 35%!
> The single DCM solution was a lot cheaper for us because we already
> had a bunch of legacy FBI's in place and had spares that could be
installed
> where needed. If I had to buy the legacy FBI's anyway I would definitely
> buy FBI10E's. Hope this is helpful.
>
> Tom VandeWater
> Control Systems Developer/Analyst
> Dow Corning Corp.
> Carrollton, KY USA
>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx
> [mailto:foxboro-bounce@xxxxxxxxxxxxx]On Behalf Of Ken Heywood
> Sent: Monday, January 26, 2004 1:10 PM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] CP40 to CP60 Fieldbus upgrade
>
>
> Depends upon why you are upgrading to the CP60 ...
>
> If you are upgrading to get better throughput or add more FBMs =
> (including the 200 series), then you need to string coax and replace the =
> FBIs with DCMs. You'll be able to use up to 120 FBMs because the DCMs =
> store and forward Fieldbus messages (that's where you get the =
> performance increase on the 10Mbps line).
>
> If you just want the latest hardware and no plans for expansion, mount =
> the DCMs near the CP60 and drive your existing twinax. You'll get no =
> increase in performance out of the I/O (although you will have more =
> block capacity and CPU throughput).
>
> * K
>
>
>> -----Original Message-----
>> From: Bismarck Alban [mailto:balban@xxxxxxxxxxxxxxxx]
>> Sent: Monday, January 26, 2004 12:58 PM
>> To: foxboro@xxxxxxxxxxxxx
>> Subject: [foxboro] CP40 to CP60 Fieldbus upgrade
>>=20
>>=20
>>=20
>> Hi everyone
>>=20
>> I=B4m looking for upgrade a CP40FT to CP60FT.
>> Actually, the CP40FT (attach: old_system.gif) have some
>> remote enclosures with Fieldbus Isolators Modules (FBI) and about
>> 12 FBMs at each one.
>> The questions are:
>> 1. could I maintain the existent FBI (as attach: new_system.gif)?
>> 2. should i change all existent FBI to FBI10E?
>> 3. should i change the existent Twisted pair shielding cable=20
>> between the
>> enclosures to 50 ohm coaxial cable?
>>=20
>> Thanks for any suggestion
>>=20
>> Bismarck Alb=E1n
>> Tecniequipos S.A.
>>=20
>>=20
>> =20
>> =20
>> ______________________________________________________________
>> _________
>> This mailing list is neither sponsored nor endorsed by=20
>> Invensys Process
>> Systems (formerly The Foxboro Company). Use the info you=20
>> obtain here at
>> your own risks. Read=20
> 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
>
>
>
> _______________________________________________________________________
> 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:
