CamView for Wheesy and Jessie

If udev is doing its job, the camera should be detected when plugged back it, but due to an incomplete cleanup when it came unplugged, the path to it might change. In that event, whats in memory would be wrong as to where it is, and LCNC may need to be restarted to find it again. Its possible some hints to the udev bugzilla might help in the long run if enough folks ask about a fix. I think that's my situation also, or at least the first thing I'd check. Write down the path from the boot log, and compare that to what dmesg shows when the device has been plugged back in.

Best I can deduce from here.

Cheers, gene1934

I think it's more likely that camview (or it's backend) isn't releasing the camera's resources. The kernels device names are usually pretty good until you add a second video device, then you start to have problems with the naming order, if video1 is pulled it will become video3 if there is a video2 in existence. In that case writing hardware based UDEV rules has solved the issues with my project so I don't rely on kernel naming. I still have an issue with the cameras resources if it were to be unplugged while running but that's generally not a huge deal for me.

Imho it is not a matter of udev. I think the python class looses the connection to the videodevice.
Have you tested what happen if you stop the capture using the camview button before unplugging the cam? And plug in the cam, wait a few seconds and restart capturing?

Otherwise you will need to edit the python file and add a feature to unconnect the videodevice before unplugging.

Norbert

I hadn't considered that, Norbert, mainly because my problems aren't related to a sudden disconnect from a sloppy usb socket, but to switch from shrink to expand and back, right st the cameras native size (800x600) as the axis screen is resized.

I remounted the camera today, looks good. But I'm mid rebuild of the box being driven by the P2 connector ATM. Using a Sainsmart bob, and real psu's, but am seriously looking at a mesa 7i76 to run it all, I'm essentially out of i/o, and considering making a tool changer and possibly a pallet holder too.

Thanks Norbert.

Cheers, gene1934

The fact is that since the button image wasn't titled, or even looked like a clickable button, was a far bigger impediment as it never occurred to me to hover over it to see if it did have something to say. Now that I know, it won't happen again.

Thanks Andy

Occasionally after some use, I get unusual behavior, specifically Gmoccapy freezing.
I have attached the error log following the event. Contained within are ongoing references to:
1:

select timeout

and 2:

libv4l2: error dequeuing buf: No such device
VIDIOC_DQBUF: No such device

with the second reference reoccurring a huge number of times in the debug section of the log.

The libv4l2 reference infers a camera issue??

Without being majorly Linux savvy, is the camera overflowing a buffer here and causing a crash??
I also notice the camera itself getting quite warm (I suspect from resistors to run the LED lights it has in the tip), is it possible this represents the camera ultimately overheating and going offline, resulting in the system not finding the camera anymore and resulting in a buffer overflow/crash?

If this is the case, per a previous post, it would be handy to be able to set up the usb camera as a hot pluggable device and thus to only use it for the time necessary.

Debug section of the file attached.

Thanks,
Marty.

i don't know as this i the exact same problem I have when resizing the camera image, which causes the camera tab to turn white/blank, and needs a LCNC restart to fix. But it could be from a similar cause. I'm using axis which throws another variable into the witches pot and don't seem to be getting your extensive debug log but I don't have debug tracing enabled in axis,

ATM I can't test the rest of it under load, a $2.50 buck voltage regulator failed shorted, putting 35 volts into a 5 volt BoB so I'm in the middle of rebuilding the whole LCNC interface box which will give me another 48 i/o points, badly needed, but I'm also in the middle of getting my cataracts fixed so am not seeing well enough for fine machining for mounting the plug/sockets and soldering that will be needed to bring it back to life. So the best I can do is confirm there is a problem needing some TLC for 100% dependability. But I'm not a python or glade expert either. I've done mosdt of my gui work with pyvcp, which is both a screen real estate hog and bulletproof.

Cheers all, Gene1934

@Marty

Have you tested what happen if you stop the capture using the camview button before unplugging the cam? And plug in the cam, wait a few seconds and restart capturing?

Norbert