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

  • From: "Johnson, Alex P \(IPS\)" <alex.johnson@xxxxxxxxxxxxxxxx>
  • To: <foxboro@xxxxxxxxxxxxx>
  • Date: Mon, 14 May 2007 14:58:51 -0400

I use HLBL for continuous operations that do not require high
performance. Each line of HLBL is roughly the load of an AIN block so it
is pretty expensive.
 

The biggest irritant to me is the lack of a math library. Typically, I
use a CALC block in addition to the SEQ block to achieve that goal.

 

I use BPCSTM and WAIT statements to minimize the load.

 

My rules of thumb are as follows:

 

1.    Do it in regulatory control blocks. (most efficient; least prone
to problems)

2.    If the regulatory control blocks can't do it, use a CALC block.
(efficient, but must deal with BAD and coding errors; debugging is a
pain)

3.    If the CALC block can't do it, use a Sequence Block (pretty
inefficient, but in the CP so it's redundant. Code/compilation
relatively complex. Debugging is a pain.)

4.    If you can't do it in a sequence block, reconsider if you need to
do it.

5.    If you must do it, see if you can do it in a shell (sh, ksh, csh,
perl, etc.) script (easier to debug, easy to schedule, remember to use
omgetimp and omsetimp to avoid broadcasts, remember to use show_params
to check the IMPORT table)

6.    If you can't do it in a script, reconsider doing it.

7.    If you must do it, see if there is a 3rd party or Foxboro package
that will do it. (Ask on the mailing list.)

8.    If you must do it and can't find a package, write a program.

 

 

 

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 Corey R Clingo
Sent: Tuesday, May 15, 2007 12:10 AM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] Sequence code (MON, DEP, IND) opinions

 

I see a significant amount of discussion on here regarding use of these 

blocks and sequence code.  Not wanting to ignore a potential tool in my 

toolbox....OK, really I'm just lazy* and do not want to pass up an 

opportunity to get a computer to do something instead of me.

 

Some background: my plants are continuous processes.  I inherited
systems 

in both plants.  Neither system had any sequence code in it - nada.  I
had 

heard all the horror stories about sequence code loading CPs, issues
with 

memory fragmentation, etc. etc., so I never took a big interest in 

learning it.

 

 

I then had an application, non-control, where a large number of complex 

calculations were being performed.  I felt it was a good application for


sequence code, so I built an IND block and got after it.  It worked
fine, 

but at the default BPCSTM of 100, it caused a CP30A's idle time to drop
by 

over 30% (it was about 50 lines of code, with a WAIT loop back to the 

beginning).  I set BPCSTM to about 10, and the idle time problem went 

away, but I only got away with it because this application did not need 

anywhere near real-time performance.  I sgain shied away for using it do


do anything that did have such requirements.

 

 

Which is a shame, really.  I used the sequence equivalent fairly 

frequently in my Brand H days, partly because they did not really have a


CALC* equivalent (you had logic, or math, but not both in one block), 

partly because some flavors of their sequence-equivalent had wide system


access that I needed.  I don't think I'd go crazy with it on I/A, but 

there are 2 or 3 applications where it would be nice to have if it
didn't 

have the issues I saw.

 

 

So how do others use sequence on I/A?  Batch only?  How do you get
around 

the CP loading issues?  What other issues do you have?  How do you get 

good performance and reesponsive interaction with a human operator?  Vi
or 

emacs? :)

 

 

Thanks,

Corey Clingo

BASF Corporation

 

 

 

 

 

 

_______________________________________________________________________

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

 

 




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 all copies of 
this message and any attachment(s). Any other use of the E-Mail 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:

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