How can I detect if My program is being activily used or running Idle?

[DB_IQ]

Hello,

I have an application where I am running 3 parallel While Loops.

1.) One While loop is an event handler, which focuses on button presses of the controls on my front panel.

2.) One While loop is my main process control which handles everything else.

3.) One While loop is calling a dynamic external VI every few seconds. The dynamic VI is called from a seperate library that changes depending on which device I am interested in testing. All this loop does is look up information and report back. I want this loop to be working in the background, and to not interfere with the operation of Loops 1 and 2.

What is happening is everytime #3 runs I temporarily loose control of my front panel, even though no pop up pannel is opened.

I want to set up a system where if my mouse is moving, or if I am using any of the controls on my front panel, the #3 while loop does nothing. It sounds like a simple test but it's not as easy as I thought.

I tried using Timeout event but that didn't work as I thought. I also tried the Wait For Front Panel Activity, but that actually almost works in complete reverse.

Is it a VI setting that I need to adjust?

Any advice would be greatly appreciated.

[RavensFan]

Use wait for front panel activity as a means of resetting a watchdog timer.  Have one loop that just ticks away.  Have another loop that waits for front panel activity, and then it triggers a notifier to the first loop to reset the timer.

You could have that first loop trigger your loop you describe in #3 whenever the timer exceeds whatever time want you want.

The best solution would be to figure out what is causing you to temporarily LOSE control of your front panel whenever loop 3 runs and fix that problem.

[DB_IQ]

I'll try that.

The VI that I am calling dynamically is, I am pretty sure, is causing the problem. I think it's transfering control from one VI to another temporarily.

[Sam_Sharp]

At a guess I would say that the VI is calling external code (e.g. from a DLL) and is set to 'Run in UI thread' - this prevents any other UI code from happening in the application until the dll call returns. You might be able to change the calling method in the SubVI (it might just be that it wasn't configured properly in the first place rather than actually needing to be run in the UI thread). 

If you want to find out a little more - read about "thread safe" DLL calls.

Either that or you might be able to create a thread-safe wrapper for your DLL? (I think?)

[DB_IQ]

There are no DLL's invoIved in this stage of my project. have debugged the function up to this point:

My while loop is not what is breaking my front panel. Inside the while loop I call a VI.

Inside this VI is this block of code that calls the external VI from a library file,in this case an uncompiled external project folder.

I have disabled everything up to the Open VI Reference. Once I add Open VI Reference, the glitch begins to occur.

Figure 1: VI Call

The H_HardwareQuert VI does nothing but return a false flag, as shown. Therefore, it's my understanding that there is something configured in the way that VI is called that is causing my front panel to break. That is where I need assistance, I think.

Figure 2: H_HardwareQuery.vi

[RavensFan]

Can you attach that subVI?

[DB_IQ]

Here it is. I toyed around with the settings earlier in VI Properties, but I might have missed something.

On this VI I require no front panel, only background processing.

[RavensFan]

It really isn't doing much, so I can't see why it would slow things down in processing.  No internal while loops, no dll's, no GUI redraws.

Looking at VI properties (which I know you messed with), I'm trying to see what is different from a standard new subVI.  Maybe some of these things are having an effect.  Maybe not.

Execution:

New subVI is Normal Priority and Pref. Exec. System same as caller.  Yours is background priority (lowest) and standard.  Maybe one or both of those things are causing the VI to not be handled quickly and falling in priority relative to other things.

Window Appearance: some difference is showing less buttons and not allowing user to close/minimize window.  But nothing that makes me think it would cause a problem.

I see your open VI has the options set for 10.  I can't tell from your picture if that is a 10 decimal, or a 10 hex.  If it is a 10 decimal, then it is a combination of 2 -  Open templates for editing, and 8, prepare for reentrant run.

(0x10 would be Prompt to find missing subVI's)  That one doesn't make sense to use as an option, but shouldn't hurt if all subVI's are present.  If it is decimal 10, then decimal 8, reentrant makes sense.  But decimal 2, open templates for editing doesn't make sense and I could see how that may make the processing slower.

[DB_IQ]

The 10 in my picture is a Hex 10. The radix was turned off but it is formated as hexadecimal.

[RavensFan]

I would take a couple steps back to start.  Instead of dynamically calling the VI.  Statically call it (drop subVI into the block diagram).  See if it runs faster.

Also, don't actually call and run the subVI.  Just return the False out.  But go through the open and close VI reference process.  Maybe that is taking a long time.

Also,  use some timer functions to see how long each of the steps is actually taking.  (open, run, close).