Re: Named Event, TSE and GeneralTime

[Bruce Hill <bhill@slac.stanford.edu>]

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.

--
Bruce Hill
Member Technical Staff
SLAC National Accelerator Lab
2575 Sand Hill Road M/S 10
Menlo Park, CA  94025