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