The Interface A Component for SEMI Equipment Data Acquisition

Licensed and Supported Software
(C) Copyright 2004, Hume Integration Software
All Rights Reserved

Introduction

Hume Integration has developed a series of high-level application components which build upon the high performance and portable architectural framework provided by the Hume Datahub and the DMH message system. The Interface A Component provides the software features needed to implement the SEMI standard Interface A for Equipment Data Acquisition (EDA). This standard is described in SEMI document PR8/3563. Interface A is designed to support the concurrent flow of equipment data to multiple host applications. In contrast, current standards for SECS-II are designed for data exchange between a single equipment and a single host.

The component software consists of prototype applications to demonstrate both the equipment and equipment client roles described in the standard, along with Tcl language source code. The source code is customized and extended in order to deploy a production application for particular equipment. The EDA component software can be integrated with a SECS/GEM interface that has been developed using any vendor's toolset or with a SECS/GEM interface developed using the Hume Datahub SDK.

Installation

For convenience, two prototype EDA applications are delivered as standalone single file applications using Starkit technology: To install these programs, simply copy the executable files to a directory of your choice such as folder on the Windows Desktop. On both applications there is a Save menu action under the File menu. This action causes multiple files of SQL statements to be written to the program's working directory in order to save the current configuration of the application. So the Save action cannot be used if the programs are running from a read-only directory such as on a DVD drive.

The terminology of client and server can be somewhat confusing with Interface A since both sides of the interface implement the HTTP server protocol to receive data from the other side, and both sides use the HTTP client protocol to initiate messages. The Equipment role is deemed the server since this side of Interface A serves process data and events to multiple clients.

For development, the EDA software extends the software base provided by the Hume Datahub SDK with new capabilities for using XML, SOAP, HTTP, and SEMI standard EDA messages. The component software also uses other packages found in the Hume Datahub SDK that are optionally installed. If you use the Hume Package Installation tool to install the EDA component, you are guided in selecting the needed prerequisites. The following software packages are needed:

Demonstration Applications

The standalone applications, edaequip and edaclient, can be used to demonstrate, exercise, and/or test various aspects of the Interface A standard for Equipment Data Acquisition. The edaequip application can be configured to concurrently operate with any number of clients. Menu functions are provided to initiate sending all of the basic EDA message types to the clients. The edaequip application is able to receive and process all standard EDA messages initiated by the client including those for Data Collection Plan management. The data exchanged and diagnostic status information can be displayed and optionally saved to files. The server's configuration including the names of Data Collection Plans can be saved and re-used in future sessions.

The edaclient application is designed to initiate messages to a single equipment instance at a time. You are expected to run multiple instances of the application, typically on multiple computer systems, to exercise the equipment's ability to support multiple simultaneous clients. Because the edaclient receives messages through an HTTP interface, it can actually receive EDA messages from any number of equipment servers simultaneously. So it is possible to use a single instance of the edaclient application, and in sequence activate Data Collection Plans with multiple equipment instances, and then collect the resultant data messages at the single edaclient instance.

As described in the standard, SEMI envisions that equipment supporting Interface A will also support a SECS interface. The two kinds of equipment interfaces are not necessarily interdependent - there is no need to deploy a SECS interface in order to have a fully functional Interface A. We think that there are situations where deploying only Interface A without a SECS interface makes sense, and the vision of Interface A only existing as a complement to the SECS interface will be revised. Opinions aside, the demonstration programs feature Interface A capability without SECS interfaces. The programs are intended to inspire confidence in the evaluator that Interface A technology is tangible, and that well designed, working software tools to deploy the new standard are available from Hume Integration Software. For the equipment provider, the Hume developed Interface A server software can be integrated into a controller system which may feature a SECS interface based on any software tools, not just the SECS/GEM software available from Hume. For the equipment integrator, the Hume developed Interface A client software provides all of the needed integration elements including HTTP protocol support, a full-fledged XML parser, and connectivity solutions for a wide variety of programming environments across various operating system platforms.

