labpython-users — LabPython users mailing list

Re: [LabPython-Users] Updates to the project

[Daniele N. <da...@gr...>]

Hello Rolf,

the first thing I would like to do is to update the LabPython presence
on SourceForge to reflect the current status of the project:

- the code has moved to the OpenG SVN repository,
- python versions up to 2.7 are supported,
- provide a location where to download the latest binaries,
- there is active interest in the project.

Would you like to give me access to the SorceForce project to do that?

Later, I would like to move the code repository to GitLab. What do you
think about this?

On 05/03/16 05:47, Rolf Kalbermatter wrote:
> Not sure which email address Jim would prefer. I'm sure you know about
> his company but he may prefer a different email address mentioned than
> his company address. For me that is certainly true both for legal
> reasons as this was something private rather than from my employer and
> also the fact that work email tends to change sometimes.

While I have been exposed to LabVIEW for quite a long time now, I cannot
consider myself an expert nor I'm much involved with the community. All
the company names I encountered researching contacts for the LabPython
authors were new to me.

> The LabPython code got moved at some point into a subproject of the
> OpenG Toolkit and as such the latest version is in the SVN repository of
> that project. I did recently make minor changes to it to fix the runtime
> errors when loading with Pyton 2.7.

I found the code repository. It seems that it has been imported without
preserving the CVS history. I'll see how difficult it is to stitch
together the two.

> I'm aware that Python has no guarantee about ABI compatibility between
> versions. However reality was that it seemed to work pretty good from
> version 2.2 up to 2.6 and with that minor change I committed recently
> even allows loading with 2.7.

The size of the structures changed, and I believe also the position of
some fields, and some of the API is defined in terms of macros. I'm
surprised this can work at all.

> Another issie is that the Python project
> maintainers never seemed to be very supportive about embedding Python
> into another program and concentrated mainly on extensibility. Any
> inquiry from me about that was at that time either ignored or outrightly
> refused.

I'm surprised. Embedding of the python interpreter is definitely a
supported and documented use-case.

> If you look at the code you will notice that I make use of the
> interpreter lock, but somehow that seems not enough to make Python run
> stable from within a multithreading environment. It could be a
> shortcoming in the interpreter lock handling in the LabPython code,
> maybe caused by internal changes in Python in later version  after 2.3,
> or it could be a fundamental problem, for instance the use of thread
> local storage within Python.

I haven't understood all the details of the implementation, but from a
coarse analysis of the codequick look at the code, there are a few
constructs that look suspicious. Test cases that cause troubles in
LabPython would be definitely useful.

Cheers,
Daniele

Re: [LabPython-Users] Updates to the project

[Daniele N. <da...@gr...>]

Hello Rolf,

thank you for the prompt reply and the useful information.

On 04/03/16 10:50, Rolf Kalbermatter wrote:
> I think you got all relevant people who have ever provided something
> to this project. Basically the C code is all from me, Jim Kring
> helped with some of the LabVIEW VIs and testing and the website.

Great! This has been easy :) However, I would like to know if the email
addresses I found are the "canonical" ones for the persons involved,
such that I can use them in the repository conversion.

> I don't have the interest and the time to dig into LabPython at this
> time so if you want to go with your own, then you are free to do so.
> Just notice that LabPython was and still is LGPL licensed so you can't
> relicense it under a different license at this point.

Re-licensing is definitely not the intent. However, I would prefer to do
not fork the project, but I would like to become a co-maintainer, or
take over maintenance, if as I understand from the above there is
actually no maintainer.

> The dynamic loading of both the Python core and the lvpython part from
> within pytscript is actually not just a random complication. The Python
> kernel was loaded dynamically since the Python developers choose to
> release every new Python version with a different shared library and
> that would have made a new release of LabPython necessary for every new
> Python release. This worked fine until Python 2.7 which introduced
> certain changes in preparation of 3.0 that broke the ABI of the Python
> shared library. Removing that will certainly make maintenance of
> LabPython to work with more than one single Python version more
> complicated than easier.

I may stand corrected on this, but I believe that major python versions
are not guaranteed to be ABI compatible, and thus I don't really see how
dynamically loading the library allows to do not have to recompile
labpython for different python major releases. It may be that doing this
was working, but by accident rather by than design. I believe Python
does not give any guarantee that this works, as has been discovered with
Python 2.7 release.

That said, a new Python major version is released about every 1.5 years.
I don't see recompiling labpython every so often as a major maintenance
burden.

> The separation of pytscript and lvpython was done for a different
> reason. pytscript in order to work has to be in a very specific location
> inside LabVIEW. Anywhere else and the script interface will not
> recognize the shared library as scripting server. But that location is
> not in any of the paths that LabVIEW will search for shared libraries
> when used in a Call Library Node. This makes the whole setup for the
> LabVIEW VI interface very brittle and easy to break as the VIs can and
> sometimes will loose the link to the location of that shared library
> when installed into a non standard LabVIEW system. And when building
> applications these locations are different again. By using dynamic
> linking it is fairly easy to add additional search paths to the loader
> rather than havi g to changge a system global PATH environment variable
> or similar.

