Dave B, Joe B, Jeff K, Darkhan T,

Overview

It was discovered that a signal generated by a FixedPhaseOsc part, which is currently present in SUS-(E|I)TM(X|Y), CAL-CS, CAL-PCAL(X|Y) and some PI front-end models, is not guaranteed to have a fixed phase at GPS time 0 after a model containing the part is restarted.

See details for a suggested bug fix.

Before the bug is fixed in the code, one must update the frequency of an oscillator to some non-nominal value, say 0 Hz, and then set it back to its nominal value every time after a model with an fixed-phase oscillator is restarted. This operation should synchronize the phase of the oscillator to be 0 degrees at GPS time 0.

We restarted all of the oscillators in the SUS-ETMY, CAL-CS and CAL-PCAL(X|Y) models (cal. lines) after the issue was discovered.

Details

The FixedPhaseOsc part is expected to generate a periodically oscillating output with a requested frequency and a phase that would be 0 degrees if measured at GPS time 0. However, recent investigations revealed that the phase of a signal from FixedPhaseOsc was rather random every time a model is restarted (related alogs: 29992, 30197). We found that when a model is restarted, a FixedPhaseOsc static variable that stores the last known requested frequency does not get initialized properly. This problem can be fixed by replacing lines 100-101 in release/src/epics/util/lib/OscFixedPhase.pm with:

my $calcExp = "\L$::xpartName[$i]_freq = 0;\n";

This correction will result in a "true" condition in line 158, leading to proper initialization of the variables in the FixedPhaseOsc code.