Open alan-zhan opened 1 year ago
Hello Alan, I'm assuming you are using a Manta, please correct me if I'm wrong. Try a firmware update first, just to get it out of the way and if you are not using Vimba6, I would also recommend to update that. The error -19 means "The current operation was not completed", which could hint to an issue in the firmware of the camera or an issue with the settings. And the traceback hints to a problem with feature discovery. Also, Synchronous Grab is not a very efficient way of acquiring frames, so if it is feasable, I would recommend an asynchronous frame grab. See if the issue also arises, when you stream with one of the asynchronous Python examples or with the Vimba Viewer as a test. Regarding communication issues, do you have any checks to see if and how many frames are received at the host? Does it make a difference (with the issue) if you lower the StreamBytesBySecond to slow the data stream to the host?
Unfortunately I don't have a specific reason to give fr this issue, but I hope this helps with troubleshooting.
Cheers, Teresa
Hi Teresa,
I've updated the firmware on the Manta G-235B that we have, and will test this overnight.
I can move to async acquisition, as we are using that for one of our in-house GUIs, but I thought that synchronous might be better to automatically ensure each frame is completed before saving.
We are not performing any checks, but I assumed that with a synchronous acquisition, this check would be done implicitly by the host and camera. Do you have any examples that show how I might be able to do these checks manually?
I haven't changed the StreamBytesBySecond feature at all, and I'm honestly not sure exactly how it works. Do you have any suggestions on a setting that would be slower? I assume I am using whatever the default is.
Thanks for the help, I'll gradually go through these over the next week.
Best, Alan
Hello Alan,
when you have received the frame object, you can check the status of the frame, like in the python example asynchronous_grab_opencv.py
if frame.get_status() == FrameStatus.Complete:
That way you can make sure the frame will only be processed/counted, when it is complete.
StreamBytesPerSecond is nothing else, than the datarate, that the camera is sending at. If you check the status of the frames and receive incompete frames, then it would be good to reduce the datarate to avoid dropped packets. Have a look at the GigE Features Reference for more inforamtion on the possible features. You can download it here: https://www.alliedvision.com/en/support/technical-documentation/manta-documentation/ But I would otherwise recommend to open the camera in Vimba Viewer and experiment with the settings there. Check out the statistics features, to see if all frames are received correctly, when you stream (e.g. to check what datarate/StreamBytesPerSeconds the system allows for the camera, before issues like dropped packets or incomplete/shoved frames occur). This is an example on how the statistics should look:
Cheers, Teresa
Hi all,
Writing a script that automates capturing of some experimental data using synchronous capturing with an Allied Vision G-235B. So far it works reasonably well, but we are testing extreme-ish cases and for long sequences of acquisitions I'm getting some communication errors (it seems)
here is the acquisition code, fairly simple:
I'm running the code to loop through 5 gains (0, 10, 20, 30, 40), 4 exposures (0.01, 0.1, 1, 10), 25 frames for each setting, with Mono12 format, so it's quite a bit of data to be acquired. This set of camera parameters is then repeated over a set of images (10-20).
I currently have the frame_delay set to 11s max
and here is the error message: