> I'm sure you're running them on separate buses, right?
Just testing with one for now, but yeah, I'm very aware of that, thanks! 😁
_Mark
> What distribution are you using?
--
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 on the web visit https://groups.google.com/d/msgid/openpnp/155d234a-b74b-41e4-8087-022f81251dbdn%40googlegroups.com.
I see, and linking from there an even older thread from 2018. 🙁
(also found my email client does not find these error keywords in my mailbox... another thing I must fix 😭)
_Mark
--
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 on the web visit https://groups.google.com/d/msgid/openpnp/2ca3a9f0-2bd0-4226-bcb5-322ac8590578n%40googlegroups.com.
OT: if anybody uses Thunderbird, and suddenly wonders, why messages are not indexed, check this checkbox in the folder properties:
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a6bf5883-1082-ae12-4ad3-7c001be457fb%40makr.zone.
> This probably doesn't count as "help", but I'm running
ELP cameras under Linux without difficulty. I've not really dug
into their settings, beyond just setting them such that it works
well, but they're very stable.
@Dave McGuire, please send a screenshot of your Device Settings, thanks!
_Mark
Some background, for others reading this to understand:
openpnp-capture is a separate C++ project, creating cross-plattform web-cam access, here:
https://github.com/openpnp/openpnp-capture
Then this is wrapped in Java in the openpnp-capture-java
project, here:
https://github.com/openpnp/openpnp-capture-java
Finally, OpenPnP is consuming it in the OpenPnpCaptureCamera,
here:
I'm not at all familiar with openpnp-capture, even less with the underlying tech, and frankly, I hoped I would never have to look into it. 😅
> errorno 22 is normal in v4l2 API because v4l2 poll the device until data return is valid so many attempt doing
do you mean to say the polling is not done properly?
I guess this comes from PlatformStream::getProperty() et
al. around here:
and polls here:
In fact, after examining this, I'm not sure these are actually real
errors. Some properties might simply not be supported by
different camera models:
// supported
properties:
#define CAPPROPID_EXPOSURE 1
#define CAPPROPID_FOCUS 2
#define CAPPROPID_ZOOM 3
#define CAPPROPID_WHITEBALANCE 4
#define CAPPROPID_GAIN 5
#define CAPPROPID_BRIGHTNESS 6
#define CAPPROPID_CONTRAST 7
#define CAPPROPID_SATURATION 8
#define CAPPROPID_GAMMA 9
#define CAPPROPID_HUE 10
#define CAPPROPID_SHARPNESS 11
#define CAPPROPID_BACKLIGHTCOMP 12
#define CAPPROPID_POWERLINEFREQ 13
Compare the errors:
[ERR ] getPropertyLimits
(ID=2) failed on VIDIOC_QUERYCTRL (errno 22)
[ERR ] getAutoProperty (ID=2) failed on VIDIOC_G_CTRL (errno
22)
[ERR ] getPropertyLimits (ID=2) failed on VIDIOC_QUERYCTRL
(errno 22)
[ERR ] getPropertyLimits (ID=2) failed on VIDIOC_QUERYCTRL
(errno 22)
[ERR ] getPropertyLimits (ID=2) failed on VIDIOC_QUERYCTRL
(errno 22)
[ERR ] getProperty (ID=2) failed on VIDIOC_G_CTRL (errno 22)
[ERR ] getAutoProperty (ID=2) failed on VIDIOC_G_CTRL (errno
22)
[ERR ] getAutoProperty (ID=5) failed on VIDIOC_G_CTRL (errno
22)
[ERR ] getAutoProperty (ID=5) failed on VIDIOC_G_CTRL (errno
22)
[ERR ] getPropertyLimits (ID=3) failed on VIDIOC_QUERYCTRL
(errno 22)
[ERR ] getPropertyLimits (ID=3) failed on VIDIOC_QUERYCTRL
(errno 22)
[ERR ] getPropertyLimits (ID=3) failed on VIDIOC_QUERYCTRL
(errno 22)
[ERR ] getPropertyLimits (ID=3) failed on VIDIOC_QUERYCTRL
(errno 22)
[ERR ] getProperty (ID=3) failed on VIDIOC_G_CTRL (errno 22)
Surely the ELP does not support motor-focus (2), motor-zoom (3).
And gain (5) seems not to have an Auto setting? That's all OK,
IMHO. It should probably not be reported as [ERR], though.
So I guess the flaky behavior is not (directly) related to these
error messages.
There can be valid negative values, when the same cam is
seen in Windows, especially on Exposure, where I see the
actual problems. Maybe there is something not treating that well
under Linux (I'll check all when I'm back on Linux):
You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/SpkC2XxB_jk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/61618f1e-550a-43ad-b389-18b0bfb0c955n%40googlegroups.com.
Same ELP camera on Linux:
vs. Windows:
I guess under Windows it does not properly determine which can be
set to Auto, i.e. this is better under Linux.
Gain does nothing in Windows, so again i guess this is
actually better disabled as under Linux.
However, the Exposure setting is clearly different under Linux, and behaving wrong. By sheer trial an error I can set it manually, but it is all over the place.
Some intermittent connection problems under Linux seem to be gone
after I connected the camera "more directly" to the PC, i.e. not
through the monitor's hub.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/948d60e9-7864-5806-5193-1dac5e5cc5d9%40makr.zone.
Thanks Ian. My cam's output below.
It seems OpenPnP does it right, but Exposure is just broken in this Linux driver.
I've changed Issues & Solution so at least it will not
take 5000 exposure probes, but a maximum of 32 probes distributed
across the range. The scan is now completely chaotic, but it still
finds a good setting.
Will make a new testing version soon.
_Mark
>
v4l2-ctl --list-devices
USB 2.0 Camera: HD USB Camera (usb-0000:00:14.0-1.1):
/dev/video5
/dev/video6
/dev/media2
Integrated_Webcam_HD: Integrate (usb-0000:00:14.0-6):
/dev/video0
/dev/video1
/dev/video2
/dev/video3
/dev/media0
/dev/media1
>
v4l2-ctl --device /dev/video5 --all
Driver Info:
Driver name : uvcvideo
Card type : USB 2.0 Camera: HD USB Camera
Bus info : usb-0000:00:14.0-1.1
Driver version : 5.15.64
Capabilities : 0x84a00001
Video Capture
Metadata Capture
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04200001
Video Capture
Streaming
Extended Pix Format
Media Driver Info:
Driver name : uvcvideo
Model : USB 2.0 Camera: HD USB Camera
Serial :
Bus info : usb-0000:00:14.0-1.1
Media version : 5.15.64
Hardware revision: 0x00000100 (256)
Driver version : 5.15.64
Interface Info:
ID : 0x03000002
Type : V4L Video
Entity Info:
ID : 0x00000001 (1)
Name : USB 2.0 Camera: HD USB Camera
Function : V4L2 I/O
Flags : default
Pad 0x01000007 : 0: Sink
Link 0x02000010: from remote pad 0x100000a of entity
'Extension 3' (Video Pixel Formatter): Data, Enabled, Immutable
Priority: 2
Video input : 0 (Camera 1: ok)
Format Video Capture:
Width/Height : 1920/1080
Pixel Format : 'MJPG' (Motion-JPEG)
Field : None
Bytes per Line : 0
Size Image : 4147789
Colorspace : sRGB
Transfer Function : Rec. 709
YCbCr/HSV Encoding: ITU-R 601
Quantization : Default (maps to Full Range)
Flags :
Crop Capability Video Capture:
Bounds : Left 0, Top 0, Width 1920, Height 1080
Default : Left 0, Top 0, Width 1920, Height 1080
Pixel Aspect: 1/1
Selection Video Capture: crop_default, Left 0, Top 0, Width
1920, Height 1080, Flags:
Selection Video Capture: crop_bounds, Left 0, Top 0, Width 1920,
Height 1080, Flags:
Streaming Parameters Video Capture:
Capabilities : timeperframe
Frames per second: 30.000 (30/1)
Read buffers : 0
brightness 0x00980900 (int) : min=-64
max=64 step=1 default=0 value=0
contrast 0x00980901 (int) : min=0
max=64 step=1 default=32 value=32
saturation 0x00980902 (int) : min=0
max=128 step=1 default=60 value=60
hue 0x00980903 (int) : min=-40
max=40 step=1 default=0 value=0
white_balance_temperature_auto 0x0098090c (bool) : default=1
value=0
gamma 0x00980910 (int) : min=72
max=500 step=1 default=100 value=100
gain 0x00980913 (int) : min=0
max=100 step=1 default=0 value=0
power_line_frequency 0x00980918 (menu) : min=0 max=2
default=1 value=2 (60 Hz)
0: Disabled
1: 50 Hz
2: 60 Hz
white_balance_temperature 0x0098091a (int) : min=2800
max=6500 step=1 default=4600 value=4600
sharpness 0x0098091b (int) : min=0 max=6
step=1 default=2 value=0
backlight_compensation 0x0098091c (int) : min=0 max=2
step=1 default=1 value=2
exposure_auto 0x009a0901 (menu) : min=0 max=3
default=3 value=1 (Manual Mode)
1: Manual Mode
3: Aperture Priority Mode
exposure_absolute 0x009a0902
(int) : min=1 max=5000 step=1 default=157 value=781
exposure_auto_priority 0x009a0903 (bool) : default=0
value=0
--
You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/SpkC2XxB_jk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d29d1953-3cb0-475c-9642-a46ca1d8cc8en%40googlegroups.com.
> But I have no success in the camera handling - is there a proper way to make this work? I still have to re-enter "13" or nudge the dragbar for the setting to "take".
There is no change in the property handling per se. It is wrong in the v4l2 driver, as we confirmed. Nothing OpenPnP can do.
> If I set Exposure time to "Auto" and go to the
Issues & Solutions, it now only tries a few settings (brings
up a dialog saying Maching still busy after timeout expired,
task rejected).
Hmmm.. I guess this is related to the "Maching still busy after timeout expired, task rejected". The funny thing is that I don't see how this is possible (at least outside of a SwitcherCamera).
After you report back, I will look further.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/77f0159c-3f01-4213-a613-e859e2f0295fn%40googlegroups.com.
> But I have no success in the camera handling - is there a proper way to make this work? I still have to re-enter "13" or nudge the dragbar for the setting to "take".
There is no change in the property handling per se. It is wrong in the v4l2 driver, as we confirmed. Nothing OpenPnP can do.
Strange. Are you using SwitcherCameras?
> It does give a final result that is somewhat ok (too bright)
Yeah, with the driver reporting a completely wrong range, it is all I could achieve. The important thing is that the calibration does no longer hang OpenPnP. Maybe I can make it more steps, so the chances for it to hit a good value increase.
> (And I have to enable the down led light manually before "Accepting" in I&S).Hmmm.. I guess this is related to the "Maching still busy after timeout expired, task rejected". The funny thing is that I don't see how this is possible (at least outside of a SwitcherCamera).
After you report back, I will look further.
I guess another workaround would be to do this from the start script, after OpenPnP has started. In a way this is probably what I would prefer anyway, since then I know the settings are properly stored/restored for this application.
Hi all,
I added a new option Freeze Properties to the OpenPnpCaptureCamera.
Best read the Instruction for Use:
https://github.com/openpnp/openpnp/pull/1510
This PR also fixes the "Machine still busy after timeout expired, task rejected" error.
Allow for a few minutes to deploy a new test version.
_Mark
--
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 on the web visit https://groups.google.com/d/msgid/openpnp/728bb8bd-f796-4c6b-9ef7-46abbe64ae93n%40googlegroups.com.
> And if I restart the program, the exposure is still wrong, until I go into the camera device dialog again, and press "Reapply to camera", then I got the settings I want loaded down to camera. So the second time/after restart, the Reapply works. But the startup loading of the saved settings seems not to work.
Darn, I wasn't able to reproduce on my Linux, so I already feared it will not solve the problem on your side (that's why I made the "Reapply to camera" button).
I wonder if the magic is in that sleep 5
that you had in your script. Let the camera run for a while and
set the property after that. Or set it periodically, until it
reads back as set. Pity I cannot reproduce.
I'm sure I asked before, but what camera make/model is that?
_Mark
You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/SpkC2XxB_jk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6f2bc6ee-ae50-4c12-b103-d7a4d6752693n%40googlegroups.com.
My FullHD 1080p ELP shows as:
[ 8941.875683]
usb 1-1.1: new
high-speed USB device number 23 using xhci_hcd
[ 8942.096755] usb 1-1.1: New
USB device found, idVendor=05a3, idProduct=9230, bcdDevice=
1.00
[ 8942.096771] usb 1-1.1: New
USB device strings: Mfr=2, Product=1, SerialNumber=0
[ 8942.096776] usb 1-1.1:
Product: USB 2.0 Camera
[ 8942.096780] usb 1-1.1:
Manufacturer: HD Camera Manufacturer
[ 8942.104241] usb 1-1.1: Found
UVC 1.00 device USB 2.0 Camera (05a3:9230)
[ 8942.158449] input: USB 2.0 Camera: HD USB Camera as
/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.1/1-1.1:1.0/input/input46
The recommended HD 720p model will likely differ a bit, but
I fear not as much as yours.
Could you do some tests as to whether reapplying the properties
after a certain time does the trick?
And is it stable after that?
If this works, no need to change the camera if it is otherwise good quality.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/31a47497-ce80-4c85-8951-b1a6a84ce802n%40googlegroups.com.
Hi Micael,
the reapplication is now done in the homing handler. I believe
this should solve this issue in all practical operational
scenarios.
During non-operational scenarios (still setting the machine up),
you should be able to get by using the Reapply button in
the camera.
Obviously the real bug is somewhere else, with the camera and/or driver and/or kernel.
See:
https://github.com/openpnp/openpnp/pull/1512
Allow some minutes for the new test version to deploy.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/233409c7-7696-13ea-f239-cc5137177a83%40makr.zone.
The test button closes and the reopens the camera, which explains what you see. Assuming you don't use this button routinely I think you can live with that.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/59826a60-e2c6-460f-b535-ac1322f04960n%40googlegroups.com.