Spinnaker SDK V1.20 is no longer available from FLIR web site.

[LeeYangLBLBCS]

The only versions available is V2.0 and V1.29 from FLIR: https://meta.box.lenovo.com/v/link/view/a1995795ffba47dbbe45771477319cc3 Is there any plan to update the drive to work with the newer version SDK? Would you happen to have an older version archived?

[LeeYangLBLBCS]

Spinnaker SDK v1.20 can still be obtained from FLIR if requested at this time.

[MarkRivers]

Sorry for the delay in replying.

I downloaded Spinnaker 2.0 from FLIR yesterday for both Windows and Linux. I will use that version in ADSpinnaker. Hopefully I can do it tomorrow.

[LeeYangLBLBCS]

Thanks. That'll be great!

In the mean time, FLIR sent me the old version Spinnaker, v1.20 after I asked for it. However it doesn't work with my camera. FLIR oryx-10G-51S5. I think it because the firmware is too new to work with the old Spinnaker. (Windows). I'm in the process of trying the same thing on Linux.

Newer versions 1.27 and 2.0 both worked (windows).

On Tue, Jul 21, 2020, 4:11 PM Mark Rivers notifications@github.com wrote:

Sorry for the delay in replying.

I downloaded Spinnaker 2.0 from FLIR yesterday for both Windows and Linux. I will use that version in ADSpinnaker. Hopefully I can do it tomorrow.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/areaDetector/ADSpinnaker/issues/3#issuecomment-662152557, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADSYGNBY7NNQ4QTVQF6YTQ3R4YOCFANCNFSM4PATGHCQ .

[MarkRivers]

However it doesn't work with my camera. FLIR oryx-10G-51S5. I think it because the firmware is too new to work with the old Spinnaker.

I have that camera and it is working fine with v1.20 and ADSpinnaker.

There is a screen shot of the medm screen running that camera in ADSpinnaker, which shows the model, and the SDK version here: https://areadetector.github.io/master/ADSpinnaker/ADSpinnaker.html#medm-screens

If you are having problems please post the exact error message.

[LeeYangLBLBCS]

Is the firmware on your camera 1710.0.0.0?

I only got as far as using the Spinview GUI to connect to my camera. The initialization fails.

I wonder if your camera has a different firmware version.

I havn't quite set up to test the EPICS MEDM yet.

On Tue, Jul 21, 2020 at 8:09 PM Mark Rivers notifications@github.com wrote:

However it doesn't work with my camera. FLIR oryx-10G-51S5. I think it because the firmware is too new to work with the old Spinnaker.

I have that camera and it is working fine with v1.20 and ADSpinnaker.

There is a screen shot of the medm screen running that camera in ADSpinnaker, which shows the model, and the SDK version here: https://areadetector.github.io/master/ADSpinnaker/ADSpinnaker.html#medm-screens

If you are having problems please post the exact error message.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/areaDetector/ADSpinnaker/issues/3#issuecomment-662215759, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADSYGNB2EDI2DNSMZ3ENEJDR4ZJ45ANCNFSM4PATGHCQ .

-- Lee Yang Lawrence Berkeley National Lab 1 Cyclotron Road, MS 7H210 Berkeley, California 97320 office:(510)486-7320 fax:(510) 486-4633

[MarkRivers]

Is the firmware on your camera 1710.0.0.0?

Yes, you can see that in the medm screen referenced in my last message. What is the firmware version of your camera?

[LeeYangLBLBCS]

My problem with v1.20 was caused by a defective RAID, which rendered the OS unusable at the wrong time. Fixed now.

When I started "Spinnaker IOC", I keep getting errors with image acquisition:

2020/07/25 20:14:54.695 ADSpinnaker::grabImage error GetImageStatus returned 9 2020/07/25 20:14:54.845 ADSpinnaker::grabImage error GetImageStatus returned 9 2020/07/25 20:14:55.716 ADSpinnaker::grabImage error GetImageStatus returned 9 2020/07/25 20:14:56.916 ADSpinnaker::grabImage error GetImageStatus returned 9 2020/07/25 20:15:10.748 ADSpinnaker::grabImage error GetImageStatus returned 9 2020/07/25 20:15:11.148 ADSpinnaker::grabImage error GetImageStatus returned 9 2020/07/25 20:15:33.853 ADSpinnaker::grabImage error GetImageStatus returned 9

The Acquire "Start" seems to work regardless of these errors though. I wonder if I need to worry about this error?

Also, how do I display the images from MEDM? I attached MEDM screen and HDF5 pluggin, in case they are useful. [image: image.png] [image: image.png]

On Wed, Jul 22, 2020 at 8:47 AM Mark Rivers notifications@github.com wrote:

Is the firmware on your camera 1710.0.0.0?

