RE: GC Analyzer Control

[Rick Rys]

Technically, you should get superior performance by using a "Sampled Data
PID Controller" rather than a fixed scan PID. i.e. enabling the PID
execution only upon receipt of a new analyzer (maybe a GC) update. This is
the SPLCOP option in the PIDA. One item you did not mention that has a big
impact on the control effectiveness is the analyzer delay time.  I.e. when
the analyzer is giving a new update, how old is this data?  In a GC this
would be the time to transport the sample from the process to the analyzer
plus the time for the analyzer to complete it's result and set the sample
ready timer to on (elution time of the applicable component peaks for a GC).
Also the use of inferred property control (like analyzer to temperature
cascade for distillation for example) can be effective to catch upsets that
are fast relative to the analysis frequency mitigating the need for
improving the analyzer PID loop.  In this case the temperature PID loop
essentially handles the upset. The PIDTAU option (deadtime compensation)
might be considered in conjunction with the SPLCOP option to better handle
the sample delay. Prior to the PIDA feature we would typically just run a
fixed scan PID but filter the measurement with 2 lags in series (set for
about .2 and .5 times the sample interval in minutes). This, in conjuntion
with signal validity logic, was typically satisfactory, but not technically
optimal.  Some multivariable controllers (I think that PCL Connoisseur does
this, and I know that BOSS blending can do this) can make a similar
synchronization and PCL control technology inherently compensates for the
sample delays.  Few of these tricks would substitute for a well designed
fast sample loop, and a fast responding analyzer technology.  My vote is to
implement this in the PIDA rather than sequence blocks or programs as it
will be simpler and easy to maintain.  The validity logic for holding the
PID and alamring might include "frozen" signal and provisions to
automatically detect analyzer maintenance like calibration in case the
operator did not take the precaution of putting the loop into manual first.

Rick Rys



---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

Re: GC Analyzer Control

[kevin . fitzgerrell]

Rory,

I've seen a variety of implementations, all of which worked well enough,
although differently.

If your process is fast enough that after a controller output change it is
likely to come to a new steady state before the next sample, then you can
tune a continuous PI controller to produce a deadbeat response.

If your process is relatively slow compared to the sample interval +
deadtime, filtering (especially filters that give more weight to the most
recent sample) can be applied to smooth the step changes in GC output.
This increases the phase lag of the sampler but the filtered measurement is
easier to use in control.

Synchronizing the PID control with the sampler output is easy to implement
but can be difficult to tune.  Just connect the fresh sample flag to the MA
parameter (or HOLD parameter) in the PID controller.  This type of control
is convenient in that you can have it just ignore any GC output flagged as
bad without affecting control.

Continuous PID control can be used, however the spikes in manipulated
variable due to derivative action on the step change may be unacceptable in
many applications.  Often very fast stabilization come from using just
enough derivative filter to minimize excessive process disturbance.

Regards,

Kevin FitzGerrell
Systems Engineer
Foxboro New Zealand

Tel:  +64 (9) 573 7690
Fax:  +64 (9) 573 7691


   
  
"Loupe, Rory (RJ)" 
  
<[EMAIL PROTECTED]>To: 'Foxboro - Cassandra' 
<[EMAIL PROTECTED]>   
Sent by: cc:   
  
<[EMAIL PROTECTED]Subject: GC Analyzer 
Control
oject.org> 
  
   
  
   
  
07/10/01 07:34 AM  
  
Please respond to "Foxboro 
  
DCS Mail List" 
  
   
  
   
  




I am converting some old Foxboro SMS control schemes to run on I/A.  There
is some code that does validity, rate of change and time-out checking on
some GC data.  If the GC data is good the code does PID control with this
data (in the code itself, not through a PID block).  The analyzer has a
cycle time of 15 minutes and sets a boolean flag true for 60 seconds on a
fresh update.

I am trying to determine if I should stick with code from the SMS and
convert it to HLBL or use standard I/A blocks to accomplish the same thing.
My idea for I/A is to do validity, rate of change and time-out checking via
a CALC block.  Do the pid control via a PIDA block and on invalid GC data
put the block in manual and alarm.  Part of the problem with this approach
is tuning the PIDA block.  I have done an extensive step test and have come
up with tuning parameters (with a large reset time).  The testing of this
PIDA seems to be doing a good job, but the GC update time has me concerned
about timing issues.

Could someone suggest a solution to GC control on I/A?

Thanks,
Rory








---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

GC Analyzer Control

[Loupe, Rory (RJ)]

I am converting some old Foxboro SMS control schemes to run on I/A.  There
is some code that does validity, rate of change and time-out checking on
some GC data.  If the GC data is good the code does PID control with this
data (in the code itself, not through a PID block).  The analyzer has a
cycle time of 15 minutes and sets a boolean flag true for 60 seconds on a
fresh update.

I am trying to determine if I should stick with code from the SMS and
convert it to HLBL or use standard I/A blocks to accomplish the same thing.
My idea for I/A is to do validity, rate of change and time-out checking via
a CALC block.  Do the pid control via a PIDA block and on invalid GC data
put the block in manual and alarm.  Part of the problem with this approach
is tuning the PIDA block.  I have done an extensive step test and have come
up with tuning parameters (with a large reset time).  The testing of this
PIDA seems to be doing a good job, but the GC update time has me concerned
about timing issues.

Could someone suggest a solution to GC control on I/A?

Thanks,
Rory

---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

Synchronization (was RE: HLBL REF.)

[kevin . fitzgerrell]

Corey,

It is critical that the CSA database, the station volume workfile and the
checkpoint file stay synchronized.  Because parameters are constantly
changing on the CP, it is normal that the setable parameters in the CP will
not match the other files, although the non-settable parameters must match.

There are several things that can cause a problem between CP, CSA, station
workfile and checkpoint file.  Some of these include:
1) Power failure or system reboot during ICC session
2) Improper exit from ICC
3) Tape restore
4) setpars
5) CSA tools
6) ICC use with severe station overloading
Other causes probably exist.  Corruption of CSA, work file or checkpoint
file is possible too.  Of the list above, #1 is the one I have seen most
often.  Typically, an ICC session is left open and is still open when the
computer or xterminal it is running on is rebooted (before checkpoint).
Tape restore of an AP or AW is a tricky one.  If changes have been made in
ICC since the tape you are restoring from was made, and if no current
SaveAlls exist, you will probably need to restore from tape, reboot the CP
(to checkpoint file from tape) and re-create the changes in ICC made after
the tape.

A couple of items that may not be obvious:
1) Upload only updates settable parameters from CP to workfile.  Assumption
probably is that non-settable parameters shouldn't need to be updated from
CP.
2) A SaveAll is not made from the CP but from the workfile.  If setpars is
used to change a non-settable parameter on the CP, a SaveAll won't reflect
that change even after an upload.

Tools are available for troubleshooting mismatches:
Select views parameters in CP.
iccprt views parameters in workfile.
dbvu views parameters in checkpoint file (-t option, needs checkpoint file,
map file and image file).
CSA_save exports an ascii copy of the CSA database.

Regards,

Kevin FitzGerrell
Systems Engineer
Foxboro New Zealand

Tel:  +64 (9) 573 7690
Fax:  +64 (9) 573 7691


   
  
Corey R Clingo 
  
<[EMAIL PROTECTED]>  To: Foxboro DCS Mail List 
<[EMAIL PROTECTED]>   
Sent by: cc:   
  
<[EMAIL PROTECTED]Subject: RE: HLBL REF.
  
oject.org> 
  
   
  
   
  
07/10/01 11:17 AM  
  
Please respond to "Foxboro 
  
DCS Mail List" 
  
   
  
   
  




OK, you've gone and confused me now (don't get the big head; it's not that
hard
to do ;-).

I am kind of new to I/A, and this whole checkpoint/workfile/CP's memory
thing
has me asking a lot of questions, to say the least.  I had thought that the
checkpoint at least was a direct copy of the CP's memory, but from what you
say
below this is not the case.  (Emotional state on discovering this
deleted...)

Sois there anything else supplied by Foxvensys that can make changes to
the
CP's memory that cannot be duplicated on-disk?

Corey Clingo
Sr. Engineer
BASF Corporation







Ken,

As others have stated, extreme caution should be taken when using setpars.

Anytime setpars is used for bulk changes it should be followed by an upload
and then a checkpoint (if you want the changes to be there in the event of
a reboot), because setpars makes active changes in the CP only, not in the
workfile or checkpoint file.
 setpars -- makes active change in CP
 upload -- updates settable parameters in CP to station workfile
 checkpoint -- builds new checkpoint file based on station workfile
