Tags:
create new tag
view all tags

20120519 Data Synchronicity

Now with all the additions to either the pv acquire list or the Epics ADDR list, the lwAcq acquisition rate is approximately 1Hz. This was measured by looking at the refresh rate of extlw:progress which updates each time a sample is acquired.

Consequences

  • Data is not synchronous. Some data acquired for one machine pulse, some for another.
  • One third slower scanning rate.

Solutions / Problems

Reduce number of variables recorded

  • There aren't too many
  • Lose necessary information

Record some variables only once

  • Possibly ok
  • No provision for this in data structure - would have to adjust lwData and lwAna - eep

Also

  • Reduce epics CA ADDR list
  • see if it's writing that's the problem or reading
  • try acquiring the variables in pylab but not writing and time it

Tests

Use caEventRate in terminal on extlw:progress, which updates each time an acquisition is finished. Set 100 pulse log in EDM.

Description Event Rate (Hz)
As is 0.969 +- 0.092
Triggervar extlw:ADC:data 1.562 +- 0.186
Writing commented out 1.031 +- 0.012
Non mission-critical pvs removed (1) 1.500 +- 0.200
caget now with timeout=0.1s, throw=False 1.500 +- 0.185
Remove more pvs (2) 1.562 +- 0.194

(1) Following pvs were removed from pulse by pulse data

temprack' 'lab:temp:ch1'
temppfn' 'lab:temp:ch2'
templab' 'lab:temp:ch3'
tempahall' 'lab:temp:ch4'
templaser' 'lab:temp:ch5'
ipm1x' 'ip:m1:x:pos'
ipm1y' 'ip:m1:y:pos'
ipm2x' 'ip:m2:x:pos'
ipm2y' 'ip:m2:y:pos'
otrm1x' 'ip:otrm1:x:pos'
otrm1y' 'ip:otrm1:y:pos'
otrlensz' 'ip:otrlens:z:pos'
td21' 'extlw:TD2:1:read'
td22' 'extlw:TD2:2:read'
td41' 'extlw:TD4:1:read'
td23' 'extlw:TD2:3:read'

(2) Following pvs were removed from pulse by pulse data

tekm3' 'extlw:tekscope:m3'
tekm4' 'extlw:tekscope:m4'
ipoffsetxabs' 'extlw:ipoffsetmag:x'
ipoffsetyabs' 'extlw:ipoffsetmag:y'
ipanglexabs' 'extlw:ipanglemag:x'
ipangleyabs' 'extlw:ipanglemag:y'

  • The tek measurements aren't being used and the others can be calculated from the other recorded data

Timing the functions in python - ca.caget takes pretty much the same time irrespective of how many pvs it's getting. Time required for acquisition loop increases approximately linearly with number of pvs - not pv specific. Data writing only takes less than 50ms - not an issue.

Solution

  • Changed the exact way the caget is used. Before it was:

sample={}
for key, pv in self.datakeys.iteritems():
    sample[key] = ca.caget(pv,timeout=0.1,throw=False)
        
self.sample = sample
self.d.WriteData(sample)
        
perc = (self.npulse/self.npulsemax)*100
ca.caput('extlw:progress',perc)

  • Now breaks datakeys dictionary into two separate lists (where the order is fixed) and gets them all at once

...in __init__

self.ps = []
self.ks = []
    for key,pv in self.datakeys.iteritems():
       self.ps.append(pv)
       self.ks.append(key)
                
...in Callback

d = []
d.append(ca.caget(self.ps))
sample = dict(zip(self.ks,d[0]))

Now timing the caget process in python - it takes only 20ms on average to get all pvs with all the omitted ones in the tests acquired. So the maximum the sample acquisition and writing can take is 100ms now.

Done.

CA Event Rate (Hz): current 1.56243 mean 1.60319 std dev 0.178284

Physics WebpagesRHUL WebpagesCampus Connect • Royal Holloway, University of London, Egham, Surrey TW20 0EX; Tel/Fax +44 (0)1784 434455/437520

Topic revision: r1 - 21 May 2012 - LauraCorner

 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2023 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding RHUL Physics Department TWiki? Send feedback