Exposure Time is not controllable with a Basler Camera

[eddybl]

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?

[MarkRivers]

The documentation in the Basler list of changes says there should be a Float feature called ExposureTime. However, arv-tool shows that there is not. You should ask them why.

This is a search for the string Name="ExposureTime in a Point Grey xml file.

corvette:areaDetector/ADGenICam/xml>xmllint --format temp.xml | grep 'Name="ExposureTime'
  <Float Name="ExposureTime" NameSpace="Standard">
  <Float Name="ExposureTimeAbs" NameSpace="Custom">

Note that it has a feature called ExposureTime, and also one called ExposureTimeAbs.

The existing Basler files have these entries:

corvette:areaDetector/ADGenICam/xml>grep '<Float Name="ExposureTime' Basler*.xml
Basler-acA1300-30gm.xml:  <Float Name="ExposureTimeAbs" NameSpace="Standard">
Basler-acA2000-50gmNIR.xml:  <Float Name="ExposureTimeAbs" NameSpace="Standard">
Basler-acA2040-35gm.xml:  <Float Name="ExposureTimeAbs" NameSpace="Standard">
Basler-acA2440-20gm.xml:  <Float Name="ExposureTimeAbs" NameSpace="Standard">
Basler-scA1300-32gm.xml:  <Float Name="ExposureTimeAbs" NameSpace="Standard">
Basler-scA1300-32gm.xml:  <Float Name="ExposureTimeBaseAbs" NameSpace="Standard">
Basler_piA640_210gm.xml:  <Float Name="ExposureTimeAbs" NameSpace="Standard">
Basler_piA640_210gm.xml:  <Float Name="ExposureTimeBaseAbs" NameSpace="Standard">

Note that none of them have a Float feature called ExposureTime, but they all have a feature called ExposureTimeAbs. Your new camera is the same.

This should be fine because ADGenICam maps either ExposureTime or ExposureTimeAbs to the ADAcquireTime parameter:

    // Make a single parameter that maps to either ExposureTime or ExposureTimeAbs
    features = {{"ExposureTime",    GCFeatureTypeDouble},
                {"ExposureTimeAbs", GCFeatureTypeDouble}};
    createMultiFeature(ADAcquireTimeString, asynParamFloat64, ADAcquireTime, features);

It never does anything with ExposureTimeRaw.

So I don't understand why this is not working for your camera, since you do have ExposureTimeAbs, and contrary to their documentation, you do not have ExposureTime.

[MarkRivers]

@eddybl I think I may understand why setting the AcquireTime has no effect on the camera. Many cameras have an ExposureTimeAuto feature which automatically sets the exposure time, and overrides any value you set. Are you sure that you have disabled ExposureTimeAuto?

Another possibility is that FrameRate is enabled and its setting will not allow the exposure time you have requested.
For example, AcquireTime=0.1 and FrameRate=20 are not compatible, and frame rate may take priority.

There may be some other feature that also automatically controls the exposure time. Look through the camera-specific OPI screens carefully.

[MarkRivers]

Any progress on this?

[AbdallaDalleh]

@eddybl I think I may understand why setting the AcquireTime has no effect on the camera. Many cameras have an ExposureTimeAuto feature which automatically sets the exposure time, and overrides any value you set. Are you sure that you have disabled ExposureTimeAuto?

Another possibility is that FrameRate is enabled and its setting will not allow the exposure time you have requested. For example, AcquireTime=0.1 and FrameRate=20 are not compatible, and frame rate may take priority.

There may be some other feature that also automatically controls the exposure time. Look through the camera-specific OPI screens carefully.

I would like to confirm this, we faced it with the acA1300-30gm model. We eventually disabled auto exposure and disabled frame rate and controlled the camera through exposure time only (as the application required) with frame rate calculated as expected from exposure time. Could there be something on the network level? Like jumbo frames? it used to be an issue on some Basler models like the scout...

[MarkRivers]

Could there be something on the network level? Like jumbo frames? it used to be an issue on some Basler models like the scout...

I think a network issue like jumbo frames would only affect streaming data, not whether the camera accepts the exposure time value.

[eddybl]

Sorry for the delay, I was sick and afterwards on Holidays

I would like to confirm this, we faced it with the acA1300-30gm model. We eventually disabled auto exposure and disabled frame rate and controlled the camera through exposure time only (as the application required) with frame rate calculated as expected from exposure time. Could there be something on the network level? Like jumbo frames? it used to be an issue on some Basler models like the scout...

