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!