Opening VI and consuming 100% CPU power

[microscopist]

I am trying to debug my VI. The first few times the VI ran well but suddenly the VI hang up. I have no choice but to end the LabView process using the Task Manager. When I try to restart this VI again, it fails to open and the Task Manager indicates that the LabView program is now consuming 100% of the CPU time but still fail to open this VI. Looks like it is entering into an infinite loop. I cannot fix anything for I cannot go into my VI to change anything. LabView just consumes all the CPU power and do nothing. What went wrong?

Regards,
Larry

[RavensFan]

You may want to post your VI so others can look at it.  Check to see if you have any while loops executing in it that are missing any sort of wait or wait for next ms functions in them.  If you have a loop that executes as fast as it can possibly go, it may not yield any processor time back to the CPU or allow anything else to happen in interacting with it.

[microscopist]

Attached is my test vi. Once I saved it and try to re-open the file, it ran into this 100% CPU usage problem.

[Jorge_Amaral]

Hello,

I think that you've a problem. The Vi may be corrupted. I had a  situation like that and I never openned the vi again.

[microscopist]

Thanks for the observation. This test.vi is a only subset copied from a larger vi. This larger vi does not have this problem, only if I try to modify this test portion. Is there a way to fix this corruption or I have to rewrite that portion that is suspicious of corruption?

[RavensFan]

Okay.  That is very strange.  I am seeing the same behavior.  (I have LV 8.2)

When I first downloaded the VI, it opened just fine.  If I did a saveas, closed the VI, and reopened the copy, I got 99% CPU usage.  I reopened the one from the message, no problem.  I left that one open and tried opening the one I had saved.  It said I already had one in memory by that name do I want to view the one in memory or replace?  I said replace.  When it opened to the block diagram, everything was okay.  But when I clicked on the window to view the front panel, that is when the CPU usage jumped up again.

So somehow the problem is associated with the FP.   Nothing looks particular wrong about your code.  The question is how did you manage to get a copy of the file that isn't causing problems when you open it?

I think you will want to recreate the VI from scratch.  You are able to view a copy to see whay you have which is good.  And it doesn't look too complicated.

What is interesting is that if I delete everything from the VI's block diagram (leaving nothing apparent on the FP), save, close, reopen, I still get the extreme CPU Usage.  It seems confined to LV, as I am still able to switch over and working within the browser to answer this message.

Message Edited by Ravens Fan on 04-16-2007 02:30 PM

[microscopist]

Thanks for taking time to look at my code to confirm this weird observations. At least you have confirmed that my code is quite normal and I have not done something obviously wrong. Maybe I'll just let the NI people to look at their LV 8.2 code. For the time being, I will just rewrite my "problem" portion. Thanks.

[Nadim R]

Hi,

Thank you for your feedback regarding this VI.  The VI does indeed seem to be corrupt somehow.  I tried opening up the VI statically and LabVIEW would crash.  I was only able to open up the VI dynamically with a Call By Reference Node, however the front panel was corrupt.  I will definately relay this information to R&D.

Regards,

Nadim
Applications Engineering
National Instruments

[JasonRMO]

Did any solution/explaination ever come of this?  I recently came across a vi with this issue.

[Norbert_B]

This is a rather old thread (2007), so the specific issue is out-dated.

So please open up a new discussion thread in case you still have the issue with a VI. Please provide information like "LV version" and "OS" (incl. "bitness") as well.

A side note:

The issue does not occur with LV 2013 with that specific test1.vi. It is remarkable that the FP "origin" is way out of bounds (more than 6600 pixels off horizontal) which could create issues like this esp. in older versions of LV.

Norbert