-   -
-   Home Page Field Missions Engineering More Info [MAP Menu]

Nets Overview

Overview

The Nets program suite is a group of tools to access and manipulate the complete electrical wiring definition for an Anderson Group experiment.

A crude list of the early steps in designing a new instrument might include:

For a number of reasons, including modularity and maintainability, most of our electrical interconnection is implemented with cables and distribution panels. The electrical interconnection is almost entirely specified by the list of signals on each pin of each connector in the experiment and the definitions of those signals.

Once the interconnect has been defined, distribution panels (DPs) need to be designed and built, computers need to be assembled and software needs to be written. Historically, each of these steps involved rote transfer of data from the connector listings, which was both time-consuming and error-prone. Changes in the design or implementation of a DP were not always fed back to the connector listings or propogated to the software. Typographical errors became enshrined in G10, and it could be difficult to determine exactly what was intended by terse signal names.

Given the central role of the connector definitions, we were motivated to develop this suite of tools in order to:

A significant portion of the DP design is specified entirely by the connector listings. By drawing the connectors automatically, the DP design is limited to designing the active circuitry.

In addition, the heart of the instrument software is also defined by the connector listings: The name and address of each analog channel is determined by the signal name and the pin of the analog board to which it is connected. The name and address of each command is determined by the signal name and the pin of the digital board to which it is connected. The connector listings can even provide a crude screen organization for use during diagnostic testing.

Finally, by using the full instrument definition, we can generate an fully-linked HTML connector database, which can allow a user to trace signals from source to destination from any computer. These listings can be kept current and consistent with the source documentation, even when the instrument is in the field.

Model

In the Nets model for electrical interconnect, and instrument's wiring is defined in terms of the following elements:

Components are connected to each other with cables. A component might be a printed circuit board or a motor or other device with one or more connectors on it. When two or more components are identical, it is useful to assign them a common component type.

Cables are defined by their connectors which in turn identify the components which the cable connects. All the connectors for a particular cable have the same "name", but are distinguished by the component to which they are connected. Hence, cable P9 may have connectors J9MDP and J9PWR.

There are some obvious limitations of this naming scheme. First, it is impossible to specify a cable that runs to two connectors on the same component. Also, you may not have the luxury of defining the connector numbers on all the components to match your instrument's interconnect. Specifically, if you are using more than one of a particular component type, each will have the same "local" connector names. For example, almost every PC board has a connector named "J1".

To resolve these two issues, we use a system of aliases. We assign appropriate global names to the cable's connectors, then record the local designation as an alias. For example, if cable P8 runs from J8 on the MDP to J1 on component "C", we could specify the cable as consisting of connectors J8MDP and J8C, where J8C has the alias J1C. In the case of a cable between two connectors on the same board, say P7 running between J7MDP and J7A:MDP, we'd list J7MDP and J7MDPA with the alias J7A:MDP. Note that we've created a fictitious component "MDPA".

Signals are the names for electrically connected wires. Technically signal names are local to each component. The relationships between signals on different components is defined by the cabling. The Global Interconnect procedure identifies which local signals are electrically connected, groups these signals together and assigns them an appropriate global name.

Procedures

txt2ili.bat

This is the procedure which initially extracts data from the Excel spreadsheet and enters it into the signals database. The name dates from the time when the input was in the form of text files and ran under QNX, but with newer versions of Perl, this procedure can now run under Windows and use OLE to get the data direct from the source.

In addition to building the database, txt2ili performs miriad syntax and sanity checks on the data in the spreadsheet. Automatic translations are performed to remove common problems, but warnings are issued so the problems can be corrected.

Schematic Generation

After running txt2ili, drawsch.bat can use the signals database to create Viewlogic connector symbols and schematics. As with txt2ili, drawsch uses OLE to run Viewdraw and create the basic drawings. (Due to troubles with certain aspects of drawing via OLE, much of the drawing is done by writing directly to the schematic file after Viewdraw has closed it.) As such, you must be licensed to use Viewdraw and have the appropriate dongle attached to your system.

We are currently developing code to automate additional portions of the schematic drawing process, starting with drawing standardized buffer circuits for analog signals.

