Python may already be installed.
For Windows, Python can be downloaded from here
https://www.python.org/downloads/windows/. Typically the best one is Python 3 in Stable Releases
and is 64-bit.
For Ubuntu, Python 3 is typically already installed.
Ubuntu requires the "python3" command to run the software.
If you don't have it, it can be installed from
www.python.org.
The first demonstration programs do not require installing packages.
Using Jupyter does not require installing packages.
Install pip using instructions here
https://pip.pypa.io/en/stable/installing/
For Ubuntu, open a terminal and run:
$ pip3 install python3-pygame
Or
$ sudo apt-get install python3-pygame
Or follow the instructions here:
www.pygame.org/wiki/GettingStarted
This is only required for programs in the image-proc folder.
For Ubuntu, open a terminal and run:
$ pip3 install python3-opencv
Or
$ sudo apt-get install python3-opencv
Or follow the instructions here:
https://docs.opencv.org/master/d2/de6/tutorial_py_setup_in_ubuntu.html
Or here:
https://docs.opencv.org/master/d5/de5/tutorial_py_setup_in_windows.html
For Ubuntu:
- Click on the "Files" icon (File Folder Viewer) on the left side of the screen.
Or run Activities and enter "Nautilus".
- Click on folders in the "explorer"
- Once the correct folder is selected, then right click with the mouse and
select, "Open in Terminal"
- Then the prompt is displayed. If there are instructions such as, "$ ls *",
the "$" part should not be entered since it is indicating the prompt that
is displayed.
There are many ways to run the Python demo programs.
Python program can be run from the Idle program.
Python programs can be run from a terminal.
First open a terminal, and then
enter the text required to run the program. In the Demos
documentation, the text to run is shown.
Another way is to right click on the file that you would like to edit and run,
then select "Open With Other Application", then select "Idle". Then select "Run/Run Module" or the key F5.
The demo programs can also be run from Jupyter.
Editing Python programs can be done with any text editor. The default
Python editor is "Idle" and has colored text so that it is easier to
read.
For Ubuntu:
- Right click on a .py file.
- Select "Open with Other Application"
- Select "Idle"
The menu Run/Run Module will run the program. The Python Shell may not show anything,
but most demos will show a new window somewhere on the screen.
Often searching on the internet will help to find out how
to solve a problem. Other types of problems require
debugging.
It is possible to debug Python programs by inserting statements
into the program. Some examples are:
| Statement | Description |
| print('1') | This will print a "1" to the terminal when the print
statement is run. |
| print(object) | This will print the content values of an object or variable |
| print(dir(object)) | This will print the methods or members of an object or variable |
| print(type(object)) | This will print the type of an object or variable |
| print('place1', str(obj)) | This will print 'place1' and information about an object. |
There are some Python editors that allow debugging. Search the internet
for "Python IDE" to find different editors.
An image can be saved of the current screen or window.
For Ubuntu:
- Click on the "Activities" menu.
- Enter "Screenshot" in the "Type to Search" box.
- Click "Take Screenshot"
A movie can be saved of the activities during some animation, or selections on the screen.
For Ubuntu:
- Click on the "Activities" menu.
- Enter "Screenshot" in the "Type to Search" box.
- Enter a delay of a few seconds.
- Press Ctrl-Alt-Shift-R to start recording.
- Run your program.
- Press Ctrl-Alt-Shift-R to stop recording.
- The output file is saved in home directory in the "Videos" folder.
Install "WinFF" using Synaptic or command line.
A video can also be edited in Gimp to change individual frames.
Cut and Crop
- Run WinFF
- Click the Options. This will show extra tabs in the screen.
- Use the Crop tab to indicate how many pixels to remove from each side.
- Use the Time tab to select when to start keeping the video and how much to keep.
- Use Preview to view the changes.
- Use Convert to save the file in the home directory.
It seems like both Crop and changing the video size don't work at the same time.
So load the already cropped video, and use the Video tab to set the output size.
Set Image Size
A complete example for the game/bug-data/Bug-Source/Bug.mp4 is:
- Video: Frame Rate=5, Video Size=100 X -1
- Time: Seek to=5, Time to Record=6
Extract Frames
To extract frames, first open a terminal, and then run:
/usr/bin/ffmpeg -i "/dir/game/bug-data/Bug.mp4" /dir/game/bug-data/Bug/frame_%03d.png
The dir in italics must be replaced with your actual folder.


schtasks create
Schedules a task.
Schtasks uses different parameter combinations for each schedule type. To see the combined syntax for creating tasks or to see the syntax for creating a task with a particular schedule type, click one of the following options.
Combined syntax and parameter descriptions
To schedule a task that runs every N minutes
To schedule a task that runs every N hours
To schedule a task that runs every N days
To schedule a task that runs every N weeks
To schedule a task that runs every N months
To schedule a task that runs on a specific day of the week
To schedule a task that runs on a specific week of the month
To schedule a task that runs on a specific date each month
To schedule a task that runs on a the last day of a month
To schedule a task that runs once
To schedule a task that runs every time the system starts
To schedule a task that runs when a user logs on
To schedule a task that runs when the system is idle
To schedule a task that runs now
To schedule a task that runs with different permissions
To schedule a task that runs with system permissions
To schedule a task that runs more than one program
To schedule a task that runs on a remote computer
Combined syntax and parameter descriptions
Syntax
Schtasks /create /sc ScheduleType /tn TaskName /tr TaskRun [/s Computer [/u [Domain**\]User [/p** Password]]] [/ru {[Domain**\]User | System}] [/rp** Password] [/mo Modifier] [/d Day[,Day...] | *] [/m Month[,Month...]] [/i IdleTime] [/st StartTime] [/ri Interval] [{/et EndTime | /du Duration} [/k]] [/sd StartDate] [/ed EndDate] [/it] [/Z] [/F]
Parameters
/sc ScheduleType
Specifies the schedule type. Valid values are MINUTE, HOURLY, DAILY, WEEKLY, MONTHLY, ONCE, ONSTART, ONLOGON, ONIDLE.
Copy

<colgroup>
<col style="width: 50%" />
<col style="width: 50%" />
</colgroup>

Schedule type
Description

MINUTE, HOURLY, DAILY, WEEKLY, MONTHLY

Specifies the time unit for the schedule.

ONCE

The task runs once at a specified date and time.

ONSTART

The task runs every time the system starts. You can specify a start date, or run the task the next time the system starts.

ONLOGON

The task runs whenever a user (any user) logs on. You can specify a date, or run the task the next time the user logs on.

ONIDLE

The task runs whenever the system is idle for a specified period of time. You can specify a date, or run the task the next time the system is idle.

/tn TaskName
Specifies a name for the task. Each task on the system must have a unique name. The name must conform to the rules for file names and must not exceed 238 characters. Use quotation marks to enclose names that include spaces.
/tr TaskRun
Specifies the program or command that the task runs. Type the fully qualified path and file name of an executable file, script file, or batch file. The path name must not exceed 262 characters. If you omit the path, Schtasks assumes that the file is in the Systemroot\System32 directory.
/s Computer
Schedules a task on the specified remote computer. Type the name or IP address of a remote computer (with or without backslashes). The default is the local computer. The /u and /p parameters are valid only when you use /s.
/u [Domain\]User
Runs this command with the permissions of the specified user account. The default is the permissions of the current user of the local computer. The /u and /p parameters are valid only for scheduling a task on a remote computer (/s).
Copy
The permissions of the specified account are used to schedule the task and to run the task. To run the task with the permissions of a different user, use the **/ru** parameter.
The user account must be a member of the Administrators group on the remote computer. Also, the local computer must be in the same domain as the remote computer, or must be in a domain that is trusted by the remote computer domain.
/p Password
provides the password for the user account specified in the /u parameter. If you use the /u parameter, but omit the /p parameter or the password argument, Schtasks prompts you for a password and obscures the text you type.
Copy
The **/u** and **/p** parameters are valid only for scheduling a task on a remote computer (**/s**).
/ru {[Domain\]User | System}
Runs the task with permissions of the specified user account. By default, the task runs with the permissions of the current user of the local computer, or with the permission of the user specified by the /u parameter, if one is included. The /ru parameter is valid when scheduling tasks on local or remote computers.
Copy

<colgroup>
<col style="width: 50%" />
<col style="width: 50%" />
</colgroup>

Value
Description

[Domain\]User

Specifies an alternate user account.

System or ""

Specifies the Local System account, a highly privileged account used by the operating system and system services.

/rp Password
provides the password for the user account that is specified in the /ru [Domain**\**]User parameter. If you omit this parameter when specifying a user account, SchTasks.exe prompts you for the password and obscures the text you type.
Copy
Do not use the **/rp** parameter for tasks run with permissions of the System account (**/ru System**). The system account does not have a password and SchTasks.exe does not prompt for one.
/mo Modifier
Specifies how often the task runs within its schedule type. This parameter is valid, but optional, for a MINUTE, HOURLY, DAILY, WEEKLY, and MONTHLY schedule. The default value is 1.
Copy

<colgroup>
<col style="width: 33%" />
<col style="width: 33%" />
<col style="width: 33%" />
</colgroup>

Schedule type
Modifier values
Description

MINUTE

1 - 1439

The task runs every N minutes.

HOURLY

1 - 23

The task runs every N hours.

DAILY

1 - 365

The task runs every N days.

WEEKLY

1 - 52

The task runs every N weeks.

ONCE

No modifiers.

The task runs once.

ONSTART

No modifiers.

The task runs at startup.

ONLOGON

No modifiers.

The task runs when the user specified by the /u parameter logs on.

ONIDLE

No modifiers.

The task runs after the system is idle for the number of minutes specified by the /i parameter, which is required for use with ONIDLE.

MONTHLY

1 - 12

The task runs every N months.

MONTHLY

LASTDAY

The task runs on the last day of the month.

MONTHLY

FIRST, SECOND, THIRD, FOURTH, LAST

Use with the /dDay parameter to run a task on a particular week and day. For example, on the third Wednesday of the month.

/d Day[,Day...] | *
Specifies a day (or days) of the week or a day (or days) of a month. Valid only with a WEEKLY or MONTHLY schedule.
Copy

<colgroup>
<col style="width: 25%" />
<col style="width: 25%" />
<col style="width: 25%" />
<col style="width: 25%" />
</colgroup>

Schedule type
Modifier
Day values (/d)
Description

WEEKLY

1 - 52

MON - SUN[,MON - SUN...] | *

Optional. MON is the default. The wildcard value (*) means every day.

MONTHLY

FIRST, SECOND, THIRD, FOURTH, LAST

MON - SUN

Required for a specific week schedule.

MONTHLY

None or {1 - 12}

1 - 31

Optional and valid only with no modifier (/mo) parameter (a specific date schedule) or when the /mo is 1 - 12 (an "every N months" schedule). The default is day 1 (the first day of the month).

/m Month[,Month...]
Specifies a month or months of the year during which the scheduled task should run. Valid values are JAN - DEC. The /m parameter is valid only with a MONTHLY schedule. It is required when the LASTDAY modifier is used.
/i IdleTime
Specifies how many minutes the computer is idle before the task starts. A valid value is a whole number from 1 to 999. This parameter is valid only with an ONIDLE schedule, and then it is required.
/st StartTime
Specifies the time of day that the task starts (each time it starts) in HH**:**MM 24-hour format. The default value is the current time on the local computer. The /st parameter is valid with MINUTE, HOURLY, DAILY, WEEKLY, MONTHLY, and ONCE schedules. It is required for a ONCE schedule.
/ri Interval
Specifies the repetition interval in minutes. This is not applicable for schedule types: MINUTE, HOURLY, ONSTART, ONLOGON, ONIDLE. Valid range is 1 to 599940 minutes (599940 minutes = 9999 hours). If either /ET or /DU is specified, then the repetition interval defaults to 10 minutes.
/et EndTime
Specifies the time of day that a minute or hourly task schedule ends in HH**:**MM 24-hour format. After the specified end time, Schtasks does not start the task again until the start time recurs. By default, task schedules have no end time. This parameter is optional and valid only with a MINUTE or HOURLY schedule.
Copy
For an example, see:
- "To schedule a task that runs every 100 minutes during non-business hours" in the **To schedule a task that runs every** ***N*** **minutes** section.
/du Duration
Specifies a maximum length of time for a minute or hourly schedule in HHHH**:**MM 24-hour format. After the specified time elapses, Schtasks does not start the task again until the start time recurs. By default, task schedules have no maximum duration. This parameter is optional and valid only with a MINUTE or HOURLY schedule.
Copy
For an example, see:
- "To schedule a task that runs every 3 hours for 10 hours" in the **To schedule a task that runs every** ***N*** **hours** section.
/k
Stops the program that the task runs at the time specified by /et or /du. Without /k, Schtasks does not start the program again after it reaches the time specified by /et or /du, but it does not stop the program if it is still running. This parameter is optional and valid only with a MINUTE or HOURLY schedule.
Copy
For an example, see:
- "To schedule a task that runs every 100 minutes during non-business hours" in the **To schedule a task that runs every** ***N*** **minutes** section.
/sd StartDate
Specifies the date on which the task schedule starts. The default value is the current date on the local computer. The /sd parameter is valid and optional for all schedule types.
Copy
The format for the *StartDate* argument varies with the locale selected for the local computer in Regional and Language Options in Control Panel. Only one format is valid for each locale.
The valid date formats are listed in the following table. Use the format most similar to the format selected for **Short date** in Regional and Language Options in Control Panel on the local computer.

<colgroup>
<col style="width: 50%" />
<col style="width: 50%" />
</colgroup>

MM/DD/YYYY

Use for month-first formats, such as English (United States) and Spanish (Panama).

DD/MM/YYYY

Use for day-first formats, such as Bulgarian and Dutch (Netherlands).

YYYY/MM/DD

Use for year-first formats, such as Swedish and French (Canada).

/ed EndDate
Specifies the date on which the schedule ends. This parameter is optional. It is not valid in a ONCE, ONSTART, ONLOGON, or ONIDLE schedule. By default, schedules have no ending date.
Copy
The format for the *EndDate* argument varies with the locale selected for the local computer in Regional and Language Options in Control Panel. Only one format is valid for each locale.
The valid date formats are listed in the following table. Use the format most similar to the format selected for **Short date** in Regional and Language Options in Control Panel on the local computer.

<colgroup>
<col style="width: 50%" />
<col style="width: 50%" />
</colgroup>

MM/DD/YYYY

Use for month-first formats, such as English (United States) and Spanish (Panama).

DD/MM/YYYY

Use for day-first formats, such as Bulgarian and Dutch (Netherlands).

YYYY/MM/DD

Use for year-first formats, such as Swedish and French (Canada).

