Mailman 3 January 2013 - Python.NET

Problem to use a dll: System.ApplicationException: Error 1: OpenDevice: Invalid handle
by Daniel Krause 16 Jan '13

16 Jan '13

I am trying to use a dll to control a camera. It is possible for me to use the dll with ironpython, but I fail to use it with python for .NET (CLR 4.0). (And I would like to use e.g. numpy as well, so I need python for .NET). Below follow a short test script, the python / ironpython versions and their console output when running the test script. Any hints are welcome. Thank you Daniel ######################################################## #test script "testcam.py" #1 for python for .NET import clr import sys sys.path.append("C:\\Users\\mdk\\workspace\\camera\\") clr.AddReference("xiAPI40.NET") from xiApi.NET import * cam = xiCam() cam.OpenDevice(0) print cam.GetParamString(PRM.DEVICE_NAME) #print device name ############### #console output showing the python version, #installed is .NET-support with pythonnet-2.0dev.clr4.0.win-amd64-py2.7.exe on Win7 64bit PS C:\Users\mdk\workspace\camera> python.exe Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. ############### #running test script #1 with python, console output Traceback (most recent call last): File "C:\Users\mdk\workspace\camera\testcam.py", line 8, in <module> cam.OpenDevice(0) System.ApplicationException: Error 1: OpenDevice: Invalid handle at xiApi.NET.xiCam.throwException(Int32 errNum, String param) at xiApi.NET.xiCam.OpenDevice(Int32 DevID) ###################################################### #test script "testcam.py" #1 modified for ironpython, test script #2 import clr import sys sys.path.append("C:\\Users\\mdk\\camera\\") clr.AddReference("xiAPI40.NET.dll") from xiApi.NET import * cam = xiCam() cam.OpenDevice(0) print cam.GetParamString(PRM.DEVICE_NAME) #print device name ############### #console output showing the ironpython version PS C:\Users\mdk\workspace\camera> ipy.exe IronPython 2.7 (2.7.0.40) on .NET 4.0.30319.17929 Type "help", "copyright", "credits" or "license" for more information. >>> ############## #running test script #2 with ironpython, console output MQ013MG-E2

2 1

success… pythonnet running in maya on osx64bit
by brad＠fie.us 13 Jan '13

13 Jan '13

success… pythonnet running in maya on osx64bit It took a good amount of hacking. But it does work. I'm going to work on wrapping all my changes and fixes into a patch or two. However, some general notes: You need to build your own mono in 64 bit mode, because they don't ship a precompiled 64bit mono for OSX currently. I found it easiest to make a custom Portfile for macports, to do this. Basic instructions can be found on the mono project's website. pythonnet desperately needs a configure script. Most of what I've been doing is ripping out a lot of pkg-config stuff that is making assumptions about python and mono locations. Apparently, someone put a whole bunch of hard-coded ubuntu paths in there. Once I've finished doing that, I can actually do what I need to do. Which is tell the build system where my 64bit mono is, and which python to use. in my case that's: export PKG_CONFIG_PATH=/path/to/my/mono/pkgconfig make PYTHON=/Applications/Autodesk/maya2013/Maya.app/Contents/bin/mayapy The makefiles themselves should not be finding mono-2 and glib-2.0. They should assume them to be available to pkg-config already. Finding them is something for a configure script. And I'd argue it probably should set the python as well. I had to hack up Python.Runtime.dll.config and tell it to "link" to "maya" rather than some form of "python26." Python is statically linked into maya, as it is with a lot of 3rd party embedded python implementations. The symbols it wants to link to, are in the maya binary, not a shared library. So from a build system point of view, I'm thinking the two big takeaways are: it REALLY needs a configure script. Python.Runtime.dll.config probably needs to be generated as part of the build process and listen to the configure script as to where to point itself. If I know where to point it to, during the build, I should be able to configure that as part of the build process. Anyhow. Those are my thoughts. I'll try and send off some patches once I do some cleaning up. -brad

2 2

unsubscribe
by Link, Hamilton 02 Jan '13

02 Jan '13

1 0