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 - Point Grey Blackfly |
From: | Mark Rivers <[email protected]> |
To: | "'John Dobbins'" <[email protected]>, EPICS Tech-Talk <[email protected]> |
Date: | Fri, 27 Mar 2015 19:26:47 +0000 |
Hi John, I have not been able to track down and fix that problem. However, there is a trivial workaround. The constructor syntax is: pointGrey(const char *portName, int cameraId, int traceMask, int memoryChannel, int maxBuffers, size_t maxMemory, int priority, int stackSize); These are the arguments that are passed via the iocsh pointGreyConfig command. The “memoryChannel” argument specifies which set of parameters stored in non-volatile camera memory should be loaded at startup. If this argument is zero then nothing is
restored from non-volatile memory. If it is greater than zero then that set of parameters is loaded. The workaround is to simply use 1 for this argument, so that the first thing that is done is to load the first set of non-volatile parameters into the camera. Here are the symptoms of the problem. -
If memoryChannel 0 then the first time the IOC is run after power-cycling the camera it works fine. -
The second time the IOC is run the driver fails to communicate with the camera part way through the initialization. -
This problem only happens with the BlackFly camera, not the Grasshopper3 or the Flea3. -
The problem only happens on Linux, not on Windows. It seems that what is happening is that when the IOC exits on Linux it leaves the camera in a “bad state”. Restoring the state from non-volatile memory in the constructor
fixes the problem. But why does it only happen on Linux? I have written a test program that makes exactly the same calls to their library that the IOC does, and it does not have the problem. But the test program is single-threaded. Is there some code in
their library that is not thread-safe? But then why does it work on Windows? There is really no down-side to the workaround, since the IOC typically overwrites all of the camera parameters from save/restore during iocInit. So the fact that they were
loaded from non-volatile memory should not matter. Note that compared to the AVT (Prosilica) cameras I have found that the Point Grey GigE cameras tend to drop many more frames under the same network load and bandwidth usage. Mark From: [email protected] [mailto:[email protected]]
On Behalf Of John Dobbins I would like to use the Point Grey Blackfly (Gige) with a Linux IOC. I see the following comment under Future Releases in the Release Notes for ADPointGrey "Fix problem BlackFly camera not working on Linux when restarting IOC if any images were acquired."
How is this situation recovered under the current version of software? Do you have to cycle power on the camera? Or is there some other work around? Regards, John Dobbins |