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