One of the big dangers in using setpars is that it can change no

RE: HLBL REF.

[Corey R Clingo]

OK, you've gone and confused me now (don't get the big head; it's not that hard
to do ;-).

I am kind of new to I/A, and this whole checkpoint/workfile/CP's memory thing
has me asking a lot of questions, to say the least.  I had thought that the
checkpoint at least was a direct copy of the CP's memory, but from what you say
below this is not the case.  (Emotional state on discovering this deleted...)

Sois there anything else supplied by Foxvensys that can make changes to the
CP's memory that cannot be duplicated on-disk?

Corey Clingo
Sr. Engineer
BASF Corporation







Ken,

As others have stated, extreme caution should be taken when using setpars.

Anytime setpars is used for bulk changes it should be followed by an upload
and then a checkpoint (if you want the changes to be there in the event of
a reboot), because setpars makes active changes in the CP only, not in the
workfile or checkpoint file.
 setpars -- makes active change in CP
 upload -- updates settable parameters in CP to station workfile
 checkpoint -- builds new checkpoint file based on station workfile
One of the big dangers in using setpars is that it can change non-settable
parameters.  These changes can not be updated in the station workfile with
an upload, resulting in a mismatch between checkpoint file, station
workfile, and CP.  Wildcards can be used in the filter specifications in
setpars which can lead to unforseen changes due to unexpected matches.
Making a small mistake when updating a setpars script can cause extensive
damage to control logic.

If you are making changes to settable parameters in an operating plant and
need to do them from a UNIX script, consider using omset or omsetimp.

Kevin FitzGerrell







---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: HLBL REF.

[kevin . fitzgerrell]

Ken,

As others have stated, extreme caution should be taken when using setpars.

Anytime setpars is used for bulk changes it should be followed by an upload
and then a checkpoint (if you want the changes to be there in the event of
a reboot), because setpars makes active changes in the CP only, not in the
workfile or checkpoint file.
 setpars -- makes active change in CP
 upload -- updates settable parameters in CP to station workfile
 checkpoint -- builds new checkpoint file based on station workfile
One of the big dangers in using setpars is that it can change non-settable
parameters.  These changes can not be updated in the station workfile with
an upload, resulting in a mismatch between checkpoint file, station
workfile, and CP.  Wildcards can be used in the filter specifications in
setpars which can lead to unforseen changes due to unexpected matches.
Making a small mistake when updating a setpars script can cause extensive
damage to control logic.

If you are making changes to settable parameters in an operating plant and
need to do them from a UNIX script, consider using omset or omsetimp.

Kevin FitzGerrell
Systems Engineer
Foxboro New Zealand

Tel:  +64 (9) 573 7690
Fax:  +64 (9) 573 7691




---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: HLBL REF.

[Johnson, Alex (Foxboro)]

Depends on what you are trying to do. If you want to the change to survive a
reboot, it must be reflected in the checkpoint file.

What are you doing that requires the use of setpars?


Regards,


Alex Johnson
10707 Haddington
Houston, TX 77043
713.722.2859 (office)
713.722.2700 (switchboard)
713.932.0222 (fax)
[EMAIL PROTECTED]  


