Lo labview freezes up

Hello everyone,
I'm having some trouble with LabVIEW freezing up as I scroll across my front panel trying to locate indicators.  I'll attach the VI and hopefully some of you can test it out for me, or let me know why this peculiar behavior is occurring.  The VI isn't even running, LabVIEW just doesn't respond when I scroll to the far left of the front panel to locate some indicators.  I'm using LabVIEW 8.2.1, and there is no trouble in terms of memory or running the program on my computer...it is more than capable of running very detailed programs.
Thanks in advance,
Attachments:
prism analysis 2-11.vi ‏531 KB

Hi Steve,
I could load your vi in LV8.5 and found some controls/indicators to the very left of the front panel (using the navigation window , ctrl-shift-n). I moved them back the to rest of your front panel. I could save the vi in LV8.5...
But then I couldn't save the vi back to LV8.2 - I get an error message from Labview "error in memory.cpp blabla"...
In LV8.2 I get the same error as you - as soon as trying to scroll the front panel LV freezes...
So I attach the LV8.5 version with moved front panel items - maybe someone else has an idea
Best regards,
GerdW
CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
Kudos are welcome
Attachments:
prism analysis 2-11_LV85.zip ‏280 KB

Similar Messages

  • Labview freeze when accessing a custom menu with data on the clipboard

    This one has got me stumped:  When selecting a custom menu item with data on the clipboard the GUI freezes.  Freezes are longer for more data and longer for older versions of Labview.  I wrote the test code, attached, but the example "Menu Selection Demo.vi" shows the same behavior.
    Running Labview 2011 here are some freeze delays for my laptop (a bit slower machine) with various amounts of text data on the clipboard:
    Clipboard size        Delay
    1.3MB                   2.1 sec
    2.6MB                   4.9 sec
    3.8MB                   17.2 sec
    14MB                    253.3 sec
    The delay appears to be non-linear.  A doubling of the clipboard data size more than doubles the delay and a tripling of the clipboard data size produces a delay of almost 10X!  Things are also much, much worse on my ancient version 8.2.1 (over a 40 second freeze for 1.3MB and it goes up from there).
    Note that the freeze also occurs on programs with a custom menu when exiting.  This would seem to suggest it might have something to do with the timeout, but why timeout should vary with clipboard size and not with the value wired to it makes this feel even more like a bug in the custom menu functionality.
    This seems to be related to known issues in Labview 2011 #39604 49UBP4LE (http://www.ni.com/white-paper/13168/en#39604_by_Da​te) that was first reported in version 8.2.1.  This known issue relates to Labview freezing when large amounts of data are copied from Labview to the clipboard.  No fix has been implemented since this was originally reported in 2007.
    This freeze also occurs when shortcuts to menu items (such as Ctrl + L) are used when large amounts of data are on the clip board.
    Thus far this has been 100% repeatable and I have not been able to find a way around it.  I also haven't found anything else similar on the forums or on the web.  It appears to be a GUI freeze with Labview still running in the background, which is also odd.
    My work-arounds at this point are either to not use the clipboard (bad), programatically clear the clipboard several times each second (worse) or remove all custom menu functionality and replace those functions with onscreen controls.  So, for now, I'm removing custom menu items because my users need the clipboard and I can't have massive delays making my data acquisition code look crashed.
    Any ideas would be helpful.  This one has me scratching my head...
    Attachments:
    Menu_Clipboard_Lv2011.vi ‏17 KB

    Well, doing Microsoft Word, Excel and what else on a computer that is used to run an important production test, is a very bad idea. There is no way that you can guarantee, that one of these applications is not causing some interruption to the currently running time critical task. Word and Excel and just about any other computer application can crash, lock up the computer or eat your breakfast while you are doing seemingly harmless things.
    The issue with the clipboard in LabVIEW is indeed a problem that exists for a long time and I hope they fix it sometime, but the fact remains, that you should NEVER use a computer for other tasks while you run a test or other manufacturing related application on it, when a failure of that application can cost you more than a few pennies.
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • Labview freezes, and stops responding each 10th run or so?

    We have a fairly complicated labview program that most of the time runs normally, but once every 5th to 10th restart or so the program freezes so much that it cannot be stopped even by pressing the red stop button "abort execution", I have to use ctrl-alt-del to shut down the program. I heard something like this can occur if you have loops without time delay, so I included such in all loops.
    The program is a forever loop of a stacked sequence 1-5, and the last thing that happens in one run is a button that finishes a loop in the 5th sequence. When I press this button is stays in the "on" position, and everything is stuck.
    We run labview 8.2 on winXP, and the program is not compiled, but run in the development system.
    Any ideas? Why does it only happen sometimes?
    Ola

    Here is one I just threw together. It is not neat and clean just a quick and dirty to show the basics. have a look and if you have any questions let me know
    Joe.
    "NOTHING IS EVER EASY"
    Attachments:
    statemachine.llb ‏80 KB

  • Labview freezes during installation

    I have an enduser that I am setting up a repurprosed computer.  The computer was originally used by a summer marketing intern so there was never any NI software.  I was setting it up, and installed 8.6 by accident as the engineer then instructed me he preferred 2010 sp1.  I ran uninstall from the CLI as the GUI didnt have a way I found to uninstall it completely with one swoop.
    Yesterday it froze during the drivers disc, but now, I redid it after the uninstall and now it froze on the disc two - product 14 of 16: Currently installing Compilation Tools for Virtex-II FPGA Devices.  It has been sititng like this for the past hour. 
    The end user does have Xilinx Webpack previously installed, v.14. 
    Office 2007.
    Lotus Notes 8.5.3
    Firefox
    Windows 7 x64
    I am using the Labview 2010 SP1 Platform DVD set
    Any advice is greatly appreciated.
    Thanks and regards

    Exactly what happens when it "freezes"? Or, how do you know it freezes?
    If the rest of the code takes negligible time to execute, the 250 ms Wait in the last frame of the innermost sequence structrure will require >182 seconds to complete the nested for loops.  There are no indicators in those loops, so it would not be obvious whether the program was still running normally or not during those 3 minutes.
    Try putting indicators on the "i" terminals of the for loops. That will tell you whether the loops are executing, and when it freezez, you will be able to see how many iterations have completed.  Also put error indicators inside the loop so that you can see if any errors are reported. Unfortunately the Velmex driver does not report errors.
    Highlight Execution is useful for finding problems in code. But if the freeze occurs after several hundred iterations of the inner loop, you will grow old waiting to see what happens. A combination of Breakpoints and Highlight Execution is more versatile for troubleshooting loops.
    Sequence structures are almost never the appropriate choice for well written LabVIEW code. I would probably create several subVIs wrapping around the Velmex driver, with each subVI perfoming one task. Include error in and error out terminals (even if the Velmex driver does not return errors for most tasks) so that you can use dataflow for controlling the order of execution.
    Lynn

  • LabView Freezing when opening files

    After upgrading to Labview 8.2. It will open but when I go to file and open, or simply press open on the LV screen the program instantly freezes, can anybody help?
    Thanks
    Peter

    HI Peter
    I suggest you try a full repair of LabVIEW, i have seen something like this before and that seemed to do the trick. If you go to Add/Remove programs in the Control Panel and select National Instruments Software, select LabVIEW 8.20 and click repair. It may take anything upto 20mins but give it a try.
    Let me know how you get on
    Regards
    YatinM
    NIUK & Ireland

  • Labview freezes when opening a modified file

    Hello,
    I'm somewhat new to Labview, and yesterday encountered a strange problem.  While working on a friend's computer (version 8.2.1), I opened one of their files, re-saved the file with a new name, made some changes, and it seemed to run just fine.  However, when I closed the file and tried to re-open it, Labview froze and wouldn't open the file (actually, it started to load, and the tool palette and some parts of the window opened, but then it froze).  I can open their original file just fine, but the modified file won't open.  I've tried copying the file to my own computer, but it won't open there either.  Any ideas?..
    Thanks.

    Are there any controls that are similar to the VISA Resource Name control - there are also versions for DAQ, IVI, etc. I have seen significant delays (on the order of several minutes) related to opening front panels containing these types of controls. This isn't exactly the situation where I saw it (I was upgrading existing code to LV8.2.1) but it could be a similar effect.
    Mike...
    Certified Professional Instructor
    Certified LabVIEW Architect
    LabVIEW Champion
    "... after all, He's not a tame lion..."
    Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

  • Changing time between data samples causes Labview 6.1 to freeze

    When using labview to record temperature values from an RTD, labview freezes when I switch the data time interval from 7 seconds, to 10 min. I don't know why this is. Any ideas?

    What hardware are you using?
    What are you using to set a time interval? If you just say "wait 10 minutes" it may need the 10 minutes before it wakes up and responds to any new clicks. OTOH if you have a loop with say, a 0.1 second loop time and a "are we there yet?" to trigger the next recording, LV can respond to clicks and repaints in .1 second.
    Les

  • VISA Ressource Name Constant freezes Labview

    I have a compelte new project.
    If I drop a VISA Ressource Name Constant from the I/O Pannel onto the work
    area, my compelte LabVIew freezes.
    This happens only with the Hardware attached.
    The VISA interactive control works fine !
    Does anybody have a clue why ? Is the access and resonse times to long ? Is
    it a IRQ or Labview peoblem ? Why VISA interactive control works without
    problems ?
    Please Help !
    Thanks for your effort !
    1. viGetAttribute (0x0015D988,0x3FFF018F,VI_TRUE)
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:29:58.774 Call Duration: 00:00:00.000
    Status: 0 (VI_SUCCESS)
    2. viGetAttribute (0x0015D988,0x3FFF0190,0 (0x0))
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:29:58.774 Call Duration: 00:00:00.000
    Status: 0 (VI_SUCCESS)
    3. viSetAttribute (0x0015D988,0x3FFF0190,2 (0x2))
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:29:58.774 Call Duration: 00:00:00.000
    Status: 0 (VI_SUCCESS)
    4. viFindRsrc (0x0015D988,"?*INSTR",0x0015D9C8,4 (0x4),"COM1")
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:29:58.774 Call Duration: 00:00:09.114
    Status: 0 (VI_SUCCESS)
    5. viFindNext (0x0015D9C8,"COM3")
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:07.888 Call Duration: 00:00:00.000
    Status: 0 (VI_SUCCESS)
    6. viFindNext (0x0015D9C8,"LPT1")
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:07.888 Call Duration: 00:00:00.000
    Status: 0 (VI_SUCCESS)
    7. viFindNext (0x0015D9C8,"GPIB0::5::INSTR")
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:07.888 Call Duration: 00:00:00.010
    Status: 0 (VI_SUCCESS)
    8. viClose (0x0015D9C8)
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:07.898 Call Duration: 00:00:00.000
    Status: 0 (VI_SUCCESS)
    9. viSetAttribute (0x0015D988,0x3FFF0190,0 (0x0))
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:07.898 Call Duration: 00:00:00.000
    Status: 0 (VI_SUCCESS)
    10. viGetAttribute (0x0015D988,0x3FFF018F,VI_TRUE)
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:07.898 Call Duration: 00:00:00.000
    Status: 0 (VI_SUCCESS)
    11. viGetAttribute (0x0015D988,0x3FFF0190,0 (0x0))
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:07.898 Call Duration: 00:00:00.000
    Status: 0 (VI_SUCCESS)
    12. viSetAttribute (0x0015D988,0x3FFF0190,2 (0x2))
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:07.898 Call Duration: 00:00:00.010
    Status: 0 (VI_SUCCESS)
    13. viFindRsrc (0x0015D988,"?*INSTR",0x0015D9C8,4 (0x4),"COM1")
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:07.908 Call Duration: 00:00:09.063
    Status: 0 (VI_SUCCESS)
    14. viFindNext (0x0015D9C8,"COM3")
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:16.971 Call Duration: 00:00:00.000
    Status: 0 (VI_SUCCESS)
    15. viFindNext (0x0015D9C8,"LPT1")
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:16.971 Call Duration: 00:00:00.000
    Status: 0 (VI_SUCCESS)
    16. viFindNext (0x0015D9C8,"GPIB0::5::INSTR")
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:16.971 Call Duration: 00:00:00.000
    Status: 0 (VI_SUCCESS)
    17. viClose (0x0015D9C8)
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:16.971 Call Duration: 00:00:00.010
    Status: 0 (VI_SUCCESS)
    18. viSetAttribute (0x0015D988,0x3FFF0190,0 (0x0))
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:16.981 Call Duration: 00:00:00.000
    Status: 0 (VI_SUCCESS)
    19. viGetAttribute (0x0015D988,0x3FFF018F,VI_TRUE)
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:16.991 Call Duration: 00:00:00.000
    Status: 0 (VI_SUCCESS)
    20. viGetAttribute (0x0015D988,0x3FFF0190,0 (0x0))
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:16.991 Call Duration: 00:00:00.000
    Status: 0 (VI_SUCCESS)
    21. viSetAttribute (0x0015D988,0x3FFF0190,2 (0x2))
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:16.991 Call Duration: 00:00:00.000
    Status: 0 (VI_SUCCESS)
    22. viFindRsrc (0x0015D988,"?*INSTR",0x0015D9C8,4 (0x4),"COM1")
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:16.991 Call Duration: 00:00:09.053
    Status: 0 (VI_SUCCESS)
    23. viFindNext (0x0015D9C8,"COM3")
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:26.044 Call Duration: 00:00:00.010
    Status: 0 (VI_SUCCESS)
    24. viFindNext (0x0015D9C8,"LPT1")
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:26.054 Call Duration: 00:00:00.000
    Status: 0 (VI_SUCCESS)
    25. viFindNext (0x0015D9C8,"GPIB0::5::INSTR")
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:26.054 Call Duration: 00:00:00.000
    Status: 0 (VI_SUCCESS)
    26. viClose (0x0015D9C8)
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:26.054 Call Duration: 00:00:00.000
    Status: 0 (VI_SUCCESS)
    27. viSetAttribute (0x0015D988,0x3FFF0190,0 (0x0))
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:26.054 Call Duration: 00:00:00.000
    Status: 0 (VI_SUCCESS)
    28. viGetAttribute (0x0015D988,0x3FFF018F,VI_TRUE)
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:26.054 Call Duration: 00:00:00.010
    Status: 0 (VI_SUCCESS)
    29. viGetAttribute (0x0015D988,0x3FFF0190,0 (0x0))
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:26.064 Call Duration: 00:00:00.000
    Status: 0 (VI_SUCCESS)
    30. viSetAttribute (0x0015D988,0x3FFF0190,2 (0x2))
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:26.064 Call Duration: 00:00:00.000
    Status: 0 (VI_SUCCESS)
    31. viFindRsrc (0x0015D988,"?*INSTR",0x0012F128,0x0012F130,0x0012F01C)
    Process ID: 0x000003F8 Thread ID: 0x000005A0
    Start Time: 11:30:26.064
    Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

    Sascha:
    NI-VISA 2.x has a couple of entries in the visaconf.ini file that we have found occasionally get into a weird state. Look in the [VISA-CONFIG] section for lines that start with "RefreshFindList" and "AlwaysRefresh". Both of these should be set to 0. If they happen to be set to 1, you can manually set them back to 0.
    This would cause a symptom similar to what you describe, where LabVIEW continually polls NI-VISA and thinks it needs to continually refresh its list, which it does by calling viFindRsrc. This seemingly infinite loop continues as long as a VISA refnum is visible, on either the front panel or block diagram.
    This has been fixed for the upcoming version, NI-VISA 3.0.
    Dan Mondrik
    Senior Software Engineer, NI-VISA
    National In
    struments

  • LabVIEW 2009 sp1 not responding / crash

    Hi, 
        I seem to have developed an issue with LabVIEW whereby it freezes at a random point during execution. It is not a case of a VI freezing, rather the LabVIEW application itself ceases to work and needs to closed by task manager. What I have running at the time is a host VI that sends and receives data over a TCP connection to a real-time target on a PXI. The real-time application keeps running after the crash. The host system is also running 3D picture control showing some basic graphics. The whole system is controlled at a top level by a program written in C#  over a TCP connection but can run stand alone. When running stand alone the problem does not occur.
       The communication between the C# and LabVIEW works fine, yet at a random point during operation, LabVIEW freezes while the C# continues to work. This doesn't seem to correspond to a particular action by the C# program. I guess my question is, is there any likely culprit by which LabVIEW can be crashed by an exernal program where the only communication is via TCP that seems to work fine and where there doesn't appear to be excessive memory or CPU usage?
    Cheers. 
    Solved!
    Go to Solution.

    Having further investigated it appears to only occur as TCP exchange is taking place and the full LabVIEW application doesn't appear to have crashed, but several VIs hang and can't be closed. There are three total TCP connections running, one that links to the PXI unit, one to the C# application and one from the C# to the visual display VI that is idle when this event occurs. Does anyone know of any reason why a TCP connection can cause LabVIEW to hang? The same connection has worked numerous times before the error occurs. Appears to only happen when the 3D picture control is running.

  • LabView (8.2) hangs when using I/O operations with traditiona​l NI-DAQ 7.4.4 after aborting LabView program

    Hello!
    We have the following problem:
    LabView (8.2) hangs when using I/O operations with traditional NI-DAQ 7.4.4 after aborting LabView program
    We freshly installed LabView 8.2 (2006) and NI-DAQ 7.4.4 on a PC running Windows XP (Service Pack 3). We built a larger vi that remotely controls a traditional NI-DAQ card (AT-AO-10) on a second PC via NI-VISA 5.0.3. We were successfully running this program until a power failure caused the first computer to crash. After this crash we were unable to start the program again: LabView freezes while loading the vi. LabView itself can be started but freezes when adding I/O operations from the NI-DAQ palette to a block diagram.
    We have tried to re-install NI-DAQ 7.4.4, but it did not help. We then re-installed all NI software, but still no improvement. In the end we decided to reinstall ALL software, first Windows XP, then LabView and finally NI-DAQ 7.4.4. This worked. However, after a few days of running the program we had to abort LabView via Windows Task manager and afterward we again experienced the same problem as before: LabView freezes when loading the program.
    Obviously, we cannot afford to reinstall Windows every time. Are there any known Windows XP / NI-DAQ issues that might cause the freezing of LabView? We would be very grateful for any idea.
    Best regards,
    Matthias

    Hello Sprice,
    Browse the shipping examples according to “Directory Structure” and then select
    DAQ to find the Traditional DAQ examples. 
    There a lot of examples that are written for counters (Counter >>
    daq-stc.llb >> Count Edges (DAQ-STC).vi). 
    What kind of signals are your photons creating?  Are they TTL compatible at a certain
    frequency?  You don’t care about overwriting
    your buffer?
    Respectfully,
    Rob F
    Test Engineer
    Condition Measurements
    National Instruments

  • LabVIEW locks up when importing my .dll

    Hey there, I'm using LabVIEW 12.0f1. I created a .dll for use in TestStand, and when I tried to wrap it in LabVIEW using the import shared library functionality, I get dependency problems with other .dlls (not found), and I'm not really sure why since the .dll works fine as-is in Teststand. I copied the .dlls it wanted into my Windows folder, and afterwards when I try to open the VI, LabVIEW freezes and I have to forcibly end the process. Now I also have the same issue when LabVIEW tries to create the VIs at the end of the import wizard, for the same reason. Is there any kind of debugging tool or simple thing I'm missing that could resolve this issue?

    bclark wrote:
    I get dependency problems with other .dlls (not found), 
    What are the names of the "other" dlls?
    LabVIEW Champion . Do more with less code and in less time .

  • LabVIEW 2013 locks up while loading new VI

    When attempting to load an existing VI while a project is open and the new VI caues conflicts LabVIEW shows a warning window.  If LabVIEW has a loading window open when the conflicts message appears then LabVIEW becomes unresponsive on all of its windows except for the help window.  The buttons appear to function but nothing happens.  I can move the Loading ... window around but none of the others.  I left it for 30 minutes yesterday (different VI that I was trying to load) but no joy.  I had to kill LabVIEW and lost my work.  Same situation today.  These were both examples I downloaded from this forum.
    How can I avoid this problem in the future?
    Thank you.
    See attached image
    Windows 7 64-bit
    LabVIEW 2013, updated to current
    Attachments:
    LabVIEW Hang.jpg ‏83 KB

    The problem has reoccurred 3 times this morning (see attached image for the 3rd lockup).  All with local files.  I have a LabVIEW project open, when I open a VI outside of the project (using windows explorer) I sometimes get the mxLvGetFilePathBatch.vi loading message and then LabVIEW freezes.  mxLvGetFilePathBatch loading message is the last apparent LV action every time before the lockup  This happens when the loading window opens while another LabVIEW related popup is showing.  See attached image where I was trying to examine a vi that is in my user.lib while LabVIEW was open.  In this case the VI is referenced by the project (strict static vi reference) but that is not always the case.  The first two lockups this morning were with nonproject VIs that use some of the same user.lib VIs as the project.  My user.lib is at the default location in the LabVIEW program directory.
    The attached txt file is in html format, it is a table listing my installed packages.  An export from JKI package manager, massaged with excel for readability.
    I would appreciate any ideas on how to proceed with debugging this problem.
    Attachments:
    7-15-14_3rd_hang.jpg ‏50 KB
    InstalledPackages.html.txt ‏10 KB

  • Topmost window freezes

    Hi everyone,
    I have a vi that becomes topmost when an event occurs. However, if there is some pop-up windows open, dialog box or other functions called by the top-most vi, and if the event happens while the pop-up window is open, it gets freeze. The whole LabVIEW freezes up.
    I use winutil, topmostwindow.vi. Is it a bug or am I missing something?
    Thanks~

    When creating event case, clicking out the checkbox which is on the buttom of the dialog , "Lock front panel until the event case for this event completes"  may solve your pro.
    Best Regards

  • VISA-relat​ed LV freeze

    I'm having an issue with LabVIEW crashing when opening or running a VI that has a VISA resource constant on the block diagram.  Once this problem occurs, even rebooting the OS does not fix the problem.  It is not until I reinstall the VISA drivers that the problem is fixed, although the fix is only short-term.  I've isolated the problem to where I can open up a new VI, drop a VISA resource constant on the block diagram, and crash LabVIEW.
    I am using a USB hub as well as USB-to-serial devices.
    Here's what I'm running:
    LV 7.1.1
    Win XP SP3
    NI-VISA 4.5

    Have you tried this?
    The problem with LabVIEW freezing is probably due to network problems and perhaps some firewall issues. This is a known issue and a workaround to get a working solution is to use a string constant or control instead of a VISA resource name constant or control.
    The resource name should adhere to the following format: GPIBx::y::INSTR, where x is the GPIB Interface Number, and y is the Primary Address.
    You should then be able to perform basic VISA write and read functions, as well as other functions such as the lock asynchronous and unlock.
    National Instruments

  • Labview frozen

    Hello,
    I am running Labview for acquisition (with a NI DAQ card) under XP. Typically, I acquire 2048 sample at 100000 Hz every 100 ms (10 Hz), but sometimes Labview freezes for a couple of seconds probably because XP requires CPU time.
    How can I deactive any process that I do not need to let run Labview properly ?
    I already disconnect the internet but it does not help.
    I do not run any printer but I need the serial line to talk to an instrument.
    I already try to prioritize some critical sub VIs (calculation).
    Regards.

    Hi,
    You are able to check your computer's processor usage on the Task Manager. Reference this to a time when your application is not running and when it is running to see how much memory it uses.
    Within LabVIEW, under Tools >> Profile >> Performance and Memory, you are able to see what sort of time each of your SubVI uses and also the memory usage.
    These tools should help you narrow your slow processing down to a more specific cause. On a side note, what version of LabVIEW are you using on what operating system and how big is your memory (RAM)?
    Regards,
    CLA | LabVIEW 7.1... 2013
    www.renishaw.com

Maybe you are looking for