Parallel event structures triggering on the same events

[pltrogon]

Close. I create the notification refnum in the aux VI but create the user event refnum in the web method VI. The fork in refnums has to happen before the event registration [this probably means nothing to you without using SV events. You first subscribe to notifications for a set of SVs. This gives you a notification refnum that you use to register for the user events. The refnum from the registration is what gets passed to the event structure]. You're absolutely right, I cannot cross outside of the web services boundary or else the refnum becomes invalid.

I've run a variety of tests in the LabVIEW environment. In fact I haven't even attempted to attach this to the web service yet, I'm testing it on two isolated VI's. [maybe that's my problem? maybe this will ONLY work in the deployed web service because the aux and web method VI's will be in the same application instance then but in my test case are not?]

My test VI that declares the notification refnum has a loop in it that keeps it active forever. My thought was that the refnum would die with the VI closing. Still didn't work.

Well the problem with notifiers and SV events is exactly the same; they'd both require passing a refnum to a web method VI that is called by a user and not by the aux VI.

By the way, I appreciate your time in hashing this out with me. I've learned a lot [been forced to clarify my thinking].

[nathand]

You haven't provided the information necessary to determine if they're in the same instance.  Are they both executing in the same project, under the same target?  If so, same instance.  One is inside a project, the other is running in LabVIEW in the Main Application Instance?  Different instances, etc.

It's beginning to sound like your problem may not be application instances as I first suspected.  Let's take your example here and assume they're in the same instance, and that there's a functional global variable containing a refnum that they both read.  VI1 and VI2 both execute a single action and then stop, and there are no other VIs running continuously in the background.  You run some VI1 once to initialize the functional global.  Now you execute VI2 - but VI2 doesn't get a valid refnum!  Why not?  Because the entire hierarchy has gone idle (no VIs are running in that instance) so all refnums are invalidated.  The refnum may have a value - it's only an integer in disguise, after all - but it can no longer be used as a valid refnum.  Does that make any sense?  Is that what happens in your situation?

[nathand]

Is there any chance you can upload some sample code demonstrating the basics of what you're trying to do?  I don't have the DSC toolkit so I can't do anything with the shared variable events, but I would think we could model it using user events.

[pltrogon]

Yes, tomorrow I'll put together a demo with user events.

As you surely guessed my theoretical VI1 and VI2 are my two test VI's. They're in the same project... frankly I don't know if they're under the same target.

What you described is exactly what I'm running into right now. Even if I let VI1 run continuously in the background, it seems that the refnum has "expired" by the time I read it out in VI2.

[pltrogon]

---

You run some VI1 once to initialize the functional global.  Now you execute VI2 - but VI2 doesn't get a valid refnum!  Why not?  Because the entire hierarchy has gone idle (no VIs are running in that instance) so all refnums are invalidated.  The refnum may have a value - it's only an integer in disguise, after all - but it can no longer be used as a valid refnum.  Does that make any sense?  Is that what happens in your situation?

---

This is what I've been trying to fix and is exactly what I think the problem is. The application instances IS relevant because I need to make sure that VI1 and VI2 are in the same application instance as well as ensure that the refnum hasn't been destroyed. Thinking about it, I imaine that LabVIEW deallocates the refnum when it no longer has anywhere to go on the diagram--instead of just floating an infinite loop on the diagram to make VI1 stay open, I should put the refnum in a shift register in the infinite loop [for the test]. Maybe that will work, crazy as it is. I'm home now and away from my lab computer but I'll give this a try in the morning and post my results here.

thanks!

[pltrogon]

Well, I've been playing around with this for a while and discovered two things:

1. Passing the refnum over a global [no danger of race conditions so I didn't bother with a functional global] doesn't work for two separate VI's in the same project on the same target. But when the two VI's are AUX and web method VI's in a deployed web service, then it DOES work. Like I said earlier--and I could have guessed this because otherwise auxiliary VI's would have no solid purpose--the aux and web method VI's are in the same application instance. So, nominally, all is well...

2. ...but this all ended up being irrelevent [for me]. When two instances of the web method VI exist simultaneously, one executes first and then the other--just like parallel processes in a standard VI [up to # of cores].

I thought that I was getting away with something with this design--declining to respond to a client query until new data exists. But it was a naive design! It's not like I'll have enough users for polling to be an issue anyway.

Edit: [addendum] The event loop parallelism works fine for multiple loops on the same diagram. It does NOT work for parallel subVI's or dynamically called VI's. I'm uncertain of how LabVIEW handles these things internally, but I naively expected two subVI's with a certain piece of code to execute identically to the exact same piece of code written twice in the same diagram. Lesson learned!

[nathand]

---

@pltrogon wrote:

1. Passing the refnum over a global [no danger of race conditions so I didn't bother with a functional global] doesn't work for two separate VI's in the same project on the same target. But when the two VI's are AUX and web method VI's in a deployed web service, then it DOES work. Like I said earlier--and I could have guessed this because otherwise auxiliary VI's would have no solid purpose--the aux and web method VI's are in the same application instance. So, nominally, all is well...

---

Just out of curiousity, could you upload your code that demonstrates this?  It doesn't make any sense to me.

[pltrogon]

Reentrance! Man that was dumb. OK, I'll post the code now [it works]. The problem was that I had neglected to set my test web method VI's to allow reentrance.

[pltrogon · Accepted solution]

I haven't put together a demo project but I can do that if you'd like, but you'd need the DSC module to run it. Here are some images:

Main VI:

The first panel mimicks the behavior of the web service AUX VI. It enables SV value change notification and adds a notification for the three listed SVs then sends the notification refnum and SV names to globals. The two model web method VI's in the right panel have this diagram:

The notification refnum and SV names are retrieved and the event loop is initialized. What happens internally is unimportant.This runs and works: when I change a SV value, both "XML Out" and "XML Out 2" show the same event data. This VI must have the reentrance property or else the two instances will not run in parallel.

If I break the two panels off into two separate VI's on the same target in the same project, the refnum at the second VI is not valid, even if I keep the refnum alive in the first VI with a while loop. However, when I deploy these two VI's in a web service--with the first as an AUX VI and the second as a web method VI--the refnum IS valid in the web method VI. Presumably I am not doing enough in the non-deployed version to ensure that my two VI's are considered part of the same application instance.

[nathand]

---

@pltrogon wrote:

If I break the two panels off into two separate VI's on the same target in the same project, the refnum at the second VI is not valid, even if I keep the refnum alive in the first VI with a while loop. However, when I deploy these two VI's in a web service--with the first as an AUX VI and the second as a web method VI--the refnum IS valid in the web method VI. Presumably I am not doing enough in the non-deployed version to ensure that my two VI's are considered part of the same application instance.

---

Still don't quite understand why you're having a problem, but in the interest of accuracy in terminology, I believe this is not a problem with application instances, it's something else.  If you put up your existing version I'll modify it to get rid of the DSC components and see if I can duplicate the problem with it, but this is mostly to satisfy my (and maybe your) curiousity at this point since it sounds like you have it working the way you want.

EDIT: unless when you run this as a test you're still using the web service to trigger it.  In that case, you do have separate application instances, because you're starting one VI (the one that creates the refnum) in the LabVIEW project environment, but when you make the web request, the web method VI executes in the web server instance.  I don't know how you'd get an auxiliary VI to execute within that instance inside the development environment, but that might explain what's happening.  If that matches your situation, no need to upload the code - it makes sense and application instances are in fact the problem, just not quite the way I expected.