-Original Message-
From:   [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
Sent:   Monday, July 09, 2001 4:29 PM
To: Foxboro DCS Mail List
Subject:RE: HLBL REF.


After speaking with our former application engineer, I agree that
the
setpars is not what we want to do.
We currently only use the "setpars" tool after an unusual event, it
is not
used on a routine basis, the display
with the call button is not nomally accessible.

Do you recommend running a checkpoint after every use of the setpars
tool?


Ken Moore
NSCC




"Johnson, Alex (Foxboro)" <[EMAIL PROTECTED]>
@lists.TheCassandraProject.org> on 07/09/2001 13:23:44

Please respond to "Foxboro DCS Mail List"
  <[EMAIL PROTECTED]>

Sent by:  <[EMAIL PROTECTED]>


To:   Foxboro DCS Mail List <[EMAIL PROTECTED]>
cc:
Subject:  RE: HLBL REF.


Setpars is a pretty powerful tool. I hope you are very careful with
its
use.
It will make changes to the CP that are not reflected in the
checkpoint
file
or the workfile.


Regards,


Alex Johnson
10707 Haddington
Houston, TX 77043
713.722.2859 (office)
713.722.2700 (switchboard)
713.932.0222 (fax)
[EMAIL PROTECTED] 


 -Original Message-
 From: [EMAIL PROTECTED]
[SMTP:[EMAIL PROTECTED]]
 Sent: Monday, July 09, 2001 9:52 AM
 To:  Foxboro DCS Mail List
 Subject:  RE: HLBL REF.


 It is a Unix script, currently called via a foxview button , I
would
like
 to include this in the sequence logic if possible.
 The script utilizes  the "setpars"  tool found in
/opt/fox/bin/tools.



 Ken Moore
 NSCC




 "Jones, Charles R. (Chuck)" <[EMAIL PROTECTED]>
 @lists.TheCassandraProject.org> on 07/09/2001 11:59:08

 Please respond to "Foxboro DCS Mail List"
   <[EMAIL PROTECTED]>

 Sent by:  <[EMAIL PROTECTED]>


 To:   "'Foxboro DCS Mail List'"
<[EMAIL PROTECTED]>
 cc:
 Subject:  RE: HLBL REF.


 If the operators can interact with the process, I recommend
putting
GDEV
 blocks to AUTO (then WAIT 2 seconds for the block to see it)
right
before
 you use each one.  It is the only way to be sure that the GDEV
will
be in
 the correct auto/manual state when you need it to be.  If you
are
going to
 change state on several GDEVs, then you can put them all to
AUTO
followed
 by
 only one WAIT statement.

 If you want to call the script that you have already written,
then I
am
 going to have flex a few thoughts to remember how to do that.
Depending on
 how you wrote the UNIX script, I believe that it may be a more
efficient
 use
 of resources to rewrite it in HLBL.  Is it a UNIX script, PERL,
C
code, or
 --Heaven forbid-- JAVA?  (I am assuming UNIX.)  Does the script
use
Object
 Manager calls or API calls?

 I'm curious now.  Does any one know if HLBL is the most
efficient
use of
 resources in this case?  Does anyone know how to call an
external
script
 from within HLBL?

 Chuck Jones
 Refinery Automation Technologist
 A.E. Staley Mfg. Co. -- Lafayette South Plant
 765.477.5324 - Office  | 765.420.4431- Pager

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
 Sent: Monday, July 09, 2001 5:17 AM
 To: Foxboro DCS Mail List
 Subject: RE: HLBL REF.



 Thanks for the input,

 I have a script that places all GDEV blocks in auto. How would
you
use this
 in HLBL. I would like to place all GDEV's in auto at the
beginning
of the
 Sequence Logic.

 thanks in advance
 Ken Moore
 NSCC

 This e-mail and any files transmitted with it are confidential
and
intended
 solely for the use of the individual or entity to whom they are
addressed.
 If you are not the in

RE: HLBL REF.

[Ken . E . Moore]

After speaking with our former application engineer, I agree that the
setpars is not what we want to do.
We currently only use the "setpars" tool after an unusual event, it is not
used on a routine basis, the display
with the call button is not nomally accessible.

Do you recommend running a checkpoint after every use of the setpars tool?


Ken Moore
NSCC




"Johnson, Alex (Foxboro)" <[EMAIL PROTECTED]>
@lists.TheCassandraProject.org> on 07/09/2001 13:23:44

Please respond to "Foxboro DCS Mail List"
  <[EMAIL PROTECTED]>

Sent by:  <[EMAIL PROTECTED]>


To:   Foxboro DCS Mail List <[EMAIL PROTECTED]>
cc:
Subject:  RE: HLBL REF.


Setpars is a pretty powerful tool. I hope you are very careful with its
use.
It will make changes to the CP that are not reflected in the checkpoint
file
or the workfile.


Regards,


Alex Johnson
10707 Haddington
Houston, TX 77043
713.722.2859 (office)
713.722.2700 (switchboard)
713.932.0222 (fax)
[EMAIL PROTECTED] 


 -Original Message-
 From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
 Sent: Monday, July 09, 2001 9:52 AM
 To:  Foxboro DCS Mail List
 Subject:  RE: HLBL REF.


 It is a Unix script, currently called via a foxview button , I would
like
 to include this in the sequence logic if possible.
 The script utilizes  the "setpars"  tool found in
/opt/fox/bin/tools.



 Ken Moore
 NSCC




 "Jones, Charles R. (Chuck)" <[EMAIL PROTECTED]>
 @lists.TheCassandraProject.org> on 07/09/2001 11:59:08

 Please respond to "Foxboro DCS Mail List"
   <[EMAIL PROTECTED]>

 Sent by:  <[EMAIL PROTECTED]>


 To:   "'Foxboro DCS Mail List'"
<[EMAIL PROTECTED]>
 cc:
 Subject:  RE: HLBL REF.


 If the operators can interact with the process, I recommend putting
GDEV
 blocks to AUTO (then WAIT 2 seconds for the block to see it) right
before
 you use each one.  It is the only way to be sure that the GDEV will
be in
 the correct auto/manual state when you need it to be.  If you are
going to
 change state on several GDEVs, then you can put them all to AUTO
followed
 by
 only one WAIT statement.

 If you want to call the script that you have already written, then I
am
 going to have flex a few thoughts to remember how to do that.
Depending on
 how you wrote the UNIX script, I believe that it may be a more
efficient
 use
 of resources to rewrite it in HLBL.  Is it a UNIX script, PERL, C
code, or
 --Heaven forbid-- JAVA?  (I am assuming UNIX.)  Does the script use
Object
 Manager calls or API calls?

 I'm curious now.  Does any one know if HLBL is the most efficient
use of
 resources in this case?  Does anyone know how to call an external
script
 from within HLBL?

 Chuck Jones
 Refinery Automation Technologist
 A.E. Staley Mfg. Co. -- Lafayette South Plant
 765.477.5324 - Office  | 765.420.4431- Pager

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
 Sent: Monday, July 09, 2001 5:17 AM
 To: Foxboro DCS Mail List
 Subject: RE: HLBL REF.



 Thanks for the input,

 I have a script that places all GDEV blocks in auto. How would you
use this
 in HLBL. I would like to place all GDEV's in auto at the beginning
of the
 Sequence Logic.

 thanks in advance
 Ken Moore
 NSCC

 This e-mail and any files transmitted with it are confidential and
intended
 solely for the use of the individual or entity to whom they are
addressed.
 If you are not the intended recipient or the person responsible for
 delivering the e-mail to the intended recipient, be advised that you
have
 received this e-mail in error, and that any use, dissemination,
forwarding,
 printing, or copying of this e-mail is strictly prohibited.  If you
have
 received this e-mail in error, please notify the TLNA HELPDESK at
 800-404-2436 or e-mail [EMAIL PROTECTED]


---
 This list is neither sponsored nor endorsed by the Foxboro Company.
All
 postings from this list are the work of list subscribers and no
warranty
 is made or implied as to the accuracy of any information
disseminated
 through this medium. By subscribing to this list you agree to hold
the
 list sponsor(s) blameless for any and all mishaps which might occur
due to
 your application of information received from this mailing list.

 To be removed from this list, send mail to
 [EMAIL PROTECTED]
 with "unsubscribe foxboro" in the Subject. Or, send any mail to
 [EMAIL PROTECTED]




 IMPORTANT NOTICE:
 This email is confidential, may be legally privileged, and is for
the
 intended recipient only.  Access, disclosure, copying, distribution,
or
 reliance on any of it by anyone else is prohibited and may be a
criminal
 offence.  Please delete if obtained 

RE: HLBL REF

[Fitzgerrell Kevin]

Ken,

To efficiently set the appropriate state of a number of blocks at the
same time I use a calc or logic block.  I trigger the calc block with a
boolean input that can be pulsed from a display (momentary contact) or
from sequence logic.  The calc block uses an appropriate OSP to toggle
on and off a boolean output to which the the AUTSW of the target blocks
is connected.  The same block can also pulse the appropriate REMSW or
LOCSW when setting the state of control blocks.

This approach is, I feel, more efficient than setting the state of each
block from within sequence logic, and easier to maintain and
troubleshoot than UNIX level scripts.  It is also re-usable.  As long
as attention is paid to what blocks are connected to which logic, the
state change logic can be shared by multiple sequence logic blocks and
buttons on operator graphics.  The calc block can have multiple
triggers for a variety of desired states.

Regards,

Kevin FitzGerrell


 --- [EMAIL PROTECTED] wrote: > 
> Thanks for the input,
> 
> I have a script that places all GDEV blocks in auto. How would you
> use this
> in HLBL. I would like to place all GDEV's in auto at the beginning of
> the
> Sequence Logic.
> 
> thanks in advance
> Ken Moore
> NSCC
> 




---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: HLBL REF.

[Johnson, Alex (Foxboro)]

I'm not familiar with VSHELL.


Regards,


Alex Johnson
10707 Haddington
Houston, TX 77043
713.722.2859 (office)
713.722.2700 (switchboard)
713.932.0222 (fax)
[EMAIL PROTECTED]  


-Original Message-
From:   Airhart, Chad M. [SMTP:[EMAIL PROTECTED]]
Sent:   Monday, July 09, 2001 10:50 AM
To: 'Foxboro DCS Mail List'
Subject:RE: HLBL REF.

Is cpShell the same as VSHELL?  That is the application we currently
use to
execute commands from HLBL code.  We use it quite a bit and it works
well.

Chad Airhart
Senior Instrument, Electrical & Control Systems Engineer
Equistar Chemicals, LP.
Victoria, TX
Wk. (361) 572-2568
Pgr. (361) 270-2214 alpha messaging at  [EMAIL PROTECTED]
Fx. (361) 572-2541

> -Original Message-
> From: Johnson, Alex (Foxboro) [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, July 09, 2001 12:22 PM
> To:   Foxboro DCS Mail List
> Subject:  RE: HLBL REF.
> 
> Re: Sequence Block Resources
> 
> HLBL is slow. Each line of HLBL code is roughly equivalent to the
CPU
> requirements of an AIN block.
> 
> External references to CBPs in the same CP take even longer.
> 
> 
> 
> Re: Setting External OM Variables from within HLBL
> 
> HLBL allows OM variables (C:B.Ps and SVs) to be set directly using
the
> following syntax:
> 
> : := ;
> 
> where 
> 
>  is a C:B.P name or a Shared Variable Name
>  is the new value for the variable.
> 
> The leading colon is required. Two examples are:
> 
> 
> :TOWER:OVRHD_LEVEL.SPT := 50.0;
> 
> 
> :WP0001DMCMD := "dmcmd applic /opt/prog/myScript $DMNAME &";
> 
> 
> NAME := SN0001, "DMCMD";
> :'NAME' := "dmcmd applic /opt/prog/myScript $DMNAME &";
> 
> 
> 
> This is documented in the appropriate manuals.
> 
> 
> There are a couple of "gotcha"s though:
> 
> 1) If the variable being set is secured or missing, you will get
an
> operational error that will either cause an SBX to be fired or
suspend the
> block.
> 2) Each external reference suspends the execution of the HLBL code
for one
> block period if the target is outside the CP. If the target is
inside the
> CP, the call does not suspend the code, but it can take quite a
long time.
> 
> 
> The former issue is difficult to handle properly if one has
several
> external
> references in the code since they will all fire the same SBX and
you will
> probably want different handling for each case. Personally, I do
not use
> this approach. I prefer to use a program like cpShell and send it
messages
> from SENDCONF (see below).
> 
> 
> The second issue causes subtle problems in the code. I had one
customer
> call
> because his emergency shutdown logic took 10s to execute and it
was only
> 20
> lines of code. The problem was that he did not know about the
suspension
> of
> execution on an external reference. Since his block ran every 0.5
seconds
> though, 10s to execute the code was as good as he could expect.
> 
> There is no workaround for this delay other than to not use
external
> references, i.e., connect the targets to the output of the block.
Of
> course,
> that can lead to conflicts with the operator if the operator needs
to set
> the same targets.
> 
> 
> 
> Re: Executing Scripts and Programs from a Sequence Block
> 
> There was a long discussion on how to run scripts on demand. The
options
> boil down to:
> 
> 
> * Using the external reference capability of HLBL to set the
DMCMD
> global of a DM/FV instance
> * Using SENDMSG or SENDCONF to send a message to a program
that will
> execute the command.
> 
> 
> There are issues with the first approach related to error
handling, i.e.,
> what happens and how do you handle it if the DMCMD variable does
not exist
> or someone overrides your command before it can be executed. These
are
> actually quite difficult to handle.
> 
> 
> The latter approach is much more controllable. The SENDCONF
command has a
> timer. It suspends execution of the sequence block and sets the
SUSPND
> parameter. When the SUSPND parameter is reset or the timer
expires, the
> sequence block awakes. If it awakes because of a timeout, the flow
of

