Re: [foxboro] Preventing bad setpoint changes

  • From: kevin.fitzgerrell@xxxxxxxxxxxx
  • To: foxboro@xxxxxxxxxxxxx
  • Date: Tue, 16 Apr 2002 07:48:56 +1200


One common way to minimize this problem is to use ramp buttons as the
primary means of changing setpoints.  For making quick setpoint changes it
is often easier to click a ramp button than it is to enter a setpoint.  If
you make buttons for +-5% and +-1% (or whatever seems most appropriate)
most adjustments can be made quickly without resorting to the keyboard or
keypad, which reduces the possibility of a seriously wrong setpoint change.
Because setpoint changes made this way are fast and can be done entirely
with the mouse or trackball, operator acceptance may not be a problem.

Regards,

Kevin FitzGerrell
Systems Engineer
Foxboro New Zealand
------------------------------------
Tel:  +64 (9) 573 7690
Fax:  +64 (9) 573 7691


                                                                                
                
                    "Lowell, Tim:"                                              
                
                    <tlowell@xxxxxxxx>       To:     "'foxboro@xxxxxxxxxxxxx'"  
                
                    Sent by:                  <foxboro@xxxxxxxxxxxxx>           
                
                    foxboro-bounce@fre       cc:                                
                
                    elists.org               Subject:     [foxboro] Preventing 
bad setpoint     
                                              changes                           
                
                                                                                
                
                    16/04/2002 06:10                                            
                
                    AM                                                          
                
                    Please respond to                                           
                
                    foxboro                                                     
                
                                                                                
                
                                                                                
                





Does anybody have a good method that prevents or at least lessens the
possibility of a console operator entering a really wrong setpoint, like
typing in 5 when he means 50, for example?  I know you can use the SPHLIM
and SPLLIM, but what if the operator really does mean to type in 5 instead
of 50, like during an emergency?  We have that situation here.

What the operations people really want is for the console guy to have a
confirmation overlay pop up, but only if the setpoint change he is making
is
past a given threshold value.  I can't figure out how to do that.  Once he
types in enter, doesn't the PIDA block run and accept the new setpoint?
How
can I insert a block to grab that "intended" new setpoint and compare it to
the current setpoint without the setpoint changing?  I can't use the RSP
parameter because it is already being used, and the operations folks want
this to only happen in Local mode.

Tim Lowell
Control Systems Engineer
Phillips Petroleum Company, Trainer Refinery
Phone:          610-364-8362
Fax:       610-364-8211
tlowell@xxxxxxxx




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