Re: [foxboro] Global Variable Connections
- From: "Doucet, Terrence" <tdoucet@xxxxxxxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Tue, 27 May 2008 20:34:52 -0400
William,
In the sink block, CALCA, connect another input to the .MA parameter of the CIN
block. Do your checkpoint and then toggle the CIN block to Manual and back to
Auto. Hopefully that will resolve the other connection too so that you do not
need to force the contact.
What s/w level are you running in the CP60's? I have done a lot of peer
testing and have never run into that problem. Perhaps with ABSTA but not CP60.
Terry
________________________________
From: foxboro-bounce@xxxxxxxxxxxxx on behalf of William C Ricker
Sent: Tue 27/05/2008 6:59 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Global Variable Connections
OK. How about a related issue.
At a customer site there are 2 CP60s. A CALCA in one CP executes
some logic which uses a Boolean input sourced from a CIN to the other
CP.
When the connection from the CALCA Boolean input is first made
to the CIN in the other CP, it will not resolve until the source
value changes state (we have been thru checkpoints, yes). Further
work shows that that this also happens with other Boolean
connections, and may occur with real values in some cases as well.
This particular application involves boilers, and the signal is a
boiler purge signal; it can not be toggled while the process is up
unless several other blocks are put to manual, and operations
doesn't like that.
What we did as to put a second CIN block in the same CP with the
Purge signal's CIN to repeat the Purge signal. We connect the CALCA
to that second CIN and it can be put into Manual and toggled to
show us the connection is OK, then put in Auto for operation. That
solves the immediate problem.
The base problem remains. Any suggestions for a better work-around
than adding a bunch of otherwise superfluous blocks ??
William C Ricker
FeedForward, Inc.
_______________________________________________________________________
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
-- No attachments (even text) are allowed --
-- Type: application/ms-tnef
-- File: winmail.dat
_______________________________________________________________________
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:
