Profile design
ComScript now includes its own Profile Editor that writes commands into your applications automatically so you don't have to worry about formatting and syntax problems. After reading this sections, please refer to the Profile Editor description.
The profile.xml file must contain some specific elements in a particular order. The first line of the profile must be the profile tag that has the following structure.
<profile start="10/25/2012 12:00:00" end="10/26/2012 12:00:00" interval="60" consoleoutput="true">
This line tells ComScript that the profile will begin on October 25, 2012 at 12:00:00 and end on October 26, 2012 at 12:00:00, and that it will repeat every 60 seconds. Not all of these attributes are required and other optional attributes for the profile tag are described in Commands>>Profile setup.
note: On profile and script tags, and some command lines, the xml line is not terminated with the '/' character because the operation is not concluded at the end of the line. This tells ComScript that the command or tag will be terminated later (e.g. </profile>, </script> and </if>). See individual commands for details.
Header commands (device, include and the StartUp script) appear after the profile tag. The devices that ComScript will communicate with are named and the specific communication parameters are defined with the device command (see example below). Device tags are very common in ComScript, but are not required if the profile is not in communication with any external devices. Most of the profile examples that demonstrate non-communication commands (e.g. file handling commands, date command, etc.) do not list any devices.
<device name="RelayBoard" type="serial" port="COM3" baudrate="38400" parity="None" stopbits="1" databits="8" dtr="False" handshake="None" />
Here, a serial device called RelayBoard is defined that will be connected to COM port 3 on the PC. The following attributes set COM Port 3 to match the required settings of the RelayBoard device. See COM Port configuration for more information on configuring COM ports.
ComScript also supports Internet TCP/IP communication which is very useful for communication with cellular modems or devices on a local network. Below is an example of communication settings for a cellular modem that communicates with ComScript through a raw TCP/IP internet connection. See TCP/IP communications for more information on configuring a TCP/IP Port.
<device name="TCP_cell_modem" type="tcp" port="12345" dns="GreenEyesModem.com" />
Following the device tags in the header area are import commands to include scripts from files outside of the profile.xml file. The loadvars command used to load variables from a config.xml file that will be used in the data interface also appears in the header area. It can be written into the general header space in which case each time the profile iterates (loops) it will reload initial values set in config.xml, or it can appear in the StartUp script in the header area that only runs on the first profile iteration. The correct location to load the config variables depends on whether you want the variables to load once at the start (load the config in the StartUp script) or if you want them to be reset to initial values on each profile iteration (load the config in general header area).
Examples:
<import file="SubScripts/Scripts.xml" />
<loadvars file="config.xml" type="xml" />
After the device tags, import commands, and the loading of the config.xml variables, follows the "main" script. All profiles must have a main script which is the starting point for profile execution. All scripts including main begin with the script command and end with </script> to indicate the end of the script. Execution of all scripts occurs from the top to the bottom - line numbers are not required. The main script may contain all the commands used in your profile, or calls to one or more sub-scripts (recommended). Subscripts appear below the main script in the profile.xml file and in external script files (larger projects) and can be called from any other script in your profile or external scripts in your project. The order that scripts appear has no effect on their availability to be called from other scripts in the profile and they do not need to be declared as with other more complicated languages.
Tip: It is unwise to build too many commands into any one script, particularly the main script, because debugging (diagnosing and fixing) code becomes more difficult when too many operations occur in the same place. It is also much easier to test sections of your code when it is broken down into small modules (scripts).