Menu selection or Alt key interferes with vi execution when VI Call Configuration (in call setup) is set to reload for each call

[hiltech]

I have this example vi attached which is a basic loop with a vi set to reload for each call.  Here's what happens...

1) Run the vi. (The time display updates for each loop execution)

2) Press the Alt key (Windows) while window active (as to access the vi's application menu)

3) Now the time display stops updating while the menu is active.

4) Press Alt again and the vi proceeds to execute.

Now change the Call Setup to 'Load with Callers' and repeat steps 1 - 4.

The vi continues to operate during menu access.

Is it intentional in the design of LabView to cease loading of vi's during menu access? 

Could someone please help to explain?

[Hueter]

What version of LabVIEW are you using? I opened and ran this in LV 2009 and the time updates even when the alt menu selection is on.

[hiltech]

I have 8.6

[Hueter]

I do not have a copy of your subVI "IP address string to cluster" so I deleted it, and I do Not see any issues with the timestamp not updating when the alt menus are on. I don't think this missing VI is related to the issue though. This works fine for me in 8.6.1

[hiltech]

Here is my subVI.  ...attached.  I'm on 8.6.1 also.  Any idea/suggestions of what I could try to isolate the cause?

[Hueter]

Alright I am now seeing the same behavior and it is related to the Sub VI, not the VI itself but the Call by reference node.

LabVIEW is a multi-threaded environment, each VI executes on a given thread. There is one special thread called the UI thread, this thread is used to update the front panels well as certain other things like call by reference node and VI server invoke methods. When you selected alt menu, the menu selection sits on top of the UI thread and blocks it, so your while loop has to just sit and wait. Once you hit alt again to exit the menu choice the UI thread is free again and your loop can update freely. This is not the intended behavior and has been filed to R&D as a corrective action report (CAR 99672)

Now that being said there is a workaround you can use to avoid this. For your example the quickest fix would be to put the IP string function and the time stamp functions in separate loops. That way when you go to the alt menu the loop with the call by reference node will freeze but the timestamp will continue to update.

You can also just remove the Run Time menus to avoid the problem

Message Edited by Hueter on 09-29-2009 02:49 PM

Message Edited by Hueter on 09-29-2009 02:51 PM

[hiltech]

Glad to learn something new and to provide something that will eventually help to improve the product.

However, so far as the solution goes, my application was much more involved than the example which I posted.

I was originally trying to operate a custom "queue/dequeue" vi which implemented the use of wait on rendezvous vi's.  I had one wait on rendezvous inside my "queue with wait for dequeue" subVI side by side with my custom "queue/dequeue" VI and so I needed to dynamically call the "queue/dequeue" VI so that my subVI "queue with wait for dequeue" was not holding up the "queue/dequeue" VI from dequeuing the items elsewhere in my application.  So I chose the "reload for each call" call type in order to free up access to my queue/dequeue object.  Needing to keep my custom menu, I eventually decided to abandon the call type and separated the "wait on rendezvous" into a separate subVI from my Queue/Dequeue VI to make everything work correctly.

Bkgd:  This problem was causing loops to freeze in my application during any menu access (or press of the alt key).  My application is running a test involving a 500 kW rectifier back to back with a 500 kW 480 Vac solar inverter.  One main application loop continuously monitors the DC bus.  If my code happens to miss the Vdc rising above 980 V, it won't shut down the DC supply in time to prevent a huge IGBT explosion from happening a few milliseconds later at 1200 Vdc+.  ...Exciting stuff!

Thanks for finding the cause of this problem!  It'll hopefully help to make me wiser in future projects.