The Edaequip Application

You can start running the equipment server application without any prior configuration or command line arguments.  If you have used the Save menu action in a prior session, the program starts with the configuration that was previously saved.  When you first start the program, two windows are created.  The larger window that appears on top is a user interface for the EDA Equipment Server functionality.  It has fields to configure the Interface A properties and also features displays of exchanged EDA messages and status information.  The smaller window which starts iconified is a user interface for the Hume Datahub features.  It is not necessary to interact with this smaller window except when shutting down the program.  Closing the large EDA window does not stop the execution of the EDA interface or exit the program.  This behavior demonstrates that the EDA software can be used with or without the Hume written user interface.  The program exits when the smaller Datahub window is closed.

The edaequip program embeds a functional HTTP (web) server.   If you configure an actual directory name for the httpd root directory, that directory and its contents are served by the web server and can be browsed by standard web browsers from anywhere on your network.  Its ok to configure a non-existent directory for the httpd root directory to avoid serving real files; the EDA interface will still function.  In most cases you will not configure the httpd interface value - the entryfield is usually left blank.  If you have multiple network cards, you can choose which network interface to serve by specifying its hostname or IP address as the httpd interface value.  You can also configure the httpd interface to the special value localhost.  The localhost hostname makes the EDA server interface visible only to software running on your own computer system, and your system will not be reachable from the network.

An important web server parameter is the httpd port integer value.  The value 80 is the default for the HTTP protocol. A particular port can be used by only one server at a time. In other words, unique port values need to be assigned to every TCP/IP socket server on a computer system. There is no problem having multiple instances of servers running as long as they serve unique ports. Application software is usually assigned port values greater than 1024 to avoid conflicts with system software. You will not be able to use the value 80 if you do not have system level privileges on the computer system.  In that case, it is recommended that a value greater than 5000 be used after examining the /etc/services file or reviewing the output of the operating system netstat command for possible conflicts.

The web server feature in not enabled until you press the Enable button.  This gives you a chance to configure a suitable directory and port before going online.  An Interface A client connects to your web server by specifying a URL that appears to be a document reference.  You are able to specify an arbitrary document name for the Url Document configuration value; the default value is EDA.xml.  When you press the Enable button, the status field labeled Served Url located just below the button shows the actual served URL that the client can use to connect to your EDA server instance.  You may change the httpd root directory, the httpd port, or the Url Document at any time by editing the field values and then pressing the Enable button again to have your new values take effect.  The change is nearly instantaneous.

Interface A has the notions of To and From address designations in the EDA message headers.  For both the edaequip and the edaclient program, you are able to configure unique values used as your own From address when initiating messages.   Unless you have a reason otherwise, we suggest you configure these fields to be the URL value that is used to connect to your program instance.  In fact, if you delete the current value so that the field is blank, the value gets set to your URL value when your HTTP server interface is enabled.

The edaequip user interface also provides entry fields to configure the data items making up the Equipment ID structure, namely Supplier, Model and ImmutableID.  From the standpoint of the current software, these are just arbitrary strings that are passed in messages.

The edaequip application implements the simple retry behavior specified in the standard when it is not able to successfully transfer a message to a client.  HTTP is a synchronous protocol; there is a reply expected in response to every message sent.  The Reply Timeout is the interval of time allowed for a client response to be received successfully.  If a response is not received, the logic will attempt a resend after delaying for the configurable Retry Interval value.  There is also a Retry Max Attempts integer value that is configured to set the number of attempts to be used when failure is encountered.  You are able to specify different values of these timeout and retry parameters for each client, or you may specify that the shared default values are used for a client by setting that client's values to the special value 0. The configured values in the framed window labeled Default Sending Configuration are the values used as default values for all clients that do not have their own non-zero configured values.

EDA Event Data messages have a Locator data element which is intended to help identify the context of the data.  You are able to configure the Locator data element using the entryfield labeled Event Location.

