...

The supported device list (SDL) is a primary component of our Confluence documentation. The original intent of the SDL was to document what kinds of devices users and other LCLS teams could bring to LCLS that could be integrated with the control system (I think). Then it sort of morphed into a list that tried to capture details of any device we had used with the control system. Things like manuals, datasheets, self-written user guides. Our unwritten rule for device support development were was to create at least a page for a each new device. This resulted in some pages being perfectly sufficient, others being woefully sparse, and still others excessively verbose, nearly to the point of duplicating a manual. Furthermore the SDL became a sort of Interface Control Document (ICD) between PCDS and other teams. Sometimes we might ask, "is it on the SDL?" and if the answer was no, then we didn't support a device. Other times the answer didn't matter.  Someone perusing the SDL might occasionally find a listing had a part number, and then place an order without a another check and find later that it was a bad part number. Other issues included perhaps ordering a piece of hardware they found on the list, only to find that it had been ordered with a different interface than we had seen before, or any other variety of divergent configurations. There were problems. 

So we set out to revamp this crucial systempiece of documentation. You can see some of our development notes here: 2021-11-12 ECS PDG Meeting Notes 2021-11-19 ECS PDG Meeting Notes.

A few months later and we're nearly done with the overhaul. Of course this is really just the start . There are probably many devices that didn't quite make it into the new listas not every device has been captured in this pass, and new devices will need integration as we go along. Most of our work focused on stuff that had been in the list before. We defined a standard way of creating new device pages (called stubs), created an easy to use template button, a page labelling scheme to organize our content, and leveraged some cool Confluence macros. We ended up with a collection of stubs, which we then worked on properly organizing (highlighting another area of Confluence that needed attention, our Subsystems area). The stubs have also given us an excellent structure for further organization of our help-guides and notes on particular devices. 

Other notable features about the new SDL include: global scope, and the ability to create arbitrary organizations of stubs. The former means anyone anywhere on confluence (in any space), can make a stub, and if they use our labeling scheme, we can include the stub in our lists, meaning our stubs can be merged with other groups' to form a lab-wide view of supported devices. The latter meaning we can organize stubs according to any category we create a label for. As an example, a temperature controller might be used for multiple categories, timing system stabilization and sample delivery instrumentation. By applying each subsystem label, plus one for "thermal controls" we can then present this device in any of those contexts. So anyone perusing our SDL could find that temperature controller multiple ways, meaning there's a better chance of them locating information they need quickly.

Finally one of the best features in the new system is the indication of support status. The previous SDL had to maintain information on all devices in production, even (and maybe even especially) the ones we might have wanted to see retired. This would lead to confusion as other people viewing the list might misunderstand that just because something was on the list didn't mean it was still "supported." Now the SDL uses a specific label for Long Term Support, End of Life and Do Not Use so it is crystal clear if the device you're looking at is really still supported or if we're just keeping a stub around to make sure we never buy another one... More explanation of these terms is available on the SDL page: Supported Devices (SDL).

PS. As the newsletter editor I want to highlight that the SDL overhaul was a herculean team effort and a bit of a grind. Thank you to the team for your dedication to actually making real progress improving our documentation!

...

The qRIX Motion and Vacuum PLC are up and running with their IOCs and vacuum screen live and added to RIX LUCID screen.

DC System Procedure Updates

The DC Power confluence page has been updated to include a section on the EEIP standards and processes. The EEIP certification section gives an overview of the EEIP requirements, EEIP reports and documentation required before powering up a new system. 

...

The DC power confluence page has an update on the section Example Component Panels. The section has updated drawings for component PLC & motion DIN Rail. Additionally, a new document has been added for points of contact to remember while doing DC connections on DRL.

Vacuum Control System Architecture Expansions

Adding a new variable leak valve, VAT Series 590 dosing valve, to our supported device list. Check the confluence page here. This valve has integrated controller with EtherCAT interface.  One more member to our increasing EtherCAT family! This valve will be installed on TMO vacuum system soon.  We will also test two new gauges during March. Watch next month ECS newsletter for the announcement!  

...

Our unresolved tickets grew by about 50% from December to the end of February. We're keeping pace, and perhaps with our new resolution workflows we'll start to cut down on the complete backlog.

One thing to note is we'll soon cross a point where it is a good idea to check Jira for prior tickets before submitting a new one. Much like Stack Overflow, Jira tickets are a kind of knowledgebase. 

...