Global Interconnect

globalic computes global interconnections within the signals database. Prior to running this program, signals are only defined locally. globalic analyzes the cabling of the system, using the cable naming conventions to determine which components are cabled to which other components. Then it equates signals that are connected by cables.

After running globalic, the signals database is a nearly complete definition of the electrical interconnect for the experiment. Running globalic is a prerequisite for running nets2html.

HTML Generation

nets2html is the procedure that translates the signals database into HTML to be served on the web.

Software Generation

TMC software can be generated from the data in the signals database via the following procedures:

gen_tmcdefs
Generates the basic definition files:
base.tmc
Basic collected variables
dstat.tmc
Code to display status bits
daspt.cmd
Command definitions to set D/A outputs
dccc.dccc
Discrete Command definitions
scdc.cmd
Command definitions for discrete commands
gen_app
Generate complete applications for initial checkout, complete with screen definitions and doit scripts. Each screen displays all or part of a connector definition with live data on any pin that represents collected data.

Inputs

The inputs to the Nets database include a configuration file, an Excel spreadsheet, optional netlists and various libraries.

The directory which contains the configuration file is the nets project directory. Libraries are located in specific subdirectories of the project directory, as well as in a global location.

nets.ini

This file provides information specific to operating the Nets suite that may not belong in the primary database. Specifically, it identifies the location of the Excel database and the Viewlogic Project File so txt2ili and drawsch can find them.

The file consists of one or more definitions of the form <keyword>=<definition>. txt2ili reads this file and enters the definitions into the database as global variables. Any keyword can be used, but the following are currently defined:

Organization
The name of the organization. Used in HTML headers. Defaults to "Harvard University Anderson Group".
Experiment
Full name of the experiment.
Exp
Short name for the experiment
Viewlogic_Project_File
Path to the Viewlogic Project File. Needed by drawsch.
xls_file
Path to the Excel spreadsheet. Needed by txt2ili.
Components
Limits txt2ili's operations to the listed components. Can be useful early in development when many component definitions are incomplete and would generate a large volume of irrelevant warnings.
Draw_Components
Identifies components for which drawsch needs to draw connectors. (txt2ili could use this information to qualify some of its warnings.)
comp_rank
A list of components whose signal names should take highest priority when selecting global signal names.

Exp.xls: Experiment Electrical Definition Document

The master connector listing database is kept in an Excel spreadsheet. This database contains names and descriptions for electrical components, electrical signals and connectors as well as the actual connector listings. The information is basically textual, but it lends itself well to the sheets, rows and columns of the Excel format. In order to be useful to the Nets suite, the names of the worksheets and the format of the data on each worksheet must conform to specific standards.

Netlists

PADS-style netlists for existing components can be fed into the Nets system to augment or take the place of the connector listings in the .xls file. One advantage of using netlists is that the boards are manufactured from the netlists, so the definitions are somewhat more reliable. Also, the netlists contain information on internal components that the connector listings don't cover.

For any component, sym/$comptype/NETLIST is read followed by comp/$comp/NETLIST.BACK if present. In addition, the translation files sym/$comptype/NETLIST.NDC, sym/$comptype/NETLIST.NDC2 and/or comp/$comp/NETLIST.NDC are also read if present. These files provide signal name translations for signals listed in the netlists. Each line has two signal names separated by whitespace. The second name is how the signal appears in the netlist, and the first is how the name should appear in this instance. The translations are applied in the order the files are read.

Octopus-style cables can also be defined using netlists. The definition is the same as for components except that sym/$comptype is replaced with cable/$comp.

Exp.vpj: Viewlogic Project File

In order to run drawsch, you need to be licensed to run Viewlogic and have the dongle attached to your computer. In addition, you need to create a project where the drawings will be created. The project information is stored in a Viewlogic Project File, which must be identified in your nets.ini file.

Outputs




last updated: Tue Apr 3 08:30:12 2001 webmaster@huarp.harvard.edu
Copyright 2000 by the President and Fellows of Harvard College
[Home] [People] [More Info] [Research Areas] [Field Missions] [Engineering]