For demonstration purposes, the edaequip application relies on manual configuration of a set of Data Collection Plans.  The program logic creates example plan names if you have not configured and saved your own set.  A real Interface A application is integrated with the equipment controller(s) and the list of defined Data Collection Plans is determined programmatically.  The standard EDA messages do not show the client descriptions of the defined plans - the client only sees the plan names.  Also, the standard message definitions cannot properly handle plan names that imbed white space.

The main part of the edaequip user interface is a tabbed notebook window.  If the mouse selection button is clicked on the tab labeled Clients a different window pane is shown where the configuration of clients is displayed in a table.  New client records can be added by pressing the Add... button.  The To Address of each client record must be unique because this is how the clients are distinguished when client messages are received.  An implication of this behavior is that you must configure each client application instance to have a unique header From Address in order to have them all successfully communicate with your edaequip instance.  You can optionally specify a proxy host and proxy port if these are needed to reach the client HTTP server for messages initiated by the edaequip.  The editing dialog allows you to choose either the ok or disabled state value for a client.  If the state value is set to ok, it means that messages can be sent to the client.  If the state value is set to disabled it means that the logic should not attempt to send any messages to the client.  You cannot configure the state values of busy or down.  These values are set by the running software to manage sending to the client.  The state of down is assigned after the retry and timeout periods have been exhausted when attempting to send a message.  The logic does not attempt to send further messages to a client whose state value is down.  The client remains in the down state until that client has sent a message to the server, or until the user has reconfigured the client state value.

If you wish to save the current server configuration, use the Save menu action under the File menu.  Your configuration will be saved as files of SQL statements in the current working directory.  A saved configuration is loaded  automatically at the next program start.

The edaequip has other features to vary the displayed trace data of messages sent and received, or to save the displayed data to the file system.  There are also menu items to send example messages to clients.  You are encouraged to explore these features.  The EdaEnabled, EdaDisabled, and EdaError messages are broadcast messages - they are sent to every client that is not down or disabled.  The other message types are sent to a single selected client.
 

Host/Client Application

The execution and runtime configuration of the edaclient application is quite similar to that of the edaequip application.  You do not need to perform any configuration or know any command line arguments before starting the program.  With the client application, there is only a single EDA user interface window created, and when this window is closed, the application exits.

The entryfields in the window frame labeled Equipment Target Configuration are used to specify the Url and other items for your chosen EDA server.  Before you press the Enable button to have your HTTP server go online, you will need to review the configuration of the httpd port and make sure it is a unique and acceptable value, and make sure that you are satisfied with the other web server parameters.
 

Interface A Development

The EDA software is composed of a small number of Incr Tcl classes. You can develop custom applications by deriving new classes that have selected methods replaced by your logic, as well as having additional methods. You can use the Hume DMH message system to control and utilize your classes from another application process through the exchange of DMH messages. You do not need to use Tcl/Tk to provide a user interface. You can deploy a user interface using the software tools of your choice, and use the DMH message system to interact with the Incr Tcl classes for their non-visual Interface A functionality.

Here is an overview of the classes, the class names are linked to detailed information.

eda
The eda class is comprised of software that is common for both the equipment and the equipment client roles. For example, parsing XML and using an httpd server are done by both roles.
edaequip
The edaequip class has the logic needed to deploy the EDA equipment role. The class uses in-memory SQL tables to manage multiple clients.
edaclient
The edaclient class is designed to communicate with EDA equipment and play the client (host) EDA role.
Edatrace
This class provides the aggregate GUI widget that displays trace information in two scrolled text fields, one for Send & Reply tracing, and one for Receive tracing. The colors and fonts used are all configurable. The widget also provides the ability to save the displayed information to the file system.
ehttp
The ehttp class is used to execute the client-side of the HTTP protocol, either version 1.0 or 1.1. The class has diagnostic and tracing features that the EDA software makes use of.
ehttpd
The ehttpd class is used to provide the server-side of the HTTP protocol. It can serve common file types such as HTML pages and image files. The class has a URL callback feature that enables having custom software such as the EDA software provide the data of a requested document. The class also has excellent tracing and diagnostic features to support embedded use.


