Should I use LabPython?

[Argold]

Hello there:

I have a big project, pretty much already coded in Labview, designed to perform monte-carlo analysis on a set of applications that use data from time synchronized measurements across the electrical power system.

The project is designed to be open source and distributable using both built .exe and vipm.  Therefore I include ONLY libraries that either come with LV or are OpenG (no third party tools that need to be purchased, and no TestStand).

A part I have yet to code is the monte-carlo engine which needs to be end-user programmable.  I have an idea for creating my own set of commands and a labview interpreter, but before I do that, I'm thinking that many of my end users will already have some python ability.  So I'm trying to decide to use labPython.  The problem is that I have not found any documentation or examples for it yet.

What I need to do, is have the python script, written by the user, access controls (mainly clusters or 2-D tables), overwrite the LV control values, then start a test run.  This is essentially test automation.  Python would be nice because then the user can use local variables to calculate the values to be written into the controls.

So I'm looking for your advice:  Should I give LabPython a try?  If so can someone:

1) point me to some documentation

2) point me to some example code (especially how to access controls).  

3) tell me where to go when I need to ask for help (this forum or another)

Thank you so much.

Edited December 17, 2016 by Argold

[Rolf Kalbermatter]

There is no way to directly access LaVIEW controls from a Python script. You would have to somehow write a Python module and an accompanying LabVIEW module that can communicate with each other. But I'm not sure that is the approach I would choose.

It requires the Python script to know your LabVIEW user interface exactly in order to be able to reference controls on it, which I find to be a rather brittle setup. Technically LabPython is best suited when you can write a library of Python routines that you then call from your LabVIEW code. In that way your LabVIEW program does provide all the information the script would need by passing it as parameters to the routines. Calling back from a Python script into LabVIEW was never really the main intention when I developed LabPython back in the old days :-).

We eventually did Lua for LabVIEW which does support some limited calling back into LabVIEW (limited in that it only works from LabVIEW to Lua or Lua to LabVIEW but not in a recursive loop back and forth) but that is in fact one of the most complicated (and brittle) parts of Lua for LabVIEW. From the initial introduction of Lua for LabVIEW in LabVIEW 6 or so until the latest LabVIEW version, almost all problems that arose with a new LabVIEW release were related to this part of the package.

As to support for LabPython the most likely place to get any feedback at all is probably here, but there are not many people using it nowadays and I haven't written any Python script in at least 10 years. I did a few minor updates in the past to the LabPython shared library to fix some minor quirks but in order to make it work properly with Python 3.0 and newer it would require some real work, also on the C side of the code. It was developed for Python 2.3 or so and works pretty ok up to Python 2.7.x but 3.0 added several changes that also have effect on the C code behind LabPython.

Edited December 28, 2016 by rolfk
Extra info

[Argold]

Thank you Rolf:

It is really great to hear from the original creator and I'm glad you are keeping an eye on things.

I was hoping that I could use some kind of scripting language such as Python or LUA and LabVIEW could pass references to the controls which could be overwritten by the script language.  It sounds to me that that is the difficult and brittle (if not impossible) thing to do.

In the meanwhile I have been trying to write a crude script Interpreter state machine completely in LabVIEW and have gotten as far as being able to handle nested FOR loops.  However I am not sure how to do things like have a script create local variables (such as "A=3.5"), then later use things like A = A+B, etc.  Even more difficult would be to have a variable set to a reference to a control then use it to perform math. this project seems to be very limited and would require my users to learn a strange sort of syntax that the LV interpreter can handle. 

So I'm still hoping for some way to use an existing scripting language and will continue my search and trying out a few things..  It does not sound like you are recommending looking into Lua for LabVIEW ether...

Edited December 29, 2016 by Argold

[Rolf Kalbermatter]

Well, Lua for LabVIEW would give you a lot of the things you hope for but it is not free. So that is the main reason I didn't really push it as a viable option.

Edited December 29, 2016 by rolfk

[G-CODE]

Argold,

I've been thinking about this lately since I think it will become more common for developers to want to be able to do this. It appears that Enthought is trying to sell a toolkit, but it is for calling Python functions from LabVIEW, not the other way around. You want to be able to script LabVIEW functions from Python. JKI has the tools to do what you want as indicated on one of their marketing pages, but they don't make those tools available to anyone.

I noticed NI has a page with links to some Python related tools:

http://forums.ni.com/t5/Community-Documents/Python-and-NI-resources/ta-p/3536750

The most interesting link on that page is a GitHub repository that might  be what you are looking for. I haven't tried it, but I'll likely download it and see what it does.

