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: AreaDetector: Virtual camera selecting from different hardware cameras |
From: | "Pearson, Matthew via Tech-talk" <tech-talk at aps.anl.gov> |
To: | Mark Rivers <rivers at cars.uchicago.edu>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>, "Blomley, Edmund (IBPT)" <edmund.blomley at kit.edu> |
Date: | Wed, 2 Aug 2023 14:29:20 +0000 |
Hi, If I was doing this today I’d do it the way Mark described below (separate IOC, pvaDriver, dynamically setting the input PV name to the NDPluginPva of each camera), as you get the benefits of using the NTNDArray data type which greatly
simplifies client configuration. Also, I would add any processing plugins in the separate IOC, linked to the output of the pvaDriver. However, if you’re only using channel access then this is a solution I’ve used for years: Setup a high level camera IOC with a subArray record, such like: # /// # /// subArray for high level user display. # /// This has to be as big as the biggest detector # /// record(subArray, "$(S):Det:Array") { field(INP, "$(S):Det:Q1:Array1:ArrayData CP MS")
ß areaDetector stdArray plugin array PV name field(FTVL, "LONG") field(MALM, "$(MAX_SIZE)") field(NELM, "$(MAX_SIZE)") field(INDX, "0") } And setup several other records to hold the array size values (if the camera images are different sizes), to use in the client display widget: # /// # /// Several records to provide the sizes and scale of the array # /// record(longin, "$(S):Det:ArraySizeX") { field(INP, "$(S):Det:Q1:Array1:ArraySize0_RBV CP MS") } record(longin, "$(S):Det:ArraySizeY") { field(INP, "$(S):Det:Q1:Array1:ArraySize1_RBV CP MS") } (and more records if you need them) Then use an mbbo to select which camera you want, and that triggers sseq records that write the INP link field names in each of the records above (including the CP MS link attributes).
The client screen just sees these high level records. Cheers, Matt From: Tech-talk <tech-talk-bounces at aps.anl.gov>
On Behalf Of Mark Rivers via Tech-talk Hi Eddy,
Here are a couple of solutions that just switched where the plugins get their data. This requires that you run all 3 cameras in the same IOC.
·
If you only want to switch the viewer plugin (NDPluginStdArrays or NDPluginPva) to get its data from the selected camera then just use an sseq record called to write the asyn port name
of the selected camera to the NDArrayPort PV of the viewer plugin.
·
If you want to switch all plugins to get their data from the selected camera then load an additional plugin like NDPluginROI. Configure that ROI plugin to just pass the NDArray unmodified
to downstream plugins. Configure downstream plugins to get their data from the ROI plugin. Now the sseq record modifies the NDArrayPort PV of the ROI plugin If you want a separate virtual camera then the following will work with the 3 cameras in separate IOCs, each with its own set of plugins.
·
Configure each camera to have its NDPluginPva get the data from the camera and be enabled
·
Create a fourth IOC that uses pvaDriver that is called CAM:VIRTUAL.
·
The sseq record sets the CAM:VIRTUAL:PvName to the NDPluginPva output of the selected camera, e.g. CAM:SCREEN:01:Pva1:Image.
·
This IOC will get its data from the selected screen.
·
Depending on what machine is hosting the IOCs this solution can add additional network traffic. Mark From: Tech-talk on behalf of Blomley, Edmund (IBPT) via Tech-talk Hey, |