Incr Tcl Class Reference



eda -  A base class for equipment or client EDA

Synopsis

none - instantiate edaclient or edaequip instead
Description
This is a base class that has data and methods which are used for both the EDA server and client roles.
Options (Public Variables) Class Methods

edaclient -  The Interface A Equipment Client (Host Role) Class

Synopsis

package require edaclient
edaclient::supervisor
edaclient objname [-option_name option_value]*
objname methodname [method_argument]*
Description
This class is designed to target a single equipment URL at a time playing the Interface A client (host) role. You can have multiple instances of the class running in the same Tcl process to target multiple equipment instances simultaneously. The edaclient class inherits from the eda class so the options and methods of the eda class are useable for an edaclient instance.
Options (Public Variables) Class Methods

edaequip -  The Interface A Equipment class

Synopsis

package require edaequip
edaequip::supervisor
edaequip objname [-option_name option_value]*
objname methodname [method_argument]*
Description
This class is used to provide the equipment role of SEMI Interface A. To integrate this software into a production application, pay particular attention to the methods whose names start with ii_. This prefix has the meaning of integration interface. By coding your own version of these methods, you will make your equipment respond to the commands that are received through Interface A. In addition, you will need to provide for sending data and event messages as determined by the activated Data Collection Plans. The methods whose names begin with eg are examples of creating different EDA message types that equipment inititates. The example application edaequip is able to send an example message of every currently defined EDA type. The method broadcast is used to send the same message to every client. Certain EDA message types are broadcast such as the EdaEnabled message. The method postmsg is used to send an EDA message to a single client. As long as a client's Data Collection Plan is still active, your equipment should continue to post data messages selected by the plan. If the client becomes unresponsive, all of his activated plans will be deactivated. This occurs after a series of retry attempts spanning a series of waiting periods, so it is common that there may be more than one data message queued for delivery to the client. Your logic will know to stop posting messages for a plan from any of the following inputs:
  1. The plan is no longer listed in the eda_client_active_dcp table so it was deactivated. Your logic could know this by querying the table at the time of sending, or by subscribing to changes in the table data.
  2. You have customized the ii_DeactivatePlan method and your logic was executed when the method was invoked to deactivate the particular plan for the particular client.
Options (Public Variables) Class Methods

Edatrace -  A Tk GUI widget to display EDA trace information

Synopsis

package require eda
Edatrace objname [-option_name option_value]*
objname methodname [method_argument]*
Description
The Edatrace class is used to create the trace information display widget that is a prominent feature of the GUI in the edaequip and edaclient applications. The widget combines two scrolledtext widgets with some buttons to enable saving and managing the trace display. Most of the options for the scrolledtext widget are also options for this widget, which allows you to easily customize colors and fonts.
Options (Public Variables) Class Methods

Table Schema

The EDA component software uses high-performance in-memory SQL tables. This capability is part of the Hume Datahub toolset. Relational database tables are an ideal software mechanism to manage multiple EDA client connections and their dynamically associated data such as the activation of various Data Collection Plans. The tables are described in alphabetical order.

eda_client Table - Basic client data

This table is used by the equipment server logic to manage basic client information such as the URL used to communicate with the client.
 