I see. I don't know enough about Windows shared library loading system
to comment in any way. However the very small size of lvpython.dll makes
me wonder if it would not be easier to simply ship two independent
shared libraries. Would you like to comment on that possibility?

> From the two interfaces pytscript and the LabVIEW VIs I consider the
> LabVIEW VI interface the much more useful one, as the scripting
> interface can not work with runtime changable scripts. The text of a
> script is compiled into the VI at compile time and cannot be changed at
> runtime (well it can in the development environment with VI scripting,
> provided the VI in question is not part of a running VI hierarchy, but
> that is a Gorilla approach to runtime changable scripts and will not
> work in an executable at all). Rather than removing the dynamic
> interface between pytscript and lvpython I would simply remove the
> enitre pytscript. That makes a lot more sense.

You definitely have a point. However, I believe that for many
applications the functionality offered by pytscript is good enough and
easier to use than the lvpython one.

> Stability problems of LabPython are most likely due to the fact that
> Python isn't multitreading safe

I may not be understanding what you mean, but I think that this is not
the case: Python as the Global Interpreter Lock that serializes access
to the interpreter state from multiple threads. It is through, however,
that the global interpreter lock must be explicitly acquired and
released in threads not initiated by Python itself.

> while LabVIEW will execute Call Library
> Nodes not set to run in the UI thread in any of the multiple threads
> that every executable system has. Changing the Call Library Nodes to run
> in the UI thread is a terrible limitation that will block LabVIEW UI
> changes whenever you execute a Python VI that takes more than a few
> microseconds to do its stuff and eliminate any possibility to do load
> sharing with multiple python sessions,  but adding thread
> synchronization to each lvpython function to make sure a particular
> python context is only invoked from the same thread is going to be a
> project where the dynamic loading of shared library calls looks like
> peanouts in comparison. It's not something I feel inclined to work on at
> the moment. Basically calling thread unsafe code from a multithreading
> environment either requires mutex protection of each resource or thread
> synchronisation or somethimes even both, which would be a very good way
> to create self locking code very easily without VERY tedious discipline
> in the C code and possibily even in the LabVIEW code.

I was under the impression that the Global Interpreter Lock does just
what you describe above. However, I have much more experience extending
Python than embedding Python, thus I may be wrong. I'm happy to
investigate this more.

Thank you for your comments!

Cheers,
Daniele

Re: [LabPython-Users] Updates to the project

[Daniele N. <da...@gr...>]

On 04/03/16 12:38, Rolf Kalbermatter wrote:
> By the way the latest version of LabPython is not on the CVS repository
> of sourceforge but rather in the SVN repository.

Which SVN repository?

Cheers,
Daniele

Re: [LabPython-Users] Updates to the project

[Rolf K. <rol...@gm...>]

By the way the latest version of LabPython is not on the CVS repository of
sourceforge but rather in the SVN repository.

Sincerely

Rolf Kalbermatter

Re: [LabPython-Users] Updates to the project

[Rolf K. <rol...@gm...>]

Hi Daniele

I think you got all relevant people who have ever provided something to
this project. Basically the C code is all from me, Jim Kring helped with
some of the LabVIEW VIs and testing and the website.

I don't have the interest and the time to dig into LabPython at this time
so if you want to go with your own, then you are free to do so. Just notice
that LabPython was and still is LGPL licensed so you can't relicense it
under a different license at this point.

The dynamic loading of both the Python core and the lvpython part from
within pytscript is actually not just a random complication. The Python
kernel was loaded dynamically since the Python developers choose to release
every new Python version with a different shared library and that would
have made a new release of LabPython necessary for every new Python
release. This worked fine until Python 2.7 which introduced certain changes
in preparation of 3.0 that broke the ABI of the Python shared library.
Removing that will certainly make maintenance of LabPython to work with
more than one single Python version more complicated than easier.

The separation of pytscript and lvpython was done for a different reason.
pytscript in order to work has to be in a very specific location inside
LabVIEW. Anywhere else and the script interface will not recognize the
shared library as scripting server. But that location is not in any of the
paths that LabVIEW will search for shared libraries when used in a Call
Library Node. This makes the whole setup for the LabVIEW VI interface very
brittle and easy to break as the VIs can and sometimes will loose the link
to the location of that shared library when installed into a non standard
LabVIEW system. And when building applications these locations are
different again. By using dynamic linking it is fairly easy to add
additional search paths to the loader rather than havi g to changge a
system global PATH environment variable or similar.

>From the two interfaces pytscript and the LabVIEW VIs I consider the
LabVIEW VI interface the much more useful one, as the scripting interface
can not work with runtime changable scripts. The text of a script is
compiled into the VI at compile time and cannot be changed at runtime (well
it can in the development environment with VI scripting, provided the VI in
question is not part of a running VI hierarchy, but that is a Gorilla
approach to runtime changable scripts and will not work in an executable at
all). Rather than removing the dynamic interface between pytscript and
lvpython I would simply remove the enitre pytscript. That makes a lot more
sense.

