Labview keeps freezing

[SHerpich]

After taking a couple of pictures, the progress bar keeps running over and over again, but the new picture will not load and the buttons lock up. If we restart labview or restart the computer we can take a couple more pictures, but then it locks up again. Turning the camera off and on doesn't seem to help. There was no problem with the installation. We are not getting any of the errors that have been posted in the forum. The TTL adaptor is connected to the camera by a PWM cable but it is not attached to the RC. We configured the com port to the specifications in the camera manual. Does anyone know what we might have done wrong?

[Mike Bortfeldt]

SHerpich,

We've observed the same problem. When we first installed LabVIEW, we were able to grab frames without any problems. The last time we tried, we saw the same problem you described. We would always be able to grab at least 1 frame, and sometimes several, but then the progress bar would indicate a frame grab in progress and once it would get to the end, there was a pause (several seconds), no new frame displayed, but the progress bar would start over as if it was acquiring another frame. Our workaround is to upload the camera parameters in between every frame grab (even if nothing has changed). I'm not sure why that works or if that will work for you, but give it a try.

You also may get a better response if you put this question in the LabVIEW forum.

Mike

[Danny Diaz]

Originally Posted by SHerpich

After taking a couple of pictures, the progress bar keeps running over and over again, but the new picture will not load and the buttons lock up.

Sounds like a classic problem of the backup battery being too low - we've seen issues just like this that have been solved by replacing with a FRESH battery. Obviously if your CMUCam2 is able to talk to LabVIEW then you don't have a traditional "communication problem", but your battery doesn't seem to have enough juice to sustain the communications (or there's an intermediate short, very likely with PWM cables from IFI - several our PWM cables were bad). If you do something in-between grabbing frames, it would appear to me that would give the battery a [small] chance to recover.

-Danny

[heydowns]

Originally Posted by Danny Diaz

Sounds like a classic problem of the backup battery being too low - we've seen issues just like this that have been solved by replacing with a FRESH battery. Obviously if your CMUCam2 is able to talk to LabVIEW then you don't have a traditional "communication problem", but your battery doesn't seem to have enough juice to sustain the communications (or there's an intermediate short, very likely with PWM cables from IFI - several our PWM cables were bad). If you do something in-between grabbing frames, it would appear to me that would give the battery a [small] chance to recover.

-Danny

Our team also continually sees the problem that the original poster is talking about.
We have used two different backup batteries, both fully charged. The problem was still observed.

Note that when I say "continually", I mean that we consistently get the problem on an inconsistent basis. Sometimes we get it immediately at the start of the work session and it lasts through several restarts of LabView and RC/Camera power cyclings. Other times, things work for a little while (we can grab 2-3 frames), but then we get the OP's problem of LabView not responding to input, not getting the frame that was asked for, and the frame grab progress bar continually filling up and starting over. This persists until we restart the LabView CMUCam GUI application. After restarting, it might or might not occur again immediately. It is consistently inconsistent as to when it works.

If it is really thought to be a power supply issue, then I will try to make an effort to rig up a non-battery supply and run the camera off that. Maybe the OP or someone else having the same problem can do the same (just use any standard DC power supply that fits the specs outlined in the CMU Cam docs).

Hope this helps to diagnose the problem.

[Danny Diaz]

Just curious, when you have this problem are you using a USB-to-Serial converter or a built-in serial port? We've been up and down this problem trying to reproduce it, and we're having a bugger doing anything close to what you're describing - we're using a built-in port on a desktop, though.

-Danny

[Peter H]

Originally Posted by Danny Diaz

Just curious, when you have this problem are you using a USB-to-Serial converter or a built-in serial port? We've been up and down this problem trying to reproduce it, and we're having a bugger doing anything close to what you're describing - we're using a built-in port on a desktop, though.

-Danny

I have this problem with a built-in serial port on a laptop. I run the camera from a 7.2 v battery and monitor the battery voltage; the voltage does not change during operation. If the current draw were too high, the voltage would drop. 7 v should be OK, since the camera has a 5 v regulator on board.

For details, see http://www.chiefdelphi.com/forums/sh...ad.php?t=42631

[Joe Hershberger]

Originally Posted by heydowns

Our team also continually sees the problem that the original poster is talking about.
We have used two different backup batteries, both fully charged. The problem was still observed.

Note that when I say "continually", I mean that we consistently get the problem on an inconsistent basis. Sometimes we get it immediately at the start of the work session and it lasts through several restarts of LabView and RC/Camera power cyclings. Other times, things work for a little while (we can grab 2-3 frames), but then we get the OP's problem of LabView not responding to input, not getting the frame that was asked for, and the frame grab progress bar continually filling up and starting over. This persists until we restart the LabView CMUCam GUI application. After restarting, it might or might not occur again immediately. It is consistently inconsistent as to when it works.

If it is really thought to be a power supply issue, then I will try to make an effort to rig up a non-battery supply and run the camera off that. Maybe the OP or someone else having the same problem can do the same (just use any standard DC power supply that fits the specs outlined in the CMU Cam docs).

Hope this helps to diagnose the problem.

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

[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 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

[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

[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.

[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