Experimental Physics and Industrial Control System
There are some issues with the ADSpinnaker software under Ubuntu 18.
Example: I can collect single images fine, I can collect multiple images
fine, but I can not do a continuous scan. Stopping that will stop the
process, but never clears the Acquire PV back to 0. So never cleanly stops,
so can never actually start it back up again.
It looks as if it should be in stopCapture, that is what is being called for
single and multiple, but it does not.
Added trace code as follows -
asynStatus ADSpinnaker::stopCapture()
{
int status;
static const char *functionName = "stopCapture";
setIntegerParam(ADAcquire, 0);
callParamCallbacks();
setShutter(0);
// Need to wait for the task to set the status to idle
while (1) {
getIntegerParam(ADStatus, &status);
if (status == ADStatusIdle) break;
// if (status == ADStatusIdle) continue;
unlock();
epicsThreadSleep(.1);
lock();
printf(".");
}
try {
printf("In the start of try block \n");
pCamera_->EndAcquisition();
printf(" after \n");
ImagePtr pImage;
// Need to empty the message queue it could have some images in it
while(pCallbackMsgQ_->tryReceive(&pImage, sizeof(pImage)) != -1) {
printf(".");
}
printf("At the end of the try block \n");
}
catch (Spinnaker::Exception &e) {
printf("in the catch block \n");
asynPrint(pasynUserSelf, ASYN_TRACE_ERROR,
"%s::%s exception %s\n",
driverName, functionName, e.what());
return asynError;
}
printf(" at end of stopAcquire \n");
return asynSuccess;
}
In the ioc console, I see
epics>
epics> In the start of try block
after
At the end of the try block
at end of stopAcquire
In the start of try block
after
At the end of the try block
at end of stopAcquire
.In the start of try block
So I am getting a hang on the statement
pCamera_->EndAcquisition();
-----Original Message-----
From: [email protected] <[email protected]> On
Behalf Of Mark Rivers
Sent: Wednesday, October 17, 2018 7:47 AM
To: 'POZAR, Andraz' <[email protected]>; [email protected]
Subject: RE: Camera Recommendations [SEC=UNCLASSIFIED]
Hi Andraz,
> we have tried using BFLY-PGE-13S2M-CS with adSpinnaker on Ubuntu 16
> and FL3-GE-13S2M-CS with adPontGrey on Centos 7 but both of them "freeze"
after running smoothly for some time.
> They become unresponsive and an IOC reboot is required in some cases even
power cycle of the camera.
That's interesting. I have some questions about this:
- What is the approximate mean time it takes for the camera to freeze? I
would like to try to reproduce the problem and want to know how long I would
need to test.
- Have you tried running the Point Grey software, either FlyCap2 or SpinView
with these cameras? Does that also freeze? That would tell us if it is a
problem with the hardware or their library, or the EPICS software.
- Have you tried running the aravisGigE software? That would also help to
see where the problem is.
I own several of the BlackFly GigE cameras, but I am using them for
development, not in production, so I have not run them for a long time where
I might observe this.
However, I am using Point Grey Grasshopper3 cameras in production, both GigE
and USB3 versions. Right now I have a GS3-U3-23S6M that has run for 42 days
at 100 frames/s with no problems. That is running ADPoinyGrey on Centos 7.
I use the same model for tomography with ADPointGrey on Windows where I
typically collect 200GB/day with no issues. I also have 2 GS3-PGE-23S6C
(GigE) cameras that have run for 15 days at 46 frames/s with no problems.
Those are running ADPointGrey on Windows.
Mark
-----Original Message-----
From: POZAR, Andraz <[email protected]>
Sent: Tuesday, October 16, 2018 5:01 PM
To: Mark Rivers <[email protected]>; [email protected]
Subject: RE: Camera Recommendations [SEC=UNCLASSIFIED]
Hi Mark,
Thank you for recommendation, however, we have tried using BFLY-PGE-13S2M-CS
with adSpinnaker on Ubuntu 16 and FL3-GE-13S2M-CS with adPontGrey on Centos
7 but both of them "freeze" after running smoothly for some time. They
become unresponsive and an IOC reboot is required in some cases even power
cycle of the camera. We're running them at toughly 1 Hz so they should get
overworked.
At this stage we're looking at potential alternatives or any kind of advice
if someone has had similar experience with those cameras?
Cheers,
Andraz
-----Original Message-----
From: Mark Rivers [mailto:[email protected]]
Sent: Tuesday, October 16, 2018 10:45 PM
To: POZAR, Andraz <[email protected]>; [email protected]
Subject: Re: Camera Recommendations [SEC=UNCLASSIFIED]
Hi Andraz,
The Point Grey Blackfly cameras will meet your specifications:
https://www.ptgrey.com/blackfly-gige-poe-cameras
Here are 2 examples:
BFLY-PGE-13S2M-CS
1/3 inch, global shutter, 1288x964 pixels
3.75 micron pixels
66% QE, 11 e- read noise, 9339 e- full well
58 dB dynamic range
30 FPS
POE
$345
The following model has significantly better QE, read noise, and dynamic
range in a somewhat larger format:
BFLY-PGE-23S6M-C
1/1.2" sensor, global shutter, 1920x1200 pixels
5.86 micron pixels
80% QE, 7 e- read noise, 33105 e- full well
73 dB dynamic range
41 FPS
POE
$495
Either camera can be used with 3 areaDetector drivers:
ADPointGrey (Windows, Linux RHEL 7 or higher) aravisGigE (Linux, most any
version) ADSpinnaker (Windows, Linux Ubuntu 16 and higher)
Mark
________________________________
From: [email protected] <[email protected]> on
behalf of POZAR, Andraz <[email protected]>
Sent: Tuesday, October 16, 2018 12:44 AM
To: [email protected]
Subject: Camera Recommendations [SEC=UNCLASSIFIED]
Hi all,
We're looking into replacing our old Firewire cameras with Ethernet ones and
we'd be interested in any suggestions and experiences you have had with
different camera models.
Some requirements:
- 1/3 inch, global shutter, mono sensor at roughly 1300 x 900
resolution
- Good quantum efficiency and low noise
- Roughly 4 microns pixel size
- Ethernet
- Preferably POE
- areaDetector support
Cheers,
Andraz Pozar
Controls Engineer
Australian Synchrotron
Tel
Email
Web
+61 3 8540 5387
[email protected]<mailto:[email protected]>
www.ansto.gov.au<http://www.ansto.gov.au/>
[fb]<http://www.facebook.com/DiscoverANSTO> [tw] <https://twitter.com/ANSTO>
[ln] <http://www.linkedin.com/company/ansto> [yt]
<http://www.youtube.com/user/ANSTOVideos>
[ansto]
Important: This transmission is intended only for the use of the intended
addressee. It is confidential to the intended addressee and may contain
privileged information and or copyright material. If this email is not
intended for your attention, any use, printing, storage, reproduction or
further disclosure of this communication (including all attachments) is
strictly forbidden. If you have received this transmission in error, please
notify me by telephone or email and immediately delete all copies of this
transmission as well as any attachments.
- Replies:
- RE: Camera Recommendations [SEC=UNCLASSIFIED] Mark Rivers
- References:
- Camera Recommendations [SEC=UNCLASSIFIED] POZAR, Andraz
- Re: Camera Recommendations [SEC=UNCLASSIFIED] Mark Rivers
- RE: Camera Recommendations [SEC=UNCLASSIFIED] POZAR, Andraz
- RE: Camera Recommendations [SEC=UNCLASSIFIED] Mark Rivers
- Navigate by Date:
- Prev:
Re: Camera Recommendations [SEC=UNCLASSIFIED] Pearson, Matthew R. via Tech-talk
- Next:
RE: Camera Recommendations [SEC=UNCLASSIFIED] Mark Rivers
- 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
- Navigate by Thread:
- Prev:
RE: Camera Recommendations [SEC=UNCLASSIFIED] Mark Rivers
- Next:
RE: Camera Recommendations [SEC=UNCLASSIFIED] Mark Rivers
- 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