Pogo
|
|
|
|---|---|
|
Hi All I am new to Tango and recently exploring POGO. I have a list of queries regarding POGO: 1) What is the class property and device property? And what are the applications? 2) What is the difference between read_write and read_with_write ? 3) How dynamic attribute differ from normal attribute? 4) What is data-type "DevEncoded"? Where it can be used? 5) While declaring commands/attributes, there is a radio button "abstract", what is the use of that? 6) what exactly the use of events while declaring attributes? What is the difference between default and pushed event? Please provide necessary documentation if possible. 7) In property of attribute, what exactly delta_t and delta_value property mean? And where it is used? 8) What does polling of attribute mean ? Where can I get the detailed documentation of POGO other than tango-manual 8.1 so I can read and try to solve my queries ? Any help is much appreciated. Thanks and Regards Kalyani Thigale |
|
|
|
|---|---|
|
|
Here is a link for Pogo documentation http://www.esrf.eu/computing/cs/tango/tango_doc/tools_doc/pogo_doc/ But I think all your questions are more Tango than POGO related, and a lot of answers are indead in the tango-manual 8.1. http://ftp.esrf.eu/pub/cs/tango/tango_81.pdf Example for delta_t and delta_val : APPENDIX A. REFERENCE PART p333 A.2.2.2.3 The delta_t and delta_val parameters These two parameters have a meaning only for attribute of the Tango::READ_WRITE and Tango::READ_WITH_WRITE read/write type and for numerical data type. They specify if and how the RDS alarm is used. When the attribute is read, if the difference between its read value and the last written value is something more than or equal to the delta_val parameter and if at least delta_val milli seconds occurs since the last write operation, the attribute quality factor will be set to Tango::ATTR_ALARM and if the device state is Tango::ON, it is switched to Tango::ALARM. Even if these parameters are numbers, they are returned as strings by the device get_attribute_config() call. Good reading 
|
|
|
|
|---|---|
|
Dear Kalyani All the questions you ask are about the concepts of TANGO. POGO will just implement the concepts. I invite you to read the introductive PPT http://www.tango-controls.org/media/filer_public/ca/8f/ca8f811a-4366-4d1e-82b9-15b7a6562930/tango_introduction.ppt At the end of the document (from slide 54, you will find a description of the concept of properties). Some interesting concepts are also described here: http://www.tango-controls.org/media/filer_public/7c/48/7c4836f7-0aed-45e3-a78f-b4fd35af1580/tango_training.ppt Concerning the read_with_write type of attribute, this type had been introduced at the begining of TANGO but never really used. I do not recommend you to use it because it's usage is not very clear. Prefer the read_write type. An attribute of type red_write contains 2 different values. the setpoint and the read point. both values may differ depending of the real physical value of the hardware. e.g. when you set 2.00 volt to a powersupply, the real value may be 1.95 volt. then, you can set an alarm when the read_value becomes too different than the set_value. It can help you to detect hardware drift. For this purpose you can use the delta_value and delta_t attribute property. the delta_value is the maximum difference between the set_value and the read_value that you tolerate before switching to alarm state. The delta_t gives the dead time after each set of the attribute before checking the delta_value. It gives the time to the hardware to establish the new value and avoid an unjustified alarm state during transient period. Concerning polling of attributes: It means that the server itself will execute the read of the attributes and store the values in a cache (also named polling_buffer). When a client wants to read an attribute which is polled, then by default the value is taken from the cache instead of being read in the hardware. There is several advantages to poll the attributes 1) the read of an attribute from the cache is very fast because the deadtime due to hardware latency is spent by a thread which does the read in background. 2)The polling buffer keeps an history of the last read values and can calculate the conditions to send events to the clients. for instance, you can configure an event when the value change by a certain amount (change_event). this is done on the values present in the polling thread. I hope it helps Jean-Michel Kalyani
Cheers
Jean-Michel |