LVx - Exported LV Function(ality)

[Norm Kirchner]

Finally!! after so much time getting this together, I have something to show y'all.

This concept of LVx is not new, but has gone through a revoltuion using LVOOP which should allow you to very easily add a small amount of code to your program that will allow it to accept commands from another LV based program in which it can easily have data passed to it, and have data passed back to the caller. Many custom implementations can be devised on how to do this, but I belive that we have hit a solid note in the area of re-use and compatability.

I'm sure you will all have many questions as not everything is clear, but Rather than try to cover all bases, I'll take them as they come.

You will find attached a demo, and exe, and the source to a technique that allows inter-LV communication (LV to LV, LV to LV built exe)(LVexe to LVexe)(etc)

You should extract to a common directory, start the exe, then open the demo.vi and run it (with the appropriate computer name). Then change the class constant wiring as noted on the front panel.

[Aristos Queue]

QUOTE(Norm Kirchner @ Oct 31 2007, 04:13 PM)

This concept of LVx is not new

And yet there might be people who don't know what LVX is. Can you post a link to previous discussions about this?

[Norm Kirchner]

QUOTE(Aristos Queue @ Nov 1 2007, 11:52 AM)

And yet there might be people who don't know what LVX is. Can you post a link to previous discussions about this?

I would have to crack my head open and plug a RJ-45 into it to give you the proper link, as it has not been a discussion here on the forums. I needed to put it that way as I am not the original inventor of the concept. Scott Menjoulet is {resident LAVA lurker}.

To sum up - The original idea was that for each exported function that you wanted a program to have, you would have to create a specific 2-mode sub-vi that on the first itteration, it took the specific functions data type and created a user event that was stored in a USR within itself and also finish and output to a dynamic registration node in the host VI. Then from somewhere else, client remote PC, another VI, whatever would dynamically run that same 2-mode in the app instance of the host and in the second mode that it's run (not first itteration because already in memory and run once when the host started) it will fire the user event with the data passed to it in the dynamic call from the other app instance(or same, if you so choose).

so after that long summary, the original version did the same basic thing with the user events and firing them from a different app instance, but if you had 20 exported funcitons you would need 20 wires running into the register for dynamic events and 20 separate VI's and then 20 separate event cases regardless of what actually had to happen.

Using LVOOP, it becomes sexy and scaleable and flexible and all those other things that LVOOP provides.

[Val Brown]

QUOTE(Norm Kirchner @ Nov 1 2007, 12:45 PM)

I would have to crack my head open and plug a RJ-45 into it to give you the proper link, as it has not been a discussion here on the forums. I needed to put it that way as I am not the original inventor of the concept. Scott Menjoulet is {resident LAVA lurker}.

To sum up - The original idea was that for each exported function that you wanted a program to have, you would have to create a specific 2-mode sub-vi that on the first itteration, it took the specific functions data type and created a user event that was stored in a USR within itself and also finish and output to a dynamic registration node in the host VI. Then from somewhere else, client remote PC, another VI, whatever would dynamically run that same 2-mode in the app instance of the host and in the second mode that it's run (not first itteration because already in memory and run once when the host started) it will fire the user event with the data passed to it in the dynamic call from the other app instance(or same, if you so choose).

so after that long summary, the original version did the same basic thing with the user events and firing them from a different app instance, but if you had 20 exported funcitons you would need 20 wires running into the register for dynamic events and 20 separate VI's and then 20 separate event cases regardless of what actually had to happen.

Using LVOOP, it becomes sexy and scaleable and flexible and all those other things that LVOOP provides.

Now THIS sounds like a perfect use for LVOOP.

[Norm Kirchner]

QUOTE(Val Brown @ Nov 2 2007, 02:34 AM)

Now THIS sounds like a perfect use for LVOOP.

Definetly.

Here is a peek at how it used to have to be done. As you can see in the demo, OOP is simpler