Thanks for the tip regarding the frame rate disabling, this is one option we might not have tried yet. I will give it a try on the next opportunity. We want to acquire one image per second based on an external hardware trigger, so only using the exposure time should be enough.

Edit: Still confusing though that setting the exposure time via the Basler software works as expected even with frame rate on etc.

[AbdallaDalleh]

If you want priority for exposure time you should set its auto to Off, that way it will calculate frame rate from exposure time. If it is set to continuous, if I understand correctly it will calculate exposure time from frame rate assuming frame rate is enabled. This is what is working for us:
Control using exposure time: Exposure auto = OFF | Frame rate enable = NO
Control using frame rate: Exposure auto = Continuous | Frame rate enable = Yes

[MarkRivers]

If it is using a hardware trigger then the frame rate should be ignored.

[MarkRivers]

@eddybl if you are still having problems please post a screen shot of the main ADAravis.adl screen, and each of the camera-specific screens.

[eddybl]

Ok, so the issue still persists: Chaning the exposure time via EPICS does not have an effect on the camera.

Here are some screenshots https://bwsyncandshare.kit.edu/s/sSry8fnm3KxxFiN

• GeniCam.png is the panel we typically use
• Basler1-4.png are the basler specific panels (although not for this camera model)
• PylonViewer.png is the relevant part from the Basler software

What I did:

1. Switched on continoues image taking, but with an external 1 Hz hardware trigger
2. Switched on Auto Exposure, this changed the expusre time to 0.035 s (Exposure-35.png is the picture with 0.035 s)
3. Switched off Auto Exposure
4. Tried to lower Exposure to 0.001
5. The acquired images where still with 0.035 s expsoure

If I restart the IOC, it also reads back the "correct" exposure time (0.001 s), and also using the Basler Software (PylonViewer.png) shows the exposure time which I set via EPICS, but the picture is still acquired with 0.035 s. I will need to change the exposure time in the basler software to have an effect.

Edit: I was wondering if I could possibly try to have a minimal working example using a Python script to directly set the exposure time to the baser camera without EPICS, could this be done? This would finally make clear if it is an aravis/EPICS problem or a basler problem

[MarkRivers]

Why did you not show the camera specific screens for the model you are using? The camera model reported in ADGenICam.adl is acA192025gm. However, the screens you are using are for the acA1300-30gm. That may be why many of the readbacks are undefined? You should really use the screens for the correct camera model.

Also, what top-level screen are you using? If you are using ADAravis then you should use ADAravis.adl as the top-level screen.

In Features Screen #1 it shows the readbacks for ExposureTimeAbs=.001 and ExposureTimeRaw=1000. Those are correct for 0.001 exposure time. Do those values update correctly if you change AcquireTime to 0.005 on ADGenICam.adl. If those readbacks are correct for your camera model then that means that EPICS is correctly setting them.

[eddybl]

Sorry, that is my mistake. I created the records a long time ago and forgot that there is also the option to create the medm panels via script.

Since I am interested in the OPI screens, is this still the way to do that? https://epics.anl.gov/tech-talk/2017/msg01913.php

[MarkRivers]

Since I am interested in the OPI screens, is this still the way to do that? https://epics.anl.gov/tech-talk/2017/msg01913.php

To do the conversions to other OPIs you can just run "make" in GenICamApp/op.

For that to work you need RULES_OPI from here:
https://github.com/EPICS-synApps/support/blob/master/configure/RULES_OPI

You also need to uncomment some lines in this file:
https://github.com/EPICS-synApps/support/blob/master/configure/CONFIG_SITE.linux-x86_64

I have done the conversions to edl, ui, opi, and bob files for the 3 Basler cameras you added.

[eddybl]

Thanks!

So even with the proper panels there seems to be roughly the same amount of channels where the readback is UDF invalid and also directly processing these channels does have no effect.

But I agree in general, it does look like EPICS is doing its job correctly. If I find some time I will try to play around with one of our spare basler cameras and maybe I can figure out if it is maybe firmware dependent...

[MarkRivers]

In Features Screen #1 it shows the readbacks for ExposureTimeAbs=.001 and ExposureTimeRaw=1000. Those are correct for 0.001 exposure time. Do those values update correctly if you change AcquireTime to 0.005 on ADGenICam.adl. If those readbacks are correct for your camera model then that means that EPICS is correctly setting them.

What do you observe for these when you change AcquireTime?

Please post a screen shot of ADAravis screen.