class function decorators (self, static methods, etc)
Confluence page with notes plus link to presentation
one of first instincts was to start with inline comments and create
make a block diagram of the lasers with an meclas overlay?
from the device perspective also block diagram to help explain what each machine does from a controls perspective
Peregrine wants to get head around the laser setup more broadly to understand context better
walked through the first part of the LPL up through the bias control box
20250822
talked about this in CDSO meeting, turned into a long discussion, needed to remind people what happened a few years ago
some feedback now is that shouldn't update on PCDSHub repo since technically in a grey area since ECS doesn't own it
alternate repo for lasers and timing related code?
Peregrine talked to Galtier about this, impression that some things might change about how they do sequencing for Dimitri's experiment, but turns out this isn't the case – already support for that and done it before
external resources? Peregrine concerned these resources come and go, concerned that even if their deliverable is documentation then there would still be a learning curve
whatever code we have is maintained by ECS so treat it like something maintained by controls, then adding features goes through that group
phase the approach – agree that scarce resources which hurts work continuity, but if make smaller project that's self contained and make a standard that they want then test it locally, and then maybe use Cosylab?
1) get code into pcdshub (compliant and accepted)
2) SME on laser and ECS each conversant enough to do productive and effective business
look for 1hr starting mid-August on weekly basis
good to start thinking requirements:
global coordination
Marc, Bob, and user-proof
20230725
start looking at pulse shaping as the overall focus of the OIP
need immediate training on laser for MEC personnel even before new code is written
boil meclas existing code down to requirements, help point out lurking hazards in the requirements
as write the requirements, can build general time estimates
some things may need to be pushed into an IOC?
20230721
Alex would prefer to start from requirements and build up rather than starting from the existing code base, but this also doesn't fit with MEC's needs and timescales; MEC-U timeline is too far out as well
What is the main thing about what this project should be? Project scope should be changed – what are the concrete expectations?
examples: kept on GitHub, code managed by ECS (e.g. for changes and updates), loaded natively within MEC hutch python environment, etc.
20230623
recast some of the material in the previous slideshow into a higher-level discussion, backing out some functional requirements from the meclas classes and functions (reminder: GitHub package here)
The main functional requirement of the meclas package is to organize the many hook-ups of PVs and IOCs into higher-level systems and sub-routines for the purpose of optimized beam delivery.
Operation of the MEC laser systems is quite complicated and time-consuming, especially considering the amount of resources allocated to running the system compared to the expected performance of the system. While the laser systems are very large, the configuration of each system tends to be fairly static, which means the system is highly amenable to automation and computerized optimization. This offloading of operational burden from human to silicon is a practical necessity for delivering the system according to experimental requirements and specifications.
LPL main functional requirements:
turn on and optimize the laser system from a cold start or during the middle of an experiment, including check-out of controls system and frequency conversion efficiency
specify different types of arbitrary shapes, including segmented waveforms, at different intermediate sections of the system – RF arbitrary waveform generator/AWG, optical pre-amplifier/YLF Front-End (YFE), optical booster amplifier/1" glass heads, aggregated optical power amplifiers/2" glass heads, aggregated frequency converters/doublers
establish a simple protocol for defining these shapes at these different positions and have the ability to quickly save and recall them
fluidly map the different real and target waveforms between different bases on the AWG, oscilloscope, etc. and be able to convert them to power vs time
determine how to adjust the shape based on measurements and feedback from the laser output
converge to new or previous goal waveforms either with low-energy high-rep (10Hz) feedback or with high-energy single-shot feedback
load, save, view, and refresh output optical waveforms
permit users to select and load previously-prepared pulse shapes
check out laser system and gauge machine protection prior to taking a shot on target
collect data and reset system after taking a shot on target
Stores functions related to LPL pulse shaping, data acquisition, etc. Functions include: :_LinearWave #function for linear waveforms appropriate for loading to the Highland AWG :_LinearWave2 #function for linear waveforms of variable length, appropriate for specifying targeted pulse shapes :_ParabolicWave2 #function for parabolic waveforms of variable length, appropriate for specifying targeted pulse shapes :_ExponentialWave2 #function for exponential waveforms of variable length, appropriate for specifying targeted pulse shapes :_EW2 #shorthand version of _ExponentialWave2 tailored for facilitating LPL shaping at 10Hz :_EW2stringhint #same as above but produces strings for the benefit of saving wave hints in recipes :_ComboWave #combines waveforms for pulse shaping goals :_TraceFormatting #projects/downsamples waveforms from one horizontal base to another :_UpdatingShapingAlgorithm #calculates new Highland input based on old input, its corresponding output, and a target :_FixEdges #allows tweaking of behavior of points near waveform discontinuities (edges and steps) :_SmoothWvfm #locally smooths an input waveform as an option as part of pulse shaping :_PulseGoal #helps define a targeted waveform for the full energy output :_PulseMax #helps set the desired amplitude of _PulseGoal based on shape and desired output energy :_Psns_get #retrieves the list of pulse segment durations of the current targeted output pulse :_Psns_set #sets the list of pulse segment durations of a new targeted output pulse :_SSs_get #retrieves the list of pulse segment start/stop heights of the current targeted output pulse :_SSs_set #sets the list of pulse segment start/stop heights of a new targeted output pulse :_YSSs_get #retrieves the list of YFE exponential pulse segment start/stop heights of the current targeted 10Hz output pulse :_YSSs_set #sets the list of YFE expnential pulse segment start/stop heights of a new targeted 10Hz output pulse :_wIter2 #wrapper function for using _UpdatingShapingAlgorithm in context :_weichall #generates weighted waveforms for YFE, 1in1w, 4x2in1w, and 4x2in2w outputs using scopes and energy meters :_weichToPowerVsTime #converts energy-weighted waveforms into a tuple of instantaneous power vs time :_PGToPowerVsTime #converts scaled _PulseGoal waveforms into a tuple of instantaneous power vs time :_pshostcheck #checks the host of the current computer to verify it is a machine with all the proper network access for pulse shaping :_DateString #shortcut for generating a string of today's date :get_curr_exp #retrieves the current experiment name in MEC :get_curr_run #retrieves the current run number in MEC :get_curr_shape #retrieves the last loaded pulse shape in MEC :_psheaders #prepares the groundwork for pulse shaping exercises :_psacqx #acquires data after taking a shot :_psefc #plots most-recent shot compared to its goal and returns a suggestion for a new input waveform :psefc10Hz #performs pulse shaping at 10Hz to converge towards an input goal for the YFE output :_psupd #shortcut for updating the Highland waveform :psloadwvfm #loads a previously-saved pulse shaping recipe :pssavewvfm #saves a new pulse shaping recipe :psviewwvfm #displays a previously-saved pulse shaping recipe :psrefrwvfm #refreshes a previously-saved pulse shaping recipe to account for system drift :psrecipes #lists all previously-saved pulse shaping recipes :psmenu #allows loading or viewing of previously-saved pulse shaping recipes from a list :pspreshot #executes routine that prepares the state of the laser and its diagnostics for a full-energy shot :pspostshot #executes routine that records all data after a full-energy shot and returns the laser to a stand-by state :On #turns the long-pulse laser system on :SHG_opt #executes the optimization routine for the SHG crystal angles of all four arms of the LPL
Potential future work includes: - put all the stuff Galtier wants to do inside lpl - LPL.On() instead of YFE.On(), e.g. - same for seeing shapes, changing energy, etc. - help avoid TAB-complete problems because of object instantiation - like LOSC('a'), for example - change names to be lowercases so Galtier can TAB-complete easier - add underscores to methods not generally intended for non-expert usage - consider consolidating some functions into one - e.g. _LinearWave, _ExponentialWave, etc. - add Deconvolution function -- help shape, seems that 100ps length also affected - account for the instrument response of the PD, amp, scope, etc. in determining a detected waveform - save PFN voltages on-shot too? - Scope vertical resolution problem -- casting somewhere? better to motorize characterized ND filters... - Slow feedback to 10Hz pulse goal based on full shot rbv? Esp to help front edge problems? - Need this combined with SCALLOPS? Need a fit function to data for the full rbv? - YSSs: YFE equivalent of SSs - Steal a notepad pv array - _EW2(Psns, YSSs) - Have a version of pulsegoal but 10hz using _ew2 to interpolate instead of lw, still have dellist - SmartPulseGoal10Hz using output of SCALLOPS
efc main functional requirements:
check and reload the package
shorthand ways to save and load files
shorthand ways to take input and format output to terminal
shorthand ways for interfacing with PVs
shorthand standard sleep functions
Extra Function Class for convenient shorthand ways of doing common things like printing in color, accepting keyboard input, interfacing with PVs, etc. Typical usage via efc.[command] Possible commands include: :reloadchk #checks the version of the code being used :reloadpkg #reloads the meclas package from file, in case of version update :cstr #generates string with color text/background options :cprint #prints strings with color text/background options :getch #prompts user for a single input character :getch_with_TO #getch but with TimeOut :input_with_TO #input but with TimeOut :pickledump2 #shortcut for saving objects to file :pickleload2 #shortcut for reloading objects from file :dotsleep #shortcut for printing dots while waiting :ssleep #shortcut for standard socket waiting time :rPV #shortcut for reading values from PVs :wPV #shortcut for writing values to PVs potential future work - consider consolidating some functions into one - e.g. getch with and without TimeOut? - add EZeLog function - take care of all the hassle of posting to the LCLS eLog from Python so people can do so very easily - add threading helper functions?
ep main functional requirements:
shorthand ways to generate various types of plots, including common plots or waveforms from common sources
Easy Plotting class for convenient shorthand ways of plotting data; nothing special, just lazy! Typical usage via ep.[command] Possible commands include: :l #quick plot of single array of y values :lxy #quick plot of single array of y values with x values also specified :lxyloglog #quick xy plot with log x- and y-axes :lsav #save plot of single array of y values :lxysav #save plot of single array of y values with x values also specified :lcomp #quick plot meant to compare diode waveform to pulse goal :lcsv #quick plot of single array from csv file :llcsv #quick plot of list of arrays from csv file :rcsv #read in array from csv file :ll #quick plot of list of arrays of y values :llxy #quick plot of list of arrays of y values with x values also specified :llxyloglog #quick xy plot of several lists with log x- and y-axes :llt #plot list of arrays of values according to a time mapping :llcomp #plot list of diode waveforms along with target waveform :lfft #quick plotting of FFT of provided waveform
CtrlSys main functional requirements:
similar kinds of functional requirements as the ATEF effort – controls system check-out, rapid controls troubleshooting, advanced-notice error detection, etc.
Class for monitoring (and potentially controlling) laser-related control systems Typical usage via CtrlSys.[command] Possible commands include: :cmp_checker #checks a list of relevant computers to see if they are pinging the network :pv_checker #checks a list of relevant PVs for current RBV, to see if their IOCs/host are live, etc. Potential future improvements: - expand list of PVs checked in pv_checker - add functionality for checking current PV RBV vs historical reference or allowed range - consider adding functionality of ping, netconfig search, grep_pv, grep_ioc, serverStat, imgr, etc. - when pinging motors, check the control box itself too? (see Stage.NewportBrowserCtrl)
GLOBAL main functional requirements:
repository for global-type variables – commonly-used PVs, IP addresses of common instruments connected via socket, common calibration constants, etc.
reset function for notepad PVs, which in some ways serve as globally-accessed variables but that are changed on a regular basis (calibrated energies, administratively-tracked shutter states, waveforms, etc.)
facilitate changes to the system due to temporary hardware failures, updated configurations, etc.
Class meant to serve like global variables for all other meclas classes Idea is that only the contents of this class need to change if PV names change, calibrations or other constants need to be updated, etc. Typical usage via GLOBAL.[attribute] where attributes might be PVs, constants, arrays, strings, etc.
Potential future improvements: - convert more of the parameters above into GLOBAL attributes for the sake of simplicity, clarity, longevity - add more restoration-type functions
Potential future class containing SPL-related utilities such as: - pointing functions - alignment functions - other macros + automation routines
Potential future class containing timing-related utilities such as: - EVR snapshot and refresh functions - fstiming utilities - Nstiming utilities - Vitara utilities
Potential future class for LPL pulse shaping simulations and shot prediction (i.e. arbitrary pulse shaping) - port everything over from Bethany and Patin? - improved background subtraction needed for improved transfer function accuracy? - need LPL.Deconv too? - test shot routine with triangle pulse (etc.) to grab day's starting transfer function guess? - fit model that makes everything most self consistent; what gets weighed most heavily? - (note: _EW2 probably not useful in that case) - what will recipe look like when based on SCALLOPS? what will recipe contain?
Class containing all the necessary functions for running the Highland Arbitrary Waveform Generator for LPL pulse shaping
Unless speed is necessary, it is usually most appropriate to interface with the Highland simply by using HAWG().[command]. This will take care of all of the socket opening/closing by itself. Example: read out the current Highland waveform using HAWG().ReadPulseHeights() Example: reset the Highland using HAWG().Reset() (Alternatively, save the initialized object via SH=HAWG() and then use SH.ReadPulseHeights(), etc.) List of possible commands includes: :ReadStatus :ClearStatus :ReadPulseHeights :WritePulseHeights :ReadFiducialImpulseSettings :WriteFiducialImpulseSettings :WriteEnableByte :ReadT0Delay :ReadWaveAmplitudeCalibrations :WriteWaveAmplitudeCalibrations :ReadWaveTimeCalibrations :WriteWaveTimeCalibrations :ReadMiscellaneousCalibrations :WriteMiscellaneousCalibrations :ReadWalkTable :WriteWalkTable :FidOn :FidOff
Most of these functions are for expert use only, so please be careful with them! Potential future work: : FET surveys : Highland internal parameter saving and restoring : find fiducial bump : other outstanding functions not yet programmed from the T400B manual
Class containing all the necessary functions for running the LeCroy oscilloscopes Because we have several such scopes, instantiation of a certain device is required Possible scope choices are: my_scope=LOSC('A') #for the YFE, 1in1w, and SHG_opt diodes my_scope=LOSC('B') #for the four 2in1w diodes my_scope=LOSC('1') #for the instruments scientists' oscilloscope my_scope=LOSC('2') #for the four 2in2w diodes
Unless speed is necessary, it is usually most appropriate to interface with a LeCroy simply by using LOSC('[1/2/A/B]').[command] This will take care of all of the socket opening/closing by itself. Example: read out all the current waveform amplitudes on scope '2' using wvfm4=LOSC('2').rchall() Example: wait for a fresh acquisition before reading out channel 2's voltage vs time on scope '1' using ch2_wvfm=LOSC('1').waitrchxy(2) (Alternatively, use the approach above: my_scope = LOSC('A') and then wvfm4=my_scope.rchall() or my_scope.pchxy(4) or whatever)
Possible commands that can be used as described above include: :waitrch #wait and read specified channel amplitude :waitrchxy #wait and read specified channel amplitude and time :rch #immediately read specified channel amplitude :rchxy #immediately read specified channel amplitude and time :rchall #immediately read amplitude for all channels :rchallxy #immediately read amplitude and time for all channels :sch #save plot of specified channel amplitude to file :schall #save plot of amplitude for all channels to file :pch #plot specified channel amplitude :pchxy #plot specified channel amplitude vs time :pchall #plot amplitude of all channels :pchallxy #plot amplitude vs time of all channels :sumch #sum apmlitude of specified channel :save_scope_to_eLog #save specified channel amplitude to eLog :RestoreConfig #restore acquisition settings according to internal memory There are also functions available for use with bare sockets; these tend to start with underscores. See the docstrings for more guidance.
Potential future work: : adding more functionality from the LeCroy manual using the _ctrl function
Class containing readout functions for energy meters on all MEC laser systems Typically used via EMeters.[command]
Possible commands include: :LPLInChamber #returns in-chamber energy meter read-outs :EG #returns 2in2w energy meter read-outs (scaled by calibration factors) :EG1wYFE1in #returns 2in2w energy meter read-outs (scaled by calibration factors) :EG1w2in #returns 2in2w energy meter read-outs (scaled by calibration factors) :EGall #returns 2in2w energy meter read-outs (scaled by calibration factors) :SPLEG #returns energy of SPL energy meter diagnostics :gentec_refresh #refreshes settings of LPL Gentec meters :E_coeff_refresh #refreshes energy coefficients :E_synth_refresh #refreshes synthesized energies written to notepad PVs
See the docstrings for more guidance.
Potential future work: : improve SPLEG accuracy currently affected by changing ambient conditions
Class for controlling different functions of the MBC bias control box used with the LPL front-end seed laser These functions are meant mostly for laser experts. Usage can simply proceed via MBC.[command] Potential commands include: :ModeCheck() :IsSafe() :Reset() Check docstrings of individual functions for more details Potential future improvements: - dither parameter control (if possible -- would need expansion of IOC capability)
Class for organizing functions associated with the YLF Front End (YFE) laser system Usage can simply proceed via YFE.[command] Potential commands include: :OnCheck() #checks whether YFE is on or off :On() #initiates turn-on sequence :Off() #initiates shut-off sequence :Get() #retrieves eDrive current sepoints and RBVs :Set(mmQ,currQ) #changes current setpoint corresponding to certain rod diameters :SetAll(IOBool) #turns on or off all eDrive currents without turning off emission :Trace() #plots oscilloscope trace of YFE output Check docstrings of individual functions for more details
Class for controlling the PFNs of the MEC Nd:glass LPL Typical usage is as follows: PFN.[command] Possible commands include: :HeadENB #reads back which PFNs are currently enabled :EnableOnly #enables PFNs of specified arms and disables PFNs of unmentioned arms :ArmOnly #same as EnableOnly but also allows specification of the HWP (throttle) on the enabled arms
Class for controlling the HWPs of the MEC Nd:glass LPL Typical usage is as follows: HWP.[command] Possible commands include: :On #sets the desired transmission level of the specified arms :Status #prints current HWP settings and returns an array of anticipated transmission levels :ClearStart #attempts to clear motor restart for AB and EF HWPs :HWP_opt #attempts to calibrate the HWP settings such that 0deg corresponds to full transmission
Class mostly containing utilities for GigE cameras for MEC Typical usage via CAM.[command] List of possible commands includes: :Name #helps with names and naming conventions of all cameras in MEC :View #quickly view a single camera or multiple cameras in a python window :QuickSave #saves the data from a specified GigE camera to a PNG image :QuickSaveData #saves the data from a specified GigE camera to a 2D txt file :Config #configures plug-ins for a given camera :ConfigReset #refreshes all current camera configurations Potential future work: - save images to file easily - (also in connection with scan parameters) - GigE_toggle_trigger for configuring SPL camera triggers - setdynxhair for quickly setting a custom temporary crosshair position, etc. - combined utility for tuning a beam while watching a live image of the camera
Class for organizing utilities for the TTL-triggerable beam shutters in the LPL and SPL Current shutter locations (and names) are as follows: :LPL: 4 x immediately before the 2" heads on 'AB', 'EF', 'GH', 'IJ' : 2 x immediately before the periscopes going into the chamber, 'WEST 527' ('WW') and 'EAST 527' ('XX') :SPL: 1 x before the compressor grating of the Legend ('REGEN' or 'ZZ') Shutters do not possess internal state sensor, so state of each shutter (open vs closed) tracked using notepad PVs Typical usage via TTL_shutter.[command] Possible commands include: :Status #provides the current status (open vs closed) of each shutter :Toggle #allows control of shutters to open/close/toggle state :Refresh #refresh state tracker if shutters are touched manually or Beckhoff has problems, etc.
Stores functions related to stages and motors Current functions include: :NewportInitRefAll #useful routine for recovering from Newport outage -- initializes and references all channels :NewportBrowserCtrl #internal function meant for launching the Newport broswer controller Potential future work: -SmarAct motor utilities -motor setting snapshots -motor setting restoration
Potential future class containing DG645-related utilities such as: - take a snapshot of settings to be restored later with a restore function - restore saved data from a snapshot function into the corresponding DG645 - perform snapshots of multiple DG boxes at the same, etc. - change labels of channels to be more descriptive
Potential future class containing UNIBLITZ-related utilities such as: - toggle system (DG boxes, etc.) triggering configurations (e.g. alignment vs SS vs burst modes, etc.) - toggle shutter state - toggle trigger state
Potential future class containing spectrometer-related utilities such as: - Qmini configuration - Qmini readout - floater Ocean Optics/other spectrometers?
Potential future class containing VISAR-related utilities such as: - laser triggering/any other EPICS-connected functions (may need to be expanded) - streak cameras (timing or configuration with shot or whatever is useful)
Potential future class containing lab environment-related utilities such as: - air/enclosure/rack temperature/humidity/etc. - dust/particulate levels
Potential future class containing RIS-related utilities such as: - easy RBV on state, radiation sensors, etc.
Potential future class containing PDU-related utilities such as: - quick and unified access/configuration/toggling of lab PDUs
20230330
(slide show from a meeting on 20230330, meant to allow ECS to better imagine the possible scope of work and routes of attack for an FY23 MEC OIP)