Re: [foxboro] CP60 and FBM legacy
- From: "Johnson, Alex P (IPS)" <alex.johnson@xxxxxxxxxxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Fri, 21 Oct 2005 11:14:30 -0400
Order of the DCM/FCMs also matters to leverage the parallelism.
You should list the ECBs for the FCM/DCMs in order by most FBMs "beneath"
them, i.e., shorter chains first.
The CP sends out a message across the set of FCM/DCMs. Then it comes back an
queries them in the order that they are listed in the ECB compound. If the
FCM/DCM is not ready, the CP waits and retries.
Thus, putting the short chains first will yield the best results because it
leaves time for the longer chains to process.
Make sense?
Regards,
Alex Johnson
Invensys Systems, Inc.
10707 Haddington
Houston, TX 77063
+1 713 722 2859 (voice)
+1 713 932 0222 (fax)
+1 713 722 2700 (switchboard)
alex.johnson@xxxxxxxxxxxxxxxx
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Corey R Clingo
Sent: Friday, October 21, 2005 5:05 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] CP60 and FBM legacy
This is probably true, but for better or worse, site practice here is to
put all the ECBs in the STATION_ECB compound, so we can refer in IOM_ID to
the letterbug only, and not have to use COMPOUND:ECB. Since we may scan
blocks at intervals from BPC up to seconds, we scan the ECBs at BPC as
well to avoid problems (though I don't personally have any 0.1-sec BPC
applications; I don't know what people here do in that case).
And Alex responded: "The CP60 will outperform in all respects CP40As if the
I/O chain is split
across multiple FCMs/DCMs."
To achieve this, how much does one typically have to divide the legacy
fieldbus across DCMs? Two 1x8's per DCM pair? One? The CP60s I have
certainly seem capable of outperforming CP40As; the ones I have with
200-series I/O handle a pretty heavy IO load (including FBM224s) well. And
others definitely outperform the CP30As I replaced (I used 1 FBI10E pair
per two 1x8s). But in the one case I mentioned, the legacy fieldbus was
split across 3 DCM pairs (not sure how many 1x8s total), and the idle time
went down relative to the old CP40A. May be an isolated case, but
checking the spreadsheet as Terry suggests is probably a good idea.
Corey
"Doucet, Terrence" <tdoucet@xxxxxxxxxxxxxxxxxx>
Sent by: foxboro-bounce@xxxxxxxxxxxxx
10/21/2005 09:43 AM
Please respond to foxboro
To: foxboro
cc:
Subject: Re: [foxboro] CP60 and FBM legacy
Troy,
People should use the CP60 loading spreadsheet on the EDOC CD to
perform their "what if" analysis. I suspect that this spreadsheet will
show Jaime's CP60 fieldbus - overloaded. Although this thread started
out as a loading question that has been answered by Alex, you now bring
up a side issue that can affect systems.
The best performance comes when FBM's (ECB's) run at the same scan rate =
as the blocks. For example - FBM04 (mA) at 1.0 sec to AIN at 1.0 sec to =
PID at
1.0 sec to AOUT at 1.0 sec back to FBM04 (could be different l'bug) with =
ECB
at 1 sec. You can phase the blocks if the basic processing cycle =
(BPC)is
0.5 seconds and as long as you set the PRI correctly, all is OK.
If you run your ECB's at 0.5 seconds in the above example, your 1 s AIN =
will
ignore half the mA input changes. On fast changing signals, this might
get you in trouble. If the signal is not fast changing, then you could =
be
OK. You can run all at 0.5 sec but you need to carefully check loading.
In any case, you never want to overload your CP.
Regards,
Terry
_______________________________________________________________________
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:
