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