Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020 
<== Date ==> <== Thread ==>

Subject: Re: Count record that resets by date
From: Daniel Cuneo via Tech-talk <tech-talk@aps.anl.gov>
To: Eric Norum <wenorum@lbl.gov>
Cc: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Thu, 14 Mar 2019 15:13:37 -0700
I see the confusion. I wasn't using the "now" record to set/update the time, it was only to simulate pressing "reset". I updated the records after removing the simulated presses, which may help explain my reasoning. I about to test it...so I could still be wrong.

If the "reset" button is not pressed over the course of a day, it stays at 0.
If it is pressed,  then it sends the time stamp to "day" which stores it. 

Since "clear' only cares that the day is different to determine  reset to 1 or increment, I do not need to have a record performing a SCAN. 

What do you think ?

>cat db/counter.db 
record(bo, "$(user):reset") {
    field(FLNK, "$(user):day")
}

record(stringin, "$(user):day") {
    field(DTYP, "Soft Timestamp")
    field(INP,  "@%j NPP") 
    field(TSEL, "$(user):now.TIME")
    field(FLNK, "$(user):clear")
}

record(calcout, "$(user):clear") {
    field(INPA, "$(user):day NPP MS")
    field(INPB, "366")
    field(CALC, "A#B?1:0;B:=A")
    field(DOPT, "Use CALC")
    field(OOPT, "Every Time")
    field(OUT,  "$(user):count.C PP")
}

record(calc, "$(user):count") {
    field(INPC, "$(user):clear.VAL")
    field(VAL,  "0")
    field(PINI, "YES")
    #field(TPRO, 1)
    field(CALC, "C?1:VAL+1")
}


On Thu, Mar 14, 2019 at 2:53 PM Eric Norum <wenorum@lbl.gov> wrote:
Let’s work through your code:
  • The ’now’ record process every second.  As part of processing it set’s its TIME field to the current date and time.  At the end of processing it does a forward link to the ‘day’ record.
  • The ‘day’ record thus processes ever second.  It reads the time value from ‘day.TIME’ and converts either the minutes (as shown in your example for testing) or the day of the year and sets its value field from the conversion result.  At the end of processing it does a forward link to the ‘clear’ record.
  • Thus the ‘clear’ record processes every second.  The ‘clear’ record gets its ‘A’ field value from the ‘day’ record.  (FWIW I had an typo in my example, too,   The CALC field should be  “A#B?1:0;B:=A”).  So the value is set to 1 if the new ‘day’ value differs from the value when the ‘clear’ record previously processed.
  • Now here is where you changed things.  You have OOPT set to  "Every Time” so the ‘clear’ record will push a value into the ‘count’ record ‘C’ field every second which will then cause the ‘count’ record to process every second (in addition to the times that the ‘count’ record process as a result of your button being pressed).
  • Thus the ‘count’ record processes at least once per second.  Every time the ‘count’ record processes it either clears or increments its value.  Since you have the ‘clear’ record causing the ‘count’ record to process once a second this means that the ‘count’ record increments its value once per second in addition to incrementing its value every time your button of interest is pressed.

What you need, and what I think was in my original example is to have the ‘clear’ record OOPT field set to "When Non-zero".  This will ensure that the ‘clear’ record causes the ‘count’ record to process (and clear) only when the day (or minute, for testing) changes.



On Mar 14, 2019, at 2:30 PM, Daniel Cuneo <dpcuneo@lbl.gov> wrote:

Hi Eric, I'm not sure if I'm miss-understanding your example, or mis-stated my use case.

Use case: Every time a user presses "reset" on a display manager (caput), the counter increments. The counter resets to 0 everyday at 0 hour, providing a daily sum of resets.

In my adaption of your record scheme, I use the "now" record to simulate pressing  reset (caput on a bo).
I take the time stamp from that press, compare it to the time stored, and increment the count if the time is within the same period, (day, minute or hour depending on %j, %M %H). If the time component increments, then send the reset signal.


On Thu, Mar 14, 2019 at 12:12 PM Eric Norum <wenorum@lbl.gov> wrote:
I think that the code you show below won’t quite work right.  It will increment the count once per second.
Note the OOPT field in my example.  It pushes the value into the count record (and hence causes the ‘count’ record to process) only when the calculation is non-zero — i.e. only when the count record is to be cleared.

On Mar 14, 2019, at 11:32 AM, Daniel Cuneo via Tech-talk <tech-talk@aps.anl.gov> wrote:

This is what I've decided on based on Eric's and Diego's examples:
I learned a lot from this. Many thanks to everyone for sharing their ideas.

One gotacha: The STRINGIN record translates the time stamp to a strftime conversion, %M for testing and %j for production. That output is still a string, "001" through "365". However, CALC takes this string and casts it into an integer. I haven't confirmed this assumed cast from base source code yet, so correct me if I'm wrong.

>cat db/counter.db 
record(bi, "$(user):now") {
    field(PINI, "YES")
    field(SCAN, "1 second")
    field(FLNK, "$(user):day")
}

record(stringin, "$(user):day") {
    field(DTYP, "Soft Timestamp")
    field(INP,  "@%M") # for testing purposes using 1 minute
    field(TSEL, "$(user):now.TIME")
    field(FLNK, "$(user):clear")
}

record(calcout, "$(user):clear") {
    field(INPA, "$(user):day NPP MS")
    field(INPB, "1000")
    field(CALC, "A>B?1:0;B:=A")
    field(DOPT, "Use CALC")
    field(OOPT, "Every Time")
    field(OUT,  "$(user):count.C PP")
}

record(calc, "$(user):count") {
    field(INPC, "$(user):clear.VAL")
    field(VAL,  "0")
    #field(TPRO, 1)
    field(CALC, "C?0:VAL+1")
}

-- 
Eric Norum
wenorum@lbl.gov




-- 
Eric Norum
wenorum@lbl.gov




Replies:
Re: Count record that resets by date Eric Norum via Tech-talk
References:
Count record that resets by date Daniel Cuneo via Tech-talk
Re: Count record that resets by date Matt Newville via Tech-talk
Re: Count record that resets by date Daniel Cuneo via Tech-talk
Re: Count record that resets by date Daniel Cuneo via Tech-talk
Re: Count record that resets by date Eric Norum via Tech-talk
Re: Count record that resets by date Daniel Cuneo via Tech-talk
Re: Count record that resets by date Eric Norum via Tech-talk

Navigate by Date:
Prev: Re: Count record that resets by date Eric Norum via Tech-talk
Next: Re: Count record that resets by date Eric Norum via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020 
Navigate by Thread:
Prev: Re: Count record that resets by date Eric Norum via Tech-talk
Next: Re: Count record that resets by date Eric Norum via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020 
ANJ, 14 Mar 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·