Gombo

2roflk: I'm sorry for suggesting that the error was deliberate, please accept my apologies. I was a bit bugged because I am unfamiliar with cintools and it took me a while figuring out the problem (which was most probably caused by a change in cintools API) and I took a wrong way a phrase from README about why would you bother compiling the code. Sorry again. Th problem is caused by line 105 in lvsapi.h. It reads PrivateP(lvsnInstance); but should be NIPrivatePtr(lvsnInstance); for my LabView 2012 version of cintools. May be you can correct it and, by the way, may I suggest changing default python version to 2.7? Anyway, thank you for your work, it is a great help.

OK, things turned out to be even stranger. The real perpetrator turned out to be "PYTHON Set Server Path.vi". It attempts to restart server and, evidently, that messes things up somehow. If it is not used (it is really have to be run once per installation to write the path into config), then even with "PYTHON Close Session.vi" subsequent runs go fine and you can have concurrent session with numpy (at least, with "import numpy" - I have not tested any further). The memory leak persists, though, so single interpreter setup is probably recommended. It would be nice to update default Python version from 2.4 to 2.7, I think.

Well, approach suggested above didn't work. I have no idea why, but python dlls still did not unload (I called PyCloseHost() function from lvpython.c, which includes Py_Finalize()) and second run would not work. The only improvement was that instead of hanging up the second attempt caused an exception, which was handled by Labview, but I still needed to close it after each run. Anyway, I found a workaround, which suits me: it turned out that it is generally OK to leave out call to "PYTHON Close Session.vi". You can reconnect to the same interpreter on the second run using state machine like this: (you get all your variables back), or even simply create a New Session each time, but that would lead to a memory leak. (BTW, it turned out that the source would not compile because of a typo, so simple but difficult to locate for a person unfamiliar with LabView develoment that it seems to be deliberate. )

Thank you for prompt response, it got me started. I've peeked into labpython code and, sure, you get your bet - Py_NewInterpreter() calls are there. Labpython seems to be specifically designed to allow several concurrent sessions (interpreters). On the other hand, "PYTHON Close Session.vi" does call Py_EndInterpreter(), so on the surface of things there should be no old interpreter in the second run. Moreover, Labview should clean things up when the VI is unloaded from memory, shouldn't it? Anyway, I'm going to try to make a call to Py_Finalize() at the end of the vi run. Would it help, what do you think?

I was requested to provide Labview bindings for an app written in mostly in python and I've found LabPython tobe a blessing. However, I run into a nasty problem and I can't really figure who is to blame. In a nutshell: LabPython does not unload python server dll and dll of imported modules (python27.dll and *.pyd) after "PYTHON Close Session.vi" have been executed and VI stopped . For most cases it causes no problem, but numpy module causes LabView to hang when "import numpy" is executed on the second run. I'll greatly appreciate any help with the matter, because I can't even tell who is to blame - labpython, numpy, or LabView In details: 1. Here is a test case 2. When the VI is loaded into memory, only labpython.dll have been loaded - OK. 3. When the VI have been run the python27.dll and a lot of numpy-related dll's are loaded and remain in memory when the VI stops. 4. If I quit the VI, labpython.dll is unloaded, but all other dll's remains - this definitely seems to be wrong. 5. The second run generates an error and hangs on closing Some handles are open at this moment: 6. If I do not quit the VI before second run (skip step 4), there is no error and it hangs on the first labpython VI after "import numpy" execution. I tested this behavior with 1) Labview 2012, labpython 4.0.0.4, python 2.7, numpy 1.7.1 and 1.6.1 2) Labview 2012, labpython 4.0.0.4, python 2.4, numpy 1.4.1 3) Labview 8.5, labpython 1.2, python 2.7, numpy 1.6.1 Test VI is attached to the post. test.vi