Labview keeps freezing

[Peter H]

Originally Posted by Joe Hershberger

Please try the test release version from 2006.01.25 here and let me know what your results are. Hopefully there will be some different behavior that will help narrow down the problem.

Thanks!
-Joe

I downloaded this new GUI, but could not get it to work. I could not find how to grab a frame.
I tried the previous GUI again; this time, it loaded 3 frames before dying. I suspect that one side or the other loses the serial channel intermittently.

[holdenga]

I've had the same issues with Labview. I've used different batteries as well as a 12v regulated/filtered supply. All versions of the software have behaved in the same fashion.

[holdenga]

UPDATE. By using the latest update posted by Joe, I was able to get through a sucessful calibration session with the camera. It still posted some "unable to communicate...check serial port..." messages a few times, but I just closed the window and kept working, ignoring the error. The camera still responded after doing this.

One new oddity came up while doing this. The pan function seemed to be reversed. It wanted to track AWAY from the light source. Tilt worked properly. Since this can be addressed in the rc code, I simply unplugged the servos in order to complete calibration.

Thanks Joe.
glenn

[Joe Hershberger]

Originally Posted by holdenga

UPDATE. By using the latest update posted by Joe, I was able to get through a sucessful calibration session with the camera. It still posted some "unable to communicate...check serial port..." messages a few times, but I just closed the window and kept working, ignoring the error. The camera still responded after doing this.

One new oddity came up while doing this. The pan function seemed to be reversed. It wanted to track AWAY from the light source. Tilt worked properly. Since this can be addressed in the rc code, I simply unplugged the servos in order to complete calibration.

Thanks Joe.
glenn

The panning issue has nothing to do with the GUI... There is a jumper on the camera for each axis to reverse them.

When you get the error message does it grab part of a frame?

-Joe

[holdenga]

Originally Posted by Joe Hershberger

The panning issue has nothing to do with the GUI... There is a jumper on the camera for each axis to reverse them.
I'll check the jumpers. Thanks.

When you get the error message does it grab part of a frame?
-Joe

Yes.
glenn

[Joe Hershberger]

Originally Posted by Peter H

I downloaded this new GUI, but could not get it to work. I could not find how to grab a frame.
I tried the previous GUI again; this time, it loaded 3 frames before dying. I suspect that one side or the other loses the serial channel intermittently.

Peter,
Are you saying that the new version does nothing? I really don't understand what you mean when saying

Originally Posted by Peter H

I could not find how to grab a frame.

You click the grab frame button.

When you say "previous GUI", are you referring to the Java GUI from last year or are you referring to one of the previous LabVIEW releases?

Have you checked your change on the backup battery and all the wires for breaks or loose ends?

-Joe

[Peter H]

Originally Posted by Joe Hershberger

Peter,
Are you saying that the new version does nothing? I really don't understand what you mean when saying You click the grab frame button.

When you say "previous GUI", are you referring to the Java GUI from last year or are you referring to one of the previous LabVIEW releases?

Have you checked your change on the backup battery and all the wires for breaks or loose ends?

-Joe

Ignore my complaint. I messed up the installation. Will try again.

[Mark McLeod]

For us, the 1/25 version eliminated the run-away progress bar behavior that version 1/17 exhibited.

Peter H came over to play last night and we were able to grab frames repeatedly from his camera, but with my laptop.

[Peter H]

Originally Posted by Mark McLeod

For us, the 1/25 version eliminated the run-away progress bar behavior that version 1/17 exhibited.

Peter H came over to play last night and we were able to grab frames repeatedly from his camera, but with my laptop.

Today, I erased the LabView GUI and reloaded it with the 1/25/06 CMUCam2 demo. Now, and also last night, I have completely different intermittent failures.

Sometimes, I can Grab Frame OK. The rest of the time, I Grab Frame, the red LED flashes, the blue progress bar advances to the end, the progress bar disappears, a partial frame shows, and an error box appears "The application is closing because of a reported error ...". The status code is -1073807252. The status source is "VISA Read in get picture.vi>CMUcam2.vi>CMUcam2GUI.vi" I had to expand the status box to read this.

I can click on the error box, it disappears, and the run icon reverts to not running. I can click on the run icon again, and repeat the process - sometimes it works, sometimes not.

What is my problem?

[Joe Hershberger]

Originally Posted by Peter H

