It would be good to have PVs containing the current minimum and maximum for numeric GenICam features. These could also potentially be propagated to the DRVL and DRVL fields of the records for GenICam features, and perhaps the abstract records as well.

Perhaps the GenICam Implemented flag could also be added which could even set the record alarm state to INVALID.

This would not be too hard to implement. The Python script could automatically generate the _MIN, _MAX, and _VALID records. The parameter library would have 2 or 3 more entries for each GenICam parameter. ADGenICam would write these values to the parameter library as it does with the VAL field each time the features are read.

Hi,
I'm not sure if this is intended behaviour but I noticed that setting the :ColorMode PV (from ADCore, NDArrayBase.template) to the desired mode no longer propagates though to the camera via :GC_PixelFormat. This results in this PV doing nothing with the camera. Is this correct?

Hi,
I noticed a difference in behaviour between aravisGigE and ADGenICam/ADAravis in terms of autosave that I think is undesirable. I've found that aravisGigE used to pull the ADCore PV values (like image size, gain etc) from the camera if an autosave file isn't found whereas ADGeniCam uses the database as the master in this instance. The values in the database don't normally make sense and result in the setting in the camera being overwritten. Is this intentional behaviour? Is it related to https://github.com/areaDetector/ADGenICam/issues/3

Currently ADGenICam::writeInt32 calls start_capture() even if the camera is already acquiring:

This is causing memory leaks in ADAravis, and perhaps other drivers. There should be a check before calling start_capture() or stop_capture() to make sure the camera is in the correct state.

Camera xml files with "string" features generate errors:

(base) corvette:~/devel/areaDetector/ADGenICam>addCamera.sh Allied_Vision_1800_U-811m
Don't know what to do with String
Don't know what to do with String
Don't know what to do with String
Don't know what to do with String
Don't know what to do with String
Don't know what to do with String
Don't know what to do with String

Support for string features needs to be added.

Hey,

so first of all I think this issue might be related to areaDetector/ADAravis#14 and #23

We recently added a new Basler Camera (acA1920-25gm), the first of its type for us. So we got the XML file to set up the .template file etc.
It also mostly works, but at some point we realized that we cannot set the Exposure Time. We can set it and also the readback value changes, but it has no effect on the camera.

It comes basically down to these two records which are part of the auto-generated .template file:

record(ao, "$(P)$(R)GC_ExposureTimeAbs") {
  field(DTYP, "asynFloat64")
  field(OUT,  "@asyn($(PORT),$(ADDR=0),$(TIMEOUT=1))GC_D_ExposureTimeAbs")
  field(PREC, "3")
  field(DISA, "0")
}
record(ao, "$(P)$(R)GC_ExposureTimeRaw") {
  field(DTYP, "asynInt64")
  field(OUT,  "@asyn($(PORT),$(ADDR=0),$(TIMEOUT=1))GC_I_ExposureTimeRaw")
  field(DISA, "0")
}

With arv-tool-0.8 -n "Basler-acA1920-25gm-***" features | grep -i ExposureTime I get:

Float       : 'ExposureTimeAbs'
Integer     : 'ExposureTimeRaw'
    EnumEntry   : 'ExposureTime'
Float       : 'ChunkExposureTime' (Not available)
Float       : 'AutoExposureTimeAbsLowerLimit'
Float       : 'AutoExposureTimeAbsUpperLimit'

We did not have any issues with previous basler cameras, but it seems like this Camera actually runs on Firmware 4.X, whereas our older cameras run on Firmware 3.7.
I also created an issue with Basler support about this. Part of the relevant response was:

One issue might be the parameter name, “ExposureTimeRaw” is considered deprecated and should be replaced by “ExposureTime”:
https://docs.baslerweb.com/pylonapi/cpp/pylon_advanced_topics#list-of-changes

Is there anything else I can try?

Hi, I've been working with updating IOCs based on the deprecated aravisGigE to the new ADGenICam and ADAravis support modules. During initial tests with the new modules, I noticed a significant delay time to get PVs responsive (regarding their set-point and read-back values) at IOC boot. Have you noticed this already?

