Re: [foxboro] IND question
- From: "Johnson, Alex P (IOM)" <Alex.Johnson@xxxxxxxxxxxx>
- To: "foxboro@xxxxxxxxxxxxx" <foxboro@xxxxxxxxxxxxx>
- Date: Mon, 1 Mar 2010 08:58:15 -0600
Part of the issue is the external references - assuming it is outside the CP
holding the IND block.
If that is the case, each one of those will suspend the block for 1 BPC
(minimum) which translates into 1 block period.
So, at the minimum, your WAIT UNTIL is adding 1 block period delay.
Can you bring that value into a RIxxxx parameter? That would eliminate that
delay. The same hold true for the external references in the rest of the code.
I once had a client call and complain that his safety shutdown logic took to
long to run. I asked how is it implemented and how long does it take. He said
it is 20 lines of sequence code and it takes 10s to complete. He sent the code
with his reply. It was 20 external references in a block with a 0.5 PERIOD. I
had to explain that what he saw is normal.
The fix? Bring the values in as connections.
Does this help?
Regards,
Alex Johnson
Invensys Operations Management
10900 Equity Drive
Houston, TX 77041
+1 713 329 8472 (desk)
+1 713 329 1600 (operator)
+1 713 329 1944 (SSC Fax)
+1 713 329 1700 (Central Fax)
alex.johnson@xxxxxxxxxxxx (current)
alex.johnson@xxxxxxxxxxxxxxxx (good until September 2010)
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of dirk.pauwels@xxxxxxxxxx
Sent: Monday, March 01, 2010 5:13 AM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] IND question
Hi list,
If I want to speed up a sequence processing time what are the consequences
if I tamper with PERIOD/BPCSTM?
I have problems with repeat until statements containing several if
endif's. They're too slow..... If one of the conditions to end the repeat
(especially stop and hold_sw in the example) becomes true it takes some
time before the repeat stmt ends. It seems the repeat statement has to go
through it's code before it checks the repeat conditions included in the
until line. How do I speed up this process and what are the disadvantages?
For now I included the "stop" and "hold_sw" conditions in the if endif's
in the repeat statement (at mutiple instances) to detect it faster. It
works more or less, but this also makes the statement longer. There has to
be a more orthodox way to do this....
I also have a similar problem with WAIT UNTIL statements, even if the
conditions are true, the WAIT UNTIL takes a couple of sec's to process. If
there are a lot of them the sequence is very slow going through it's code.
I would expect the wait until to pass very quickly if the condition is
true.
Ie: you'll notice I included the stop and hold_sw multiple times, to
obtain a faster response.
REPEAT
pumped := beginweight_kettle - :'weight'.PNT;RO0002 :=
pumped;
pumprate := ABS(:WEIGHT:K'kettle'PUMP_AIN.PNT);RO0012 :=
pumprate;
IF ::TIMER7.POS_V1 THEN
II0008 := 1;
GOTO finished;
ENDIF;
IF hold_sw THEN
GOTO hold;
ENDIF;
IF stop THEN
II0008 := 2;
GOTO finished;
ENDIF;
IF :'pressP3'.HAI THEN
II0008 := 3;
GOTO hold;
ENDIF;
IF :'level'.BAD THEN
II0008 := 4;
GOTO finished;
ENDIF;
IF hold_sw THEN
GOTO hold;
ENDIF;
IF :'level'.HAI THEN
II0008 := 15;
GOTO finished;
ENDIF;
IF stop THEN
II0008 := 2;
GOTO finished;
ENDIF;
IF :'filterPT'.HAI THEN
II0008 := 16;
GOTO hold;
ENDIF;
IF :'temp' > hitemp THEN
II0008 := 5;
GOTO hold;
ENDIF;
IF hold_sw THEN
GOTO hold;
ENDIF;
IF ...
ENDIF;
IF stop THEN
II0008 := 2;
GOTO finished;
ENDIF;
IF ...
ENDIF;
IF hold_sw THEN
GOTO hold;
ENDIF;
IF ...
ENDIF;
IF hold_sw THEN
GOTO hold;
ENDIF;
IF stop THEN
II0008 := 2;
GOTO finished;
ENDIF;
...
UNTIL ((:'weight'.PNT) < (endweight_kettle + stopweight)) OR stop OR
hold_sw;
IF hold_sw THEN GOTO hold;
ELSE GOTO finished;
ENDIF;
Thanx
Ps: my appologies if I do not answer to some of the list's mails, I do not
seem to receive every posting to the list for some odd reason.....
Dirk
_______________________________________________________________________
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: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
*** Confidentiality Notice: This e-mail, including any associated or attached
files, is intended solely for the individual or entity to which it is
addressed. This e-mail is confidential and may well also be legally privileged.
If you have received it in error, you are on notice of its status. Please
notify the sender immediately by reply e-mail and then delete this message from
your system. Please do not copy it or use it for any purposes, or disclose its
contents to any other person. This email comes from a division of the Invensys
Group, owned by Invensys plc, which is a company registered in England and
Wales with its registered office at Portland House, Bressenden Place, London,
SW1E 5BF (Registered number 166023). For a list of European legal entities
within the Invensys Group, please go to
http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_id=77.
You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail
inet.hqhelpdesk@xxxxxxxxxxxxx This e-mail and any attachments thereto may be
subject to the terms of any agreements between Invensys (and/or its
subsidiaries and affiliates) and the recipient (and/or its subsidiaries and
affiliates).
_______________________________________________________________________
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: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
