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