/it
Specifies to run the task only when the "run as" user (the user account under which the task runs) is logged on to the computer. This parameter has no effect on tasks that run with system permissions.
Copy
By default, the "run as" user is the current user of the local computer when the task is scheduled or the account specified by the **/u** parameter, if one is used. However, if the command includes the **/ru** parameter, then the "run as" user is the account specified by the **/ru** parameter.
For examples, see:
- "To schedule a task that runs every 70 days if I am logged on" in the **To schedule a task that runs every** ***N*** **days** section.
- "To run a task only when a particular user is logged on" in the **To schedule a task that runs with different permissions** section.
/Z
Specifies to delete the task upon completion of its schedule.
/F
Specifies to create the task and suppress warnings if the specified task already exists.
/?
Displays help at the command prompt.
To schedule a task that runs every N minutes
Minute Schedule Syntax
schtasks /create /tn TaskName /tr TaskRun /sc minute [/mo {1 - 1439}] [/st HH**:MM] [/sd** StartDate] [/ed EndDate] [{/et HH**:MM | /du HHHH:MM} [/k**]] [/it] [/ru {[Domain**\]User [/rp** Password] | System}] [/s Computer [/u [Domain**\]User [/p** Password]]]
Remarks
In a minute schedule, the /sc minute parameter is required. The /mo (modifier) parameter is optional and specifies the number of minutes between each run of the task. The default value for /mo is 1 (every minute). The /et (end time) and /du (duration) parameters are optional and can be used with or without the /k (end task) parameter.
Examples
To schedule a task that runs every 20 minutes
The following command schedules a security script, Sec.vbs, to run every 20 minutes. The command uses the /sc parameter to specify a minute schedule and the /mo parameter to specify an interval of 20 minutes.
Because the command does not include a starting date or time, the task starts 20 minutes after the command completes, and runs every 20 minutes thereafter whenever the system is running. Notice that the security script source file is located on a remote computer, but that the task is scheduled and executes on the local computer.
schtasks /create /sc minute /mo 20 /tn "Security Script" /tr \\central\data\scripts\sec.vbs
To schedule a task that runs every 100 minutes during non-business hours
The following command schedules a security script, Sec.vbs, to run on the local computer every 100 minutes between 5:00 P.M. and 7:59 A.M. each day. The command uses the /sc parameter to specify a minute schedule and the /mo parameter to specify an interval of 100 minutes. It uses the /st and /et parameters to specify the start time and end time of each day's schedule. It also uses the /k parameter to stop the script if it is still running at 7:59 A.M. Without /k, Schtasks would not start the script after 7:59 A.M., but if the instance started at 6:20 A.M. was still running, it would not stop it.
schtasks /create /tn "Security Script" /tr sec.vbs /sc minute /mo 100 /st 17:00 /et 08:00 /k
To schedule a task that runs every N hours
Hourly Schedule Syntax
schtasks /create /tn TaskName /tr TaskRun /sc hourly [/mo {1 - 23}] [/st HH**:MM] [/sd** StartDate] [/ed EndDate] [{/et HH**:MM | /du HHHH:MM} [/k**]] [/it] [/ru {[Domain**\]User [/rp** Password] | System}] [/s Computer [/u [Domain**\]User [/p** Password]]]
Remarks
In an hourly schedule, the /sc hourly parameter is required. The /mo (modifier) parameter is optional and specifies the number of hours between each run of the task. The default value for /mo is 1 (every hour). The /k (end task) parameter is optional and can be used with either /et (end at the specified time) or /du (end after the specified interval).
Examples
To schedule a task that runs every five hours
The following command schedules the MyApp program to run every five hours beginning on the first day of March 2002. It uses the /mo parameter to specify the interval and the /sd parameter to specify the start date. Because the command does not specify a start time, the current time is used as the start time.
Because the local computer is set to use the English (Zimbabwe) option in Regional and Language Options, the format for the start date is MM/DD/YYYY (03/01/2002).
schtasks /create /sc hourly /mo 5 /sd 03/01/2002 /tn "My App" /tr c:\apps\myapp.exe
To schedule a task that runs every hour at five minutes past the hour
The following command schedules the MyApp program to run hourly beginning at five minutes past midnight. Because the /mo parameter is omitted, the command uses the default value for the hourly schedule, which is every (1) hour. If this command runs after 12:05 A.M., the program does not run until the next day.
schtasks /create /sc hourly /st 00:05 /tn "My App" /tr c:\apps\myapp.exe
To schedule a task that runs every 3 hours for 10 hours
The following command schedules the MyApp program to run every 3 hours for 10 hours.
The command uses the /sc parameter to specify an hourly schedule and the /mo parameter to specify the interval of 3 hours. It uses the /st parameter to start the schedule at midnight and the /du parameter to end the recurrences after 10 hours. Because the program runs for just a few minutes, the /k parameter, which stops the program if it is still running when the duration expires, is not necessary.
schtasks /create /tn "My App" /tr myapp.exe /sc hourly /mo 3 /st 00:00 /du 0010:00
In this example, the task runs at 12:00 A.M., 3:00 A.M., 6:00 A.M., and 9:00 A.M. Because the duration is 10 hours, the task is not run again at 12:00 P.M. Instead, it starts again at 12:00 A.M. the next day.
To schedule a task that runs every N days
Daily Schedule Syntax
schtasks /create /tn TaskName /tr TaskRun /sc daily [/mo {1 - 365}] [/st HH**:MM] [/sd** StartDate] [/ed EndDate] [/it] [/ru {[Domain**\]User [/rp** Password] | System}] [/s Computer [/u [Domain**\]User [/p** Password]]]
Remarks
In a daily schedule, the /sc daily parameter is required. The /mo (modifier) parameter is optional and specifies the number of days between each run of the task. The default value for /mo is 1 (every day).
Examples
To schedule a task that runs every day
The following example schedules the MyApp program to run once a day, every day, at 8:00 A.M. until December 31, 2002. Because it omits the /mo parameter, the default interval of 1 is used to run the command every day.
In this example, because the local computer system is set to the English (United Kingdom) option in Regional and Language Options in Control Panel, the format for the end date is DD/MM/YYYY (31/12/2002)
schtasks /create /tn "My App" /tr c:\apps\myapp.exe /sc daily /st 08:00 /ed 31/12/2002
To schedule a task that runs every 12 days
The following example schedules the MyApp program to run every twelve days at 1:00 P.M. (13:00) beginning on December 31, 2002. The command uses the /mo parameter to specify an interval of two (2) days and the /sd and /st parameters to specify the date and time.
In this example, because the system is set to the English (Zimbabwe) option in Regional and Language Options in Control Panel, the format for the end date is MM/DD/YYYY (12/31/2002)
schtasks /create /tn "My App" /tr c:\apps\myapp.exe /sc daily /mo 12 /sd 12/31/2002 /st 13:00
To schedule a task that runs every 70 days if I am logged on
The following command schedules a security script, Sec.vbs, to run every 70 days. The command uses the /mo parameter to specify an interval of 70 days. It also uses the /it parameter to specify that the task runs only when the user under whose account the task runs is logged onto the computer. Because the task will run with the permissions of my user account, then the task will run only when I am logged on.
schtasks /create /tn "Security Script" /tr sec.vbs /sc daily /mo 70 /it
Note
To identify tasks with the interactive-only (/it) property, use a verbose query (/query /v). In a verbose query display of a task with /it, the Logon Mode field has a value of Interactive only.
To schedule a task that runs every N weeks
Weekly Schedule Syntax
schtasks /create /tn TaskName /tr TaskRun /sc weekly [/mo {1 - 52}] [/d {MON - SUN[,MON - SUN...] | *}] [/st HH**:MM] [/sd** StartDate] [/ed EndDate] [/it] [/ru {[Domain**\]User [/rp** Password] | System}] [/s Computer [/u [Domain**\]User [/p** Password]]]
Remarks
In a weekly schedule, the /sc weekly parameter is required. The /mo (modifier) parameter is optional and specifies the number of weeks between each run of the task. The default value for /mo is 1 (every week).
Weekly schedules also have an optional /d parameter to schedule the task to run on specified days of the week, or on all days (*). The default is MON (Monday). The every day (*) option is equivalent to scheduling a daily task.
Examples
To schedule a task that runs every six weeks
The following command schedules the MyApp program to run on a remote computer every six weeks. The command uses the /mo parameter to specify the interval. Because the command omits the /d parameter, the task runs on Mondays.
This command also uses the /s parameter to specify the remote computer and the /u parameter to run the command with the permissions of the user's Administrator account. Because the /p parameter is omitted, SchTasks.exe prompts the user for the Administrator account password.
Also, because the command is run remotely, all paths in the command, including the path to MyApp.exe, refer to paths on the remote computer.
schtasks /create /tn "My App" /tr c:\apps\myapp.exe /sc weekly /mo 6 /s Server16 /u Admin01
To schedule a task that runs every other week on Friday
The following command schedules a task to run every other Friday. It uses the /mo parameter to specify the two-week interval and the /d parameter to specify the day of the week. To schedule a task that runs every Friday, omit the /mo parameter or set it to 1.
schtasks /create /tn "My App" /tr c:\apps\myapp.exe /sc weekly /mo 2 /d FRI
To schedule a task that runs every N months
Syntax
schtasks /create /tn TaskName /tr TaskRun /sc monthly [/mo {1 - 12}] [/d {1 - 31}] [/st HH**:MM] [/sd** StartDate] [/ed EndDate] [/it] [/ru {[Domain**\]User [/rp** Password] | System}] [/s Computer [/u [Domain**\]User [/p** Password]]]
Remarks
In this schedule type, the /sc monthly parameter is required. The /mo (modifier) parameter, which specifies the number of months between each run of the task, is optional and the default is 1 (every month). This schedule type also has an optional /d parameter to schedule the task to run on a specified date of the month. The default is 1 (the first day of the month).
Examples
To schedule a task that runs on the first day of every month
The following command schedules the MyApp program to run on the first day of every month. Because a value of 1 is the default for both the /mo (modifier) parameter and the /d (day) parameter, these parameters are omitted from the command.
schtasks /create /tn "My App" /tr myapp.exe /sc monthly
To schedule a task that runs every three months
The following command schedules the MyApp program to run every three months. It uses the /mo parameter to specify the interval.
schtasks /create /tn "My App" /tr c:\apps\myapp.exe /sc monthly /mo 3
To schedule a task that runs at midnight on the 21st day of every other month
The following command schedules the MyApp program to run every other month on the 21st day of the month at midnight. The command specifies that this task should run for one year, from July 2, 2002 to June 30, 2003.
The command uses the /mo parameter to specify the monthly interval (every two months), the /d parameter to specify the date, and the /st to specify the time. It also uses the /sd and /ed parameters to specify the start date and end date, respectively. Because the local computer is set to the English (South Africa) option in Regional and Language Options in the Control Panel, the dates are specified in the local format, which is YYYY/MM/DD.
schtasks /create /tn "My App" /tr c:\apps\myapp.exe /sc monthly /mo 2 /d 21 /st 00:00 /sd 2002/07/01 /ed 2003/06/30
To schedule a task that runs on a specific day of the week
Weekly Schedule Syntax
schtasks /create /tn TaskName /tr TaskRun /sc weekly [/d {MON - SUN[,MON - SUN...] | *}] [/mo {1 - 52}] [/st HH**:MM] [/sd** StartDate] [/ed EndDate] [/it] [/ru {[Domain**\]User [/rp** Password] | System}] [/s Computer [/u [Domain**\]User [/p** Password]]]
Remarks
The "day of the week" schedule is a variation of the weekly schedule. In a weekly schedule, the /sc weekly parameter is required. The /mo (modifier) parameter is optional and specifies the number of weeks between each run of the task. The default value for /mo is 1 (every week). The /d parameter, which is optional, schedules the task to run on specified days of the week, or on all days (*). The default is MON (Monday). The every day option (/d *) is equivalent to scheduling a daily task.
Examples
To schedule a task that runs every Wednesday
The following command schedules the MyApp program to run every week on Wednesday. The command uses the /d parameter to specify the day of the week. Because the command omits the /mo parameter, the task runs every week.
schtasks /create /tn "My App" /tr c:\apps\myapp.exe /sc weekly /d WED
To schedule a task that runs every eight weeks on Monday and Friday
The following command schedules a task to run on Monday and Friday of every eighth week. It uses the /d parameter to specify the days and the /mo parameter to specify the eight-week interval.
schtasks /create /tn "My App" /tr c:\apps\myapp.exe /sc weekly /mo 8 /d MON,FRI
To schedule a task that runs on a specific week of the month
Specific Week Syntax
schtasks /create /tn TaskName /tr TaskRun /sc monthly /mo {FIRST | SECOND | THIRD | FOURTH | LAST} /d MON - SUN [/m {JAN - DEC[,JAN - DEC...] | *}] [/st HH**:MM] [/sd** StartDate] [/ed EndDate] [/it] [/ru {[Domain**\]User [/rp** Password] | System}] [/s Computer [/u [Domain**\]User [/p** Password]]]
Remarks
In this schedule type, the /sc monthly parameter, the /mo (modifier) parameter, and the /d (day) parameter are required. The /mo (modifier) parameter specifies the week on which the task runs. The /d parameter specifies the day of the week. (You can specify only one day of the week for this schedule type.) This schedule also has an optional /m (month) parameter that lets you schedule the task for particular months.
Examples
To schedule a task for the second Sunday of every month
The following command schedules the MyApp program to run on the second Sunday of every month. It uses the /mo parameter to specify the second week of the month and the /d parameter to specify the day.
schtasks /create /tn "My App" /tr c:\apps\myapp.exe /sc monthly /mo SECOND /d SUN
To schedule a task for the first Monday in March and September
The following command schedules the MyApp program to run on the first Monday in March and September. It uses the /mo parameter to specify the first week of the month and the /d parameter to specify the day. It uses /m parameter to specify the month, separating the month arguments with a comma.
schtasks /create /tn "My App" /tr c:\apps\myapp.exe /sc monthly /mo FIRST /d MON /m MAR,SEP
To schedule a task that runs on a specific date each month
Specific date syntax
schtasks /create /tn TaskName /tr TaskRun /sc monthly /d {1 - 31} [/m {JAN - DEC[,JAN - DEC...] | *}] [/st HH**:MM] [/sd** StartDate] [/ed EndDate] [/it] [/ru {[Domain**\]User [/rp** Password] | System}] [/s Computer [/u [Domain**\]User [/p** Password]]]
Remarks
In the specific date schedule type, the /sc monthly parameter and the /d (day) parameter are required. The /d parameter specifies a date of the month (1 - 31), not a day of the week. You can specify only one day in the schedule. The /mo (modifier) parameter is not valid with this schedule type.
The /m (month) parameter is optional for this schedule type and the default is every month (*). Schtasks does not let you schedule a task for a date that does not occur in a month specified by the /m parameter. However, if omit the /m parameter, and schedule a task for a date that does not appear in every month, such as the 31st day, then the task does not run in the shorter months. To schedule a task for the last day of the month, use the last day schedule type.
Examples
To schedule a task for the first day of every month
The following command schedules the MyApp program to run on the first day of every month. Because the default modifier is none (no modifier), the default day is day 1, and the default month is every month, the command does not need any additional parameters.
schtasks /create /tn "My App" /tr c:\apps\myapp.exe /sc monthly
To schedule a task for the 15th days of May and June
The following command schedules the MyApp program to run on May 15 and June 15 at 3:00 P.M. (15:00). It uses the /d parameter to specify the date and the /m parameter to specify the months. It also uses the /st parameter to specify the start time.
schtasks /create /tn "My App" /tr c:\apps\myapp.exe /sc monthly /d 15 /m MAY,JUN /st 15:00
To schedule a task that runs on a the last day of a month
Last day syntax
schtasks /create /tn TaskName /tr TaskRun /sc monthly /mo LASTDAY /m {JAN - DEC[,JAN - DEC...]} [/st HH**:MM] [/sd** StartDate] [/ed EndDate] [/it] [/ru {[Domain**\]User [/rp** Password] | System}] [/s Computer [/u [Domain**\]User [/p** Password]]]
Remarks
In the last day schedule type, the /sc monthly parameter, the /mo LASTDAY (modifier) parameter, and the /m (month) parameter are required. The /d (day) parameter is not valid.
Examples
To schedule a task for the last day of every month
To run a program on the last day of every month, you must create three separate tasks. Each task will include months that have the same number of days. Each task uses the /mo parameter to specify the last day and the /m parameter to specify the months.
The following command schedules the MyApp program to run on the last day of every month that contains 31 days.
schtasks /create /tn "My App" /tr c:\apps\myapp.exe /sc monthly /mo lastday /m JAN,MAR,MAY,JUL,AUG,OCT,DEC
The following command schedules the MyApp program to run on the last day of every month that contains 30 days.
schtasks /create /tn "My App" /tr c:\apps\myapp.exe /sc monthly /mo lastday /m APR,JUN,SEP,NOV
The following command schedules the MyApp program to run on the last day of February.
schtasks /create /tn "My App" /tr c:\apps\myapp.exe /sc monthly /mo lastday /m FEB
To schedule a task at 6:00 P.M. on the last day of February
You can also schedule a task to run at a specific time on the last day of a month. The following command schedules the MyApp program to run at 6:00 P.M. on the last day of February. It uses the /mo parameter to specify the last day, the /m parameter to specify the month, and the /st parameter to specify the start time.
schtasks /create /tn "My App" /tr c:\apps\myapp.exe /sc monthly /mo lastday /m FEB /st 18:00
To schedule a task that runs once
Syntax
schtasks /create /tn TaskName /tr TaskRun /sc once /st HH : MM [/sd StartDate] [/it] [/ru {[Domain**\]User [/rp** Password] | System}] [/s Computer [/u [Domain**\]User [/p** Password]]]
Remarks
In the run-once schedule type, the /sc once parameter is required. The /st parameter, which specifies the time that the task runs, is required. The /sd parameter, which specifies the date that the task runs, is optional. The /mo (modifier) and /ed (end date) parameters are not valid for this schedule type.
Schtasks does not permit you to schedule a task to run once if the date and time specified are in the past, based on the time of the local computer. To schedule a task that runs once on a remote computer in a different time zone, you must schedule it before that date and time occurs on the local computer.
Examples
To schedule a task that runs one time
The following command schedules the MyApp program to run at midnight on January 1, 2003. It uses the /sc parameter to specify the schedule type and the /sd and st to specify the date and time.
Because the local computer is uses the English (United States) option in Regional and Language Options in Control Panel, the format for the start date is MM/DD/YYYY.
schtasks /create /tn "My App" /tr c:\apps\myapp.exe /sc once /sd 01/01/2003 /st 00:00
To schedule a task that runs every time the system starts
Syntax
schtasks /create /tn TaskName /tr TaskRun /sc onstart [/sd StartDate] [/it] [/ru {[Domain**\]User [/rp** Password] | System}] [/s Computer [/u [Domain**\]User [/p** Password]]]
Remarks
In the on-start schedule type, the /sc onstart parameter is required. The /sd (start date) parameter is optional and the default is the current date.
Examples
To schedule a task that runs when the system starts
The following command schedules the MyApp program to run every time the system starts, beginning on March 15, 2001:
Because the local computer is uses the English (United States) option in Regional and Language Options in Control Panel, the format for the start date is MM/DD/YYYY.
schtasks /create /tn "My App" /tr c:\apps\myapp.exe /sc onstart /sd 03/15/2001
To schedule a task that runs when a user logs on
Syntax
schtasks /create /tn TaskName /tr TaskRun /sc onlogon [/sd StartDate] [/it] [/ru {[Domain**\]User [/rp** Password] | System}] [/s Computer [/u [Domain**\]User [/p** Password]]]
Remarks
The "on logon" schedule type schedules a task that runs whenever any user logs on to the computer. In the "on logon" schedule type, the /sc onlogon parameter is required. The /sd (start date) parameter is optional and the default is the current date.
Examples
To schedule a task that runs when a user logs on to a remote computer
The following command schedules a batch file to run every time a user (any user) logs on to the remote computer. It uses the /s parameter to specify the remote computer. Because the command is remote, all paths in the command, including the path to the batch file, refer to a path on the remote computer.
schtasks /create /tn "Start Web Site" /tr c:\myiis\webstart.bat /sc onlogon /s Server23
To schedule a task that runs when the system is idle
Syntax
schtasks /create /tn TaskName /tr TaskRun /sc onidle /i {1 - 999} [/sd StartDate] [/it] [/ru {[Domain**\]User [/rp** Password] | System}] [/s Computer [/u [Domain**\]User [/p** Password]]]
Remarks
The "on idle" schedule type schedules a task that runs whenever there is no user activity during the time specified by the /i parameter. In the "on idle" schedule type, the /sc onidle parameter and the /i parameter are required. The /sd (start date) is optional and the default is the current date.
Examples
To schedule a task that runs whenever the computer is idle
The following command schedules the MyApp program to run whenever the computer is idle. It uses the required /i parameter to specify that the computer must remain idle for ten minutes before the task starts.
schtasks /create /tn "My App" /tr c:\apps\myapp.exe /sc onidle /i 10
To schedule a task that runs now
Schtasks does not have a "run now" option, but you can simulate that option by creating a task that runs once and starts in a few minutes.
Syntax
schtasks /create /tn TaskName /tr TaskRun /sc once [/st HH**:MM] /sd MM/DD/YYYY [/it**] [/ru {[Domain**\]User [/rp** Password] | System}] [/s Computer [/u [Domain**\]User [/p** Password]]]
Examples
To schedule a task that runs a few minutes from now.
The following command schedules a task to run once, on November 13, 2002 at 2:18 P.M. local time.
Because the local computer is uses the English (United States) option in Regional and Language Options in Control Panel, the format for the start date is MM/DD/YYYY.
schtasks /create /tn "My App" /tr c:\apps\myapp.exe /sc once /st 14:18 /sd 11/13/2002
To schedule a task that runs with different permissions
You can schedule tasks of all types to run with permissions of an alternate account on both the local and a remote computer. In addition to the parameters required for the particular schedule type, the /ru parameter is required and the /rp parameter is optional.
Examples
To run a task with Administrator permissions on the local computer
The following command schedules the MyApp program to run on the local computer. It uses the /ru to specify that the task should run with the permissions of the user's Administrator account (Admin06). In this example, the task is scheduled to run every Tuesday, but you can use any schedule type for a task run with alternate permissions.
schtasks /create /tn "My App" /tr myapp.exe /sc weekly /d TUE /ru Admin06
In response, SchTasks.exe prompts for the "run as" password for the Admin06 account and then displays a success message.
Copy
Please enter the run as password for Admin06: ********
SUCCESS: The scheduled task "My App" has successfully been created.
To run a task with alternate permissions on a remote computer
The following command schedules the MyApp program to run on the Marketing computer every four days.
The command uses the /sc parameter to specify a daily schedule and /mo parameter to specify an interval of four days.
The command uses the /s parameter to provide the name of the remote computer and the /u parameter to specify an account with permission to schedule a task on the remote computer (Admin01 on the Marketing computer). It also uses the /ru parameter to specify that the task should run with the permissions of the user's non-Administrator account (User01 in the Reskits domain). Without the /ru parameter, the task would run with the permissions of the account specified by /u.
schtasks /create /tn "My App" /tr myapp.exe /sc daily /mo 4 /s Marketing /u Marketing\Admin01 /ru Reskits\User01
Schtasks first requests the password of the user named by the /u parameter (to run the command) and then requests the password of the user named by the /ru parameter (to run the task). After authenticating the passwords, Schtasks displays a message indicating that the task is scheduled.
Copy
Type the password for Marketing\Admin01:********
Please enter the run as password for Reskits\User01: ********
SUCCESS: The scheduled task "My App" has successfully been created.
To run a task only when a particular user is logged on
The following command schedules the AdminCheck.exe program to run on the Public computer every Friday at 4:00 A.M., but only if the administrator of the computer is logged on.
The command uses the /sc parameter to specify a weekly schedule, the /d parameter to specify the day, and the /st parameter to specify the start time.
The command uses the /s parameter to provide the name of the remote computer and the /u parameter to specify an account with permission to schedule a task on the remote computer. It also uses the /ru parameter to configure the task to run with the permissions of the administrator of the Public computer (Public\Admin01) and the /it parameter to indicate that the task runs only when the Public\Admin01 account is logged on.
schtasks /create /tn "Check Admin" /tr AdminCheck.exe /sc weekly /d FRI /st 04:00 /s Public /u Domain3\Admin06 /ru Public\Admin01 /it
Note
To identify tasks with the interactive-only (/it) property, use a verbose query (/query /v). In a verbose query display of a task with /it, the Logon Mode field has a value of Interactive only.
To schedule a task that runs with system permissions
Tasks of all types can run with permissions of the System account on both the local and a remote computer. In addition to the parameters required for the particular schedule type, the /ru system (or /ru "") parameter is required and the /rp parameter is not valid.
Important
The System account does not have interactive logon rights. Users cannot see or interact with programs or tasks run with system permissions.
The /ru parameter determines the permissions under which the task runs, not the permissions used to schedule the task. Only Administrators can schedule tasks, regardless of the value of the /ru parameter.
Note
To identify tasks that run with system permissions, use a verbose query (/query /v). In a verbose query display of a system-run task, the Run As User field has a value of NT AUTHORITY\SYSTEM and the Logon Mode field has a value of Background only.
Examples
To run a task with system permissions
The following command schedules the MyApp program to run on the local computer with permissions of the System account. In this example, the task is scheduled to run on the fifteenth day of every month, but you can use any schedule type for a task run with system permissions.
The command uses the /ru System parameter to specify the system security context. Because system tasks do not use a password, the /rp parameter is omitted.
schtasks /create /tn "My App" /tr c:\apps\myapp.exe /sc monthly /d 15 /ru System
In response, SchTasks.exe displays an informational message and a success message. It does not prompt for a password.
Copy
INFO: The task will be created under user name ("NT AUTHORITY\SYSTEM").
SUCCESS: The Scheduled task "My App" has successfully been created.
To run a task with system permissions on a remote computer
The following command schedules the MyApp program to run on the Finance01 computer every morning at 4:00 A.M. with system permissions.
The command uses the /tn parameter to name the task and the /tr parameter to specify the remote copy of the MyApp program. It uses the /sc parameter to specify a daily schedule, but omits the /mo parameter because 1 (every day) is the default. It uses the /st parameter to specify the start time, which is also the time the task will run each day.
The command uses the /s parameter to provide the name of the remote computer and the /u parameter to specify an account with permission to schedule a task on the remote computer. It also uses the /ru parameter to specify that the task should run under the System account. Without the /ru parameter, the task would run with the permissions of the account specified by /u.
schtasks /create /tn "My App" /tr myapp.exe /sc daily /st 04:00 /s Finance01 /u Admin01 /ru System
Schtasks requests the password of the user named by the /u parameter and, after authenticating the password, displays a message indicating that the task is created and that it will run with permissions of the system account.
Copy
Type the password for Admin01:**********
INFO: The Schedule Task "My App" will be created under user name ("NT AUTHORITY\
SYSTEM").
SUCCESS: The scheduled task "My App" has successfully been created.
To schedule a task that runs more than one program
Each task runs only one program. However, you can create a batch file that runs multiple programs and then schedule a task to run the batch file. The following procedure demonstrates this method:
Create a batch file that starts the programs you want to run.
In this example, you create a batch file that starts Event Viewer (Eventvwr.exe) and System Monitor (Perfmon.exe).
Open a text editor, such as Notepad.
Type the name and fully qualified path to the executable file for each program. In this case, the file includes the following statements.
C:\Windows\System32\Eventvwr.exe C:\Windows\System32\Perfmon.exe
Save the file as MyApps.bat.
Use SchTasks.exe to create a task that runs MyApps.bat.
The following command creates the Monitor task, which runs whenever anyone logs on. It uses the /tn parameter to name the task, and the /tr parameter to run MyApps.bat. It uses the /sc parameter to indicate the OnLogon schedule type and the /ru parameter to run the task with the permissions of the user's Administrator account.
schtasks /create /tn Monitor /tr C:\MyApps.bat /sc onlogon /ru Reskit\Administrator
As a result of this command, whenever a user logs on to the computer, the task starts both Event Viewer and System Monitor.
To schedule a task that runs on a remote computer
To schedule a task to run on a remote computer, you must add the task to the remote computer's schedule. Tasks of all types can be scheduled on a remote computer, but the following conditions must be met.
You must have permission to schedule the task. As such, you must be logged on to the local computer with an account that is a member of the Administrators group on the remote computer, or you must use the /u parameter to provide the credentials of an Administrator of the remote computer.
You can use the /u parameter only when the local and remote computers are in the same domain or the local computer is in a domain that the remote computer domain trusts. Otherwise, the remote computer cannot authenticate the user account specified and it cannot verify that the account is a member of the Administrators group.
The task must have sufficient permission to run on the remote computer. The permissions required vary with the task. By default, the task runs with the permission of the current user of the local computer or, if the /u parameter is used, the task runs with the permission of the account specified by the /u parameter. However, you can use the /ru parameter to run the task with permissions of a different user account or with system permissions.
Examples
An Administrator schedules a task on a remote computer
The following command schedules the MyApp program to run on the SRV01 remote computer every ten days starting immediately. The command uses the /s parameter to provide the name of the remote computer. Because the local current user is an Administrator of the remote computer, the /u parameter, which provides alternate permissions for scheduling the task, is not necessary.
Please note that when scheduling tasks on a remote computer, all parameters refer to the remote computer. Therefore, the executable file specified by the /tr parameter refers to the copy of MyApp.exe on the remote computer.
schtasks /create /s SRV01 /tn "My App" /tr "c:\program files\corpapps\myapp.exe" /sc daily /mo 10
In response, Schtasks displays a success message indicating that the task is scheduled.
A user schedules a command on a remote computer (Case 1)
The following command schedules the MyApp program to run on the SRV06 remote computer every three hours. Because Administrator permissions are required to schedule a task, the command uses the /u and /p parameters to provide the credentials of the user's Administrator account (Admin01 in the Reskits domain). By default, these permission are also used to run the task. However, because the task doesn't need Administrator permissions to run, the command includes the /ru and /rp parameters to override the default and run the task with permission of the user's non-Administrator account on the remote computer.
schtasks /create /s SRV06 /tn "My App" /tr "c:\program files\corpapps\myapp.exe" /sc hourly /mo 3 /u reskits\admin01 /p R43253@4$ /ru SRV06\user03 /rp MyFav!!Pswd
In response, Schtasks displays a success message indicating that the task is scheduled.
A user schedules a command on a remote computer (Case 2)
The following command schedules the MyApp program to run on the SRV02 remote computer on the last day of every month. Because the local current user (user03) is not an Administrator of the remote computer, the command uses the /u parameter to provide the credentials of the user's Administrator account (Admin01 in the Reskits domain). The Administrator account permissions will be used to schedule the task and to run the task.
schtasks /create /s SRV02 /tn "My App" /tr "c:\program files\corpapps\myapp.exe" /sc monthly /mo LASTDAY /m * /u reskits\admin01
Because the command did not include the /p (password) parameter, Schtasks prompts for the password. Then it displays a success message and, in this case, a warning.
Copy
Type the password for reskits\admin01:********
SUCCESS: The scheduled task "My App" has successfully been created.
WARNING: The Scheduled task "My App" has been created, but may not run because
the account information could not be set.
This warning indicates that the remote domain could not authenticate the account specified by the /u parameter. In this case, the remote domain could not authenticate the user account because the local computer is not a member of a domain that the remote computer domain trusts. When this occurs, the task job appears in the list of scheduled tasks, but the task is actually empty and it will not run.
The following display from a verbose query exposes the problem with the task. In the display, note that the value of Next Run Time is Never and that the value of Run As User is Could not be retrieved from the task scheduler database.
Had this computer been a member of the same domain or a trusted domain, the task would have been successfully scheduled and would have run as specified.
Copy
HostName: SRV44
TaskName: My App
Next Run Time: Never
Status:
Logon mode: Interactive/Background
Last Run Time: Never
Last Result: 0
Creator: user03
Schedule: At 3:52 PM on day 31 of every month, start
starting 12/14/2001
Task To Run: c:\program files\corpapps\myapp.exe
Start In: myapp.exe
Comment: N/A
Scheduled Task State: Disabled
Scheduled Type: Monthly
Start Time: 3:52:00 PM
Start Date: 12/14/2001
End Date: N/A
Days: 31
Months: JAN,FEB,MAR,APR,MAY,JUN,JUL,AUG,SEP,OCT,NO
V,DEC
Run As User: Could not be retrieved from the task sched
uler database
Delete Task If Not Rescheduled: Enabled
Stop Task If Runs X Hours and X Mins: 72:0
Repeat: Every: Disabled
Repeat: Until: Time: Disabled
Repeat: Until: Duration: Disabled
Repeat: Stop If Still Running: Disabled
Idle Time: Disabled
Power Management: Disabled
Remarks
To run a /create command with the permissions of a different user, use the /u parameter. The /u parameter is valid only for scheduling tasks on remote computers.
To view more schtasks /create examples, type schtasks /create /? at a command prompt.
To schedule a task that runs with permissions of a different user, use the /ru parameter. The /ru parameter is valid for tasks on local and remote computers.
To use the /u parameter, the local computer must be in the same domain as the remote computer or must be in a domain that the remote computer domain trusts. Otherwise, either the task is not created, or the task job is empty and the task does not run.
Schtasks always prompts for a password unless you provide one, even when you schedule a task on the local computer using the current user account. This is normal behavior for Schtasks.
Schtasks does not verify program file locations or user account passwords. If you do not enter the correct file location or the correct password for the user account, the task is created, but it does not run. Also, if the password for an account changes or expires, and you do not change the password saved in the task, then the task does not run.
The System account does not have interactive logon rights. Users do not see and cannot interact with programs run with system permissions.
Each task runs only one program. However, you can create a batch file that starts multiple tasks, and then schedule a task that runs the batch file.
You can test a task as soon as you create it. Use the run operation to test the task and then check the SchedLgU.txt file (Systemroot\SchedLgU.txt) for errors.


