• Not Answered

TO AVOID WRONG SP CHANGES

Does anybody know how to configure the controller faceplate, when operator changes the SP, it will change only within (+/-5% of current running SP) when operator will enter the SP. Otherwise a popup will ask operator are you sure to make this change in SP, then change the SP.

4 Replies

  • We achieve this on selected loops (not every one) by customizing the faceplate. Instead of the normal script - which invokes the frsNumericDataEntry function / method - we wrote our own which pops up a dialog box, whose UserForm_Activate and Initialize subs read the pv_scale zero & 100 and calculates an acceptable range ± the current SP for a setpoint change. If the new setpoint is out of the range the form opens a message box saying the new SP was too large / small.

    You might want to disable the "slider" functionality if it concerns you - where you drag the SP to a new value.

    Any customization like this requires the designer to fully test - use at your own risk.
  • To cover changing the SP with both the Slider and the SP Entry box, there are a few things that have to be changed.

    SP Entry box:
    This has to be changed to read the PV Range and then calculate the allowable SP range. I've used the frsReadValue to get the range of the PV scale.
    -example: pvHiVal = frsReadValue("DVSYS.@mod@/PID1/PV_SCALE.F_EU100", 0, "", True)
    You could also use the InputBox() and the frsWriteValue() to prompt for and write the value instead of the frsNumericDataEntry() function that is currently used there. If you replace the frsNumericDataEntry() function, however, you will have to include additional checks on the value being written to avoid any errors.

    SP Slider:
    Limiting the SP Slider is more complicated as it requires changes to the current frsz functions used by the sliders.
    I'd suggest copying the required frsz functions into an SIGlobals module, renaming these new functions, and implementing the SP limits there.
    The Faceplate functions grpSlider1_MouseUp() and CFixPicure_MouseUp() functions would be pointed to the edited frsz functions in the SIGlobals.
    The frsFactoryGlobals functions frszObjMouseUp() and frszIAMouseUp() functions would be edited. I would check that the new value is within your acceptable before sending the new values to the frszWriteMoves() function.

    Things to keep in mind:
    1. John is correct about fully testing any changes. Do not expose the frsz functions anywhere except on a test system.
    2. The CFixPicture_MouseUp function is triggered when a slider has been moved, but the mouse is not over the slider (just over the faceplate) when the mouse button is released. This means that the function will execute if the OUT slider is moved and the mouse is released while not over the slider. If you are planning to make the Slider changes, you should check in your edited frszIAMouseUp() function that the object being moved is the SP Slider before applying the SP Limits
    - example: If objMove.Name = "grpSlider1"
  • And other option that you can consider and this is relatively easy to implement on a per loop basis is to dynamically calculate the set point high and set point low limit parameters to be plus and minus X percent of current set point. If someone enters in a bad value beyond those limits it would automatically limit the amount of change to the calculated limit.

    The obvious negative of this solution is that it eliminates the setpoint high and low limit parameters from being used for their intended purposes, in my case I use local tp1 type variables in our pcsd class and coded the setpoint limits in the same function that calculates the dynamic set point limits.
  • In reply to MPHymel:

    Sorry I had to create that response on a mobile device so forgive the gross grammatical errors such as the very first word