LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabView 2010F2 Not Responding

Labview does not crash -- it just hangs up for a period of time after every attempt to save and shows "Not Responding" it the title bar. It does not generate the screens in the link provided. 

0 Kudos
Message 11 of 30
(1,904 Views)

Lets talk more specifics then:

Which kind of VIs are you working on when this happens? Any VI? Just large VI's?

Do you make a selection to clean up or just all of the block diagram?

Ben J.
National Instruments
Applications Engineer
0 Kudos
Message 12 of 30
(1,887 Views)

Typically I see the problem with large VIs. Nothing special in them, Just functions and other VIs. The problem occurs most often if I clean up the entire diagram or do a Save or Save All.

0 Kudos
Message 13 of 30
(1,867 Views)

Be aware there is no error or log generated in this case. Just "not responding" in the title bar.

 

I doubt any crash dumpor log will help you unless spething specil has been added to catch these events.

0 Kudos
Message 14 of 30
(1,861 Views)

Could you upload a VI which consistently freezes? 

Ben J.
National Instruments
Applications Engineer
0 Kudos
Message 15 of 30
(1,842 Views)

@B James wrote:

Could you upload a VI which consistently freezes? 


I don't have a VI that constantly freezes.

 

I can not send you any code beacause an NDA agreement prevents me from doing so.

 

You are going to have to try large BDs of your own, or start looking for internal processes inside LV that may run form several seconds without releasing the CPU.

0 Kudos
Message 16 of 30
(1,814 Views)

In terms of the cleaning of large block diagrams we have found this issue before and are working on it. Unfortunately cleaning up a large and complex block diagram is very resource intensive on top of the development environment and so these kinds of actions are prone to crash simply because of the overload on the system. One easy workaround is to clean up by selecting smaller sections. This is more in line with best practices in the sense of modularity of development. 

In terms of saving a large block diagrams I need more specifics. If I make a BD with 100 while loops and hit save, will this be enough to make it crash? What kinds of VIs/functions have you found to crash it more often? 

Ben J.
National Instruments
Applications Engineer
0 Kudos
Message 17 of 30
(1,801 Views)

The current program I am developing batch processes approximately 60-70 files one subject. I have one while loop built in with the ability to input a manual event if the right condition exists. Within the Main VI, there are about 10-12 subvi's that execute with the Stacked Sequences. The size of the total VI is 147 KB. I have been also noting that the "Not Responding" shows up when trying to edit the label of an indicator from the back panel or trying to edit an icon in a subvi. LV does not get hung up when the program runs. When the Block Diagram begins to slow down -- meaning it takes objects a few seconds to move to their new positions or to create new objects, I have to close out of LV and open it back up again. Like clockwork the "Not Responding" shows up in the title bar when I try to save before closing or clicking "Save all" before the VI closes. 

0 Kudos
Message 18 of 30
(1,780 Views)

 


@Ben J wrote:

In terms of the cleaning of large block diagrams we have found this issue before and are working on it. Unfortunately cleaning up a large and complex block diagram is very resource intensive on top of the development environment and so these kinds of actions are prone to crash simply because of the overload on the system. One easy workaround is to clean up by selecting smaller sections. This is more in line with best practices in the sense of modularity of development. 

In terms of saving a large block diagrams I need more specifics. If I make a BD with 100 while loops and hit save, will this be enough to make it crash? What kinds of VIs/functions have you found to crash it more often? 


 

I wanted to commented on one thing that Ben had mentioned.  We do not expect any certain part of LabVIEW to be prone to crash.  In cases where LabVIEW is crashing and we have identified the problem we have made adjustments to our code to either fix the problem or handle it gracefully.  We do take crashes very seriously and want to get as much information as possible. LabVIEW R&D is working with Don to try and figure out the cause of his behavior.  When we identify what is wrong we will take action to correct the problem.

 

SimpleeLaura: Do you have code that will reproduce this behavior?  Can you share it with us?  If you don't feel comfortable posting your code on a public forum you can create a service request if you have a valid service contract.  If not please contact our customer support (1-800-531-5066) and tell them that you need to report a bug.

 

Ben's workaround will proabably be beneficial to use.  You can use block diagram cleanup on smaller sections of code instead of the entire application.  In the applications that I have worked on I rarely use my main VI because the way in which you organize higher level VIs is usually different than how a smaller subVI that only handles a certain task is laid out.  The clean up tool works the best of VIs that fit our style guidelines

Regards,

Jon S.
National Instruments
LabVIEW NXG Product Owner
0 Kudos
Message 19 of 30
(1,765 Views)

I am experiencing the same problem as well when saving or building an exe for a large vi.

When saving the vi, I have the circular cursor, and the (not responding) in the title bar for more than 1 minute.

when building a .exe from a large vi, the progress bar reaches about 50% and then gives the same behaviour as for saving, not responding, for more than 2 minutes, after that it reaches 100% in matter of seconds.

 

I also had the same problem with LV2009 and LV2009sp1, and now I am using LV2010.

0 Kudos
Message 20 of 30
(1,753 Views)