RE: HLBL REF.

[Johnson, Alex (Foxboro)]

Okay, I'll say it.


My advice is do not use setpars on a running system. It is intended as an
application engineering support tool, e.g., to put CP's in simulation mode.


There are some places where its use can be considered to be appropriate,
e.g., setting some parameters like Computer Control timers, but they are
pretty few and far between. Many of these special cases can be dealt with
using the ICC Driver Task which at least checks for other configurators
being used on the target station.



Regards,


Alex Johnson
10707 Haddington
Houston, TX 77043
713.722.2859 (office)
713.722.2700 (switchboard)
713.932.0222 (fax)
[EMAIL PROTECTED]  


-Original Message-
From:   Stear, Bo [SMTP:[EMAIL PROTECTED]]
Sent:   Monday, July 09, 2001 10:33 AM
To: 'Foxboro DCS Mail List'
Subject:RE: HLBL REF.

What Alex did NOT mention although I feel he should have, is that
using setpars should be avoided period.  There are other more graceful
(omset class) methods that are not nearly as dangerous.

-Original Message-
From: Johnson, Alex (Foxboro) [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 09, 2001 12:22 PM
To: Foxboro DCS Mail List
Subject: RE: HLBL REF.


Re: Sequence Block Resources

HLBL is slow. Each line of HLBL code is roughly equivalent to the
CPU
requirements of an AIN block.

External references to CBPs in the same CP take even longer.



Re: Setting External OM Variables from within HLBL

HLBL allows OM variables (C:B.Ps and SVs) to be set directly using
the
following syntax:

: := ;

where 

 is a C:B.P name or a Shared Variable Name
 is the new value for the variable.

The leading colon is required. Two examples are:


:TOWER:OVRHD_LEVEL.SPT := 50.0;


:WP0001DMCMD := "dmcmd applic /opt/prog/myScript $DMNAME &";


NAME := SN0001, "DMCMD";
:'NAME' := "dmcmd applic /opt/prog/myScript $DMNAME &";



This is documented in the appropriate manuals.


There are a couple of "gotcha"s though:

1) If the variable being set is secured or missing, you will get an
operational error that will either cause an SBX to be fired or
suspend the
block.
2) Each external reference suspends the execution of the HLBL code
for one
block period if the target is outside the CP. If the target is
inside the
CP, the call does not suspend the code, but it can take quite a long
time.


The former issue is difficult to handle properly if one has several
external
references in the code since they will all fire the same SBX and you
will
probably want different handling for each case. Personally, I do not
use
this approach. I prefer to use a program like cpShell and send it
messages
from SENDCONF (see below).


The second issue causes subtle problems in the code. I had one
customer call
because his emergency shutdown logic took 10s to execute and it was
only 20
lines of code. The problem was that he did not know about the
suspension of
execution on an external reference. Since his block ran every 0.5
seconds
though, 10s to execute the code was as good as he could expect.

There is no workaround for this delay other than to not use external
references, i.e., connect the targets to the output of the block. Of
course,
that can lead to conflicts with the operator if the operator needs
to set
the same targets.



Re: Executing Scripts and Programs from a Sequence Block

There was a long discussion on how to run scripts on demand. The
options
boil down to:


*   Using the external reference capability of HLBL to set the
DMCMD
global of a DM/FV instance
*   Using SENDMSG or SENDCONF to send a message to a program
that will
execute the command.


There are issues with the first approach related to error handling,
i.e.,
what happens and how do you handle it if the DMCMD variable does not
exist
or someone overrides your command before it can be executed. These
are
actually quite difficult to handle.


The latter approach is much more controllable. The SENDCONF command
has a
timer. It suspends execution of the sequence block and sets the
SUSPND
parameter. When the SUSPND parameter is reset or the timer expires,
the
sequence block awakes. If it awakes because of a timeout, the flow
of
control goes to a particular part of your logic associated with
exactly that
failure. If it awakes because the SUSPND parameter is reset, the
flow of
control moves to the next line.


Sadly, we do not ship such an application with the standard system.
However,
you can get 

RE: HLBL REF.

[Airhart, Chad M.]

Is cpShell the same as VSHELL?  That is the application we currently use to
execute commands from HLBL code.  We use it quite a bit and it works well.

Chad Airhart
Senior Instrument, Electrical & Control Systems Engineer
Equistar Chemicals, LP.
Victoria, TX
Wk. (361) 572-2568
Pgr. (361) 270-2214 alpha messaging at  [EMAIL PROTECTED]
Fx. (361) 572-2541

> -Original Message-
> From: Johnson, Alex (Foxboro) [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, July 09, 2001 12:22 PM
> To:   Foxboro DCS Mail List
> Subject:  RE: HLBL REF.
> 
> Re: Sequence Block Resources
> 
> HLBL is slow. Each line of HLBL code is roughly equivalent to the CPU
> requirements of an AIN block.
> 
> External references to CBPs in the same CP take even longer.
> 
> 
> 
> Re: Setting External OM Variables from within HLBL
> 
> HLBL allows OM variables (C:B.Ps and SVs) to be set directly using the
> following syntax:
> 
> : := ;
> 
> where 
> 
>  is a C:B.P name or a Shared Variable Name
>  is the new value for the variable.
> 
> The leading colon is required. Two examples are:
> 
> 
> :TOWER:OVRHD_LEVEL.SPT := 50.0;
> 
> 
> :WP0001DMCMD := "dmcmd applic /opt/prog/myScript $DMNAME &";
> 
> 
> NAME := SN0001, "DMCMD";
> :'NAME' := "dmcmd applic /opt/prog/myScript $DMNAME &";
> 
> 
> 
> This is documented in the appropriate manuals.
> 
> 
> There are a couple of "gotcha"s though:
> 
> 1) If the variable being set is secured or missing, you will get an
> operational error that will either cause an SBX to be fired or suspend the
> block.
> 2) Each external reference suspends the execution of the HLBL code for one
> block period if the target is outside the CP. If the target is inside the
> CP, the call does not suspend the code, but it can take quite a long time.
> 
> 
> The former issue is difficult to handle properly if one has several
> external
> references in the code since they will all fire the same SBX and you will
> probably want different handling for each case. Personally, I do not use
> this approach. I prefer to use a program like cpShell and send it messages
> from SENDCONF (see below).
> 
> 
> The second issue causes subtle problems in the code. I had one customer
> call
> because his emergency shutdown logic took 10s to execute and it was only
> 20
> lines of code. The problem was that he did not know about the suspension
> of
> execution on an external reference. Since his block ran every 0.5 seconds
> though, 10s to execute the code was as good as he could expect.
> 
> There is no workaround for this delay other than to not use external
> references, i.e., connect the targets to the output of the block. Of
> course,
> that can lead to conflicts with the operator if the operator needs to set
> the same targets.
> 
> 
> 
> Re: Executing Scripts and Programs from a Sequence Block
> 
> There was a long discussion on how to run scripts on demand. The options
> boil down to:
> 
> 
> * Using the external reference capability of HLBL to set the DMCMD
> global of a DM/FV instance
> * Using SENDMSG or SENDCONF to send a message to a program that will
> execute the command.
> 
> 
> There are issues with the first approach related to error handling, i.e.,
> what happens and how do you handle it if the DMCMD variable does not exist
> or someone overrides your command before it can be executed. These are
> actually quite difficult to handle.
> 
> 
> The latter approach is much more controllable. The SENDCONF command has a
> timer. It suspends execution of the sequence block and sets the SUSPND
> parameter. When the SUSPND parameter is reset or the timer expires, the
> sequence block awakes. If it awakes because of a timeout, the flow of
> control goes to a particular part of your logic associated with exactly
> that
> failure. If it awakes because the SUSPND parameter is reset, the flow of
> control moves to the next line.
> 
> 
> Sadly, we do not ship such an application with the standard system.
> However,
> you can get a copy of one by ordering cpShell. This is a VAS-IT item which
> means that it is sold as reusable application engineering. It is licensed
> on
> a per unit basis where we trust you to have a reasonable "process unit".
> 
> 
> To order, tell your account rep that you want:
> 
> 
> Part No: VAS-IT
> Description: cpShell for Solaris
> Order Type: ZZPB or ZZPR 
> Item Tag: cpShell for Solaris
> Special Shipping Instructions: Contact Ruby Chapman in Houston to fill the
> cpShell order.
> Delivery: 4 to 8 weeks ARO.
> List Price (US): 2,200 USD
> 
> 
> I'll send you the manual separately.
> 
> 
> I'm sure that there are others with similar products.
> 
> 
> 
> Regards,
> 
> 
> Alex Johnson
> 10707 Haddington
> Houston, TX 77043
> 713.722.2859 (office)
> 713.722.2700 (switchboard)
> 713.932.0222 (fax)
> [EMAIL PROTECTED]  
> 
> 
>   -Original Message-
>   From:   Jones, Charles R. (Chuck) [SMTP:[EMAIL PROTECTED]]
>   Sent:   Monday, July 09, 2001 8:59 AM
>   To

