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