Column Name Key Type Description
client_id PCK varchar(32) A unique value which is assigned as a shorthand identifier for the client. The stock edaequip application assigns sequential values starting with 1000 to newly discovered clients. 
comment   varchar(120) This field is for manually entered text that can help to identify and manage the client
url   varchar(120) A URL specification for the document name that is used to communicate with the client, such as http://ELVIS:8015/EDA.xml
to_address   varchar(120) Per the standard, the client software has a To message header item. This item is determined by the client; the equipment specifies the address in messages to the client.
proxy_host   varchar(120) In some deployments HTTP communication with the client must be performed using a proxy host. The proxy_host field value should be left as an empty string when direct communication without a proxy is wanted.
proxy_port   integer A non-zero value should be set when HTTP communication through a proxy port is needed.
send_state   varchar(10) This field is used to help manage sending messages to the client. The following values are used:
  • ok the client is believed to be online and ready to receive. Sending messages to this client is enabled.
  • busy the software is currently in the process of sending or attempting to send a message. There may be multiple messages that are queued for sending to this client.
  • disabled The client has been manually configured to this state so that the software will not attempt to send messages to the client.
  • down There has been an error return or timeout result and the retries have been exhausted. There will not be further attempts to send to this client.
  • new The software has encountered communication with a client where the message header value does not match any of the current values in the to_address field. In this event, a new record is added to the table. This record is not used for sending until the value is configured to ok.
ts_last_response   varchar(26) This field is updated after every successful send to the client. The value can be used to identify client records that are no longer in use, and to confirm proper operation.
reply_timeout   integer A non-zero value in this field overrides the default time interval in milliseconds allowed for receiving the client's reply to a message.
retry_max   integer A non-zero value in this field overrides the default number of retry attempts allowed to successfully send a message and receive a reply.
retry_interval   integer A non-zero value in this field overrides the default time interval in milliseconds that the software waits in the wake of a failed attempt before initiating another send.

eda_client_active_dcp Table - Activated Data Collection Plans

This table is used by the equipment server logic to track which Data Collection Plans have been activated by the clients using the EDA ActivatePlan message. The DeactivatePlan message causes the deletion of the corresponding table row.
Column Name Key Type Description
client_id PCK varchar(32) The shorthand identifier for a particular client.
dcp_id PCK varchar(32) The identifier for a particular Data Collection Plan.
persistent   integer This field is used as a boolean flag with values of 1 or 0 to indicate whether the client indicated that plan activation should persist until explicitly deactivated. If the value is 1, the client set the UntilDeactivated argument in the ActivatePlan command message true.


eda_client_startup Table - Configuration of Client startup instances

This table is used by the edaclient application, not by the equipment server logic. The edaclient application has the ability to automatically start multiple EDA Equipment client instances at startup. The default data creates a single client instance with an interactive GUI (Graphical User Interface), and the safer behavior of not going online to receive messages or send messages until commanded. At startup, the table data is read from the file of SQL statements named eda_client_startup.tab. You can change the startup behavior of the edaclient application by editing this file. If you develop a custom client application using the edaclient class, you do not need to configure data in this table unless you call the edaclient::supervisor method.
 
Column Name Key Type Description
objname PCK varchar(20) A unique name to be used for the client object. This is the name of an Incr Tcl object of the class edaclient.
auto_start   int Used as a boolean with the value 1 or 0 to determine if the client instance should be instantiated when the edaclient application starts.
auto_enable   int Used as a boolean with the value 1 or 0 to determine if the HTTP server interface should be started when the client instance is instantiated. If the HTTP server interface is started then receiving messages from the equipment is enabled.
auto_start_gui   int Used as a boolean with the value 1 or 0 to determine whether the edaclient::tracewin should be called when the client instance is instantiated in order to create and show the Tcl/Tk GUI.
httpd_addr   varchar(80) This field corresponds to the httpd interface selection seen on the edaclient GUI.You can optionally specify which network interface should be served either as a TCP/IP hostname or as an IP address. Use this option to specify the desired interface when you have more than one TCP/IP network address, or you want to restrict the serving to your own system by specifying localhost. When the field is blank, the default behavior is operating system dependent but usually makes the server visible on the first TCP/IP network interface and on the localhost interface. For some operating systems, the served port is reachable on all network interfaces. 
httpd_doc   varchar(80) This field is for the document name that the client serves. It becomes the last part of the URL that is configured at the equipment to communicate with the client. The name has to be useable and proper as a file name, but there does not have to be an actual document of this name on the file system.
httpd_port   int This field holds the TCP/IP port value that the client uses to receive EDA messages. The value 80 is the default for the HTTP protocol. A particular port can be used by only one server at a time. In other words, unique port values need to be assigned to every TCP/IP socket server on a computer system. There is no problem having multiple instances of servers running as long as they serve unique ports. Application software such as the edaclient is usually assigned port values greater than 1024 to avoid conflicts with system software. 
httpd_root   varchar(100) The root of the file system to be served by the edaclient HTTP server. A non-existent directory can be named if you do not wish to serve documents. Do not specify a directory containing private data files.
eq_autofix_config   int Used as a boolean flag to indicate that the Equipment target URL, header address, and EquipmentID values configured for the client should be revised with actual values received from messages sent by the equipment.
eq_reply_timeout   int The time interval in milliseconds to allow for successfully receiving a reply message from the target equipment.
eq_SupModID   varchar(300) A Tcl formatted list of the EquipmentID Supplier, Model, and ImmutableID items for the target equipment.
eq_To   varchar(100) The message header element used as the To value when sending a message to the target equipment.
eq_url   varchar(300) The URL used to initiate HTTP communication with the target equipment.
TRACE   int An integer value used as a bitfield to control the amount of trace information displayed during communication with the target equipment. See the documentation for the edatrace class for details.