RE: HLBL REF.

[Stear, Bo]

What Alex did NOT mention although I feel he should have, is that using setpars should 
be avoided period.  There are other more graceful (omset class) methods that are not 
nearly as dangerous.

-Original Message-
From: Johnson, Alex (Foxboro) [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 09, 2001 12:22 PM
To: Foxboro DCS Mail List
Subject: RE: HLBL REF.


Re: Sequence Block Resources

HLBL is slow. Each line of HLBL code is roughly equivalent to the CPU
requirements of an AIN block.

External references to CBPs in the same CP take even longer.



Re: Setting External OM Variables from within HLBL

HLBL allows OM variables (C:B.Ps and SVs) to be set directly using the
following syntax:

: := ;

where 

 is a C:B.P name or a Shared Variable Name
 is the new value for the variable.

The leading colon is required. Two examples are:


:TOWER:OVRHD_LEVEL.SPT := 50.0;


:WP0001DMCMD := "dmcmd applic /opt/prog/myScript $DMNAME &";


NAME := SN0001, "DMCMD";
:'NAME' := "dmcmd applic /opt/prog/myScript $DMNAME &";



This is documented in the appropriate manuals.


There are a couple of "gotcha"s though:

1) If the variable being set is secured or missing, you will get an
operational error that will either cause an SBX to be fired or suspend the
block.
2) Each external reference suspends the execution of the HLBL code for one
block period if the target is outside the CP. If the target is inside the
CP, the call does not suspend the code, but it can take quite a long time.


The former issue is difficult to handle properly if one has several external
references in the code since they will all fire the same SBX and you will
probably want different handling for each case. Personally, I do not use
this approach. I prefer to use a program like cpShell and send it messages
from SENDCONF (see below).


The second issue causes subtle problems in the code. I had one customer call
because his emergency shutdown logic took 10s to execute and it was only 20
lines of code. The problem was that he did not know about the suspension of
execution on an external reference. Since his block ran every 0.5 seconds
though, 10s to execute the code was as good as he could expect.

There is no workaround for this delay other than to not use external
references, i.e., connect the targets to the output of the block. Of course,
that can lead to conflicts with the operator if the operator needs to set
the same targets.



Re: Executing Scripts and Programs from a Sequence Block

There was a long discussion on how to run scripts on demand. The options
boil down to:


*   Using the external reference capability of HLBL to set the DMCMD
global of a DM/FV instance
*   Using SENDMSG or SENDCONF to send a message to a program that will
execute the command.


There are issues with the first approach related to error handling, i.e.,
what happens and how do you handle it if the DMCMD variable does not exist
or someone overrides your command before it can be executed. These are
actually quite difficult to handle.


The latter approach is much more controllable. The SENDCONF command has a
timer. It suspends execution of the sequence block and sets the SUSPND
parameter. When the SUSPND parameter is reset or the timer expires, the
sequence block awakes. If it awakes because of a timeout, the flow of
control goes to a particular part of your logic associated with exactly that
failure. If it awakes because the SUSPND parameter is reset, the flow of
control moves to the next line.


Sadly, we do not ship such an application with the standard system. However,
you can get a copy of one by ordering cpShell. This is a VAS-IT item which
means that it is sold as reusable application engineering. It is licensed on
a per unit basis where we trust you to have a reasonable "process unit".


To order, tell your account rep that you want:


Part No: VAS-IT
Description: cpShell for Solaris
Order Type: ZZPB or ZZPR 
Item Tag: cpShell for Solaris
Special Shipping Instructions: Contact Ruby Chapman in Houston to fill the
cpShell order.
Delivery: 4 to 8 weeks ARO.
List Price (US): 2,200 USD


I'll send you the manual separately.


I'm sure that there are others with similar products.



Regards,


Alex Johnson
10707 Haddington
Houston, TX 77043
713.722.2859 (office)
713.722.2700 (switchboard)
713.932.0222 (fax)
[EMAIL PROTECTED]  


-Original Message-
From:   Jones, Charles R. (Chuck) [SMTP:[EMAIL PROTECTED]]
Sent:   Monday, July 09, 2001 8:59 AM
To: 'Foxboro DCS Mail List'
Subject:RE: HLBL REF.

If the operators can interact with the process, I recommend putting
GDEV
blocks to AUTO (then WAIT 2 seconds for the block to see it) right
before
you use each one.  It is the only way to be sure that the GDEV will
be in
the correct auto/manual state when you need it to be.  If you are
going to
change state on several GDEVs, then you can put t

RE: HLBL REF.

[Johnson, Alex (Foxboro)]

Setpars is a pretty powerful tool. I hope you are very careful with its use.
It will make changes to the CP that are not reflected in the checkpoint file
or the workfile.


Regards,


Alex Johnson
10707 Haddington
Houston, TX 77043
713.722.2859 (office)
713.722.2700 (switchboard)
713.932.0222 (fax)
[EMAIL PROTECTED]  


-Original Message-
From:   [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
Sent:   Monday, July 09, 2001 9:52 AM
To: Foxboro DCS Mail List
Subject:RE: HLBL REF.


It is a Unix script, currently called via a foxview button , I would
like
to include this in the sequence logic if possible.
The script utilizes  the "setpars"  tool found in
/opt/fox/bin/tools.



Ken Moore
NSCC




"Jones, Charles R. (Chuck)" <[EMAIL PROTECTED]>
@lists.TheCassandraProject.org> on 07/09/2001 11:59:08

Please respond to "Foxboro DCS Mail List"
  <[EMAIL PROTECTED]>

Sent by:  <[EMAIL PROTECTED]>


To:   "'Foxboro DCS Mail List'"
<[EMAIL PROTECTED]>
cc:
Subject:  RE: HLBL REF.


If the operators can interact with the process, I recommend putting
GDEV
blocks to AUTO (then WAIT 2 seconds for the block to see it) right
before
you use each one.  It is the only way to be sure that the GDEV will
be in
the correct auto/manual state when you need it to be.  If you are
going to
change state on several GDEVs, then you can put them all to AUTO
followed
by
only one WAIT statement.

If you want to call the script that you have already written, then I
am
going to have flex a few thoughts to remember how to do that.
Depending on
how you wrote the UNIX script, I believe that it may be a more
efficient
use
of resources to rewrite it in HLBL.  Is it a UNIX script, PERL, C
code, or
--Heaven forbid-- JAVA?  (I am assuming UNIX.)  Does the script use
Object
Manager calls or API calls?

I'm curious now.  Does any one know if HLBL is the most efficient
use of
resources in this case?  Does anyone know how to call an external
script
from within HLBL?

Chuck Jones
Refinery Automation Technologist
A.E. Staley Mfg. Co. -- Lafayette South Plant
765.477.5324 - Office  | 765.420.4431- Pager

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 09, 2001 5:17 AM
To: Foxboro DCS Mail List
Subject: RE: HLBL REF.



Thanks for the input,

I have a script that places all GDEV blocks in auto. How would you
use this
in HLBL. I would like to place all GDEV's in auto at the beginning
of the
Sequence Logic.

thanks in advance
Ken Moore
NSCC

This e-mail and any files transmitted with it are confidential and
intended
solely for the use of the individual or entity to whom they are
addressed.
If you are not the intended recipient or the person responsible for
delivering the e-mail to the intended recipient, be advised that you
have
received this e-mail in error, and that any use, dissemination,
forwarding,
printing, or copying of this e-mail is strictly prohibited.  If you
have
received this e-mail in error, please notify the TLNA HELPDESK at
800-404-2436 or e-mail [EMAIL PROTECTED]


---
This list is neither sponsored nor endorsed by the Foxboro Company.
All
postings from this list are the work of list subscribers and no
warranty
is made or implied as to the accuracy of any information
disseminated
through this medium. By subscribing to this list you agree to hold
the
list sponsor(s) blameless for any and all mishaps which might occur
due to
your application of information received from this mailing list.

To be removed from this list, send mail to
[EMAIL PROTECTED]
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]




