Stop acquisition when pixel format is changed

[LeeHudsonDLS]

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.

[MarkRivers]

This seems like a good idea. Some other areaDetector drivers stop acquisition when certain parameters are changed, and restart after. I have not done a study to see which GenICam features can be changed without stopping the camera and which cannot. We should probably stop and restart for all features that require it.

[thomascobb]

aravisGigE used to stop then restart whenever the geometry (binx, biny, minx, miny, sizex, sizey), colorMode or dataType were changed. Basically anything that would change the number of bytes in an image

[LeeHudsonDLS]

I'm don't mind looking into this, i'll take a look at how aravisGigE behaves.

[MarkRivers]

Thanks. I would suggest doing some empirical studies with ADAravis to see what features can be changed without stopping (Gain, AcquireTime, AcquirePeriod, etc?) and which cannot (BinX/Y, MinX/Y, PixelFormat, etc?). This may be documented in the GenICam specification, I'm not sure.

[LeeHudsonDLS]

Ok i'll do some tests and look at the specification

[MarkRivers]

This issue is fixed with 497265d4bfff818773809a6a376f96b1d7b51193.

I added new pauseAcquisition() and resumeAcquisition() methods.

• pauseAcquisition() calls stopCapture() if ADAcquire is 1.
• resumeAcquisition() calls startCapture() if pauseAcquisition() called stopCapture().

If any of the following parameters are changed then pauseAcquisition() is called, the parameter is changed, and then resumeAcquisition is called().

• ADMinX, ADMinY
• ADSizeX, ADSizeY
• ADBinX, ADBinY
• ADNumImages
• GCPixelFormat

[LeeHudsonDLS]

Hi Mark, I've pulled you latest changes along with this commit to test out the pauseAcquisition() and resumeAcquisition() behaviour and it doesn't appear to be doing what i'd expect.

When I change the pixel format via ":GC_PixelFormat" I see writeInt32 is called as expected but the pasynUser->reason it's called with doesn't appear to be "GCPixelFormat" which you are checking for. When I do an asynReport I see there are 2 parameters that are related to pixel format:

Parameter 102 type=asynInt32, name=GC_PIXEL_FORMAT, value=35127316, status=0 Parameter 267 type=asynInt32, name=GC_E_PixelFormat, value=35127316, status=0

The ":GC_PixelFormat" record uses GC_E_PixelFormat whereas you're looking for GC_PIXEL_FORMAT in the writeInt32 method.

What's the difference between these two asyn parameters? Should I be changing the pixel format via $(P)$(R)PixelFormat rather than $(P)$(R)GC_PixelFormat?

[MarkRivers]

Should I be changing the pixel format via $(P)$(R)PixelFormat rather than $(P)$(R)GC_PixelFormat?

Yes, you should. $(P)$(R)PixelFormat is an abstraction. It is guaranteed to exist, while $(P)$(R)GC_PixelFormat is not. $(P)$(R)PixelFormat will normally map to the GenICam PixelFormat feature, but if we find some camera that uses a different feature name that will be hidden from the user.

$(P)$(R)PixelFormat is what is exposed in all of the main OPI files (ADAravis.adl, ADGenICam.adl). $(P)$(R)GC_PixelFormat is only exposed in the camera-specific Features OPI screens.

The same is true for the other records that will pause acqusition (SizeX/Y, MinX/Y, BinX/Y, NumImages). Acquisition will be paused and restarted if, for example, $(P)$(R)MinX is changed but not if the underlying feature $(P)$(R)GC_OffsetX is changed.

[LeeHudsonDLS]

Ah I understand, thanks for the clarification, i'll give that a try.

[LeeHudsonDLS]

I tested this last week and did some more testing this morning. I'm seeing the occasional camera crash when changing the pixel format during an acquisition. The camera i'm using is an AVT Manta G-235C. The only way to recover is to power cycle the camera.

The most repeatable way to make the camera crash is change the pixel format twice without manually stopping the acquisition.

It would appear there needs to be some delay between setting setting the pixel format and resuming acquisition. I've tried a usleep of 0.1 second and this appear to prevent the crash as far as I can tell. I would imagine this delay isn't ideal (is writeInt32 in the main thread?). Could we perhaps check if the parameter has been accepted by the camera? Have you seen this behaviour?

[MarkRivers]

I have not see that behavior, but I may have only tested on Point Grey cameras. I suggest that you find the minimum time that works reliably and we will use that.

I don't think a small delay will be a problem. writeInt32 is being run in the asyn port thread (created by asynManager) specifically to allow slow operations not to affect the rest of EPICS. That is true as long as the port is created with ASYN_CANBLOCK, which ADGenICam does.

[LeeHudsonDLS]

Ok great, i'm just waiting for someone on site to power cycle the camera as i'm working from home. Once i've got a robust figure for what I can test with i'll do a pull request.

[MarkRivers]

Sounds good. At the start of the Covid shutdown I bought one of these units for my office:

https://www.amazon.com/Web-Power-Switch-Pro-Model/dp/B0765NCB2L/ref=sr_1_3?keywords=ethernet+controlled+power+strip&qid=1585318178&sr=8-3

It's great, I can individually power-cycle up to 8 devices from home. It's something I've needed for a long time, because I was frequently asking if anyone was around on the weekend to help me power-cycle a device I was working on.

[LeeHudsonDLS]

Sounds like a good idea. The only camera I have access to is POE and gets it power via a rack mount POE injector. Perhaps this has some remote switching functionality.