Yes, you can see that in the medm screen referenced in my last message. What is the firmware version of your camera?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/areaDetector/ADSpinnaker/issues/3#issuecomment-662531020, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADSYGNFUC6VJRX3H5RVTVB3R44C2XANCNFSM4PATGHCQ .

-- Lee Yang Lawrence Berkeley National Lab 1 Cyclotron Road, MS 7H210 Berkeley, California 97320 office:(510)486-7320 fax:(510) 486-4633

[MarkRivers]

Those errors are coming because the camera is defaulting to jumbo packets. Go to the Features #1 screen and change the PacketSize (which is probably about 8000) to 1500.

This is a common problem with ADSpinnaker. I will add the packet size to the standard parameters, and add it to autosave.

[MarkRivers]

Your attachments are not showing up. You cannot add them from e-mail, you need to add them directly on Github.

You cannot see the images in medm. I recommend using the ImageJ plugin from ADViewers.

[LeeYangLBLBCS]

I assume you meant the "Camera-specific features" drop down list "Featuers #1"? I tried it, and Features 2,3,4,... but got errors:

Cannot open related display: $(C)-features_1.adl Check EPICS_DISPLAY_PATH

I suspect the parameter $(C) is not instantiated properly, though I don't know where it's being set.

Also, do these Features require the "aravisGigE" module to be compiled? (It didn't).

[MarkRivers]

I assume you meant the "Camera-specific features" drop down list "Featuers #1"? I tried it, and Features 2,3,4,... but got errors:

Cannot open related display:
$(C)-features_1.adl
Check EPICS_DISPLAY_PATH

I suspect the parameter $(C) is not instantiated properly, though I don't know where it's being set.

You need to pass the C macro when you load the ADSpinnaker screen, the same way you pass P and R. The C macro should be the string that is specific to your camera, in this case you would pass:

C=FLIR_ORX_10G_51S5M

You can look at ADTop.adl for examples.

Also, do these Features require the "aravisGigE" module to be compiled? (It didn't).

No, you never need aravisGigE. You do need to build the Linux package aravis if you need to add support for a new camera that is not already in ADGenICam, because you need to read the XML file from the camera and build the EPICS database and medm screens. But for your Oryx camera those files are already in ADGenICam.

You can use either ADSpinnaker or ADAravis to control that camera.

[MarkRivers]

When I started "Spinnaker IOC", I keep getting errors with image acquisition: 2020/07/25 20:14:54.695 ADSpinnaker::grabImage error GetImageStatus returned 9

My previous answer to this question, where I said to change the PacketSize is incorrect. I forgot you are using a USB camera, not a GigE camera.

For USB cameras there are Linux system settings that need to be changed in order to stream images larger than 2 MB. Those are described here: https://areadetector.github.io/master/ADGenICam/ADGenICam.html#linux-usb-and-gige-system-settings

Have you changed the settings described on that page?

[LeeYangLBLBCS]

I'm using GigE, not USB.

After I increased the "net.core.rmem" setting according to the instructions,

sysctl -w net.core.rmem_max=8388608 net.core.rmem_default=8388608

The error is not happening nearly as often, but still occasionally, about 1/min, as compared to 1/few seconds.

epics> epics> 2020/07/26 09:31:49.484 ADSpinnaker::grabImage error GetImageStatus returned 9 2020/07/26 09:32:48.609 ADSpinnaker::grabImage error GetImageStatus returned 9 2020/07/26 09:33:54.186 ADSpinnaker::grabImage error GetImageStatus returned 9

On Sun, Jul 26, 2020 at 9:15 AM Mark Rivers notifications@github.com wrote:

When I started "Spinnaker IOC", I keep getting errors with image acquisition: 2020/07/25 20:14:54.695 ADSpinnaker::grabImage error GetImageStatus returned 9

My previous answer to this question, where I said to change the PacketSize is incorrect. I forgot you are using a USB camera, not a GigE camera.

For USB cameras there are Linux system settings that need to be changed in order to stream images larger than 2 MB. Those are described here: https://areadetector.github.io/master/ADGenICam/ADGenICam.html#linux-usb-and-gige-system-settings

Have you changed the settings described on that page?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/areaDetector/ADSpinnaker/issues/3#issuecomment-664007746, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADSYGNA5DCIHYOLHFHNF6CLR5RJCTANCNFSM4PATGHCQ .

-- Lee Yang Lawrence Berkeley National Lab 1 Cyclotron Road, MS 7H210 Berkeley, California 97320 office:(510)486-7320 fax:(510) 486-4633

[LeeYangLBLBCS]

I found where to supply $(C) value. The Features 1-6 work now.

Do you know why I can't change acquisition time? I think it's related to the initial error message I got when ioc starts:

2020/07/26 10:04:24.763 Param[ACQ_TIME] GenICamFeature::write: node ExposureTime is not writable

2020/07/26 10:04:24.800 Param[ACQ_PERIOD] GenICamFeature::write: node AcquisitionFrameRate is not writable

On Sun, Jul 26, 2020 at 9:37 AM Lee L. Yang llyang@lbl.gov wrote:

I'm using GigE, not USB.

After I increased the "net.core.rmem" setting according to the instructions,

sysctl -w net.core.rmem_max=8388608 net.core.rmem_default=8388608

The error is not happening nearly as often, but still occasionally, about 1/min, as compared to 1/few seconds.

epics> epics> 2020/07/26 09:31:49.484 ADSpinnaker::grabImage error GetImageStatus returned 9 2020/07/26 09:32:48.609 ADSpinnaker::grabImage error GetImageStatus returned 9 2020/07/26 09:33:54.186 ADSpinnaker::grabImage error GetImageStatus returned 9

On Sun, Jul 26, 2020 at 9:15 AM Mark Rivers notifications@github.com wrote:

When I started "Spinnaker IOC", I keep getting errors with image acquisition: 2020/07/25 20:14:54.695 ADSpinnaker::grabImage error GetImageStatus returned 9

My previous answer to this question, where I said to change the PacketSize is incorrect. I forgot you are using a USB camera, not a GigE camera.

For USB cameras there are Linux system settings that need to be changed in order to stream images larger than 2 MB. Those are described here: https://areadetector.github.io/master/ADGenICam/ADGenICam.html#linux-usb-and-gige-system-settings

Have you changed the settings described on that page?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/areaDetector/ADSpinnaker/issues/3#issuecomment-664007746, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADSYGNA5DCIHYOLHFHNF6CLR5RJCTANCNFSM4PATGHCQ .

-- Lee Yang Lawrence Berkeley National Lab 1 Cyclotron Road, MS 7H210 Berkeley, California 97320 office:(510)486-7320 fax:(510) 486-4633

-- Lee Yang Lawrence Berkeley National Lab 1 Cyclotron Road, MS 7H210 Berkeley, California 97320 office:(510)486-7320 fax:(510) 486-4633

[MarkRivers]

I'm using GigE, not USB.

Sorry, that's right the Oryx is 10 GBit Ethernet, not USB.

The error is not happening nearly as often, but still occasionally, about 1/min, as compared to 1/few seconds.

What kind of system is this, i.e. what CPU type and how many cores? Send the output of

more /proc/cpuinfo

I am able to stream with that camera with very few if any dropped frames on a system with 16 cores and Intel(R) Xeon(R) W-2145 CPU @ 3.70GHz.

Here is a screen shot of my camera. I have set it for 163 frames/s, ImageMode=Multiple and NumImages=20000.

I collected all 20000 frames without seeing the message you reported.

Is your camera on a dedicated NIC? Mine is, and that is a good idea. It does not share Ethernet bandwidth with any other devices.

[LeeYangLBLBCS]

My computer is about 8 years old. I should get a new computer in a few weeks. Though I do have a dedicated 10G NIC bought directly from FLIR. I can revisit this problem when the new computer arrives. The cpu info is attached nonetheless.

I couldn't change the exposure time and frame rate for some reason. So I can't do the same test you did. When I tried to change them, the value reverts back quickly. I can change some of the other parameters though, such as trigger mode, trigger input etc. Maybe there are file permission problems in my setup?

On Sun, Jul 26, 2020 at 10:16 AM Mark Rivers notifications@github.com wrote:

I'm using GigE, not USB.

Sorry, that's right the Oryx is 10 GBit Ethernet, not USB.

The error is not happening nearly as often, but still occasionally, about 1/min, as compared to 1/few seconds.

What kind of system is this, i.e. what CPU type and how many cores? Send the output of

more /proc/cpuinfo

I am able to stream with that camera with very few if any dropped frames on a system with 16 cores and Intel(R) Xeon(R) W-2145 CPU @ 3.70GHz.

Here is a screen shot of my camera. I have set it for 163 frames/s, ImageMode=Multiple and NumImages=20000.

[image: image] https://user-images.githubusercontent.com/6115534/88485194-ad8ce900-cf39-11ea-9273-a18501488087.png

I collected all 20000 frames without seeing the message you reported.

Is you camera on a dedicated NIC? Mine is, and that is a good idea. It does not share Ethernet bandwidth with any other devices.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/areaDetector/ADSpinnaker/issues/3#issuecomment-664015901, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADSYGNH4IVLOF7GXKCAXIZLR5RQIRANCNFSM4PATGHCQ .

-- Lee Yang Lawrence Berkeley National Lab 1 Cyclotron Road, MS 7H210 Berkeley, California 97320 office:(510)486-7320 fax:(510) 486-4633

processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 62 model name : Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz stepping : 4 microcode : 0x42e cpu MHz : 1232.970 cache size : 10240 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts md_clear flush_l1d bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit bogomips : 7399.30 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management:

processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 62 model name : Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz stepping : 4 microcode : 0x42e cpu MHz : 1226.703 cache size : 10240 KB physical id : 0 siblings : 8 core id : 1 cpu cores : 4 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts md_clear flush_l1d bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit bogomips : 7399.30 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management:

processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 62 model name : Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz stepping : 4 microcode : 0x42e cpu MHz : 1237.775 cache size : 10240 KB physical id : 0 siblings : 8 core id : 2 cpu cores : 4 apicid : 4 initial apicid : 4 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts md_clear flush_l1d bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit bogomips : 7399.30 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management:

processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 62 model name : Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz stepping : 4 microcode : 0x42e cpu MHz : 1238.743 cache size : 10240 KB physical id : 0 siblings : 8 core id : 3 cpu cores : 4 apicid : 6 initial apicid : 6 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts md_clear flush_l1d bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit bogomips : 7399.30 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management:

processor : 4 vendor_id : GenuineIntel cpu family : 6 model : 62 model name : Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz stepping : 4 microcode : 0x42e cpu MHz : 1267.571 cache size : 10240 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts md_clear flush_l1d bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit bogomips : 7399.30 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management:

processor : 5 vendor_id : GenuineIntel cpu family : 6 model : 62 model name : Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz stepping : 4 microcode : 0x42e cpu MHz : 1221.939 cache size : 10240 KB physical id : 0 siblings : 8 core id : 1 cpu cores : 4 apicid : 3 initial apicid : 3 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts md_clear flush_l1d bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit bogomips : 7399.30 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management:

processor : 6 vendor_id : GenuineIntel cpu family : 6 model : 62 model name : Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz stepping : 4 microcode : 0x42e cpu MHz : 1219.757 cache size : 10240 KB physical id : 0 siblings : 8 core id : 2 cpu cores : 4 apicid : 5 initial apicid : 5 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts md_clear flush_l1d bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit bogomips : 7399.30 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management:

processor : 7 vendor_id : GenuineIntel cpu family : 6 model : 62 model name : Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz stepping : 4 microcode : 0x42e cpu MHz : 1231.240 cache size : 10240 KB physical id : 0 siblings : 8 core id : 3 cpu cores : 4 apicid : 7 initial apicid : 7 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts md_clear flush_l1d bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit bogomips : 7399.30 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management:

[MarkRivers]

I couldn't change the exposure time and frame rate for some reason. So I can't do the same test you did. When I tried to change them, the value reverts back quickly. I can change some of the other parameters though, such as trigger mode, trigger input etc. Maybe there are file permission problems in my setup?

It is not a file permissions problem, it is because you have set ExposureAuto=Continuous. So it is continually adjusting the exposure time. You should set ExposureAuto=Off. Then you should be able to use the same settings I used.

Your computer does not look bad, 8 cores at 3.7 GHz.

[LeeYangLBLBCS]

that's what I thought at first. But no that's not it. I made sure the exposure is off. What's more interesting is that I can change exposure time from command line: lyang@lyangUbuntu:~/epics/flir_setup$ caput 13SP1:cam1:GC_ExposureTime 0.03 Old : 13SP1:cam1:GC_ExposureTime 0.02 New : 13SP1:cam1:GC_ExposureTime 0.03 And the exposure time is updated correctly in "features #1" window as I watched it changing. But I can't change it from either the main MEDM window or the feature #1.

[LeeYangLBLBCS]

Maybe I am confused which is exposure time. There are two numbers next to "ExposureTime" label. The left number can't be changed - may be that's the measured value? The right number changes when I change it from command line through caget. caput 13SP1:cam1:GC_ExposureTime I thought there is a way to change it from the GUI, No?

[MarkRivers]

The problem is that you have FrameRateEnable=Yes, and you have set the FrameRate=71.847. That means that your requested ExposureTime=0.015 is impossible, because at that FrameRate the longest possible ExposureTime is 1/71.847=0.0139 seconds. You can set FrameRateEnable=No, and then the frame rate will be controlled by the requested ExposureTime, up to the maximum possible FrameRate.

Note that you have set PixelFormat=Mono16. That is slower, so you can't get 163 frames/s in that mode. Change to Mono8 and you should be able to get 163 frames/s.

The left number can't be changed - may be that's the measured value? The right number changes when I change it from command line through caget. caput 13SP1:cam1:GC_ExposureTime

There are 2 PVs that control the ExposureTime. The first is the areaDetector abstraction called AcquireTime. That is on the main ADSpinnaker screen and that is what you should be changing. GC_ExposureTime is the low-level GenICam parameter. When you change AcquireTime it actually writes to the same GenICam feature as GC_ExposureTime, but it does additional things, so you should use AcquireTime. If you use the middle mouse button in medm it will show you the name of the PV. You can also use the right button and then click PV Info with the left button on a widget you want to see.

[LeeYangLBLBCS]

thanks. Mouse click info really helps. Though the frame rate enable=Off didn't do anything for me.

[MarkRivers]

Do you know why I can't change acquisition time? I think it's related to the initial error message I got when ioc starts: 2020/07/26 10:04:24.763 Param[ACQ_TIME] GenICamFeature::write: node ExposureTime is not writable 2020/07/26 10:04:24.800 Param[ACQ_PERIOD] GenICamFeature::write: node AcquisitionFrameRate is not writable

Those errors were because you had ExposureTimeAuto=Yes.

[MarkRivers]

Your fonts are messed up now and hard to read. Close the window and re-open it and the fonts should go back to normal.

Put it in ImageMode=Continuous and start Acquire. You should then be able to change the exposure time, and the Image Rate it reports should change. Try 0.1, 0.01, 0.5, etc.

Are you pressing Enter after you change the AcquireTime? You need to do that without moving the mouse out of that widget before pressing Enter.

[LeeYangLBLBCS]

that's it. I didn't press enter! Sorry I wasn't used to pressing enters on a web page, fearing unintended consequences for some reason.

On Sun, Jul 26, 2020 at 12:07 PM Mark Rivers notifications@github.com wrote:

Your fonts are messed up now and hard to read. Close the window and re-open it and the fonts should go back to normal.

Put it in ImageMode=Continuous and start Acquire. You should then be able to change the exposure time, and the Image Rate it reports should change. Try 0.1, 0.01, 0.5, etc.

Are you pressing Enter after you change the AcquireTime? You need to do that without moving the mouse out of that widget before pressing Enter.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/areaDetector/ADSpinnaker/issues/3#issuecomment-664027958, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADSYGNHYET6RRNHB4DS62A3R5R5HFANCNFSM4PATGHCQ .

-- Lee Yang Lawrence Berkeley National Lab 1 Cyclotron Road, MS 7H210 Berkeley, California 97320 office:(510)486-7320 fax:(510) 486-4633

[MarkRivers]

Yes, medm has a different interface that way. The idea is that if the user moves the mouse out of the widget without pressing Enter the value reverts to its previous version. That is to prevent mistakes from the operators in the control room, they need to press Enter first.

Can you configure things like I did, and get an actual frame rate of 163 frames/s? Post another screen shot.

[LeeYangLBLBCS]

thanks. Mouse click info really helps. Though the frame rate enable=Off didn't do anything for me.

[LeeYangLBLBCS]

I did the same test using the same params from yours. There is one error occurring once at around 13-kth frame.

2020/07/26 12:38:40.844 ADSpinnaker::grabImage error GetImageStatus returned 9

It must be caused by non ideal condition of my computer hardware, I guess.

[MarkRivers]

Notice that although you asked for 163 frames/s you are only getting 144.554 frames/s. That is because you are in 10-bit mode, not 8-bit mode. You need to open Features#2 screen and on the lower-left change AdcBitDepth from 10 to 8. Then you should be able to get the full 163 frames/s.

What application will you be using this camera for? Is it for the 8.3.2 micro-tomography beamline?

[LeeYangLBLBCS]

I did the same test using the same params from yours. There is one error occurring once at around 13-kth frame.

2020/07/26 12:38:40.844 ADSpinnaker::grabImage error GetImageStatus returned 9

It must be caused by non ideal condition of my computer hardware, I guess.

[LeeYangLBLBCS]

I changed to 8 bit ADC and got the same frame rate and without any error this time. And yes this development is intended for use at 8.3.2 uT, though we are not sure if the camera is too noisy until we take real images. We've been using a slower camera (PCO), but less noisy. Also we probably have to use 10 bit or even 12 bit, and mono16 in real experiments. So we won't be able to achieve the same frame rate.

[MarkRivers]

If you are going to do tomography I would recommend these settings.

On the Features#2 screen I have selected AdcBitDepth=10. Note that on this screen I have selected PixelFormat=Mono12Packed. That sends a 2 12-bit pixels in 3 bytes, which is faster than sending 16-bit pixels in 4 bytes. I also selected ConvertFormat=Mono16, so it convert the 12-bit pixels to 16-bit pixels on the IOC computer, not in the camera. In those mode the maximum frame rate is almost 110 frames/s. I can't quite get that, but I do get 105 frames/s.

And yes this development is intended for use at 8.3.2 uT, though we are not sure if the camera is too noisy until we take real images. We've been using a slower camera (PCO), but less noisy.**

I am not sure you will actually see any difference in the noise of the Oryx and the PCO. The read-noise of the PCO is lower, but in most tomography experiments that makes absolutely no difference. The reason is that most tomography images are limited by the shot noise, not by the read noise. The full-well capacity of the Oryx is 10,435 e-, and the read noise is 2.31 e-. If you adjust the exposure time so that the air is almost saturating the camera (10,000 e-) then the shot noise in the air pixels is sqrt(10000)=100. So the noise in each pixel is 100 e-, or 1% of the signal. This is 43 times larger than the read noise, so the read noise it irrelevant in this case. If the most absorbing part of the sample absorbs 95% of the beam then the signal in that pixel will be 500 e-, and the noise in those pixels will be sqrt(500)=22.3 e-. This is still almost 10X more than the read noise. Only if the signal in a pixel is less than 10e- will the read noise be comparable to the shot noise.

In terms of dynamic range, which controls how many ADC bits you need, if we use the example of air=10000 e- and darkest pixel=500, then we need to capture the noise in the darkest pixels (22e-) and intensity of the brightest pixels (10000 e-). That is a dynamic range of 10000/22 = 455, which is just less than 9 bits. So a 10-bit ADC is plenty to capture the full dynamic range of those images.

[LeeYangLBLBCS]

Thanks a lot. I'll try the set up you suggested. Though I still have one more question: How and where are the images saved?

On Sun, Jul 26, 2020, 2:22 PM Mark Rivers notifications@github.com wrote:

If you are going to do tomography I would recommend these settings.

[image: image] https://user-images.githubusercontent.com/6115534/88489362-73334400-cf59-11ea-8481-3f2bf0aa31a7.png

On the Features#2 screen I have selected AdcBitDepth=10. Note that on this screen I have selected PixelFormat=Mono12Packed. That sends a 2 12-bit pixels in 3 bytes, which is faster than sending 16-bit pixels in 4 bytes. I also selected ConvertFormat=Mono16, so it convert the 12-bit pixels to 16-bit pixels on the IOC computer, not in the camera. In those mode the maximum frame rate is almost 110 frames/s. I can't quite get that, but I do get 105 frames/s.

And yes this development is intended for use at 8.3.2 uT, though we are not sure if the camera is too noisy until we take real images. We've been using a slower camera (PCO), but less noisy.**

I am not sure you will actually see any difference in the noise of the Oryx and the PCO. The read-noise of the PCO is lower, but in most tomography experiments that makes absolutely no difference. The reason is that most tomography images are limited b the shot noise, not by the read noise. The full-well capacity of the Oryx is 10,435 e-, and the read noise is 2.31 e-. If you adjust the exposure time so that the air is almost saturating the camera (10,000 e-) then the shot noise in the air pixels is sqrt(10000)=100. So the noise in each pixel is 100 e-, or 1% of the signal. This is 43 times larger than the read noise, so the read noise it irrelevant in this case. If the most absorbing part of the sample absorbs 95% of the beam then the signal in that pixel will be 500 e-, and the noise in those pixels will be sqrt(500)=22.3 e=. This is still almost 10X more than the read noise. Only if the signal in a pixel is less than 10e- will the read noise be comparable to the shot noise.

In terms of dynamic range, which controls how many ADC bits you need, if we use the example of air=10000 e- and darkest pixel=500, then we need to capture the noise in the darkest pixels (22e-) and intensity of the brightest pixels (10000 e-). That is a dynamic range of 10000/22 = 455, which is just less than 9 bits. So a 10-bit ADC is plenty to capture the full dynamic range of those images.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/areaDetector/ADSpinnaker/issues/3#issuecomment-664042211, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADSYGNGKVQ44U73Z4JNVD7TR5SNCNANCNFSM4PATGHCQ .

[MarkRivers]

You save the images with the areaDetector file plugins. On the medm screen go to Plugins/File. There are plugins to save files in HDF5, Nexus, netCDF, TIFF, JPEG, and other formats. For tomography you will want HDF5. You can configure the HDF5 file layout via an XML file. https://areadetector.github.io/master/ADCore/NDPluginFile.html. You can configure additional metadata to save with each file, or each image in the file, with another XML file.

[LeeYangLBLBCS]

I can save image to tiff file pluggin without much trouble. But when I tried HDF5, the contents is empty. here is my H5 screen shot: Can you see anything obviously wrong? Here is the content of a H5 file in HDF5View:

[MarkRivers]

That looks OK.

Please list the contents of that directory with “ls -l“. Also run the command “h5dump —header _abcdesss_22.h5” and show that output.

[LeeYangLBLBCS]

the file size is about 5MB. the output of h5dump is in attached file.

lyang@lyangUbuntu:~/images$ ls -l total 4940 -rw-r--r-- 1 lyang lyang 5043608 Jul 26 19:20 _abcdesss_22.h5

h5dump.txt

[MarkRivers]

ls -l and h5dump indicate that the HDF5 file is the right size, and contains the expected data in /entry/data/data. I think there is something wrong either with the HDF5Viewer itself, or with the way you are using it.

Try this command:

h5dump —dataset /entry/data/data _abcdesss_22.h5

That should dump the image data itself. No need to post all of it, just make sure the data looks reasonable.

[MarkRivers]

I just saved an HDF5 file using the following settings:

It displays fine with HDFView 2,14

It looks like the interface has changed a bit bettween 2.11 (yours) and 2.14 (mine). Perhaps you need to double-click on the filename or do something else to expand the view to show what is in the file?

[LeeYangLBLBCS]

the HDFview from ubuntu package is old (V2.11), and buggy. I downloaded directly from HDF group, V3.11. It shows the data. https://www.hdfgroup.org/downloads/hdfview/

On Mon, Jul 27, 2020 at 7:44 AM Mark Rivers notifications@github.com wrote:

I just saved an HDF5 file using the following settings:

[image: image] https://user-images.githubusercontent.com/6115534/88555256-2bf69300-cfed-11ea-8bbf-c2c9cc320057.png

It displays fine with HDFView 2,14

[image: image] https://user-images.githubusercontent.com/6115534/88555311-3f096300-cfed-11ea-8aa6-ff87e7b37343.png

It looks like the interface has changed a bit bettween 2.11 (yours) and 2.14 (mine). Perhaps you need to double-click on the filename or do something else to expand the view to show what is in the file?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/areaDetector/ADSpinnaker/issues/3#issuecomment-664439699, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADSYGNHU4WRHUCBBREB4UODR5WHC7ANCNFSM4PATGHCQ .

-- Lee Yang Lawrence Berkeley National Lab 1 Cyclotron Road, MS 7H210 Berkeley, California 97320 office:(510)486-7320 fax:(510) 486-4633

[LeeYangLBLBCS]

I moved this camera to a brand new computer. Duplicated everything I had on the older computer. I keep getting error with FLIR's spinview when I acquire an image: bug: (null) ((null):0, Begin acquisition) QIODevice::write (QFile, "SpinView_QT_log"): device not open Info: (null) ((null):0, Image incomplete with image status 9) QIODevice::write (QFile, "SpinView_QT_log"): device not open

Have you ever seen this?

I tried two different ethernet ports with the same error. When I tried to run MEDM, I see error: epics> 2020/08/06 21:10:59.228 ADSpinnaker::grabImage error GetImageStatus returned 9

I guess these errors must be correlated.

On Mon, Jul 27, 2020 at 10:45 AM Lee L. Yang llyang@lbl.gov wrote:

the HDFview from ubuntu package is old (V2.11), and buggy. I downloaded directly from HDF group, V3.11. It shows the data. https://www.hdfgroup.org/downloads/hdfview/

On Mon, Jul 27, 2020 at 7:44 AM Mark Rivers notifications@github.com wrote:

I just saved an HDF5 file using the following settings:

[image: image] https://user-images.githubusercontent.com/6115534/88555256-2bf69300-cfed-11ea-8bbf-c2c9cc320057.png

It displays fine with HDFView 2,14

[image: image] https://user-images.githubusercontent.com/6115534/88555311-3f096300-cfed-11ea-8aa6-ff87e7b37343.png

It looks like the interface has changed a bit bettween 2.11 (yours) and 2.14 (mine). Perhaps you need to double-click on the filename or do something else to expand the view to show what is in the file?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/areaDetector/ADSpinnaker/issues/3#issuecomment-664439699, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADSYGNHU4WRHUCBBREB4UODR5WHC7ANCNFSM4PATGHCQ .

-- Lee Yang Lawrence Berkeley National Lab 1 Cyclotron Road, MS 7H210 Berkeley, California 97320 office:(510)486-7320 fax:(510) 486-4633

-- Lee Yang Lawrence Berkeley National Lab 1 Cyclotron Road, MS 7H210 Berkeley, California 97320 office:(510)486-7320 fax:(510) 486-4633

[MarkRivers]

I am not sure the SpinView errors and the EPICS errors are related. The SpinView errors look like they are from QT, i.e. GUI related. The EPICS error could be data transmission related. Is this Linux or Windows? If Linux did you set those system parameters for Ethernet buffers on the new system?

[LeeYangLBLBCS]

It's linux, ubuntu 18.04Added /etc/sysctl.conf with these two lines:net.core.rmem_max=8388608 net.core.rmem_default=8388608

FLIR CAMERA model: ORX-10G-51S5M-C

[MarkRivers]

Did you reboot Linux after changing those settings? Did you read the current run-time values to make sure those values are what is currently in use?

[MarkRivers]

Is the camera using jumbo packets? That is in one of the camera specific screens. Have you enabled jumbo packets on your Ethernet card?

[LeeYangLBLBCS]

yes, jumbo. mtu=9000. enp13s0f1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000 inet 172.16.1.64 netmask 255.255.255.0 broadcast 172.16.1.255 inet6 fe80::20a:cdff:fe38:5df1 prefixlen 64 scopeid 0x20 ether 00:0a:cd:38:5d:f1 txqueuelen 1000 (Ethernet) RX packets 1380807 bytes 12319408894 (12.3 GB) RX errors 0 dropped 1001450 overruns 0 frame 0 TX packets 8813 bytes 574360 (574.3 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

I installed newer spinnaker v2.0. I can stream videos at 66 Hz with spinview. Then reverted back to v1.20. Can't acquire any image at all.

I think the older spinnaker v1.20 has some problems with newer computer hardware. Since I was able to make it work with MEDM on my older computer.

The newer version spinnaker v2.0 must have fixed some bugs. Maybe the improved Epics ADSpinnaker driver would work?

On Thu, Aug 6, 2020 at 11:43 PM Mark Rivers notifications@github.com wrote:

Is the camera using jumbo packets? That is in one of the camera specific screens. Have you enabled jumbo packets on your Ethernet card?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/areaDetector/ADSpinnaker/issues/3#issuecomment-670304933, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADSYGNG4L7SADXY3657ZV4DR7NZ7TANCNFSM4PATGHCQ .

-- Lee Yang Lawrence Berkeley National Lab 1 Cyclotron Road, MS 7H210 Berkeley, California 97320 office:(510)486-7320 fax:(510) 486-4633

[LeeYangLBLBCS]

I moved the ethernet port from 10G to 1G then it started to work. The same 10G card worked on the old computer but not the new one. Strange.

On Fri, Aug 7, 2020 at 1:03 AM Lee L. Yang llyang@lbl.gov wrote:

yes, jumbo. mtu=9000. enp13s0f1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000 inet 172.16.1.64 netmask 255.255.255.0 broadcast 172.16.1.255 inet6 fe80::20a:cdff:fe38:5df1 prefixlen 64 scopeid 0x20 ether 00:0a:cd:38:5d:f1 txqueuelen 1000 (Ethernet) RX packets 1380807 bytes 12319408894 (12.3 GB) RX errors 0 dropped 1001450 overruns 0 frame 0 TX packets 8813 bytes 574360 (574.3 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

I installed newer spinnaker v2.0. I can stream videos at 66 Hz with spinview. Then reverted back to v1.20. Can't acquire any image at all.

I think the older spinnaker v1.20 has some problems with newer computer hardware. Since I was able to make it work with MEDM on my older computer.

The newer version spinnaker v2.0 must have fixed some bugs. Maybe the improved Epics ADSpinnaker driver would work?

On Thu, Aug 6, 2020 at 11:43 PM Mark Rivers notifications@github.com wrote:

Is the camera using jumbo packets? That is in one of the camera specific screens. Have you enabled jumbo packets on your Ethernet card?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/areaDetector/ADSpinnaker/issues/3#issuecomment-670304933, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADSYGNG4L7SADXY3657ZV4DR7NZ7TANCNFSM4PATGHCQ .

-- Lee Yang Lawrence Berkeley National Lab 1 Cyclotron Road, MS 7H210 Berkeley, California 97320 office:(510)486-7320 fax:(510) 486-4633

-- Lee Yang Lawrence Berkeley National Lab 1 Cyclotron Road, MS 7H210 Berkeley, California 97320 office:(510)486-7320 fax:(510) 486-4633

[MarkRivers]

RX packets 1380807 bytes 12319408894 (12.3 GB) RX errors 0 dropped 1001450 overruns 0 frame 0

Note that it has recevied 1.3M packets and dropped 1.0M packets. That means something is very wrong, and it has nothing to do with Spinnaker or EPICS. You need to figure out why the network card is dropping about 50% of the incoming packets. See if you can copy large files back and forth between that new system and another computer over the 10Gbit interface and get close to the full bandwidth.

Is your new system running the same version of Ubuntu as the old system?

I think the older spinnaker v1.20 has some problems with newer computer hardware.

That is very unlikely. At the APS we are running Spinnaker v1.20 on at least 5 different hardware configurations, using Ubuntu 18, Centos 8, and RHEL 8.

I installed newer spinnaker v2.0. I can stream videos at 66 Hz with spinview.

If you put the camera in 8-bit mode with SpinView you should be able to stream 163 frames/s. Can you do that?