Repository navigation
Scaler ophyd-async device implementation - #306
Draft
Thomas Hopkins (thopkins32) wants to merge 3 commits into
Draft
Thomas Hopkins (thopkins32) wants to merge 3 commits into
Thomas Hopkins (thopkins32) wants to merge 3 commits into
Conversation
Assisted-by: oh-my-pi:claude-sonnet-5
Assisted-by: oh-my-pi:claude-sonnet-5
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #287
Adds
nslsii.ophyd_async.devices.scaler.Scaler:Scaler: the SynAppsscalerRecord(e.g. a Struck SIS3820 run as a plain VME scaler):.CNT/.TP-driven step counting viatrigger(), per-channel.Sn/.NMn/.PRn/.Gnreadouts (num_channels,hinted_channels), and an optional SIS calc-record extension (num_calculations) for sites (HXN) that compute a derived scalar from the channels on the same IOC, in the same trigger cycle.Here is how it is used:
Motivation / Context
Plain SynApps scaler records and the HXN SIS calc-record extension, and ad hoc retrying-read signal subclasses are independently reimplemented across
csx,tes,xfm,fxi,srx,ios, andhxnprofile collections. This consolidates them into one configurable pair of devices instead of each site's bespoke subclass.I originally tried to implement the flyscanning
ScalerMCSclass but decided against it since it depends on a customZebraSaverIOC and otherwise does not follow the proper flyscanning protocol. To do this work would require a standard mechanism to write this data to disk (HDF writer or similar) and then use ofStandardDetectorand a data logic.Testing
References
SynApps / hardware
Beamline-specific implementations reviewed
90-softGluescalar.pyScaler/FixedScalerCHpattern25-sclr.py90-softGluescalar.py20-scaler.pymode='counting'/'flying'switch togglingread_attrs/configuration_attrsbetween aScalerCHand aScalerMCAsub-device — exactly the single-object, mode-switching design this PR deliberately avoids by keepingScaler/ScalerMCSas two independent devices30-scaler.pySRXScaler, MCS fly-buffer usage, unpaddedmca{1..32}naming05-ion-chamber.pyFXIScaler,EpicsSignalROLazyierretry-on-stale-read subclass (obsoleted here byFormat.UNCACHED_SIGNALreads plus atrigger()that only completes once counting has actually finished)20-detectors.pyDodgyEpicsScaler, same retry-on-stale-read motivation as FXI22-scalers.py,hxntools/struck_scaler.pyStruckScaler/HxnTriggeringScaler, internal/external (modal) channel-advance triggering, SIS calc-record extension,Mca:{1..32}-style (colon) buffer naming