ABB Ulma 3D File



ABB Ulma 3D

Single Camera Beam Systems File Interface to the PI System

Version 3.0 – 3.2.0.1

How to Contact Us

|Phone |(510) 297-5800 (main number) |

| |(510) 297-5828 (technical support) |

|Fax |(510) 357-8136 |

|Internet |techsupport@ |

|World Wide Web | |

|Bulletin Board |(510) 895-9423 |

| |Telebit WorldBlazer modem (Hayes, MNP, or PEP compatible) |

| |8 data bits, 1 stop bit, no parity, up to 14400 bps download |

| |protocols: Xmodem, Ymodem, Zmodem, Kermit |

|Mail |OSI Software, Inc. | |

| |P.O. Box 727 | |

| |San Leandro, CA 94577-0427 | |

| |USA | |

| | | |

| |OSI Software GmbH |OSI Software, Ltd |

| |Hauptstra(e 30 |P. O. Box 8256 |

| |D-63674 Altenstadt 1 |Level One, 6-8 Nugent Street |

| |Deutschland |Auckland 3, New Zealand |

Unpublished – rights reserved under the copyright laws of the United States.

RESTRICTED RIGHTS LEGEND

Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph I(1)(ii)

of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013

Trademark statement—PI is a registered trademark of OSI Software, Inc. Microsoft Windows, Microsoft Windows for Workgroups, and Microsoft NT are registered trademarks of Microsoft Corporation. Solaris is a registered trademark of Sun Microsystems. HP-UX is a registered trademark of Hewlett Packard Corp. IBM AIX RS/6000 is a registered trademark of the IBM Corporation. DUX, DEC VAX and DEC Alpha are registered trademarks of the Digital Equipment Corporation.

PI_ULMA3D.DOC

( 1999 – 2003 OSI Software, Inc. All rights reserved

777 Davis Street, Suite 250, San Leandro, CA 94577

Table of Contents

Introduction 1

Supported Features 1

PI Point Definition 3

Point Source 3

Point Type 3

Compression 3

Exception 3

Location 1 3

Location 2 3

Location 3 4

Location 4 4

Location 5 5

Software Configuration 7

IO Rate Points 7

Step 1 – PI Point configuration on the PI Server 7

Step 2 – Configuration on the Interface Node 7

PI 2 Home Node 8

Point Source 9

Digital States 9

PI 3 Home Node 9

Point Source 9

Digital States 9

Startup Command File 11

Command Line Parameters 12

NT Interface Node 13

Ulma3D.bat 13

VAX/Alpha 14

ULMA3Dstart_.com 14

15

Interface Operation 17

VAX/Alpha 17

Startup 17

Shutdown 17

NT 17

Interface Installation on NT 19

General 19

Naming Conventions and Requirements 19

Interface Directories 20

The PIHOME Directory Tree 20

Interface Installation Directory 20

Setting the Interface Node Clock 20

Security 21

Interface Installation Procedure 21

Installing the Interface as an NT Service 21

Configuring the Interface to Start and Stop with PI 22

Interactive Process 23

Service 23

Buffering on the PI Server Node 24

Installation Checklist NT and VMS 27

Appendix A: Tag Attributes 29

Appendix B: Digital State Sets 35

Appendix C: Defect File Format Description July 03, 1996 37

Appendix D: Defect File Format Description January 20, 1998 43

Appendix E: Defect File Format Description Unknown (Tappi reel number format) 49

Revision History 55

Introduction

The ULMA 3D File Interface to PI is designed to read defect files produced by the ABB ULMA Single Camera Beam System and enter the data into the PI System from OSI Software, Inc. The interface runs on a DEC VAX (VMS) or DEC AXP (Open VMS) or Intel NT (NTI).

The interface has been written to read files as described in the ABB Defect File Format Description dates July 03, 1996 and January 20, 1998. The formats are in the appendix.

WARNING: If your files do NOT match exactly one of the file descriptions in the appendices, the interface will need to be rewritten for your site. You should contact OSI with a file description and sample files before ordering this interface.

The Ulma3D interface requires PI version 2.11 or greater.

Supported Features

|Feature |Support |

|Part Number |PI-IN-ABB-UL3D-AXP |

| |PI-IN-ABB-UL3D-NTI |

| |PI-IN-ABB-UL3D-VAX |

|Platforms |VMS / Alpha VMS / NTI (4, 2000, XP) |

|PI Point Types |PI 2: R / I / D |

| |PI 3: float16 / float32 / int16 / int32 / digital |

|Sub-Second Timestamps |No |

|Sub-Second Scan Classes |No |

|Automatically Incorporates PI Point Attribute Changes |Yes |

|Exception Reporting |Yes, but not recommended |

|Outputs from PI |No |

|Inputs to PI: Scan-Based / Unsolicited / Event Tags |Scan-based |

|Maximum Point Count |None |

|Uses PI-SDK |No |

|PINet to PI 3 String Support |No |

|* Source of Timestamps |Device |

|* History Recovery |Yes |

|Failover |No |

|* UniInt-Based |Yes |

|Vendor Software Required on PI-API / PINet Node |No |

|* Vendor Software Required on Foreign Device |Yes |

|Vendor Hardware Required |No |

|Additional PI Software Included with Interface |No |

* See paragraphs below for further explanation.

Source of Timestamps

The timestamps for the data come from the device. Data that applies to the entire reel, i.e. the reel number, grade, etc. uses the start time of the reel as the timestamp. Defect data is timestamped with a time between the start and end times of the reel.

History Recovery

The interface reads files which are not deleted until they have been processed.

UniInt-Based

UniInt stands for Universal Interface. UniInt is not a separate product or file; it is an OSIsoft-developed template used by our developers, and is integrated into many interfaces, such as this interface. The purpose of UniInt is to keep a consistent feature set and behavior across as many of our interfaces as possible. It also allows for the very rapid development of new interfaces. In any UniInt-based interface, the interface uses some of the UniInt-supplied configuration parameters and some interface-specific parameters. UniInt is constantly being upgraded with new options and features.

The UniInt End User Document is a supplement to this manual.

Vendor Software Required

The user must ensure that the defect files are transferred from the Ulma3D to the interface computer. This is typically done using FTP.

PI Point Definition

The following information is necessary for defining a PI point to uniquely identify a defect characteristic. In some cases there is a one-to-one correspondence between a line from the defect file and a PI tag. In other cases, a combination of lines is required to define the tag.

Point Source

A separate point source character is required for every instance of the interface. It should be defined as a single character not used by any other PI process. If the PI home node is a PI 2 system, the point source must have been previously defined in the point source table. If the PI home node is a PI 3 system, the point source character must not be used elsewhere.

Point Type

This interface supports each of the point types on a PI 2 server, real R, integer I, and digital D. It also supports digital, int16, int32, float16, and float32 on a PI 3 server.

Compression

It is suggested that compression be turned off for all tags associated with this interface.

Exception

It is suggested that exception reporting be turned off for all tags associated with this interface.

Location 1

The line numbers should be entered in location 1 to determine which data to extract from the file. Note that there is NOT always a one-to-one correspondence to the file itself.

For more information, see “Appendix A, Tag Attributes” on page 6.

Location 2

This field determines the output device to which the defect is reported. Each device requires its own digital tag. Enter the bit number in this field. Create a two-state digital state set (OFF/ON or NO/YES or NOT SENT/SENT) for these tags

This location is checked when location 1 refers to an output bit mask, i.e.: only if location 1 is 71, 117, or 118.

|Bit |Device |

|0 |Color Marker 1 |

|1 |Color Marker 2 |

|2 |Light Panel |

|3 |Audible Alarm |

|4 |Defect Map |

|5 |Reel Report |

|6 |Computer Interface 1 |

|7 |Computer Interface 2 |

|8 |Unwinding Report |

|9 |History Display |

This field may also be used to collect defect or streak attributes by type. Referring to Appendix A, any attribute in table F or table G may be collected by type.

|Location 2 |Collect attribute for: |

|0 |All defect/streak types |

|1 |Holes |

|2 |Dark spots |

|3 |Light spots |

|4 |Gray spots |

|5 |Dark streaks |

|6 |Bright streaks |

|7 |Light streaks |

|8 |Gray streaks |

|9 |Other |

For example, if you want to collect the MD location of holes, set location 1 to 132 and location 2 to 1. For the CD location of light streaks, set location 1 to 173 and location 2 to 7.

Location 3

Location 3 defines the set when it is used in conjunction with location 1 with a value of 190, 225, 226, or 230. An acceptable value is an integer from 1 to 20.

This location parameter serves a dual purpose. If location 1 refers to a defect category (20, 21, 22, 23, 69, 70, 71, or72), enter that category here. An acceptable value is an integer from 1 to 12.

Location 4

For this interface, the value must always be 1.

Location 5

Location 5 defines the roll within a set. It is used in conjunction with location 1 with a value of 203, 226, or 230. An acceptable value is an integer from 1 to 20.

Location 5 can also indicate that a total should be stored for the reel. Set location 1 to 130 and use the following table to indicate which total is to be calculated by the interface. Totals will have a timestamp of the beginning of the reel.

|Location 5 |Total to calculate |

|1 |Holes |

|2 |Dark spots |

|3 |Light spots |

|4 |Gray spots |

|5 |Dark streaks |

|6 |Bright streaks |

|7 |Light streaks |

|8 |Gray streaks |

|9 |Other streaks |

|10 |All spots |

|11 |# defects + # streaks |

|13 |Web breaks |

|14 |Length clearances |

|15 |Set changes |

|16 |Cuts |

Software Configuration

In addition to PI Point definitions, the point source, digital states, and the I/O rate counter need to be configured.

IO Rate Points

An IO Rate point can be configured to receive 10-minute averages of the total number of exceptions per minute that are sent to PI by the interface. An exception is a value that has passed the exception specifications for a given PI point. Since 10-minute averages are taken, the first average is not written to PI until 10 minutes after the interface has started. There are two configuration steps.

Step 1 – PI Point configuration on the PI Server

For step 1 and 2, it is assumed that the name of the PI tag is ulma3d01.

PI 3 Server Nodes

Create an IO Rate Tag with the following point attribute values.

|Attribute |Value |

|PointSource |L |

|PointType |float32 |

|Compressing |1 |

|ExcDev |0 |

The default settings can be used for the remaining PI Point attributes. However, one may wish to adjust the compression specifications (CompDev, CompMin, CompMax, and CompDevPercent) to control the amount of data that is archived owing to the IO Rate point.

PI 2 Server Nodes

Create an IO Rate Tag using one of the existing IO Rate Tags as a template. A listing of IO Rate Tags can be found on page DA-71 of PI System Manual I.

Step 2 – Configuration on the Interface Node

For step 2, it is assumed that the name of the IO Rate point on the home node is ulma3d01.

NT Nodes

1. Edit/Create a file called iorates.dat in the PIHOME\dat directory. The PIHOME directory is defined either by the PIPCSHARE entry or the PHOME entry in the pipc.ini file, which is located in the \WinNT directory. If both are specified, the PIPCSHARE entry takes precedence.

Since the PIHOME directory is typically C: \PIPC, the full name of the iorates.dat file will typically be C:\PIPC\dat\iorates.dat.

Add a line in the iorates.dat file of the form:

ulma3d01, x

where ulma3d01 is the name of the IO Rate Tag and x corresponds to the first instance of the /ec=x flag in the startup command file. X can be any number between 1 and 34 or between 51 and 200, inclusive. However, it is best to use an event counter, x, that is not equal to 1 because 1 is the default event counter for UniInt-based interfaces. Set the /ec=x flag on the startup command file of the interface to match the event counter in the iorates.dat file.

2. The interface must be stopped and restarted in order for the IO Rate tag to take effect. IORates will not be written to the tag until 10 minutes after the interface is started.

3. The 10-minute rate averages (in events/minute) can be monitored with a client application such as Processbook.

Open VMS Nodes

IORates are discussed on page DA-59 of PI System Manual I.

To implement an IO Rate tag, perform the following steps:

1. Add a line to the PISysDat:IORates.dat file of the form:

INF001, x

where INF is a 3-letter abbreviation for the interface and x corresponds to the event counter specified by the first instance of the /ec=x flag in the startup command file of the interface. X can be any number between 1 and 34 or between 51 and 200, inclusive. However, it is best to use an event counter, x, that is not equal to 1 because 1 is the default event counter for Uniint-based interfaces. The event counter, /ec=x, should be unique for each copy of the interface. Note that the PISysDat:IORates.dat file must be edited on the node where the interface is running. That is, if the interface is running on a PINet node, then the PISysDat:IORates.dat file on the PINet node must be edited, not the PISysDat:IORates.dat file on the home node.

2. Set the /ec=x flag on the startup command file of the interface to match the event counter in the PISysDat:IORates.dat file.

3. Stop and start the IORates process with the following commands so that the changes take effect.

@PISysExe:stop iorates

@PISysExe:

The rate (events/minute) can be monitored with the PISysExe:IOMonitor.exe program or with another client program such as Process Book. The IOMonitor program is discussed on page DA-71 of PI System Manual I.

PI 2 Home Node

These definitions are needed on a PI 2 home node.

Point Source

The point source may be any single character not currently used by another PI process or interface. It must be defined prior to point configuration. All tags for this interface must have the same point source.

The point source is defined by running the Point Src display on the PI menu, selecting a blank field in the list and entering the following definition.

|Point Source Character |(char) |

|Point Source Description |ULMA 3D |

The location parameters should be defined as follows:

|Location 1 |Location 2 |Location 3 |Location 4 |Location 5 |

|1 |0 |0 |1 |0 |

|230 |9 |20 |1 |20 |

Digital States

Digital states are defined by running the Digtl Stat display from the PI menu. The states must be contiguous for each status type. The digital states need to be defined prior to point configuration. Appendix A indicates which tags ought to be digital and the meanings of the input value.

For more information, see the DA manual. For more information about proposed state sets, see “Appendix B, Digital State Sets” on page 6.

PI 3 Home Node

These definitions are needed on a PI 3 home node.

Point Source

While the point source must also be unique on a PI 3 home node, there is no point source table. The point source tag attribute is sufficient for defining the point source. All tags for this interface must have the same point source.

Digital States

A digital state set is a group of digital states that are related. For instance, ON/OFF may be a digital state set where the zero of the tag is ON and a value of one for the tag denotes OFF.

Appendix A indicates which tags ought to be digital and the meanings of the input value. See the DA manual for more information. For proposed state sets, see “Appendix B, Digital State Sets” on page 6.

Startup Command File

The ABB Ulma 3D Single Beam interface on Windows has an ICU Control that will aid in configuring the ULMA3D interface startup command file:

[pic]

There is a PI-ICU control available for the Ulma3D interface that allows the following interface specific parameters to be configured on the Ulma3D tab shown above. A yellow text box indicates that an invalid value has been entered, or that a required value has not been entered.

Reject file path

This is the full path to the directory containing the reject files and is a required parameter. The command line equivalent is /path. You can enter the path in the text box or browse to and select it using the “…” button.

Grade file

This is an optional parameter. The command line equivalent is /g.

The grade file is an ASCII file that contains the quality codes used on your system. You can enter the filename or the full path to the grade file or.browse to and select the file using the “…” button. If the filename alone is used, the Ulma3D interface will look for the grade file in the Ulma3D interface directory.

Elapsed distance tag

This is an optional parameter that defines the elapsed distance tag on your system. The command line equivalent is /edt This tag is not part of the interface, but is used to locate defects within the reel. If this tag is not defined, a constant machine speed will be assumed.

You can enter the tagname in the text box or search for and select the tag using the “…” button.

UseTappi reel numbers

Check this if the reel number is a single ASCII character followed by 7 digits. The command-line equivalent is /tap.

Defect files have edge crack data

Check this if the defect files the interface will be reading include an output bit mask for edge cracks. The command line equivalent is /cr.

Turn on additional interface performance messages

Check this to turn on additional messages for debugging purposes. The command line equivalent is /db.

Additional Arguments

This text box is included so that any additional arguments added to the interface in the future can be configured. Arguments should be entered into the additional arguments textbox in command line format with each argument starting with a /.

Command Line Parameters

Before the interface starts, a file containing the configuration parameters must be created. The command line arguments will need to be modified for your site and interface.

At startup, the interface interprets the command line arguments. The command line arguments define the point source, scan frequency, path, grade table file, elapsed distance tag, and I/0 rate counter. All arguments must begin with a /, have a space between them, and no spaces within the argument. The arguments are not case sensitive. A point source, scan class, and path must be defined for the interface to start. The formats for the arguments are:

|Parameter |Required/Optional |Meaning |

|/ps |Required |Point source definition where x is the character used in defining the |

| | |tags. |

| | |/ps=x |

|/f |Required |The scan class is defined with a /f, followed by the period and optional |

| | |phase. The phase indicates when to start the first data collection and |

| | |the period indicates how often thereafter to collect data. |

| | |/f=hh:mm:ss,hh:mm:ss |

|/tz |Required on VMS |Offset from Universal Coordinated Time (UCT). West of UCT is a negative |

| |Ignored on NT |number and east is positive. For example: During EST this parameter |

| | |would be set to /tz=-5. During EDT it would be /tz=-4. |

|/path |Required |The path defines the location of the reject files. |

| | |/path=string |

|/cr |Required |This command line parameter is required if the defect files the interface|

| | |will be reading includes an output bit mask for edge cracks. |

|/tap |Required |This command line parameter is required if the reel number is a single |

| | |ASCII character followed by 7 digits. |

|/ec |Optional |I/O rate or event counter definition where n is the number of the counter|

| | |associated with your iorate tag in iorates.dat. Defaults to 1 if not |

| | |supplied. |

| | |/ec=n |

|/edt |Optional |This defines the elapsed distance tag on your system. This tag is not |

| | |part of the interface, but is used to locate defects within the reel. If |

| | |this tag is not defined, a constant machine speed will be assumed. |

| | |/edt=tagname |

|/g |Optional |The grade file is an ASCII file that contains the quality codes used on |

| | |your system. These are a maximum of 20 characters long and must be mapped|

| | |into a 12-character digital state in PI 2. In PI 3 the digital states may|

| | |be 20 characters. The order they are listed in the file must have a |

| | |one-to-one correspondence to the set of digital states associated with |

| | |the tag with location parameter 1 set to 7. |

| | |/g=filename |

|/db |Optional |This is an optional command line switch that will turn on additional |

| | |interface performance messages. |

| | |/db |

NT Interface Node

If users do not want to use the Interface Configuration Utility to configure the startup command file for Windows, they may manually modify the Ulma3D.bat file.

Ulma3D.bat

The interface bat file uses the command line parameters described above.

For NT, command file names have a .bat extension. The NT continuation character (^) allows one to use multiple lines for the startup command. The maximum length of each line is 1024 characters (1 kilobyte). The maximum number of flags is 128, and each flag can be a maximum of 128 characters long.

Example

REM =========================================================================

REM Sample NT command file to start the ULMA3D interface to PI.

REM You will need to modify the parameters for your site and interface.

REM =========================================================================

REM The following command-line arguments are required to start the interface:

REM /ps=x Point source

REM /f=hh:mm:ss, hh:mm:ss Scan frequency

REM /path=string Path to the reject files.

REM

REM The following arguments are optional:

REM /ec=n Event counter

REM /grade=filename Grade file

REM /edt=tagname Elapsed distance tag

REM /db Debug flag

REM

REM Example Startup of the interface

REM ULMA3D /ps=x /f=hh:mm:ss /ec=n /path=path

Ulma3D /ps=x /f=00:01:00,00:00:00 /ec=20 /path=c:\pipc\interfaces\ulma3D\reels

REM

REM End command file

VAX/Alpha

ULMA3Dstart_.com

Example

A typical command line might look like this:

ULMA3D /PS=R /ec=14 /f=00:30:00,00:00:00 /path=dka0:[ulma.pm61] /tz=-5

This command sets the point source to R, the I/0 rate counter to 14, and establishes the scan class with a period of 30 minutes and a phase of midnight. The leading 0’s are required in the scan class definition.

Note: This interface must be stopped and restarted at each time change to adjust the TZ offset. The Ulma3D files store timestamps in UCT adjusted by the TZ variable on the NT box and the VAX only knows about local time.

$! =========================================================================

$!

$! =========================================================================

$! Sample VAX command file to start the ULMA 3D interface to PI.

$! You will need to modify the parameters for your site and interface.

$! =========================================================================

$! The following command-line arguments are required to start the interface:

$! /ps=x Point source

$! /f=hh:mm:ss, hh:mm:ss Scan frequency

$! /path=string Path to the reject files.

$!

$! The following arguments are optional:

$! /ec=n Event counter

$! /grade=filename Grade file

$! /edt=tagname Elapsed distance tag

$! /db Debug flag

$!

$! Define the interface to run with arguments

$ ULMA3D :== $PISysExe:ULMA3D.exe

$!

$! Example Startup of the interface

$! ULMA3D /ps=x /f=hh:mm:ss /ec=n /path=path /edt=tagname /g=filename

$!

$! End command file

$ Exit

$! =================================================================

$! Edit History:

$! 11-Nov-96 CG> Written

$! =================================================================



The interface is started as a detached process by running the file PISysExe:. This file takes one parameter and expects the startup file to be named Ulma3Dstart_ where ptsource is the input parameter.

$!

$! --------------------------------------------------------

$! Command file to start the ABB Ulma3D to PI Interface program

$! As a detached process and purge existing log files.

$!

$! P1 is the first passed parameter on the command line. It

$! Is optional. If it is defined, then it will enable a

$! Different version of the interface program to be started.

$! This will allow different symbols to be used in the Start

$! Command file.

$!========================================================================

$!

$ say == “write sys$output “

$!

$ if (f$search(“pisysexe:ulma3dstart_’’p1’.com”) .EQS. “”) then goto no_file

$ if (f$search(“pisysexe:ulma3d.exe”) .EQS. “”) then goto no_abbpi

$!

$ if (f$search(“pisysexe:ulma3d_’’p1’.out”) .nes. “”) then –

purge/nolog/keep:3 pisysexe:ulma3d_’p1’.out

$!

$ Run /Detach/UIC=[SYSTEM]-

/Proc=”ULMA3D_’’p1’”-

/Priority=6-

/Input=pisysexe:ulma3dstart_’p1’.com-

/enqueue_limit=500-

/working_set=6000-

/Output=pisysexe:ulma3d_’p1’.out –

Sys$System:LogInOut

$!

$ goto fini

$!

$no_file:

$!

$ say “File pisysexe:ulma3dstart_’’p1’.com does NOT exist”

$ say “Process ulma3d_’’p1’ was NOT started”

$ goto fini

$!

$no_abbpi:

$ say “File pisysexe:ulma3d.exe does NOT exist”

$ say “Process ulma3d_’’p1’ was NOT started”

$ goto fini

$!

$fini:

$ exit

$!========================================================================

$! Edit History:

$! 18-Mar-97 CG written

$!========================================================================

Interface Operation

The interface will read files from the directory specified by the /path parameter in the startup file. Only reject files should ever be placed in the directory. Once a file has been processed, whether successfully or not, it will be deleted.

The defect files will need to be moved from the monthly sub directories on the NT into a single directory on the VAX. This can be done via FTP.

Filenames have the format NNNNNN.xyz, where NNNNNN is a reel number, xy is a production date, and z is a sequence number of reels that have been produced in the same day.

If there is a problem processing a file, it will be deleted so the interface will not attempt to process it again. A message will be sent to the PI message log. (Note that the message includes a number in parentheses that indicates the troublesome line.)

It is important that the Ulma 3D clock and the PI system clock be synchronized. If a file has a start time or end time for the reel that is more than 10 minutes in the future, a message will be sent to the PI message log.

VAX/Alpha

After configuration of the software, the Ulma3D Interface may be started. The interface may be run from the DCL prompt, but it should be configured to start automatically whenever the PI System is started.

Startup

The Ulma3D Interface is started by running from the DCL prompt:

@PISysExe:ULMA3DDetach

To ensure that the interface restarts when the PI System is started, add the previous line to PISysMgr:.

Shutdown

The Ulma3D Interface can be stopped from the DCL prompt by typing the command:

@PISysExe:Stop ulma3d_ptsource

where ptsource is the input parameter used to start the detached process. This method is preferred over one that writes shutdown to each of the tags because the files being processed may not be current ones.

NT

The startup and shutdown procedures are described in the installation chaper below.

Interface Installation on NT

General

This is the generic installation procedure for Uniint-based interfaces on NT.

OSI recommends that interfaces be installed on API nodes instead of directly on the PI server node. An API node is an NT or UNIX node other than the PI Server node where the PI Application Programming Interface (PI-API) has been installed (see the PI-API Installation Instructions manual). The PI server should not need to compete with interfaces for CPU time. The primary function of the PI server is to archive data and to service clients that request data.

After the interface has been installed and tested, Bufserv should be enabled on the API node (once again, see the PI-API Installation Instructions manual). Bufserv is distributed with the PI-API. It is a utility program that provides the capability to store and forward events to a PI server, allowing continuous data collection when communication to the PI server is lost. Communication will be lost when there are network problems or when the PI server is shut down for maintenance, upgrades, backups, or unexpected failures.

In most cases, interfaces on API nodes should be installed as automatic services, except during the initial testing period where it is recommended to run the interface interactively to simplify troubleshooting. Services keep running after the user logs off. Automatic services automatically restart when the computer is restarted, which is useful in the event of a power failure.

The guidelines are different if an interface is installed on the PI server node. In this case, the typical scenario is to install the PI server as an automatic service and interfaces as manual services that are launched by site-specific command files when the PI server is started. Interfaces that are started as manual services are also stopped in conjunction with the PI server by site-specific command files. This typical scenario assumes that Bufserv is not enabled on the PI server node. Bufserv can be enabled on the PI Server node so that interfaces on the PI server node do not need to be started and stopped in conjunction with PI, but it is not standard practice to enable buffering on the PI server node. See the section “Buffering on the PI Server Node” for special procedural information.

Naming Conventions and Requirements

In the installation procedure below, it is assumed that the name of the interface executable is ifc.exe and that the startup command file is called ifc.bat. If the actual name of the interface is “Random,” one should substitute Random for ifc in the installation procedure below.

It is customary for the user to rename the executable and the startup command file when multiple copies of the interface are run. For example, one would typically use ifc1.exe and ifc1.bat for interface number 1, ifc2.exe and ifc2.bat for interface number 2, and so on. When an interface is run as a service, the executable and the command file must have the same root name because the service looks for its command-line arguments in a file that has the same root name as itself.

Interface Directories

The PIHOME Directory Tree

The PIHOME directory tree is defined by the PIHOME entry in the pipc.ini configuration file. This pipc.ini file is an ASCII text file, which is located in the WinNT directory. A typical pipc.ini file contains the following lines:

[PIPC]

PIHOME=c:\pipc

The above lines define the \pipc directory as the root of the PIHOME directory tree on the C: drive. OSI recommends using \pipc as the root directory name. The PIHOME directory does not need to be on the C: drive.

Interface Installation Directory

There are two conventions for the installation directory. The first convention is to place all copies of the interface into a single directory. If this convention is followed, it is recommended to place ifc1, ifc2, ifc3, etc., in the directory:

PIHOME\interfaces\ifc\

The second convention is to create a separate interface directory for each copy of the interface. If this convention is followed, it is recommended to place ifc1, ifc2, ifc3, etc., in the directories:

PIHOME\interfaces\ifc1\

PIHOME\interfaces\ifc2\

PIHOME\interfaces\ifc3\

and so on.

Create the installation directories as necessary. Replace PIHOME with the corresponding entry in the pipc.ini file.

Setting the Interface Node Clock

The correct settings for the time and time zone should be set in the Date/Time control panel. From the control panel, configure the time to be automatically adjusted for daylight savings time. The correct local settings should be used even if the interface node runs in a different time zone than the PI server node.

Make sure that the TZ environment variable is NOT defined. The currently defined environment variables can be listed by going to Start | Settings | Control Panel, double clicking on the system icon, and selecting the environment tab on the resulting dialog box. Also, make sure that the TZ variable is NOT defined in an autoexec.bat file. When the TZ variable is defined in an autoexec.bat file, the TZ variable may not appear as being defined in the System control panel even though the variable is defined. Admittedly, autoexec.bat files are not typically used on NT, but this does not prevent a rogue user from creating such a file and defining the TZ variable unbeknownst to the system administrator.

Security

If the home node is a PI 3 server, the PI Firewall Database and the PI Proxy Database must be configured so that the interface is allowed to write data to the PI Data Archive. See “Modifying the Firewall Database” and “Modifying the Proxy Database” in the PI Data Archive Manual.

If the home node is a PI 2 server, the read/write permissions should be set appropriately in the pisysdat:piserver.dat file on the PI 2 home node. For more information on setting permissions on PI 2, see the pibuild:piserver.txt file on the PI 2 home node.

If the interface cannot write data to a PI 2 or PI 3 server because it has insufficient privileges, a –10401 error will be reported in the pipc.log file. See the section “Error and Informational Messages” for additional information on error messaging.

Interface Installation Procedure

In the installation procedure below, it is assumed that interface number 1 is being installed and that all copies of the interface will be installed in the same directory. To install another copy of the interface, the following procedure is repeated with ifc# used in place of ifc1, where # is the interface number between 1 and 99.

1. Copy the interface files from the installation media to c:\pipc\interfaces\ifc\. Create the directory if necessary.

2. If necessary, rename the executable and command files to ifc1.exe and ifc1.bat. The executable and command file should have the same root name.

3. Alter the command-line arguments in the ifc.bat file as discussed in this manual and the interface-specific documentation.

4. Try to start the interface interactively with the command:

ifc1.bat

If one cannot run the interface interactively, one will not be able to run the interface as a service. It is easier to debug interactively started processes because error messages are echoed directly to the screen. Once the interface is successfully running interactively, one can try to run it as a service by following the instructions below.

Installing the Interface as an NT Service

One can get help for installing the interface a service at any time with the command:

ifc1.exe –help

Change to the directory where the ifc1.exe executable is located. Then, consult the following table to determine the appropriate service installation command.

|NT Service Installation Commands on an API node or a PI server node |

|with Bufserv implemented |

|Manual service |ifc1.exe –install –depend “tcpip bufserv” |

|Automatic service |ifc1.exe –install –auto –depend “tcpip bufserv” |

| |

|NT Service Installation Commands on an API node or a PI server node |

|without Bufserv implemented |

|Manual service |ifc1.exe –install –depend tcpip |

|Automatic service |ifc1.exe –install –auto –depend tcpip |

When the interface is installed as a service on the PI server node and when Bufserv is not implemented, a dependency on the PI network manager is not necessary because the interface will spin its wheels until it connects to PI. Note that interfaces are typically not installed as automatic services when the interface is installed on the PI server node.

Check the Microsoft Windows NT services control panel to verify that the service was added successfully. One can use the services control panel at any time to change the interface from an automatic service to a manual service or vice versa.

The service can be started from the services control panel or with the command:

ifc1.exe –start

A message will be echoed to the screen informing the user whether or not the interface has been successfully started as a service. Even if the message indicates that the service started successfully, one should make sure that the service is still running by checking in the services control panel. There are several reasons that a service may immediately terminate after startup. For one, the service may not be able to find the command-line arguments in the associated .bat file. For this to succeed, the root name of the .bat file and the .exe file must be the same, and the .bat file and the .exe file must be in the same directory. If the service terminates prematurely for whatever reason, no error messages will be echoed to the screen. The user must consult the pipc.log file for error messages. See the section “Error and Informational Messages” for additional information.

The service can be stopped at any time from the services control panel or with the command:

ifc1.exe –stop

The service can be removed by

ifc1.exe –remove

Configuring the Interface to Start and Stop with PI

This section describes how to configure the site-specific startup command files so that an interface can be started and stopped in conjunction with the PI server. The information in this section pertains to an interface that has been installed on the PI server node as a manual service or as an interactive process without Bufserv enabled. When Bufserv is not enabled, there is no need to install the interface as an automatic service on the PI server node. If Bufserv is enabled on the PI server node, see the section “Buffering on the PI Server Node” for special procedural information.

Interactive Process

The PI server can be started interactively with the \PI\adm\pistart.bat command file. This command file invokes a site-specific startup command file called \PI\adm\pisitestart.bat. An example of a site-specific command file is given below.

|Rem |

|rem $ Archive: $ |

|rem |

|rem Site Specific startup file. This file should |

|rem be modified to start site specific applications |

|rem related to PI. This file will not be overwritten |

|rem on upgrade. Instead new versions will be written |

|rem as pisitestart.bat.new for review and integration |

|rem by the PI Administrator. |

|Rem |

| |

|echo Starting Random Interface... |

|start “Random Interface” /min ..\interfaces\random\random.bat |

|pidiag –w 5000 |

| |

|echo Starting Ramp Soak Interface... |

|start “Ramp Soak Interface” /min ..\interfaces\rmp_sk\rmp_sk.bat |

To start ifc1 with the above site-specific command file, one would add the following lines to the end of the command file.

Pidiag –w 5000

echo Starting the Ifc1 Interface...

start “Ifc1” /min c:\pipc\interfaces\ifc1\ifc1.bat

There is no command file for stopping interfaces that have been started interactively. To stop interfaces that have been started interactively, one must hit control-c while the window from which the interface was started is in focus.

Service

The PI server is started as a service with the \PI\adm\pisrvstart.bat command file. This command file invokes a site-specific startup command file called \PI\adm\pisrvsitestart.bat. An example of this site-specific command file is given below.

|Rem |

|rem $ Archive: $ |

|rem |

|rem Non-Interactive Site Specific startup file. This file |

|rem should be modified to start site specific services |

|rem related to PI. This file will not be overwritten |

|rem on upgrade. Instead new versions will be written |

|rem as pisrvsitestart.bat.new for review and integration |

|rem by the PI Administrator. |

|Rem |

| |

|echo Starting Site Specific PI System Services... |

|..\interfaces\rmp_sk\rmp_sk –start |

|..\interfaces\random\random –start |

|:theend |

Assuming that ifc1 is installed as a manual service, one would add the following line just before “:theend” to start ifc1 in conjunction with the PI server.

C:\pipc\interfaces\ifc1\ifc1 –start

The PI server service is stopped with the \PI\adm\pisrvstop.bat command file. This command file invokes a site-specific shutdown procedure called \PI\adm\pisrvsitestop.bat. An example of this site-specific file is given below.

|Rem |

|rem $ Archive: $ |

|rem |

|rem Non-Interactive Site Specific shutdown file. This file |

|rem should be modified to stop site specific services |

|rem related to PI. This file will not be overwritten |

|rem on upgrade. Instead new versions will be written |

|rem as pisrvsitestop.bat.new for review and integration |

|rem by the PI Administrator. |

|Rem |

|echo Stopping Site Specific PI System Services... |

|..\interfaces\rmp_sk\rmp_sk –stop |

|..\interfaces\random\random –stop |

|:theend |

For ifc1, one would add the following line just before “:theend.”

C:\pipc\interfaces\ifc1\ifc1.exe –stop

Buffering on the PI Server Node

If the interface is installed on the PI server node, one may wish to enable Bufserv on the PI server node to allow continuous data collection when the PI server is down. If Bufserv is enabled on the PI server node, any interfaces on the PI server node should be installed as automatic services dependent on Bufserv, including the Ramp Soak and Random interfaces that are distributed with PI.

With this in mind, follow the procedure below before enabling Bufserv on the PI server node.

1. Check the services control panel to see if the Ramp Soak and Random interfaces were installed as services when the PI server was installed. The names of these services should appear as “PI Ramp-Soak Simulator Interface” and “PI Random Simulator Interface” in the control panel. If the interfaces are installed as services, stop the services if they are running and remove them as follows:

\pi\interfaces\rmp_sk\rmp_sk –remove

\pi\interfaces\random\random –remove

Next, install the interfaces as automatic services dependent on Bufserv.

cd \pi\interfaces\rmp_sk

rmp_sk –install –auto –depend “tcpip bufserv”

cd \pi\interfaces\random

random –install –auto –depend “tcpip bufserv”

2. Install the interface as an automatic service dependent on Bufserv. Change to the interface directory and execute the command:

ifc1 –install –auto –depend “tcpip bufserv”

3. Install Bufserv as an automatic service as described in the PI-API Installation Instructions manual.

Installation Checklist NT and VMS

1. Verify that your file format is one this interface can read.

2. Check that the reject files can be transferred to the computer where the interface will be running.

3. Choose a point source and create it, if necessary.

4. Define an IORate tag, if necessary.

5. Allocate an event counter for the IORate tag in IORates.dat, if necessary.

6. Edit the interface startup file.

7. Define the necessary digital states.

8. Configure the PI tags.

9. Edit .

10. Edit .

11. Start interface.

Appendix A:

Tag Attributes

Table A

Loc 1 or the Location parameter 1 roughly corresponds to the line number in the reject file. Loc 2, Loc 3, Loc 4, and Loc 5, the other location parameters, are listed with the possible values for each tag. Note that Location 4 is always one.

No duplicates of location 1 are allowed.

|Loc 1 |Tag type |Description |Loc 2 |Loc 3 |Loc 4 |Loc 5 |

|2 |real |Version number |0 |0 |1 |0 |

|3 |real |Starting time of the reel in seconds after 1.1.1970 00:00:00 |0 |0 |1 |0 |

|4 |real |Ending time of the reel in seconds after 1.1.1970 00:00:00 |0 |0 |1 |0 |

|5 |real |Total length of reel (dm) |0 |0 |1 |0 |

|6 |integer |Sequence number (same as in file name) usually zero |0 |0 |1 |0 |

|7 |digital |Quality code (grade) string maximum 20 characters |0 |0 |1 |0 |

|8 |integer |Parameter category (1..10) |0 |0 |1 |0 |

|10 |real |Total dark formation number |0 |0 |1 |0 |

|11 |real |Total light formation number |0 |0 |1 |0 |

|12 |integer |Number of formation samples |0 |0 |1 |0 |

|15 |digital |On history display |0 |0 |1 |0 |

| | |0 No | | | | |

| | |1 Yes | | | | |

|16 |real |Slabbed length of reel (dm) |0 |0 |1 |0 |

|17 |digital |Data has been sent to ULMA ABS |0 |0 |1 |0 |

| | |0 No | | | | |

| | |1 Yes | | | | |

|18 |digital |Drive side |0 |0 |1 |0 |

| | |0 Right | | | | |

| | |1 Left | | | | |

Table B

The following four lines are repeated in the defect file for each of the 12 defect categories. Enter the category in Loc 3.

|Loc 1 |Tag type |Description |Loc 2 |Loc 3 |Loc 4 |Loc 5 |

|20 |integer |Number of removed defects |0 |1..12 |1 |0 |

|21 |real |Length (dm) of removed streaks |0 |1..12 |1 |0 |

|22 |integer |Number of removed edge defects |0 |1..12 |1 |0 |

|23 |integer |Number of removed defect bursts |0 |1..12 |1 |0 |

Table C

The following four lines are also repeated in the defect file for each of the 12 defect categories. Enter the category in Loc 3. For location 1 set to 71, enter the output device in location 2.

|Loc 1 |Tag type |Description |Loc 2 |Loc 3 |Loc 4 |Loc 5 |

|69 |real |Minimum size in CD (0.1 mm or 0.01 inch) |0 |1..12 |1 |0 |

|70 |real |Minimum size in MD (0.1 mm or 0.01 inch) |0 |1..12 |1 |0 |

|71 |digital |Defect output reporting device |0..9 |1..12 |1 |0 |

|72 |real |Detection level (0.1%) |0 |1..12 |1 |0 |

Table D

The output device for the following lines should be entered in Loc 2. The list of output devices can be found in the location 2 point attribute section above.

|Loc 1 |Tag type |Description |Loc 2 |Loc 3 |Loc 4 |Loc 5 |

|117 |digital |Edge defects: Defect output reporting device |0..9 |0 |1 |0 |

|118 |digital |Burst defects: Defect output reporting device |0..9 |0 |1 |0 |

|119 |digital |Edge cracks: Defect output reporting device |0..9 |0 |1 |0 |

| | |(If your files include this data, be sure /CR is a | | | | |

| | |command line parameter for startup of the interface.) | | | | |

Table E

The next few lines have a one-to-one correspondence to the lines in the reject file.

|Loc 1 |Tag type |Description |Loc 2 |Loc 3 |Loc 4 |Loc 5 |

|120 |real |Reel number |0 |0 |1 |0 |

|122 |integer |Number of discrete defects in the defect buffer |0 |0 |1 |0 |

|123 |integer |Number of start and ends of streaks in the streak buffer |0 |0 |1 |0 |

|124 |real |Web width (mm) |0 |0 |1 |0 |

|125 |real |Sum of the edge pixels on the camera #1 side |0 |0 |1 |0 |

|126 |real |Total number of edge scans on the camera #1 side |0 |0 |1 |0 |

|127 |real |Sum of the edge pixels on the last camera side |0 |0 |1 |0 |

|128 |real |Total number of the edge scans on the last camera side |0 |0 |1 |0 |

Table F

References to Loc 1 with values of 130 – 142 will be repeated in the reject file for each discrete defect. The number of defects is indicated by line 122. For each discrete defect, lines 141 – 142 are repeated the number of times indicated by line 140.

|Loc 1 |Tag type |Description |Loc 2 |Loc 3 |Loc 4 |Loc 5 |

|130 |integer |Defect category |0 – 4 |0 |1 |1..16 |

| | |1..12 Hole or spot | | | | |

| | |13 Web break | | | | |

| | |14 Length clearance | | | | |

| | |15 Set change | | | | |

| | |16 Cut | | | | |

|131 |digital |Defect type only applicable to categories 1 – 12 |0 – 4 |0 |1 |0 |

| | |0 None | | | | |

| | |1 Hole | | | | |

| | |2 Dark spot | | | | |

| | |3 Light spot | | | | |

| | |4 Gray spot | | | | |

|132 |real |Defect location in MD (dm) |0 – 4 |0 |1 |0 |

|133 |real |Defect location in CD (pixels) |0 – 4 |0 |1 |0 |

|134 |real |Distance from web edge in tender side (mm or 0.1 inch) |0 – 4 |0 |1 |0 |

|135 |real |Defect size in MD (0.1 mm) |0 – 4 |0 |1 |0 |

| | |If this is the end of defect burst, this line is # of defects in | | | | |

| | |burst. | | | | |

| | |If this is the beginning of defect burst, this is Not Used. | | | | |

|136 |real |Defect size in CD (0.1 mm). |0 – 4 |0 |1 |0 |

| | |If end of defect bursts, this is Not Used. | | | | |

|137 |digital |Defect distinction parameter |0 – 4 |0 |1 |0 |

| | |0 Normal defect | | | | |

| | |1 Edge defect | | | | |

| | |2 Beginning of a defect burst | | | | |

| | |3 End of defect burst | | | | |

|138 |digital |Unwounded defect |0 – 4 |0 |1 |0 |

| | |0 No | | | | |

| | |1 Yes | | | | |

|139 |digital |Patched defect |0 – 4 |0 |1 |0 |

| | |0 No | | | | |

| | |1 Yes | | | | |

|140 |integer |Number of defect shape data |0 – 4 |0 |1 |0 |

|141 | |Shape data not available at this time |0 – 4 |0 |1 |0 |

|142 | |Shape data not available at this time |0 – 4 |0 |1 |0 |

Table G

Each streak is defined by the group of lines from 170 – 178. They are repeated in the defect file the number of times indicated by line 123.

|Loc 1 |Tag type |Description |Loc 2 |Loc 3 |Loc 4 |Loc 5 |

|170 |digital |Defect category |0, 5 – 9 |0 |1 |0 |

| | |1..12 Streak | | | | |

| | |13 Web break | | | | |

| | |14 Length clearance | | | | |

| | |15 Set change | | | | |

| | |16 Cut | | | | |

|171 |digital |Defect type |0, 5 – 9 |0 |1 |0 |

| | |5 Dark streak | | | | |

| | |6 Bright streak | | | | |

| | |7 Light streak | | | | |

| | |8 Gray streak | | | | |

| | |9 Other | | | | |

|172 |real |Defect location in MD (dm) |0, 5 – 9 |0 |1 |0 |

|173 |real |Defect location in CD (pixels) |0, 5 – 9 |0 |1 |0 |

|174 |real |Distance from web edge in tender side (mm or 0.1 inch) |0, 5 – 9 |0 |1 |0 |

|175 |real |Defect size in CD (0.1 mm) |0, 5 – 9 |0 |1 |0 |

|176 |digital |Start or end of streak |0, 5 – 9 |0 |1 |0 |

| | |0 Start of streak | | | | |

| | |1 End of streak | | | | |

|177 |digital |Unwounded defect |0, 5 – 9 |0 |1 |0 |

| | |0 No | | | | |

| | |1 Yes | | | | |

|178 |digital |Streak has started from hole |0, 5 – 9 |0 |1 |0 |

| | |0 No | | | | |

| | |1 Yes | | | | |

Table H

The next line is repeated twenty times in the defect file, once for each set change. Enter the set in Loc 3.

|Loc 1 |Tag type |Description |Loc 2 |Loc 3 |Loc 4 |Loc 5 |

|190 |real |Set change MD (dm) from start of the reel |0 |1..20 |1 |0 |

Table I

The next two lines refer to the roll cutting before the first set change. For the roll end point enter the roll in Loc 5.

|Loc 1 |Tag type |Description |Loc 2 |Loc 3 |Loc 4 |Loc 5 |

|202 |real |1st roll start point |0 |0 |1 |0 |

|203 |real |Roll end point |0 |0 |1 |1..20 |

Table J

The next two lines refer to the roll cutting after the first set change. Enter the set in Loc 3. For the roll end point enter the roll in Loc 5.

|Loc 1 |Tag type |Description |Loc 2 |Loc 3 |Loc 4 |Loc 5 |

|225 |real |1st roll start point |0 |1..20 |1 |0 |

|226 |real |Roll end point |0 |1..20 |1 |1..20 |

Table K

The roll quality information may be recorded by the following line. Enter the set in Loc 3 and the roll in Loc 5.

|Loc 1 |Tag type |Description |Loc 2 |Loc 3 |Loc 4 |Loc 5 |

|230 |digital |Quality of roll |0 |1..20 |1 |1..20 |

| | |0 None | | | | |

| | |1 Prime | | | | |

| | |2 Unwind | | | | |

| | |3 Reject | | | | |

Appendix B:

Digital State Sets

States must start numbering from zero within each set. Below the state None is used to indicate a placeholder in the set. These are only suggestions.

| |Digital State Sets |

|State |A |

|2 |Version Number |

|3 |Start time of reel |

|4 |End time of reel |

|5 |Total length of reel |

|6 |Sequence number |

|7 |Quality code (grade) string maximum 20 characters |

|8 |Parameter category (1..10) |

|9 |EMPTY |

|10 |Total dark formation number |

|11 |Total light formation number |

|12 |Number of formation samples |

|13 |EMPTY |

|14 |EMPTY |

|15 |1 if reel has been on history display, otherwise 0 |

|16 |Slabbed length of reel (dm) |

|17 |1 if data has been sent to ULMA ABS, otherwise 0 |

|18 |1 if drive side is on left, 0 if dive side is on right |

|19 |EMPTY |

|20 |Defect category 1: Number of removed defects |

|21 |Defect category 1: Length (dm) of removed streaks |

|22 |Defect category 1: Number of removed edge defects |

|23 |Defect category 1: Number of reomoved defect bursts |

|24..67 |Defect categories 2 – 12: Same as in lines 20 – 23 |

|68 |EMPTY |

|69 |Defect category 1: Minimum size in CD (0.1 mm or 0.01 inch) |

|70 |Defect category 1: Minimum size in MD (0.1 mm or 0.01 inch) |

|71 |Defect category 1: Output bit mask (16 bits) |

|72 |Defect category 1: Detection level (0.1%) |

|73..116 |Defect categories 2 – 12: Same as in lines 69 – 72 |

|117 |Output bit mask (16 bits) for edge defects |

|118 |Output bit mask (16 bits) for defect bursts |

|119 |EMPTY |

|120 |Reel number (0 – 999999) |

|121 |Defect Counters |

|122 |Number of discrete defects in the defect buffer |

|123 |Number of starts and ends of streaks in streak buffer |

|124 |Web width (mm) |

|125 |Sum of the edge pixels on the camera #1 side |

|126 |Total number of edge scans on camera #1 side |

|127 |Sum of edge pixels on the last camera side |

|128 |Total number of edge scans on the last camera side |

|129 |EMPTY |

|130 |For each discrete defect |

| |Line 1: Defect category |

| |1 – 12 |hole or spot |

| |13 |web break |

| |14 |length clearance |

| |15 |set change |

| |16 |cut |

| |Line 2: Defect type |

| |1 |hole |

| |2 |dark spot |

| |3 |light spot |

| |4 |gray spot |

| |If defect category is 1 – 12, then the following lines |

| |Line 3: |Defect location in MD (dm) |

| |Line 4: |Defect location in CD (pixels) |

| |Line 5: |Distance from web edge in tender side (mm or 0.1 inch) |

| |Line 6: |Defect size in MD (0.1 mm). If this is the end of defect |

| | |burst, then this line contains the number of defects in the |

| | |burst. If this is the beginning of defect burst, then this is|

| | |a filler line. |

| |Line 7: |Defect size in CD (0.1 mm). If end of defect bursts, this is |

| | |a filler line. |

| |Line 8: |Defect distinction parameter: |

| | |0=Normal |

| | |1=Edge defect |

| | |2=Beginning of a defect burst |

| | |3=End of a defect burst |

| |Line 9: |Unwound defect (1 = yes, 0 = no) |

| |Line 10: |Patched defect (1 = yes, 0 = no) |

| |Line 11: |Number of defect shape data |

| |Line 12 – |Number of defect shape data; for each shape 2 lines |

| |12 + 2 * | |

| |Last line: |EMPTY |

| |If defect category is 13 – 16, then the following lines: |

| |Line 3: |MD location (dm) |

| |Line 4: |EMPTY |

|??? |For each streak beginning and end |

| |Line 1: |Defect category |

| | |1-12 Streak |

| | |13 Web break |

| | |14 Length clearance |

| | |15 Set change |

| | |16 Cut |

| |Line 2: |Defect type (for categories 1 – 12) |

| | |5 Dark streak |

| | |6 Bright streak |

| | |7 Light streak |

| | |8 Gray streak |

| | |9 Other |

| |If defect category is 1 – 12, then the following lines |

| |Line 3: |MD location (dm) |

| |Line 4: |Defect location in CD (pixels) |

| |Line 5: |Distance from web edge in tender side (mm or 0.1 inch) |

| |Line 6: |Defect size in CD (0.1 mm) |

| |Line 7: |0 for start of streak, 1 for end of streak |

| |Line 8: |Unwound defect (1 = yes, 0 = no) |

| |Line 9: |Streak has started from hole (1 = yes, 0 = no) |

| |Line 10: |EMPTY |

| |If defect category is 13 – 16, then the following lines |

| |Line 3: |MD location (dm) |

| |Line 4: |Empty |

| |Because the number of lines has been so far dependent on the number of defects, the next line is|

| |the string “aaa”. |

|??? |aaa | |

|1 | |1st set change MD (dm) from start of reel |

|2 | |2nd set change MD (dm) from start of reel |

| | | |

|20 | |20th set change MD (dm) from start of reel |

|21 | |EMPTY |

| |In case there are less than In case there are less than 20 set changes in a reel, those set |

| |change lines not in use are set to zero. The Next 21 lines describe the roll cutting before the|

| |first set change (mm) |

|22 | |1st roll start point |

|23 | |1st roll end point |

|24 | |2nd roll end point |

| | | |

|43 | |20th roll end point |

|44 | |EMPTY |

|45 – 67 | |Same as lines 22 – 44 |

|68 – 485 | |Roll cutting after set changes from 2 to 20 |

| | |In case there are less than 20 roll cuttings, those roll |

| | |cutting lines not in use are set to zero. |

|??? |bbb | |

| |There are 20 lines for roll qualities of each set change in the file. Thus the number of roll |

| |quality lines is 21 x 20 = 420. |

| |Quality of roll 101 | |

| |Quality of roll 102 | |

| |… | |

| |Quality of roll 120 | |

| |… | |

| |Quality of roll 201 | |

| |Quality of roll 202 | |

| |… | |

| |Quality of roll 2120 | |

Appendix D:

Defect File Format Description

January 20, 1998

|1 |Version |

|2 |Version Number |

|3 |Start time of reel |

|4 |End time of reel |

|5 |Total length of reel |

|6 |Sequence number |

|7 |Quality code (grade) string maximum 20 characters |

|8 |Parameter category (1..10) |

|9 |EMPTY |

|10 |Total dark formation number |

|11 |Total light formation number |

|12 |Number of formation samples |

|13 |EMPTY |

|14 |EMPTY |

|15 |1 if reel has been on history display, otherwise 0 |

|16 |Slabbed length of reel (dm) |

|17 |1 if data has been sent to ULMA ABS, otherwise 0 |

|18 |1 if drive side is on left, 0 if dive side is on right |

|19 |EMPTY |

|20 |Defect category 1: Number of removed defects |

|21 |Defect category 1: Length (dm) of removed streaks |

|22 |Defect category 1: Number of removed edge defects |

|23 |Defect category 1: Number of reomoved defect bursts |

|24..67 |Defect categories 2 – 12: Same as in lines 20 – 23 |

|68 |EMPTY |

|69 |Defect category 1: Minimum size in CD (0.1 mm or 0.01 inch) |

|70 |Defect category 1: Minimum size in MD (0.1 mm or 0.01 inch) |

|71 |Defect category 1: Output bit mask (16 bits) |

|72 |Defect category 1: Detection level (0.1%) |

|73..116 |Defect categories 2 – 12: Same as in lines 69 – 72 |

|117 |Output bit mask (16 bits) for edge defects |

|118 |Output bit mask (16 bits) for defect bursts |

|119 |Output bit mask (16 bits) for edge cracks |

|120 |EMPTY |

|121 |Reel number (0 – 999999) |

|122 |Defect Counters |

|123 |Number of discrete defects in the defect buffer |

|124 |Number of starts and ends of streaks in streak buffer |

|125 |Web width (mm) |

|126 |Sum of the edge pixels on the camera #1 side |

|127 |Total number of edge scans on camera #1 side |

|128 |Sum of edge pixels on the last camera side |

|129 |Total number of edge scans on the last camera side |

|130 |EMPTY |

|130 |For each discrete defect |

| |Line 1: Defect category |

| |1 – 12 |hole or spot |

| |13 |web break |

| |14 |length clearance |

| |15 |set change |

| |16 |cut |

| |17 |edge crack |

| |Line 2: Defect type |

| |1 |hole |

| |2 |dark spot |

| |3 |light spot |

| |4 |gray spot |

| |If defect category is 1 – 12, then the following lines |

| |Line 3: |Defect location in MD (dm) |

| |Line 4: |Defect location in CD (pixels) |

| |Line 5: |Distance from web edge in tender side (mm or 0.1 inch) |

| |Line 6: |Defect size in MD (0.1 mm). If this is the end of defect |

| | |burst, then this line contains the number of defects in the |

| | |burst. If this is the beginning of defect burst, then this is|

| | |a filler line. |

| |Line 7: |Defect size in CD (0.1 mm). If end of defect bursts, this is |

| | |a filler line. |

| |Line 8: |Defect distinction parameter: |

| | |0=Normal |

| | |1=Edge defect |

| | |2=Beginning of a defect burst |

| | |3=End of a defect burst |

| |Line 9: |Unwound defect (1 = yes, 0 = no) |

| |Line 10: |Patched defect (1 = yes, 0 = no) |

| |Line 11: |Number of defect shape data |

| |Line 12 – |Number of defect shape data; for each shape 2 lines |

| |12 + 2 * | |

| |Last line: |EMPTY |

| |If defect category is 13 – 16, then the following lines: |

| |Line 3: |MD location (dm) |

| |Line 4: |EMPTY |

|??? |For each streak beginning and end |

| |Line 1: |Defect category |

| | |1-12 Streak |

| | |13 Web break |

| | |14 Length clearance |

| | |15 Set change |

| | |16 Cut |

| |Line 2: |Defect type (for categories 1 – 12) |

| | |5 Dark streak |

| | |6 Bright streak |

| | |7 Light streak |

| | |8 Gray streak |

| | |9 Other |

| |If defect category is 1 – 12, then the following lines |

| |Line 3: |MD location (dm) |

| |Line 4: |Defect location in CD (pixels) |

| |Line 5: |Distance from web edge in tender side (mm or 0.1 inch) |

| |Line 6: |Defect size in CD (0.1 mm) |

| |Line 7: |0 for start of streak, 1 for end of streak |

| |Line 8: |Unwound defect (1 = yes, 0 = no) |

| |Line 9: |Streak has started from hole (1 = yes, 0 = no) |

| |Line 10: |EMPTY |

| |If defect category is 13 – 16, then the following lines |

| |Line 3: |MD location (dm) |

| |Line 4: |Empty |

| |Because the number of lines has been so far dependent on the number of defects, the next line is|

| |the string “aaa”. |

|??? |aaa | |

|1 | |1st set change MD (dm) from start of reel |

|2 | |2nd set change MD (dm) from start of reel |

| | | |

|20 | |20th set change MD (dm) from start of reel |

|21 | |EMPTY |

| |In case there are less than In case there are less than 20 set changes in a reel, those set |

| |change lines not in use are set to zero. The Next 21 lines describe the roll cutting before the|

| |first set change (mm) |

|22 | |1st roll start point |

|23 | |1st roll end point |

|24 | |2nd roll end point |

| | | |

|43 | |20th roll end point |

|44 | |EMPTY |

|45 – 67 | |Same as lines 22 – 44 |

|68 – 485 | |Roll cutting after set changes from 2 to 20 |

| |In case there are less than 20 roll cuttings, those roll cutting lines not in use are set to |

| |zero. |

|??? |bbb | |

| |There are 20 lines for roll qualities of each set change in the file. Thus the number of roll |

| |quality lines is 21 x 20 = 420. |

| |Quality of roll 101 | |

| |Quality of roll 102 | |

| |… | |

| |Quality of roll 120 | |

| |… | |

| |Quality of roll 201 | |

| |Quality of roll 202 | |

| |… | |

| |Quality of roll 2120 | |

Appendix E:

Defect File Format Description

Unknown (Tappi reel number format)

|1 |Version |

|2 |Version Number |

|3 |Start time of reel |

|4 |End time of reel |

|5 |Total length of reel |

|6 |Sequence number |

|7 |Quality code (grade) string maximum 20 characters |

|8 |Parameter category (1..10) |

|9 |EMPTY |

|10 |Total dark formation number |

|11 |Total light formation number |

|12 |Number of formation samples |

|13 |EMPTY |

|14 |EMPTY |

|15 |1 if reel has been on history display, otherwise 0 |

|16 |Slabbed length of reel (dm) |

|17 |1 if data has been sent to ULMA ABS, otherwise 0 |

|18 |1 if drive side is on left, 0 if dive side is on right |

|19 |EMPTY |

|20 |Defect category 1: Number of removed defects |

|21 |Defect category 1: Length (dm) of removed streaks |

|22 |Defect category 1: Number of removed edge defects |

|23 |Defect category 1: Number of reomoved defect bursts |

|24..67 |Defect categories 2 – 12: Same as in lines 20 – 23 |

|68 |EMPTY |

|69 |Defect category 1: Minimum size in CD (0.1 mm or 0.01 inch) |

|70 |Defect category 1: Minimum size in MD (0.1 mm or 0.01 inch) |

|71 |Defect category 1: Output bit mask (16 bits) |

|72 |Defect category 1: Detection level (0.1%) |

|73..116 |Defect categories 2 – 12: Same as in lines 69 – 72 |

|117 |Output bit mask (16 bits) for edge defects |

|118 |Output bit mask (16 bits) for defect bursts |

|119 |EMPTY |

|120 |Unknown |

|121 |Reel number (Cddddddd where c is a character and d is a digit) |

|122 |Defect Counters |

|123 |Number of discrete defects in the defect buffer |

|124 |Number of starts and ends of streaks in streak buffer |

|125 |Web width (mm) |

|126 |Sum of the edge pixels on the camera #1 side |

|127 |Total number of edge scans on camera #1 side |

|128 |Sum of edge pixels on the last camera side |

|129 |Total number of edge scans on the last camera side |

|130 |EMPTY |

|131 |For each discrete defect |

| |Line 1: Defect category |

| |1 – 12 |hole or spot |

| |13 |web break |

| |14 |length clearance |

| |15 |set change |

| |16 |cut |

| |Line 2: Defect type |

| |1 |hole |

| |2 |dark spot |

| |3 |light spot |

| |4 |gray spot |

| |If defect category is 1 – 12, then the following lines |

| |Line 3: |Defect location in MD (dm) |

| |Line 4: |Defect location in CD (pixels) |

| |Line 5: |Distance from web edge in tender side (mm or 0.1 inch) |

| |Line 6: |Defect size in MD (0.1 mm). If this is the end of defect |

| | |burst, then this line contains the number of defects in the |

| | |burst. If this is the beginning of defect burst, then this is|

| | |a filler line. |

| |Line 7: |Defect size in CD (0.1 mm). If end of defect bursts, this is |

| | |a filler line. |

| |Line 8: |Defect distinction parameter: |

| | |0=Normal |

| | |1=Edge defect |

| | |2=Beginning of a defect burst |

| | |3=End of a defect burst |

| |Line 9: |Unwound defect (1 = yes, 0 = no) |

| |Line 10: |Patched defect (1 = yes, 0 = no) |

| |Line 11: |Number of defect shape data |

| |Line 12 – |Number of defect shape data; for each shape 2 lines |

| |12 + 2 * | |

| |Last line: |EMPTY |

| |If defect category is 13 – 16, then the following lines: |

| |Line 3: |MD location (dm) |

| |Line 4: |EMPTY |

|??? |For each streak beginning and end |

| |Line 1: |Defect category |

| | |1-12 Streak |

| | |13 Web break |

| | |14 Length clearance |

| | |15 Set change |

| | |16 Cut |

| |Line 2: |Defect type (for categories 1 – 12) |

| | |5 Dark streak |

| | |6 Bright streak |

| | |7 Light streak |

| | |8 Gray streak |

| | |9 Other |

| |If defect category is 1 – 12, then the following lines |

| |Line 3: |MD location (dm) |

| |Line 4: |Defect location in CD (pixels) |

| |Line 5: |Distance from web edge in tender side (mm or 0.1 inch) |

| |Line 6: |Defect size in CD (0.1 mm) |

| |Line 7: |0 for start of streak, 1 for end of streak |

| |Line 8: |Unwound defect (1 = yes, 0 = no) |

| |Line 9: |Streak has started from hole (1 = yes, 0 = no) |

| |Line 10: |EMPTY |

| |If defect category is 13 – 16, then the following lines |

| |Line 3: |MD location (dm) |

| |Line 4: |Empty |

| |Because the number of lines has been so far dependent on the number of defects, the next line is|

| |the string “aaa”. |

|??? |aaa | |

|1 | |1st set change MD (dm) from start of reel |

|2 | |2nd set change MD (dm) from start of reel |

| | | |

|20 | |20th set change MD (dm) from start of reel |

|21 | |EMPTY |

| |In case there are less thIn case there are less than 20 set changes in a reel, those set change |

| |lines not in use are set to zero. The Next 21 lines describe the roll cutting before the first |

| |set change (mm) |

|22 | |1st roll start point |

|23 | |1st roll end point |

|24 | |2nd roll end point |

| | | |

|43 | |20th roll end point |

|44 | |EMPTY |

|45 – 67 | |Same as lines 22 – 44 |

|68 – 485 | |Roll cutting after set changes from 2 to 20 |

| | |In case there are less than 20 roll cuttings, those roll |

| | |cutting lines not in use are set to zero. |

|??? |bbb | |

| |There are 20 lines for roll qualities of each set change in the file. Thus the number of roll |

| |quality lines is 21 x 20 = 420. |

| |Quality of roll 101 | |

| |Quality of roll 102 | |

| |… | |

| |Quality of roll 120 | |

| |… | |

| |Quality of roll 201 | |

| |Quality of roll 202 | |

| |… | |

| |Quality of roll 2120 | |

Revision History

|Date |Author |Comments |

|18-Dec-96 |CG |Completed Appendix A and C |

|19-Dec-96 |CG |Changed location parameters. |

|23-Dec-96 |CG |Changed escripti of location 1 |

|28-Feb-97 |CG |Added /edt /g /path; corrected digital states |

|1-Aug-97 |CG |Version 1.05a; Removed ; added code to print message|

| | |if timestamps in file are more than 10 minutes in the future. |

|11-Sep-97 |CG |Version 1.0.6 Added TZ parameter to command line. |

|22-Sep-97 |CG |Version 1.0.7 Added calculation of totals |

|25-Sep-97 |CG |Added note to turn compression and exception reporting off. |

|28-Jan-98 |CG |Version 1.2 Added /CR for reading files with edge crack data; |

| | |added more information regarding location of files; added listing |

| | |of file formats. |

|2-Feb-98 |CG |Added detailed escriptions of which file formats can be read |

|9-Feb-98 |CG |Version 1.3 Added /tap and Appendix E |

|6-May-98 |CG |Version 2.0 Added defect/streak attributes by type |

|21-Jun-99 |CG |Version 3.0 Interface now also runs on NT |

|22-Mar-02 |CG |Added to 3.2 for version |

|17-Apr-02 |HAB |Incorporated the ICU Control sections (3.0-3.2, doc rev A) |

|29-Oct-02 |CG |Clarified platforms in Supported Features Table; fixed headers & |

| | |footers |

|18-Aug-03 |CG |Updated version on title page |

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download