Re: [foxboro] Sequence code (MON, DEP, IND) opinions

  • From: "Jones, Charles R. \(Chuck\)" <Chuck.Jones@xxxxxxxxxxxxxxx>
  • To: <foxboro@xxxxxxxxxxxxx>
  • Date: Tue, 15 May 2007 09:33:49 -0400

Corey,
I am also at a continuous process plant, a corn wet mill and refinery.
In the wet mill, we use very few sequence blocks.  In the refinery, we
use them extensively.  Like Gabriel O'Dwyer and Mike Adams, I know my
way pretty well around the code and the interfaces.  (I rlogin to the AP
and go directly to the source code, edit it with vi, and only use the
ICC to compile the code and check for errors.)  After a short while, it
becomes second nature. =20

To Alex's list, I would add one more consideration.  Actually, it is
often the deciding factor for me.  Because we are a continuous control
plant, as opposed to a batch plant, our control philosophy is that a
well trained technician can always override the automatic controls.
(There are exceptions, of course, for safety interlocks, environmental
interlocks, etc.)  So, if I must share the operation of a regulatory
control block with the technicians, my solution will almost always be a
sequence block.  A sequence block will allow me to operate other blocks
without securing the inputs of the other block and thus making them
unavailable to the operators.  We also use sequence blocks for startup
and shutdown sequences.

CP loading has been an issue in the past.  A lot of it was taken care of
by very good predictive planning by the Foxboro engineers at
installation (thanks, Jim Mowrey and Cassandra Justice!).  But,
operations grow and over time I have learned to stuff 10 pounds of
.=2E.stuff... into a 5 pound sack with judicious use of WAIT 0.1 and WAIT
UNTIL statements, BPCSTM, PHASE, and PERIOD.=20

The toughest problem for me to troubleshoot with sequence blocks, as
stated by others, is the coordination of control between the sequence
blocks.  Like a coach or choreographer, you really have to define your
algorithm with close attention to specific events for the "hand off" of
control from one to the other and for defining specific "zones of
influence" for each individual block.

For good operator interaction, I often use SENDMSG to write out
information to one of the string variables, like SN0001.  I then link
the user screen to the string variable.  If the program appears to be
stopped, the user has a message telling them "WAITING ON TANK LEVEL >
42%" or something similar.  I have used them so often in some programs
that I did not need comment lines for large sections of the code.

I agree with Gabriel, "Very often I find that an IND block is WAY
smarter than trying to use all the other block combinations, CALCS,
etc.".  I also agree with Mike, "I don't think Foxboro ever got enough
credit for the programming power that's available through the synergy of
continuous blocks, PLBs and sequences".

When I was first learning this job, I went to an area Users' Group
meeting at the plant where Duc and Tom work.  (At the time, I didn't
know they were world famous...)  What they were doing with sequence
blocks 10 years ago still humbles me when I look at my notes from that
meeting.  (I know, 'cause I just dug them out.)

Chuck Jones
Automation Technologist
Tate & Lyle -- Lafayette Plant
Office 765.477.5324 | Cell 765.586.5290





=20
=20
***************************************************************************=
**************************
This email and any files transmitted with it are confidential and intended =
solely for the=20
use of the individual or entity to whom they are addressed. If you are not =
the intended=20
recipient or the person responsible for delivering the email to the intende=
d recipient, be=20
advised that you have received this email in error that any use, disseminat=
ion,=20
forwarding, printing, or copying of this email is strictly prohibited.  If =
you have received=20
this email in error please notify the sender immediately. Please note that =
we reserve=20
the right to monitor and read any emails sent and received by the Company i=
n=20
accordance with and to the extent permitted by applicable legal rules.
***************************************************************************=
**************************
 
 
_______________________________________________________________________
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:

  1. Home
  2. foxboro
  3. Archive
  4. 05-2007