Development of generic slow control producers for the
Contents
1. amp Every encapsulated measured value of a LazyDeviceReader has been mapped to it s own readout frequency If the time difference between the last readout and the current time is greater than this given frequency the data list gets enriched The data list is a list of the physical meaning of a value stored as a string tag first and the value itself second All new data are stored in an eudaq RawDataEvent object line 17 and get sent via the SendEvent method It is possible that no device provides new data In this case it is not reasonable to generate an empty eudaq RawDataEvent object lines 11 13 i while _done if _started continue vector lt pair lt string string gt gt data for int i 0 i lt _devices size i devices i lazyEnrichData data E dera size 0 ae continue eudaq RawDataEvent event EVENT_TYPE run ev for pair lt string string gt p data event SetTag p first p second SendEvent event Listing 3 readout loop of SlowControlProducer cxx 3 3 SerialCommunicator To make it possible to provide different kinds of connections for slow control producers like serial ports network infrared etc a pure virtual interface for devices is introduced 10 i virtual Device void virtual void connect void throw runtime _error 0 virtual bool connected void const 0 virtual void disco2. and just differs in the name of the commands 2 1 Generic Slow Control Producer The idea for the implementation of generic slow control producers is to define all nec essary commands as well as queries and their response pattern in a separate device configuration file Each command can be identified and referenced by a given key name lin fact a serial ports can be just emulated and with that encapsulate the real communication e g via USB Supplementary this device configuration provides other hardware specific information for example the requested baud rate of the connection Another producer configuration file refers to possible multiple device configurations and lists the keys and values for initial commands as well as queries for the readout loop The achievement of this design is that the producer logic is completely extracted to configuration files so that there is no need for multiple slow control producer imple mentation as EUDAQ C classes To define new producers or even devices it is enough to plug in new configuration files with no need of recompiling the framework or edit ing internal code compare figure 2 Furthermore this configuration can be extremely minimal by just focusing on the real producer logic producer config device config initialize device gt set connection details p define readout loop gt define commands refers to commands Producer Figure 2 Constructio
3. changes the status of this machine from configured to running For that some internal values get changed like started true and a eudaq RawDataEvent BORE event with the current run number is sent for more in formation about this event please consider 1 This event is sent via void SendEvent const Event 4 a method provided by the producer base class which encapsulates the data sending to the DataCollector Changing the started value is important for the readout loop see section 3 2 5 Further more the status of the producer changes to Running 3 2 3 Method OnStopRun This method is called at the end of the run It sets _started false and sends the eudaq RawDataEvent EORE event I 3 2 4 Method OnTerminate This method is called at the very end and just changes the internal variable _done true ending condition for the readout loop see section 3 2 5 3 2 5 Readout loop After a producer is configured properly and initial commands have been executed it can start to readout the hardware and to send the data to the DataCollector The readout is performed in a readout loop which is called at the very beginning even before configuration has started and is started with setting started true by OnStartRun compare listing 3 lines 2 4 A time depending readout logic is realized by LazyDeviceReader which provides a lazyEnrichData method void lazyEnrichData vector lt pair lt string string gt gt
4. defined in its specific device configuration file Furthermore each query is associated with a tag label which represent the physical meaning of this value e g core_voltage in line 6 and a readout frequency in milliseconds Each symbol of a command not a query in the device configuration file will be replaced by the value given in the producer configuration file compare line 4 and line 5 all leading and ending spaces tabs etc of values and keys gets cut off for all properties 3 Implementation In the following code examples the namespace std was removed to not produce avoidable line breaks In case of insecurity please compare the source code 3 1 Overview Figure 3 summarize the work flow of a Slow Control Producer The managed devices are used device configuration gt SlowControlProuder cxx producer configuration create amp initialize __ devices config files with CommandFactory generate commands from create LazyDeviceReaders LDR map commands to a device Device Device Device Commands Commands Commands data readout loop ____ LER Figure 3 Work flow of a Slow Control Producer as SerialCommunicators compare section 3 3 to enable the communication via serial ports The collected data are sent to the DataCollector At every stage possible errors due to malformed configuration files or connection problems are thrown back to the produce
5. 00766b80aS046E pa 15
6. Development of generic slow control producers for the EUDAQ framework Nis Meinert Deutsches Elektronen Synchrotron Germany September 11 2014 Abstract This report documents the implementation and shows the usage of a producer for the EUDAQ framework which allows to handle slow control devices The configuration and readout of this devices can be managed in a generic way by creating minimalistic properties files and without any need of changing EUDAQ s C source code Contents 3 1 1 The architecture of the EUDAQ framework 3 4 2 1 Generic Slow Control Producer o 4 2 2 The device configuration in detail 6 2 3 The producer configuration in detail 7 8 a Beh ee pos e Po e ee Oe ee ee 8 3 2 SlowControlProducer 264 bp ees eek 2 Ped w Beedle aes 8 3 2 1 Method UnConliglitel 2 124 eee ee ee eee ER 9 Oe ay Bin E ee ee oe AA 9 oe oe Be ee oe ee eo es Bee a 9 3 2 4 Method On Terminatel 9 3 2 5 Readout IR A ew 10 3 3 SerialCommunicator 24 x a aye a Bee oe one gs ww eo oe Ee 10 Sk See AM abe Th ae eat ead et ek Bo eee 11 3 5 Command Roctor Y io ue daa he Gag ed oe a Owe eee 12 3 6 ExceptionFactory Oo saa eee as OES Se OES OP REE ee ee 12 1 Introduction The EUDAQ framework 1 is a generic data acquisition framework DAQ for detector R amp D research and development at test beams with spe
7. alled a query The device configuration listing L defines two queries and two commands and associate the keys getVoltage chi getVoltage_ch2 and setVoltage ch1 setVoltage ch2 for then Each query contains three fields command This is the actual command which will be sent to the device regexp The regular expression of the expected answer This can be an arbitrary regular expression without using capture groups this feature is not yet implemented pattern This defines the concrete structure of the value which gets returned The n th ap pearance of the symbol will be replaced by the n th mapping result of the given regular expression An additional number k can be given to truncate the first k characters of the return statement given no number at all is equivalent to k 0 Let s assume a regular expression maps on 42 and abc 13 37 Using a pattern measured and 4 au makes the return string to be measured 42 and 13 37 au To return the response without any formating at all the pattern has to be set to 2 3 The producer configuration in detail The producer configuration listing 2 can load different kind of devices Each device enu merate alphanumerical has its own device configuration file line 2 and is bound to a specific port line 3 Initial commands are listed as commands and queries for the readout loop as querys Each query as well as commands refers directly to a command which is
8. cial focus on collecting data from test beam telescopes EUDAQ 1 had a trigger based layout One hardware trigger needed to be spread to all devices and by that limited the data rate by the slowest device Due to that all data were taken at the same frequency leaving no option to provide a readout of e g temperature sensors damp sensors power supplies or others so called Slow Control devices While for example tracking positions are taken at frequencies up to 1 MHz a readout of slow control devices at a frequency of 1 Hz is reasonable A readout with higher frequencies is neither necessary nor possible for such devices unnecessarily data duplication Due to the fact that EUDAQ 1 did not support such kind of slow control devices a separate and often manual readout without EUDAQ was necessary With EUDAQ 2 the old data format was replaced by a format which allows multiple triggers beeing associated with one single readout and by that allowing the implemen tation of Slow Control Producers In the EUDAQ framework the part which takes care of the hardware interaction is called a producer A producer encapsulates the communication with the hardware initializes it and manages the data readout This report shows the implementation and usage of a generic slow control producer which allows customers to easily configure initializing and data acquisition of arbitrary slow control devices These configuration can be done in a generic way by creating
9. e 1 Relevant parts of the EUDAQ framework architecture 2 Slow Control Producer Within the old data format in EUDAQ 1 there was only one existing kind of producer These producers were made to readout hardware at the highest possible frequency but still common for all devices and limited by the slowest device A trigger given by four scintillator detectors in the telescope correspond to one readout of a producer so that the slowest device limited this rate This behavior is reasonable for e g tracking data but not necessary for data which do not directly correspond to a specific hit in the detector due to it very slow change Such kind of slow changing data could be values like temperature or air humidity Because it was neither reasonable nor for some devices even possible to readout such slow changing data at high frequencies by producers it was done without the EUDAQ framework sometimes even manual The new data format of EUDAQ 2 fixes this grievance and finally allows the data taking of this even when they are not corre sponding to a particular hit in the telescope important data for the measurement and controlling The implementation of this slow changing data taking producer is called Slow Control Producer So the task of a slow control producers is roughly the same as for a normal producer initialize the device in the beginning and readout some quantity at a given slow fre quency The communication is realized via serial ports
10. js ysuo0d Aton oyeiaues Aron 914e 4S ISDUVL eyo ysu00 919898 99 193U1 Tepeeyedtaeghzeyq SULISIT 10119 901IJUNI MOIY Y lt lt 3urigs 3ULIJS gt I1Ed gt I1O0YD9A LIB QUIIUH AZe prioa SPURUITIONS lt PpUBUMUO J9N1IS gt I10I99A lt 9IA9M gt 14d p I eys 1SPeIYIMAD ZRT 29 PUeuIIoo 390 198 lt ootaog gt 14d poirys lopeoyootAaqAzey 9WIIJINOPeA1 SUOT 389 SULI S ionb Lian yoy pueumiog 39 198 13 Acknowledgements I would like to express my sincere gratitude to my adviser Dipl Phys Richard Peschke for the continuous support and for his patience motivation enthusiasm and deep knowledge about the EUDAQ framework and C 11 His guidance helped me all time of project work I am sure it would have not been possible without his help I wish to thank my parents for their undivided support and interest who inspired me and encouraged me to go my own way and enable me my study At last but not the least I want to thank all summer students especially my room mate Harald Viemann for having such a great time You provided the necessary state of distraction to love my work without going crazy Thanking you 14 References 1 EUDAQ Development Team EUDAQ Software User Manual URL k tp eudaq github io manual EUDAQUserManual p f 2 Thurlby Thandar Instruments TTi QL355TP POWER SUPPLY Manual URL ht tp docs europe electroconponents con webdocs 0a59 09
11. listing 2 The magic of a lazy read is performed as already described above in the lazyEnrichData method The most relevant part of this code is shown in listing 6 for int i 0 i lt _commands size i chrono milliseconds tl _time i chrono milliseconds t2 currentTime chrono milliseconds dt commands i readouttime it ta tl gt ai 4 data push_back readoutAndSetTime i op Listing 6 Extract from the lazyEnrichData method 11 The pair lt string string gt readoutAndSetTime const unsigned ID method executes the specific command returns the formated answer and sets the readout time of the command to the current time via _time ID currentTime If it is necessary to have access to the encapsulated Device object this can be performed by the shared_ptr lt Device gt device void method This can be usefully for example if there is need to call the disconnect method of a device The complete interface of LazyDeviceReader is shown in listing 7 3 5 CommandFactory The interface of the CommandFactory is shown in listing 8 The CommandFactory allows the production of Querys and RichQuerys A Query only encapsulate one command string and is the base class of RichQuery Besides this command string a RichQuery also stores the regular expression and the pattern of a query to generate the formated answer compare section 2 1 To generate a command it is enough to call generateQuer
12. minimalistic properties files without the need of changing EUDAQ s C source code 1 1 The architecture of the EUDAQ framework The EUDAQ framework is build in a very modular way All processes and especially the hardware specific parts are separated which allows the framework to work with many different kinds of hardware by just adding new or changing a few existing modules In figure 1 the most relevant parts of this project are shown Each one of this modules can be compiled independently and run separately on different devices The communication is realized via TCP IP The main focus for this project lies on the producer and its interaction with the hardware A producer handles the receiving of commands from the RunControl the sending of data to the DataCollector and it encapsulates the Communication with the hardware Each of this hardware devices is controlled by one producer and each producer can manage multiple devices Apart from configuration a producer collects data from his assigned hardware and sends them to a DataCollector Similar to a producer a DataCollector can handle multiple producers bundle their incoming data streams and writes them to storage A producer as well as all other EUDAQ parts gets configured by the RunControl The RunControl sends commands to all connected processes and receives their status gt DataCollector 3 configure RunControl more oe 3 3 R Y p 5 bp a g al o Figur
13. n of a generic producer by configuration files The fact that one producer configuration can refer to multiple device configuration files is not shown An example of a device and producer configuration for the TTi QL355TP POWER SuPPLY 2 is shown in listing 1 and listing 2 The producer configuration is an excerpt of a general configuration file which is sent by the RunControl to all processes CONNECTION 2 baudRate 9600 characterSize 8 sendTwoStopBits false enableParity false get Voltage_chl command V1 getVoltage_chl regexp V1 0 9 x 0 9 x o get Voltage_chl pattern 3 2 get Voltage_ch2 command V2 getVoltage_ ch2 regexp V2 0 9 x 1 0 9 x getVoltage_ch2 pattern 3 setVoltage_chl V1 set Voltage _ch2 V2 Listing 1 example for a device configuration ttiCPX400 config Producer SlowControlExample 2 a config ttiCPX400 config a_port dev ttyACMO a_command_1 setVoltage_chl 0 1 5 a_command 2 setVoltage_ch2 0 2 la query_1 getVoltage_chl core_voltage 2000 a_query_2 getVoltage_ch2 important_voltage 1337 b_config Listing 2 example for a producer configuration 2 2 The device configuration in detail The device configuration consists of three parts At first some general connection parameters have to been set The type of this parameters is given by the connection the values are given b
14. nnect void throw runtime_error 0 virtual void send const Query amp throw runtime_error 0 virtual string plainRead void throw runtime_error 0 z virtual string query const RichQuery amp throw runtime _error 0 Listing 4 Device interface This interface defines all necessary methods to connect and disconnect from one arbitrary device and send commands via send or perform queries via query Apart from this a plain read to the encapsulated port can be performed The objects Query and RichQuery are produced in a CommandFactory see section 3 5 SerialCommunicator implements this interface listing and by that encapsulates the communication with serial ports for some devices USB connections are emulated as serial ports The implementation itself is some kind of technical and was implemented to work for Linux as well as for Windows In case of errors or exceptions std runtime_errors with messages produced by ExceptionFactory see section gets thrown For further information please consider the source code 3 4 LazyDeviceReader A LazyDeviceReader owns an implementation of a Device and performs a time dependent execution of struct Commands i struct Command 4 RichQuery query string tag long readouttime Listing 5 Extract from LazyDeviceReader implementation These three variables realize the three variables which are passed in the producer configuration file compare
15. r The messages of the errors are generated by the ExceptionFactory compare section 3 6 3 2 SlowControlProducer A producer receives its commands from the RunControl and sends back his current status The data getting collected by a producer from his devices are sent to the DataCollector Both communications are realized via TCP IP and are encapsulated completely by a provided base class for producers To use the encapsulating of this base class four methods have to be implemented 3 2 1 Method OnConfigure The OnConfigure method is called to provide the producer with a global configuration file which is sent to every process of the EUDAQ framework listing 2 was extracted from this file please consider the manual for more detailed information about eudaq Configuration For every slow control device which is listed in the configuration file a SerialCommunicator see section 3 3 is created and plugged into a LazyDeviceReader see section 3 4 In case that a desired property couldn t be found in the configuration file maybe due to malformed syntax or other connection problems occurs a verbose error message is printed to std cerr and the status of the producer changes from eudaq Status LVL_OK to eudaq Status LVL_ERROR 3 2 2 Method OnStartRun The OnStartRun method is called on the start of each run The parameter param is the run number of the started run A producer is a state machine and this method
16. y the device Secondary initial commands have to been executed to set the device in a proper initial state Afterwards third queries for a readout loop which provide the measured values for this device have to been defined Necessary types of connection parameters for devices connected via emulated serial ports are the same and do not differ between arbitrary devices baud rate Symbol rate or modulation rate in symbols per second character size Number of data bits in each character stop bits Stop bits showing the end of a signal Devices can send one one and one half or two stop bits most devices uses one stop bit parity Additional data bit is sent with each character bit to detect corrupted transmissions Commands are specific for every device Nevertheless they have very similar patterns and therefor they can be grouped into two different types Commands and Queries A plain command does not have a response from the device For a power supply this could be com mands like setting the voltage of a specific channel to a certain value For example for the TTi QL355TP POWER SUPPLY this command could be compare with the manual 2 V1 42 0 setting the voltage of channel 1 to 42 V The device won t send a response To get the current voltage of channel 1 of the TTi QL355TP POWER SUPPLY one have to send the command v1 This device will answer quickly V1 42 0000 A command which expects and answer to been sent afterwards is c
17. y with a desired command and optional with values args which will replace all occurrences of the character target Analog to this a query can be generated by calling generateQuery RichQuery stores all relevant information to generate the formated answer via the generateAnswer method 3 6 ExceptionFactory The ExceptionFactory provides a method to generate exception messages in a common for mat 1 2 A call to this method could look like A O leading to the following exception message MyClass cpp 42 Something went terribly wrong 9 8 193UT L10492 JPUBULIO Q SUTYSTT UOTINSIV pl eaAUL moiy THOYVL 293189 IBI ysuod usoqjed2 Surzgs ysuod dx 3 1 SulIys ysuod I MSUL SUII S JSUOD IoMSUVoejeioues JULIJS D1989S IADUVL 393189 IeyO ysuod sBiez lt 3UTIJS gt I0J99A SUOI usoqjyeda Surigs ysuod dx 3 1 SUIS ysuod PURUILIO SULIJS ysu0d ATONHojxe19U0s ATONYMYOIY 913898 IT9YVL 3981 18q9 ysuod ZIR SUIS ysuod uloyyeda Surigs ysuod dxa3olzy Suldys ysuod puewuooy SULIJS ysUOD AJONHoj eI9U9s ATONHYOIY 913e3s uioyyeday Surays ysuoo dx 3 1 Zur s ysuod pueumuooy SUIIYS JsuU0d ATONPMaeeIoues ATONYYOIY I19e4s IADUVL 393189 18y9 ysuod S318 lt BUILIAS gt I10J99A JSUOD PURUILION SULIJS SU09 AIONMo4eI9U0s AON 913898 IADYUVL 398184 18y9 ysuod 312 SULIJS ysuod puewwox 3urigs 9suo 1en oyelgua3 Aton 919e 48 pueurutony 3UrI
Download Pdf Manuals
Related Search