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