Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 1 Template Instrument Overview VLTSW 2014 Release Mauro Comin Stewart McLay

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 2 1. Introduction 2. New Architecture 3. Fieldbus hardware support 4. Paranal Additions 5. Multiple ICS Configuration 6. Future development Contents

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 3 The template instrument is...  a reference design for VLT instrument control software  designed to focus on demonstrating the instrument control software architecture  provides simple examples of various features and functionality available in the instrument control software framework  designed to be simple for new users to install, run and learn more about the instrument control software  used by collaborators as a starting point when developing a new instrument control software system  a fully working instrument able to run as a standalone system with software and hardware simulation available Introduction What is the template instrument?

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 4  XXXX/MS/xxmcfg has moved to XXXX/CONFIG/xxmcfg  Introduced support for multiple ICS sub-systems  Removed obsolete hardware  Removed IRACE DCS – superseded by the NGCIR DCS  Removed FIERA DCS – superseded by the NGCOPT DCS  VME TCCD (still used) – will soon be superseded by the new GigE TCCD  Introduced support for new PLC devices using fieldbus software  Cleaned up standard devices  In the past the template instrument included all available devices. It was very big and complicated for new users  It now provides a subset of the standard devices for VME and fieldbus platforms  Changes introduced from Paranal to improve compatibility with their daily operations Introduction Main Changes To Template Instrument

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 5  Detector Control Systems (DCS)  Infra-red DCS (NGCIR): ngcir1  Optical CCD DCS (NGCOPT): ngcopt  Technical CCD DCS (TCCD): tccd  Multiple Instrument Control Software (ICS) Systems  XXXX ICS LCU1 (VME): lxxics1 LCU2 (VME): lxxics2  XXXX2 ICS DCE1 (Fieldbus): wxxics1 DCE2 (Fieldbus): wxxics2  XXXX3 ICS LCU3 (VME): lxxics3 DCE3 (Fieldbus): wxxics3  Telescope Control System (TCS): wxxtcs New Architecture Template Instrument Sub-systems

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 6 New Architecture Multiple ICS Overview Ic0fb Env.

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 7 ICS ICS 1 ICS 2 wxxics2 ID =4 wxxics1 ID = 3 lxxics2 ID = 2 lxxics1 ID = 1 lxxics3 ID =5 Single ICSMultiple ICS New Architecture Mapping LCU/IC0FB Environments wxxics3 ID = 6 ICS 3 wxxics2 ID = 2 wxxics1 ID = 1 lxxics2 ID = 2 lxxics1 ID = 1 lxxics3 ID = 1 wxxics3 ID = 2 The ic0fb environments - i.e - those surrounded by, are treated as “LCU” For each ICS the LCU/DCE numbering always starts from “1”

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 8 DeviceLCU/DCEEnvironmentDevice NameDevice TypeDevice Interface Calibration LampLCU 1lxxics1lampDigitalCanbus digital IO ShutterLCU 1lxxics1tshDigitalCanbus digital IO Filter WheelLCU 2lxxics2filtMotorMaccon GratingLCU 2lxxics2gratMotorMaccon Digital SensorsLCU 3lxxics3dis1DigitalCanbus digital IO Cabinet cooling sensorLCU 3lxxics3asen1AnalogCanbus analog IO Lakeshore 218LCU 3lxxics3lakeLakeshoreSerial IO JumoLCU 3lxxics3jumoIMAGO500Serial IO Calibration LampDCE 1wxxics1lamp2DigitalFieldbus ShutterDCE 1wxxics1shut2DigitalFieldbus Filter WheelDCE 1wxxics1filt2MotorFieldbus SensorDCE 2wxxics2sen6SensorFieldbus SensorDCE 2wxxics2sen5SensorFieldbus New Architecture Standard Devices

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 9 New Architecture Multiple ICS Configuration The starting point is the file xxmcfgCONFIG.cfg and each configuration set defines an ICS. CONFIG.SET1.NAME "XXXX"; CONFIG.SET1.CATEGORY "INS"; CONFIG.SET1.DICT "ICB_CFG … XXXX_CFG XXXX_ICS"; For each ICS there is : CONFIG.SET2.NAME "XXXX2"; CONFIG.SET2.CATEGORY "INS2"; CONFIG.SET2.DICT "ICB_CFG … XXXX_CFG XXXX2_ICS"  A dictionary - e.g.- XXXX_ICS, XXXX2_ICS, XXX3_ICS, …  An ICS configuration file -e.g.- xxmcfgINS_ICS1, xxmcfgINS_ICS2, xxmcfgINS_ICS3.cfg CONFIG.SET3.NAME "XXXX3"; CONFIG.SET3.CATEGORY "INS3"; CONFIG.SET3.DICT "ICB_CFG … XXXX_CFG XXXX3_ICS"

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 10 New Architecture Multiple ICS Configuration The starting point is the file xxmcfgCONFIG.cfg and each configuration set defines an ICS. For each ICS there is :  A dictionary - e.g.- XXXX_ICS, XXXX2_ICS, XXX3_ICS, …  An ICS configuration file -e.g.- xxmcfgINS_ICS1, xxmcfgINS_ICS2, xxmcfgINS_ICS3.cfg The multiple ICS architecture provides a further level of modularity for the instrument. Each ICS can be controlled independently. Increase scalability of the system and system loads can be distributed among all ICSs CONFIG.SET1.NAME "XXXX"; CONFIG.SET1.CATEGORY "INS"; CONFIG.SET1.DICT "ICB_CFG … XXXX_CFG XXXX_ICS"; CONFIG.SET2.NAME "XXXX2"; CONFIG.SET2.CATEGORY "INS2"; CONFIG.SET2.DICT "ICB_CFG … XXXX_CFG XXXX2_ICS" CONFIG.SET3.NAME "XXXX3"; CONFIG.SET3.CATEGORY "INS3"; CONFIG.SET3.DICT "ICB_CFG … XXXX_CFG XXXX3_ICS"

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 11 New Architecture Multiple ICS Configuration(2) INS.CON.ID "XXXX"; # Instrument identifier INS.CON.PREFIX "xx"; # Name prefix for modules and servers INS.CON.SUFFIX "" ; # Name suffix for modules and servers INS.CON.CATEGORY "INS"; Examples are : xxiControl, xxi2Control, xxi2panControl, xxi3SimControl, etc … INS2.CON.ID "XXXX2"; # Instrument identifier INS2.CON.PREFIX "xx"; # Name prefix for modules and servers INS2.CON.SUFFIX "2"; # Name suffix for servers INS2.CON.CATEGORY "INS2"; INS3.CON.ID "XXXX3"; # Instrument identifier INS3.CON.PREFIX "xx"; # Name prefix for modules and servers INS3.CON.SUFFIX “3"; # Name suffix for servers INS3.CON.CATEGORY "INS3"; Inside the xxmcfgINS_ICS configuration files INSi.CON.SUFFIX and INSi.CON.PREFIX are used to name the processes and panels of the specific ICS.

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 12 New Architecture Multiple ICS Configuration(3) OCS.INS1.NAME "ICS"; # name, used by INS OCS.INS1.DICT1 "XXXX_ICS"; # dictionary OCS.INS1.PROCNAME "xxiControl"; # process name OCS.INS1.DBROOT " XXXX:ICS"; # DB root (default) OCS.INS1.KEYWFILT "INS.*.*.*.*.*.*"; # keyword filter OCS.INS.NUM 3; # Number of INS's OCS.INS2.NAME “XXXX2"; # name, used by INS OCS.INS2.DICT1 "XXXX2_ICS"; # dictionary OCS.INS2.PROCNAME "xxi2Control"; # process name OCS.INS2.DBROOT " XXXX2:ICS"; # DB root (default) OCS.INS2.KEYWFILT "INS2.*.*.*.*.*.*"; # keyword filter OCS.INS3.NAME “XXXX3"; # name, used by INS OCS.INS3.DICT1 "XXXX3_ICS"; # dictionary OCS.INS3.PROCNAME "xxi3Control"; # process name OCS.INS3.DBROOT " XXXX3:ICS"; # DB root (default) OCS.INS3.KEYWFILT "INS3.*.*.*.*.*.*"; # keyword filter At OS level we need to specify :  the total number of ICSs  The name of each ICS

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 13 New Architecture Multiple ICS - Database Default ICS (LCU) Second ICS (ic0fb) Third ICS (LCU) Not all the “LCU” database points have the same structure … … but still the ICS common SW works because it is based on alias !!!

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 14 New Architecture Multiple ICS – xxi Control int main(int argc, char *argv[]) { xxiCtrlMAIN_HANDLER mainHandler("XXXX"); /* *# Startup * Register to CCS, set defaults, parse runstring, create SERVER object */ mainHandler.Init(argc, argv, rcsId); /* *# Enter the main loop */ evhHandler->MainLoop(); /* *# Terminate * Deregister from CCS */ mainHandler.Exit(EXIT_SUCCESS); } Each ICS has its own xxi Control process and the ICS name is required to let the process read the related ICS configuration parameters int main(int argc, char *argv[]) { xxiCtrlMAIN_HANDLER mainHandler("XXXX2"); /* *# Startup * Register to CCS, set defaults, parse runstring, create SERVER object */ mainHandler.Init(argc, argv, rcsId); /* *# Enter the main loop */ evhHandler->MainLoop(); /* *# Terminate * Deregister from CCS */ mainHandler.Exit(EXIT_SUCCESS); } int main(int argc, char *argv[]) { xxiCtrlMAIN_HANDLER mainHandler("XXXX3"); /* *# Startup * Register to CCS, set defaults, parse runstring, create SERVER object */ mainHandler.Init(argc, argv, rcsId); /* *# Enter the main loop */ evhHandler->MainLoop(); /* *# Terminate * Deregister from CCS */ mainHandler.Exit(EXIT_SUCCESS); }

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 15 New Architecture Multiple ICS – xxipan Control As for the xxiControl process also here each ICS has its own icbpan panel. To start the panel one needs to know the name of the ICS > xxinsStart –panel ICS > xxinsStart –panel XXXX2 proc xxipanControlInit {} { global cv menuBar EDITING xxipan : if {[ catch { ctooCONFIG xxinsCfg XXXX } res ]} { tk_dialog.oslxDialog "ICS Dialog" $res info 0 OK return "" } proc xxi2panControlInit {} { global cv menuBar EDITING xxipan : if {[ catch { ctooCONFIG xxinsCfg XXXX2 } res ]} { tk_dialog.oslxDialog "ICS Dialog" $res info 0 OK return "" } proc xxi3panControlInit {} { global cv menuBar EDITING xxipan : if {[ catch { ctooCONFIG xxinsCfg XXXX3 } res ]} { tk_dialog.oslxDialog "ICS Dialog" $res info 0 OK return "" } > xxinsStart –panel XXXX3

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 16 New Architecture Multiple ICS – xxopanEngineering The user still needs to know too many internal details to configure the widgets … it would be better to provide building blocks hiding these details from the user (4LGSF already provides a first version) XXXX2:ICS:PROCESSES:WS:icsControl.state XXXX3:ICS:PROCESSES:WS:icsControl.opMode exec xxinsStart –proc XXXX2 &

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 17 New Architecture Multiple ICS – xxinsStartup Each ICS can be controlled independently. And a proper combination of simulation flags and/or availability flag makes it easier the development of a complex instrument among teams.

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 18  INS Fieldbus drivers provide support for TwinCAT (Beckoff) and Simatic S7 (Siemens) PLC devices  Support for official Siemens Softnet and the open source nodave driver is available  Using Beckoff TwinCAT PLC is the standard for VLT instruments  TwinCAT standard devices are available for sensor, generic IO, lamp, shutter and discrete motion control devices.  New TwinCAT standard devices on the way include cabinet cooling controller, lakeshore 218/336/340, de-rotator, atmospheric dispersion correction and tracking devices.  All devices can be run in simulation on the workstation without actual PLC device hardware Fieldbus Support Overview

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 19  TwinCAT standard devices have pre-configured field bus map files available in $VLTROOT/config  Siemens Simatic S7 requires fieldbus map files to be generated using the ic0fbs7MapMaker utility  Parses the data block file (pdf) created by the Siemens Manager application  Comments are used to filter attributes that are applicable to the device driver interface Input attributes comments begin with: $in:.... Output attributes comments begin with: $out:.... Attributes whose comments that do not begin with $ are ignored Fieldbus Support Fieldbus Device Map files (1)

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 20  Example of Siemens Simatic S7 data block file Fieldbus Support Fieldbus Device Map files (2)

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 21  Convert the pdf document into a text file $ pdftotext -layout DB310.pdf  Pass the text file through ic0fbs7MapMaker $ ic0fbs7MapMaker –d sensor –n ASEN1 DB310.txt  Creates two output files  DB310.cfg - INS configuration file for device  DB310.fbmap - field bus map file read by the device driver Fieldbus Support Fieldbus Device Map files (3) $ ic0fbs7MapMaker -h Usage: ic0fbs7MapMaker [-d ] [-f ] [-h] [-k ] [-n ] [-p ] [-t ] [-v] Where: -b Memory data block name (optional). Read from file if available. -d Device type can be 'iodev', 'lamp', 'motor', 'shutter' or -f PLC parameter map file format can be 'csv' or 'text'. Default behavior is to examine the filename and determine the file format from the filename suffix. -h Help text description describing the command line options -k Set keyword values (e.g. "PERIOD:30000,SWSIM:F") -n Device name (e.g. 'SHUT2') -p Device prefix (e.g. 'INS2.SENSOR3') -t Target communication device can be 'echo' or 's7' (default) -v Verbose output

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 22 Example showing the main INS keywords for configuring for a TwinCAT LAMP device interface ( XXXX/CONFIG/xxmcfg/config/xxmcfgINS_ICS2.cfg ) Fieldbus Support INS Device Configuration Example INS2.LAMP2.DEVNAME "lamp2"; # Name of the device INS2.LAMP2.DEVDESC "Lamp 2"; # Description of the device INS2.LAMP2.DEVTYPE "ic0fbiDevDrvLamp"; # Type of the device driver INS2.LAMP2.LCUID 1; # DCE ID INS2.LAMP2.SWSIM T; # Software simulation INS2.LAMP2.ADDRESS "opc.tcp:// :4840,4"; # Address of device INS2.LAMP2.SIMADDR ":ic0fbSim_Lamps"; # Simulation address of device INS2.LAMP2.PERIOD ; # Control Loop period INS2.LAMP2.MAPPREFIX "MAIN.Lamp2."; # Prefix for name mapping INS2.LAMP2.MAPFILE "ic0fbiLamp_TwinCAT.fbmap"; # Mapping File

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 23 Shown below is an example of the CcsEnvTable file contents for starting the relevant fieldbus processes ( XXXX/xxins/ENVIRONMENTS/wxxics2/CcsEnvTable ) Fieldbus Support Configuring the DCE Environment # Start ic0 fieldbus device simulators 0 5 N P Y N N ic0fbiSimLamps --cfg=XXXX2 --log-level=1 0 5 N P Y N N ic0fbiSimShutters --cfg=XXXX2 --log-level=1 0 5 N P Y N N ic0fbiSimDiscMots --cfg=XXXX2 --log-level=1 0 5 N N Y N N ccsNextPhase –t 5 # Start ic0 fieldbus device driver 0 6 N P Y N N ic0fbiLamp --device=LAMP2 --cfg=XXXX2 --log-level=1 0 6 N P Y N N ic0fbiShutter --device=SHUT2 --cfg=XXXX2 --log-level=1 0 6 N P Y N N ic0fbiDiscrMotor --device=FILT2 --cfg=XXXX2 --log-level=1 0 6 N N Y N N ccsNextPhase –t 5 # Start ic0 fieldbus controller 0 7 N P N N N ic0fbControl --dce-id=1 --cfg=XXXX2 --log-level=1

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 24 Database node for a fieldbus LAMP device ( XXXX/ICS/xxi/dbl/xxi2Env1.db ) Scan links for a fieldbus LAMP device ( XXXX/ICS/xxi/config/wxxics1.scan ) Fieldbus Support Adding Database Node and Scan Links //************************************************************************ // Device LAMP2 //************************************************************************ #ifdef icbIC0FB_ENV POINT ic0fbiLamp xxiINS_ROOT:IC0FB:DEVICES:LAMP2 #else POINT icbFB_LAMP icsLCU_DEV_ROOT:LAMP2 #endif BEGIN ALIAS LAMP2 ATTRIBUTE bytes20 device "lamp2" ATTRIBUTE bytes16 prefix "INS2.LAMP2" ATTRIBUTE int32 lcuId 1 END # Lamp 2 LAMP2.state LAMP2.state SRBX 2 LAMP2.simulation LAMP2.simulation SRBX 2 LAMP2.substate LAMP2.substate SRBX 2 LAMP2.error LAMP2.error SRBX 2 LAMP2.status0 LAMP2:DATA.status0 SRBX 2 LAMP2.intPower LAMP2:DATA.intPower SRBX 2

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 25  New PECS files have been added into xxins module and are automatically installed in their final location via pkginBuild  xxins-misc-all.env  xxins-misc-all.wmrc  xxins-misc-all.xrdb  xxins-misc-uws.env  New XXXX/OS/xxocal module  See “Calibration OB Tool User Manual”  Requires vlt2014-vltops.rpm to be installed  Useful for validating instrument modes Paranal Additions General Changes

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 26  OSF provides an additional utility for the start-up and shutdown of the whole instrument.  Older xxinsStart scripts will still be used at OS/ICS panel levels.  Consortium should from now on also deliver OSF scripts Examples to start and stop the instrument : $ osfStarter –script xxinsStart.osf Will open several panels (requires 6 workspaces) Executes a test OB in BOB to very instrument is operational. $ osfStarter –script xxinsStop.osf $ osfStarter –script xxinsEndOfNight.osf Leaves the instrument in safe state, produces the daytime calibration OB, executes this OB and then finally leave the instrument in DAY mode  OSF scripts are automatically created from the INS configuration files by the utility stooOsfCreate, as shown in the example below.  $ stooOsfCreate XXXX Paranal Additions OSF Scripts

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 27 Paranal Additions OSF Screenshots

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 28  Start-up  Starts the instrument and leaves it in STANDBY.  Day Mode  Stable set-up in which the instrument shall be left for long periods of time (e.g. day time)  TCS access will be disabled  Should facilitate access for instrumentation personnel  Global state of instrument should be STANDBY  Night Mode  Instrument ready for night operations  TCS access should be disabled (avoid conflicts with multiple instruments)  Global state of instrument is ONLINE Paranal Additions Instrument Operation Mode We have introduced in the SW the concept of Instument Operation Mode. Each mode defines a specific “usage of the instrument” at a given point in time.

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 29  Calibration  Instrument ready for day time calibrations  Instrument global state is ONLINE  Instrument should be light tight (as much as it can be)  Shutdown  Stops the software and leaves the instrument OFF Paranal Additions Instrument Operational Mode The script xxinsOpMode allows the user to change operation mode. $ xxinsMode Usage: /diska/introot/XXXX/bin/xxinsOpMode Modes: - STARTUP: Start software, leave instrument STANDBY. - NIGHT: TCS DISABLED, Instrument ONLINE. - CALIB: TCS DISABLED, Instrument parked and ONLINE. - DAY: TCS DISABLED, Instrument parked and STANDBY - SHUTDOWN: Stop software, leave instrument OFF.

Instrument Control Systems Seminar, 20 th - 24 th October 2014, Slide 30  Better reusability of dictionary keywords definitions. This could be simplified by providing the ability to ‘include’ dictionary files for standard devices  Dictionary keyword browsing utility  Update template instrument user manual with better examples. (e.g. How to write templates? High level control loops, etc.)  Provide tools to support the instrument configuration  Add newly available field bus devices  We are currently evaluating the Softing echocollect OPC UA server gateway for data integration with Siemens Simatic Future Improvements