1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 <2015> 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 <2015> 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: xspress3 |
From: | Mark Rivers <[email protected]> |
To: | "'[email protected]'" <[email protected]>, Matt Newville <[email protected]> |
Cc: | "[email protected]" <[email protected]> |
Date: | Tue, 21 Jul 2015 16:24:09 +0000 |
I see. I think it is worth doing it in the plugin itself. It will then have the same interface as the NDPluginStats and NDPlugAttribute plugins. It will also be lower
overhead. If there are 32 ROIs and 4 detectors then the asyn time series device support requires 128 callbacks per time point, while doing in the plugin will have no callbacks. Mark From: [email protected] [mailto:[email protected]]
Mark, We have had some success in just using the time series device support in asyn for this… Nick Rees Principal Software Engineer Phone: +44 (0)1235-778430 Diamond Light Source Fax: +44 (0)1235-446713 From: Mark Rivers [mailto:[email protected]]
One thing that the
NDPluginROIStat plugins lacks is the time-series arrays which the NDPluginStats and NDPluginAttribute plugins have. That is important, and is easy to add. I will do that
this week, and it will be in ADCore R2-3. Mark From:
[email protected] [mailto:[email protected]]
On Behalf Of [email protected] 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:
[email protected] [mailto:[email protected]]
On Behalf Of Matt Newville On Mon, Jul 20, 2015 at 3:51 AM, <[email protected]> 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.
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.
Perhaps I'm not understanding, but aren't those connected in xspress3Channel.template and xspress3ChannelMCAROI.template to the PVs 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. -- 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. |