Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Identifying VIs that are actually running (was part of Re: Debugging Actors)

AristosQueue wrote:

Write a VI that gets all the VIs in memory and asks for their execution status.

There is no property in LabVIEW that returns is the VI is actually running.  The Exec.State property node returns "Running" if a SubVI is waiting to run or if it is actually running.  In the case where one VI is running out of thousands, it becomes a needle in a haystack of manually opening VIs and looking at the toolbar (if it is displayed).

See below for my details.  My attempt to script the below work-around did not work.

http://lavag.org/topic/16660-how-to-get-actual-vi-execution-state/

CLA, CTA
0 Kudos
Message 1 of 15
(11,820 Views)

Oh. That kind of running. I don't think I've ever heard of anyone asking for that before. I suspect that we don't expose it because it is totally ephemeral. By the time we returned an answer to you, it would be stale for most leaf-level VIs. It is exactly the sort of data that is generally bad to use for making decsions in a highly parallel execution environment like LabVIEW. What are you wanting to do with it?

Without waiting for the answer to that question, I'll assume you do have a good need for this... the VI updates its own panel (and the hierarchy window) when it starts or stops running. I don't believe there is any facility even within the LV C++ code for something to reach in from the outside and query the running status -- it is all the VI pushing information out to the panel or hierarchy window. I think we would have to expose this as some sort of event on the VI so that the VI can push this information out to you as a listener for that event. That would raise a question about whether we would want to synchronously wait at the start or stop point for all registered event structures to say "yes, I handled this event". If you're trying to build some sort of debugger whose UI is appropriately grayed in/out based on the subVI running, we probably want to make that a synchronous event, similar to Application Exit.

0 Kudos
Message 2 of 15
(4,671 Views)

A *very* basic use case.  Consider a customer application that has thousands of VI's.  A developer creates an infinite loop in a VI (front panel is not visible) and the application is locked up.  The developer asks me to take a look at his program that has been running for one week.  How does one find the VI that is causing the lockup?  This is currently a manual and extremely painful process.

AristosQueue wrote:

If you're trying to build some sort of debugger whose UI is appropriately grayed in/out based on the subVI running...

Yes, but starting this tool after the lockup occurs.  My interest is in having the LabVIEW Task Manager (or similar tool) identify what VI's are truely running and in a deadlocked/infinite loop, that is all I want to see.  I typically encounter this when debugging others code.  Sometimes enabling DETT will modify the performance of the application so the deadlock does not occur.

CLA, CTA
0 Kudos
Message 3 of 15
(4,671 Views)

My current method of accomplishing this task is the Profile Performance and Memory tool to see which VIs are accumulating time.  Since the run state at any given moment is just a sample of the execution state at that moment in time, using this tool instead to aggregate run time over a period of seconds or minutes helps me determine which parts of the codebase I actually need to care about. 

If there is a better way to accomplish this task, I'd love to learn more.

Cheers,

Matt Pollock
National Instruments
0 Kudos
Message 4 of 15
(4,671 Views)

Hi All,

We are out of luck here. We are using 64-bit LabVIEW and there is no Profile Performance for 64-bit or any other monitor tool.

I am surprise that 32-bit Windows 7 can run some serious application. When I started it, 1.8GB of RAM already consumed. So I have only around 1GB left for everything else.

I would like to ask NI to get more serious on supporting 64-bit application. Even cell phones are goung 64-bit nowaday.

How can I raise this one priority to NI Development team?

Thanks,

0 Kudos
Message 5 of 15
(4,671 Views)

SJ_Buddy wrote:

How can I raise this one priority to NI Development team?

You can't ... because porting various parts of the NI software stack to 64-bits is already as high a priority as it can get given the resources we have for porting tools. Given all the things we have to work on, we've put as many people on porting as we can afford to. If you'd like to fix the global economy so we can double our number of R&D hires in the next few months, that would help.

Message 6 of 15
(4,671 Views)

SJ_Buddy wrote:

I am surprise that 32-bit Windows 7 can run some serious application. When I started it, 1.8GB of RAM already consumed. So I have only around 1GB left for everything else.

You're not supposed to run LabVIEW 32-bit on a 32-bit Win7, but instead you should run LabVIEW 32-bit on a 64-bit Win7. That works nicely for me, and you'll be able to use about 4 Gb RAM for each LabVIEW instance (I have 20 Gb RAM in my dev laptop, works like a charm).

What did you load that consumed 1.8 Gb RAM immediately? Not Win7 by itself hopefully? If your application uses up several Gb of RAM, I'd suggest you take a look at how you manage memory allocations in your code. I'm not saying it shouldn't be so, I'm just saying that very few (healthy) apps use up huge amounts of memory and keeps growing. Vision and file post-processing are two types that could use up large amounts of memory. That's why the Vision Module has been ported to 64-bit LabVIEW as one of the first.

Cheers,

Steen

CLA, CTA, CLED & LabVIEW Champion
0 Kudos
Message 7 of 15
(4,671 Views)

More info about DETT on 64-bit. Turns out it does work if you know the trick:

https://decibel.ni.com/content/thread/18687

0 Kudos
Message 8 of 15
(4,671 Views)

Hi AQ,

Thanks a lot for the info. I will set up a 64-bit LV2013 station to try it out.

I have a little separate question. I courious if you can share source code of a VI belong to a NI supplied code to generate 2-actor AF application. The file is is "C:\Program Files\National Instruments\LabVIEW 2012\ProjectTemplates\Source\Core\Actor Framework\scripting\TwoTasksMetaDataObj\Rename And Move Entire Library.vi". It is password protected. I am trying to automate our AF coding. Or would you have a VI scripting code to Rename VI, class, controls, ... of a library. It would be a tremendous help for us.

Best Regards,

0 Kudos
Message 9 of 15
(4,671 Views)

You might look in the code that the Create Project dialog uses to copy templates and sample projects to a new directory.  I believe it uses a G API that includes VIs you can call to rename libraries and classes. 

Elijah Kerry
NI Director, Software Community
0 Kudos
Message 10 of 15
(4,671 Views)