Re: [foxboro] Grouping for compounds

Our philosophy here is to name our compounds based on the P&ID. All blocks that 
would be associated with one sheet of our P&ID would all go in one compound. We 
name our compounds in this format: AREA_UNIT_P&ID Sheet #. For instance our 
Vacuum Unit is in AREA1, it is designed as unit 17 (all instrument tags are in 
the 17000 range) and all the instrument loops in the compound came from P&ID 
sheet 28 then the compound would be labeled 1_17_0028.
This method seems to work a lot better than what we have done in the past. In 
any case never label a compound MISC. 

Good luck 

Jim Jenckes, CCST
Process Control Specialist
Tesoro Alaska Company
P.O. Box 3369
Kenai, AK 99611
907-776-3865
907-776-3863 Fax
 
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jerry Hidahl
Sent: Wednesday, September 24, 2008 11:06 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Grouping for compounds

This reminds me of a research location in the early days of I/A that
decided, with peer-to-peer communication, it would be convenient to put all
the thermocouples in one CP, all the flows in a second, pressures, level,
and etc in separate CPs. It didn't take long during cutover to figure out
it was a bad idea.

We do put ECBs in a compound of their own, but group all other blocks
associated with a major piece of equipment (e.g. a reactor or tower) in one
compound. Your greatest difficulty should be deciding where one compound
ends and the next begins. Focus on operation and making money, not the
instrument index.

Jerry Hidahl
Process Control Engineer
Port Neches Performance Products
Huntsman Corporation


                                                                           
             "Moore, Kenneth,                                              
             Celanese/US"                                                  
             <ken.e.moore@cela                                          To 
             nese.com>                 <foxboro@xxxxxxxxxxxxx>             
             Sent by:                                                   cc 
             foxboro-bounce@fr                                             
             eelists.org                                           Subject 
                                       Re: [foxboro] Grouping for          
                                       compounds                           
             09/24/2008 01:00                                              
             PM                                                            
                                                                           
                                                                           
             Please respond to                                             
             foxboro@freelists                                             
                   .org                                                    
                                                                           
                                                                           




Using the process unit as the driver for grouping also allows code to be
developed once and deployed many times to common units.
That is if you have several identical units, you can develop the code for
unit1, and then copy the entire contents of unit1 to unit2 and not have to
make all the connection changes.


Ken Moore
Celanese
Enoree, SC

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Jeff Hurt
Sent: Wednesday, September 24, 2008 11:46 AM
To: foxboro@xxxxxxxxxxxxx
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



_______________________________________________________________________
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



 
 
_______________________________________________________________________
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
 


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