EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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  <20232024  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  <20232024 
<== Date ==> <== Thread ==>

Subject: Re: Data transport problem with CA
From: Jörn Dreyer via Tech-talk <tech-talk at aps.anl.gov>
To: tech-talk at aps.anl.gov
Date: Wed, 01 Feb 2023 13:32:38 +0100
Hi Yong,

it turned out to be a complex combination of mistakes:

1) For my NDStadArray.template I had originaly set Type=Int32 and FTVL=USHORT.
This does not match of course, so changing TYPE to INT16 and FTVL to SHORT was 
part of the solution.

2) As the array is defined with TYP set to asyn$(TYPE)ArrayIn, the type defines 
the size og the elements. So no need to take this in the ELEMENTS into 
account. 4656 * 3520 is good enough.

3) But the size of the array elements has to be take n into account, when 
calculating the value of EPICS_CA_MAX_ARRAY_BYTES. I used 32000000.

4) For phoebus the overhead seems to be larger than for caget. I needed to 
set:
org.phoebus.pv.ca/max_array_bytes=33000000

Now also my QT application based on EPICS-QT works.

Thanks for all the help.

Regards,

Jörn

Am Dienstag, 31. Januar 2023, 14:37:07 CET schrieb Hu, Yong:
> Here is my points: do the calculation for big array data (tens of MB)
> instead of simply using a huge number; then set the just-big-enough number
> for EPICS_CA_MAX_ARRAY_BYTES both inside your IOC and your CA client
> (Phoebus, caget, etc.).
> 
> You can type something like this to get the data type: caget
> YourADPrefix:DataType_RBV. Even suppose you use ‘Float64’ which I guess is
> 8-byte on 64-bit OS, you only need less than 132MB: 4656*3520*8 = 131112960
> (+ a few bytes for CA protocols) ~ 131113100 Bytes. 400MB is really too big
> and it will probably give you trouble down the road when too many CA
> clients are trying to see the image.
> 
> Yong
> 
> From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Hu, Yong via
> Tech-talk <tech-talk at aps.anl.gov> Date: Tuesday, January 31, 2023 at 8:17
> AM
> To: Jörn Dreyer <j.dreyer at hzdr.de>, tech-talk at aps.anl.gov
> <tech-talk at aps.anl.gov> Subject: Re: Data transport problem with CA
> Hi Jörn,
> 
> Firstly you missed one ‘0’ in your caget’s EPICS_CA_MAX_ARRAY_BYTES which is
> 40MB (not 400MB as you configured in Phoebus).
> 
> Having said that, 40MB should be enough for the ASI1600MM if your
> ‘imagePV:ArrayData’ is 16-bit data type: 4656*3520*2 = 32778240 < 40MB.
> What is your settings for the data type ‘imagePV:ArrayData’’? 16-bit,
> 24-bit, 32-bit?
> 
> Also, it is worth checking the settings of EPICS_CA_MAX_ARRAY_BYTES inside
> your IOC (i.e. st.cmd). I guess it is big enough, otherwise you will have
> trouble with the Phoebus reading. Anyway, what is the number you used for
> the ASI1600MM IOC?
> 
> Cheers,
> Yong
> 
> 
> From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Jörn Dreyer via
> Tech-talk <tech-talk at aps.anl.gov> Date: Tuesday, January 31, 2023 at 6:33
> AM
> To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
> Subject: Data transport problem with CA
> 
> Hi,
> 
> 
> I run into a problem with transporting the data of an areaDetector image
> over CA. It works in one case, but not the other.
> 
> I have one IOC that reads out three cameras
> 
> 
> 1) Two basler cameras with 659*494 pixels
> 
> 2) One ASI 1600MM with 4656 x 3520 pixels
> 
> 
> Now to the problem:
> 
> The Basler cameras do not make any problem, only the ASI1600MM is affected:
> 
> 
> It works in Phoebus when setting org.phoebus.pv.ca/max_array_bytes=400000000
> 
> 
> I can see reasonable Data when calling caget with a low number of elements
> to read, but fails with a warning "virtual circuit disconnect" when
> attempting to read the full image and all data is shown to be 0.
> 
> 
> The first lines of caget output are:
> 
> 
> caget imagePV:ArrayData
> 
> Read operation timed out: some PV data was not read.
> imagePV:ArrayData 16389120 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0
> 
> Limiting the amount of data read:
> 
> 
> caget imagePV:ArrayData -# 100
> imagePV:ArrayData 100 3520 3888 4080 4480 4560 4992 4480 4864 5136 5184 5536
> 6096 5488 4672 3024 2192 1536 1264 848 944 816 608 560 640 480 496 464 432
> 544 416 336 400 336 33 6 464 320 400 480 352 304 336 256 304 272 240 320
> 272 288 272 288 256 320 256 304 240 224 304 288 240 240 256 256 288 320 288
> 304 256 304 272 256 240 288 256 352 304 320 304 304 288 304 256 288 28 8
> 320 352 336 368 368 304 320 288 352 336 288 304 320 272 224 272 256
> 
> 
> 
> The environment vaiable EPICS_CA_MAX_ARRAY_BYTES is set to 40000000 to match
> the setting for phoebus.
> 
> 
> What setting might need to be changed to get that working?
> 
> 
> Regards,
> 
> 
> Jörn

Vorstand: Prof. Dr. Sebastian M. Schmidt, Dr. Heike Wolke
Vereinsregister: VR 1693 beim Amtsgericht Dresden 



References:
Data transport problem with CA Jörn Dreyer via Tech-talk
Re: Data transport problem with CA Hu, Yong via Tech-talk
Re: Data transport problem with CA Hu, Yong via Tech-talk

Navigate by Date:
Prev: Quickstart Error trying P4P Matt Rippa via Tech-talk
Next: Phoebus server mode question Steve Kinder - STFC UKRI via Tech-talk
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  <20232024 
Navigate by Thread:
Prev: Re: Data transport problem with CA Hu, Yong via Tech-talk
Next: Allen-Bradley PLC question Mark Rivers via Tech-talk
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  <20232024 
ANJ, 01 Feb 2023 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·