Experimental Physics and
Industrial Control System

"Hu, Yong via Tech-talk" <tech-talk at aps.anl.gov> · Thu, 28 May 2020 13:54:44 +0000

That is odd. We are using CS-Studio heavily for areaDetector at NSLS-II and have not seen such problems.

Which version of CS-Studio are you using? What is the settings of EPICS_CA_MAX_ARRAY_BYTES both on your camera IOC side and on your CS-Studio side?  

We are using rules with PVs in IntensityGraph to automatically set Data width / height instead of manually configuring those parameters. I can send our .opi to you if you want (after your problems are fixed).

Best luck!

Yong Hu
NSLS-II Controls Group

On 5/28/20, 4:24 AM, "Tech-talk on behalf of Jörn Dreyer via Tech-talk" <tech-talk-bounces at aps.anl.gov on behalf of tech-talk at aps.anl.gov> wrote:

    Hello

    After some debugging, it turns out that the reason for the problem is
    CS-Studio.

    I have set up an opi Scene with an IntesityGraph for the Image. If I set the 
    Data width and Data high to zero, the scene chanes from "No data" to 
    "disconnected". If I set Data width to 4565 and Data height to 3520, the scene 
    can not be loaded and results in java.lang.IllegalArgumentException.
    No further information is available. The scene can then even not get loaded 
    into the OPI Editor and needs to be modified in a text editor.

    For other cameras I was able to set the data height and data width parameters 
    of the IntensityGraph to 2048 x 2048. Is there a size limit for this Widget?
    I did not find any hints obn that in the documentation.

    Regards,

    Jörn Drteyer

    Am Donnerstag, 28. Mai 2020, 09:29:58 CEST schrieb Jörn Dreyer via Tech-talk:
    > Am Mittwoch, 27. Mai 2020, 16:10:26 CEST schrieb Mark Rivers via Tech-talk:
    > > > Closed the OPI screen that shows the image. Now the number of threads is
    > > > constant. System load is at normal level.
    > > 
    > > When you saw the threads and high system load did you use top -H to see
    > > whether the threads with high CPU load were CSS threads or IOC threads? I
    > > suspect they are CSS threads.
    > 
    > No they are all started from the IOC. After 300 threads spawned I decided to
    > stop the IOC. I used
    > 
    > ps -eLF | grep st.cmd | wc
    > 
    > > > Will need some time to gat that going. Java on my system seems to have
    > > > problem with the code.
    > > 
    > > ImageJ on both Linux and Windows comes with its own version of Java in the
    > > ImageJ/jre directory, so it should be completely independent of your
    > > system
    > > version of Java.  Get the latest version of the ImageJ zip file and
    > > install
    > > it in your own directory so you don't need to worry about system
    > > permissions, etc.
    > 
    > I got it working, but there seems to be a problem that only half of the
    > image is intrerpreted correctly. The ArrayType is UInt16 instead of UInt8.
    > Will need to find out teh reason for that.
    > 
    > Regards,
    > 
    > Jörn
    > 
    > > Mark
    > > 
    > > 
    > > 
    > > -----Original Message-----
    > > From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Jörn Dreyer
    > > via Tech-talk Sent: Wednesday, May 27, 2020 8:56 AM
    > > To: tech-talk at aps.anl.gov
    > > Subject: Re: Strange problem with areaDetector driver
    > > 
    > > Am Mittwoch, 27. Mai 2020, 14:46:09 CEST schrieb Mark Rivers:
    > > > Hi Jörn,
    > > > 
    > > > > I ran into a severe problem in the image readout handler.
    > > > > 
    > > > > When calling doCallbackGenericPointer() the IOC creates every time a
    > > > > couple of  new threads and consumes lot of CPU power ( 300% on a
    > > > > quad core).
    > > > 
    > > > First a few questions:
    > > > 
    > > > 
    > > > Is this Linux or Windows?
    > > 
    > > Linux
    > > 
    > > > What frame rate are you using?
    > > 
    > > 0.5 Hz
    > > 
    > > > What plugins are running?
    > > 
    > > Only NDStdArray.
    > > 
    > > > Is the CS-Studio GUI on the same machine as the IOC or a different
    > > > machine?
    > > 
    > > On the same machine
    > > 
    > > > The first thing to establish is whether the problem is the
    > > > areaDetector IOC or the CS-Studio client.  I suggest you do the
    > > > following:
    > > > 
    > > > 
    > > > -  Disable all plugins except NDPluginStdArrays for testing.
    > > 
    > > Done,
    > > 
    > > > - Exit CS-Studio so there is no display client running.  What is the
    > > > CPU load under those conditions?
    > > 
    > > Closed the OPI screen that shows the image. Now the number of threads is
    > > constant. System load is at normal level.
    > > 
    > > > - Try the ImageJ viewer instead of CS-Studio for testing.  Does that
    > > > also have the problem?
    > > 
    > > Will need some time to gat that going. Java on my system seems to have
    > > problem with the code.
    > > 
    > > Regards,
    > > 
    > > Jörn
    > > 
    > > > Mark
    > > > 
    > > > 
    > > > 
    > > > 
    > > > 
    > > > ________________________________
    > > > 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> Sent: Wednesday, May 27,
    > > > 2020 7:03 AM
    > > > To: tech-talk at aps.anl.gov
    > > > Subject: Strange problem with areaDetector driver
    > > > 
    > > > Hello,
    > > > 
    > > > currently I have a very strange problem in a code I'm developing to
    > > > read out cameras from ZWO. I ran into a severe problem in the image
    > > > readout handler. When calling doCallbackGenericPointer() the IOC creates
    > > > every time a couple of new threads and consumes lot of CPU power ( 300%
    > > > on a quad core). So after a very short time the system becomes
    > > > unresponsive and has to be switched off. The image is 3520*4656 bytes in
    > > > size and is in monochrome mode, so UInt8 as data type.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System