Error 1027: Reference cannot be reserved as requested or is in improper

[jccorreu]

I got this one, and found nothing on the internet about it at all. So now I've figured it out I'm gonna post my solution.

Got a VI that opens another and takes references to that others controls, and has a registered event created from that. IT seemed to work just fine, except the first time I would open it, after having closed all my VI's, each time. But when I ran it with the highlight execution it worked every time and I could never re-create the error in that mode.

Turned out that after I opened the vi, it was going through the props for front panel, controls[], and registering the event, before it actually started running the vi. So i changed the run vi invoke node to NOT wait until done, and passed the reference from that on to the property nodes.

I have not seen anywhere that specifies a subvi needs to be running in order to register for events. Nor have I seen much about what the purpose of having the Run vi invoke node wait until done.

This is just to illustrate the difference in the code I was using. This one actually seems to run everytime, unlike my large and complex project which is using this subset.

http://forums.lavag.org/index.php?act=attach&type=post&id=6332

[Michael Aivaliotis]

QUOTE(jccorreu @ Jul 9 2007, 04:35 PM)

I have not seen anywhere that specifies a subvi needs to be running in order to register for events. Nor have I seen much about what the purpose of having the Run vi invoke node wait until done.

I don't have an explanation for trying to register events on an idle VI, however I think I read somewhere that the VI should be running or reserved for running in order to register for front panel events.

Your assumption about "wait until done" is false. It has no affect on your problem. The issue is a http://wiki.lavag.org/Race_condition' target="_blank">race condition. You are performing the two tasks in parallel. It worked when execution highlighting was on because the VI was running before the registration happened. The slowdown gave the VI more time to run. The second approach is better since there is more chance that the VI will be running by the time you do the registration. I have even seen the second approach fail under certain conditions because the VI to run is very large and takes a while to load into memory and execute. By setting "wait until done" to false LabVIEW issues the Run VI command and keeps going on to the next piece of code without checking to see if the VI is actually running. If you really want determinism, there needs to be some kind of handshaking where the caller waits for confirmation that the VI is running before continuing.

[Aristos Queue]

QUOTE(Michael_Aivaliotis @ Jul 10 2007, 02:33 AM)

there needs to be some kind of handshaking where the caller waits for confirmation that the VI is running before continuing.

... such as having both VIs obtain a reference to the same named notifier. The VI that needs to be running uses Send Notification to indicate that it is running. The VI that needs to wait until the other is running does a Wait For Notification and thus doesn't proceed until the notification is received. If it happens that the first VI gets up and running first, that's ok, it just means the message is there and waiting for the second VI so it doesn't have to wait.

[Michael Aivaliotis]

QUOTE(Aristos Queue @ Jul 10 2007, 06:52 AM)

... such as having both VIs obtain a reference to the same named notifier. The VI that needs to be running uses Send Notification to indicate that it is running. The VI that needs to wait until the other is running does a Wait For Notification and thus doesn't proceed until the notification is received. If it happens that the first VI gets up and running first, that's ok, it just means the message is there and waiting for the second VI so it doesn't have to wait.

Yes, this works well.

One other solution is to use rendezvous. Rendezvous are tailor made for this use case. Now you know where you can use those obscure functions.

[Aristos Queue]

QUOTE(Michael_Aivaliotis @ Jul 10 2007, 03:44 PM)

Yes, this works well.

One other solution is to use rendezvous. Rendezvous are tailor made for this use case. Now you know where you can use those obscure functions.

I used to recommend the rendezvous for this case. But after a while I started noticing that although rendezvous solved the initial problem of synchronizing two VIs, many programs eventually turned out to need more communication between the VIs that went beyond just a "go" signal. So I've just been recommending queues/notifiers right from the start so that the data channel exists if it turns out to be necessary.

[jccorreu]

I've never really looked at rendezvous before. I've been using lots of notifiers and queues. I'll read more into them however, to see what all I might use them for.

I noticed where I had a couple of race conditions in my code, after ya'll replied.

Thank you much for the insight.

I notice in one of your quotes mention of classes in LabView. Is that something new to v8, or does my 7.1 also have them? If so, got a goog link for me to read up? My background is c++, and I keep looking for ways I can use more of what I learned from that here, notice the metaphors if you will. :>)

[Yair]

LV classes were introduced in 8.2 and are a new paradigm of OOP.

To do OOP in 7.1, you can use any of the several existing GOOP implementations (you can see more details in the GOOP forum) which implement OOP using LV code. I believe the only ones which support inheritance are Sciware GOOP and Endevo GOOP.

Here are some details about LV classes.

[jccorreu]

Here I'm posting an example of a race condition I found from my use of notifiers in the project I'm working on.

There are many vi's in the project and the notifiers are communicating amongst a few of them. Turns out there was a nice timing condition that essentially was overwriting the first notifier I sent, therefore I only got an action of the second, because it took less time between the calls, then it did for the vi to run that was waiting on the calls.

http://forums.lavag.org/index.php?act=attach&type=post&id=6353

[Yair]

Why weren't you using a queue in that case?

That would be the right tool as a notifier can only hold a single notification.

[jccorreu]

In answer to that Yen, I've inherited the job. The coder who started the project just quit showing up, and I got hired. So I've been having to learn a half completed framework, and turn it into a fully operational system. I'm still finding things like this that I wind up changing. And, I only have some idea of what was going on inside his head, he left almost no documentation at all.

I did change to a queue. It would have been nice to realize this a few weeks ago, because now I realize a number of problems that were bothering me were all related to this. I had a feeling he had something wrong in his architecture and didn't like the little alterations here and there that I kept finding myself doing, but until this I just didn't see it. I'm still pretty green at Labview. And I've really appreciated the help I've found at LAVA, and am wanting to put out some things I learn along the way for others to benefit from.