IMPORTANT NOTICE:
This email is confidential, may be legally privileged, and is for
the
intended recipient only.  Access, disclosure, copying, distribution,
or
reliance on any of it by anyone else is prohibited and may be a
criminal
offence.  Please delete if obtained in error and email confirmation
to the
sender.



---
This list is neither sponsored nor endorsed by the Foxboro Company.
All 
postings from this list are the work of list subscribers and no
warranty 
is made or implied as to the accuracy of any information
disseminated 
through this medium.

Re: OPC client for I/A?

[Bakke, Richard A]

Corey,
We are have been using the Matrikon OPC server for almost a year to make I/A
points (740 points so far) available to our mill info system, and to send a few
values back to I/A.  The Matrikon OPC server is running on an NT box and
communicates via ethernet to an AW51B to open FoxAPI lists.  It is working very
well.

The only slight issue I have is that they are not currently making use of the change
delta, so all the values are sent each time period (we are currently using 10 sec,
which is the max period).  We have been encouraging them to do this, though we have
not had any trouble with LAN loading to date.

Rich



Corey R Clingo wrote:

> Hello all,
>
> I'm looking for a way(s) to get data from 3rd-party OPC servers into points on
> an I/A system.  I'd rather not buy an AW70, as we don't have any now and are
> looking to do this as cheaply as possible, but I don't have a problem with
> something running on a generic PC and talking to a 51-series box.
>
> I've seen 3rd-party OPC servers for the I/A, but no clients.  The only client
> I've come across is the one from Foxboro, but that requires an AW70, as far as I
> can tell.
>
> The data is monitor-only and extreme robustness of the system is not required
> (if it were, I wouldn't be using OPC in the first place ;-).
>
> Any pointers or, better yet, actual application experience in this area would be
> most helpful.
>
> TIA,
>
> Corey Clingo
> Sr. Engineer
> BASF Corporation
>
> ---
> This list is neither sponsored nor endorsed by the Foxboro Company. All
> postings from this list are the work of list subscribers and no warranty
> is made or implied as to the accuracy of any information disseminated
> through this medium. By subscribing to this list you agree to hold the
> list sponsor(s) blameless for any and all mishaps which might occur due to
> your application of information received from this mailing list.
>
> To be removed from this list, send mail to
> [EMAIL PROTECTED]
> with "unsubscribe foxboro" in the Subject. Or, send any mail to
> [EMAIL PROTECTED]


---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: HLBL REF.

[Johnson, Alex (Foxboro)]

Re: Sequence Block Resources

HLBL is slow. Each line of HLBL code is roughly equivalent to the CPU
requirements of an AIN block.

External references to CBPs in the same CP take even longer.



Re: Setting External OM Variables from within HLBL

HLBL allows OM variables (C:B.Ps and SVs) to be set directly using the
following syntax:

: := ;

where 

 is a C:B.P name or a Shared Variable Name
 is the new value for the variable.

The leading colon is required. Two examples are:


:TOWER:OVRHD_LEVEL.SPT := 50.0;


:WP0001DMCMD := "dmcmd applic /opt/prog/myScript $DMNAME &";


NAME := SN0001, "DMCMD";
:'NAME' := "dmcmd applic /opt/prog/myScript $DMNAME &";



This is documented in the appropriate manuals.


There are a couple of "gotcha"s though:

1) If the variable being set is secured or missing, you will get an
operational error that will either cause an SBX to be fired or suspend the
block.
2) Each external reference suspends the execution of the HLBL code for one
block period if the target is outside the CP. If the target is inside the
CP, the call does not suspend the code, but it can take quite a long time.


The former issue is difficult to handle properly if one has several external
references in the code since they will all fire the same SBX and you will
probably want different handling for each case. Personally, I do not use
this approach. I prefer to use a program like cpShell and send it messages
from SENDCONF (see below).


The second issue causes subtle problems in the code. I had one customer call
because his emergency shutdown logic took 10s to execute and it was only 20
lines of code. The problem was that he did not know about the suspension of
execution on an external reference. Since his block ran every 0.5 seconds
though, 10s to execute the code was as good as he could expect.

There is no workaround for this delay other than to not use external
references, i.e., connect the targets to the output of the block. Of course,
that can lead to conflicts with the operator if the operator needs to set
the same targets.



Re: Executing Scripts and Programs from a Sequence Block

There was a long discussion on how to run scripts on demand. The options
boil down to:


*   Using the external reference capability of HLBL to set the DMCMD
global of a DM/FV instance
*   Using SENDMSG or SENDCONF to send a message to a program that will
execute the command.


There are issues with the first approach related to error handling, i.e.,
what happens and how do you handle it if the DMCMD variable does not exist
or someone overrides your command before it can be executed. These are
actually quite difficult to handle.


The latter approach is much more controllable. The SENDCONF command has a
timer. It suspends execution of the sequence block and sets the SUSPND
parameter. When the SUSPND parameter is reset or the timer expires, the
sequence block awakes. If it awakes because of a timeout, the flow of
control goes to a particular part of your logic associated with exactly that
failure. If it awakes because the SUSPND parameter is reset, the flow of
control moves to the next line.


Sadly, we do not ship such an application with the standard system. However,
you can get a copy of one by ordering cpShell. This is a VAS-IT item which
means that it is sold as reusable application engineering. It is licensed on
a per unit basis where we trust you to have a reasonable "process unit".


To order, tell your account rep that you want:


Part No: VAS-IT
Description: cpShell for Solaris
Order Type: ZZPB or ZZPR 
Item Tag: cpShell for Solaris
Special Shipping Instructions: Contact Ruby Chapman in Houston to fill the
cpShell order.
Delivery: 4 to 8 weeks ARO.
List Price (US): 2,200 USD


I'll send you the manual separately.


I'm sure that there are others with similar products.



Regards,


Alex Johnson
10707 Haddington
Houston, TX 77043
713.722.2859 (office)
713.722.2700 (switchboard)
713.932.0222 (fax)
[EMAIL PROTECTED]  


-Original Message-
From:   Jones, Charles R. (Chuck) [SMTP:[EMAIL PROTECTED]]
Sent:   Monday, July 09, 2001 8:59 AM
To: 'Foxboro DCS Mail List'
Subject:RE: HLBL REF.

If the operators can interact with the process, I recommend putting
GDEV
blocks to AUTO (then WAIT 2 seconds for the block to see it) right
before
you use each one.  It is the only way to be sure that the GDEV will
be in
the correct auto/manual state when you need it to be.  If you are
going to
change state on several GDEVs, then you can put them all to AUTO
followed by
only one WAIT statement. 

If you want to call the script that you have already written, then I
am
going to have flex a few thoughts to remember how to do that.
Depending on
how you wrote the UNIX script, I believe that it may be a more
efficient use
of resources to rewrite it in HLBL.  Is it a UNIX

RE: HLBL REF.

[Ken . E . Moore]

It is a Unix script, currently called via a foxview button , I would like
to include this in the sequence logic if possible.
The script utilizes  the "setpars"  tool found in /opt/fox/bin/tools.



Ken Moore
NSCC




"Jones, Charles R. (Chuck)" <[EMAIL PROTECTED]>
@lists.TheCassandraProject.org> on 07/09/2001 11:59:08

Please respond to "Foxboro DCS Mail List"
  <[EMAIL PROTECTED]>

Sent by:  <[EMAIL PROTECTED]>


To:   "'Foxboro DCS Mail List'" <[EMAIL PROTECTED]>
cc:
Subject:  RE: HLBL REF.


If the operators can interact with the process, I recommend putting GDEV
blocks to AUTO (then WAIT 2 seconds for the block to see it) right before
you use each one.  It is the only way to be sure that the GDEV will be in
the correct auto/manual state when you need it to be.  If you are going to
change state on several GDEVs, then you can put them all to AUTO followed
by
only one WAIT statement.

If you want to call the script that you have already written, then I am
going to have flex a few thoughts to remember how to do that.  Depending on
how you wrote the UNIX script, I believe that it may be a more efficient
use
of resources to rewrite it in HLBL.  Is it a UNIX script, PERL, C code, or
--Heaven forbid-- JAVA?  (I am assuming UNIX.)  Does the script use Object
Manager calls or API calls?

I'm curious now.  Does any one know if HLBL is the most efficient use of
resources in this case?  Does anyone know how to call an external script
from within HLBL?

Chuck Jones
Refinery Automation Technologist
A.E. Staley Mfg. Co. -- Lafayette South Plant
765.477.5324 - Office  | 765.420.4431- Pager

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 09, 2001 5:17 AM
To: Foxboro DCS Mail List
Subject: RE: HLBL REF.



Thanks for the input,

I have a script that places all GDEV blocks in auto. How would you use this
in HLBL. I would like to place all GDEV's in auto at the beginning of the
Sequence Logic.

thanks in advance
Ken Moore
NSCC

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you are not the intended recipient or the person responsible for
delivering the e-mail to the intended recipient, be advised that you have
received this e-mail in error, and that any use, dissemination, forwarding,
printing, or copying of this e-mail is strictly prohibited.  If you have
received this e-mail in error, please notify the TLNA HELPDESK at
800-404-2436 or e-mail [EMAIL PROTECTED]

---
This list is neither sponsored nor endorsed by the Foxboro Company. All
postings from this list are the work of list subscribers and no warranty
is made or implied as to the accuracy of any information disseminated
through this medium. By subscribing to this list you agree to hold the
list sponsor(s) blameless for any and all mishaps which might occur due to
your application of information received from this mailing list.

To be removed from this list, send mail to
[EMAIL PROTECTED]
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]




IMPORTANT NOTICE:
This email is confidential, may be legally privileged, and is for the
intended recipient only.  Access, disclosure, copying, distribution, or
reliance on any of it by anyone else is prohibited and may be a criminal
offence.  Please delete if obtained in error and email confirmation to the
sender.


---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

Re: OPC client for I/A?

[Neil Martin]

Matrikon has an OPC Server for Foxboro and they also have software that
enables two OPC Servers to communicate back and forth.




   
   
Corey R Clingo 
   
<[EMAIL PROTECTED]>  To: Foxboro DCS Mail List 
   
Sent by: 
<[EMAIL PROTECTED]>  
<[EMAIL PROTECTED]cc:   
   
oject.org>   Subject: OPC client for 
I/A? 
   
   
   
   
07/09/01 11:05 AM  
   
Please respond to "Foxboro 
   
DCS Mail List" 
   
   
   
   
   



Hello all,

I'm looking for a way(s) to get data from 3rd-party OPC servers into points
on
an I/A system.  I'd rather not buy an AW70, as we don't have any now and
are
looking to do this as cheaply as possible, but I don't have a problem with
something running on a generic PC and talking to a 51-series box.

I've seen 3rd-party OPC servers for the I/A, but no clients.  The only
client
I've come across is the one from Foxboro, but that requires an AW70, as far
as I
can tell.

The data is monitor-only and extreme robustness of the system is not
required
(if it were, I wouldn't be using OPC in the first place ;-).

Any pointers or, better yet, actual application experience in this area
would be
most helpful.

TIA,

Corey Clingo
Sr. Engineer
BASF Corporation



---
This list is neither sponsored nor endorsed by the Foxboro Company. All
postings from this list are the work of list subscribers and no warranty
is made or implied as to the accuracy of any information disseminated
through this medium. By subscribing to this list you agree to hold the
list sponsor(s) blameless for any and all mishaps which might occur due to
your application of information received from this mailing list.

To be removed from this list, send mail to
[EMAIL PROTECTED]
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]






---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: OPC client for I/A?

[Lemieux, Tom]

Corey,

I believe Matrikon makes an OPC server that will talk to an AW51. 
Phone 780-448-1010
www.matrikon.com


Thanks Tom Lemieux
Process Systems Specialist
Alabama Pine Pulp
Phone334-743-8576
Fax 334-743-8295
Email  [EMAIL PROTECTED]

 -Original Message-
From:   Corey R Clingo [mailto:[EMAIL PROTECTED]] 
Sent:   Monday, July 09, 2001 11:05 AM
To: Foxboro DCS Mail List
Subject:OPC client for I/A?

Hello all,

I'm looking for a way(s) to get data from 3rd-party OPC servers into points
on
an I/A system.  I'd rather not buy an AW70, as we don't have any now and are
looking to do this as cheaply as possible, but I don't have a problem with
something running on a generic PC and talking to a 51-series box.

I've seen 3rd-party OPC servers for the I/A, but no clients.  The only
client
I've come across is the one from Foxboro, but that requires an AW70, as far
as I
can tell.

The data is monitor-only and extreme robustness of the system is not
required
(if it were, I wouldn't be using OPC in the first place ;-).

Any pointers or, better yet, actual application experience in this area
would be
most helpful.

TIA,

Corey Clingo
Sr. Engineer
BASF Corporation



---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

OPC client for I/A?

[Corey R Clingo]

Hello all,

I'm looking for a way(s) to get data from 3rd-party OPC servers into points on
an I/A system.  I'd rather not buy an AW70, as we don't have any now and are
looking to do this as cheaply as possible, but I don't have a problem with
something running on a generic PC and talking to a 51-series box.

I've seen 3rd-party OPC servers for the I/A, but no clients.  The only client
I've come across is the one from Foxboro, but that requires an AW70, as far as I
can tell.

The data is monitor-only and extreme robustness of the system is not required
(if it were, I wouldn't be using OPC in the first place ;-).

Any pointers or, better yet, actual application experience in this area would be
most helpful.

TIA,

Corey Clingo
Sr. Engineer
BASF Corporation



---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: HLBL REF.

[Jones, Charles R. (Chuck)]

If the operators can interact with the process, I recommend putting GDEV
blocks to AUTO (then WAIT 2 seconds for the block to see it) right before
you use each one.  It is the only way to be sure that the GDEV will be in
the correct auto/manual state when you need it to be.  If you are going to
change state on several GDEVs, then you can put them all to AUTO followed by
only one WAIT statement. 

If you want to call the script that you have already written, then I am
going to have flex a few thoughts to remember how to do that.  Depending on
how you wrote the UNIX script, I believe that it may be a more efficient use
of resources to rewrite it in HLBL.  Is it a UNIX script, PERL, C code, or
--Heaven forbid-- JAVA?  (I am assuming UNIX.)  Does the script use Object
Manager calls or API calls?  

I'm curious now.  Does any one know if HLBL is the most efficient use of
resources in this case?  Does anyone know how to call an external script
from within HLBL?

Chuck Jones
Refinery Automation Technologist
A.E. Staley Mfg. Co. -- Lafayette South Plant
765.477.5324 - Office  | 765.420.4431- Pager

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 09, 2001 5:17 AM
To: Foxboro DCS Mail List
Subject: RE: HLBL REF.



Thanks for the input,

I have a script that places all GDEV blocks in auto. How would you use this
in HLBL. I would like to place all GDEV's in auto at the beginning of the
Sequence Logic.

thanks in advance
Ken Moore
NSCC

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you are not the intended recipient or the person responsible for
delivering the e-mail to the intended recipient, be advised that you have
received this e-mail in error, and that any use, dissemination, forwarding,
printing, or copying of this e-mail is strictly prohibited.  If you have
received this e-mail in error, please notify the TLNA HELPDESK at
800-404-2436 or e-mail [EMAIL PROTECTED]

---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

RE: HLBL REF.

[Ken . E . Moore]

Thanks for the input,

I have a script that places all GDEV blocks in auto. How would you use this
in HLBL. I would like to place all GDEV's in auto at the beginning of the
Sequence Logic.

thanks in advance
Ken Moore
NSCC




"Jones, Charles R. (Chuck)" <[EMAIL PROTECTED]>
@lists.TheCassandraProject.org> on 07/06/2001 17:35:52

Please respond to "Foxboro DCS Mail List"
  <[EMAIL PROTECTED]>

Sent by:  <[EMAIL PROTECTED]>


To:   "'Foxboro DCS Mail List'" <[EMAIL PROTECTED]>
cc:
Subject:  RE: HLBL REF.


I don't know for certain about the "C precursor" commands. I am familiar
with C pre-processor commands.  I wonder if "precursor" refers to them.

In case you are not familiar with them, the most common ones that I use
are:

#include filename

#define MANUAL FALSE

#define AUTO TRUE

#define LOCAL FALSE

#define REMOTE TRUE

#define OPEN TRUE

#define CLOSED FALSE

Note that the include syntax is slightly different than C. It does not
include the angle brackets, e.g. #include . Also, it searches for
filename in the directory /opt/fox/ciocfg/sequeninclude.  When using
pre-processor commands the # must be in the left-most column.  (So, we draw
on FORTRAN, also ;-)  Also, there must be no space after the #.

The define statements are some examples of the syntax and its usage. From
this example, I can now use the words like MANUAL in the source code. When
the code is compiled, the pre-compiler first replaces all strings that
conform to MANUAL with the string FALSE, etc.

Since this particular list of define statements is universal in all of my
code, I have put them into an include file.  That way, I don't have to
re-type them for every program.


-Original Message-
From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED]
 ]
