RE: HLBL REF.

[kevin . fitzgerrell]

Norberto,

You're right of course, I should have read that over more closely before
sending.  That should have read:
 setpars -- makes active change in CP
 upload -- updates settable parameters in CP to station workfile
 checkpoint -- builds new checkpoint file based on CP memory
 saveall -- builds diskette based on station workfile

Regards,

Kevin FitzGerrell
Systems Engineer
Foxboro New Zealand

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


   
  
"Marrassini, Norberto" 
  
   
.com.ar> cc:   
  
Sent by:     Subject: RE: HLBL REF.
  
<[EMAIL PROTECTED]  
  
oject.org> 
  
   
  
   
  
07/14/01 03:01 AM  
  
Please respond to "Foxboro 
  
DCS Mail List" 
  
   
  
   
  




Kevin,
   The checkpoint -- builds new checkpoint file based on station
memory
and not station workfile, in that case we can guarantee always to have the
checkpoint file at memory status after a checkpoint, but not the workfile
since upload only updates settable parameters

Norberto Marrassini
Invensys Process Automation - Argentina

-Mensaje original-
De: FitzGerrell, Kevin
Enviado el: Monday, July 09, 2001 7:30 PM
Para: Foxboro DCS Mail List
Asunto: RE: HLBL REF.



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]


---
This list is neither sponsored nor endorsed by the Foxboro Company. All
postings fro

RE: HLBL REF.

[Marrassini, Norberto]

Kevin,
The checkpoint -- builds new checkpoint file based on station memory
and not station workfile, in that case we can guarantee always to have the
checkpoint file at memory status after a checkpoint, but not the workfile
since upload only updates settable parameters

Norberto Marrassini
Invensys Process Automation - Argentina

-Mensaje original-
De: FitzGerrell, Kevin 
Enviado el: Monday, July 09, 2001 7:30 PM
Para: Foxboro DCS Mail List
Asunto: RE: HLBL REF.



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]


---
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: Synchronization (was RE: HLBL REF.)

[Stear, Bo]

Other tools to check synchronization of all the pertinent data files can be obtained 
and aren't mentioned here.  When installed, check_db_sync and ck_multi_cps in the 
directory check_sync located in /opt/fox/bin/tools will give you a warm and fuzzy 
feeling when it successfully reports databases are synchronized.  These tools are a 
part of the (now partially defunct) 'bootless upgrade' feature.  I run these once a 
week and have discovered problems long before they cause real trouble.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Monday, July 09, 2001 7:29 PM
To: Foxboro DCS Mail List
Subject: Synchronization (was RE: HLBL REF.)



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...)

S

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 wo

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] <mailto:[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] <mailto:[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 confi

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] <mailto:[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.  Acce

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] <mailto:[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 d

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] <mailto:[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

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

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] <mailto:[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 y

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] <mailto:[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 
   

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] <mailto:[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 be

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

Re: HLBL REF.

[D.B. H.]

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]

RE: HLBL REF.

[Jones, Charles R. (Chuck)]

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]
<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]

RE: HLBL REF.

[Roberts, Geraint (Calgary)]

In particular:

B0193AV (Chapters 7, 8, 9, Appdx.A).  Ch.8 discusses the use of
C-preprocessor directives.
B0193AW (Ch. 10)

G.R.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: July 6, 2001 3: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




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

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.


Ken,

The only reference I know of is the CON-01 textbook.  I believe the class
is
now called "2100 Integrated Process Control".

This isn't much help, and there may be a better source that I don't know
about.  Perhaps we could start up a project here at the web site.  I would
be interested in contributing. I am now in the process of training 5
people,
so I am current in explaining the details to beginners.  (Not that you're a
beginner, but it would be important in a readable, useable document.)

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: Thursday, July 05, 2001 12:53 PM
To: [EMAIL PROTECTED]
Subject: HLBL REF.


Can anyone recommend a reference manual source for the HLBL used in
sequence code?

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]

---
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]

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




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

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.


Ken,

The only reference I know of is the CON-01 textbook.  I believe the class
is
now called "2100 Integrated Process Control".

This isn't much help, and there may be a better source that I don't know
about.  Perhaps we could start up a project here at the web site.  I would
be interested in contributing. I am now in the process of training 5
people,
so I am current in explaining the details to beginners.  (Not that you're a
beginner, but it would be important in a readable, useable document.)

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: Thursday, July 05, 2001 12:53 PM
To: [EMAIL PROTECTED]
Subject: HLBL REF.


Can anyone recommend a reference manual source for the HLBL used in
sequence code?

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: HLBL REF.

[Jones, Charles R. (Chuck)]

Ken,

The only reference I know of is the CON-01 textbook.  I believe the class is
now called "2100 Integrated Process Control".  

This isn't much help, and there may be a better source that I don't know
about.  Perhaps we could start up a project here at the web site.  I would
be interested in contributing. I am now in the process of training 5 people,
so I am current in explaining the details to beginners.  (Not that you're a
beginner, but it would be important in a readable, useable document.)

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: Thursday, July 05, 2001 12:53 PM
To: [EMAIL PROTECTED]
Subject: HLBL REF.


Can anyone recommend a reference manual source for the HLBL used in
sequence code?

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]