OpenPnP-Capture: no frame captured

[Jan]

Hi All!
I'm trying to find out why my two cameras can not be used on a single
host controller on Win11 (I know this is not recommended). Both are ELPs
with multiple resolutions and many interfaces with different bandwidth
requirements.
When I start OpenPnP, I find "Camera <...> thread <...> started" twice
in the log and I get a preview image on the first camera. The second is
just black (not the error image).
In OpenPnP I can see, that Cap_openStream() is called on each camera
and that it quickly returns with 0 for the first and takes longer for
the second but also returns 0. Cap_hasNewFrame() never returns 1 for the
the second camera.
I've used USB Device Tree Viewer V4.5.0 to check the USB configuration
details and can see, that the first camera has two pipes open. The
second ("pipe[1]") is reported as EndpointID=1, wMaxPacketSize=0x13fc
and bInterval=1. That corresponds to bAlternateSetting=0x03 of Interface
1, which is the configuration with the highest bandwidth requirements.
For the second camera I don't see an active second pipe. I'd say that
the camera has no active streaming connection. Using an external camera
viewer I can not connect to the camera. So I'd conclude that
OpenPnP-capture has an open handle on the camera preventing others from
using it.
The question is now, why is there no error message indicating that
OpenPnP-capture can not capture from this camera and why is
OpenPnP-capture not able to choose a different configuration for the
streaming interface that has less bandwidth requirements?
Final note: I'd love to see that OpenPnP prefers Bottom over Top
cameras by acquiring more bandwidth for bottom vision. However, at
present cameras seem to be created and initialized directly from
machine.xml in which the order is probably given by the order of
assigning them when first configuring the machine.

Jan

BTW: The same issue happens if the cameras are forced to be initialized
the other way around.

[vespaman]

Hi Jan,

While I have only experience of Linux, I think this is a kernel driver thing, maybe USB limitation. When the device is opened, it will require the camera device and the needed bus speed. At this point, the needed bus speed is not known, it takes most device need.

On Linux, you can see the second camera being knocked off the USB bus in the kernel log.

I have never seen a working configuration with the 'dynamic' bus speed allocation you are expecting to see. 

(Not saying this does not exist, just my own experiences with the cheap USB cameras I have used)

On my previous computer, a PCIe USB3 adapter card did the trick, but maybe you cannot make place for such.

 - Micael

[Jan]

Hi Micael!
I do have a dedicated USB controller installed and that's the reason
why I'm trying to get all PnP-related devices on that controller. And
this one shows the problem if both cameras are connected (btw: the
problem happens with any format).
Previously I researched, that usb drivers shall choose a good interface
amount the available by respecting the available bandwidth. I don't know
if Windows supports that and if that's actually the problem.
What I'm not happy with is that OpenPnP does not report an error in
this case. You only notice it that the preview is not updated or bottom
vision fails. That's not enough.
Maybe it would be a good starting point if anyone could hint me how to
get OpenPnP and OpenPnP-capture into Eclipse and debug them im parallel...

Jan

> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/openpnp/
> e8276048-d630-468d-9c8b-25de3f0dd962n%40googlegroups.com <https://
> groups.google.com/d/msgid/openpnp/e8276048-
> d630-468d-9c8b-25de3f0dd962n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

[bert shivaan]

I am not at all versed in this type of stuff, but it seems like it is not a bandwidth issue. It is my understanding it will happen even on USB3 connections. So I wonder if it is a camera name issue? Likely ELP cameras enumerate to the same name, so we then have 2 of the same end points on the same bus. If this is the case only 1 can work of course.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/openpnp/340bd79b-8900-445f-ae06-d2887d8bd0fb%40googlemail.com.

[Mike Menci]

Jan would this help; 

Mike

Dne 2. dec. 2025 ob 14:56 je oseba bert shivaan <bert.s...@gmail.com> zapisala:



To view this discussion visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNwP9LtfXLq7CMcYB-dgYa2eZ2VTwW0iKEnZtukWuqAW6w%40mail.gmail.com.

[simpl...@tuta.io]

>> Likely ELP cameras enumerate to the same name, so we then have 2 of the same end points on the same bus

It is possible to nail a uvc camera to a specific USB port using a ManagementObjectSearcher database query to circumvent the annoying race condition when using completly equal cameras on windows.

[Jan]

Hi all!
No, this is for sure not a name issue. USB is strictly hierarchical and
devices are identified using a path that leads in a unique fashion to a
specific port. Endpoints (in the USB sense) are device specific and
names are completely optional.
To be a little bit more specific, my two cameras are of different
bands, with respect to USB identification. They have different Vendor
and Product IDs. The Video Streaming interface descriptors are
identical. Both provide the same three options with different bandwidth
requirements.
The main issue I have with the current situation is, that there is not
error message. Both cameras can be opened but only one delivers a video
stream. The other just looks ok, but never delivers any image. And due
to the lack of error message, one only notices the problem when enabling
preview or on bottom vision failure. That's IMHO not enough and shall be
fixed. However, I currently don't know how to debug openpnp-capture. Can
anyone please shine a light on how to do that? That would be very much
appreciated.

Jan

On 02.12.2025 18:00, simplemount via OpenPnP wrote:
> /*>> Likely ELP cameras enumerate to the same name, so we then have 2 of
> the same end points on the same bus*//*
> */

>
> It is possible to nail a uvc camera to a specific USB port using a
> ManagementObjectSearcher database query to circumvent the annoying race
> condition when using completly equal cameras on windows.
>

> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/openpnp/

> OfV-bVa--F-9%40tuta.io <https://groups.google.com/d/msgid/openpnp/OfV-
> bVa--F-9%40tuta.io?utm_medium=email&utm_source=footer>.

[simpl...@tuta.io]

>> USB is strictly hierarchical and devices are identified using a path that leads in a unique fashion to a specific port

On all my Windows 10 machines, there were repeated problems with multiple cameras that had identical IDs during cold starts. Only assigning them to a specific port provided a solution and the desired convenience. During warm starts, however, the confusion problem never occurred.

>> However, I currently don't know how to debug openpnp-capture

I assume that the part of OpenPnP-Capture that seems to be responsible here is written in C++, which is usually debugged in Visual Studio. Maybe Jason has some instructions for that.

[bert shivaan]

I wonder if it could be done through openPNP like by checking the "returned image" for complete nothingness? 

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/openpnp/OfYnMPm--F-9%40tuta.io.