Re: [foxboro] Grouping for compounds

This was done back in 2003 on a project in one of my plants.  1 compound 
for analog, 1 for discrete, and one for CALC-ish blocks (!).

IMHO, it's a drag.


We don't have the alarm destination issues, as the 3 compounds all refer 
to the same section of the plant.  But the switching back and forth 
between compounds in Select, and having to use full pathnames on every 
connection between different block types, is enough to convince me not to 
do it again (we still have DM in this plant, so no tree views as in 
FoxSelect).


The fact that the blocks aren't in loop alphabetical order (except where 
loop processing dictates otherwise), as is my personal standard practice, 
further exacerbates the problems.


Corey Clingo
BASF Corporation






Jeff Hurt <thehurtman@xxxxxxxxx> 
Sent by: foxboro-bounce@xxxxxxxxxxxxx
09/24/2008 10:46 AM
Please respond to
foxboro@xxxxxxxxxxxxx


To
foxboro@xxxxxxxxxxxxx
cc

Subject
[foxboro] Grouping for compounds






We are in the design phase for a new Foxboro I/A project.  For our 
compounds, we were considering having one compound for each type of block 
(AIN, COUT, etc).  It seems that this is a break from the norm, grouping 
by system.  Any thoughts as to why grouping by block type would be a bad 
idea?
 
Thanks,
Jeff
 



 
 
_______________________________________________________________________
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: