Hi Kevin,
This is indeed the problem I've been having. I'd like to be able to
manipulate the initialization bits directly from a CALC block, so that in
the case of two parallel control streams, I could logically combine the
initialisation requests.
I'd also be interested to hear what the official word is on the CHARC
BCALCO.
Thanks,
Con
> ----------
> From: [EMAIL PROTECTED][SMTP:[EMAIL PROTECTED]]
> Reply To: Foxboro DCS Mail List
> Sent: Saturday, 25 March 2000 9:36
> To: Foxboro DCS Mail List
> Subject: Re:PRIBLK - Our special friend
>
> Hello all,
>
> I've been having similar problems to the one Con has. If I read the docs
> on PRI and PRO in a CALC block right, Niel's suggestion will help me in
> about half of my problems (where I have multiple AOUTs but only use one at
> a time, with a CALC block doing the switching and any characterization).
> I
> am still having problems with controlling parallel downstream blocks
> simultaneously from a single controller and managing initialization and
> error propigation up and down the control stream, especially with CHARC
> blocks downstream.
>
> According to my documentation, the BCALCO on a CHARC block is supposed to
> match measurement all of the time, whether PRIBLK is set or not, however
> that is demonstratibly not the case. I'm down in Foxboro now, and was
> hoping to find someone to fill me in on this Monday.
>
> I also have not been able to set PRIBLK on a PID block (resident on a
> CP30)
> when I have my AOUT on an AB-station. Anyone have any thoughts on this?
>
> Kevin FitzGerrell
> Fairbanks Gold Mining, Inc.
>
> -------------original message-----------------------
> Subject: Re:PRIBLK - Our special friend
> Date: Fri, 24 Mar 2000 08:40:55 -0600
> From: [EMAIL PROTECTED]
> To: "O'Brien; Con (EUPRO)" <O'[EMAIL PROTECTED]>, "'Foxboro DCS mail
> list'" <[EMAIL PROTECTED]>
>
>
>
>
> 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]