The manager component often serves as a device driver, and often includes highly abstracted code capable of executing complex actions. Commercial solutions usually consist of graphical user interfaces (GUIs) tailored for individual operations and often lack an application programming interface (API) for direct communication. Consequently, custom software modifications are often required to exert control over these devices. The manager therefore provides a "workaround" for some instruments that are limited by their provided user interfaces for automation, or a device driver for more barebones/simplistic instruments. To bridge the communication gap between the (standardized) SiLA2 server and the (device-specific) manager, we implemented a socket server. Although the decoupling introduced by this connection adds complexity to the code architecture, the socket communication layer acts as a safeguard in case of a loss of connection during the execution of sensitive/hazardous operations. The socket layer also addresses the practical need for our researchers to sometimes operate instruments without ChemOS 2.0, and critically, ensure the continued operation of the instrument in the event of a loss of connection between ChemOS 2.0 and the instrument. A deeper description of the SiLA2 server implementation and the socket server can be found in Notes S8, S9, S10 and Figures S1, S2, S5, respectively. A code example of interacting with a SiLA2 server can be found in Note S11.