Skills Survey Dasboard
Press "h" on your keyboard to view this help
While the data loads, here's a little about what you will see appear.
The survey cross filter dashboard allows you to interactively browse the results from from the EDSA demand analysis – a combination of online survey and interviews responses.
E.g., to look at the data from Managers in the UK, select "Manager" in the Role pie chart, and then the UK in the Map view. This will apply this filter to the view. Deselect to restore to the default view or refresh the page.
All charts apart from the word cloud can be used to filter the data.
The default view shows all data:
- The Map view shows locations of the respondents.
- The Role pie chart shows the primary role of the respondents, e.g., data scientist, manager, other.
- The Sector bar chart shows the respondents' primary industry sector.
- The Which skills are essential for a data scientist? chart shows the key areas of data science respondents considered as essential, desirable or not required for a data scientist to have.
- The You or your teams current expertise donut charts show the current level of expertise in 8 key data science areas that respondents were asked to rate. If you filter to manager this was answered for their team, otherwise it was for the indicidual themselves.
- The Word Cloud shows key tools, languages and techniques that have been rated as important to respondents. Size maps to frequency of mention.
The dashboard shows a live view of all submitted data. A filter however excludes inconsistent or incomplete results. Because this may be updated, data currently available may be excluded at a later time.


COVID-19 Charts
Compare Countries
SVG Badges
CSV Export
JSON API
Data Source
All Regions
All Subregions
All Countries
All States/Provinces
All Cities/Counties
CSV Export
Date
Confirmed
Deaths
Loading...


