emit debug message when buffer clearing fails

[ckuethe]

At least this way I know when the trash frame exposures fail, and why... rather than getting a silent failure

[EricClaeys]

Thomas, I'm ok with this addition. At one point I had it in the code, but it's really not necessary since failure message(s) will already by written to the log when the buffer-clearing images fail.
Eric

[ckuethe]

It was not at all clear in the log files - even at debug level 4 - what error was occurring. This won't spam the logs with useless success messages.

[EricClaeys]

Chris, with this change the user will get two errors about ASI_ERROR_TIMEOUT during the buffer clearing images. One from takeOneExposure() ("ERROR: Failed getting image, status = ...") at line 468, and one from the loop of taking 3 buffer clearing images at line 1957.

[ckuethe]

Yes, that's intentional.

I prefer to see errors as they happen. Deciding to exit after too many errors is a different bit of logic, and there's no guarantee that all the errors will be the same.

Remember, I wasn't seeing timeouts at this stage, I was getting buffer clearing exposure 1 failed: -1 (Non-ASI ERROR). Sure, ASI_ERROR_TIMEOUT and non-ASI error are probably going to be the common cases, but ASI_ERROR_CAMERA_REMOVED or ASI_ERROR_INVALID_INDEX don't seem implausible in case of a bus reset or a device disconnection.

[EricClaeys]

Chris,
I've never seen the "Non-ASI ERROR" message before, and there are only two cases where it should happen:

1. if the 3rd argument (the image buffer) to takeOneExposure() is NULL.
2. If auto exposure is off and the returned exposure time is not what was requested. For example, you request a 10 second night shot but the camera took a 9-second shot. In this case, there would have been a message in the log saying "WARNING: not correct exposure (request: X us, actual: Y us, diff: Z)"

Do you know which of these caused your error? If the first, any idea why pRgb.data would be NULL?

[ckuethe]

Yes, it was caused by setting a 0x0 ROI (see #474).

I had specified 1280x960 in my config file, and that wasn't getting properly processed, which led to the default 0x0 being passed in. This put the SDK/camera into a very confused state, and since the return code from ASISetROIFormat wasn't being checked, further operations would fail with Non-ASI errors.

To help detect similar failures in the future, I intentionally log the image ROI if SetROI fails. :)

[EricClaeys]

This change looks good.