Today, I erased the LabView GUI and reloaded it with the 1/25/06 CMUCam2 demo. Now, and also last night, I have completely different intermittent failures.

Sometimes, I can Grab Frame OK. The rest of the time, I Grab Frame, the red LED flashes, the blue progress bar advances to the end, the progress bar disappears, a partial frame shows, and an error box appears "The application is closing because of a reported error ...". The status code is -1073807252. The status source is "VISA Read in get picture.vi>CMUcam2.vi>CMUcam2GUI.vi" I had to expand the status box to read this.

I can click on the error box, it disappears, and the run icon reverts to not running. I can click on the run icon again, and repeat the process - sometimes it works, sometimes not.

What is my problem?

That error means that you are overflowing the VISA serial buffer. That is why you get a partial frame before it fails. Are you using a slow computer? What kind of serial port? Are there any settings in the device manager's properties for your serial port that will allow you to increase the buffer that is used on the serial port?

I'll look at the code to see if there is anything that can be done to make the program less susceptible to the problem. One solution is to lower the Baud rate (which would need to be done both on the camera and in the application / MAX) but would make the frame grabbing even slower. Hopefully we can avoid having to do that.

Cheers!
-Joe

[Peter H]

Originally Posted by Joe Hershberger

That error means that you are overflowing the VISA serial buffer. That is why you get a partial frame before it fails. Are you using a slow computer? What kind of serial port? Are there any settings in the device manager's properties for your serial port that will allow you to increase the buffer that is used on the serial port?

I'll look at the code to see if there is anything that can be done to make the program less susceptible to the problem. One solution is to lower the Baud rate (which would need to be done both on the camera and in the application / MAX) but would make the frame grabbing even slower. Hopefully we can avoid having to do that.

Cheers!
-Joe

My laptop uses an Intel Premium M730, at 1.6 GHz, and 512 MB memory. I don't find any option in WinXP2 to increase the buffer size. The RS-232 serial port is built in to the mother board. No other app is running while LabView is running.

If this is a buffer size problem, why does it work more often than not? When I get a partial frame, it is anywhere from 10% to 90% of the full frame.

[Joe Hershberger]

Originally Posted by Peter H

My laptop uses an Intel Premium M730, at 1.6 GHz, and 512 MB memory. I don't find any option in WinXP2 to increase the buffer size. The RS-232 serial port is built in to the mother board. No other app is running while LabView is running.

If this is a buffer size problem, why does it work more often than not? When I get a partial frame, it is anywhere from 10% to 90% of the full frame.

Your setup seems reasonable. I have a serial port that plugs into the PCMCIA port that looks just like a standard ISA UART. In the properties of the port in Device manager is has the option to turn on buffering (it allows 14 bytes for transmit and 15 bytes for receive)... I would expect that to be available to you as well, but it depends on which UART chip they used on your motherboard. The older models of UARTS have no buffering at all... the driver must read every byte that comes in before the next one comes. This can be difficult to achieve and very inefficient, which is why newer UARTs have buffering. or operating systems like Windows that are not real-time, it is difficult to service every byte with low latency (before the next byte). It is much easier for something like the PIC in the RC.

If it works more often than not, then VISA is barely not able to keep up with the serial stream. This should only be an issue for receiving, so you shouldn't have problems with things like programming your RC. You may have problems if you try reading the memory at full speed. I will add an option in the code to allow you to make it work for your serial port and computer. It will slow down the rate at which the camera sends bytes to you and will eliminate the buffer overflows (as long as you set it high enough). You will want to start with 1 bit delay (the default is 0 which is causing your problems) and increase it until your problem goes away. Since it almost works now, I would expect that a value of 1 or 2 should be sufficient to make it work very well.

At least I'm confident that this should solve the problems you and others have been having. Thanks for helping to diagnose the problem so that everyone can enjoy the benefits of a working system! I'll post it when I finish the addition.

Cheers!
-Joe

[Joe Hershberger]

Peter,

I've posted the new version. Please let me know if it solves your problem.

Thanks,
-Joe

[Peter H]

Originally Posted by Joe Hershberger

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.

[Joe Hershberger]

Originally Posted by Peter H

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.

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?

Originally Posted by Peter H

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?

In that case I'm surprised you ever got that VISA error. Did you check for PIO mode?

Originally Posted by Peter H

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.

I'm glad to hear it works somewhere! I thought maybe you wouldn't believe that it works here!


Let me know,
-Joe