Scheduling a Python script or model to run at a prescribed time

At the Spatial Analysis and Geoprocessing island at this year’s user conference, several folks asked us about running a Python script or ModelBuilder model at a prescribed time — usually in the early morning when their computers are bored and just waiting for something to do. We thought it would be good to make a post about this and to share some tips.

The first place to start is with the help topic Scheduling a Python script to run at prescribed times. This topic is kind of buried in the help system so it’s easy to miss. The meat of this topic shows you how to launch Window’s Task Scheduler on various operating systems (Windows 7, XP, and so on). The screenshot below shows the Task Scheduler on Windows 7. There’s a lot stuff you can do with the task scheduler and you’ll just have to play around with it and read the Windows help. The Actions pane, on the right, has the Create Basic Task action, and this is the place to start.

Clicking on Create Basic Task opens a wizard where you define the name of your task, the trigger (when it runs), and the action (what program to run). The screenshot below shows the Action tab where you specify the name of your Python script to run as well as any arguments to the script.

The Action tab is where we have a few tips, as follows.

Run the Python executable with arguments

To ensure that your Python script will run regardless of the login account that the schedule task uses, and to avoid any confusion about which version of Python is used in mixed environments (64bit or 32bit), we recommend that you run the Python executable with the name of your Python file as an argument to the executable.

Suppose the script you want to run is E:\My script.py. Instead of running the script directly, instruct the task scheduler to run python.exe with the script as an argument. For example:

C:\Python27\ArcGIS10.2\python.exe "E:\My script.py"

The location of python.exe depends on your install. If you don’t know where it is, you can discover its location; copy and paste the following code into a new Python script then execute the script. The script will print the location of python.exe as well as other information about your Python environment.

import sys
import platform
import imp

print("Python EXE     : " + sys.executable)
print("Architecture   : " + platform.architecture()[0])
print("Path to arcpy  : " + imp.find_module("arcpy")[1])

raw_input("\n\nPress ENTER to quit")

After determining the location of python.exe, this is what is entered in the Action panel of the task scheduler:

If there are additional arguments (parameters) to your script, provide them after the path to your script. For example, the following command line executes a Python script that takes two arguments; the path to a feature class and an integer.

C:\Python27\ArcGIS10.2\python.exe "E:\My Scripts\DoConversion.py" c:\gisWork\gdb.mdb\counties 10

We typically recommend writing scripts so that they take arguments like the above example rather the hard-coding dataset paths or values within the script. However, this is one case where hard-coding paths and values in your script works to your advantage; rather than changing argument values in the task scheduler, it’s easier to just edit your script to use different paths or values.

If you’re familiar with .bat files in Windows, you can have the task scheduler run a .bat file that in turn runs your script with arguments. The contents of the .bat is the single command line shown above.

Remember that if any of your arguments contain spaces, you need to enclose the argument in double quotes. In the above example, E:\My Scripts\DoConversion.py contains a space, so double quotes are required.

Running models at a prescribed time

A common misconception is that in order to run a model as a Python script, you must first export the model to a Python script. Geoprocessing is designed so that models are tools, just like all the tools delivered with the ArcGIS.  That means you can run your model within Python just like any other geoprocessing tool.  All you need to do is import the toolbox containing your model using the ImportToolbox function, then run your model within Python.

For example, the model to the left imports a .gpx file to a geodatabase, adds a field, calculates it to the current date and time, then appends all those features into a “master” feature class.

To run this model on a schedule, all that’s needed is to execute the model within a script. Here’s the Python script to run the model:

import arcpy
import os
from datetime import datetime

# Import the toolbox containing the model.  This toolbox
#  has an alias of "gpxtools"
#
arcpy.ImportToolbox(r"c:\importgpx\myGPXstuff.tbx")

# Run the model.  The model has two parameters, the input
#  .gpx file and the feature class to update
#
arcpy.ImportGPX_gpxtools(r"c:\ftp\inbox\datadrop.gpx",
                         r"c:\ftp\server.sde\gpx_tracks")

