RE: xspress3

[<nick.rees@diamond.ac.uk>]

Hi Matt,

 

I think we aren’t far apart really. I think you made two points, one about ROI’s and one about individual site configurations.

 

With regard to ROI’s, we would like the ROI’s in the new system to be generated by Matt Pearson’s NDPluginROIStat plugin, which can be used with all types of detectors and gives sites flexibility as to how ROI’s are configured and used.

 

The Xspress3 hardware comes in 1, 2, 4, 6, 8, 16 and 32 channel varieties (to my knowledge), and with the existing software the only way I can reasonably generate IOC’s for all these configurations is automatically – and this both makes them hard to change in the repository and dependent on a few Diamond build rules (which is why they are included in the release). One goal of the changes is to make IOC configuration simpler so it is reasonable for a site to generate an IOC from scratch as they may do for other detectors.

 

However, I expect local sites to hand modify these auto-generated IOC’s – but the ones in the central repository can’t be hand modified. I think we need to develop a work flow in Git (for all of areaDetector) so that we can keep local modifications local and keep the GitHub repository generic. I see in the pull request that you have reverted some of the local changes, but kept other and also kept a set_location.py script to allow some ability to differentiate between sites even in the GitHub repository.

 

As to a way forward, I have suggested to Ulrik that we have a short Xspress3 item on the agenda in the areaDetector working group meeting tomorrow, and we could then plan a way forward then. The meeting starts at 09:30 Chicago time – could you (and Matt Moore) join in with Mark Rivers from Chicago?

 

Cheers,

 

Nick Rees

Principal Software Engineer           Phone: +44 (0)1235-778430

Diamond Light Source                  Fax:   +44 (0)1235-446713

 

From: matt.newville@gmail.com [mailto:matt.newville@gmail.com] On Behalf Of Matt Newville
Sent: 20 July 2015 18:45
To: Rees, Nick (DLSLtd,RAL,TEC)
Cc: Matthew D. Moore; EPICS Tech Talk
Subject: Re: xspress3

 

 

On Mon, Jul 20, 2015 at 3:51 AM, <nick.rees@diamond.ac.uk> wrote:

Hi Matt (and Matt),

 

First I want to start by apologising for missing/not being aware of the pull request from Matt Newville. I have just looked at it and it seems we are going in basically the same direction (eliminating a lot of the crap from the data files), except Matt has made quite a few changes to an example IOC which is auto-generated so if we need to keep this we will have to move it somewhere else or else it will be trodden on by the next time we auto-generate the code.

 

Hm, one of the key features of using github.com is that it notifies about Pull Requests.

I run from a hand-modified copy of an auto-generated ioc startup script.   I think that sort of thing that should probably be preferred / recommended over running from automatically generated scripts.
 

The auto-generation has been essential up until now because otherwise there is been no practical way to easily write IOC’s for Xspress3’s with differing numbers of channels. I hope to change this.

 

For electronics supplied by a vendor and essentially one-to-one with a specific detector, I don't see that worrying about different numbers of channels is a very high priority.
 

So, in answer to Matt Moore, the driver still needs work, but we want to fix it. Most of the changes are on GitHub, either in Matt Newvilles area (https://github.com/newville/xspress3) or Adam Bark’s (https://github.com/AdamBark/xspress3). We need to work on a merge of all these.

My first question from a quick look at Adam's work would be about "removing MCA ROIs" at
https://github.com/AdamBark/xspress3/commit/4f3a170ae585bdd2812ba280614d1b5f40a8b9fb

Perhaps I'm not understanding, but aren't those connected in xspress3Channel.template and xspress3ChannelMCAROI.template to the PVs

   $(PREFIX):C$(CHAN)_MCA_ROI$(ROI)_HLM
   $(PREFIX):C$(CHAN)_MCA_ROI$(ROI)_LLM
   $(PREFIX):C$(CHAN)_ROI$(ROI)
   $(PREFIX):C$(CHAN)_ROI$(ROI):Value_RBV
   $(PREFIX):C$(CHAN)_ROI$(ROI):ArrayData_RBV

I use these ROIs.  Is there a proposed alternative for them?

I agree with Matt Moore that it would be useful to discuss the path forward.

 

--Matt Newville

 

-- 

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