alliedvision / VimbaPython

Old Allied Vision Vimba Python API. The successor to this API is VmbPy
BSD 2-Clause "Simplified" License
93 stars 40 forks source link

Long delay between SW trigger and handler function. #162

Open alexdesion opened 1 year ago

alexdesion commented 1 year ago

Hello.

I am using 2 allied vision cameras with must be triggered by SW at the same time. In order to do this I have the following code:

The issue is related the big delay between the call to the SW trigger of each camera

                    if not picture_producer_1_taken:
                        self.producer_1.cam.TriggerSoftware.run()
                        self.logger.info(
                            f"Consumer trigger cam 1 at {datetime.utcnow().strftime('%Y-%m-%d %H:%M:%S.%f')[:-3]}")

                    if not picture_producer_2_taken:
                        self.producer_2.cam.TriggerSoftware.run()
                        self.logger.info(
                            f"Consumer trigger cam 2 at {datetime.utcnow().strftime('%Y-%m-%d %H:%M:%S.%f')[:-3]}")

and the execution of the handler function on each producer

    def handler(self, cam, frame):
        self.logger.info(
            f"Producer cam {self.camera_name} started frame queueing at {datetime.utcnow().strftime('%Y-%m-%d %H:%M:%S.%f')[:-3]}")
        cam.queue_frame(frame)
        self.queued_frame = frame
        self.logger.info(
            f"Producer cam {self.camera_name} queued frame at {datetime.utcnow().strftime('%Y-%m-%d %H:%M:%S.%f')[:-3]}")

I added some prints in the code to really see how big this delay is. Here is the output: 2023-05-22 13:52:44,823 | INFO | Consumer received event at 2023-05-22 11:52:44.823. 2023-05-22 13:52:44,825 | INFO | Consumer trigger cam 1 at 2023-05-22 11:52:44.825. 2023-05-22 13:52:44,828 | INFO | Consumer trigger cam 2 at 2023-05-22 11:52:44.828. 2023-05-22 13:52:45,114 | INFO | Producer cam cam1 started frame queueing at 2023-05-22 11:52:45.114. 2023-05-22 13:52:45,114 | INFO | Producer cam cam1 queued frame at 2023-05-22 11:52:45.114. 2023-05-22 13:52:46,187 | INFO | Producer cam cam2 started frame queueing at 2023-05-22 11:52:46.187. 2023-05-22 13:52:46,187 | INFO | Producer cam cam2 queued frame at 2023-05-22 11:52:46.187. 2023-05-22 13:52:46,188 | INFO | Consumer queued frames are not None anymore at 2023-05-22 11:52:46.188.

As you can see, on cam1 that delay is about 300 ms from 11:52:44.825 to 11:52:45.114. On cam2 is way bigger, about 1.4 secons from 11:52:44.828 to 1:52:46.187.

What is the reason of this delay? The dalay is not caused because having 2 cameras. If I try only with one of them, it keeps constant 300 ms for cam1 and 1.4s for cam2. Both cameras are the same model, Alvium G5-500c.

Btw, trigger delay parameter is set to 0 in both cameras.

Teresa-AlliedVision commented 1 year ago

Do you check the timestamp of the frame object (frame.timestamp)? This shows the time of when the camera started exposing the sensor, it is essentially the time of the start of the frame. That would be helpful to see: Is the delay between triggering and exposing the frame or between the start of exposure and receiving the frame. What are the settings of the cameras and how are they conneced to the PC? If the delay is always the same for each camera, then I would either assume, that the cameras are set to a long exposure time and/or that the network settings aren't optimized and a lot of resends happen. The resends should lead to variable delays, so I would also check the feature "DeviceLinkThroughputLimit". This is the data rate of the camera in Bytes/s and should be at about 80% to 95% of the maximum, to leave some bandwidth for resends.

alexdesion commented 1 year ago

Thanks for your reply @Teresa-AlliedVision

I checked the time stamp of the frame inside the handler function (where I can access it).

self.logger.info(
            f"Producer cam {self.camera_name} started frame queueing at {datetime.utcnow().strftime('%Y-%m-%d %H:%M:%S.%f')[:-3]}"
            f"\n\tFrame timestamp {frame.get_timestamp()}")

And here is the output for the more delayed camera:

2023-05-23 14:00:11,275 | INFO | Consumer trigger cam 2 at 2023-05-23 12:00:11.275 2023-05-23 14:00:12,630 | INFO | Producer cam alliedV_spread_cam2 started frame queueing at 2023-05-23 12:00:12.630 Frame timestamp 2461762152200

I am not sure of how compare this timestamp with the time trigger starts.

Regarding the other topic: