Some questions to help us troubleshoot:
1)How crashed is your computer when it crashes?
Blue Screen Of Death crashed? If you don't know about BSOD then that
is when your computer presents a blue screen (white in XP) and tells
you that the system is halted, gives you a register dump and the
memory address where it stopped (all of which is useless unless you
are an assembly language wizard) and then you have to reboot the
machine.
Application error that kills LabVIEW.exe? Usually a pop-up MSGBOX
style dialog box will appear with a such and such error occurred in
LabVIEW.exe or another application and an OK button.
VI Slows to a crawl w/hourglass in the app window? Program doesn't
stop executing, it just stops responding to user inputs.
LabVIEW error cluster error that causes the VI to quit?
2) What O/S are you running? Win 3.1, Win 95, Win 98, Win NT 3.1, Win
NT 3.5, Win NT 4.0, Win2000, WinME, WinXPHome, Win XPPro?, Linux?, Mac
O/S?
In the Microsoft family, WinNT and Win2000 are by far the most stable
and reliable of the various versions of Windows with Win95 and Win98
having a lot of problems running for long periods of time. Make sure
that you get WinNT 4.0 updated to service pack 6 if you are still
using 4.0 but haven't updated the service pack level yet. There were
quite a number of problems with it when it first came out that have
since been cured.
3) Have you run the LabVIEW VI profiler yet? This will point out
memory leaks that are due to dynamically built arrays using shift
registers etc. or appending to strings, or improper IMAQ management,
etc.
4) Have you brought up the task manager and looked at the memory
allocated for LabVIEW.exe and for the whole system as well? Is it
growing? Sometimes there can be memory leaks that don't show in the
profiler that will show in the task manager when you look. These can
be due to bugs in LabVIEW itself or some driver for some hardware you
are using, etc.
If you are not running NT or a later derivative, then you won't have
task manager available but you can get diagnostic tools that are very
similar to task manager from off the web.
5) How much memory do you have in your PC? How fast is your PC? What
does the CPU % usage look like under task manager when you first start
your app? If it is running >40% CPU usage for any significant amount
of time at the start then perhaps your PC is overloaded with work and
you need a faster PC or your code needs redesigning. I like data
acquisition systems to operate <25% generally speaking. This number
seems to improve the reliability of the code that is running on them.
6) How much H/D space is available? You say you are writing data to
files. Your h/d space isn't running out is it?
7) Is it possible to run one instrument at a time for several hours to
see if it is a particular instrument that is causing the crash? Make
sure that your GPIB cards are properly configured so that they don't
share resources with any other devices(IRQ, DMA, memory addresses,
etc.) It may be possible that they behave fine most of the time even
with shared resources but if they ever try to send a command
simultaneously and they share resources, they could "collide" and
crash your PC. You can check all this out in the control panel and/or
MAX.
😎 Is it possible that your serial port is getting hung up after
running a long period of time? Serial port UARTS are notoriously
finicky especially over longer line lengths and higher data rates. It
could be that your serial instrument is locking up your app or your PC
serial port is locking up your app and causing the crash. Can you put
a serial port analyzer in between your serial instrument and your PC
to see what's going on when it crashes?
9) Are you trying to read or write to the serial port in more than one
thread or while loop or dynamically launched vi? If you are you MUST
protect the serial port access with a semaphore or a VISA resource
lock. You CANNOT use a boolean global to protect access. Regular
globals aren't atomic and you can have race conditions that result in
unintended serial port collisions between differen threads. I have
seen this lock up multi-threaded serial programs before to the point
of requiring rebooting.
This problem can be especially frustrating if you haven't done
multi-threaded before. The port won't necessarily lock up right away
or at the same time every time. You MUST make sure that serial port
access is limited to ONLY ONE execution thread at a time.
10) Is there another application or service running in the background
with your application that may be trying to access the serial port or
GPIB cards when you aren't expecting it? This could cause a collision
that could crash your system as well.
Douglas De Clue
LabVIEW developer
ddeclue@bellsouth.net
Yan wrote in message news:<50650000000800000018520000-1023576873000@exchange.ni.com>...
> My VI is using DAQ6025e and GPIB cards, it is countiniusly writing
> data to files and talking with 2 GPIB instruments and one Serial
> instrument. Sudenly after 3 hours of perfect working it is crash my
> computer.
> Does any body know why ??? Help? S.O.S?
