LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Failures in image.c???

Hi,
I'm fairly new to Labview, as I've only been using it for around 6 months
or so. I'm currently working with LV 5.1.1, and I've been trying to work
out how to create an animated picture on the front panel.
I've tried using a picture listbox, with imported bitmaps or jpegs, and it
seems to work pretty well. However, if I leave it running over night, it
always crashes, with the message "Failure in image.c at line xxx". If I can't
sort this out, I'm going to have to remove the whole sequence from the program,
which isn't going to please the customer.
I've tried NI support, they claim it is a problem with Windows (I'm using
Win 95), I've tried Microsoft - they say it is a problem with the graphics
card drivers, and I've tried the
graphics companies (NVidia, ATi and Matrox)
- they claim it is a problem with LabView.
Does anyone know how to solve or get round this problem?
Cheers,
Ben
0 Kudos
Message 1 of 13
(3,420 Views)
Ben,

Have you tried to look at the memory problem? The images should be disposed
from the memory eventhe window is closed. You might done this. I do not
know any other options. Good luck.

"Ben" wrote:
>>Hi,> I'm fairly new to Labview, as I've only been using it for around
6 months>or so. I'm currently working with LV 5.1.1, and I've been trying
to work>out how to create an animated picture on the front panel.>I've tried
using a picture listbox, with imported bitmaps or jpegs, and it>seems to
work pretty well. However, if I leave it running over night, it>always crashes,
with the message "Failure in image.c at line xxx". If I can't>sort this out,
I'm going to have to remove the whole sequence from the program,>which isn't
going to please the cu
stomer.>I've tried NI support, they claim it is a problem
with Windows (I'm using>Win 95), I've tried Microsoft - they say it is a
problem with the graphics>card drivers, and I've tried the graphics companies
(NVidia, ATi and Matrox)>- they claim it is a problem with LabView.>Does
anyone know how to solve or get round this problem?>Cheers,>Ben
0 Kudos
Message 2 of 13
(3,420 Views)
I'm not quite sure what you mean Hugh,
as I've said I'm still fairly new to LabView. I have noticed that the amount
of memory used on the system as the pictures cycle gradually increases, until
it is around 800K to 1Mb greater when the program crashes than when it started
- is this what is causing the problem? If so, is there some way I can prevent
it from happening?
Thanks,
Ben


"Hugh" wrote:
>>Ben,>>Have you tried to look at the memory problem? The images should be
disposed>from the memory eventhe window is closed. You might done this.
I do not>know any other options. Good luck.>>"Ben"
0 Kudos
Message 3 of 13
(3,420 Views)
Ben wrote in message
news:39dafa9a@newsgroups.ni.com...
>
> I'm not quite sure what you mean Hugh,
> as I've said I'm still fairly new to LabView. I have noticed that the
amount
> of memory used on the system as the pictures cycle gradually increases,
until
> it is around 800K to 1Mb greater when the program crashes than when it
started
> - is this what is causing the problem? If so, is there some way I can
prevent
> it from happening?
> Thanks,
> Ben

It may be that you're keeping all the pictures you use in memory, so they
pile up and eventually no more memory can be allocated and the program dies.

Another possibility; a while ago a problem was found and discussed in this
group (check DejaNews) with memory leaks in the P
NG file utilities under
Labview5. They're fixed in Labview 6. What happens is the low level
functions under the PNG VIs don't give back all the memory they use, and
again eventually you run out of memory. Perhaps this also affects JPEG
operations- I don't know.

If you put the VI somewhere people can leech it then there might be a
glaring mistake causing it that can be pointed out.
0 Kudos
Message 4 of 13
(3,420 Views)
Ben,

Craig has explained what I meant by memory problem. You can try to free
up the memory by using vi called IMAQ dispose that can be found in vision
palette in the first group named MANAGEMENT. Good luck.

Hugh

"Craig Graham" wrote:
>>Ben wrote in message>news:39dafa9a@newsgroups.ni.com...>>>>
I'm not quite sure what you mean Hugh,>> as I've said I'm still fairly
new to LabView. I have noticed that the>amount>> of memory used on the system
as the pictures cycle gradually increases,>until>> it is around 800K to 1Mb
greater when the program crashes than when it>started>> - is this what is
causing the problem? If so, is there some way I can>prevent>> it from happening?>>
Thanks,>> Ben>>It
may be that you're keeping all the pictures you use in
memory, so they>pile up and eventually no more memory can be allocated and
the program dies.>>Another possibility; a while ago a problem was found and
discussed in this>group (check DejaNews) with memory leaks in the PNG file
utilities under>Labview5. They're fixed in Labview 6. What happens is the
low level>functions under the PNG VIs don't give back all the memory they
use, and>again eventually you run out of memory. Perhaps this also affects
JPEG>operations- I don't know.>>If you put the VI somewhere people can leech
it then there might be a>glaring mistake causing it that can be pointed out.>>>
0 Kudos
Message 5 of 13
(3,420 Views)
Thanks for the advice,
I'm trying to use the IMAQ dispose option right now, although it usually
takes several hours to crash, so I won't know whether it works or not until
tommorow.
As for my program itself, it is simply a picture Ring control, inside a
for loop, connected to the index (to cycle through the sequence), which is
itself inside a While loop so I can turn it off. There is a Wait until Next
Multiple set to 50 mS inside the For Loop. Not exactly complex, which is
why I couldn't understand why it kept crashing.
Ben
0 Kudos
Message 6 of 13
(3,420 Views)
You can speed up the tests removing the 50 ms wait and feed few copies of
the picture ring. To test if it is a video driver problem, set your display
driver to plain old generic VGA, which is very stable, and test the VI. If
it does not crash, it is a video driver problem.

Jean-Pierre Drolet


"Ben" a écrit dans le message news:
39dc8769@newsgroups.ni.com...
>
> Thanks for the advice,
> I'm trying to use the IMAQ dispose option right now, although it usually
> takes several hours to crash, so I won't know whether it works or not
until
> tommorow.
> As for my program itself, it is simply a picture Ring control, inside a
> for loop, connected to the index (to cycle through the sequence), wh
ich is
> itself inside a While loop so I can turn it off. There is a Wait until
Next
> Multiple set to 50 mS inside the For Loop. Not exactly complex, which is
> why I couldn't understand why it kept crashing.
> Ben
0 Kudos
Message 7 of 13
(3,420 Views)
That is the advice NI gave me,
but it didn't make much difference unfortunately, it simply took longer
to crash. And to be honest, I can't see it being a problem with the graphics
drivers really, I've tried it on 3 different machines with an ATi Rage Light
8Mb graphics card, a Matrox MGA-100, and an Nvidia TNT2 M64. If it crashes
with all 3, then surely it can't be the graphics drivers?
Ben


"Jean-Pierre Drolet" wrote:
>You can speed up the tests removing the 50 ms wait and feed few copies of>the
picture ring. To test if it is a video driver problem, set your display>driver
to plain old generic VGA, which is very stable, and test the VI. If>it does
not crash, it is a video driver problem.>>Jean
-Pierre Drolet>>>"Ben"
a écrit dans le message news:>39dc8769@newsgroups.ni.com...>>>> Thanks for
the advice,>> I'm trying to use the IMAQ dispose option right now, although
it usually>> takes several hours to crash, so I won't know whether it works
or not>until>> tommorow.>> As for my program itself, it is simply a picture
Ring control, inside a>> for loop, connected to the index (to cycle through
the sequence), which is>> itself inside a While loop so I can turn it off.
There is a Wait until>Next>> Multiple set to 50 mS inside the For Loop. Not
exactly complex, which is>> why I couldn't understand why it kept crashing.>>
Ben>>
0 Kudos
Message 8 of 13
(3,420 Views)
Ok,
I ran the IMAQ dispose test last night, unfortunately it doesn't stop the
machine from crashing. Upgrading to LabView 6 is not an option either, LabView
5.1f1 is expicitly specified in the functional specification (and my customer
isn't prepared to fork out 1000 pounds for a bug fix). Is it possible to
use an ActiveX control to simulate the animation frames (i.e. program the
animation in VB and then use it to create an ActiveX control, and place the
activeX control in LabView)? Would this get around the problem, and if it
would, does anyone know if such a control has already been made?
Thanks,
Ben

"Ben" wrote:
>>That is the advice NI gave me,> but it didn't make much difference unfortunately,
it simply took longer>to crash. And to be honest, I can't see it being a
problem with the graphics>drivers really, I've tried it on 3 different machines
with an ATi Rage Light>8Mb graphics card, a Matrox MGA-100, and an Nvidia
TNT2 M64. If it crashes>with all 3, then surely it can't be the graphics
drivers?>Ben>>>"Jean-Pierre Drolet" wrote:>>You
can speed up the tests removing the 50 ms wait and feed few copies of>the>picture
ring. To test if it is a video driver problem, set your display>driver>to
plain old generic VGA, which is very stable, and test the VI. If>it does>not
crash, it is a video driver problem.>>Jean-Pierre Drolet>>>"Ben" >a
�crit dans le message news:>39dc8769@newsgroups.ni.com...>>>> Thanks for>the
advice,>> I'm trying to use the IMAQ dispose option right now, although>it
usually>> takes several hours to crash, so I won't know whether it works>or
not>until>> tommorow.>> As for my program itself, it is simply a picture>Ring
control, inside a>> for loop, connected to the index (to cycle through>the
sequence), which is>> itself inside a While loop so I can turn it off.>There
is a Wait until>Next>> Multiple set to 50 mS inside the For Loop. Not>exactly
complex, which is>> why I couldn't understand why it kept crashing.>>>Ben>>
0 Kudos
Message 9 of 13
(3,420 Views)
Ben wrote in message
news:39dd96a3@newsgroups.ni.com...
>
> Ok,
> I ran the IMAQ dispose test last night, unfortunately it doesn't stop
the
> machine from crashing. Upgrading to LabView 6 is not an option either,
LabView
> 5.1f1 is expicitly specified in the functional specification (and my
customer
> isn't prepared to fork out 1000 pounds for a bug fix). Is it possible to
> use an ActiveX control to simulate the animation frames (i.e. program the
> animation in VB and then use it to create an ActiveX control, and place
the
> activeX control in LabView)? Would this get around the problem, and if it
> would, does anyone know if such a control has already been made?
> Than
ks,
> Ben

How about a test where you load, say, 10 images at the start of your program
and keep them buffered as picture objects- perhaps in an array of picture
objects within your program- and then just leave the machine copying them
one by one to a front panel picture indicator as quickly as possible? If it
doesn't crash overnight, then the problem is with the repeated loading of
the files and a memory leak in the picture reading C code, as others have
found.

If this method works fine, then you could write a utility program that loads
all your images and then saves them as some file format of your own devising
which can be loaded and saved using just the standard file manipulation
functions.
0 Kudos
Message 10 of 13
(3,420 Views)