Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Wed, 28 Feb 2018 11:53:18 -0600

On 02/28/2018 04:32 AM, Dirk Zimoch wrote:
> 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 is right, there has never been a built-in connection between the
"time event" numbers from a hardware timing system as used by TSE and
the "soft event" numbers used by post_event() and the EVNT field. I
would ask people to adopt the above terminology from generalTime.h to
distinguish the two when discussing them from here on.

The above record demonstrates how to connect the two when you need an
incoming hardware time event to trigger a soft event in a particular
IOC, which is actually a fairly rare thing from what I have seen. No IOC
could handle the traffic if every time event were announced as a soft
event by the receiver driver, thus event records are used to control
which time events become soft events (much easier than having to program
a driver with the same information).

Thus this plan by SLAC doesn't seem quite right and may need to be
re-thought slightly.

I am commenting separately on Bruce's PR#11 which expands the number of
time events. I will look at and comment on your other PRs in due course.

- Andrew

> 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.
>>>>
>>

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System