Replies: 13 comments 7 replies
-
Basic toolingState saving tooling should include:
This should be easy for the end user, and an API should be provided for programmatic usage. |
Beta Was this translation helpful? Give feedback.
-
Options as to how to specify "good" configuration
|
Beta Was this translation helpful? Give feedback.
-
Tools and functionality to build on top of configuration control
|
Beta Was this translation helpful? Give feedback.
-
TODO reminders
|
Beta Was this translation helpful? Give feedback.
-
Representing a passive checkout resultCombination of non-binary "did it succeed", broken down into maybe:
Any "non-OK" result should include a reason. Reason should likely be just a string to start with (and probably not structured). Checkout results may come in classesThe following may be the same or different, depending on the device:
An example would be a gauge that's reading out just fine, but is not at low enough vacuum for beam to pass through unattenuated. |
Beta Was this translation helpful? Give feedback.
-
Some devices may implicitly depend on other devicesNot all devices can be meaningfully checked out on their own.
Some of these scenarios should be represented at the device level (-> pcdsdevices should be modified). |
Beta Was this translation helpful? Give feedback.
-
Some vacuum-focused classes of devices for design consideration... Gauges
Gate valves
Pumps
PIMS / pop-ins
Mirrors
SATT
|
Beta Was this translation helpful? Give feedback.
-
Not in happi?There may be significant work to get all devices into happi. About 58% of signals (80 of 138) in the user-provided HXR EBD/FEE checkout dashboard were present in happi, according to whatrecord. What does this mean for us?
I think (2) is preferable overall, but it's not something I'm willing to do during the prototyping phase. I think there will always be a strong desire from some to allow for (1), so at the very least we should make sure it could be done without major refactoring required. |
Beta Was this translation helpful? Give feedback.
-
Configurations and groups of configurations
|
Beta Was this translation helpful? Give feedback.
-
"Comparisons" PR?In working on #23, I'm trying to see where it really fits in. I think a viable path forward could be a GUI that does the following for configuration specification:
Additionally:
|
Beta Was this translation helpful? Give feedback.
-
Flatline checking? |
Beta Was this translation helpful? Give feedback.
-
Lightpath status? |
Beta Was this translation helpful? Give feedback.
-
Parameter manager v2De-scoping configuration control - moving it out to a separate project. (Discussion resulting from how MEC-U project is looking for a "setpoint API" that aligns pretty well with a pmgr-style tool)
Ideas / discussion points for requirements
|
Beta Was this translation helpful? Give feedback.
-
What "configuration" needs to hold
For any given happi device, nominal configuration settings should be defined by:
Values should:
atol
,rtol
?)( numeric | string)
when it comes to enumerated values (to discuss/choose)Beta Was this translation helpful? Give feedback.
All reactions