Emerson Exchange 365

• Not Answered

Timer

Hi

I want to put a timer to show the time that takes each pumps , is there any parameter on DC block to show that

Hassan.hameed

• 21 Mar 2021 11:49 AM
• Cancel

8 Replies

• Jhad Hanon

  

  • 21 Mar 2021 11:14 PM

  Hi,
  
  You can use the Integrator block, It cones by default with PCSD Pump Modules

  • Cancel
• zazar

  

  • 22 Mar 2021 6:26 AM

  hi sir. you can Gavin more detail about the equation.

  thanks 

  haroon dcs eng 

  call iraq 07701012121 

  • Cancel
• Matt Stoner

  

  • 22 Mar 2021 12:49 PM

  It isn't apparent to me on what you are wanting. Are you wanting total runtime of a pump or time it takes the pump to start?
  
  Books Online has writeup on the block and all the parameters with TRAVEL_TIMER giving you the time it takes the pump/valve to receive feed back on SP changes. The DC block doesn't have a total runtime so you will have to design/configure this which as indicated was typically done with Integrator block.
  
  If you have v13 or later the EDC block actually does have an overall "active" timer (not in passive state) as well as an active state count (i.e. stroke/start count). This would be a better block to use in v13 and later because it has other "features" that make it more flexible and provide more functionality. This along with the DCC block will also provide some controller loading relief (sometimes significant) compared to DC configurations with default interlocks/permissives that are not being used.

  • Cancel
• Hassan.hameed

  

  • 22 Mar 2021 3:07 PM

  In reply to Matt Stoner:

  Yes we looking on total runtime of a pump ,operator want to swap between two pumps after 8 hrs

  • Cancel
• Andre Dicaire

  

  • 22 Mar 2021 5:18 PM

  In reply to Hassan.hameed:

  Yes the EDC block CUR_ACT_TIME and ACT_TIME counters are designed for this. The CUR_ACT_TIME resets every time you start. The ACT_TIME persists until it is reset. So if Pump A starts, Pump_B ACT_TIME is reset, and vise versa.
  
  At the HMI, create a Variable that reads the ACT_TIME and divide by 3600 to get Hours. You can add minutes and seconds variables if you like, but in most cases, having Hours with a decimal fraction serves the purpose of knowing when time reaches 8 hours. (8.00 hrs).
  
  If you go with the Integrator block, you can use the Block Scan multiplier to run the integration every 5 or 10 scans of the module and reduce loading. Consider a composite block with the integrator and some logic to output Hours, Minutes, and maybe seconds. Motor runtime monitoring does not require accuracy to the second.

  Andre Dicaire

  • Cancel
• Andre Dicaire

  

  • 22 Mar 2021 6:39 PM

  In reply to Andre Dicaire:

  one more note on the EDC ACT_TIME value. this is a 32 bit float value and once you get into the millions of seconds ( about 11 days or so), you can start to see accumulation errors as the value being incremented gets rounded up or down to the nearest value of the mantissa. At 8 million seconds, the resolution is 0.5. and values are rounded to nearest number. That is about 3 months.
  
  If you are needing to track motor run times that could get into the millions of seconds the built in Active Timer ( and the CUR_ACT_TIME) would at some point stop updating. This would happen sooner if the module is running at a faster scan rate.
  
  The Integrator block will maintain its accuracy on its internal calculation. Although the output is still the precision of a 32 bit float, it will accurately increment the output value, eventually. This resolution issue is present on all the basic timer blocks that would increment based on the module scan time as the total value of the timer reaches millions of seconds.
  
  For this application, where pumps are switched over every 8 hours, the EDC ACT_TIME will work well, is built in and can be easily displayed in hours with a display expression. The CUR_ACT_TIME would reset each time you start the motor and that too might work, but not if you stop and restart the same motor more frequently than when you switch motors.
  
  For long total accumulated run times, such as tracking run time per month or per year or until replaced, you should capture this in a separate parameter that is reset externally.

  Andre Dicaire

  • Cancel
• Jeffrey Mach

  

  • 26 Mar 2021 12:31 AM

  In reply to Andre Dicaire:

  I think if all you need is to measure the 8 hours for each pump cycle, this is easily straightforward, using the methods suggested above. If you are trying to measure the total runtime for the pump to switch pumps every 8 hours, but then perform major maintenance after the pump has run for hundreds of hours, as some have pointed out, you'll loose precision just using the built in function. It's unlikely to be a serious issue, but if you really want to maintain full precision, you could add a function to move the accumulation to a second register and reset the timer.
  
  For example, if the timer is indicating it has been running for more than a day (86,400 seconds/day), you can add a day to a separate day counter and subtract 86,400 from the timer value. The long term display would need to add the two numbers (current seconds + 86,400 x days accumulated). Note that If you are monitoring for the timer to pass a given timer accumulation that would indicate that the 8 hour pump cycle has elapsed, you would need to similarly subtract 86,400 seconds for the target time to trigger the pump at the correct time.
  
  One can safely assume that your pump will not run for more than a million days (nearly 2,738 years).

  • Cancel
• royalvnm

  

  • 28 Mar 2021 5:59 AM

  In reply to Matt Stoner:

  Sir,
  
  How to find the minimum and maximum value of a single parameter. Eg i need to find the min and max speed of machine for 8hrs. Thanks in advance

  • Cancel