python-ezca issueshttps://git.ligo.org/cds/software/python-ezca/-/issues2023-07-06T03:52:52Zhttps://git.ligo.org/cds/software/python-ezca/-/issues/15get_LIGOFilter wait=True isn't waiting full ramp time2023-07-06T03:52:52ZCamilla Comptonget_LIGOFilter wait=True isn't waiting full ramp timeI'm using ezca.get_LIGOFilter from within a guardian node and it appears that the wait=True parameter isn't waiting the full ramp_time specified.
See attached example:
- At 15:14:03 the DRIVEALIGN_L2L_GAIN's are changed with a `ramp_...I'm using ezca.get_LIGOFilter from within a guardian node and it appears that the wait=True parameter isn't waiting the full ramp_time specified.
See attached example:
- At 15:14:03 the DRIVEALIGN_L2L_GAIN's are changed with a `ramp_time=20, wait=True` (lines 61 and 62 in SUS_CHARGE guardian code).
- Only **15 seconds** later at 15:14:19 the LOCK_L gain is taken to 0 (line 65).
- Can see this in the attached ndscope too.
![code_get_LIGOFilter](/uploads/76bc25f999dd224e4e1ccc18c0757f98/code_get_LIGOFilter.png)
^ SUS_CHARGE guardian code and log.
![get_LIGOFilter](/uploads/8e600a0ae48f138dbda0769becda87f8/get_LIGOFilter.png)
^ ndscope showing 15 seconds (not 20) between L2L gain change (bottom green plots) and LOCK_L gain change (middle pink plot).https://git.ligo.org/cds/software/python-ezca/-/issues/14LIGOFilter needs clear_history method2023-05-23T19:23:48ZJameson Rollinsjameson.rollins@ligo.orgLIGOFilter needs clear_history methodhttps://git.ligo.org/cds/software/python-ezca/-/issues/13Adding filter alarm setting method2020-05-14T23:32:04ZJameson Rollinsjameson.rollins@ligo.orgAdding filter alarm setting method```
Charles Celerier (Stanford Advanced Gravitational Wave Interferometry Group) 2014-02-27 01:59:23 PST
As of RCG 2.7, every filter has SWMASK, SWREQ, and SWSTAT channels which can be
used to for alarming on whether a filter is in the...```
Charles Celerier (Stanford Advanced Gravitational Wave Interferometry Group) 2014-02-27 01:59:23 PST
As of RCG 2.7, every filter has SWMASK, SWREQ, and SWSTAT channels which can be
used to for alarming on whether a filter is in the requested state. The
attached patches add methods to the LIGOFilter class for setting the SWMASK and
SWREQ channels. Note that the patch for the Ezca class adds the ability to
write to ENUM type channels, which is necessary for changing the alarm level on
the SWSTAT.HSV channel.
These methods are particularly useful for building graphics on MEDM screens
since the SWSTAT alarm makes it very easy for an MEDM rectangle to determine
whether a filter is in the correct state or not. For example, the SEI system
uses colored MEDM rectangles to indicate the status of of the isolation and
damping filters.
```
[0001-ezca-Add-support-for-using-ENUM-type-channels-throug.patch](/uploads/ceb94bf9451b98a8b458d0f07c018624/0001-ezca-Add-support-for-using-ENUM-type-channels-throug.patch)
[0002-ligofilter-const-Added-basic-simple-methods-for-writ.patch](/uploads/415aa8c629781f1dd1e5a45be794a28c/0002-ligofilter-const-Added-basic-simple-methods-for-writ.patch)https://git.ligo.org/cds/software/python-ezca/-/issues/12LIGOFilter contstructor should not requires ezca object2020-05-14T22:05:03ZJameson Rollinsjameson.rollins@ligo.orgLIGOFilter contstructor should not requires ezca objectusually ezca object is global, so just use that if it's available.usually ezca object is global, so just use that if it's available.https://git.ligo.org/cds/software/python-ezca/-/issues/11deprecate ligofilter Mask class in favor of SFMask2020-05-14T21:13:20ZJameson Rollinsjameson.rollins@ligo.orgdeprecate ligofilter Mask class in favor of SFMaskMask is currently an alias for SFMask. deprecated the Mask object, remove
references to it from any system that still reference it (SEI), and remove it.Mask is currently an alias for SFMask. deprecated the Mask object, remove
references to it from any system that still reference it (SEI), and remove it.https://git.ligo.org/cds/software/python-ezca/-/issues/10"fast many" write method to allow writing multiple channels simultaneously2020-05-14T18:34:08ZJameson Rollinsjameson.rollins@ligo.org"fast many" write method to allow writing multiple channels simultaneouslye.g. with some sort of threading...
See: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=19765e.g. with some sort of threading...
See: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=19765https://git.ligo.org/cds/software/python-ezca/-/issues/9write should include option to specify set point channel and/or value2020-05-14T18:32:36ZJameson Rollinsjameson.rollins@ligo.orgwrite should include option to specify set point channel and/or valueThis would primarily be to handle the problem with momentary switches that change back to some nominal value after being set. It may have other uses as well, if for instance there are settings channels that should use different channels...This would primarily be to handle the problem with momentary switches that change back to some nominal value after being set. It may have other uses as well, if for instance there are settings channels that should use different channels for readback.https://git.ligo.org/cds/software/python-ezca/-/issues/8write logs sometimes not indicating updated value2020-05-14T18:27:52ZJameson Rollinsjameson.rollins@ligo.orgwrite logs sometimes not indicating updated valueThis is transferred from bugzilla:
```
Jameson Graef Rollins (LIGO - Caltech) 2016-11-30 15:27:00 PST
I'm re-opening this report after talking to Sheila about it a bit more. ezca
writes have wait=True set by default, and are therefore...This is transferred from bugzilla:
```
Jameson Graef Rollins (LIGO - Caltech) 2016-11-30 15:27:00 PST
I'm re-opening this report after talking to Sheila about it a bit more. ezca
writes have wait=True set by default, and are therefore not supposed to return
until the write has taken place. The failure we're seeing here seems to
indicate that the wait is not happening, or is not happening in a truly
synchronous way. I think more investigation is required.
```
```
Jameson Graef Rollins (LIGO - Caltech) 2018-02-15 20:00:13 PST
Some more clarity on this:
It's entirely possible that a pyepics get() immediately following a put() will
not show the just-put value. This is because by default get() is reading the
value from the EPICS CA subscription, and the subscription might not have been
updated yet from the recent put(). With pyepics you can specify
pv.get(use_monitor=False) to force pulling the value directly from the channel,
instead of just taking what's in the subscription value.
There's no clean way to universally deal with this in Ezca without incurring a
cost. One might expect that write(wait=True) would not return until the
subscription itself had been updated, but that would definitely add
considerable more time to writes, which are already slow. read() could use
use_monitor=False by default, but that would undermine the entire point of
subscriptions and also slow down reads considerably.
I think the best we could do is to expose the use_monitor=False in ezca.read()
so that it could be used if needed.
```https://git.ligo.org/cds/software/python-ezca/-/issues/7Feature Request: Support return values for ezca.LIGOFilterManager.all_do method.2020-05-04T04:40:29ZNathan HollandFeature Request: Support return values for ezca.LIGOFilterManager.all_do method.Currently the `LIGOFilterManager.all_do` class method doesn't support the callable argument having return values. This is a useful feature to implement. An example use case would be for supporting tests; for example `myTestResults = myLI...Currently the `LIGOFilterManager.all_do` class method doesn't support the callable argument having return values. This is a useful feature to implement. An example use case would be for supporting tests; for example `myTestResults = myLIGOFilterManager.all_do(myTest)`.
Below I outline some code that should work to implement this:
```python
# Pregenerate results list.
results = [None for _ in self.filter_dict.values()]
# Alter evaluation of function.
for ii, f in enumerate(self.filter_dict.values()):
results[ii] = func(f, *args, **kwargs)
# Check for any output.
if all([ii is None for ii in results]):
# All results are None, nothing was returned.
return
else:
# At least one result is not None
return results
```
There may be smarter/better ways to handle this.https://git.ligo.org/cds/software/python-ezca/-/issues/6`Ezca.read` "as_string" keyword argument not documented2020-03-10T19:05:17ZJameson Rollinsjameson.rollins@ligo.org`Ezca.read` "as_string" keyword argument not documentedhttps://git.ligo.org/cds/software/python-ezca/-/issues/4Move Guardian TimerManager code into ezca2018-11-18T16:15:51ZLee McCullerMove Guardian TimerManager code into ezcaThe timer code is useful for all manner of scripting, and so Ezca should get a property for ezca.timer access. This allows decorators in Guardian access to timers and will allow scripts access as well.
Since this makes a more global tim...The timer code is useful for all manner of scripting, and so Ezca should get a property for ezca.timer access. This allows decorators in Guardian access to timers and will allow scripts access as well.
Since this makes a more global timer, and the concern is that user error handling may not catch the possibility of state timers, I suggest a change such that for ezca timers, the timer may be read out only exactly once after it has triggered, so that users must store the fact that the timer has tripped in local code.
Something like
```python
ezca.timer["CHECK_X"] = 10
X_tripped = False
#some algorithm, or dither or whatever
while True:
time.sleep(1)
if X_tripped or ezca.timer["CHECK_X"]:
X_tripped = True
#DO X
if yadda_yadda_subcall_X():
break
else:
#DO Y
yadda_yadda_subcall_Y()
```
and if the ezca.timer["X"] is checked a second time after tripping, it throws some descriptive error, perhaps with a link to this example pattern.
This avoids the worry of stale timers by forcing a transition to local state. In principle, the Guardian timers should also have this behavoir (in which case they could start using the global timer instance), but it would break existing code.https://git.ligo.org/cds/software/python-ezca/-/issues/2ezca "device" for prefixed channels2018-10-03T00:26:26ZJameson Rollinsjameson.rollins@ligo.orgezca "device" for prefixed channelsAllow an ezca instance to define futher prefixed "devices". This would be useful in e.g. the ISC_LOCK node, for interfacing with all 'SUS_ETMX' channels in a single interface.Allow an ezca instance to define futher prefixed "devices". This would be useful in e.g. the ISC_LOCK node, for interfacing with all 'SUS_ETMX' channels in a single interface.https://git.ligo.org/cds/software/python-ezca/-/issues/1tests needed for setpoint monitoring, EZCA_CA=NOFAIL2018-10-03T00:17:33ZJameson Rollinsjameson.rollins@ligo.orgtests needed for setpoint monitoring, EZCA_CA=NOFAILTests are needed for the following functionality:
* [ ] setpoint monitoring
* [ ] EZCA_CA=DISABLE
* [ ] EZCA_CA=NOFAILTests are needed for the following functionality:
* [ ] setpoint monitoring
* [ ] EZCA_CA=DISABLE
* [ ] EZCA_CA=NOFAIL