Re: Named Event, TSE and GeneralTime

[Dirk Zimoch <dirk.zimoch@psi.ch>]

I still think that timing events and db events are two fundamentally 
different things. What connect these two is the event record:
record(event,"$(NAME)") {
  field(DTYP, "APS event receiver")
  field(SCAN, "I/O Intr")
  field(INP,  "#C0 S$(TIMING_EVENT_NR)")
  field(VAL,  "$(DATABASE_EVENT_NAME)")
}

Dirk

On 28.02.2018 10:40, Bruce Hill wrote:
> The primary change that Kukhee is proposing involves
> changing NUM_TIME_EVENTS in epicsGeneralTime.h to
> a larger number.    This affects an array size in epicsGeneralTime.c
> and allows larger event numbers to be requested via
>   epicsTimeGetEvent()
>
> There's also a related change in dbScan.c changing an
> array of cached event_list ptrs from 256 to NUM_TIME_EVENTS.
> This is used by the deprecated post_event() call to do the
> string to event_list lookup once for each event number.
>
> Assuming your timing system calls post_event or the newer
> postEvent when timing events are received, that's the tie-in
> between the TSE and EVNT fields which allows you to process
> records when a timing event occurs and use TSE to fetch the
> corresponding timeStamp.
>
> I've posted a pull request to github w/ the above change:
> https://github.com/epics-base/epics-base/pull/11
>
> Re the TSE field changing from a short to a string:
> I think what we're pointing out is that it's inconsistent to
> make EVNT a string but leave TSE as a short int.
>
> Making this change would require the same support for
> converting compatible strings to event numbers or changing
> epicsTimeGetEvent() to also use a string for the event arg.
>
> We're probably going to continue setting those fields to
> numbers whether the field is a short int or a string,
> as that's what our users and gui's are setup to handle.
> We haven't found a good way to describe all the timing
> options for our new timing triggers as either an integer or
> a string, which drove our request to bump NUM_TIME_EVENTS,
> adding unused event numbers which we'll map to trigger
> output channels.
>
> Cheers,
> - Bruce
>
>
> On 02/26/2018 02:18 AM, Dirk Zimoch wrote:
> > On 24.02.2018 23:08, Michael Davidsaver wrote:
> > > On 02/23/2018 02:37 PM, Kim, Kukhee wrote:
> > > > Dear Core Developers;
> > > >
> > > >
> > > > I and my colleagues in SLAC, are recently studying about the named 
> > > > event and its new API.
> > > > It is helpful us.
> > > >
> > > > LCLS1 used up all of 255 numbered events in event system, and we 
> > > > need more events for LCLS2.
> > > > Since, our timing system need to work for both LCLS1 and LCLS2, we 
> > > > want to extend the number of events.
> > > > The named event removes the cap of 255 events.
> > > Isn't the "cap" +-32767?  The TSE field is DBF_SHORT.  And the second 
> > > argument of epicsTimeGetEvent()
> > > is an 'int'.
> > The old implementation supported only events 1-255.
> >
> > > > But, it also brings some following issues:
> > > >
> > > >
> > > > When we generates event, we latched timestamp and pulse id for the 
> > > > event.
> > > > If we set TSE>0, the generalTime allows to retrieve the timestamp 
> > > > for PVs.
> > > >
> > > > 1.       There is no limit for the number of event, but TSE has 
> > > > limits -2, -1, 0, …. ,255
> > > > 2.       Event can have name (not numberic) but, TSE is still 
> > > > numeric field
> > > >
> > > >
> > > > Since, TSE is still numeric field, we found a quick solution.
> > > >
> > > > We are going to assign  “1” to  name “255” named event for LCLS1 and 
> > > > higher number string (ex, “301”, “302”..) for LCLS2.
> > > > We are going to modify a macro in GeneralTime which limits the 
> > > > maximum number of event to support the higher number events. We are 
> > > > going to extend supporting event number in our Event Provider function.
> > > > Please, let me know if it is acceptable.
> > > This is going to come down to the details.  Will this in any way be 
> > > an incompatible change?
> > > Either to .db files, code calling epicsTime*() functions, or the time 
> > > provider API?
> > > > I am also wondering about future plan for the TSE field generalTime 
> > > > Event Provider.
> > > > Event has name, but TSE is numeric. It looks like we are in the 
> > > > middle of changes.
> > > In order to minimize redundant work, and frustration, it might be a 
> > > good idea
> > > to answer the question of compatibility before going too far.
> > >
> > > > I would like to suggest, if we can change TSE field to accept 
> > > > string. Then, we can solve all of above issues.
> > > > For the backward compatibility for the string TSE field, we can use 
> > > > string for certain function:
> > > > Ex,          “-2”: driver layer updates record timestamp field
> > > >
> > > >                 “-1”: best event provider gives record timestamp
> > > >
> > > >                  “0”: current time provider gives timestamp
> > > >
> > > >                  Named string: best event provider gives timestamp 
> > > > which corresponds to the particular event.
> > I thought that TSE uses hardware events (e.g. from MRF event receiver) 
> > which have not much more in common with db events than a similar name.
> > > If we're going to change TSE to DBF_STRING then:
> > >
> > > 1. You'll need to handle the cases like the ongoing changes involving 
> > > EVNT.  eg. "-2.0"
> > > https://code.launchpad.net/~dirk.zimoch/epics-base/+git/epics-base/+merge/337850 
> > >
> > > 2. How about a meaningful symbolic name as well as the compatibility 
> > > magic numbers?  eg "-2" === "device"
> > >
> > > For what it's worth, I'm quite happy to consider incompatible changes 
> > > to the time provider API
> > > so long as this includes eliminating the global lock.  Now that the 
> > > lockset modify lock has
> > > been eliminated, the generalTime global mutex is the major 
> > > contributor to coupling between
> > > high and low priority scan tasks.