EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Named Event, TSE and GeneralTime
From: Dirk Zimoch <[email protected]>
To: <[email protected]>
Date: Wed, 28 Feb 2018 11:32:52 +0100
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.



Replies:
Re: Named Event, TSE and GeneralTime Andrew Johnson
References:
Named Event, TSE and GeneralTime Kim, Kukhee
Re: Named Event, TSE and GeneralTime Michael Davidsaver
Re: Named Event, TSE and GeneralTime Dirk Zimoch
Re: Named Event, TSE and GeneralTime Bruce Hill

Navigate by Date:
Prev: Re: Named Event, TSE and GeneralTime Bruce Hill
Next: epicsThreadGetStackSize Dirk Zimoch
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Named Event, TSE and GeneralTime Bruce Hill
Next: Re: Named Event, TSE and GeneralTime Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
ANJ, 28 Feb 2018 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·