# Now that the input gpx file has been processed, rename it
#   to have the date and time.
#
os.rename(r"c:\ftp\inbox\datadrop.gpx",
          r"c:\ftp\inbox\datadrop{}.gpx".format(datetime.strftime(datetime.now(), "%Y%m%d"))

Advanced options

The Create Basic Task wizard allows you to set basic properties of the task. Once the task is created, you can examine its properties and refine its triggers and actions. For example, you can have your task run every five minutes for three hours. You can set up a task with advanced options using the Create Task action.

Start simple

When I started writing this blog, it had been a long time since I messed around with scheduled tasks, so I started with a simple script that wrote information to a log file. I scheduled it to run every minute for ten minutes so I could test changes to the script soon after I made them. It was a great way to test and understand how scheduling worked before committing to running the “real” script. Here’s my simple script:

import sys
import platform
import imp
print "Importing arcpy... this may take a moment\n"
import arcpy

# Open a log file to write to
#
f = open(r'E:\schedule.log','w')

# Write date/time
#
f.write(time.strftime('%x %X'))
f.write('\n')

# Test receiving of arguments/parameters via arcpy
#
f.write("Parameter 0 : " + arcpy.GetParameterAsText(0) + "\n")

# Python info
#
f.write("Python EXE : " + sys.executable + "\n")
f.write("Architecture : " + platform.architecture()[0] + "\n")
f.write("Path to arcpy : " + imp.find_module("arcpy")[1] + "\n")
f.close()

Ghislain Prince contributed to this post

This entry was posted in Analysis & Geoprocessing, Python and tagged , , , , , , , , . Bookmark the permalink.

Leave a Reply

12 Comments

  1. cmlosaria_gis says:

    cool post!

  2. mvalderrama says:

    Thanks, very good explanation.

  3. raj_philly says:

    Thank you for the blog! This is really helpful. You might want to end the f.close() at the end so the text is saved before closing.

  4. Dale Honeycutt says:

    Below is a link to a forum post that describes and solves a data access problem in a scheduled task. If your scheduled task is having data access problems (that is, it can’t find the datasets it needs), have a look at the post. It has to do with mapping external drives to a drive letter (for example, “Y:” is mapped to “//somemachine/gis_data“)

    Here’s the link: Windows Scheduler Python issue

  5. alexroma says:

    In mid-July 2013 I created a script “C:\Python27\ArcGIS10.1\python.exe ……..” that worked perfectly fine and I left it alone to work silently in the background. In mid-August I noticed that I was missing a bunch of results during the last two weeks. After a long search I realized that ArcGIS 10.2, that I installed during that period, caused the issue. I totally forgot to update the “10.1″ line to “10.2″ in that script. Beware!

    • Dale Honeycutt says:

      Great point. That’s one advantage to running the script directly (instead of “C:\Python27\… C:\mystuff\myscript”, just “C:\mystuff\myscript” — you’re not dependent on the location of Python. But then again, when Python doesn’t start for whatever reason, the fallback is to run Python (“C:\Python27\…”). It’s a trade-off.

  6. ghopkins says:

    Hi Dale,
    Thanks for your post! I’m struggling to get this to work though. My script will work if I run it from Python Win (only after right clicking and running as Administrator… I’m running it on Windows Server 2008) but when I try to run it from Task Scheduler it just doesn’t work. It says it runs successfully but it’s clearly not working (I’ve told it to run this task as the local Administrator). I’ve tried running the script directly and by your suggestion about to run python.exe and then run the script as an argument. Do you have any ideas as to what I’m doing wrong?

    Thanks,
    Grant

    • Dale Honeycutt says:

      Grant:
      So sorry — I just discovered your comment. Did you find a solution to this? The first thing that comes to mind is that it’s a login/permissions thing, but it’s really hard to tell what’s going on from afar. The only suggestion I have is to put copious print statements in your code to find out exactly where it’s failing.

      • ninabean says:

        I’m having the same problem. It’s just a basic “open text file and write to it” script. It runs fine from PythonWin. But from Task Scheduler it says it ran successfully but no text file gets created. If I run it using Python.exe as the program and the script as the argument, the Windows command prompt runs quickly and I see the word “error” but it goes so fast I can’t see what it says. Then if I run it just using the .py file as the program to run, all it does is open PythonWin.