Re: [foxboro] Setting Application Objects from IND blocks

Re: Apparently, IND blocks run only when their scan periods tell them to
run, regardless of any do-loops and WAIT statements inside the code.

While on the topic of IND block execution:

1) It runs all code to completion when the block is Auto and Active.
2) The BPCSTM parameter will limit the number of statements per BPC.
3) A WAIT or WAITUNTIL will suspend the block's execution. It will check the
wait every BPC until it is time to move on. So a WAIT is not completely
free.
4) External references like yours (:A:O.A := 2) will suspend the block's
execution. For example, ten external references in a block with a 0.5 BPC
will require 5 seconds to complete.
5) Internal references won't suspend the block's execution, but they are
slow compared to other lines of code.
6) If the code terminates its execution, the block will go INACTIVE.
7) If the code loops without wait statements, the block will execute until
the BPCSTM is reached and consume large percentages of the CP's CPU time.

The gist of 6 and 7 is have all paths lead to a WAIT and follow the wait
with a GOTO <<START>> or something similar if you want the block to stay
active and not run amok while doing so.

Maybe everyone knows all of this, but maybe not...



Regards,
 
Alex Johnson
Invensys Process Systems
Invensys Systems, Inc.
10707 Haddington
Houston, TX 77043
713.722.2859 (voice)
713.722.2700 (switchboard)
713.932.0222 (fax)
ajohnson@xxxxxxxxxxx

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Lowell, Tim:
Sent: Wednesday, November 17, 2004 4:49 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Setting Application Objects from IND blocks

Richard,=20

Sorry for the confusion.  Yes, we are using the mapping function for the
bulk of the control.  We just have one little piece of logic that
DMCplus can't handle that we are using IND blocks for.

We think we found the solution.  We were running the IND block with a
PERIOD of 30 seconds.  The block had a "WAIT 60" statement inside of a
do-loop, which we thought would take precedence over the block scan
period.  When we set the PERIOD parameter to 0.5 seconds, the block
behaved as we wanted it to with no latency.  Apparently, IND blocks run
only when their scan periods tell them to run, regardless of any
do-loops and WAIT statements inside the code.  I supposed we should have
assumed that to be true, but for some reason we thought the do-loop
inside the code took precedence.  Another lesson learned.  Thanks for
the responses.

Tim Lowell
Control Systems Engineer
ConocoPhillips Trainer Refinery
(610) 364-8362
tim.c.lowell@xxxxxxxxxxxxxxxxxx


-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Wetton, Richard J
Sent: Wednesday, November 17, 2004 5:38 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Setting Application Objects from IND blocks

Tim,

I can not explain the latency, but have you tried using the map file
instead of the IND block's connectionless connection?   I would normally
try to use the aos mapping function in preference to the IND block,
because the IND block connection creates broadcast messages on every
read or write. The mapping function is looked after by foxapi and is far
more reliable than an IND block.

Richard Wetton.....

-----Original Message-----
From: Lowell, Tim: [mailto:Tim.C.Lowell@xxxxxxxxxxxxxxxxxx]=3D20
Sent: Thursday, 18 November 2004 5:44 AM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] Setting Application Objects from IND blocks


We are working on a DMCplus application where we have to set the values
of Application Objects, which were generated by DMCBridge, using an IND
sequence block.  We are noticing a great deal of latency, upwards of 1
or 2 minutes, between the time the IND sequence code runs and when the
Application Object value gets set.  Here is an example bit of IND HLBL
code:
=3D20

IF value1 > value2

            :APP_OBJ_CMPND:APP_OBJ.PARAM :=3D3D value3;

ENDIF

=3D20

Is this fairly typical of IND sequence code performance?  Is there
something special about Application Objects vs. regular CP blocks that
might cause this?  Is there a setting somewhere that maybe we have left
at the default that governs how fast AO's can be written to?

=3D20

Any ideas would be appreciated.

=3D20

Thanks,

=3D20

Tim Lowell

Control Systems Engineer

ConocoPhillips Trainer Refinery

(610) 364-8362

tim.c.lowell@xxxxxxxxxxxxxxxxxx

=3D20


=3D20
=3D20
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
=3D20
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         =3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Djoin
to unsubscribe:      =3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Dleave
=3D20
=20
=20
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
=20
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
to unsubscribe:      =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
=20
 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
 
 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: