Re: [LabPython-Users] Problems running the Labpython scripting node

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

Hi Mirko
 
> First I hope that this mailing list is still active.

Yes it is! :-) Although no real activity.
 
>I installed the labpython package with OpenG and have the problem that
Labview can not
>start the scripting server: "Error1046: LabVIEW cannot initialize the
script server.  Ensure
>the server software is installed." I'm using Labview 8.2 and Python 2.5
inside of an PyGTK
>installation. Path Variables are set to the Python directory.
>
>Do I need another (or older?) Python installation? Do you have somewhere
some instructions
>how to install the Labpython scripting node properly? 
 
You don't mention what version of the LabPython package you downloaded.
 
The currently released LabPython package 1.1 on source forge is compiled for
Python 2.2 if I'm not mistaken. I have tried it with 2.4 at some point but
not really made any tests. The dependency on a specific Python sub version
is something that is dictated by the Pyton policy of naming each Python DLL
according to its version. This is also so because Python reserves the right
to introduce binary incompatiblities between versions.
 
Also testing for LapPython has been really only done for LabVIEW 6.0 and
6.1. So there is a potential problem that the scripting node API interface
might have changed at some point in LabVIEW. The information used to create
LabPython is from an NI source but not an official documentation and
therefore NI reserves the right to make changes to this whenever they like.
 
LabPython has a (rather complicated mechanisme) to link dynamically to the
Python server DLL. But without setting the actual Python DLL path with the
function PYTHON Set Server Path.vi to point to the actual new Python DLL it
will try to load the default Python DLL which is python22.dll. And since it
does not know about the entire path this DLL also has to be in the DLL
search path (eg. Windows, or System directory or a directory specified in
the PATH environment variable). Also pointing this path to anything but a
real Python DLL will also cause the labpython DLL to return an error to
LabVIEW.
 
Fixing this should at least get rid of the server not found error but won't
guarantee that it will work with newer Python versions due to possible
binary incompatibilities with the called Python APIs.
 
That said I have done a little work on LabPython at the end of last year,
integrating a few fixes and improvements and also updating LabPython to link
to the Python 2.5 library instead. However no serious testing has been done
and consequently no package has been build so far. Also due to some
workarounds necessary the whole is now split into two DLLs that do work
together to allow using the LabVIEW VI API and the script node at the same
time in the same LabVIEW program without crashing. But as said no serious
testing yet however and no packages either.
 
You can however get the actual C source with these changes from the
sourceforge servers in the LapPython project.
Rolf Kalbermatter