[%settitle Project Argonaut%]
[%file newheader%] [%file newnavbar%]The Argonaut Project addresses the recommendations of the JASON Task Force, a joint task force of the HIT Standards and Policy Committees and is a joint project between HL7 and the following organizations:
For further information concerning the Argonaut project, and the implementation for Argonaut, see the Argonaut Project Wiki.


HTTP Request (JS)
Type in the following form the name of the city you want to know the current temperature of
Current Temperature


Barambe
| | http://barambe.comBar browser/mobile application for real time order creation and management
- Connected user generated orders to render real time in bartender's queue
- Implemented full-stack design from UI/UX up to database schemas
- Designed experience of bar ordering flow by opening/closing drink tabs
- Persisted web/native application state so user's changes present accurately on reload


palmivora plants intracellular Fig. infection structures Marchantia colonization pathogen plant polymorpha Appendix, land thalli interactions Plant TAK air cells using host Phytophthora associated observed dpi early growth hyphae hyphal chambers genes nop {border-style microbes performed ARI-td RXLR expression px;} #ffffff;} fluorescence liverworts photosynthetic dpi. microbial microscopy pathogenic similar symbiotic Biol cell demonstrate plants. proteins effectors filamentous haustoria living oomycete support biomass development infestans liverwort tissues zoospores (Scale Cell bars, branched demonstrating effector levels μm.) colonized divergent marker results RNA disease displayed dpi, expressed gene layer membrane moss suggests Confocal New analysis cycle data described differences evolution however, infected intercellular lifestyle localization pathogens qRT-PCR quantified relative significant structures. Dr. Microbiol Phytol Sci analyses biotrophic compared demonstrated haustoria-like markers presence px; revealed secreted sporangia syntaxin transcripts vascular {font-family Intracellular Medicago Schornack analyzed bryophyte cDNA colonizes font-size interaction mock-treated mycorrhizal responses sporulation suggest symbiosis trafficking transitions up-regulated up-regulation (ARI-td) Bot Genome Moreover, Physiol REX REX, Together, accommodate accommodation appressoria arbuscular associations callose cells. conserved determine double; eukaryotic evidence following function functional fungal fungi generated grown highly homologs identified images indicate inoculated instructions. interfaces invading limited mechanisms model region results. rhizoids role samples staining thalli, transcript used wild-type < -wk-old Collectively, Cryo-SEM Curr Infection Marchantia, Mol MpPRX MpSYPB Pathogen PpEFa Proc SYP Table accumulation angiosperms benthamiana border-color border-width broad cellular central chamber completes complex contrast, controls cruciata digit-like display earliest epidermal experiments haustoria-associated key late molecular mutants patens phase plants, plastid polymorpha. projections ref. required requires solid; specialized statistically stomata storage study successful surface surfaces symbioses symptoms times, tissue {font-style {font-weight (Invitrogen) .). A.G., Acad Bioinformatics Biological Different Duckett Epifluorescence Experiments Fungal Host Importantly, Ishizaki MAZI Marchantia. MpDIR MpRab MpRabA Natl Opin P.C., PNAS Physcomitrella Plants PpCdc PpCdc) Research Rev Sciences Tukey’s Wang ability abundance addition, additional air-chamberless alternative ancient article beneficial bold bright-field changes colonization. common comparison, courier; deposition different diverging em; establish extensive features forms genetic growth. hornworts host-range hosts includes including increased induced induction isolate isolates largely letters machinery manufacturer’s membrane-localized merged mycelium no. nonvascular novel observations occurred oomycetes palmivora, palmivora. planta plants: pores prevalent protein pt;} response significantly signify species structures, studies supported supporting susceptibility syntaxins thalli. thallus time tomato water work


