LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

vi hangs in object repository

My GOOP project is behaving strangely. It hangs in the Get Data to Modify.vi that is automagically created by the GOOP wizard. There is a case statement in the loop that wait for an occurrence. The occurrence is apparently set inside the object repository (which is inaccessible). When I run my application, it gets to a certain point where it calls the Get Data to Modify.vi and hangs in this vi. I put some "OK dialogs" in the vi to locate the offending code. I put an OK on either side of the repository and they always execute. Apparently, the code hangs when waiting on the occurrence. The code hangs for the duration of the wait on occurrence timeout. If the timeout value is set to -1, it hangs forver. When I put an OK in the waiting
on occurrence case, the code executes without hanging, even if the timeout is -1.
jc
Mac 10.4
LV7.1
CLD
0 Kudos
Message 1 of 4
(2,641 Views)
This is a common problem, but it is probably the fault of a programmer and not LabVIEW/GOOP -- as it has been my fault on several occasions ;-).

"Get Data to Modify.vi" acts like a Semaphore/Mutex. Any other calls to "Get Data to Modify.vi" will wait/hang until "Set Modified Data.vi" (which acts like a Release Semaphome/Mutex) is called -- at which time one of the calls to "Get Data to Modify.vi" will stop waiting. This process then repeats.

You problem is most likely occuring because some VI has called "Get Data to Modify.vi" and never called "Set Modified Data.vi". This happens, most likely, in one of two ways.

(1) The VI is stuck in some loop and cannot proceed, therefore "Set Modified Data.vi" can never be called.

(2) The VI doesn't hav
e any call to "Set Modified Data.vi". This is usually because someone meant to call "Get Data.vi" (which reads without acquiring the Semaphore/Mutex) but instead they called "Get Data to Modify.vi"

Good luck,

-Jim
0 Kudos
Message 2 of 4
(2,641 Views)
Thanks, Jim. I had my Set Data to Modify inside nested cases such that it didn't always execute. I thought that, since it was in a case statement when generated by the wizard, it wasn't necessary that it execute. I failed to realize that the wizard puts Set Data to Modify inside the error case, which means that if it does not execute the Get Data to Modify did not execute either.

Which do you prefer, whiskey, beer, wine, or some other elixir? I want to send it your way. Thanks.

-jayme
jc
Mac 10.4
LV7.1
CLD
0 Kudos
Message 3 of 4
(2,641 Views)
Jayme,

If you are at NI Week, and we cross paths, I'll take a Shiner Bock 😉

Cheers,

-Jim
0 Kudos
Message 4 of 4
(2,641 Views)