I recently traced a timestamp issue on an older ioc using genSub
to when genSubRecord.c calls recGblGetTimeStamp(), and I think
the same problem exists in aSubRecord.c in 3.14.12.
In our environment, epics timestamps from our EVR's have an embedded
pulseId in the nsec field, which we use to identify which beam pulse
values are derived from. When we use a genSub or aSub record to
do computations related to a beam pulse, that record will either get
it's timestamp via TSE -2 in the records process function or via a TSEL
link to a waveform timestamped w/ the currect pulse ID.
I found that it worked correctly for TSE -2, as the user process function
sets the timestamp. However, when using TSEL to get the genSub or aSub
timestamp, I'd get stale timestamps on any output links which used
a TSEL back to the genSub or aSub record.
The reason this happens is that recGblGetTimeStamp() is getting called
after the output links are processed, and the TSEL based output records
thus grab the aSub timestamp before recGblGetTimeStamp is called.
Has anyone else seen this problem, or know of some reason why we
shouldn't be calling recGblGetTimeStamp before processing the output
records?
Thanks!
- Bruce
P.S. Here's my patch for this:
--- src/rec/aSubRecord.c (revision 19727)
+++ src/rec/aSubRecord.c (revision 19728)
@@ -266,6 +266,7 @@
return 0;
prec->pact = TRUE;
+ recGblGetTimeStamp(prec);
/* Push the output link values */
if (!status) {
@@ -276,7 +277,6 @@
(&prec->neva)[i]);
}
- recGblGetTimeStamp(prec);
monitor(prec);
recGblFwdLink(prec);
prec->pact = FALSE;