Whether or not one is going to use Prolog to build a finished application, Prolog is still a powerful tool for prototyping the application. The problem might fit nicely into Clam or Foops in which case those systems should be used for the prototype, otherwise pure Prolog can be used to model the application.
In an expert system prototype it is important to model all of the different types of knowledge that will be used in the application. Initial knowledge engineering should be focused on what types of information the expert uses and how it is used. The full range of expertise should be modelled, but not to the depth required for a real system.
The Prolog rules used in a prototype can be quickly molded to get the desired effects in the application. The clean break between the inference engine and the knowledge base can be somewhat ignored to allow more rapid development of the prototype. Explanations, traces, and many of the other features of an expert system are left out of the prototype. The I/O is implemented simply to just give a feeling for the user interaction with the system. The full system can be more elegantly designed once the prototype has been reviewed by the potential users.
This section describes the building of a prototype system which acts as an advisor for a mainframe software salesperson. A good sales person must not only be congenial and buy lunches, but must also have good product knowledge and know how to map that knowledge onto a potential customer's needs. The type of knowledge needed by the sales person is different from that typically held by a technical person.
The technical person thinks of a product in terms of its features, and implementation details. The sales person must think of the prospect's real and perceived needs and be able to map those to benefits provided by the features in the product. That is, the sales person must understand the prospect's objectives and be able to present the benefits and features of the product that help meet those objectives.
The salesperson must also have similar product knowledge about the competitor's products and know which benefits to stress that will show up the weaknesses in the competitor's product for the particular prospect.
In addition to this product knowledge, the sales person also has rules for deciding whether or not the prospect is likely to buy, and recognizing various typical sales situations.
With a large workload, it is often difficult for a sales person to keep up on product knowledge. An expert system which helps the sales person position the products for the prospect would be a big asset for a high tech sales person. The Sales Advisor system is a prototype of such a system, designed to help in the early stages of the sales cycle.
The ways in which sales people mentally organize product knowledge are fairly consistent. The knowledge base for the sales advisor should be organized in a format which is as close to the sales person's organization of the knowledge as possible. This way the semantic gap will be reduced and the knowledge base will be more easily maintained by a domain expert.
The main types of knowledge used by the salesperson fall into the following categories:
• Qualification - the way in which the salesperson determines if the prospect is a good potential customer and worth pursuing;
• Objective Benefit Feature (OBF) analysis - the way a salesperson matches the customer's objectives with the benefits and features of the product;
• Competitive analysis - the way a salesperson decides which benefits and features to stress based on the competitor's weaknesses;
• Situation analysis - the way a salesperson determines if the products will run in the prospect's shop.
• Miscellaneous advice - various rules covering different situations which do not fall neatly in the above categories.
Having this overall organization, we can now begin to prototype the system. The first step is to design the knowledge base. Simple Prolog rules can be used wherever possible. The knowledge for each area will be considered separately. The example uses the products sold for mainframe computers by Cullinet Software.
First we implement the knowledge for qualifying the prospect. This type of knowledge falls easily into a rule format. The final version will probably need some uncertainty handling as in Clam, but it is also important for this system to provide more text output than Clam provides. The quickest way to build the prototype is to use pure Prolog syntax rules with I/O statements included directly in the body of the rule. Clam can be used later with modifications for better text display.
Two examples of qualifying rules are: the prospect must have an IBM mainframe, and the prospect's revenues must be at least $30 million. They are written as unqualified since if the prospect fails a test then it is unqualified.
unqualified:-
not computer('IBM'),
advise('Prospect must have an IBM computer'),
nl.
unqualified:-
revenues(X),
X < 30,
advise('Prospect is unlikely to buy IDMS with revenues under $30 million'),
nl.
Sales people typically store product knowledge in a tabular form called an objective-benefit-feature chart, or OBF chart. It categorizes product knowledge so that for each objective of the customer, the benefits of the product for meeting that objective, and the features of the product are detailed.
For the prototype we can simplify the prospect objectives by considering three main ones: development of applications, building an information center, and building efficient production systems. Each prospect might have a different one of these objectives. The benefits of each product in the product line varies for each of these objectives. This information is stored in Prolog structures of three arguments called obf. The first argument is the feature (or product), the second is the customer objective, and the third is the benefit which is stressed to the prospect.
obf('IDMS/R',
development,
'IDMS/R separates programs from data, simplifying development.').
obf('IDMS/R',
information,
'IDMS/R maintains corporate information for shared access.').
obf('IDMS/R',
production,
'IDMS/R allows finely tuned data access for optimal performance.').
obf('ADS',
development,
'ADS automates many programming tasks thus increasing productivity.').
obf('ADS',
production,
'ADS generates high performance compiled code.').
obf('OLQ',
development,
'OLQ allows easy validation of the database during development.').
obf('OLQ',
information,
'OLQ lets end users access corporate data easily.').
obf('OLE',
information,
'OLE lets users get information with English language queries.').
By using a chart such as this, the salesperson can stress only those features and benefits which meet the prospect's objectives. For example, OLE (OnLine English - a natural language query) would only be mentioned for an information center. OLQ (OnLine Query - a structured query language) would be presented as a data validation tool to a development shop, and as an end user query tool to an information center.
This knowledge could have been stored as rules of the form:
obf( 'OLE',
'OLE lets users get information in English') :-
objective(information).
This type of rule is further away from the way in which the expert's understand the knowledge. The structures are more natural to deal with, and the inference engine can be easily modified to deal with what is really just a different format of a rule.
The next key area is making sure that the products are compatible with the customer's configuration. We wouldn't want to sell something that doesn't work. For example, OLE would not run at the time on a small machine or under a DOS operating system.
unsuitable('OLE'):-
operating_system(dos).
unsuitable('OLE'):-
machine_size(small).
A good sales person will not directly attack the competition, but will use the competition's weakness to advantage. This is done by stressing those aspects of a product which highlight the competitor's weakness. That is, how can our product be differentiated from the competitor's. For example, two of Cullinet's main competitors were IBM and ADR. Both IBM and Cullinet provided systems that performed well, but Cullinet's was easy to use, so ease of use was stressed when the competitor was IBM. ADR's system was also easy to use, but did not perform as well as Cullinet's, so against ADR performance was stressed.
prod_dif('IDMS/R',
'ADR',
'IDMS/R allows specification of linked lists for high performance.').
prod_dif('IDMS/R',
'IBM',
'IDMS/R allows specification of indexed lists for easy access.').
prod_dif('ADS',
'ADR',
'ADS generates high performance code.').
prod_dif('ADS',
'IBM',
'ADS is very easy to use.').
Besides this tabular data, there are also collections of miscellaneous rules for different situations. For example, there were two TP monitors, UCF, and DC. One allowed the user to use CICS for terminal networks, and the other provided direct control of terminals. The recommendation would depend on the situation. Another example is dealing with federal government prospects, which required help with the Washington office as well. Another rule recommends a technical sales approach, rather than the business oriented sell, for small shops that are not responding well.
advice:-
not objective(production),
tp_monitor('CICS'),
online_applications(many),
nl,
advise(
'Since there are many existing online applications and'), nl,
advise(
'performance isn''t an issue suggest UCF instead of DC'), nl.
advice:-
industry(government),
government(federal),
nl,
advise(
'If it's the federal government, make sure you work'),nl,
advise(
' with our federal government office on the account'),nl.
advice:-
competition('ADR'),
revenues(X),
X < 100,
friendly_account(no),
nl,
advise(' Market database technical issues'),nl,
advise(' Show simple solutions in shirt sleeve sessions' ), nl.
Finally, the knowledge base contains a list of those items which will be obtained from the user.
competition(X):-
menuask('Who is the competition?',
X, ['ADR', 'IBM', 'other']).
computer(X):-
menuask('What type of computer are they using?',
X, ['IBM', 'other']).
friendly_account(X):-
menuask('Has the account been friendly?',
X, [yes, no]).
government(X):-
menuask('What type of government account is it?',
X, [federal, state, local]).
industry(X):-
menuask('What industry segment?',
X, ['manufacturing', 'government', 'other']).
machine_size(X):-
menuask('What size machine are they using?',
X, [small, medium, large]).
objective(X):-
menuask('What is the main objective for looking at DBMS?',
X, ['development', 'information', 'production']).
online_applications(X):-
menuask('Are there many existing online applications?',
X, [many, few]).
operating_system(X):-
menuask('What operation system are they using?',
X, ['OS', 'DOS']).
revenues(X):-
ask('What are their revenues (in millions)?',X).
tp_monitor(X):-
menuask('What is their current TP monitor?',
X, ['CICS', 'other']).
Now that a knowledge base has been designed, which has a reasonably small semantic gap with the expert's knowledge, the inference engine can be written. For the prototype, some of the knowledge is more easily stored in the inference engine. The high level order of goals to seek is stored in the main predicate, recommend.
recommend:-
qualify,
objective_products,
product_differentiation,
other_advice, !.
recommend.
First, the prospect is qualified. The qualify predicate checks to make sure there are no unqualified rules which fire.
qualify:-
unqualified,
!, fail.
qualify.
The objective_products predicate uses the user's objectives and the OBF chart to recommend which products to sell and which benefits to present. It makes use of the unsuitable rules to ensure no products are recommended which will not work in the customer's shop.
objective_products:-
objective(X),
advise('The following products meet objective'),
advise(X),nl,nl,
obf(Product, X, Benefit),
not unsuitable(Product),
advise(Product:Benefit),nl,
fail.
objective_products.
Next, the product differentiation table is used in a similar fashion.
product_differentiation:-
competition(X),
prod_dif(_,X,_),
advise('Since the competition is '), advise(X),
advise(', stress:'),nl,nl,
product_diff(X), !.
product_differentiation.
product_diff(X):-
prod_dif(Prod, X, Advice),
tab(5), advise(Advice), nl,
fail.
product_diff(_).
Finally, the other advice rules are all tried.
other_advice:-
advice,
fail.
other_advice.
For a prototype, the user interface is still a key point. The system will be looking for supporters inside an organization, and it must be easy for people to understand the system. The windowing environment makes it relatively easy to put together a reasonable interface.
Figure 11.1. User interface of sales advisor prototype
For this example, one display window is used for advice near the top of the screen, and a smaller window near the bottom is used for questions to the user. Pop-up menus and prompter windows are used to gather information from the user. Figure 11.1 shows the user interface.
The two display windows are defined at the beginning of the session.
window_init:-
window(advice, create, [type(display), coord(1,1,10,78),
border(blue:white),
contents(blue:white)]),
window(quest, create, [type(display), coord(13,10,13,70),
border(blue:white), contents(blue:white)]).
The prompt and pop-up menu windows are defined dynamically as they are needed. The ask and menuask predicates work as in other examples. Here are the clauses that interface with the user.
ask(A,V):-
window(quest,write,A),
window([type(prompt),coord(16,10,16,70),border(white:blue),
contents(white:blue)], read, ['', Y]),
asserta(known(A,Y)),
Y = V.
menuask(Attribute,AskValue,Menu):-
length(Menu,L),
R1 = 16,
R2 is R1 + L - 1,
window(quest,write,Attribute),
window([type(menu),coord(R1,10,R2,40),border(white:blue),
contents(white:blue),menu(Menu)], read, AnswerValue),
asserta(known(Attribute,AnswerValue)),
AskValue = AnswerValue.
The advise predicate uses the predefined display window, advice.
advise([H|T]):- window(advice,writeline,[H|T]),!.
advise(X):- window(advice,write,X).
One can model a fairly complex domain relatively quickly in Prolog, using the tools available. A small semantic gap on the knowledge base, and good user interface are two very important points in the prototype.
11.1 - Prototype an expert system which plays poker or some similar game. It will need to be specialized to understand the particular knowledge of the game. Experiment with the prototype to find the best type of user interface and dialog with the system.
Copyright ©1989,2000 Amzi! inc. All Rights Reserved.