From: Greg W. <gr...@sl...> - 2012-02-14 10:40:10
|
Perfect. On 14 Feb 2012, at 11:26, <jam...@di...> wrote: > Thanks > >> Hi fellas, ISO 8601 is cool. The most important things are, firstly, that >> it's documented in a well known place. So eg, if the command line tool is >> eget, that has nothing to do with archiver, so users have to know where they >> can go to get documentation on the definitive answer. > > So the archiver query is now (as a name/value pair or whatever) > > string channel > string t0 > string t1 > > And the server does the conversion from ISO8601 to EPICS timestamp (EPICS timestamps are required at some point because that's what the archiver disk API uses) > > Possible examples (specifying the service name with -s assuming there's no directory service): > > # positional parameters > eget -s archiveRPC QUAD01 2012-02-14T11:12:30 2012-02-14T11:12:40 > > # named parameters url style > eget -s archiveRPC?name=QUAD01&t0=2012-02-14T11:12:30&t1=2012-02-14T11:12:40 > > James > >> -----Original Message----- >> From: Matej Sekoranja [mailto:mat...@co...] >> Sent: 14 February 2012 10:15 >> To: Greg White; epi...@li... >> Subject: Re: Archiver Example >> >> Note that JCA/JCA/pvAccessJava and pvAccessCPP already use ISO8601. >> It should look like this (be in this form; standard allows different forms): >> >> blackhole:pvAccessCPP msekoranja$ ./bin/darwin-x86/pvget -d invalid >> 2012-02-14T11:12:36.826 Broadcast address #0: 192.168.1.255:5067 >> 2012-02-14T11:12:37.160 Broadcast address #1: 172.16.103.255:5067 >> 2012-02-14T11:12:37.160 Broadcast address #2: 172.16.240.255:5067 >> 2012-02-14T11:12:37.160 Creating datagram socket to: 0.0.0.0:5067 >> 2012-02-14T11:12:37.161 Creating datagram socket to: 0.0.0.0:0 >> 2012-02-14T11:12:37.161 Starting thread: UDP-receive 0.0.0.0:5067 >> 2012-02-14T11:12:37.161 Starting thread: UDP-receive 0.0.0.0:0 >> >> Matej >> >> >> On Tue, Feb 14, 2012 at 10:49 AM, Greg White <gr...@sl...> wrote: >>> [Adding epics-pvdata for date command example I found really useful] >>> >>> Hi fellas, ISO 8601 is cool. The most important things are, firstly, that >> it's documented in a well known place. So eg, if the command line tool is >> eget, that has nothing to do with archiver, so users have to know where they >> can go to get documentation on the definitive answer. Second, sounds stupid, >> but it should't have spaces in it! Physicists rarely know how to quote stuff. >>> >>> Also as I said, remember you can always use the date command to >>> convert one datetime to another, both the time value (so you can for >>> instance ask for the time to be rendered both absolutely or even >>> relatively (useful for archiver acquisitions of say the last 24 >>> hours", and format conversion). Useful in scripts that wrap archiver >>> specific requests. Eg >>> >>> $ date --date='-1day' +"%Y:%m:%dT:%H:%m" >>> 2012:02:13T:10:02 >>> >>> $ date --date='3 hours ago' +"%Y:%m:%dT:%H:%m" >>> 2012:02:14T:07:02 >>> >>> >>> >>> >>> >>> On 13 Feb 2012, at 23:12, <jam...@di...> >> <jam...@di...> wrote: >>> >>>> I'll do ISO 8601, it's what our fast feedback archiver command line too >> uses. Goes from most significant (years) to least signification (seconds + >> fractional seconds) so that's easy to remember. >>>> >>>> James >>>> >>>> ________________________________________ >>>> From: Shen, Guobao [sh...@bn...] >>>> Sent: 13 February 2012 20:33 >>>> To: Rowland, James (DLSLtd,RAL,DIA) >>>> Cc: gr...@sl... >>>> Subject: Re: Archiver Example >>>> >>>> Not sure which encoding is good, but I was often asked about the format >> that to retrieve data from archiver with current tool. >>>> User are always got confused they should use 02/13, or 2/13. >>>> >>>> Guobao >>>> >>>> >>>> On 2/13/12 2:22 PM, jam...@di... wrote: >>>>> Fine by me, Diamond only has one index file anyway. End time can replace >> count. >>>>> >>>>> What's a good string encoding of UTC date and time for the command line >> tool? >>>>> >>>>> James >>>>> >>>>> ________________________________________ >>>>> From: Greg White [gr...@sl...] >>>>> Sent: 13 February 2012 18:05 >>>>> To: sh...@bn... >>>>> Cc: Rowland, James (DLSLtd,RAL,DIA); Greg White >>>>> Subject: Re: Archiver Example >>>>> >>>>> You guys are going to have to explain the subtlety to me. Why can a >>>>> user not just specify start time and end time in UTC? >>>>> >>>>> is this related to the smarts in SLAC's archiver service where it >>>>> finds the index of your query for you. I know Bob hall at SLAC did >>>>> that, but I don't know the details. He made it so a user just asks for >> name with a start and end time. >>>>> >>>>> Greg >>>>> >>>>> On 13 Feb 2012, at 18:11, Shen, Guobao wrote: >>>>> >>>>>> >>>>>> On 2/13/12 11:48 AM, jam...@di... wrote: >>>>>>> Hi Guobao >>>>>>> >>>>>>> The magic numbers are the EPICS archiver codes for disconnected, >> disabled etc. >>>>>> Thanks. Is that a stand magic number by archiver engine? >>>>>>> I have considered inhomogeneous data and it's not allowed as EPICS >> channels change type very rarely, and it's not supported by NTTable. >>>>>>> Type will be determined by the type of the first sample in the time >> range. >>>>>>> Strings aren't supported yet. >>>>>> I see. That is one channel over time. I confused myself by extending it >> to multiple channels. >>>>>>> String date is there because it's useful to have the data in human- >> readable format, yes it's UTC. This is my interpretation of Greg's >> requirement. >>>>>> If this is for the convenience of human reading, why not put this to the >> client side? >>>>>>> Waveforms are not supported yet. Either the table can have one value >> column per waveform element, called 'sample0', 'sample1', etc. or there will >> be one extra column called 'sample index' and a waveform will produce one row >> per waveform element. I slightly prefer the latter. >>>>>> I believe the waveform can be the last step. But is current NTTable >> suitable for this? Not sure. >>>>>> >>>>>>> For multiple channel queries (you guessed it, not supported) the result >> will either be: >>>>>>> 1) a list of NTTables, one per channel >>>>>>> 2) a single table, with a new column called 'channel index' to identify >> the channel. In that case, all channels will have to be numbers or all >> channels will have to be strings. >>>>>>> >>>>>>> The parameter type isn't name/value pair but there's an action on >>>>>>> me and Greg to come up with something that will work with the >>>>>>> command line tool >>>>>>> >>>>>>> This is the current parameter type: >>>>>>> >>>>>>> structure MYArchiverQuery >>>>>>> string index >>>>>>> /home/jr76/epics4/cpp/exampleCPP/ChannelArchiverService/data/index >>>>>>> string name fred >>>>>>> long t0secPastEpoch 496169402 >>>>>>> int t0nsec 0 >>>>>>> long count 20 >>>>>> If this require users input, how does they input t0secPastEpoch magic >> number correctly? >>>>>> >>>>>> Guobao >>>>>>> James >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Shen, Guobao [mailto:sh...@bn...] >>>>>>>> Sent: 13 February 2012 16:31 >>>>>>>> To: epi...@li... >>>>>>>> Cc: Rowland, James (DLSLtd,RAL,DIA) >>>>>>>> Subject: Re: Archiver Example >>>>>>>> >>>>>>>> Thanks James. >>>>>>>> It is really great for the first step. >>>>>>>> >>>>>>>> Some question: >>>>>>>> What is the NTType you use for the request, NTNameValue? >>>>>>>> >>>>>>>> What is your considering to have the date in your NTTable since >>>>>>>> it can be retrieve form secPastEPoch and nano-sec? >>>>>>>> Actually, the date give me kind of confusion, for example, is it >>>>>>>> a UTC time, or local time? >>>>>>>> >>>>>>>> Do you have any considering about supporting inhomogeneous data, >>>>>>>> for example a mixed data type of double, string, and integer? >>>>>>>> Further more, how about a mixed waveform and scalar with inhomogeneous >> data? >>>>>>>> >>>>>>>> It might be too much to consider, but... >>>>>>>> >>>>>>>> ps: >>>>>>>> just very curious, in your security array, you have some magic # >>>>>>>> like 3094 and 3872. What is that? >>>>>>>> >>>>>>>> Guobao >>>>>>>> >>>>>>>> On 2/13/12 10:24 AM, jam...@di... wrote: >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> I have pushed the archiver example (no decimation). Below are >>>>>>>>> the request >>>>>>>> and result structures. The result is an NTTable. The request API >>>>>>>> may change to support the generic command line tool. Included is >>>>>>>> a small command line tool with fixed parameters. >>>>>>>>> I have also copied a example archiver index and data files into hg. >>>>>>>>> >>>>>>>>> James >>>>>>>>> >>>>>>>>> >>>>>>>>> Request: >>>>>>>>> >>>>>>>>> structure MYArchiverQuery >>>>>>>>> string index >>>>>>>> /home/jr76/epics4/cpp/exampleCPP/ChannelArchiverService/data/inde >>>>>>>> x >>>>>>>>> string name fred >>>>>>>>> long t0secPastEpoch 496169402 >>>>>>>>> int t0nsec 0 >>>>>>>>> long count 20 >>>>>>>>> >>>>>>>>> Result: >>>>>>>>> >>>>>>>>> structure MYArchiverTable >>>>>>>>> string[] labels >>>>>>>>> [value,secPastEpoch,nsec,date,status,severity] >>>>>>>>> double[] value >>>>>>>>> [0.168245,0.255837,0.317312,0.215941,0.495392,0.318756,0,0,0,0.3379,0. >>>>>>>>> 429723,0.518855,0.485716,0.528851,0.207881,0.355957,\ >>>>>>>>> 0.248583,0.0180872,0.226599,0.0924722] >>>>>>>>> long[] secPastEpoch >>>>>>>>> [496169401,496169410,496169420,496169430,496169440,496169450,496 >>>>>>>>> 169450 ,496169450,496169537,496169542,496169544,496169\ >>>>>>>>> >>>>>>>> 550,496169560,496169570,496169580,496169590,496169600,496169610,4 >>>>>>>> 96169620,4961 >>>>>>>> 69630] >>>>>>>>> int[] nsec >>>>>>>>> [996447000,52636000,109690000,100015000,81932000,89935000,699760 >>>>>>>>> 000,69 9760000,905713000,934346000,936794000,934487000,90968400\ >>>>>>>>> 0,900124000,880791000,865753000,859166000,834278000,809687000,79 >>>>>>>>> 4591000] >>>>>>>>> string[] date [Wed Sep 21 17:50:01 2005,Wed Sep 21 17:50:10 >>>>>>>>> 2005,Wed Sep 21 17:50:20 2005,Wed Sep 21 17:50:30 2005,Wed Sep >>>>>>>>> 21 >>>>>>>>> 17:50:40 20\ 05,Wed Sep 21 17:50:50 2005,Wed Sep 21 17:50:50 >>>>>>>>> 2005,Wed Sep 21 17:50:50 2005,Wed Sep 21 17:52:17 2005,Wed Sep >>>>>>>>> 21 17:52:22 2005,Wed Sep 21 17\ >>>>>>>>> :52:24 2005,Wed Sep 21 17:52:30 2005,Wed Sep 21 17:52:40 >>>>>>>>> 2005,Wed Sep >>>>>>>>> 21 17:52:50 2005,Wed Sep 21 17:53:00 2005,Wed Sep 21 17:53:10 >>>>>>>>> 2005,Wed \ Sep >>>>>>>> 21 17:53:20 2005,Wed Sep 21 17:53:30 2005,Wed Sep 21 17:53:40 >>>>>>>> 2005,Wed Sep 21 >>>>>>>> 17:53:50 2005] >>>>>>>>> int[] status [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0] >>>>>>>>> int[] severity >>>>>>>>> [0,0,0,0,0,0,3904,3872,3904,0,0,0,0,0,0,0,0,0,0,0] >>>>>>>>> >>>>>>>> -- >>>>>>>> Guobao Shen >>>>>>>> Bldg. 902-B, 17 Cornell Avenue >>>>>>>> National Synchrotron Light Source II Brookhaven National >>>>>>>> Laboratory Upton, New York 11973 Tel. : +1 (631) 344 7540 >>>>>>>> Fax. : +1 (631) 344 8085 >>>>>>>> http://www.bnl.gov/nsls2 >>>>>> -- >>>>>> Guobao Shen >>>>>> Bldg. 902-B, 17 Cornell Avenue >>>>>> National Synchrotron Light Source II Brookhaven National Laboratory >>>>>> Upton, New York 11973 Tel. : +1 (631) 344 7540 Fax. : +1 (631) >>>>>> 344 8085 >>>>>> http://www.bnl.gov/nsls2 >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------- >>>>>> ----------- Try before you buy = See our experts in action! >>>>>> The most comprehensive online learning library for Microsoft >>>>>> developers is just $99.99! Visual Studio, SharePoint, SQL - plus >>>>>> HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you >> subscribe now! >>>>>> http://p.sf.net/sfu/learndevnow-dev2 >>>>> >>>> >>>> -- >>>> Guobao Shen >>>> Bldg. 902-B, 17 Cornell Avenue >>>> National Synchrotron Light Source II >>>> Brookhaven National Laboratory >>>> Upton, New York 11973 >>>> Tel. : +1 (631) 344 7540 >>>> Fax. : +1 (631) 344 8085 >>>> http://www.bnl.gov/nsls2 >>>> >>>> >>>> -- >>>> This e-mail and any attachments may contain confidential, copyright and or >> privileged material, and are for the use of the intended addressee only. If >> you are not the intended addressee or an authorised recipient of the addressee >> please notify us of receipt by returning the e-mail and do not use, copy, >> retain, distribute or disclose the information in or attached to the e-mail. >>>> Any opinions expressed within this e-mail are those of the individual and >> not necessarily of Diamond Light Source Ltd. >>>> Diamond Light Source Ltd. cannot guarantee that this e-mail or any >> attachments are free from viruses and we cannot accept liability for any >> damage which you may sustain as a result of software viruses which may be >> transmitted in or with the message. >>>> Diamond Light Source Limited (company no. 4375679). Registered in >>>> England and Wales with its registered office at Diamond House, >>>> Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, >>>> United Kingdom >>>> >>>> >>>> >>>> >>> >>> >>> ---------------------------------------------------------------------- >>> -------- Keep Your Developer Skills Current with LearnDevNow! >>> The most comprehensive online learning library for Microsoft >>> developers is just $99.99! Visual Studio, SharePoint, SQL - plus >>> HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you >> subscribe now! >>> http://p.sf.net/sfu/learndevnow-d2d >> >> ------------------------------------------------------------------------------ >> Keep Your Developer Skills Current with LearnDevNow! >> The most comprehensive online learning library for Microsoft developers is >> just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro >> Style Apps, more. Free future releases when you subscribe now! >> http://p.sf.net/sfu/learndevnow-d2d > > -- > This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. > Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. > Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. > Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom > > > > |