Re: [foxboro] Cascade Master Block Reversing Control

  • From: "Tom VandeWater" <tom@xxxxxxxxxxxxxx>
  • To: foxboro@xxxxxxxxxxxxx
  • Date: Tue, 24 May 2005 10:32:48 -0400

James,
        Now that I can see your block parameters I see one thing that used to 
cause us occasional problems similar to the one you mention.  It happened to us 
when we tied the .FBK parameter of a block to it's own output, (.OUT), such as 
you have done in your SLAVE block.  We now tie the .FBK to the downstream AOUT 
blocks' .MEAS parameter.  Even though it would appear to be the same value, we 
had occasional problems whenever the SLAVE block initialized. When it happened 
to us we found out that the connection to the .FBK parameter of the SLAVE block 
was undefined/disconnected/CYAN and the only way we could get it to reconnect 
was to delete and undelete the SLAVE block. After we connected the .FBK of the 
SLAVE to the AOUT blocks' .MEAS we haven't seen the problem again.
        If you don't change the SLAVE's .FBK connection and the problem occurs 
again, use OMA or build a graphic element to find out the status of the SLAVE's 
.FBK parameter.  I bet it will be disconnected!  Hope this helps.

Tom VandeWater
Control Systems Developer/Analyst
Dow Corning Corporation
Carrollton, KY   USA

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx
[mailto:foxboro-bounce@xxxxxxxxxxxxx]On
Behalf Of James B Koenig
Sent: Tuesday, May 24, 2005 7:47 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Cascade Master Block Reversing Control


I would to thank everyone for your input. I now have an idea of what to
look for. but since this is random, and I am usually not notified until
later, this may be a mute point unless it gets worse, which is the way
we
have been treating it in the past. A couple asked why I had PRIBLK set
to 1
in the Master block, we dont, I would like to apologize for how my block
information looked to everyone, below is a strait line view of my block
connections.

Master Block (temperature)
Period  2
Phase  1
FBK   :SlaveBlock.BCALCO
MODOPT  5
INCOPT     0
PRIBLK      0
INITI         :SlaveBlock.INITO
BCALCI  :SlaveBlock.BCALCO
LOCSP   1
DERIV  0.02

Slave Block (press)
Period  2
Phase  1
FBK   :SlaveBlock.OUT
MODOPT  5
INCOPT  1
PRIBLK    1
INITI        :AOUT.INITO
BCALCI  :AOUT.BCALCO
LOCSP   0
RSP    :MasterBlock.OUT
DERIV  0.0

AOUT
Period  2
Phase  1
MEAS   :SlaveBlock.OUT
PRIBLK  1

thank you


James B Koenig
Production Data Tech
BASF Corp.




                                    "Rick Rys"
To:  foxboro
                                    <Rys@xxxxxxxxxxxxxx>
cc:
                                    Sent by:                       
                                    Subject:
Re: [foxboro] Cascade Master Block Reversing Control
                                    foxboro-bounce@xxxxxxxxxxxxx


                                    05/23/2005 11:37 PM
                                    Please respond to foxboro








I doubt TAC could reproduce your problem, unless you make it happen with
a
simulation or provide some very specific test data.  Basically the
BCALCI
incorporates the FBK and the INITO functions in one connection and are
redundant.  I would try to capture the deviation between the
MASTERBLOCK.OUT
and the MASTERBLOCK.BCALCI as this is the integration input for the
Integral
action.  Additionally, I would verify that neither the master or the
slave
.INITI bits are true.   One other thing to check is the derivative.  If
the
MASTERBLOCK.MEAS is oscillating unsymmetrically (high frequency
saw-tooth
for example), it might be possible that the derivative function is
driving
the controller output.  You might set the Derivative to 0.0 during such
an
event to see if it stops.  Also the derivative has a Kd filter that can
be
adjusted in case you are picking up some noise somehow.  Not sure why
you
have PRIBLK=1 for the MASTERBLOCK?  I think this should be 0.  I assume
that neither the Master of Slave loops are limited in any way during
this
behavior.


Rick Rys P.E.
www.R2Controls.com
508-369-5186 Cell
508-339-6633 Home Office



_______________________________________________________________________
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






_______________________________________________________________________
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 virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 266.11.15 - Release Date: 5/22/2005


--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 266.11.15 - Release Date: 5/22/2005

--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 266.11.15 - Release Date: 5/22/2005

 
 
_______________________________________________________________________
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: