silmaril Posted August 7, 2007 Report Share Posted August 7, 2007 ZITAT(konroh @ Aug 6 2007, 03:09 PM) I have a vi I am working on, and for some reason, every change I make causes the CPU to go to 100% for several seconds, for instance, dropping a constant on the block diagram or a new control on the front panel, or anything else besides just cosmetically moving things around basically locks up LabVIEW for several seconds. This is on a fast laptop (Dell M90, core2 2.0Ghz, 2gb RAM) and only happens on this one vi, which isn't very large (340kb). Any idea how to find the culprit? This happens on 2 different laptops, so I am pretty sure it is something in this particular VI... I remember this kind of effects from a 25 MB VI with > 6000 front panel elements in LV 7.1. (No! I didn't write that one! ) Can you post your VI? It's really hard to guess what might be wrong without looking at it. One thing you can try quickly: Hold down Ctrl-Shift while pressing the run button with the mouse. This causes LV to recomile the VI hierarchy. Maybe you are lucky and the VI gets broken, which would show you the culprit. Quote Link to comment
crelf Posted August 7, 2007 Report Share Posted August 7, 2007 QUOTE(konroh @ Aug 6 2007, 11:09 PM) ...every change I make causes the CPU to go to 100% for several seconds... Hey Doug - is it in a format that you can post to the thread? Quote Link to comment
konroh Posted August 7, 2007 Report Share Posted August 7, 2007 QUOTE(Ben @ Aug 6 2007, 09:53 AM) Please read through this thread on the NI forums.http://forums.ni.com/ni/board/message?boar...=209054#M217418 There are a numbr of work-arounds listed there for what NI has logged as a bug to try and fix the edit speed. Ben I read that thread, looks like this is a somewhat common problem, I do have typedefs, case structures, and event structures in this code. I have checked each subVI and they all seem fast, I will keep checking various things that appear in that posting... QUOTE(silmaril @ Aug 6 2007, 09:55 AM) I remember this kind of effects from a 25 MB VI with > 6000 front panel elements in LV 7.1. (No! I didn't write that one! ) Can you post your VI? It's really hard to guess what might be wrong without looking at it. One thing you can try quickly: Hold down Ctrl-Shift while pressing the run button with the mouse. This causes LV to recomile the VI hierarchy. Maybe you are lucky and the VI gets broken, which would show you the culprit. I did try re-compiling the vi (several times actually!) I can't really post this program, as it's the top level vi of a fairly large program, although of about 6 active projects, this is the smallest one and for some reason it's the only one with this problem! I have other vi's that are much larger and more complex that don't show this behaviour. At this point, and from looking at the posting referenced above on the NI forums, I think I have a typedef or a case structure that is misbehaving...it would be nice if there was an easy way to find it! QUOTE(crelf @ Aug 6 2007, 09:59 AM) Hey Doug - is it in a format that you can post to the thread? hey Chris, I will see if I can re-create the issue with a stripped down version of this VI, but I doubt it...and unfortunately I can't really post the entire program... ok, after deleting case by case and checking the edit speed, it seems that I have a problem with an xy graph. If i delete the graph the edit speed vastly improves (almost no noticable delay), if I replace it with another xy graph however, everything slows back down. if I create a new xy graph, and wire everything in it also slows down again...I will have to keep digging, but I think something is messed up with my xy graphs or at least the way I am using them. Quote Link to comment
orko Posted August 7, 2007 Report Share Posted August 7, 2007 QUOTE(konroh @ Aug 6 2007, 07:49 AM) ok, after deleting case by case and checking the edit speed, it seems that I have a problem with an xy graph. If i delete the graph the edit speed vastly improves (almost no noticable delay), if I replace it with another xy graph however, everything slows back down. if I create a new xy graph, and wire everything in it also slows down again...I will have to keep digging, but I think something is messed up with my xy graphs or at least the way I am using them. I've seen "bog downs" when I was feeding a very large data set through a shift register (LV2 variable). You might check the VI profiler when your top level VI is open and see if one of your VI's is allocating a large chunk of memory. Maybe even compare the memory usage when you delete the graph? Quote Link to comment
konroh Posted August 7, 2007 Report Share Posted August 7, 2007 QUOTE(orko @ Aug 6 2007, 12:11 PM) I've seen "bog downs" when I was feeding a very large data set through a shift register (LV2 variable). You might check the VI profiler when your top level VI is open and see if one of your VI's is allocating a large chunk of memory. Maybe even compare the memory usage when you delete the graph? I found the problem. I couldn't get it to reproduce in a small VI, but the constant circled above was a SGL, changing it to a DBL fixed everything...the type coersion where it was connected to the shift register on the for loop seemed to be causing the problem... Quote Link to comment
orko Posted August 7, 2007 Report Share Posted August 7, 2007 QUOTE(konroh @ Aug 6 2007, 09:54 AM) I found the problem.I couldn't get it to reproduce in a small VI, but the constant circled above was a SGL, changing it to a DBL fixed everything...the type coersion where it was connected to the shift register on the for loop seemed to be causing the problem... Just curious... was there a coersion dot anywhere in the shift register or bundle nodes before you made the type change? Glad you were able to find the problem. One tip for you: Change your coersion dot color (Tools->Options->Colors) to something brighter, like a bright red, to see it more clearly. I think on LV8.0 they were grey, but LV8.2 changed the default to red. Quote Link to comment
konroh Posted August 7, 2007 Report Share Posted August 7, 2007 QUOTE(orko @ Aug 6 2007, 01:41 PM) Just curious... was there a coersion dot anywhere in the shift register or bundle nodes before you made the type change?Glad you were able to find the problem. One tip for you: Change your coersion dot color (Tools->Options->Colors) to something brighter, like a bright red, to see it more clearly. I think on LV8.0 they were grey, but LV8.2 changed the default to red. there was a coersion dot...but this is the first time I have seen it cause a problem editing, I know it slows down execution to some extent, but in this case execution was fine, editing was horribly slow. Like I said, I tried to recreate the issue from a blank vi with no luck, so it must be related to how deeply in the code this was buried. There is no noticable delay in editing any more, where there was a 1-5 seconds delay before. Quote Link to comment
crelf Posted August 7, 2007 Report Share Posted August 7, 2007 QUOTE(konroh @ Aug 7 2007, 02:54 AM) I found the problem... Wow! I'd be reporting that one to NI. Quote Link to comment
Steve Mate Posted August 9, 2007 Report Share Posted August 9, 2007 Good post - thanks for posting your problem and solution. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.