labpython-users

[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!

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!

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)

[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 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...>]

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