Implemented AcquisitionFrameCount on Fake-camera

[LorenzoBalducci96]

The first frame is immediately taken, but maybe is correct to wait the framePeriod also on the first frame?

[EmmanuelP]

Fake camera should stick to the behavior describe in the Genicam SNFC document: https://www.emva.org/wp-content/uploads/GenICam_SFNC_v2_7.pdf

[LorenzoBalducci96]

Hi thanks for the interest.

From the Genicam SNFC document I read: "AcquisitionFrameRate controls the rate at which the Frames are captured when TriggerMode is Off.". So it seems that this parameter must be taken into account when not using triggered mode acquisition. (so I guess it defines the framerate when acquisitionMode is continous). So it should be correct to not take into account the framerate when sending multiFrames in triggered mode and send frames immediately as soon as are available in the fake-camera?. However in basler aca1920-50gm/c you can set the AcquisitionFrameRateAbs parameter when acquiring multiFrame in triggered mode and it will define the framerate of the frames acquired after a trigger. Maybe basler cameras are slightly out of specification?

"the counter is not reset at every AcquisitionStart" in arv_fake_camera_check_and_acknowledge_software_trigger when the trigger is acknoledged the frameCount is reset to 1 and is increased every new frame. Since the frameCount is smaller than AcquisitionFrameCount register the arv_fake_camera_check_and_acknowledge_software_trigger still returns true meaning that a new frame must be taken (the trigger was already acknoledged at first frame). Once the acquisitionFrameCount is reached, the frameCount is set to 65535 in order to be bigger than any other acquisitionFrameCount that could be set before the next trigger causes the reset of the frameCount. Do you propose a better solution?

every other notes are for shure reasonable for the next commit.

[EmmanuelP]

From the Genicam SNFC document I read: "AcquisitionFrameRate controls the rate at which the Frames are captured when TriggerMode is Off.". So it seems that this parameter must be taken into account when not using triggered mode acquisition. (so I guess it defines the framerate when acquisitionMode is continous). So it should be correct to not take into account the framerate when sending multiFrames in triggered mode and send frames immediately as soon as are available in the fake-camera?.

Yes.

However in basler aca1920-50gm/c you can set the AcquisitionFrameRateAbs parameter when acquiring multiFrame in triggered mode and it will define the framerate of the frames acquired after a trigger. Maybe basler cameras are slightly out of specification?

Most camera manufacturers don't strictly stick to the SNFC, mostly because they started the work on their firmware and SDK before the SNFC even exists.

"the counter is not reset at every AcquisitionStart" in arv_fake_camera_check_and_acknowledge_software_trigger when the trigger is acknoledged the frameCount is reset to 1 and is increased every new frame. Since the frameCount is smaller than AcquisitionFrameCount register the arv_fake_camera_check_and_acknowledge_software_trigger still returns true meaning that a new frame must be taken (the trigger was already acknoledged at first frame). Once the acquisitionFrameCount is reached, the frameCount is set to 65535 in order to be bigger than any other acquisitionFrameCount that could be set before the next trigger causes the reset of the frameCount. Do you propose a better solution?

There is no reason to couple AcquisitionFrameCount and TriggerSoftware, they are unrelated. AcquisitionFrameCount is here to set the number of acuiqred frames when AcuisitionMode is set to MultiFrame, wether the camera is free running or triggered.