First successful transport of Area Detector image to client running plugins

[<dav...@di...>]

On Friday I got the full data path working for my area detector application.

As you may be aware I already had an area detector plugin which ran a pvAccess server that served up an area detector image. I demoed this at PSI using simDetector to generate the images and got and monitored the PV with pvget/pvget -m.

Last week I wrote a pvAccess client that implements area detector and creates NDArrays by monitoring the image. I can now run this and connect it to existing plugins.

This was one of our main objectives for Diamond as discussed at the BNL meeting in October (http://epics-pvdata.sourceforge.net/meetings/2012-10/18-minutes.html):

“Want to be able to run an areaDetector driver on one machine, and an areaDetector plugin on another machine, and transfer the NDArrays between the two using EPICS V4 monitors “

I also got to the bottom of the main issue I was having with the plugin - the reason the server was locking up for several minutes was due to the first array copy actually taking that long. Now I understand that issue I should be able to make more progress server-side.

I’ve attached a screenshot. The left-hand panel is for the machine running the area detector driver (pc0046). The selected tab is the one for sim detector which is generating a scrolling black and white image. The mpg plugin (which you can see on the tab on the right hand side of the panel) provides the window displaying the image in the top right.  The adImSrv tab corresponds to the V4 plugin serving up the image.

The right-hand panel is the client running on pc0008. The tab on the left is not actually one for sim detector, but the v4 client. It’s monitoring the image pv, converting it to an NDArray and sending it to the plugins, including the mpg plugin seen on the right-hand tab, which provides  the image window in the bottom right. You can see the dimensions, color mode and unique ID on the mpg tab of the right hand panel.

So this is proof of concept. One of our beamline engineers has given me some requirements – 90 10 MB images a second. I’m quite a way off this (this is producing 7MB images and starts dropping them above 8 or 9 a second – so lots of work to do).  I’ll have to look at the efficiency of my code and that in pvData. It may be that we need to compress the data to get the rates we want – I don’t know yet.

I need to do some other work now for the next run which starts on Friday. After that I should be able to resume work on this.

Next tasks:
Improve/tidy up the code.
Make the server plugin and client more reliable (they’re very buggy at the moment).
Try and improve the data rate.
Work how to package this up so other people can use it.

So still plenty to do, but it’s a good start.

Dave



-- 

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