CamView for Wheesy and Jessie

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

Hallo Norbert.

Ich war in Australien geboren aber meine Eltern haben Deutsch zu Hause gesprochen
Vielen dank fuer Ihre hilfe.

I do not see a "camview" button in the camera tab of Gmoccapy. I currently have the ini file tab location set to "ntb_preview". Maybe I need a bigger view??
Sometimes when I expand Gmoccapy to full screen, I see the "ghosting" of some buttons beneath, but nothing really to act upon, hence I don't know of the "camview" button.

I was also using the camera tab today and while some people are talking of a slow frame rate, I see something slightly different... I see intermittent capture rate, so in other words, for about 4 seconds the refresh rate is OK, then for 2 seconds I see the frame freeze, then for the next 4 seconds it refreshes OK again etc. I feel this is different behavior from simply a slow frame rate but rather something coming to a limit, then clearing a buffer, then back to a limit again, in a 4/2/4/2/4/2 second cycle. If you were not watching closely it could be confused for a slow frame rate, but I think it is something different.

I wonder if you have any thoughts on both of the above issues?

Nochmal vielen dank!
Chuess,
Marty.

I have noticed another interesting behavior.
After Gmoccapy is opened but before the machine is out of E-Stop, the camera under the camera tab runs seamlessly. Good refresh rate, no lagging.
As soon as the machine is taken out of E-Stop, when I go back to the camera tab, the picture is slow and laggy. I hope this information helps. Of note (possibly?), I am also running Any Pugh's Lathe macros (which I believe is also via gvp and py??), could there be a conflict?

Norbert, I have also tried your modification as below, and it works, but the behavior as specified above is still there with in and out of E-Stop lag/refresh.

If you have installed all dependencies as mentioned in previous post, you just will need to add to your INI File:
EMBED_TAB_NAME = Camera
EMBED_TAB_LOCATION = ntb_user_tabs
EMBED_TAB_COMMAND = gladevcp -x {XID} -c emb_cam -H emb_cam.hal -u emb_cam.py emb_cam.glade

and copy the following files to your config dir:
emb_cam.hal
emb_cam.py
emb_cam.glade

BUT, given the above, I wonder if that is slowing my system down overall, so, I wonder if someone could tell me how to disable the cam portion please? Is there a way of commenting out a line or some other action etc. which will prevent this from loading and potentially slowing down the machine but still allowing me to un-comment the line etc and try other options or cameras with linuxcnc?

Thanks,
Marty.