Re: [foxboro] FCP's vs. ZCP selection on new projects
- From: "Deathos, Matthew" <matthew.deathos@xxxxxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Thu, 16 Aug 2007 13:26:06 -0400
Group,
The following is essentially the response that I made to Tom VandeWater
at Dow Corning based on his request below. He asked that I post it to
the group to the benefit of everyone. I hope it helps.
Regards,
Matt =
----------------
Tom,
I have been monitoring the conversations in Cassandra, so I want to
address one of the other topics first. =
The FBM limit on the FCP270 should be taken as the 64 FBMs as specified
in the PSS. I echo strongly the statements that Russ and Alex have made
that the limit is 64. I know for a fact that if an FCP is loaded with
128 of a typical mix of non-digital protocol FBMs, and the normal block
to IO ratio of 3 to 4, that there will not be sufficient performance in
the FCP to handle it. (confirming your speculations) The 128 connection
limit was put in place to eliminate hardware as a reason to limit the
FCP capacity, and if a customer wanted to connect IO at slower speeds
(say 2-5 seconds) for data acquisition purposes then they would have
that ability. But also, if a customer has 64 FBMs on an FCP currently
and they see that there is spare IO and block load capacity on the FCP,
they will be able to add a 65 or 66 FBM without needing to add a
controller or ask for special dispensation from Foxboro to do so.
Now to your questions:
The 128 limit for 200 series FBMs on a ZCP270 is a specification listed
in the PSS and this is the limit that has been tested and will be
supported via TAC. Exceeding these limits may make it difficult for any
problems to be diagnosed and supported via the TAC Center, so we
strongly do not recommend exceeding them.
However... if you do exceed those ZCP limits, the system will likely
work especially for just a couple modules, but it is untested
functionality so unforeseen limits may be hit that are unrelated to
performance and the number of FBMs specifically. (block size and
execution limits, IPC, OM scanner tables, and other more esoteric
aspects for instance) Performance, of course, will be a major stumbling
block related not only to the traffic on the IO fieldbus, but also in
block performance to support the number of blocks required for that IO
quantity.
So if you hit the 128 FBM limit, and you are contemplating exceeding it,
I would be extremely cautious in doing so. And you do it at your own
risk.
Next question...
As far as qualifying the system to exceed the limit, it is difficult to
speculate how much work it would be and of course it depends on how many
additional FBMs would be required (150 from your note below). We have
found very few customers who are interested in exceeding that quantity
of IO on a single controller. Most customers seem to prefer to segment
their plant into distinct controllers so as to minimize the plant impact
in case of operational issues with a particular controller. I do
understand though your desire to minimize peer-to-peer comms due to your
use of sequence blocks and one-shot sets and gets and the load that
feature that puts on the system/network.
But back to the question, as I said it is difficult to speculate what
exceeding these limits would do, because the load increase on the IO bus
is only the beginning of the potential issue. Other bottlenecks in the
system would likely be hit that would require investigation as to how
and if they could be exceeded. A program would start specifying the
number of IO that is desired, loading up a system to that number of IO
and other reasonable supporting configurations (displays, blocks,
peer-to-peer, historians, etc.) and then run it through a full
regression test of the system, and evaluate key systems to see what sort
of tolerance margins are seen. And if problems ensue, which are likely,
then it would take development resources to investigate, do risk
assessments and project estimates to enhance the product to overcome the
limit. Depending on what they find, it could be significant effort or
nearly impossible to do.
This sort of activity would be difficult to sponsor as it would consume
much of the testing organization's hardware resources for a period of
time (stalling current programs) or would require specifying,
purchasing, and building a new lab for this purpose. Further, in my
opinion, it is unlikely that we would invest development budget to
pursue such an activity.
Question 3:
In a broad sense, your speculations resemble those by many of us
internally in terms of where we think Foxboro should go in the future.
There are many factors to consider though, and what make sense today
changes over time. That's about as much as I can say. This answer is
highly speculative and deliberately vague. I'm sorry but these sorts of
discussions are dangerous in setting incorrect customer expectations,
and I have been burned in the past by engaging in them too freely. =
Regards,
Matt DeAthos
IA Series Product Management
-----Original Message-----
From: tom.vandewater@xxxxxxxxxxxxxx
[mailto:tom.vandewater@xxxxxxxxxxxxxx]
Sent: Tuesday, August 14, 2007 12:32 PM
To: Deathos, Matthew
Cc: Thomas, Bill
Subject: RE: [foxboro] FCP's vs. ZCP selection on new projects
Matt,
Tom VandeWater here. You may have been following this thread on
the Cassandra mail list. If not here are my questions?
Is the 128 FBM limitation a gospel rule or could a user add more than
that to a ZCP today?
If it is a hard and fast rule, how difficult would it be to modify from
Foxboro's perspective to allow a larger number of FBM's?
Is there a CP with ZCP capabilities built in the form factor of an FCP
being visualized in the future?
Read on below for a better understanding of why I'm interested in this.
Thanks for any feedback or insight you may have.
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of tom.vandewater@xxxxxxxxxxxxxx
Sent: Tuesday, August 14, 2007 12:44 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] FCP's vs. ZCP selection on new projects
Alex,
I understand the reasons for your response and have contacted
Matt off list with my questions and requests. From my observation,
several people on the list would like to see ZCP functionality in the
FCP form factor. That has spurred Foxboro to try to expand the number
of FBM's an FCP can host. I'm skeptical of whether an FCP would be very
useable when hosting 128 FBM's, even across a 2MB/s RS485 bus. I am
leery of sinking a lot of eggs in the FCP basket. I had a similar
feeling about the Micro IA offering that was supposed to be a low cost
control alternative, much like the FCP. We avoided them like the plague
and now I am forever thankful.
Tom
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Johnson, Alex P (IPS)
Sent: Tuesday, August 14, 2007 11:42 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] FCP's vs. ZCP selection on new projects
The 128 FBM limit is the published specification. =3D3D
I'm not going to make any comments on whether or not one can violation
our specification without consequences because I'm not that crazy. :)
As far as changing the limit is concerned, you'd have to take that up
with Marketing - Matt DeAthos and Betty-Naylor.
I hope this helps and I do understand the issue.
Regards,
Alex Johnson
Invensys Systems, Inc.
10900 Equity Drive
Houston, TX 77041
713.329.8472 (voice)
713.329.1700 (fax)
713.329.1600 (switchboard)
alex.johnson@xxxxxxxxxxxxxxxx
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of tom.vandewater@xxxxxxxxxxxxxx
Sent: Tuesday, August 14, 2007 11:17 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] FCP's vs. ZCP selection on new projects
Below is an actual case study based on our experience with
CP-60's. We initially used multiple FBI10E's, (10MB E-Net to 268KBS
RS-485), to communicate with our 100 series I/O. We limited each FBI10E
to host no more than 24 FBM's. We were able to communicate with 120
FBM's and the Fieldbus scan as a percentage of Total Control Cycle was
only 32 percent, or about .25 percent loading per attached FBM.
Being good customers, we complained about the cost of all the FBI10E's
and the clumsiness of the thin net to connect them to the CP-60
fieldbus.
Foxboro responded and said we could save a lot of money and thin
net if we used one set of DCM10E's, (10MB E-Net to 268KBS RS-485), and
connected all of our pre-existing old style FBI segments to it using the
same Belden twin-ax that was in place from previous CP10's, 30's, and
40's. We said that sounds great and we installed it that way. We were
able to communicate with 59 FBM's and the Fieldbus scan as a percentage
of Total Control Cycle was 55 percent, or about 1.00 percent loading per
attached FBM. In addition, we had huge numbers of fieldbus
communication errors on the CP using the DCM in this arrangement.
Alex said in his note on this subject:
"a lot of the I/O performance of the ZCP comes from a strong
co-processor in the box plus the parallelism of the FCMs."
I am sure he is correct. As such there should be no expectation that a
FCP using today's design will ever be a suitable replacement to
communicate with as much I/O as a ZCP. I expect that trying to
communicate with 120 FBM's via a single 2MB/s RS485 fieldbus used by the
FCP will be about "ONE FOURTH" as efficient as using distributed FCM100
segments communicating at 100MB/s to a ZCP so everyone should be aware
of that very real limitation.
Corey Clingo summed it up best for me when he said:
"Like Tom, I like the ZCP's capabilities and the FCP's form factor."
Here are more specific reasons for my request: =3D3D3D20
Using the 200 series baseplates and I/O form factor, (less
depth), we have been able to achieve double sided, (back-to-back),
mounting in the same 19" rack. That allows us to share power
distribution and fiber communication infrastructure over 8 baseplates
instead of 4 1x8's like we used in the past for 100 series I/O. With an
FCP form factor we could mount the CP's in the same rack space. The
depth of the 1x8's used for the ZCP's takes up the entire space,
(front-to-back), in a standard 19" rack.
In addition, our processes are large enough to require 80 to 150
FBM's. This is too much for an FCP, but we now see that a ZCP could
easily handle that kind of load. One of our ZCP's communicates with 82
200 series FBM's and uses 20 percent for field bus scan. Again, about
0.25 percent loading per attached FBM. There is an advantage for us to
be able to fit each process in its own CP. Peer-to-peer becomes more
undesirable as we increase our sequence automation. Change deltas and
timing for values being passed between CP's is an issue with
peer-to-peer but if all control for a process is in one CP there is no
need to use object manager resources to get and set the values and a
more timely and robust execution is achieved. That is my reason for
wanting Foxboro to allow a larger number of FBM's connected to a ZCP
that can clearly handle the additional load.
Questions to Alex or Russ:
Is the 128 FBM limitation a gospel rule or could a user add more than
that to a ZCP today?
If it is a hard and fast rule, how difficult would it be to modify from
Foxboro's perspective to allow a larger number of FBM's?
Thanks again for any feedback,
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 Boulay, Russ
Sent: Tuesday, August 14, 2007 8:05 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] FCP's vs. ZCP selection on new projects
The FCP270 uses FEM100's to go beyond 32 FBM's
With the FEM100 only one pair is allowed. 4 ports going to 4 basplates
each.
So, FEM100 is trying to do all the work.
So, number per sizing spreadsheet will vary from 64 to 128 FBM's
depending on what your asking the FCP to do.
The ZCP270 can use multiple pairs of FCM100's to split it's fieldbus
load.
32 FBM's per FCM100
Multiple FCM100's drops the I/O load on a ZCP
Thus allowing more FBM's
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Kinsinger, Matthew R
Sent: Tuesday, August 14, 2007 7:58 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] FCP's vs. ZCP selection on new projects
I took a class at Foxboro last week. We were interested in the new V8
=3D3D3D3D3D
stuff and learning about IACC so I only took 2001V8. Alan Leslie, the
=3D3D3D3D3D
person teaching the course, made it very clear the FCP270 now supports
=3D3D3D3D3D
128x 200 series FBMs and 64 100 series. I notice many of you are still
=3D3D3D3D3D
focusing on the original 32 then 64 200 series supported. =3D3D3D3D3D20
With the 128 supported, is the FCP still using FEM's instead of FCM's?
=3D3D3D3D3D
Is that the limiting difference?
Matt Kinsinger
Process Control Engineer=3D3D3D3D3D20
PPG Barberton
330-825-1208
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
=3D3D3D3D3D
On Behalf Of Corey R Clingo
Sent: Tuesday, August 14, 2007 1:51 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] FCP's vs. ZCP selection on new projects
I've been watching this whole FCP vs. ZCP discussion with some interest.
=3D3D3D3D3D
It seems to me on the surface that control system vendors today are =3D
=3D3D3D
=3D3D3D3D3D
going=3D3D3D3D3D20
to a model of more controllers with fewer I/O cards per controller,
I=3D3D3D3D3D20
presume to "reserve" more power in the controller for advanced =3D3D3D3D3D
algorithms=3D3D3D3D3D20
as well as simplify the system architecture (particularly if they
don't=3D3D3D3D3D20
allow I/O remote from the controller at all). Of course as you split
=3D3D3D3D3D
your=3D3D3D3D3D20
plant amongst more controllers, the amount of peer-to-peer you end
up=3D3D3D3D3D20
doing probably increases. I wonder how the industry in general is
=3D3D3D3D3D
dealing=3D3D3D3D3D20
with that (besides going to faster networks, of course).
I don't have any CPs right now that have more than 61 FBMs, but if the
=3D3D3D3D3D
FCP=3D3D3D3D3D20
is limited to 64, I would likely split a 50+ FBM CP40 up into two FCPs
=3D3D3D3D3D
if=3D3D3D3D3D20
I were going to use those, just so I could have a few more spare I/O.
=3D3D3D3D3D
I'd=3D3D3D3D3D20
probably end up doing some more P2P though to effect that split. P2P
=3D3D3D3D3D
has=3D3D3D3D3D20
worked well for me in the past, but I use it sparingly. Is it any
=3D3D3D3D3D
better=3D3D3D3D3D20
on the FCP than, say, a CP60?
Like Tom, I like the ZCP's capabilities and the FCP's form factor.
Corey Clingo
BASF Corporation
"Johnson, Alex P \(IPS\)" <alex.johnson@xxxxxxxxxxxxxxxx>=3D3D3D3D3D20
Sent by: foxboro-bounce@xxxxxxxxxxxxx
08/13/2007 11:11 PM
Please respond to
foxboro@xxxxxxxxxxxxx
To
<foxboro@xxxxxxxxxxxxx>
cc
Subject
Re: [foxboro] FCP's vs. ZCP selection on new projects
I'll give it a try.
Re: I guess the FCP's were initially developed as a lower cost
alternative.
True. They were also expected to serve as a way to enter new markets
once they are self-hosting.
Re: It is my understanding that the the FCP's have the same
horsepower with the exception that they don't have fast =3D3D3D3D3D3D
Ethernet fieldbus communication. =3D3D3D3D3D3D
True enough, but a lot of the I/O performance of the ZCP comes from a
strong co-processor in the box plus the parallelism of the FCMs.
Re: Adding that capability would make the FCP's a lot more flexible and
would make it easier for them to communicate with multiple
distributed
segments of I/O in the same way as the ZCP's
The original plan was to offer three CP270s:
1) Field mounted (FCP) for use in situations where the controller would
be
Field mounted.
2) Z-module (ZCP) form factor to allow the reuse of the cabinets and
=3D3D3D3D3D3D
power supplies owned by our installed base.
3) Rack mounted (RCP) which was to be - basically - ZCP in a DIN rail
mounted tin can.
We built the first two. I suppose one could argue about the product mix,
but we felt the ZCP was important to the installed base.
Clearly as we look forward to new CP hardware, the mix may change.
Re: PSSs
The specification sheets are correct.
Re: Does Foxboro have plans to release a CP in the FCP form factor that
uses
a Fast Ethernet Fieldbus?
Not in the near term.
Re: Has Foxboro considered increasing the number of FBM's that a ZCP can
communicate with?
It has been stressed test well beyond 128, but we don't see a compelling
reason to increase the published limit on the ZCP. =3D3D3D3D3D3D
Most new jobs find the FCP to offer a better $ per I/O point ratio.
Moreover, even in the installed base, a large number locations are
interested in using the FCP to free space in their rack room. An FCM
takes the same space as an FCP so unless there is a truly compelling
reason, most folks don't use the ZCP. They remove the old racks and use
the FCP.
Given the above, we've worked to improve the $ per I/O point ratio of
the FCP as being the best short-term approach for our clients.
Regards,
Alex Johnson
Invensys Systems, Inc.
10900 Equity Drive
Houston, TX 77041
713.329.8472 (voice)
713.329.1700 (fax)
713.329.1600 (switchboard)
alex.johnson@xxxxxxxxxxxxxxxx
=3D3D3D3D3D20
=3D3D3D3D3D20
_______________________________________________________________________
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
=3D3D3D3D3D20
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: =3D3D3D3D3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D3D3D3D3Djoin
to unsubscribe: =3D3D3D3D3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D3D3D3D3Dleave
=3D3D3D3D3D20
=3D3D3D3D
=3D3D3D3D
_______________________________________________________________________
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
=3D3D3D3D
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D3D3D3Djoin
to unsubscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D3D3D3Dleave
=3D3D3D3D
Confidentiality Notice:
The information contained in this electronic message and any
attachment(s) =3D3D3D3D
to this message are intended for the exclusive use of the recipient(s)
and =3D3D3D3D
may contain confidential, privileged or proprietary information. If you
are=3D3D3D3D
not the intended recipient, please notify the sender immediately,
delete a=3D3D3D3D
ll copies of this message and any attachment(s). Any other use of the
E-Mai=3D3D3D3D
l by you is prohibited.
=3D3D3D20
=3D3D3D20
_______________________________________________________________________
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
=3D3D3D20
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: =3D3D3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D3D3Djoin
to unsubscribe: =3D3D3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D3D3Dleave
=3D3D3D20
=3D3D
=3D3D
_______________________________________________________________________
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
=3D3D
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D3Djoin
to unsubscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D3Dleave
=3D3D
Confidentiality Notice:
The information contained in this electronic message and any
attachment(s) =3D3D
to this message are intended for the exclusive use of the recipient(s)
and =3D3D
may contain confidential, privileged or proprietary information. If you
are=3D3D
not the intended recipient, please notify the sender immediately,
delete a=3D3D
ll copies of this message and any attachment(s). Any other use of the
E-Mai=3D3D
l by you is prohibited.
=3D20
=3D20
_______________________________________________________________________
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
=3D20
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: =3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Djoin
to unsubscribe: =3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Dleave
=3D20
=
=
_______________________________________________________________________
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=3Djoin
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
=
Confidentiality Notice:
The information contained in this electronic message and any attachment(s) =
to this message are intended for the exclusive use of the recipient(s) and =
may contain confidential, privileged or proprietary information. If you are=
not the intended recipient, please notify the sender immediately, delete a=
ll copies of this message and any attachment(s). Any other use of the E-Mai=
l by you is prohibited.
_______________________________________________________________________
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:
