Client Start Command Line Options
|/Dx||Start the server in debug level "x", where "x" is 1,2,3,4, or 5. The higher the number, the more detail that is logged.|
|/L||Start a local instance of the server components. This is the default mode of operation (hence using this switch is a bit redundant...).|
|/Qxxx.xxx.xxx.xxx||Connect to a remote instance of server components at IP xxx.xxx.xxx.xxx. Note there is NO SPACE between the "Q" and the IP.|
|/Pxxxxxxxxxx||Use Profile name "xxxxxxxxx", bypassing the profile prompt popup. You cannot summon a profile with spaces in it from the command line. Again, note no space.|
|/Annnnn||Connect to remote ProShip server on TCP port nnnnn instead of the default (3300). Again, note no space.|
|/S||Suppress server warning messages during client startup.|
|/M||Enable debug mode messages (DMsgBox and DSBNote)|
|/U||Save cache information in the local user directory for Terminal Services deployments Normally located in C:\Documents and Settings\[username]\AppData\Roaming\PROSHIP\CACHE\
(published apps in server farms will be located in the master)
|/N||Disable all ProShip Velocity scripts during startup. Please note this could have unintended consequences!|
The XML documents used within
There are three main XML documents in the ProShip GUI- the System Document, the Shipment Document, and the Shipment History Document. Understanding what each one does, and how it changes during operation is critical to a proper installation.
- The System Document contains all the configuration and behavior options of the client. It is built dynamically at each startup from several smaller XML files. Some are local files (allowing multiple network workstations, each with a different configuration) and some are global to the installation (such as carrier service lists). The System.xml can be viewed in the client by going to Configuration -> Debug -> System XML.
- The Shipment Document contains all the information and configuration of the current shipment. This information is either manually entered by the user through the ProShip Velocity client or scripted to load from a datasource. The Shipment Document is cleared out at the completion of each shipment or when the Reset object is instantiated. The Shipment.xml can be viewed at any time during the shipment in the client by going to Configuration -> Debug -> Shipment XML.
- The Shipment History Document contains a collection of Shipment Documents of recently shipped packages from that specific client station. Configuration options concerning the Shipment History Document can be found on the ProShip Velocity client under Configuration -> General -> History tab. The file can be found under C:\Program Files\ProShip\CLIENT\CACHE\DEFAULT\SH_HISTORY.XML. The Shipment History Document is only used for the History panel in the client.
The default client installation does not install any XML files. The client will look for the appropriate XML files, and if it doesn't find them, will automatically download them from the server. This allows the administrator to define a "template" that will be automatically applied to new clients. If a file gets corrupted, you will get a "file import failed, do you wish to download a new copy from server?" message. If you choose to download, and receive the same message, this means the server's copy is corrupted and needs to be fixed.
Any updates to the disk files will not take effect until next restart; some files (such as CONFIG.XML and FORMS.XML) will be overwritten by changes made to the client upon exit.
The client will cache these files locally (in C:\Program Files\ProShip\CLIENT\CACHE\DEFAULT), and subsequent startups will only download system-wide files (as noted below by an asterisk ("*")) if the server contains a newer copy (as determined by the previous server time stamp and the server's current time) only. You may force an unconditional download from the "Startup" tab in general configuration.
|BW.XML||Contains a list of rate-shop groups and manually rated carriers. Defined and changed by user.|
|COMMITMENTS.XML||Contains a list of carrier delivery commitment times. Each engine that can offer time-in-transit commitments does so in 10 minute increments; this file translates this to a user-readable value.|
|CONFIG.XML||Dynamic file containing most miscellaneous parameters used for client behavior, operation, and configuration. File is downloaded from server when not present on client; client changes are saved locally and not overwritten from or propagated back to server. Changes to the server's copy will overwrite local copies, potentially causing unintended effects.|
|COUNTRIES.XML||List of the defined countries of the world as per the ISO 3166 standard.|
|CUSTOMLABELS.XML||Defines any user defined labels/documents present on the system.|
|DEVICES.XML||Static set of device parameters used in communicating with scales, scanners, dimensioning equipment, and other specialty hardware as well as printer attributes used to correctly format labels and reports generated by server engine for different printing engines.|
|ENUMS.XML||Static set of enumeration constants used to map numerical symbols used inside a rating engine to the plaintext terms shown on the client screen.|
|FORMS.XML||Dynamic file containing lists of all forms and the fields they contain. Client changes are saved locally and not overwritten from or propagated back to server. Changes to the server's copy will overwrite local copies, potentially causing unintended effects.|
|LABELCONFIG.XML||Dynamic file containing all active documents, where and how they are being printed to. Client changes are saved locally and not overwritten from or propagated back to server. Changes to the server's copy will overwrite local copies, potentially causing unintended effects.|
|MASTER_SH.XML||Dynamic list of shipment attributes and their properties. Defaults created at installation. Client changes are saved locally and not overwritten from or propagated back to server. Changes to the server's copy will overwrite local copies, potentially causing unintended effects.|
|SH_HISTORY.XML||Stores the Shipment History Document between instances of client operation. This document does NOT propagate from the server, ever.|
|SYSTEM.XML||Dynamic snapshot of the rating engines variables. Refreshed at server (re)start, contains all profiles, labels, etc used in server transactions. Used to translate between symbol and plaintext names.|
|TOOLBAR.XML||Contains the toolbar and menu layout customizations. Client changes are saved locally and not overwritten from or propagated back to server. Server copy does not propagate to client unless the local copy is corrupted or missing, even if newer.|
|UoMs.XML||Lists the units of measure for international documentation.|
The Shipment Document, initially blank, is what is sent to the server for transactions such as rate and ship. Some transactions, including, but not limited to, search, void, closeout, and transmit send a request not based on the Shipment document. The top-level node must be named "SHIPMENT", and most engines will look for three levels of child nodes: a single COMMON node (holds elements that apply to any and all boxes in the shipment), one or more PACKAGE nodes (holds elements that may vary in a multiple part shipment, such as weight), and a single SERVICE node (the service or best way group for the transaction). Most engines with international capabilities will look for a INTERNATIONAL node as a child off PACKAGE or COMMON containing one or more LINE child nodes, each containing information about the commodities in a shipment. See engine documentation for specifics.
It is only required to have an entry for a corresponding node in the Master Shipment XML file if the field is to be used on a GUI form- you can create any set of nodes you (or an engine) needs dynamically in code. In general, however, developers are encouraged to take advantage of the flexibility to add fields not used by the carriers (like picker or packer, for instance);however, it is not advisable to add huge numbers of entries to the Shipment structure as it may slow processing by some engines or conflict with future upgrades.
Using External Devices
The scanner and electronic scale are invaluable devices to automate the shipment process. In addition to drivers for all the popular serial port scanners (keyboard wedge style scanners require no drivers) and scales that are built in, you can define a new device. The device protocols are stored in XML format in the DEVICES.XML file on the server, which is downloaded to the clients as updated; simply add another <SCALE> or <SCANNER> node, with the appropriate populated child nodes as listed below. The device engine is designed to accept input from any serial port device following some semblance of industry standard protocols.
If you are using a dimensioning equipment, RFID readers, or interfacing to a PLC, please refer to the specific addendum provided during install. The devices XML also contains printer settings. These are NOT considered "user serviceable" as options set within will have vastly different effects on different engines. Please contact ProShip support for any printing device questions.
|Scanner XPATH Expression||Description/Value|
|/DEVICES/SCANNER/SYMBOL||Scanner Internal Name|
|/DEVICES/SCANNER/PLAINTEXT||Scanner Plaintext Name|
|/DEVICES/SCANNER/DTR||Use DTR Line on Port? (0=No, 1=True)|
|/DEVICES/SCANNER/RTS||Use RTS Line on Port?|
|/DEVICES/SCANNER/HANDSHAKE||Port Flow Control (None / XON-XOFF / RTS-CTS / Both, respectively)|
|/DEVICES/SCANNER/PORT_SETTINGS||String value in the format BBBBB,P,D,S where BBBBB is the baud rate, P is the parity, D is the number of data bits, and S is the number of stop bits when communicating with the port.|
|/DEVICES/SCANNER/ETXCHAR||Hexadecimal value representing ASCII value of ETX Character. Without specification, scanner will wait the defined timeout period before parsing the weight from the response.|
|/DEVICES/SCANNER/STRIPCONTROL||If "1", remove ASCII 0,2,3,10,13 characters from the returned string.|
|/DEVICES/SCANNER/TIMEOUT||Time to wait for scanner data to be written back to the port. Specified in seconds.|
|Scale XPATH Expression||Description/Value|
|/DEVICES/SCALE/SYMBOL||Scale Internal Name|
|/DEVICES/SCALE/PLAINTEXT||Scale Plaintext Name|
|/DEVICES/SCALE/DTR||Use DTR Line on Port? (0=No, 1=True)|
|/DEVICES/SCALE/RTS||Use RTS Line on Port?|
|/DEVICES/SCALE/HANDSHAKE||Port Flow Control (None / XON-XOFF / RTS-CTS / Both, respectively)|
|/DEVICES/SCALE/ETXCHAR||Hexadecimal value representing ASCII value of ETX Character. Without specification, scale will wait the defined timeout period before parsing the weight from the response.|
|/DEVICES/SCALE/ICD||Number of seconds (or fraction thereof) to wait between characters for scales without handshaking (0=None, .25=Fine in most cases)|
|/DEVICES/SCALE/PORT_SETTINGS||String value in the format BBBBB,P,D,S where BBBBB is the baud rate, P is the parity, D is the number of data bits, and S is the number of stop bits when communicating with the port.|
|/DEVICES/SCALE/WEIGHT/OZSTART||Integer position in the scale's response where the ounce portion of a weight starts. Leave this node out if scale does decimal pounds only.|
|/DEVICES/SCALE/WEIGHT/OZLEN||Integer value representing the number of significant bytes in the weight in the scale's response of the ounce portion. Leave this node out if scale does decimal pounds only.|
|/DEVICES/SCALE/WEIGHT/START||Integer position in the scale's response where the weight starts|
|/DEVICES/SCALE/WEIGHT/LEN||Integer value representing the number of significant bytes in the weight in the scale's response.|
|/DEVICES/SCALE/COMMANDS/WEIGH||Hexadecimal representation of the ASCII value(s) sent to the scale for a weight request|
|/DEVICES/SCALE/COMMANDS/TARE||Hexadecimal representation of the ASCII value(s) sent to the scale to set tare (zero) value.|
|/DEVICES/SCALE/STATUS/POSITIION||Integer value representing the position in the scale's response for the status byte|
|/DEVICES/SCALE/STATUS/GOOD/VALUE||Decimal value of the scale's response on a "good" weigh.|
|/DEVICES/SCALE/STATUS/GOOD/MASK||Decimal mask used as a bit-wise "AND" when determining the significant bits for "good" value determination.|
|/DEVICES/SCALE/STATUS/ZERO/VALUE||Decimal value of the scale's response at tared value (zero).|
|/DEVICES/SCALE/STATUS/ZERO/MASK||Decimal mask used as a bit-wise "AND" when determining the significant bits for "zero" value determination.|
|/DEVICES/SCALE/STATUS/MOTION/VALUE||Decimal value of the scale's response when scale is unstable.|
|/DEVICES/SCALE/STATUS/MOTION/MASK||Decimal mask used as a bit-wise "AND" when determining the significant bits for "motion" value determination.|
In Velocity, click on Configuration -> Script Engine. In the lower left part of the Script Control window that opens there is a text box called "Script Timeout" with a value in milliseconds. A good rule of thumb is to initially double this value and see if the "Long Running Script" popup goes away.