Open pthomasj opened 1 year ago
At the moment we only raise a warning message per skipped frame.
Thank you.
I was also wondering, is there a way to override having the pipeline abort after 100 buffers are skipped?
Would it be possible to add an option to override having the pipeline abort after 100 buffers are skipped?
We set this value because having capture errors is a severe system/hardware/misconfiguration error that should be fixed. In proper setup Basler cameras run 24/7 with no errors at all.
Can we support you in setting up your system to run without errors?
Sure, thank you.
What is being checked that informs the process to report this particular error? Is it some kind of checksum of the buffer?
Is there a means to track down if this is occurring at the camera, in a network switch, in the GStreamer pipeline or someplace else?
There are error messages in get debug logging that show the reason of the error.
And this can be a lot of different things depending on system and camera
with the new GstMeta support in v0.5.0 you can get detailed information from the camera in buffer metadata. ( see readme/changelog) This can also help to identify lost frames. TriggerCounter Chunk e.g. is for a HW triggered device the number of triggers received. This allows to exactly track, if you received every triggered frame.
Thank you. Is there a forum for questions about using just the Pylon library? I'm having an issue where after the camera has run a while, changing the exposure time a small amount causes the image grabs to repeatedly time out which then can not be recovered from. The amount the exposure time is changed should not be enough to make the image grab time out.
You can contact your area support team regarding pylon C++ SDK questions:
If the
capture-error
property is set tokeep
orskip
, is there a notification when a capture error occurs?