Stability problems of LabPython are most likely due to the fact that Python
isn't multitreading safe while LabVIEW will execute Call Library Nodes not
set to run in the UI thread in any of the multiple threads that every
executable system has. Changing the Call Library Nodes to run in the UI
thread is a terrible limitation that will block LabVIEW UI changes whenever
you execute a Python VI that takes more than a few microseconds to do its
stuff and eliminate any possibility to do load sharing with multiple python
sessions,  but adding thread synchronization to each lvpython function to
make sure a particular python context is only invoked from the same thread
is going to be a project where the dynamic loading of shared library calls
looks like peanouts in comparison. It's not something I feel inclined to
work on at the moment. Basically calling thread unsafe code from a
multithreading environment either requires mutex protection of each
resource or thread synchronisation or somethimes even both, which would be
a very good way to create self locking code very easily without VERY
tedious discipline in the C code and possibily even in the LabVIEW code.

Sincerely

Rolf Kalbermatter

Re: [LabPython-Users] Updates to the project

[fesegre <enr...@we...>]

I've only been an user of labpython for a certain project at the time of 
my previous messages to this list; nevertheless I still consider it as 
aviable tool worth keeping an eye onto, which I'll gladly use again; 
therefore I'd be only happy if the project is maintained and modernized. 
I miss time and skills to be much of help with it, tough, as of now. 
Good luck with your effort!

Limitations I stumbled into in the past, from the user point of view, 
are indeed: only 32bit windows platform, instability, lack of thread 
safety, issue with name visibility, mentioned in my previous messages.

Enrico

[LabPython-Users] Updates to the project

[Daniele N. <da...@gr...>]

Hello,

I recently discovered LabPython and I'm considering using it, However,
it seems that there is not much activity on the project and that it
cannot be used in its current state on a modern system.

I downloaded the code and implemented some of the required updates:

