TS Popup from LAVA - Adding 3-input Cluster

[battler.]

You are right tst.  It does call a lot of VI's dynamically - this is the source of the problem.

I have experimented.  A main processing VI starts by calling dynamically an event Monitoring VI using the Open VI Reference VI.  See image:

The main VI will not function correctly even when it is not an exe.  Except when I open the dynamically loaded Monitoring VI firstly (i.e. put it into memory?).  If I do that first then the VI functions.

I built an exe and used error cluster to expose an error with Open VI reference.  However, as a VI and not exe no error with Open VI Reference is given - the Monitoring VI simply doesnt do its job.

I am completely lost when it comes to dynamically calling VIs.  Your help is most appreciated.

[tst]

When you supply the Open VI Ref function with an incomplete path, it considers it to be a relative path to the VI which calls the function, so in this case, TSPopup.Monitor Events.vi should be in the same folder as the VI in your image. A quick test shows that when you include it in the build (along with another dynamic VI, whose name I don't remember) it works fine.

If you're not getting an error from the OVR function, it means it was successful. If the code still isn't working, it probably means something else is broken.

[battler.]

Yes, but it works when I manually open TSPopup.Monitor Events.vi before I run.  It seems to work intermittently, which makes it difficult.

There is no error produced by the OVR VI but the successful operation seems to be totally dependent on opening TSPopup.Monitor Events, which is what OVR is supposed to be doing.

Any ideas would be great.

Download the code here:

http://lavag.org/index.php?app=downloads&showfile=31 

This is a great toolkit if only it could work as an application.

[battler.]

tst, when you say "include it in the build" what do you mean?

It is part of the project.  Do you mean in the App builder under Source files to place it under Always Included?

Cheers.

[tst]

---

battler. wrote:

Do you mean in the App builder under Source files to place it under Always Included?

---

Yes.

[battler.]

Thanks tst.

Please help me with this problem:

My app dynamically calls the TSPopup.Monitor Events VI (as shown in the previous diagram) by using the Open VI Reference VI (as shown).

My app doesn't work unless I manually open TSPopup.Monitor Events first and leave it open; then the dynamic call and run works.

If I dont open TPPopupMonitorEvents before running then my app doesnt work (because the dynamic VI is never started).  No error is returned by the Open VI Reference VI.

Hmm..

Thanks.

[MichaelAivaliotis]

How do you know that no error is returned from the Open VI ref function? Did you probe the error wire or create an error indicator? Try putting the complete path to the VI, not just the VI name (ex: c:\mycode\my.vi). What happens then? If you just use the VI name then the VI needs to be loaded memory.

Also, another thing I noticed is that you are closing the reference after the Run VI method. Try removing the Close Reference function altogether. You don't need it.

Message Edited by Michael Aivaliotis on 01-12-2010 10:39 PM

[battler.]

Hi Michael,

I probed the Open VI Ref and successive VIs and created an error cluster and placed on front panel of main app.  No error and yet the program wont work due to not loading the dynamic VI.  Tried a complete path.  Didn't work either.

I read that dynamic loadng of VIs is a way of placing them in memory, as opposed to a static VI which is already in memory.

I have noticed that if I open the dynamically called VI first and leave it open (i.e. place it in memory), then run my app which dynamically calls it everything works fine.

This has lead me to a temporary fix where I have placed the dynamically called VI on the block diagram of my main app and disabled it with a case structure.  I made it re-entrant.  I'm not sure if this works as an exe but it does otherwise.

Can anyone help me to explain this behaviour?

Thanks,

Battler.

[tst · Accepted solution]

The exact way it depends on which version you have - since 8.5 (I think) LV won't accept conflicting paths, but it should return an error in any case if it doesn't find the VI.

Like I said, I took the example which ships with the library, created a project, added the two dynamic VIs to the build and that was it. To avoid issues like this, I usually do something like this with static VIs which need to be called dynamically (e.g. if you need N copies):

This means that you don't have to have exact paths, don't need to remember to include the VI in the build, etc. I believe this should work correctly in all versions of 8.x, at least if the VI is reentrant and you set the reentrant flag in the OVR function.

[battler.]

Thanks tst.

Like you I was able to build the demo.vi which came with the library by including the dynamically called VIs.  Something must have happened with my implementation/modification of the code.  I could not locate the issue as to why Open VI ref was not working.

Your suggestion to use the static VI reference worked.

Much appreciated.