Con,

I am not exactly sure of your question, but may this will help.  We often use
CALC as fancy switch blocks to be able to switch which controllers can cascade
to one another.  This requires PRIBLK parameters to be set in the normal manner
and back initialization parameters to be linked using the CALC block parameters.
 Depending on which line-up is desired, the CALC block will jump to a certain
block of steps and then exit out.  We use the PRI and PRO commands in the CALC
block to make all of the initialization things work correctly.

____________________Reply Separator____________________
Subject:    PRIBLK - Our special friend
Author: "O'Brien; Con (EUPRO)" <O'[EMAIL PROTECTED]>
Date:       03/24/2000 10:10 AM

Good morning everyone!

After reading the postings of the last couple of days, I feel emboldened to
share some of my troubles with you all.

I'm trying to pass the "PRIBLK" initialization request and acknowledgment
bits between one controller and two output blocks. The application is a
split-range controller, with the PID output going through two CHARC blocks
to two AOUT blocks. I'm calculating the BCACLI input for the PID block
explicitly in a CALC block, using the BCALOs from the CHARC blocks.

This is straightforward enough, and normally I would do without the PRIBLK
functionality, because all blocks are running in one compound, at the same
period and phase. But unfortunately, the CHARC doesn't seem to recalculate
it's BCALCO unless PRIBLK is set. 

I've come up with a way around, using dummy BIAS blocks to terminate the
initialization chains, but I would really like to be able to pass the BCALC
status bits from both CHARC blocks through to the PID. 

Does anyone have a way of explicitly handling the initialization and
acknowledgment bits in a CALC block? 

Many thanks,

Con O'Brien



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

Reply via email to