- I replaced the Visual Studio based build system with a 'waf' build
  script [1] (https://waf.io/). This makes the project independent of
  the compiler suite, and Python is of course already a dependency to
  build LabPython, and I expect anyone interested in hacking on it to
  be at least minimally familiar with Python to be able to understand
  what the build script does.

- In the process of making it work with recent Python releases, I
  cleaned up the code a bit removing the support for loading the python
  interpreter support library at runtime. It made things much more
  complex without any apparent benefit.

- I imported the CVS project history into a git repository and I'm
  considering to merge the 'labpython_c_source' and 'labpython' modules
  into one. I would like to migrate the project to GitLab.

There are two things that I would still like to work on:

- I'm considering directly linking the pytscript shared library to the
  lvpython shared library as I don't see the advantage of the runtime
  loading. This would allow to drop some more code.

- I see LabVIEW crashes on loading/unloading/reloading of VIs using
  LabPython. I suspect something is wrong either in the Python
  interpreter is initialized, or in the threads managements. I would
  like to investigate this a bit more.

I would like to hear the opinion of the old maintainers of the project
about what I've done and about the plans I have, and, because of the
very low recent activity I would like to ask if they mind if I take over
maintenance, migrating the project to GitLab.

In any case, if a migration away from CVS as a version control system is
seen as something desirable, I volunteer to take care of it. For that I
would like to collect for each person that contributed to the project a
real name and a preferred email address to associate to their SorceForge
user names, that will be used to identify the authors of the commits in
the project history. I can get real names from SourceForge, but
apparently I cannot obtain email addresses. Due to the very low traffic
on this mailing list I added the email address of the SorceForge project
admins that I found with a web search in Cc.

Thank you. Cheers,
Daniele

Re: [LabPython-Users] A question from a beginner

[fesegre <enr...@we...>]

<html style="direction: ltr;">
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
    <style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
  </head>
  <body style="direction: ltr;"
    bidimailui-detected-decoding-type="UTF-8" bgcolor="#FFFFFF"
    text="#000000">
    If your "summary" prints to stdout, perhaps you can use the trick of
    redirecting stdout to a string, and retreive it afterwards. Like was
    described in
    <a class="moz-txt-link-freetext" href="http://sourceforge.net/p/labpython/mailman/message/28364359/">http://sourceforge.net/p/labpython/mailman/message/28364359/</a> and
    antecedents.<br>
    Enrico<br>
  </body>
</html>

[LabPython-Users] A question from a beginner

[ChiangKim <jia...@ou...>]

Hi ，everyone!
I'm just a student ans this is my first time to use python and Labpython, but I meet a trouble so I ask for some help.
I use a software package "igraph" in python .There is an igraph's own namespace summary()  ,when I command this,some information shows like this:

>>> summary(g)
6 vertices, 6 edges, undirected
Number of components: 2
Diameter: 1
Density: 0.4000
Average path length: 1.0000
print also shows some information:
>>> print g
Undirected graph (|V| = 3, |E| = 2)In labpython,I can do it  to show the information that "print g" give as string




But I can't find the way to use "summary(g)"
Would you please help me ?
Many thanks!
 		 	   		  

[LabPython-Users] thread safety and error 1047

[Enrico S. <enr...@we...>]

<html style="direction: ltr;">
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8"><style>body
      p { margin-bottom: 0cm; margin-top: 0pt; } </style>
  </head>
  <body style="direction: ltr;"
    bidimailui-detected-decoding-type="UTF-8" bgcolor="#FFFFFF"
    text="#000000">
    I am trying to run several instances of labpython in parallel, to
    increase performance and balance the load of different threads in my
    LV application. I still have to dissect and debug the problem, but I
    suspect that I'm discovering that labpython is not thread safe, in
    the sense that I get different results depending on the number of
    workers simultaneously running, and variable results with the same
    input data from run to run.<br>
    <br>
    In this old thread,
    <a class="moz-txt-link-freetext" href="http://sthmac.magnet.fsu.edu/LV/ILVDigests/2003/12/11/Info-LabVIEW_Digest_2003-12-11_004.html">http://sthmac.magnet.fsu.edu/LV/ILVDigests/2003/12/11/Info-LabVIEW_Digest_2003-12-11_004.html</a>
    Rolf says:<br>
    <br>
    <blockquote type="cite">In LabPython there is some serious locking
      done as well on the Python<br>
      system level as the Python system is at this time not safely
      reentrant<br>
      but it shouldn't block the LabVIEW UI thread.<br>
    </blockquote>
    <br>
    Possibly related, I also observe frequent occurrences of Error 1047
    from PYTHON Set Data when trying to pass variables to a script.
    These occur mostly when the script is called "too often" or
    concurrently with other running labpython sessions. The workaround
    I've found is to feed the script text again to the problematic
    labpython session (PYTHON Set Script Text) and to recompile (PYTHON
    Compile Script).<br>
    <br>
    Is there still anybody who can shed some light on the details?<br>
    <br>
    Enrico<br>
    <br>
  </body>
</html>

[LabPython-Users] R: Occasional "failed to send variable to the scriptserver"

[Enrico S. <enr...@we...>]

>In the process of developing a larger application, I'm running my labpython chain in parallel with other LV stuff, making heavy use of images and camera communication >trough a proprietary sdk, that is without having much idea about things happening in hidden threads. I remark that while the labpython part runs smoothly standalone, >once the load is increased I get very often Error 1047 - "LabVIEW failed to send variable to the script server" out of the initial PYTHON Set Data vi, that is routine >lvsnSetLabVIEWData returns with code 1 rather than 0. To recover from the error I can run again in the call chain PYTHON Set script.vi and PYTHON Compile Script.vi. 

Problem solved. It was not a "load" or a "thread" problem, what caused the disconnection from the script server, but the fact that sometimes I was trying to retrieve from Python a zero sized array, at the end of the previous iteration of the computation. The workaround has been simply to have the python script output the dimension of that array in another variable, retrieve it (PYTHON Get Data.vi) first, and then conditionally retrieve the array only if dim>0. For future memory.

[LabPython-Users] R: R: comments on labpython (WORKING with LV2010/python 2.7.1)

[Enrico S. <enr...@we...>]

>The examples are in Labview 2010.  If possible, please can you convert to Labview 2009?

Here you go.
Enrico

Re: [LabPython-Users] R: comments on labpython (WORKING with LV2010/python 2.7.1)

[Ian P. <ian...@er...>]

Hi Enrico,

Thanks for update.  Excellent idea, and certainly makes reading errors back easier.

The examples are in Labview 2010.  If possible, please can you convert to Labview 2009?

Best Regards
Ian
________________________________________
From: Enrico Segre [enr...@we...]
Sent: 02 November 2011 15:03
To: 'LabPythonUsers Mailing List'
Subject: [LabPython-Users] R: comments on labpython (WORKING with LV2010/python 2.7.1)

>Issue (2) makes it very diffuclt to debug any code, in particular code that works ok in python IDLE but not in Labview (+ labpython).
>I also find the lack of feedback when running a labpython script also limiting (i.e. Print statement doesn't output to anywhere).  It would be great if the print command >and error information could be displayed in a dos window or better in a dedicated window in labview, and even better if this was updated in real time.

>To overcome the issues above, I now use the following as part of my python code.
>
>import sys
># Re-direct stdout
>...

I've elaborated a little on your idea, and send stdout and stderr to python strings with the following variation:

import sys
from StringIO import StringIO
import traceback

# Re-direct stdout
old_stdout = sys.stdout
sys.stdout = stdoutcapture = StringIO()

# Re-direct stderr
stderrstring=""

try:
    # [insert code here]

except:
    stderrstring=traceback.format_exc()
    print "Unexpected error:", sys.exc_info()

sys.stdout = old_stdout
stdoutstring=stdoutcapture.getvalue()

After the Python Execute script node, I can pull the variables  stdoutstring and stdoutstring into labview, and see the result. No realtime, but helps. No hassle of handling files in changing directories and reading them back into LV.
Attached an llb containing two small convenience vi's - one for wrapping the python script, the other for reading back the variables into LV strings.
Enrico

[LabPython-Users] Occasional "failed to send variable to the script server"

[Enrico S. <enr...@we...>]

In the process of developing a larger application, I'm running my labpython chain in parallel with other LV stuff, making heavy use of images and camera communication trough a proprietary sdk, that is without having much idea about things happening in hidden threads. I remark that while the labpython part runs smoothly standalone, once the load is increased I get very often Error 1047 - "LabVIEW failed to send variable to the script server" out of the initial PYTHON Set Data vi, that is routine lvsnSetLabVIEWData returns with code 1 rather than 0. To recover from the error I can run again in the call chain PYTHON Set script.vi and PYTHON Compile Script.vi. However the frequency of this happening troubles me. Is there an explanation why this could happen, and a workaround (e.g. a timeout which could be increased?)
Enrico

[LabPython-Users] R: comments on labpython (WORKING with LV2010/python 2.7.1)

[Enrico S. <enr...@we...>]

>Issue (2) makes it very diffuclt to debug any code, in particular code that works ok in python IDLE but not in Labview (+ labpython).
>I also find the lack of feedback when running a labpython script also limiting (i.e. Print statement doesn't output to anywhere).  It would be great if the print command >and error information could be displayed in a dos window or better in a dedicated window in labview, and even better if this was updated in real time.

>To overcome the issues above, I now use the following as part of my python code.
>
>import sys
># Re-direct stdout
>...

I've elaborated a little on your idea, and send stdout and stderr to python strings with the following variation:

import sys
from StringIO import StringIO
import traceback

# Re-direct stdout
old_stdout = sys.stdout
sys.stdout = stdoutcapture = StringIO() 

# Re-direct stderr
stderrstring=""

try:
    # [insert code here]

except:
    stderrstring=traceback.format_exc()
    print "Unexpected error:", sys.exc_info()

sys.stdout = old_stdout
stdoutstring=stdoutcapture.getvalue()

After the Python Execute script node, I can pull the variables  stdoutstring and stdoutstring into labview, and see the result. No realtime, but helps. No hassle of handling files in changing directories and reading them back into LV.
Attached an llb containing two small convenience vi's - one for wrapping the python script, the other for reading back the variables into LV strings.
Enrico

Re: [LabPython-Users] comments on labpython (WORKING withLV2010/python 2.7.1)

[Enrico S. <enr...@we...>]

 Thanks for all of your answers, Rolf!

Re: [LabPython-Users] comments on labpython (WORKING with LV2010/python 2.7.1)

[Rolf K. <r.k...@hc...>]

>For what matters, luaview has an emulated stdout in a LV window, as support
for the print statement. But luaview has certainly

>a much more complex handling of the interaction with LV, and can run
asynchronously. A developer could perhaps say how

>difficult could be to implement such a feature .

 

Actually LuaVIEW does this by starting up a background deamon in LabVIEW
that receives those messeages from a queue. Neat but

quite involved, and it makes all kinds of involved initialization behind the
scenes necessary. Definitely not what I had intended to do

with LabPython.

 

>I can add a further wish: support for more input/output types. For instance
I find myself dealing with images, which are large

>matrices of U8, and I would be forced to cast them to I32 in LV and
downcast back to U8 in python; that is a detour and requires

>extra memory and time. (currently I convert them to strings, bytearray and
reshape them in python, which wastes less memory

>but is still a detour).



This is a limit by Python itself. Maybe newer versions support additional
types but when I worked on LabPython the only internal supported

basic datatypes in Python were Int, Long, Real and Complex. I did not find
it useful to make involved conversions between all possible

LabVIEW datatypes to these four basic Python types. And no, optional modules
like numpy or such are not a good option. There was no

good C API to access modules with, that could or could not be present. That
is also why I implemented arrays as lists. The array datatype

was only in an optional module whose use was discouraged at that time.

 

Rolf Kalbermatter

CIT Engineering Netherlands BV

Re: [LabPython-Users] comments on labpython (WORKING with LV2010/python 2.7.1)

[Rolf K. <r.k...@hc...>]

Hi Enrico

Thanks for your interesting report and a possible solution to a problem
quite a lot of people seem to have run across in the past.

>2) I find that the error messages reported by the labpython script note and
by PYTHON Execute script.vi miss what would
>be very useful information for debugging - the call stack or at least the
offending python line number. Luaview reports such
>information (in fact, contrary to LV convention of reporting only the
source vi in the error cluster), and there is very useful.
>Luaview and labpython share the same author IIUC...

Just a small correction: LabPython was developed by me long ago, mainly as
an exercise to test the script node interface that had appeared
around LabVIEW 5. In order to test and debug the package interactively I had
also developed a VI interface to it and that appeared to be
quite handy as it allowed dynamic execution of Python scripts while the
script node was static at runtime.

LuaVIEW on the other hand was originally developed by my collegue Albert-Jan
Brouwer for a large project he was working on. As such it was
definitely more production quality class and there was a lot more time and
energy invested into it. Over time I started to help with small
maintenance tasks and modifications to it and I'm currently the maintainer
of LuaVIEW. We are currently discussing internally about a LuaVIEW
update and possible changes in how it will be distributed/licensed, possibly
as part of the LabVIEW Tools Network.

As much as I would like to work on some improvements to LabPython, I do lack
both the time and commercial justification to do so. Some
things like improved error messages would probably be not so hard to add,
the issue about non global identifiers I would have no glue at this
time why that would work different in the IDE than in LabPython.

>3) I found one case, whith a 160 line python script which imports modules,
in which the first call to PYTHON Execute script.vi takes
>significantly more time than subsequent calls, *despite the fact that the
script is precompiled*. The test is done by the BD attached, and
>the overhead for the first call is some 600ms. Is there an explanation for
the fact?

There are quite a few possible reasons for something like that, such as
additional binary or other modules that are used by your script that
might have a lengthy initialization procedure. Remember that every LabPython
session is much like an IDE command line. In your IDE you
have probably also a lengthy initialization time for that script the first
time you run it, but it may be harder to notice. Once you have run it
the various modules are loaded and remain loaded until you close the IDE
shell. Same for a LabPython session, but if you open a new session
you effectively create a completely new and independent Python environment,
that shares no variables, modules or whatsoever with other
sessions.

Rolf Kalbermatter
CIT Engineering Nederlands BV

Re: [LabPython-Users] comments on labpython (WORKING with LV2010/python 2.7.1)

[Enrico S. <enr...@we...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: ltr;">
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <style>body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
</head>
<body style="direction: ltr;"
 bidimailui-detected-decoding-type="latin-charset" bgcolor="#ffffff"
 text="#000000">
Hi Ian,<br>
<br>
<blockquote
 cite="mid:C0F...@ES..."
 type="cite">
  <p><font size="2"><font size="3"><font face="Arial" size="2">I have
tended to avoid the "Python Script Node" as I found this less reliable.<br>
  </font></font></font></p>
</blockquote>
<p>I haven't yet accumulated enough experience to compare reliability.
I'd just prefer the python session over the script node for all but the
simplest tests, because you can create the python content
programmatically - or load the python code at runtime from a file you
edit more conveniently in a dedicated editor.<br>
</p>
<blockquote
 cite="mid:C0F...@ES..."
 type="cite">
  <p><font size="2"><font size="3"><font face="Arial" size="2"><br>
Issue (2) makes it very diffuclt to debug any code, in particular code
that works ok in python IDLE but not in Labview (+ labpython).</font></font></font></p>
</blockquote>
<p>Definitely.<br>
</p>
<blockquote
 cite="mid:C0F...@ES..."
 type="cite">
  <p><font size="2"><font size="3"><font face="Arial" size="2">I also
find the lack of feedback when running a labpython script also limiting
(i.e. Print statement doesn't output to anywhere).&nbsp; It would be great
if the print command and error information could be displayed in a dos
window or better in a dedicated window in labview, and even better if
this was updated in real time.</font></font></font></p>
</blockquote>
<p>For what matters, luaview has an emulated stdout in a LV window, as
support for the print statement. But luaview has certainly a much more
complex handling of the interaction with LV, and can run asynchronously.
A developer could perhaps say how difficult could be to implement such
a feature .<br>
</p>
<blockquote
 cite="mid:C0F...@ES..."
 type="cite">
  <p><font size="2"><font size="3"><font face="Arial" size="2"><br>
To overcome the issues above, I now use the following as part of my
python code.<br>
  </font><br>
  </font><font size="3"><font color="#0000ff">...<br>
  </font><br>
  </font><font face="Arial" size="2">This effectively redirects the
stdout (print command) and stderr (error information) to a text file or
debug log.</font></font></p>
</blockquote>
<p>viable idea<br>
</p>
<blockquote
 cite="mid:C0F...@ES..."
 type="cite">
  <p><font size="2"><font face="Arial" size="2">I have also noticed the
following additional issue:<br>
1) If I run the code below in labpython, then it works on the first
iteration.</font></font></p>
</blockquote>
Can't comment on this.<br>
<br>
I can add a further wish: support for more input/output types. For
instance I find myself dealing with images, which are large matrices of
U8, and I would be forced to cast them to I32 in LV and downcast back
to U8 in python; that is a detour and requires extra memory and time.
(currently I convert them to strings, bytearray and reshape them in
python, which wastes less memory but is still a detour).<br>
<br>
Enrico<br>
</body>
</html>

Re: [LabPython-Users] comments on labpython (WORKING with LV2010/python 2.7.1)

[Ian P. <ian...@er...>]

Hi Enrico,

I also use labpython a lot for similar reasons, and think it is really excellent.

I follow a very similar labpython setup to your "sessionchain.jpg" example.  I have tended to avoid the "Python Script Node" as I found this less reliable.

I have seen similar issues to what you describe in (1) and (2).

Issue (2) makes it very diffuclt to debug any code, in particular code that works ok in python IDLE but not in Labview (+ labpython).
I also find the lack of feedback when running a labpython script also limiting (i.e. Print statement doesn't output to anywhere).  It would be great if the print command and error information could be displayed in a dos window or better in a dedicated window in labview, and even better if this was updated in real time.

To overcome the issues above, I now use the following as part of my python code.

import sys
# Re-direct stdout
old_stdout = sys.stdout
fstdout = open('stdout.log', 'a')
sys.stdout = fstdout

# Re-direct stderr
old_stderr = sys.stderr
fstderr = open('stderr.log', 'a')
sys.stderr = fstderr

try:
    print("Place python code here")

except:
    import traceback
    traceback.print_exc()
    print "Unexpected error:", sys.exc_info()

sys.stdout = old_stdout
fstdout.close()

sys.stderr = old_stderr
fstderr.close()

This effectively redirects the stdout (print command) and stderr (error information) to a text file or debug log.
This has allowed me to debug my python code more effectively, but ideally it would be nice to redirect this information to a Labview variable (ideally updated in realtime when executing)

I have also noticed the following additional issue:
1) If I run the code below in labpython, then it works on the first iteration.

import xml.etree.cElementTree as ET

try:
    f = file('C:/index.xml')
    root = ET.parse(f).getroot()
    print root
    name = root.findtext('name')
    print name
except:
    import traceback
    traceback.print_exc()
    print "Unexpected error:", sys.exc_info()

But crashes on further interations.  Producing the following error:

Unexpected error: (<type 'exceptions.TypeError'>, TypeError("'NoneType' object is not callable",), <traceback object at 0x0F2185D0>)
Traceback (most recent call last):
  File "<LabVIEW>", line 20, in <module>
  File "<string>", line 56, in parse
  File "<string>", line 24, in parse


If I shut down the vi and re-open it, then the code works again.
I tried unloading labpython dll (see: http://digital.ni.com/public.nsf/allkb/77594203D78D12278625729100758BE5), but this didn't solve the problem.
I also tried dynamically executing (http://forums.ni.com/t5/LabVIEW/Remove-or-delete-vi-from-memory/m-p/1671806/highlight/true#M596119) the labpython vi.  This loads the vi into memory and then unloads it when finished.  This seemed to work to a point.

In the end I found that it was related to the cElementTree module being imported.
If I change the code to (standard python Element Tree library aka ElementTree)
import xml.etree.ElementTree as ET

Then all works fine.  I am not sure if this a problem with the cElementTree Module in python or with labpython.

I have also noticed that labpython is not included in VI Package Manager.  It would be nice to get this included again and therefore maybe get more wider use.

Overall, an excellent addition to both Labview and python, but if anybody has the knowledge to help support better management for debugging e.g. Routing stdout and stderr to labview variables, then this would certainly greatly reduce debug time.

Best Regards
Ian



-----Original Message-----
From: Enrico Segre [mailto:enr...@we...]
Sent: mercoledì 24 agosto 2011 12.02
To: lab...@li...
Subject: [LabPython-Users] comments on labpython (WORKING with LV2010/python 2.7.1)

In this message
http://lavag.org/topic/8137-labpython-error-message/page__view__findpost__p__48425
Rolf Kalbermatter complained about very low feedback about labpython, and mostly in the form of "help me it doesn't work" by random users.

I'd like to mend for that and submit a few comments. Labpython works for me and is great, and helps me integrating in a big LV frame some image processing code written earlier in python. I'm essentially illitterate in python and trying to pick up quickly.

I'm using labpython in LV2010sp1 (yes it works!), with python 2.7.1 together with some modules, which at the moment are numpy 1.6.1 and matplotlib 1.0.1 (both just installed from the respective windows installers, no need to set paths, anything) and openCV 2.2.0 (just needed to copy the two files cv.lib and cv.pyd to Python 2.7\Lib\site-packages\). Platform is Windows7/32bit (and pity linux is not supported...)

I have a couple of comments though:

1) there seems to be a name visibility problem, or maybe a strict private variable enforcement (? -- my python ignorance), such that functions cannot see variables defined outside them (this is different than in IDLE).
Notably, this produces errors like
"PYTHON Execute Script__ogtk.vi->xxxxx.vi:<type 'exceptions.NameError'>, global name 'yyyy' is not defined", and seems to be what people trying to use modules stumble upon. The problem has been already reported earlier (http://forums.ni.com/t5/LabVIEW/LabPython-Global-Variables/m-p/1481590/highlight/false
http://forums.openg.org/index.php?showtopic=1152
http://lavag.org/topic/12661-importing-modules/page__hl__labpython__fromsearch__1 ); I stumbled on it at first, but worked around it by declaring the necessary modules and variables global.

2) I find that the error messages reported by the labpython script note and by PYTHON Execute script.vi miss what would be very useful information for debugging - the call stack or at least the offending python line number. Luaview reports such information (in fact, contrary to LV convention of reporting only the source vi in the error cluster), and there is very useful. Luaview and labpython share the same author IIUC...

3) I found one case, whith a 160 line python script which imports modules, in which the first call to PYTHON Execute script.vi takes significantly more time than subsequent calls, *despite the fact that the script is precompiled*. The test is done by the BD attached, and the overhead for the first call is some 600ms. Is there an explanation for the fact?

Enrico

PS for Rolf - I'm also perusing luaview (win & linux) in another project of mine - KEEP UP THE GOOD WORK!

[LabPython-Users] comments on labpython (WORKING with LV2010/python 2.7.1)

[Enrico S. <enr...@we...>]

In this message
http://lavag.org/topic/8137-labpython-error-message/page__view__findpost__p__48425
Rolf Kalbermatter complained about very low feedback about labpython, and mostly in the form of "help me it doesn't work" by random users.

I'd like to mend for that and submit a few comments. Labpython works for me and is great, and helps me integrating in a big LV frame some image processing code written earlier in python. I'm essentially illitterate in python and trying to pick up quickly.

I'm using labpython in LV2010sp1 (yes it works!), with python 2.7.1 together with some modules, which at the moment are numpy 1.6.1 and matplotlib 1.0.1 (both just installed from the respective windows installers, no need to set paths, anything) and openCV 2.2.0 (just needed to copy the two files cv.lib and cv.pyd to Python 2.7\Lib\site-packages\). Platform is Windows7/32bit (and pity linux is not supported...)

I have a couple of comments though:

1) there seems to be a name visibility problem, or maybe a strict private variable enforcement (? -- my python ignorance), such that functions cannot see variables defined outside them (this is different than in IDLE).
Notably, this produces errors like 
"PYTHON Execute Script__ogtk.vi->xxxxx.vi:<type 'exceptions.NameError'>, global name 'yyyy' is not defined", and seems to be what people trying to use modules stumble upon. The problem has been already reported earlier (http://forums.ni.com/t5/LabVIEW/LabPython-Global-Variables/m-p/1481590/highlight/false
http://forums.openg.org/index.php?showtopic=1152
http://lavag.org/topic/12661-importing-modules/page__hl__labpython__fromsearch__1 ); I stumbled on it at first, but worked around it by declaring the necessary modules and variables global.

2) I find that the error messages reported by the labpython script note and by PYTHON Execute script.vi miss what would be very useful information for debugging - the call stack or at least the offending python line number. Luaview reports such information (in fact, contrary to LV convention of reporting only the source vi in the error cluster), and there is very useful. Luaview and labpython share the same author IIUC...

3) I found one case, whith a 160 line python script which imports modules, in which the first call to PYTHON Execute script.vi takes significantly more time than subsequent calls, *despite the fact that the script is precompiled*. The test is done by the BD attached, and the overhead for the first call is some 600ms. Is there an explanation for the fact?

