search

genicam / harvesters

Image Acquisition Library for GenICam-based Machine Vision System
Apache License 2.0
502 stars 86 forks source link

ia.destroy() is slow #312

Closed MasIgor closed 2 years ago

MasIgor commented 2 years ago

Hello all..

I am having a little problem: after i stop the image acquisition, i call ia.destroy(). unfortunately that takes 220 ms. Is there a way to speed that up? my program does not continue until this is done, and my available cycletime is 130 ms, so I cannot spend 220 ms to destroy the image aquirer...

Thank you!

Best regards

Igor

olofsjo1SICKAG commented 2 years ago

Why do you need to destroy the image acquirer on every cycle? I'm thinking you should be able to stay connected to the camera and use start/stop to control the acquisition or what does your use-case look like?

MasIgor commented 2 years ago

thanks for your answer @olofsjo.

my case is that I take a picture on every trigger over a extended period of time. yes you are right, I could stay connected.. but how do I detect if the camera has disconnected or has been unplugged?

olofsjo1SICKAG commented 2 years ago

As far as I know there is no way to detect a disconnect without polling the camera. But I might be wrong.

kazunarikudo commented 2 years ago

@tanzerlana Hi, could you please show me a piece of evidence that helps me to understand that the difference is coming from the Harvester versions so that I can investigate it further? I would need to know the specific names of the GenTL Producer and the camera. If possible, I would like to encourage you to try another GenTL Producer for comparison.

On the other hand, I admit there is a use case where the device is freely plugged/unplugged. However, such a feature must be implemented on the GenTL Producer side and as far as I know there is no standardized way as of today. Hence there is nothing Harvester can do. So I would recommend designing your application based on that fact.

(@olofsjo Hi Jonas, thank you for your kind help! I appreciate that!)

MasIgor commented 2 years ago

hello @kazunarikudo !

thank you for your answer! here is a screenshot of the time it takes. please note that the time is the total time from the beginning, so for instance the time it takes to destroy is "T Destroy - T stop acquisition".

image

the file I am using is this one: C:\Program Files\MATRIX VISION\mvIMPACT Acquire\bin\x64\mvGenTLProducer.cti'

and the camera is a genie nano C1920

Thank you!!

kazunarikudo commented 2 years ago

@tanzerlana Hi, thanks for the information. Could you show me another one with another version which you claim “it was faster”?

MasIgor commented 2 years ago

@kazunarikudo i think there is a misunderstanding.. i am not claiming that.. :) i simply say that for my needs it is slow, and am asking if it is possible to speed up. there was no faster version that i am aware of..

kazunarikudo commented 2 years ago

Thank you for the reply. I had interpreted that you were claiming Harvester turned slow at some point. So I was willing to try to find a hot spot where it makes the difference, i.e., it slows Harvester down. Please let me know if I am still misunderstanding the information you have provided.

Concerning the time that is consumed at the destroy call, Harvester is just calling a single GenTL function that closes a device handle. Just calling the function on the Producer side, nothing more. So it is clear that there must be an unnecessary set of procedures to close a device on the GenTL Producer side.

Would this explanation make sense for you?

kazunarikudo commented 2 years ago

As far as I tested, a non-standardized, pure proprietary simulator can close a virtual device so quickly (that is about a few milliseconds), but a real machine vision standard-compliant GenTL Producer + a device can take a few hundred milliseconds (it's about 300 ms). I hope the evidence helps you to have the right design for your application.

kazunarikudo commented 2 years ago

Hi again, Igor. Excuse me, since I had been busy releasing version 1.3.4, I misunderstood this ticket was triggered by the release.

MasIgor commented 2 years ago

thank you very much for your information. so it is not related to harvester.. thank you again and sorry for the time taken.

Best regards

Igor

kazunarikudo commented 2 years ago

Don't worry, Igor. Everything is fine. I understand there should be no information on your side as long as Harvester stays on the front-end. In principle, that would be great if we could react to unintentional plugged/unplugged events, and if the tear-down time turned almost 0 sec. Perhaps the first topic could be a chance for standardization in the future.