http://lavag.org/old_files/monthly_11_2007/post-208-1194027768.jpg' target="_blank">

[Tomi Maila]

I tried to open the LVx source project with LabVIEW 8.5 but it's full of conflicts.

[Yair]

QUOTE(Tomi Maila @ Feb 22 2008, 09:47 AM)

I tried to open the LVx source project with LabVIEW 8.5 but it's full of conflicts.

Likewise here.

[Norm Kirchner]

Download File:post-208-1205123180.zip

Download File:post-208-1205123156.zip

Please accept my apologies for taking so long to get back to this.

Now in LV 8.2

You should be able to run the EXE now w/out conflict. You can debug the EXE to see what's going on. There may be a warning but because I'm at 8.2 there is no way around it.

After running the demo, you should open the Demo.vi program from the "For Lava LVx" zip file {after all are extracted}

Wire different sibling classes to the "Remote - ExecuteEvent.vi" to observe the coolness of LVx

Send a command WITH data through a standardized interface AND receive completion confirmation AND data back from the recipient.

Please be detailed w/ any issues or feedback. I'm all ears.

[Tomi Maila]

Norm,

Thanks for fixing the problems, I was able to open the code in LabVIEW 8.5 without errors and run it.

Then for the feedback. The code architecture was not completely clear to me by just inspecting the code. Some description of all parallelly executing instances and the communication channels between the instances would help together with the class diagram. I figured out that you seem to be using the command design pattern to pass commands to remote application instance. The idea of using LVOOP to pass commands to remotely executing LabVIEW instance is good and I'm happy that you've come up with a functional application taking advantage of the method.

However you seem not to use the command design pattern in a pure form but you have mixed the command pattern with some other functionality. For example your command parent class LVx.lvclass contains the command method itself Dyn - ExecuteEvent.vi but in addition it contains state selecting method Dyn - State To Execute.vi. Your command is then specified as a combination of these two methods which is somewhat confusing to me. I would myself choose differently so that the developer of new commands didn't need to know the exact implementation of the execution loop as a state machine with states of certain names. Either I would write a few build in Commands such as Close and would test if the received command is one of these build in commands or I would add some methods to the command parent class such as Close?.vi that would indicate if the remote instance should be closed after executing the command. Both alternatives have their own benefits and drawbacks. The latter is perhaps more suitable for LabVIEW which doesn't have pattern matching functionality built-in.

Is there some specific reason you have separated the Event Handling loop and the Primary Execution loop from one another? I don't see any benefit in this particular application to have two separate loops as the Event handling loop doesn't seem to do anything but feed the Primary Execution loop.

You use named queues and named notifiers both in your example which makes the code hard to follow as at least I didn't find out all the places where the named references are used. Are you using named queues and named notifiers to allow communication between different top-level VIs of the same application instance?

Now I've to go back with my real work

[Aristos Queue]

QUOTE(Tomi Maila @ Mar 10 2008, 02:39 AM)

Thanks for fixing the problems, I was able to open the code in LabVIEW 8.5 without errors and run it.

I still have not been able to get it working.

[Norm Kirchner]

QUOTE(Aristos Queue @ Mar 10 2008, 09:37 AM)

I still have not been able to get it working.

What can't you get to work? Getting into debug mode of the EXE or getting the EXE to respond to requests from the VI?

The only thing I can think of at the moment, although the problem would be pretty obvious w/ just a minute of debug, is that you're not opening the application instance properly.

Can you give any more details regarding this?

[eprothro]

You will find attached a demo, and exe, and the source to a technique that allows inter-LV communication (LV to LV, LV to LV built exe)(LVexe to LVexe)(etc)

You should extract to a common directory, start the exe, then open the demo.vi and run it (with the appropriate computer name). Then change the class constant wiring as noted on the front panel.

Are there any plans to release this in VI Package form? A few minutes of talking with Google led me to believe that's not the case yet.