LabView periodically hangs

[xl600]

I'm struggling to figure out how to diagnose an issue with LabView hanging with high CPU periodically (Dev environment only).

While doing fairly innocuous things that execute at with little CPU, after a few rounds of execution, debug/modification, re-run, LabView suddenly starts to lock up for long periods (seconds to 10's of seconds).  For example, I have a VI I call asynchronously:

After first opening LabView and executing this, it opens extremely fast.  But after awhile, the Start Async call starts to delay.  The LabView profiler claims nothing is taking a long time but if I look at the LabView process itself, it always shows a nearly 100% load on one core during the lock-up.  It generally doesn't even matter what VI being called asynchronously, how it's being called (0x80 forget or 0x100 collect), or what that VI is doing (The one above just waits in an event loop until it's told to close).

On top of this, when I try to close LabView (After closing all running VIs), again the LabView process starts doing the 100% thing on one core and often fails to shut down.  It really drives me nuts!

Is there any way to see or sense what the LabView.exe process is going crazy on when it gets into this state?  This has been fairly persistent from LV2013 through 2016.  I suspect it's has something to do with VI server in the dev environment.

Thanks,

XL600

[xl600]

Some more details.  The stalls occur at the FP.Open call as well (Both delay for many seconds each).  Once the VI is actually running, it runs at normal speed.

[RavensFan]

A couple thoughts that crossed my mind.

Is the VI you are opening saved in the version of LabVIEW you are running it from?  If LabVIEW opens up an older VI version, it takes a little bit of time to recompile the code for the new version.  Perhaps it is doing that even when you are programmatically/dynamically opening it.

I've seen odd hangs while developing, usually on a larger project.  My gut feel is that maybe LV decided to do a autosave on the open VI's.  I'm wondering if it does that as well even on programmatically opened VI's, particularly if it was modified upon opening for the reason stated above.

[xl600]

Of the VI's I'm working on, all are LV2016.  It is a large project though with hundreds of VIs, many classes, etc.  The specific VIs I'm working on at the moment do not pull in the bulk of the project VIs (The project spans several related programs).

The autosave notion is interesting.  How would I be able to tell if that was happening?  And would that explain the closing LabView issue?  When labView refuses to close with no VI's running, it's CPU usage looks very similar to the CPU usage when the VI's are stalling.

[RavensFan]

I have no idea.  Just something that crossed my mind because I'll see occasional hangs in LabVIEW, usually right as I'm about to do something.  Sometimes I've seen that same sort of thing happen in other programs like AutoCAD or Excel that I know are auto-saving.  Makes me think the same thing might be happening here.

[Ben]

xl600

Check your private messages if you get a chance.

Ben

[Bob_Schor]

It looks to me as though you are trying to run your VI "Post_Process_etc" using two different methods -- you tell VI Server to run it (using the FP.Open Invoke Node) and start it running as an Asynchronous "clone"!  I have no idea what LabVIEW would try to do in this situation, but it would not surprise me if this drove it to drink!

Once Start Asynchronous Call functionality was introduced, I largely stopped using VI Server.  You might want to consider doing the same.

Bob Schor

[xl600]

I did change that right after I posted (removed the fp.open) but there's still a long pause in the startup at the async call.  The vi is a jki state machine so it calls its own fp.open.  I had that disabled when my calling vi was doing it and it seemed to work fine.  But now it's back to calling itself and the delay is about cut in half.

[Bob_Schor]

Aha!  It sounds like you want a "substitute Front Panel" while the JKI State Machine is running.  You really haven't shown us much code, so I may be completely wrong about this but ...

What sort of Front Panel does your main VI have, and what Front Panel does your "detached" VI (the JKI State Machine) have?  Are you interacting with both of them at the same time?  If your Main routine has very few controls/indicators, you might be able to put a large Sub-Panel on its Front Panel and run your JKI State Machine using this sub-Panel to visualize its Front Panel.  I've done something like this to monitor Sample data streaming through my main VI, having a Show Sample VI whose Front Panel had an updating Graph of the data flowing through the system.

Bob Schor

[xl600]

No, that's not what I'm doing at all.  The pop-up graphs are their own front panel displays.  The main VI is just a set of channel pick lists where the user picks which X and Y variables to plot (in the next pop-up graph) or overplot (In the last selected or active pop-up windows).  Think about how MatLab figure windows appear.  That's the effect I'm shooting for (figure(), hold on, plot(this), plot(that), plot(the other thing)).  I collect potentially hundreds of channels of differing data which the user inspects before exporting for follow-on analysis via specialty tools.

Both the main VI and the pop-up graph VIs (One for Y vs time and another type for XY plotting) are JKI SMs.  I've really grown to like the JKI SM approach so I use it everywhere (Even for my RT system, heavily modified of course to remove front panel operations).

The main VI just acts as a control for those, as a central point for controlling data conversion VIs, analysis VIs, export VIs, time range selection, bias correction, curve fitting, and other functions.  It's packed with buttons and lists.  Unfortunately, it's all proprietary code and even though it's nothing spectacular, I'm still prevented from posting it in open forums.  It certainly makes it difficult, I realize that.

Thanks,

XL600