Introduction and Executive Summary

We liked how issues and topics were raised and we could get immediate feedback and ratification of the discussion.
It was a good format for broadcasting the roadmap.
We anticipate the forum as being a productive augmentation of the newsletter for communicating progress in our various campaigns/ goals.

We think it is a good idea to host a forum on a quarterly basis. In-between runs was also suggested, and we may change to this cadence if we hear from more people this is a better option.
We will send out a targeted survey a week in advance of the next forum to collect information we can use to drive the conversation.

Topics in this forum included UI/UX QoL improvements, Experiment setup reconfiguration/ flexibility, SDL process, and ongoing stakeholder feedback.
A number of specific issues that were raised were filed directly into GitHub Issues.

UI/UX Quality of Life Improvements

Forum opened with discussion of LUCID and Typhos, procedurally generated screens (as opposed to artisanal screens).
Screen space efficiency was raised as an issue, which ECS has been aware of for some time. The feedback on this issue gave us a few new ideas for how to tackle the problem.
We believe there are some worthwhile improvements that could be prioritized.
Procedurally generated screens are considered advantageous for a number of reasons including reduced long-term maintenance costs, increased fidelity to the as-built system configuration and consistency in function between UI and command line interfaces (CLI).
Artisanal screens are considered inevitable as it may be in some cases easier to achieve a more dense and intuitive arrangement of readbacks and controls this way. However, we strive to make artisanal screens unnecessary.
We believe 2023 will include opportunities for improvements in the UI to be prioritized and look forward to reporting progress at the next forum.

Feedback regarding the reconfigurability of the L2SI systems, and the proposed designs for HE was discussed.
ECS has been exploring the possibility of user-deployable motion control systems since XPP designs for HE proposed them earlier this year.
Such systems were purposefully excluded from L2SI designs. This was because an overarching goal for L2SI was to do more with less by leveraging automation. System stability was considered essential for automation to work and thus L2SI intentionally focused on building hutches without allocations for user reconfigurable systems.
Despite this, the ECS architecture inherently has the ability to be changed or extended as necessary.
ECS will continue to look into technical solutions to this challenge, but will refrain from any implementation until a larger discussion regarding the nature of operations at LCLS because how LCLS intends to handle ad hoc changes to experiment plans, and experiment planning is still unclear.

Piezo actuators play a key role in high-precision, in-vacuum (and air), positioning for a variety of applications in LCLS systems.
There are at least two piezo actuator “makes” deployed at LCLS, SmarAct and Micronix. PI may also be deployed, but not as prevalently.
When the SDL was first published in January of 2022, ECS had marked the Micronix line of piezo actuators (and controllers) as end-of-life. This was done to encourage consolidation of makes and models, and because Micronix controllers allegedly have a history of issues with reliability.
The forum discussed this change, and how SDL statuses should be handled in general.
More discussion is needed, but there are some outlined processes that will be followed for future changes in status, including additions. In short the process will include collaboration between identified subject matter experts from both mechanical engineering and controls. It remains to be determined how stakeholders from SRD will be included in this process.
More assessment of overall consolidation probably ought to be done. Consider that much of LCLS was pieced together without an objective to minimize the number of makes and models in our systems. We might find that we truly have duplicated solutions, each with their own idiosyncrasies.

It is vital that ECS is responsive to stakeholder feedback, and for stakeholders to know how their feedback is processed.
Spent some time in our close-out session discussing ECS processes for stakeholder feedback.
To understand how stakeholder feedback is acted upon one should understand how ECS is structured internally. ECS’s internal macro-structure consists of two departments, Platform Development and Delivery.
The idea is that the Delivery team consists of points of contact that are meant to represent the wider stakeholder crowd.
We think these Delivery PoC may be the best way to accumulate and cohere stakeholder feedback for Platforms to act upon.
We have determined we need to reinforce our internal interfacing between PD and Delivery through a few changes, and intend to work on this going forward.
Therefore, we want to continue to encourage stakeholders to work through their Delivery PoC to capture feedback, in addition to filing Jira issues (as Jira issues are where all feedback must be recorded in any case).
When appropriate, PD SMEs will be engaged to work directly with stakeholders to ensure we have the best communication possible, while at the same time maintaining PoC engagement to ensure coherence with wider facility needs.