Recent Control & Safety Systems Discussions
Similar Posts
"ALARMCOUNTERS" Parameter. How does it work?
How does the BIAS block work?
Ramp function for SP to a PID in RCAS
How do you ramp when in RCAS?
Does enabling conditional alarming for function blocks affect controller loading?
Share

RAMP Function Block does not work when I use Time parameter

Hi Folks

I am using the RAMP function to close my PID controller to 0% in 20 seconds

The RAMP output is connected to Track_Val of PID controller.

See the attached configuration. When I am using the time function, the ramp function does not work and the controller does not go to 0%.

When I am using the rate function and set a particular Rate of closing in the RAMP function block, the controller does go to 0%

I am attaching my Module configuration.

Has anyone faced a similar issue before wherein the RAMP function works by selecting the Rate parameter but not with Time parameter?

dikshitsh
  • Maarten van der Waal
    The picture shows the ENABLE value to be 0, so no RAMPing would occur.
    Having TRK_IN_D at 1 makes the OUT to equal ti IN.
    So I am surprised that RAMPing happens with the RATE Parameter.
    Please indicate which function is used in the CND2 block.
  • dikshitsh

    In reply to Maarten van der Waal:

    Hi Maarten, Yes this screenshot was taken when the ramp was over so it shows enable as 0, the CND2 has a soft switch value of 0 and 1 to enable and disable the ramp, ramping happens with TIME parameter also but does not go to 0% in 20 seconds(RAMP TIME), TP1 has a time of 25 seconds but with RATE parameter goes all the way to 0%. The strange thing is when I remove the wired connection between RAMP1/IN and PID1/OUT and write to the RAMP1/IN.CV through an ACTION block,with the RAMP1/IN.ST set to 128 the time function also works, which is quite strange.
  • dikshitsh

    In reply to Maarten van der Waal:

    Hi Maarten, By any chance did you get a chance to simulate a similar configuration to mine for the RAMP function, Am I doing something wrong?
  • Maarten van der Waal

    In reply to dikshitsh:

    I created a simulation similar to your picture.
    The CND2 block was a boolean in my configuration.
    Both functions (Rate and Time parameter) are working well.
    I see a question mark indicated on AI1 and AO1. What is the reason for this? The question mark on AO1 could influence the status of RAMP1/IN.
    For now I have no clue what may be wrong.
    What version are you working on? I have version 13.3.1.
  • dikshitsh

    In reply to Maarten van der Waal:

    Hi Maarten, Thanks for the reply. I am also having Version 13.3.1. The question marks are there as I have not connected the DST's and the blocks were in simulate state. Now I have deleted the connections of AI and AO the blocks and using only PID block to test the RAMP. I created another module using the Rate function of RAMP block and simulated the RAMP condition in parallel for both of them. The result is as before, the one with TIME function of 20 seconds does not go to 0 from 100 in 20 seconds and the one with RATE function of 5% per second goes to 0 in 20 seconds. If you dont mind, Can you share your email ID so that I can send the screenshots of the modules and configuration to be more clear.

  • Mark Bendele

    Books Online says the following about the RAMP block, "When the RAMP_TYPE, IN, or END_VALUE parameters change during the execution of the block, the ramp is reset with the new values." I see that you have IN connected to PID1/OUT. IN is changing every scan, so the RAMP block is resetting every scan, attempting to ramp from the current IN to zero in 20 seconds. Somehow you have to freeze the value of IN while the ramp is enabled.

    I had a similar problem except that I was ramping the PID setpoint. I did not have to track the current setpoint, so I disconnected RAMP1/IN and set RAMP1/TRK_IN_D = False. The OUT ramped to END_VALUE just fine, but unfortunately the status of OUT is BadNotConnected when IN is not connected. The PID would not accept a setpoint with a bad status, but I got around it by using an action block to write only the CV. If the RAMP block is in another module, you can output to a floating point parameter without status and read that parameter with an external reference parameter in the module being ramped. That way, the bad status can't pass through.

  • Nabil BOU

    Try to do like that and use SP of PID:

  • gamella

    I've seen that behavior in the past.RAMP fb must be set to ENABLE=FALSE and TRK_IN_D=TRUE when ramp has not to be active and ENABLE=TRUE and TRK_IN_D=FALSE when ramp has to be active.

    Because RAMP fb does not have BKCAL feature output tracking is not automatically handled by RAMP fb. To address this, I use to insert a fb having BKCAL between RAMP and PID function blocks (Bias Gain fb normally).  In this way, Bias Gain fb handles PID/AO out status and RAMP fb is related only to Bias Gain fb.

    NOTE1: Consider using ROUT mode in PID for this CLOSE function. 

    Attached screenshot shows a similar function. In this case RAMP is implemented on PID SP by using RCAS mode on PID. Note that PID/RCAS_OUT is used instead of PID/BKCAL_OUT and for ROUT parameter to use must be PID1/ROUT_OUT. For this sample, when PID is not in RCAS mode PID fb is master and BiasGain fb will track PID SP, passign this value into RAMP/IN. At same time, RAMP fb is set to ENABLE=FALSE and TRK_IN_D=TRUE. This makes RAMP OUT to have same value as RAMP/IN (who already has BiasGain/OUT = PID/SP = AO/CAS_IN value) but also sets RAMP to initial state because ENABLED=FALSE. In this way, when PID is set to RCAS mode, RAMP is initialized with OUT equal to actual AO/CAS_IN.

    NOTE2: Depending on your needs RAMP/BiasGain may be inserted between PID and AO, actiong only on AO. This could be useful if PID does also feed other blocks (another AO through an Split Range in example)

  • gamella

    In reply to Nabil BOU:

    I whould not recommend writing into PID/SP. PID function block itself writes into SP under certain conditions and having something referenced to PID/SP may raise some issues. Use RCAS/ROUT instead if possible
  • dikshitsh

    In reply to Mark Bendele:

    Hi Mark, I also saw books online wherein it mentions the RESET of RAMP block if the Input to it changes, But when the RAMP TYPE is set to RATE parameter with a particular RAMP RATE, the RAMP does not RESET and completes the RAMP cycle in the same configuration as shown in my previous post( RAMP RATE of 5 and the RAMP type set to RATE-The value comes from 100 to 0 in 20 secs, without the RAMP block being RESET even though the RAMP INPUT changes) The RAMP should RESET in both the cases, when RAMP TYPE is Time and also when RAMP type is RATE, but does not do that when RATE is selected.

    I did use the ACTION block to write to the RAMP IN when RAMP is False and not to Write when RAMP is true and deleted the wired connection which works for the requirement that I have

    but still what is strange to me is, RAMP should RESET, If RAMP is active if Input to it changes both in the CASE when RATE is selected and when TIME is selected, but does not do that when RATE is selected. 

  • dikshitsh

    In reply to gamella:

    Hi Gamella

    You are right, one way is to do it the way you have configured, another is by Using ACTION block and break the wired connection and write the value to RAMP IN only when RAMP is not enabled,

    which I used in my case as I need to RAMP the TRACK_IN_D of PID block so kept my configuration simple.

    Thanks for the help.

  • dikshitsh

    In reply to Nabil BOU:

    Hi Nabil

    Thanks for the reply, I need to RAMP the TRACK_IN_D of PID block but used a similar approach as yours, Thanks for sharing.

  • Mark Bendele

    In reply to dikshitsh:

    When the resetting happens, the ramp rate does not change when ramp type is rate. In that case, you set the ramp rate directly. But when ramp type is time, the ramp rate changes every scan that IN, END_VALUE or RAMP_TIME changes, because ramp rate is (IN - END_VALUE)/RAMP_TIME. At least, that is the behavior I have observed.
  • Matt Stoner

    In reply to Mark Bendele:

    Yes the Ramp does reset the time when any of the values change that Mark has indicated in his comment and because of this method you should consider always using Rate instead of Time as it doesn't reset if any of the values change. It will always be the same rate (Slope of the output ramp remains the same always regardless of the changes) instead of rate changing because of where you are starting from (Ramp from 50 to 0 in 20 sec vs 100 to 0 in 20 sec).

    You could change the configuration to remove the wire to IN parameter, only update the IN when the ramp is not active by logic (Make sure the Status is GoodNonCascade) and keep using time if you want but remember the Rate would be different depending on where the starting point of the ramp is.
  • dikshitsh

    In reply to Matt Stoner:

    Hi Matt, Thanks for the reply. Thisis what I precisely did, update the IN when the ramp is not active by logic. Thanks

This is the official online community site of the Emerson Global Users Exchange, a forum for the free exchange of non-proprietary information among the global user community of all Emerson Automation Solution's products and services. Our goal is to improve the efficiency and use of automation systems and solutions employed at members’ facilities by sharing our knowledge, experiences, and application information.

User Groups | World Areas | Community Guidelines | Legal Information | Privacy Policy | Contact Community Manager

Website translation provided by Website Translator

© 2015-2022 Emerson Global Users Exchange. All rights reserved.