To get an insight on what was going on, I run the IOC under Linux Perf profiling tool. From about 106 seconds the driver thread (the one named after the port name) takes to start up, about 57 secs (~53%) is collectively taken by readAll calls, called both by writeInt32 and writeFloat64 functions.

The side-effect of this is having the parameter library frozen (due to the global lock being taken?) and PVs being unresponsive for about a minute. I'm thinking these write calls are being triggered during the database initialization, leading to processCallbackOutput calls. However, I'm not certain of that. Does it make sense?

As far as I understand, the rationale here to readAll after these writes is to synchronize parameter library with the camera registers, since its firmware may update one register based on the other, right? Could we delay them until all these sequential writes are performed or coalesce readAll requests to minimize these synchronizations and improve performance?

I may provide more information about the setup I tested it and the profiling data I gathered, if needed.

I'd like to work on this to have it improved. Some insights on the best path to go are pretty much appreciated.

Hi,
I don't know if this is a reasonable request but a user as requested the added behavior of stopping the camera acquiring when the pixel format is changed and then starting this again. I'm happy to look into this but I wanted to check if it was a sensible thing to do.

I'm trying out the implementation of the 12 bit data unpacking

It seems that the result will be 12 bits of data occupying bits 15:4 of the uint16 data type, and with 3:0 zeroed out. This is comparable to the Mono16 data type that these cameras are able to produce. My user working with FLIR BFS-PGE-70S7M would prefer to see unpacked 12 bits rather occupy 11:0 of the uint16 data type, with 15:12 zeroed out. On our side, we are assuming that the pixel data should always be non-negative; is this appropriate to expect?

I'm using this IOC startup directive:

dbLoadRecords("NDStdArrays.template", "P=$(PREFIX),R=image1:,PORT=Image1,ADDR=0,TIMEOUT=1,NDARRAY_PORT=$(PORT),TYPE=Int16,FTVL=SHORT,NELEMENTS=$(NELEMENTS)")

One thing that bothered my user was having bit 15 used for pixel data, with 12 bit relevant payload. This resulted in EPICS clients getting waveform with signed 16 bit values where bit 15 would flip the sign interpreted by Matlab as negative pixel value. His Matlab code would have to treat arriving data as int16 then shift the pixel value 4 bits to the right to get into 12 range and avoid 'negative' value pixel values. Maybe I'm doing something wrong but, I can not get the waveform to hold unsigned 16 bit values; it seems that asyn layer with the asynInt16 data type is the reason. IOW, changing FTVL=SHORT to FTVL=USHORT has no effect. Is this expected? I know that going 32 bits from the IOC -> DB -> client makes this a non-issue but it feels an overkill in data overhead, for my taste at least.

Is the use of higher bits a standard way of transporting the pixels (i.e. do other devices do this)?

With the current implementation how does using IOC "shift left" PV with 12 bit data type result in valid pixel values? I guess it should be always set to 'no' shift, but then again, it is possible to perform the shift only if the pixel format is not 8 or 16 bits.

For reference, here is the change that makes my user happy:

diff --git a/GenICamApp/src/ADGenICam.cpp b/GenICamApp/src/ADGenICam.cpp
index 5f84c7d..870b9fe 100755
--- a/GenICamApp/src/ADGenICam.cpp
+++ b/GenICamApp/src/ADGenICam.cpp
@@ -553,8 +553,10 @@ void ADGenICam::decompressMono12Packed(int numPixels, epicsUInt8 *input, epicsUI
     int i;
 
     for (i=0; i<numPixels/2; i++) {
-        *output++ = (*input << 8) | ((*(input+1) & 0x0f) << 4);
-        *output++ = (*(input+1) & 0xf0) | (*(input+2) << 8);
+        *output++ = ((epicsUInt16)((*input << 4) | (*(input+1) & 0x0f))) & 0x0FFF;
+        *output++ = ((epicsUInt16)(((*(input+1) & 0xf0) >> 4) | (*(input+2) << 4))) & 0x0FFF;
         input += 3;
     }
 }

With this the EPICS clients get to see lowest 12 bits of the 16 bit data type occupied with pixel data. No more negative pixel values. A (nice) side effect is that, for example, the statistics plugin is now showing proper pixel values in 12 bit range. Also, Matlab code does not have to do any data manipulation either as pixel can not get negative. An OPI with intensity XY plot also looks better now.

What do you think?

I know certain GenICam parameters have set min and max values, and I was wondering if the database files generated by ADGenICam support assigning limits to the PV values entered for these parameters, and if it doesn't yet, would it be possible?

I believe these min/max values are listed as pMin and pMax tags in the xml:

ADGenICam reads back all features from the camera, including the enum strings and values for enum features, under 2 circumstances:

• When writing the value to any feature in the camera. This is done because writing to one feature (e.g. PixelFormat) can affect the availability or enum choices of other features.
• When periodically polling, so that the values of things like temperature, frame error statistics, power supply voltages, etc. are updated.

This is working fine, except for an issue with performance with aravis. The following table compares the times to read all of the features on a number of cameras, using both ADAravis (aravis SDK) and ADSpinnaker (FLIR Spinnaker SDK).

Note that for USB3 aravis is very fast, only 85 ms to poll all of the features. However, for the GigE cameras it is 7-40 times slower than Spinnaker, and for the 10 GigE camera it is 210 times slower. On the Oryx changing a single feature like Gain introduces a delay of 11.8 seconds before the camera can be streaming again. This is not acceptable.

Questions:

• Is the Spinnaker performance so good because it is caching features in the SDK and reading them is just reading the cached values?
• With aravis is it possible to get a list of the other features that have changed in response to changing one feature? If so then only those features would need to be read when changing the feature?

The attached text file shows the debugging trace when reading the features. It is the data used in compiling the table above.

FeaturePollPerformance.txt

GenICam integer features are 64-bit integers. However, the ADGenICam GenICam feature class declares these pure virtual methods:

   virtual int readInteger(void) = 0;
   virtual int readIntegerMin(void) = 0;
   virtual int readIntegerMax(void) = 0;
   virtual int readIncrement(void) = 0;
   virtual void writeInteger(int value) = 0;

This limits the range of such features to 32-bits, rather than the full 64-bit range that the camera may be using.

This has been shown to be an issue, for example, with the ChunkTimestamp feature on FLIR cameras, and likely on a number of other features on other cameras.

Mark, thanks for adding support for GainRaw in R1-8. This was exactly what I needed to support our old cameras.

But I found that it didn't quite work for our cameras, as the GenICam feature datatype for this parameter appears to be a float.
Here is one example:
$ bin/arv-tool-0.4 -n "Allied Vision Technologies-50-0503321242" features | grep -i gain
Category: 'Gain'
Enumeration: 'GainSelector'
Float: 'GainRaw'
...

This causes a failed type conversion and the driver to print the following error messages:
2021/08/09 13:37:41.583 VimbaFeature::VimbaFeature error input feature type=0 != Vimba feature type=3 for featurename=GainRaw
2021/08/09 13:37:41.583 VimbaFeature:readInteger: ERROR calling GetValue error=-10
As a result the gain can't be set or read correctly.

If I change the feature datatype to a double it fixes the problem:

$ git diff GenICamApp/src/ADGenICam.cpp
diff --git a/GenICamApp/src/ADGenICam.cpp b/GenICamApp/src/ADGenICam.cpp
index 073b03f..91a1a86 100755
--- a/GenICamApp/src/ADGenICam.cpp
+++ b/GenICamApp/src/ADGenICam.cpp
@@ -511,7 +511,7 @@ asynStatus ADGenICam::addADDriverFeatures()
 
     // Make a single parameter that maps to either Gain, GainRaw, or GainRawChannelA
     features = {{"Gain",            GCFeatureTypeDouble},
-                {"GainRaw",         GCFeatureTypeInteger},
+                {"GainRaw",         GCFeatureTypeDouble},
                 {"GainRawChannelA", GCFeatureTypeInteger}};
     createMultiFeature(ADGainString, asynParamFloat64, ADGain, features);

So are there cameras out there that actually use an integer type for GainRaw?
I found three cameras of ours that are old enough to use GainRaw and they are all floats.
They are all Manta G033B cameras with FW versions 00.01.42.00 or 00.01.44.00.

I can submit a PR if you agree that this change makes sense.
If different cameras use different datatypes for this parameter, how do we deal with this?

Thanks,
Mike Dunning
SLAC