1

In an attempt to render an interactive window via matplotlib I am using an out of process script in a toolbox. If I debug the script, it is possible to step through and render the window as expected. Running it through ArcMap (not in debug mode) causes a 000714 error.

  1. Arc10.2
  2. Running the script out of process
  3. Tested with background processing on and off (Geoprocessing Options)
  4. pythonExe is being properly found

Any thoughts?

import multiprocessing
import sys, os
import arcpy

import matplotlib.pyplot as plt

def show_form():
    fig = plt.figure()
    x = range(10)
    y = range(10)
    plt.plot(x,y)
    plt.show()

def main():
    pythonExe = os.path.join(sys.exec_prefix, 'python.exe')
    multiprocessing.set_executable(pythonExe)
    multiprocessing.freeze_support = True
    jobs = []
    pool = multiprocessing.Pool(1)
    jobs.append(pool.apply_async(show_form,[]))
    pool.close()
    pool.join()
    del pool
    del jobs
    arcpy.SetParameterAsText(0, True)       

if __name__ == "__main__":
    main()

Update 1

As per Luke's comment, I tested cmd.exe /C test.py. Other than the long import time for arcpy the script executed as expected with the Tk plot window appearing.

Update 2

By opening a command window and quickly snapping a screen capture, I can grab an error from the script before it dies. This looks like an issue loading the libraries (32 vs. 64bit?)

enter image description here

Update 3

Arcmap is using the 64bit python by default when running out of process. The next step is to figure out how to disable this, as it appears to be causing a Tk issue as @Luke suggested.

  • This might have changed in 10.2, but have you checked the licensing? I know older versions of Arc have the licensing set up so that multiprocessing isn't allowed by the license. Does it work when you don't thread? – Jezibelle Jul 27 '14 at 20:19
  • @Jezibelle - where did you get that info. I've been using multiprocessing since 10.0. Note that the multiprocessing module was only introduced in python 2.6, which has nothing to do with ArcGIS licensing. – user2856 Jul 28 '14 at 1:56
  • @Jay - Have you been installing new python versions? I'm running ArcGIS 10.1. I had previously upgraded python 2.7.2 to 2.7.8 for both 32bit and then 64bit python and I got the same error. When I ran the same command Arc* uses to call the script (cmd.exe /C C:\TEMP\TEST.PY), it showed that the 64bit python was getting picked up, and that there was a Tk version conflict with my upgraded python. Reinstalling 32bit python (still 2.7.8) over the top to reset it as the default python got your script working for me (in 10.1). – user2856 Jul 28 '14 at 2:07
  • @Luke Was the reinstallation of the 32-bit Python via a python installer or an Arc installer? I will give a reinstall a try. The only change I made to Arc's python was the installation of SciPy, but perhaps that has caused some issue. – Jay Laura Jul 28 '14 at 14:32
  • 1
    @Luke Sounds good. I think what is happening: User installs 64-bit python (via ESRI geoprocessing or otherwise). Windows is setting .py files to open using the more recent installation of python. When background geoprocessing occurs, Arc* is opening the most recent python. So, a repair fixes the issue. So does changing the 'open with' property of the .py file. – Jay Laura Jul 28 '14 at 19:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.