Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Tue, 6 Feb 2018 13:13:45 +0000

Hi Ulrik,

I've asked them to provide a library that works with RHEL/Centos 7, so we will see what happens.

> An even better and more portable solution would be to wrap their entire public API in "extern C".

> A C API is more portable across  compiler/linker versions, but C++ is not (your error relates to a C++ string type). > Obviously, this could potentially be a major change to their code and API!

I think they actually do that, they have both a C and C++ interface to the library.  The C interface library is  libSpinnaker_C.so.  However, I don't think that really helps with the problem, because the C library calls the C++ library, and thus still depends on newer versions of GLIBCXX:

corvette:amd64/usr/lib>strings libSpinnaker_C.so.1.8.0.64 | grep GLIB
GLIBC_2.4
GLIBC_2.14
GLIBC_2.2.5
GLIBCXX_3.4.20
GLIBCXX_3.4.9
GLIBCXX_3.4.21
GLIBCXX_3.4

Thanks,
Mark

________________________________
From: [email protected] <[email protected]>
Sent: Tuesday, February 6, 2018 4:05 AM
To: Mark Rivers; [email protected]
Subject: RE: FLIR Spinnaker SDK: Request for input

Hi Mark,

To my knowledge we don't have any Spinnaker cameras here at Diamond at the moment... However, we have been arguing about similar topics with detector vendors in the past and what seems to have worked is to ask that they build their Linux libraries against large-scale, long-term support Linux distributions - and follow their release cycle. These distributions are used across many sites and organisations across the world. The compiler/libs versions on there are fairly conservative and constant.

In my view, currently RedHat (or CentOS) 7 would be a good, conservative choice that would be supported and in use for several years. If they insist on a debian-based distribution then go for one of the Ubuntu Long Term Support (LTS) ones.

An even better and more portable solution would be to wrap their entire public API in "extern C". A C API is more portable across compiler/linker versions, but C++ is not (your error relates to a C++ string type). Obviously, this could potentially be a major change to their code and API!

Just my £0.02 worth...

Cheers,
Ulrik

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Mark Rivers
Sent: 05 February 2018 14:41
To: 'EPICS Mailing list' <[email protected]>
Subject: FLIR Spinnaker SDK: Request for input

Folks,

I have begun work on a new ADSpinnaker driver based on the Spinnaker SDK.  The Spinnaker libraries for Windows are no problem.  However, the Linux libraries have names like:

libGenApi_gcc540_v3_0.so
libGCBase_gcc540_v3_0.so

The name implies that they were built with gcc 5.4.0.  When I try to link against these libraries on my Centos 7 system with gcc 4.8.5 I get errors like the following:

/home/epics/devel/areaDetector-3-2/ADSpinnaker/lib/linux-x86_64/libSpinnaker.so: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::find(char const*, unsigned long) const@GLIBCXX_3.4.21'

This means it requires GLIBCXX 3.4.21.  When I run the following command "strings" on my Centos 7 system I see that I have the following versions of GLIBCXX:

corvette:ADSpinnaker/spinnakerApp/src>strings /usr/lib/libstdc++.so.6 | grep LIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_DEBUG_MESSAGE_LENGTH

So the most recent version I have is 3.4.19, I don't have 3.4.21.

I think it is unfortunate that their Linux Spinnaker version requires a very recent version of Linux and gcc.  I believe it will pose a problem for many of our sites that are using older versions of gcc.

Assuming it is technically possible, I would like to try to convince FLIR to release a version of the library built with an older version of gcc.  Other vendors (e.g. AVT) do this.

In order to convince them I would like to get some input from sites that are currently using Point Grey/FLIR cameras or plan to do so within a year or so.

- About how many of their cameras do you current use or plan on using within the next year?
- What version of Linux, gcc, and GLIBCXX are you using on your production machines?

Thanks,
Mark

________________________________
From: Mark Rivers
Sent: Wednesday, January 31, 2018 4:50 PM
To: 'EPICS Mailing list'
Subject: FLIR 10Gbit Ethernet camera question

Folks,

FLIR (formerly Point Grey) has introduced 10 Gbit Ethernet cameras.  They currently sell a 4096 x 3000 pixel version which can do 68 frames/s for $3,950.  They will soon start selling a 2448 x 2048 camera which can do 162 frames/s (price not announced yet).  These are very interesting cameras, since they use the Sony CMOS chips with very low read noise and global shutter.  These data rates are 775-796 MB/s, which is more than 2x faster than the same chips using a USB-3 interface.

These cameras cannot use the FlyCap2 SDK that other Point Grey cameras use.  They require their new Spinnaker SDK.  They are GeniCAM compliant, so they may also work with the aravisGigE driver.  Note that their new BlackFlyS cameras also require the Spinnaker SDK, they don't work with FlyCap2 either.

My questions:

-          Has anyone begun an areaDetector driver that uses the Spinnaker SDK?

-          Does anyone know if these 10Gbit cameras will work with the aravisGigE driver?  Any idea if aravisGigE is capable of running at the 10GBit Ethernet speeds?

Thanks,

Mark

--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System