Thread: RE: [LabPython-Users] Hello

Hi Ian,
=20
Yes I use the script node and it works with Python 2.4 with some issues:
=20
1. Only one script node per VI.
2. LabVIEW hangs when the VI is closed. So I have to kill LabVIEW using
CTRL+ALT+Delete.
=20
The recipe is like this:
=20
1. Download the package.
2. Copy pytscript.dll from labpython\File Group 0 to "C:\Program
Files\National Instruments\LabVIEW 7.1\resource\script".=20
5. Copy the labpython\File Group 2\labpython folder into "C:\Program
Files\National Instruments\LabVIEW 7.1\user.lib" or vi.lib depending on
where you want the menu to appear in LabVIEW.
3. Open "PYTHON Set Server Path.vi" (in labpython\File Group
2\labpython) and execute it with path "C:\WINNT\system32\python24.dll".
4. Test the three VIs in labpython\File Group 3 and then File->Save with
Options.../Save these. The labpython folder in your user.lib/vi.lib is
now compiled to use python24.dll so you won't need to run "PYTHON Set
Server Path.vi" again.=20
=20
I currently use a Python script VI as a toplevel GUI to a Python object
that controls the rest of my mostly LabVIEW-based test system. So when I
run the script, a number of subVIs open up and stay in run mode until I
delete my test object in the script.=20
=20
Because of the bug 2 above, I plan to move the toplevel script into a
pyton file that uses the GUI as a subVI instead. I can send the neat
LabVIEW.py file I use to remote LabVIEW if you like (it runs on top of
the win32com module).
=20
I took a look at the C code for the pytscript.dll and I think the bug is
that the dll doesn't disconnect the session with the Python interpreter
properly. It should probably call sys.exit () as cleanup when the VI is
closed, but it was not obvious to me where I should do that. I got stuck
because I didn't find the API description for LabVIEWs script node and I
can live with the bug for a while.
=20
Please notify if you can't get it to work using the recipe above or if
you dig further into the C code or get rid of the bug somehow.
=20
Best wishes,
Joakim
=20
________________________________

From: lab...@li...
[mailto:lab...@li...] On Behalf Of I
Phillips
Sent: den 7 december 2005 12:12
To: lab...@li...
Subject: [LabPython-Users] Hello



Hi everybody,=20

Anybody currently using LabPython ?=20

I have been using Labview for years, and have just started writing
scripts in Python, so I thought now was a good time to integrate the
two.=20

Any examples/tips/known issues would be welcome.=20

Thanks in advance=20

Ian

Hi Joakim,

Thanks for the intro. to Labpython.

I have tracked down the bug to Python 2.3.5.
i.e. if you install any version upto and including Python 2.3.4, then the 
bug isn't present.