eda_datacoll_plan Table - Data Collection Plans

The default equipment server logic and the example application use this table to determine which Data Collection Plans are defined. It is expected that for a real application the developer replaces the ii_GetDefinedPlanIDs and the ii_IsDefinedPlan methods with similar methods that reference a table of the user's own design, or interact with the equipment through some other API.
 
Column Name Key Type Description
dcp_id PCK varchar(32) An identifier for the Data Collection plan - same as the PlanID argument in relevant EDA messages. The value ALL should not be used because the standard uses this value to indicate all of the plans. The value should not contain embedded spaces since the EDA standard uses space characters to delimit list items.
description   varchar(80) An optional description for the plan. The current standard does not allow for passing a description or any other plan metadata such as author or version. 


eda_schema Table - Table schema descriptions

This table is intended to hold descriptions of the SQL tables and columns so that the schema can be referenced during interactive development, and a schema description document can be generated programatically.
 
Column Name Key Type Description
tablename PCK varchar(32) The name of the SQL table.
colname PCK varchar(32) The name of a table column.
description   varchar(1000) Documentation for the particular table column.


eda_send_log Table - Logging of sent EDA messages

This table is used by the edaequip server logic to show the status of messages that have been successfully sent or where sending has ended in failure after exhaustion of any retries.
 
Column Name Key Type Description
client_id PCK varchar(32) Identifies the client record in the eda_client table.
ts_send PCK varchar(26) A high resolution timestamp in the UTC timezone is assigned to identify the message when sending is first initiated. See the localtime 16 description.
elapsed_secs   float This floating point value indicates the time interval in seconds that has transpired between the initiation of sending and the successful receipt of a reply, or the exhaustion of retries.
msgtype   varchar(32) The message type tag such as EdaEnabled or EdaData.
msglen   int The number of characters in the EDA message. This value is the length of the transmitted HTTP content and does not include the HTTP header information.
http_rc   int The HTTP protocol return code if the send-and-reply got far enough to get a return code. The value of 200 is the usual successful result. A value such as 404 ("File not Found") may indicate a configuration error.
try_count   int This value shows how many tries were attempted before success or retry exhaustion.
status   varchar(80) The value success is used for the usual successful result, otherwise a short failure description is found. More detail is available by using the trace window features.


eda_send_Q Table - In process EDA messages

This table is used by the edaequip server logic to queue and manage EDA messages that are in the process of being sent to clients.
 
Column Name Key Type Description
client_id PCK varchar(32) Identifies the client record in the eda_client table.
ts_send PCK varchar(26) A high resolution timestamp in the UTC timezone is assigned to identify the message when sending is first initiated. See the localtime 16 description.
msgtype   varchar(32) The message type tag such as EdaEnabled or EdaData.
ehttp_token   varchar(24) A token value returned from the ehttp command which identifies state data associated with sending the message.
try_count   integer This field is used to keep track of the number of attempts being used to send the message.
content   varchar(80000) The complete text of the EDA message being sent.


