Peter,
I’ve posted the new version. Please let me know if it solves your problem.
Thanks,
-Joe
With the 1/27 version, LabView still sometimes show a partial frame, even with the serial port delay set to 4. I see little difference between a delay of 1 and 4. One difference now is that when LabView shows a partial frame, the red LED keeps blinking for the usual duration, the blue progress bar disappears, and no error is posted. LabView is still in run mode, and I can select Grab Frame again - which may or not show a full frame.
My earlier post was misleading. The serial port buffers are set to 14 and 15. I had thought you meant a software buffer. And many (~50?) WinXP processes are running in the background; most, I have no idea what they do. Maybe one of these sometimes prevents LabView from fetching the data?
I can operate LabView CMUcam2 GUI reliably on my desktop; Grab Frame works 20 times out of 20. But that is faster, with fewer background processes.
If you are not getting the VISA error when it aborts the frame grab, then the serial delay is not likely to help. So the LED continues to blink after the download bar disappears? That would indicate that it is quiting early. There are currently three reasons why the frame grab stops. If there is an error, if the expected time plus 50% passes, or enough bytes appear.If you look at the image, when only a partial frame is downloaded… does i look like there are lines missing in the middle, or does it look complete and error free up to the point that the image is truncated? If it’s not an interrupt servicing issue, then it’s most likely data corruption. Is your serial cable frayed or shorting out? Are you running lots of motors around it? Is your battery FULLY charged?
In that case I’m surprised you ever got that VISA error. Did you check for PIO mode?
I’m glad to hear it works somewhere! I thought maybe you wouldn’t believe that it works here! :eek:
Let me know,
-Joe
The partial image is complete, as far as it goes - no missing lines. I have used 2 serial cables, both look OK, both give the same result. No motors or robot controller - I run the camera stand-alone on my desk. Battery is fully charged, and voltage stays about 7.5 volts while running. COM1 / Resources shows IRQ 4; no PIO.
Micrsoft Antispyware used 9% of cpu every few seconds. Killed it, but no change. Other processes use 2-3% every few seconds.
LabView is now adequate for my purpose.
Just to be clear, does the red light continue to flash after the download bar disappears and the error message pops up?
Thanks,
-Joe
Usually yes. The download bar disappears and the frame stops updating at the same time, and the red LED continues to flash for a total of about 8 - 10 seconds. There is no error message other than the partial frame. I can select Grab Frame, and the download repeats for another try.
Sometimes, the previous behavior shows: the red LED stops when the frame update stops, the download bar repeats after several seconds, and no red LED. The Grab Frame button stays green, but, if I click it, it grays out. The download bar still repeats about every 25 seconds.
That is very interesting. From the behavior you describe, it sounds like the timeout for the frame grab is being computed incorrectly. The only inputs that the timeout is based upon is the Baud rate, the serial port delay, and the image dimensions that are returned from the camera. The first two shouldn’t change unless you change them. It sounds as though the data coming from the camera may be getting corrupted.
Do you know how to probe lines in LabVIEW? It is a good way to debug LabVIEW code. I need you to open the “get picture.vi” inside of “CMUCam2 demo.llb” and switch to the block diagram (Ctrl-e), right click on the computed number of bytes and click probe. Then run the CMUCam Gui Application and let me know what the probe says for each of the cases you described above. I’m thinking that for whatever reason, you are having trouble with that, but lets see what you find from the probe.
Thanks,
-Joe
There are 3 cases. I deleted the byte counter and then reselected it before each case, to ensure it started at 0.
1 Correct operation, the full frame appears: as soon as I select Grab Frame, the number of bytes shows 114242
2 Partial frame, red LED continues to blink: as soon as I select Grab Frame, the number of bytes shows 114242
3 Partial frame, progress bar advances spontaneously, no red LED blinking: the number of bytes does not change from 0.
I have not knowingly changed any LabView settings. I removed LAbView and reinstalled it a few days ago, but saw no change in operation. Since this GUI works OK with a desktop computer, I suspect some incompatibility between my laptop and the camera, that produces a hiccup in the data flow, and LabView can not tolerate the hiccup.
Peter,
I’m suspecting that it will now work properly for you most of the time. The new update (from 2006.01.31) will much more robustly check that it is getting what is expected and quit if it doesn’t. It also flushes the serial port buffers completely now and interrupts any currently executing streams on the camera. This means that even if the camera is in the middle of a frame grab (for whatever reason) and the app asks for a new frame, it will abort the first one and ask for a fresh new one. You should never get case 3 from above, now. If you get case 2 (I’m really not sure how this is happening since the size is correct) then it should fix itself on the next try.
Good luck!
-Joe
OK. With the 1/31/06 version, I do not get case 3 in 20 tries. Case 2 still occurs, but the GUI recovers in the next frame grab. Thanks for all your effort.
Peter,
I’m glad to hear that it’s working better. I really wish we could figure out what’s going on with the 2nd case. Does it return an error when you get case 2? (I’m referring to the error cluster that appears on the front panel, not the pop up window.) It may be a screwy hardware thing.
-Joe