Calling LabVIEW VI's from Python

[candidus]

Thanks for checking, that's important. COM does a lot of stuff behind the scenes, threading, message loops, RPC...

Maybe you're better off implementing your application as client and server. I would try to run the subVI in a loop with queues for input and output. Python then could call VIs that just interact with these queues. Maybe that works. Also consider to move your VISA communication to the LV side.

Regarding the GetModule() error:

If you don't set comtypes.client.gen_dir = None comtypes will import the type library only once and build a persistent Python script in the subdirectory Lib\site-packages\comtypes\gen of your Python installation.

[steveh01]

I would recommend trying the late-bound approach with a dynamic dispatch.  This avoids the GetModule error.  By the way, to mitigate the draw-back I listed in my previous post, I found out that you can flag and call any VI method to get data back from the VI.  So, you could do a pre-call call of something benign like GetControlValue.  So, as long as you understand how to do the quirky work-arounds, I see hardly any drawback to doing LabVIEW control from Python using COM.

Here's the section of code that I changed from before (full file attached):

______

    #Get VI ref and flag methods (needed for some functions when calls are late-bound).
    ArrSelVI = LabVIEW.GetVIReference(AppPath + r'\ArraySelect.vi')

    #For some reason at least one function must be flagged and called here before a
    #Call or Call2 function runs.  Otherwise the data in the VI gets cleared before
    #GetControlValue() has a chance to access it.  The whole point is to run a VI
    #behind the scenes without showing it to the user.
    ArrSelVI._FlagAsMethod("GetControlValue")
    ArrSelVI.GetControlValue("The Value")
   
    #From the makepy-generated file, the VirtualInstrument class function Call2 offers more control:
    #Call2(self, paramNames, paramVals, openFP, CloseFPAfterCall, SuspendOnCall, bringAppToFront).
    ArrSelVI._FlagAsMethod("Call2")
    ArrSelVI.Call2(ParameterNames, Parameters, False, False, False, False) #Call VI without opening.
   
    TheValue = ArrSelVI.GetControlValue("The Value")
    print(TheValue)
    OutData = ArrSelVI.GetControlValue("Out Array")
    print(OutData)

______

So, the communication between Python and LabVIEW shouldn't be a problem.  Now, you may want to use a Queued Message Handler so that separate LabVIEW processes can run without Python having to wait for the VIs it calls to finish.

[steveh01]

akki1811,

I think I have something that might help.  Using the COM interface, Python will wait for whatever VI you call to end before it returns application control back over to Python.  So, if you want to run a continuous loop in LabVIEW from Python you have to do it through VIs that will run quickly and end.  I am attaching some example code to illustrate.   In the example, Display Queue.vi has a message handling loop similar to the Queued Message Handler example.  A Python script acts as the event handling loop, and sends messages to the message handling loop using short-running VIs, and communicating through a Functional Global Variable called MQ_FGV.vi that ensures no two VIs access the message queue at once.  You can use the Buttons.vi to send the same messages if you want to see it all in LabVIEW.

Hopefully this addresses your question of why things get locked-up, and how to work around it.