eda_server_startup Table - Configuration of edaequip startup instances

This table is used by the edaequip application to configure the number and properties of equipment server instances. You can manually configure the startup of multiple equipment server instances.
 
Column Name Key Type Description
objname PCK varchar(32) A unique name to be used for the object. This is the name of an Incr Tcl object of the class edaequip.
auto_start   int Used as a boolean to specify whether the table record should be instantiated as an Incr Tcl object when the application starts.
auto_enable   int Used as a boolean to specify whether the httpd receiving interface should be enabled when the edqequip object is instantiated.
auto_start_gui   int Used as a boolean to specify whether the Tcl/Tk GUI for the object should be created and displayed when the object is instantiated. The GUI is created by calling the tracewin method of the edaequip class.
eq_From   varchar(120) Per the EDA standard, the equipment has an address header element which can be configured. If the value is left as an empty string, the logic uses the equipment's URL for this item.
httpd_addr   varchar(80) This field corresponds to the httpd interface selection seen on the GUI.You can optionally specify which network interface should be served either as a TCP/IP hostname or as an IP address. Use this option to specify the desired interface when you have more than one TCP/IP network address, or you want to restrict the serving to your own system by specifying localhost. When the field is blank, the default behavior is operating system dependent but usually makes the server visible on the first TCP/IP network interface and on the localhost interface. For some operating systems, the served port is reachable on all network interfaces. 
httpd_doc   varchar(80) This field is for the document name that the equipment serves. It becomes the last part of the equipment's URL. The name has to suitable for use as a file name, but there does not have to be an actual file so named.
httpd_port   int This field holds the TCP/IP port value that the equipment uses to receive EDA messages. The value 80 is the default for the HTTP protocol. A particular port can be used by only one server at a time. In other words, unique port values need to be assigned to every TCP/IP socket server on a computer system. There is no problem having multiple instances of servers running as long as they serve unique ports.
httpd_root   varchar(100) The root of the file system to be served by the edaequip HTTP server. A non-existent directory can be named if you do not wish to serve documents. Do not specify a directory containing private data files, or having private files in any subdirectory.
Locator_default   varchar(200) Certain EDA messages have a Locator value. This field is used to configure a default value for the Locator item.
log_period   int The log_period is a configurable interval of time specified in milliseconds for completed messages to be held in the eda_send_log table. There needs to be a provision for deleting aged messages from this table so that memory usage remains bounded. The edaequip application does not delete logged messages, it is designed for the user to delete them by pressing a button on the GUI. A real application needs to have programmed deletion of the logged messages.
reply_timeout_default   int This value represents the time interval in milliseconds that is allowed for successfully receiving a reply from a client. The value is a default value that is used unless there is a non-zero configured value for the particular client.
retry_interval_default   int This value represents the time interval in milliseconds that the equipment waits before initiating another send attempt when the previous send has failed. The value is actually a default value that is used when there is not a positive value configured for a client.
retry_max_default   int This value is the maximum number of times the sending logic will retry to send a message to a client. The value is a default that is used if there is not a positive value configured for the client.
Supplier   varchar(80) This field holds the configured value of the Supplier item in the EquipmentID data structure.
Model   varchar(80) This value is for the corresponding item in the EquipmentID data structure.
ImmutableID   varchar(80) This value is for the corresponding item in the EquipmentID data structure.
TRACE   int An integer value used as a bitfield to control the amount of trace information displayed during communication with clients. See the documentation for the edatrace class for details.

Document Version

Date of last revision: $Date: 2004/07/06 14:20:10 $

This document covers the Hume Integration Software developed Interface A Component which is available for the Tcl 8.4/Tk 8.4 environment on the Windows XP/2000 and UNIX/POSIX platforms.