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:
:<variableName> := <value>;
where
<variableName> is a C:B.P name or a Shared Variable Name
<value> 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 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]
-----------------------------------------------------------------------
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]