The big thing that sticks out in the python release between v.2.3.4 and 
v2.3.5 is a security patch (http://www.python.org/security/PSF-2005-001/).
"Note that these patches disable recursive traversal."

I am not an expert in python or programming, but think that this may be 
worth investigating.

Are any of the original developers still subscribed to this user group? 
Would you see this as a possible issue?

A second bug I have found, is that if the python input("Please enter your name") command is used, and executed using the Labpython Execute script.vi then 
Labview crashes.

If anybody can highlight any other bugs, or help solve the bug above that 
would be great.

Cheers everybody

Ian





"Joakim Pettersson (LD/EAB)" <joa...@er...>
Sent by: lab...@li...
07/12/2005 13:12
Please respond to labpython-users

 
        To:     <lab...@li...>
        cc: 
        Subject:        RE: [LabPython-Users] Hello


Hi Ian,
 
Yes I use the script node and it works with Python 2.4 with some issues:
 
1. Only one script node per VI.
2. LabVIEW hangs when the VI is closed. So I have to kill LabVIEW using 
CTRL+ALT+Delete.
 
The recipe is like this:
 
1. Download the package.
2. Copy pytscript.dll from labpython\File Group 0 to "C:\Program 
Files\National Instruments\LabVIEW 7.1\resource\script". 
5. Copy the labpython\File Group 2\labpython folder into "C:\Program 
Files\National Instruments\LabVIEW 7.1\user.lib" or vi.lib depending on 
where you want the menu to appear in LabVIEW.
3. Open "PYTHON Set Server Path.vi" (in labpython\File Group 2\labpython) 
and execute it with path "C:\WINNT\system32\python24.dll".
4. Test the three VIs in labpython\File Group 3 and then File->Save with 
Options.../Save these. The labpython folder in your user.lib/vi.lib is now 
compiled to use python24.dll so you won't need to run "PYTHON Set Server 
Path.vi" again. 
 
I currently use a Python script VI as a toplevel GUI to a Python object 
that controls the rest of my mostly LabVIEW-based test system. So when I 
run the script, a number of subVIs open up and stay in run mode until I 
delete my test object in the script. 
 
Because of the bug 2 above, I plan to move the toplevel script into a 
pyton file that uses the GUI as a subVI instead. I can send the neat 
LabVIEW.py file I use to remote LabVIEW if you like (it runs on top of the 
win32com module).
 
I took a look at the C code for the pytscript.dll and I think the bug is 
that the dll doesn't disconnect the session with the Python interpreter 
properly. It should probably call sys.exit () as cleanup when the VI is 
closed, but it was not obvious to me where I should do that. I got stuck 
because I didn't find the API description for LabVIEWs script node and I 
can live with the bug for a while.
 
Please notify if you can't get it to work using the recipe above or if you 
dig further into the C code or get rid of the bug somehow.
 
Best wishes,
Joakim
 

From: lab...@li... 
[mailto:lab...@li...] On Behalf Of I Phillips
Sent: den 7 december 2005 12:12
To: lab...@li...
Subject: [LabPython-Users] Hello


Hi everybody, 

Anybody currently using LabPython ? 

I have been using Labview for years, and have just started writing scripts 
in Python, so I thought now was a good time to integrate the two. 

Any examples/tips/known issues would be welcome. 

Thanks in advance 

Ian

I Phillips wrote:

>I have tracked down the bug to Python 2.3.5. 
>i.e. if you install any version upto and including Python 2.3.4, then the bug isn't present. 
>
>The big thing that sticks out in the python release between v.2.3.4 and v2.3.5 is a
>security patch (http://www.python.org/security/PSF-2005-001/). 
>"Note that these patches disable recursive traversal." 
>
>I am not an expert in python or programming, but think that this may be worth investigating. 
>
>Are any of the original developers still subscribed to this user group?
>Would you see this as a possible issue? 

I'm still subscribed and the main original developer but my time is limited and labpython
is not at the top of my priority list.

I will take a look at the mentioned patch when I have some time and see if that might be
the problem. I'm not specifically aware that I used something called recursive traversal.
Instead I suspect something strange going on with the Python thread protection or session
management. Above mentioned patch might have some indirect influence on these things though.

>A second bug I have found, is that if the python input("Please enter your name")
>command is used, and executed using the Labpython Execute script.vi then Labview crashes. 

This might be a hard one to fix. I suspect some issues with standard IO clashes as python
is really called as a client inside the LabVIEW process and as such as no default standard
IO anymore. Maybe that one could provide some standard IO redirections going to dialog
boxes or such but that seems like a huge hassle.

Rolf Kalbermatter

Hello Ian and Rolf,

Good to hear from you Rolf and thanks for a nice open-source package! It
would be great if you could find sime time to have a look at the Python
2.3.5 problem.=20

Downgrading Python from 2.4.1 to 2.3.4 was a good workaround for me,
LabVIEW doesn't hang anymore when I close my script VIs. Thanks Ian for
the investigation!

The input() problem can actually be fixed: If the input is known before
execution or can be supplied through an external file, try redirecting
sys.stdin for example like this:

Test with stdin =3D "1\n" (supplied as a LabVIEW string).
--- script ---
try:
    sys
except:
    import sys
    from StringIO import StringIO
    version =3D sys.version

sys.stdin =3D StringIO ("".join (stdin)) # StringIO wants ASCII, LabVIEW
has UNICODE
sys.stdout =3D StringIO ()
sys.stderr =3D StringIO ()

print "Hi there!"
try:
    x =3D input ("Wazzup?")
except:
    sys.stderr.write ("Invalid input")

stdout =3D sys.stdout.getvalue ()
stderr =3D sys.stderr.getvalue ()

sys.stdin =3D sys.__stdin__
sys.stdout =3D sys.__stdout__
sys.stderr =3D sys.__stderr__
--- end script ---
Result: x =3D 1

Adding to a wishlist for labpython: A Variant data type in the pop-up
menu (on script node variables and the polymorphic "Python Set/Get data"
VI). Would be really great to have! Is this feasible Rolf?

Best regards,
Joakim

-----Original Message-----
From: lab...@li...
[mailto:lab...@li...] On Behalf Of Rolf
Kalbermatter
Sent: den 16 december 2005 20:24
To: lab...@li...
Subject: RE: [LabPython-Users] Hello

I Phillips wrote:

>I have tracked down the bug to Python 2.3.5.=20
>i.e. if you install any version upto and including Python 2.3.4, then
the bug isn't present.=20
>
>The big thing that sticks out in the python release between v.2.3.4 and

>v2.3.5 is a security patch
(http://www.python.org/security/PSF-2005-001/).
>"Note that these patches disable recursive traversal."=20
>
>I am not an expert in python or programming, but think that this may be
worth investigating.=20
>
>Are any of the original developers still subscribed to this user group?
>Would you see this as a possible issue?=20

I'm still subscribed and the main original developer but my time is
limited and labpython is not at the top of my priority list.

I will take a look at the mentioned patch when I have some time and see
if that might be the problem. I'm not specifically aware that I used
something called recursive traversal.
Instead I suspect something strange going on with the Python thread
protection or session management. Above mentioned patch might have some
indirect influence on these things though.

>A second bug I have found, is that if the python input("Please enter=20
>your name") command is used, and executed using the Labpython Execute
script.vi then Labview crashes.

This might be a hard one to fix. I suspect some issues with standard IO
clashes as python is really called as a client inside the LabVIEW
process and as such as no default standard IO anymore. Maybe that one
could provide some standard IO redirections going to dialog boxes or
such but that seems like a huge hassle.

Rolf Kalbermatter



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files for problems?  Stop!  Download the new AJAX search engine that
makes searching your log files as easy as surfing the  web.  DOWNLOAD
SPLUNK!
http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
_______________________________________________
LabPython-Users mailing list
Lab...@li...
https://lists.sourceforge.net/lists/listinfo/labpython-users

Hello Joakim,

>Good to hear from you Rolf and thanks for a nice open-source package! It
>could be great if you could find sime time to have a look at the Python
>2.3.5 problem. 

I will see what I can do. If it is where I'm thinking it is, then it is
a real bitch to fix. The threading protection API in Python is a little
obscure and sort of misnamed as well. It is more about a context than
real threading and I remember having fiddled quite a lot with that part
back when I did develop the labpython interface and while I tried to apply
a logical approach, it finally came down to some trial and error too.

Chances are that there is no good solution which works both for pre 2.3.5
and later.

>sys.stdin = StringIO ("".join (stdin)) # StringIO wants ASCII, LabVIEW
>has UNICODE

This sounds wrong. I'm positive that any string parameters LabVIEW passes
to a script are in ASCII. LabVIEW positively does not support nor use
UNICODE at all but uses internally multi-byte strings for it's user
interface when necessary while the strings in your diagram are always ASCII.

>Adding to a wishlist for labpython: A Variant data type in the pop-up
>menu (on script node variables and the polymorphic "Python Set/Get data"
>VI). Would be really great to have! Is this feasible Rolf?

No! The variant datatype as used in LabVIEW is not documented, nor are any
of the LabVIEW manager functions needed to deal with this datatype. It is
positively not directly compatible with a Windows OLE variant and my drive
for reverse engineering such an obscure datatype is close to 0.

Rolf Kalbermatter

Hi Rolf,

>Chances are that there is no good solution which works both for pre
2.3.5 and later.

Sounds like you are approaching the source already! Hope it affects only
pyimport.c?

>>sys.stdin =3D StringIO ("".join (stdin)) # StringIO wants ASCII, =
LabVIEW
has UNICODE
>This sounds wrong. I'm positive that any string parameters LabVIEW
passes to a script are in
>ASCII. ...

Thanks for the correction, "sys.stdin =3D StringIO (stdin)" works!
(Something spooked me yesterday.)

>No! The variant datatype as used in LabVIEW is not documented, nor are
any of the LabVIEW manager >functions needed to deal with this datatype.
It is positively not directly compatible with a=20
>Windows OLE variant and my drive for reverse engineering such an
obscure datatype is close to 0.

I see.=20
Would you like to point me to where I can find docs about the LabVIEW
API for script nodes? I would like to have types for waveform plots and
xy plots. I have problems generating those types when calling LabVIEW
VIs from Python through win32com because that module doesn't distinguish
between tuples (clusters) and lists (arrays). I guess that module uses
OLE variants.

/Joakim

Hi Joakim,
> 
> >Chances are that there is no good solution which works both for pre
> 2.3.5 and later.
> 
> Sounds like you are approaching the source already! Hope it 
> affects only pyimport.c?

Nope it is more likely affecting lvpython.c and in there PyCloseHost and there
again the use of PyEval_.. functions as well as probably PyThreadState_Swap().
It is definitely in there where LabVIEW hangs indirectly when trying to unload
the script DLL.

> >No! The variant datatype as used in LabVIEW is not documented, nor are
> >any of the LabVIEW manager >functions needed to deal with this datatype.
> >It is positively not directly compatible with a Windows OLE variant and
> >my drive for reverse engineering such an obscure datatype is close to 0.
> 
> I see. 
> Would you like to point me to where I can find docs about the LabVIEW
> API for script nodes? I would like to have types for waveform plots and
> xy plots. I have problems generating those types when calling LabVIEW
> VIs from Python through win32com because that module doesn't distinguish
> between tuples (clusters) and lists (arrays). I guess that module uses
> OLE variants.

I'm not aware of official documentation for the script node API. Basically
I did start out to reverse engineer that API and then Jim Kring managed to
get in touch with a LabVIEW developer who was willing to give us the header
file defining that API as used in LabVIEW 6.0. As far as that is concerned
it basically just confirmed most of the things I had already found out and
it was more or less what is now in lvpython.h except some of the comments
in there which I had added myself before, based on my own findings.
I'm sure the script node in current LabVIEW version has some more features
added but that is of little importance for labpython up to this moment.

If you interface LabVIEW through win32com then you interface through COM
(which was called OLE and now listens to the name of ActiveX) and as such
you will eveidently see OLE variants. Waveforms are basically LabVIEW variants
but LabVIEW takes care of  converting from its own variants to OLE variants
when you interface the ActiveX interface of LabVIEW.

Rolf Kalbermatter

Hi Rolf, Joakim,

I was wondering if you could help with the following problem.
I have a class that redirects the print statement to a Tkinter window, see 
below.
The test script (testprint.py) works fine under a python shell.

However, when I try to run the same script in LabPython, I get the 
following error:
        "exceptions.AttributeError, 'module' object has no attribute 
'argv'" (Script fails at "root=Tk()" statement)

Am I doing something silly? or can't LabPython open any GUI windows?
(NOTE: I typically use PYTHON set script.vi and PYTHON Execute script.vi.)

Your thoughts
Thanks for your help

Ian

---------------------------------------
##filename = testprint.py
from Tkinter import *
from printtogui import *


root = Tk()
text = Tktextfile(root)
logger = Logger(text)
for i in range(6):
    print "%d, " %i
-----------------------------------------
## filename = printtogui.py

"""A short python script for re-directing print statement."""

import os, os.path, tkFileDialog
from Tkinter import *
 
class Logger:
    """A filelike object that prints its input on the screen."""
 
    def __init__(self, logfile=None):
        """Takes one argument, a file like object for logging."""
        print 'Starting logger...'
        if not logfile:
            self.logfile = open('relative-refs.log','w')
        else:
            self.logfile = logfile
        sys.stderr = self                 # Super cheap logging 
facility...
        sys.stdout = self                 # Just redirect output to a 
file.
        print 'Logger running...'
 
    def write(self, line):
        sys.__stdout__.write(line)
        self.logfile.write(line)
 
    def close(self):
        """The close method restores stdout and stderr to normal."""
        self.logfile.close()
        sys.stderr = sys.__stderr__
        sys.stdout = sys.__stdout__

class Tktextfile:
    """A file like interface to the Tk text widget."""
 
    def __init__(self, root):
        """Create a scrollable text widget to be written to."""
        self.root = root
        self.text = Text(root,width=40,height=20)
        self.text.pack(side=LEFT, expand=True, fill=BOTH)
        scrollbar = Scrollbar(root)
        scrollbar.pack(side=RIGHT,fill=Y)
        self.text.configure(yscrollcommand=scrollbar.set)
        scrollbar.config(command=self.text.yview)
        self.text.focus()
 
    def write(self, line):
        """Write method for file like widget."""
        self.text.insert(INSERT, line)
        self.text.see(END)
 
    def close(self):
        """Fake close method."""
        pass
-------------------------------------------------




"Rolf Kalbermatter" <rol...@ci...>
Sent by: lab...@li...
21/12/2005 00:23
Please respond to labpython-users

 
        To:     <lab...@li...>
        cc: 
        Subject:        RE: [LabPython-Users] Hello


Hi Joakim,
> 
> >Chances are that there is no good solution which works both for pre
> 2.3.5 and later.
> 
> Sounds like you are approaching the source already! Hope it 
> affects only pyimport.c?

Nope it is more likely affecting lvpython.c and in there PyCloseHost and 
there
again the use of PyEval_.. functions as well as probably 
PyThreadState_Swap().
It is definitely in there where LabVIEW hangs indirectly when trying to 
unload
the script DLL.

> >No! The variant datatype as used in LabVIEW is not documented, nor are
> >any of the LabVIEW manager >functions needed to deal with this 
datatype.
> >It is positively not directly compatible with a Windows OLE variant and
> >my drive for reverse engineering such an obscure datatype is close to 
0.
> 
> I see. 
> Would you like to point me to where I can find docs about the LabVIEW
> API for script nodes? I would like to have types for waveform plots and
> xy plots. I have problems generating those types when calling LabVIEW
> VIs from Python through win32com because that module doesn't distinguish
> between tuples (clusters) and lists (arrays). I guess that module uses
> OLE variants.

I'm not aware of official documentation for the script node API. Basically
I did start out to reverse engineer that API and then Jim Kring managed to
get in touch with a LabVIEW developer who was willing to give us the 
header
file defining that API as used in LabVIEW 6.0. As far as that is concerned
it basically just confirmed most of the things I had already found out and
it was more or less what is now in lvpython.h except some of the comments
in there which I had added myself before, based on my own findings.
I'm sure the script node in current LabVIEW version has some more features
added but that is of little importance for labpython up to this moment.

If you interface LabVIEW through win32com then you interface through COM
(which was called OLE and now listens to the name of ActiveX) and as such
you will eveidently see OLE variants. Waveforms are basically LabVIEW 
variants
but LabVIEW takes care of  converting from its own variants to OLE 
variants
when you interface the ActiveX interface of LabVIEW.

Rolf Kalbermatter



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
LabPython-Users mailing list
Lab...@li...
https://lists.sourceforge.net/lists/listinfo/labpython-users