Experimental Physics and
Industrial Control System

Dirk Zimoch <[email protected]> · Mon, 26 Feb 2018 11:18:45 +0100

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.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System