Another thought I had was to look at Jack Dunaway's Featherweight framework. I believe it uses nanomsg under the hood as its messaging library and nanomsg has several language bindings including Python. Since I'm not completely certain about this, I would get Jack's input before proceeding down that path.

Lastly, there's a way to architect your application so that whatever test sequence you script in Python doesn't have to concern itself or interact with the LabVIEW UI. Your LabVIEW test logic can be started and controlled either from a LabVIEW UI or from a Python script. There's a little bit of work to decouple the LabVIEW UI from the code that runs the tests, but there are a lot of benefits to doing that, including being able to control those tests from Python independent of any LabVIEW UI.

Eric

[Argold]

Thank you Eric for the reply and all the reading.  

I looked at Enthought and came to a similar conclusion from their marketing materials.  

Yes, that GitHub does look interesting.  I'll check it out.

I'll pass on Featherweight for now while I try to learn the basics.  Later it might be interesting.

On your last comment, believe it or not, I'm already there.  Each of my major functions are completely stand-alone cloneable modules which are abstracted using plugins.  They are launched by, and use user events to communicate with, a framework.  The framework can be LabView or Python assuming I figure out how to generate the user events in Python, hence my subsequent thread which you already replied to.

Allen

[G-CODE]

Allen, I spent some time looking at the python_labview_automation GitHub repo and actually trying to get the code to run. It looks like it was probably written in Python 2.X and I have 3.5.1 installed. I modified enough of the 2.X code to get it to at least establish a connection with LabVIEW. When fully functional, it looks like it is supposed to call a VI and set some control inputs. All the code on the LabVIEW side is based on actor framework which probably isn't even necessary for us since all we we want to do is create a TCP server in LabVIEW. To be honest, I think it's overkill for what you (and I) want to be able to do. It is dependent on some other libraries (hoplite, BSON) which make it more difficult to install and run. All we really need to be able to do is to call a function(with arguments) that executes some LabVIEW code. On the LabVIEW side of things we will know the data type of the arguments (received as string) so we can convert the arguments to their correct type. Then we need to send a response back to the Python function that is waiting for it.

Once you receive the command in LabVIEW, you can do whatever you want with it including generating user events, notifiers, putting data in a queue... whatever. So I don't think the question to answer is how to generate a user event from Python. The question to answer is what's the best way to create a communication architecture between these two languages given that we want to call a function with arguments from Python and have it received by a process running in LabVIEW.

As you'll see if you run the example code I attached to the other post, a simple version of this is really easy to implement. It will take a little bit more work to make it full featured enough so it is reusable and works well in our application. I'm thinking a community version of this on GitHub would be really useful and it's about time we have this. I'm not committing myself to doing that, just thinking about it. :-)

[Argold]

Thank you for taking the time to do this.

FYI, my colleagues here pretty much stick with Py 2.7, telling me that many of the scientific packages have not yet been ported to 3.x.  I am new to Python.

I noticed that same thing on the GitHub.  I spent some time with the Actor Framework a while back and decided it was overkill for even some of the big projects I do.  So i ended up making my own stand-alone, cloneable/pluggable module template that depends on user events for communications.  I have been developing hardware abstracted (IVI compliant) clonable modules for instrumentation in my lab.  My (new) goal is to use python for test automation so folks do not need to be labview coders to create new test rigs using my modules.

So for me, event generation really is key because I don't want to go back and re-write my modules.  An alternative would be to make wrappers for them, but it would be best if I can just natively generate the user events.  I am encouraged by the post from ShaunR in the other thread.

So for now I'll keep looking for a way to generate events.  I'm out of town next week (at the IEEE PES JTCM) so there will be a break from this discussion for a bit...

Allen

Edited January 6, 2017 by Argold

[Argold]

On 12/28/2016 at 0:56 AM, rolfk said:

As to support for LabPython the most likely place to get any feedback at all is probably here, but there are not many people using it nowadays and I haven't written any Python script in at least 10 years. I did a few minor updates in the past to the LabPython shared library to fix some minor quirks but in order to make it work properly with Python 3.0 and newer it would require some real work, also on the C side of the code. It was developed for Python 2.3 or so and works pretty ok up to Python 2.7.x but 3.0 added several changes that also have effect on the C code behind LabPython.

Thanks Rolf:

After the discussions here and in the thread about using Python to create user events.  I think I do want to look under the hood of LabPython.  But I am a bit confused about the source relation between Github and the version on the labview tools network.  Both of these are 4.0.0.4 (2011)  Do your know who,  if anyone is maintaining it?