Enrico

PS for Rolf - I'm also perusing luaview (win & linux) in another project of mine - KEEP UP THE GOOD WORK!

[LabPython-Users] LabVIEW 2010

[montri <Jos...@on...>]

Hello,

I want to us The Python Script Node with LabVIEW 2010.
Has anymone try this version ?
How do you configure the script node ?

Best regards,

Jo

Re: [LabPython-Users] How to initialize python script server - Labpython

[Sathish S <sa...@so...>]

Atul,

Have you installed python in your PC ? If not install it first. If you have
installed then, Open up the PYTHON Set Server Path__ogtk.vi, browse and
select the pythonxx.dll in Windows\System32 and run the VI. This should
solve your problem.

Thanks,
Sathish


On Wed, Sep 29, 2010 at 12:44 PM, atul bansal <atu...@gm...> wrote:

> Hello, I am trying to use Python Script Node in labview but i am not able
> to initialize python script server.
>
> every time getting a error *"LabVIEW:  LabVIEW cannot initialize the
> script server.  Ensure the server software is installed. in Untitled 3"*.
>
> kindly help me to resolve this problem.
>
> --
> With regards,
> Atul Bansal
>
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> LabPython-Users mailing list
> Lab...@li...
> https://lists.sourceforge.net/lists/listinfo/labpython-users
>
>

[LabPython-Users] How to initialize python script server - Labpython

[atul b. <atu...@gm...>]

Hello, I am trying to use Python Script Node in labview but i am not able to
initialize python script server.

every time getting a error *"LabVIEW:  LabVIEW cannot initialize the script
server.  Ensure the server software is installed. in Untitled 3"*.

kindly help me to resolve this problem.

-- 
With regards,
Atul Bansal

[LabPython-Users] Error While Importing Module

[Sathish S <sa...@so...>]

Hi ppl,

I created a class within a module, and tried to import the module in a
script. While importing the module i'm getting the following error. However
I'm able to import these modules in the python IDE

Error code: Error 1050 occurred at PYTHON Execute Script__ogtk.vi->Script
Editor.vi:<type 'exceptions.WindowsError'>,

my module looks like this:

class myclass:

    def __init__(self):
    ...

and I also added the module path using the sys.path.append command
my script is as below

import sys
sys.path.append('....')
import myclass
...

what could be the issue ?

Thanks,
Sathish