Sent: Friday, July 06, 2001 4:04 PM
To: Foxboro DCS Mail List
Subject: RE: HLBL REF.



There are some references on the FOXDOC CD, but they are in about three
different places.
Also the use of "C precursor " commands is not mentioned anywhere.

HLBL syntax does resemble Pascal, but it is not Pascal.

Ken


This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you are not the intended recipient or the person responsible for
delivering the e-mail to the intended recipient, be advised that you have
received this e-mail in error, and that any use, dissemination, forwarding,
printing, or copying of this e-mail is strictly prohibited.  If you have
received this e-mail in error, please notify the TLNA HELPDESK at
800-404-2436 or e-mail [EMAIL PROTECTED]

---
This list is neither sponsored nor endorsed by the Foxboro Company. All
postings from this list are the work of list subscribers and no warranty
is made or implied as to the accuracy of any information disseminated
through this medium. By subscribing to this list you agree to hold the
list sponsor(s) blameless for any and all mishaps which might occur due to
your application of information received from this mailing list.

To be removed from this list, send mail to
[EMAIL PROTECTED]
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]




IMPORTANT NOTICE:
This email is confidential, may be legally privileged, and is for the
intended recipient only.  Access, disclosure, copying, distribution, or
reliance on any of it by anyone else is prohibited and may be a criminal
offence.  Please delete if obtained in error and email confirmation to the
sender.


---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

AW: AIMAPI via Visual Basic for Applications

[Sascha Wildner]

Oops, the linefeed in the an_read_init() declaration was inserted by my mail
program.  In my modules it's all in one line.

Regards,
Sascha



-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]Im Auftrag von Sascha
Wildner
Gesendet: Freitag, 6. Juli 2001 15:57
An: Foxboro DCS Mail List
Betreff: AIMAPI via Visual Basic for Applications


Dear Folks,

I'm trying to access AIMAPI functions via Visual Basic for Applications with
mixed success.  Everything works fine when I call functions with no
arguments.  Take a module with the following declarations:

--8<--
Option Compare Database
Option Explicit

Public Declare Function an_print_err Lib "aimapi" () As Integer
Public Declare Function an_read_init Lib "aimapi" (ByVal initfile As String)
As Integer
-->8--

When I call an_print_err() it returns 0 (like it should).  It seems to find
the library and the return value is also 0 if I set it to some nonzero value
first.  BUT...I have not yet been able to call an_read_init() (or any other
function with arguments).  When I test an_read_init() I always get a VBA run
time error 49 indicating that I used a wrong DLL calling convention (rough
translation of the error text).  I suppose that there is something wrong
with my parameter declaration.

BUT WHAT???


For testing I used the following statements:

Dim reterr As Integer
reterr = an_print_err()
reterr = an_read_init("an_init.cfg")


Regards,
Sascha Wildner
erpicon Software Development GmbH



---
This list is neither sponsored nor endorsed by the Foxboro Company. All
postings from this list are the work of list subscribers and no warranty
is made or implied as to the accuracy of any information disseminated
through this medium. By subscribing to this list you agree to hold the
list sponsor(s) blameless for any and all mishaps which might occur due to
your application of information received from this mailing list.

To be removed from this list, send mail to
[EMAIL PROTECTED]
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]


---
This list is neither sponsored nor endorsed by the Foxboro Company. All postings from 
this list are the work of list subscribers and no warranty is made or implied as to 
the accuracy of any information disseminated through this medium. By subscribing to 
this list you agree to hold the list sponsor(s) blameless for any and all mishaps 
which might occur due to your application of information received from this mailing 
list.

To be removed from this list, send mail to [EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

AW: HLBL REF.

[Sascha Wildner]

Folks,

here's the (I hope) complete list of all documents related to HLBL and
sequences:

B0193AV Chapter  7: Editing Sequence Logic
B0193AV Chapter  8: Sequence Language
B0193AV Chapter  9: HLBL Statements
B0193AV Appendix A: Sequence Control Printed Error Messages
B0193AW Chapter 10: Sequence Logic
B0193AX Chapter 16: Description of the DEP block
B0193AX Chapter 54: Description of the EXC block
B0193AX Chapter 58: Description of the IND block
B0193AX Chapter 69: Description of the MON block
B0193AX Chapter 96: Description of the TIM block (not a real sequence block,
but closely related)

Helpful Hint #302:  Simulating Value Change-Driven Strings on Displays
Helpful Hint #353:  Executing SBXs when a DEP is Paused
Helpful Hint #674:  Executing display manager commands from scripts
Helpful Hint #792:  Using Texteditor in the ICC

PSS 21S-4V2 B3: Sequential Function Chart/Structured Text Configurator
(SFC)

SFC Online Help


Regards,
Sascha


-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]Im Auftrag von D.B. H.
Gesendet: Sonntag, 8. Juli 2001 03:40
An: [EMAIL PROTECTED]
Betreff: Re: HLBL REF.


Ken,
I use the following documents for HLBL work:
1. BO193AX - Tab 58 for Indendent Block parameters (useful in HLBL and
setting up block initially).
2. BO193AV - Tab 7 is for editting sequence logic (I don't need this info.
anymore and I edit either with vi or notepad then FTP back to AW/AP, but
this section tells you how to use ICC to compile. Tab 8 explains subroutines
and gives examples of code. It is best to set up a standard and use this as
include statements or over and over in programs (e.g.: for opening valves,
and starting equipment). Tab 9 is useful for describing HLBL statements, and
Appendix A - gives you all the error codes when executing/debugging code. I
can't find this document on the website though!
3. BO193AW - Tab 10 covers types of sequence blocks and subroutines,
4. Finally, even if you aren't going to purchase a batch package you can
learn quite a bit from the course BAT01, if they still offer it.
If you need any help email me off list at [EMAIL PROTECTED] and I can share
some of the ways I have done this type of programming.
Sincerely,
Diane B. Harris
Harris Automation Services, Inc.
http://www.HarrisAS.com

Original Message Follows
From: [EMAIL PROTECTED]
Reply-To: "Foxboro DCS Mail List" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: HLBL REF.
Date: Thu, 5 Jul 2001 13:52:49 -0400
MIME-Version: 1.0
Received: from [209.145.196.197] by hotmail.com (3.2) with ESMTP id
MHotMailBD0E33050061400431C9D191C4C584CF0; Thu, 05 Jul 2001 15:19:57 -0700
Received: from nstarch.com by lists.CyberSpaces.net with SMTP; Thu, 5 Jul
2001 15:14:21 -0700
>From [EMAIL PROTECTED] Thu, 05 Jul 2001 15:21:02 -0700
Message-ID: <[EMAIL PROTECTED]>
X-MIMETrack: Serialize by Router on GBRHN001/BKB/ICI(Release 5.0.7 |March
21, 2001) at 07/05/2001 06:57:15 PM
Sender: <[EMAIL PROTECTED]>
Precedence: Bulk
List-Software: LetterRip Pro 3.0.7 by Fog City Software, Inc.
List-Subscribe: 
List-Unsubscribe: 

Can anyone recommend a reference manual source for the HLBL used in
sequence code?
IMPORTANT NOTICE:
This email is confidential, may be legally privileged, and is for the
intended recipient only.  Access, disclosure, copying, distribution, or
reliance on any of it by anyone else is prohibited and may be a criminal
offence.  Please delete if obtained in error and email confirmation to the
sender.



---
This list is neither sponsored nor endorsed by the Foxboro Company. All
postings from this list are the work of list subscribers and no warranty
is made or implied as to the accuracy of any information disseminated
through this medium. By subscribing to this list you agree to hold the
list sponsor(s) blameless for any and all mishaps which might occur due to
your application of information received from this mailing list.

To be removed from this list, send mail to
[EMAIL PROTECTED]
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]


_
Get your FREE download of MSN Explorer at http://explorer.msn.com


---
This list is neither sponsored nor endorsed by the Foxboro Company. All
postings from this list are the work of list subscribers and no warranty
is made or implied as to the accuracy of any information disseminated
through this medium. By subscribing to this list you agree to hold the
list sponsor(s) blameless for any and all mishaps which might occur due to
your application of information received from this mailing list.

To be removed from this list, send mail to
[EMAIL PROTECTED]
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]


-