Controlling LabVIEW application using LabVIEW as an ActiveX server: avoid double-loading of VI

[dlanger]

I want to control my LabVIEW application by means of a Ruby script using ActiveX. The application is already running before the script is started and the scripting should provide the user with automation capabilities. The script will have to access both the main VI and sub-VIs of the application.

Using the a little test script I came across the following problem:

I opened and started the application via the LabVIEW project browser, so the VI that I will access via the script is already loaded into memory. When I execute the Ruby script (see below), apparently a whole new copy of the VI I want to access is loaded into memory (including all dependencies). Because this VI has a lot of dependencies from other VIs of the project, the loading takes ages (tens of seconds), which is

* absolutely not user-friendly,

* wouldn't allow precise timing of the automation on the millisecond level,

* waste memory resources - I am anyway already on the limit with a single instance of the application, so I certainly don't want to load a second one.

Is there a way to access the instance of the VI that had already been loaded into memory as part of the LabVIEW project (i.e., the running application) instead of having the ActiveX server loadnig a whole new copy including all dependencies?

Thanks in advance for any hints!

** The ruby script I used (simplified version for the sake of clarity): ******************

require 'win32ole'

$labview_app = WIN32OLE.new('Labview.Application')

vi_path = 'c:\my_application\send_trigger.vi'
vi_ref = $labview_app.GetVIReference(vi_path)

vi_ref.SetControlValue("trigger", 4)
vi_ref.Run()    
print("Done...)

**********************************************************************************************

[tst]

I've never used the ActiveX connection to LV, but one thing that immediately jumps out is that you're creating a new application instance. Instead, you should connect to the existing application.

I'm not sure how you would do this with ActiveX (although I assume the help has some reference to this), but I do know that you can also do this by enabling TCP access for the VI server (in the LabVIEW options dialog). TCP access works transparently in LV (you just use the IP address and port to connect to the application), but I'm not sure if you can do that from the Ruby code, as I believe the VI server protocol LV uses on top of TCP is proprietary.

[dlanger]

I actually don't think I start a new application instance, because there is no second LabVIEW process visible in the task manager. The "new" command is just to create a new WinOLE32 object in Ruby, which in turn accesses the already running LabVIEW as I assume.

The problem seems to be the loading of a new instance of the VI...

Thank you for your hint regarding the TCP access. I have unfortunately no clue how to use that from with Ruby...

[RuedigerE]

Hello,

have you build an executable out of the lv application?

Regards

Rüdiger

[dlanger]

No, I haven't built an executable, I am rather executing the application from the LabVIEW project browser.

Actually, I would like to continue doing so, without having to compile - at leat at the moment.

Is there no way to avoid the double-loading when working from the LabVIEW project browser (e.g., in "development mode", so to say)?

[dlanger]

I guess it really must somehow be possible to access the already running LabVIEW application. Doesn't LabVIEW somehow register with Windows at start-up, thereby receiving some ID that could be passed when calling WIN32OLE.new?

I.e., instead of...

$labview_app = WIN32OLE.new('Labview.Application')

it would then rather be...

$labview_app = WIN32OLE.new(id_of_already_running_labview_application)

The question then just is, how do I get this ID???

[dlanger]

@RuedigerE: unfortunately, building an executable is currently not an option... I hope that this was not the only way to circumvent the problem?

[shb]

I guess you are connected to the main application instance. You must get the reference to the project and then use its application property. This is at least how it works inside LabVIEW.

(I only see the method open project for getting a project reference.)