ࡱ> ,/ !"#$%&'()*+ Jbjbj 5P[:&o**77O<O<O<>>>@I >ݢkTkm(mm=x7A5O<7"88mmpP8mO<m ;0ma>Tbl0ݢB<,HXO< [w! Z  ݢ * 6: Universal File and Stream Loader Interface to the PI System Version 3.0.3.16 Revision D Copyright 2006-2009 OSIsoft, Inc. OSIsoft, Inc. 777 Davis St., Suite 250 San Leandro, CA 94577 USA (01) 510-297-5800 (main phone) (01) 510-357-8136 (fax) (01) 510-297-5828 (support phone)  HYPERLINK "http://techsupport.osisoft.com" http://techsupport.osisoft.com  HYPERLINK "mailto:techsupport@osisoft.com" techsupport@osisoft.com Houston, TX Johnson City, TN Longview, TX Mayfield Heights, OH Philadelphia, PA Phoenix, AZ Savannah, GA Yardley, PA OSIsoft Australia Perth, Australia Auckland, New Zealand OSI Software GmbH Altenstadt,Germany OSIsoft Asia Pte Ltd. Singapore OSIsoft Canada ULC Montreal, Canada Calgary, Canada OSIsoft, Inc. Representative Office Shanghai, Peoples Republic of China OSIsoft Japan KK Tokyo, Japan OSIsoft Mexico S. De R.L. De C.V. Mexico City, Mexico OSIsoft do Brasil Sistemas Ltda. Sao Paulo, Brazil Sales Outlets/DistributorsMiddle East/North Africa Republic of South Africa Russia/Central AsiaSouth America/Caribbean Southeast Asia South Korea Taiwan  HYPERLINK "http://www.osisoft.com" www.osisoft.com All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, mechanical, photocopying, recording, or otherwise, without the prior written permission of OSIsoft, Inc. OSIsoft, the OSIsoft logo and logotype, PI Analytics, PI ProcessBook, PI DataLink, ProcessPoint, Sigmafine, Analysis Framework, PI Datalink, IT Monitor, MCN Health Monitor, PI System, PI ActiveView, PI ACE, PI AlarmView, PI BatchView, PI ManualLogger, PI ProfileView, ProTRAQ, RLINK, RtAnalytics, RtBaseline, RtPortal, RtPM, RtReports and RtWebParts are all trademarks of OSIsoft, Inc. All other trademarks or trade names used herein are the property of their respective owners. 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 Table of Contents  TOC \o "1-3" \h \z \u  HYPERLINK \l "_Toc233168939" Terminology  PAGEREF _Toc233168939 \h vii  HYPERLINK \l "_Toc233168940" Introduction  PAGEREF _Toc233168940 \h 1  HYPERLINK \l "_Toc233168941" Reference Manuals  PAGEREF _Toc233168941 \h 2  HYPERLINK \l "_Toc233168942" Supported Features  PAGEREF _Toc233168942 \h 2  HYPERLINK \l "_Toc233168943" Configuration Diagram  PAGEREF _Toc233168943 \h 6  HYPERLINK \l "_Toc233168944" Principles of Operation  PAGEREF _Toc233168944 \h 9  HYPERLINK \l "_Toc233168945" Interface Startup  PAGEREF _Toc233168945 \h 9  HYPERLINK \l "_Toc233168946" Runtime Operations  PAGEREF _Toc233168946 \h 10  HYPERLINK \l "_Toc233168947" Use of PI SDK  PAGEREF _Toc233168947 \h 12  HYPERLINK \l "_Toc233168948" Performance Considerations  PAGEREF _Toc233168948 \h 13  HYPERLINK \l "_Toc233168949" Installation Checklist  PAGEREF _Toc233168949 \h 15  HYPERLINK \l "_Toc233168950" Data Collection Steps  PAGEREF _Toc233168950 \h 15  HYPERLINK \l "_Toc233168951" Interface Diagnostics  PAGEREF _Toc233168951 \h 16  HYPERLINK \l "_Toc233168952" Interface Installation  PAGEREF _Toc233168952 \h 17  HYPERLINK \l "_Toc233168953" Naming Conventions and Requirements  PAGEREF _Toc233168953 \h 17  HYPERLINK \l "_Toc233168954" Interface Directories  PAGEREF _Toc233168954 \h 18  HYPERLINK \l "_Toc233168955" PIHOME Directory Tree  PAGEREF _Toc233168955 \h 18  HYPERLINK \l "_Toc233168956" Interface Installation Directory  PAGEREF _Toc233168956 \h 18  HYPERLINK \l "_Toc233168957" Interface Installation Procedure  PAGEREF _Toc233168957 \h 18  HYPERLINK \l "_Toc233168958" Installing Interface Service with PI ICU  PAGEREF _Toc233168958 \h 19  HYPERLINK \l "_Toc233168959" Installing Interface Service Manually  PAGEREF _Toc233168959 \h 22  HYPERLINK \l "_Toc233168960" Digital States  PAGEREF _Toc233168960 \h 23  HYPERLINK \l "_Toc233168961" PointSource  PAGEREF _Toc233168961 \h 25  HYPERLINK \l "_Toc233168962" PI Point Configuration  PAGEREF _Toc233168962 \h 27  HYPERLINK \l "_Toc233168963" Point Attributes  PAGEREF _Toc233168963 \h 27  HYPERLINK \l "_Toc233168964" Tag  PAGEREF _Toc233168964 \h 27  HYPERLINK \l "_Toc233168965" PointSource  PAGEREF _Toc233168965 \h 27  HYPERLINK \l "_Toc233168966" PointType  PAGEREF _Toc233168966 \h 28  HYPERLINK \l "_Toc233168967" Location1  PAGEREF _Toc233168967 \h 28  HYPERLINK \l "_Toc233168968" Location2  PAGEREF _Toc233168968 \h 28  HYPERLINK \l "_Toc233168969" Location3  PAGEREF _Toc233168969 \h 28  HYPERLINK \l "_Toc233168970" Location4  PAGEREF _Toc233168970 \h 28  HYPERLINK \l "_Toc233168971" Location5  PAGEREF _Toc233168971 \h 28  HYPERLINK \l "_Toc233168972" ExDesc  PAGEREF _Toc233168972 \h 29  HYPERLINK \l "_Toc233168973" InstrumentTag  PAGEREF _Toc233168973 \h 30  HYPERLINK \l "_Toc233168974" Convers  PAGEREF _Toc233168974 \h 30  HYPERLINK \l "_Toc233168975" Scan  PAGEREF _Toc233168975 \h 30  HYPERLINK \l "_Toc233168976" Shutdown  PAGEREF _Toc233168976 \h 31  HYPERLINK \l "_Toc233168977" Output Points  PAGEREF _Toc233168977 \h 31  HYPERLINK \l "_Toc233168978" Configuration File  PAGEREF _Toc233168978 \h 33  HYPERLINK \l "_Toc233168979" General  PAGEREF _Toc233168979 \h 33  HYPERLINK \l "_Toc233168980" [INTERFACE]  PAGEREF _Toc233168980 \h 34  HYPERLINK \l "_Toc233168981" [PLUG-IN] ASCII Files  PAGEREF _Toc233168981 \h 35  HYPERLINK \l "_Toc233168982" [PLUG-IN] Serial Port  PAGEREF _Toc233168982 \h 38  HYPERLINK \l "_Toc233168983" [PLUG-IN] POP3  PAGEREF _Toc233168983 \h 40  HYPERLINK \l "_Toc233168984" Principles of Operation  PAGEREF _Toc233168984 \h 40  HYPERLINK \l "_Toc233168985" [SETTING]  PAGEREF _Toc233168985 \h 47  HYPERLINK \l "_Toc233168986" [FIELD]  PAGEREF _Toc233168986 \h 50  HYPERLINK \l "_Toc233168987" [MSG]  PAGEREF _Toc233168987 \h 54  HYPERLINK \l "_Toc233168988" Message Structure Definitions: [MSG(n)]  PAGEREF _Toc233168988 \h 56  HYPERLINK \l "_Toc233168989" Data Extraction to Fields  PAGEREF _Toc233168989 \h 59  HYPERLINK \l "_Toc233168990" Data Manipulation  PAGEREF _Toc233168990 \h 61  HYPERLINK \l "_Toc233168991" Arithmetic and Logical Operators  PAGEREF _Toc233168991 \h 61  HYPERLINK \l "_Toc233168992" Mathematical Functions  PAGEREF _Toc233168992 \h 62  HYPERLINK \l "_Toc233168993" String Functions  PAGEREF _Toc233168993 \h 62  HYPERLINK \l "_Toc233168994" DateTime and Time Functions  PAGEREF _Toc233168994 \h 63  HYPERLINK \l "_Toc233168995" IF Statement  PAGEREF _Toc233168995 \h 64  HYPERLINK \l "_Toc233168996" Arithmetic and Logical Operators - Examples  PAGEREF _Toc233168996 \h 64  HYPERLINK \l "_Toc233168997" MSG(n).Action  PAGEREF _Toc233168997 \h 68  HYPERLINK \l "_Toc233168998" Graphical User Interface (GUI) Facilitating the INI File Creation  PAGEREF _Toc233168998 \h 75  HYPERLINK \l "_Toc233168999" Startup Command File  PAGEREF _Toc233168999 \h 85  HYPERLINK \l "_Toc233169000" Configuring PI_UFL Interface with PI ICU  PAGEREF _Toc233169000 \h 85  HYPERLINK \l "_Toc233169001" UFL Interface page  PAGEREF _Toc233169001 \h 87  HYPERLINK \l "_Toc233169002" Command-line Parameters  PAGEREF _Toc233169002 \h 91  HYPERLINK \l "_Toc233169003" Sample PI_UFL.bat File  PAGEREF _Toc233169003 \h 94  HYPERLINK \l "_Toc233169004" Interface Node Clock  PAGEREF _Toc233169004 \h 95  HYPERLINK \l "_Toc233169005" Security  PAGEREF _Toc233169005 \h 97  HYPERLINK \l "_Toc233169006" Windows  PAGEREF _Toc233169006 \h 97  HYPERLINK \l "_Toc233169007" Starting / Stopping PI_UFL Interface  PAGEREF _Toc233169007 \h 99  HYPERLINK \l "_Toc233169008" Starting Interface as a Service  PAGEREF _Toc233169008 \h 99  HYPERLINK \l "_Toc233169009" Pausing Interface  PAGEREF _Toc233169009 \h 99  HYPERLINK \l "_Toc233169010" Stopping Interface Running as a Service  PAGEREF _Toc233169010 \h 99  HYPERLINK \l "_Toc233169011" The service can be removed (uninstall) by:  PAGEREF _Toc233169011 \h 99  HYPERLINK \l "_Toc233169012" Buffering  PAGEREF _Toc233169012 \h 101  HYPERLINK \l "_Toc233169013" Which Buffering Application to Use  PAGEREF _Toc233169013 \h 102  HYPERLINK \l "_Toc233169014" How Buffering Works  PAGEREF _Toc233169014 \h 102  HYPERLINK \l "_Toc233169015" Buffering and PI Server Security  PAGEREF _Toc233169015 \h 103  HYPERLINK \l "_Toc233169016" Enabling Buffering on an Interface Node with the ICU  PAGEREF _Toc233169016 \h 104  HYPERLINK \l "_Toc233169017" Choose Buffer Type  PAGEREF _Toc233169017 \h 104  HYPERLINK \l "_Toc233169018" Buffering Settings  PAGEREF _Toc233169018 \h 105  HYPERLINK \l "_Toc233169019" Buffered Servers  PAGEREF _Toc233169019 \h 107  HYPERLINK \l "_Toc233169020" Installing Buffering as a Service  PAGEREF _Toc233169020 \h 110  HYPERLINK \l "_Toc233169021" Interface Diagnostics Configuration  PAGEREF _Toc233169021 \h 113  HYPERLINK \l "_Toc233169022" Scan Class Performance Points  PAGEREF _Toc233169022 \h 113  HYPERLINK \l "_Toc233169023" Performance Counters Points  PAGEREF _Toc233169023 \h 113  HYPERLINK \l "_Toc233169024" Interface Health Monitoring Points  PAGEREF _Toc233169024 \h 113  HYPERLINK \l "_Toc233169025" Creating Health Monitoring Points Using the PI Tag Configurator  PAGEREF _Toc233169025 \h 113  HYPERLINK \l "_Toc233169026" I/O Rate Point  PAGEREF _Toc233169026 \h 117  HYPERLINK \l "_Toc233169027" For Users of Previous (2.x) Interface Versions  PAGEREF _Toc233169027 \h 121  HYPERLINK \l "_Toc233169028" Appendix A: Error and Informational Messages  PAGEREF _Toc233169028 \h 125  HYPERLINK \l "_Toc233169029" Appendix B: CSV (Comma Delimited) Data Files  PAGEREF _Toc233169029 \h 127  HYPERLINK \l "_Toc233169030" For Users of the PI Batch File Interface  PAGEREF _Toc233169030 \h 127  HYPERLINK \l "_Toc233169031" Data File Example  PAGEREF _Toc233169031 \h 127  HYPERLINK \l "_Toc233169032" Configuration File Example  PAGEREF _Toc233169032 \h 127  HYPERLINK \l "_Toc233169033" Bat File Example  PAGEREF _Toc233169033 \h 129  HYPERLINK \l "_Toc233169034" Explanation  PAGEREF _Toc233169034 \h 129  HYPERLINK \l "_Toc233169035" Appendix C: XML Document Files  PAGEREF _Toc233169035 \h 131  HYPERLINK \l "_Toc233169036" Data File Example  PAGEREF _Toc233169036 \h 131  HYPERLINK \l "_Toc233169037" Configuration File Example  PAGEREF _Toc233169037 \h 132  HYPERLINK \l "_Toc233169038" Bat File Example  PAGEREF _Toc233169038 \h 133  HYPERLINK \l "_Toc233169039" Explanation  PAGEREF _Toc233169039 \h 134  HYPERLINK \l "_Toc233169040" Appendix D: Reading Data from Serial Port  PAGEREF _Toc233169040 \h 135  HYPERLINK \l "_Toc233169041" Streams Patterns from Serial Port  PAGEREF _Toc233169041 \h 135  HYPERLINK \l "_Toc233169042" Configuration File Example  PAGEREF _Toc233169042 \h 135  HYPERLINK \l "_Toc233169043" Bat File Example  PAGEREF _Toc233169043 \h 136  HYPERLINK \l "_Toc233169044" Explanation  PAGEREF _Toc233169044 \h 136  HYPERLINK \l "_Toc233169045" Appendix E: Reading Data from POP3 Server  PAGEREF _Toc233169045 \h 137  HYPERLINK \l "_Toc233169046" Email Text  PAGEREF _Toc233169046 \h 137  HYPERLINK \l "_Toc233169047" Configuration File Example  PAGEREF _Toc233169047 \h 137  HYPERLINK \l "_Toc233169048" Bat File Example  PAGEREF _Toc233169048 \h 138  HYPERLINK \l "_Toc233169049" Explanation  PAGEREF _Toc233169049 \h 139  HYPERLINK \l "_Toc233169050" Appendix F: More Advanced Examples  PAGEREF _Toc233169050 \h 141  HYPERLINK \l "_Toc233169051" Data File Example  PAGEREF _Toc233169051 \h 141  HYPERLINK \l "_Toc233169052" Configuration File Example  PAGEREF _Toc233169052 \h 141  HYPERLINK \l "_Toc233169053" Point Configuration  PAGEREF _Toc233169053 \h 142  HYPERLINK \l "_Toc233169054" Bat File Example  PAGEREF _Toc233169054 \h 142  HYPERLINK \l "_Toc233169055" Explanation  PAGEREF _Toc233169055 \h 143  HYPERLINK \l "_Toc233169056" Appendix G: ASCII Codes Supported  PAGEREF _Toc233169056 \h 145  HYPERLINK \l "_Toc233169057" Appendix H: Tested Operating Systems  PAGEREF _Toc233169057 \h 147  HYPERLINK \l "_Toc233169058" Revision History  PAGEREF _Toc233169058 \h 149  Terminology In order to understand this interface manual, you should be familiar with the terminology used in this document. Buffering Buffering refers to an Interface Nodes ability to store temporarily the data that interfaces collect and to forward these data to the appropriate PI Servers. N-Way Buffering If you have PI Servers that are part of a PI Collective, PIBufss supports n-way buffering. N-way buffering refers to the ability of a buffering application to send the same data to each of the PI Servers in a PI Collective. (Bufserv also supports n-way buffering to multiple PI Server however it does not guarantee identical archive records since point compressions specs could be different between PI Servers. With this in mind, OSIsoft recommends that you run PIBufss instead.) ICU ICU refers to the PI Interface Configuration Utility. The ICU is the primary application that you use in order to configure and run PI interface programs. You must install the ICU on the same computer on which an interface runs. A single copy of the ICU manages all of the interfaces on a particular computer. You can configure and run an interface by editing a startup command file. However, OSIsoft discourages this approach. Instead, OSIsoft strongly recommends that you use the ICU for interface management tasks. Interface Node An Interface Node is a computer on which the PI API and/or PI SDK are installed, and PI Server programs are not installed. PI API The PI API is a library of functions that allow applications to communicate and exchange data with the PI Server. All PI interfaces use the PI API. PI Collective A PI Collective is two or more replicated PI Servers that collect data concurrently. Collectives are part of the High Availability environment. When the primary PI Server in a collective becomes unavailable, a secondary collective member node seamlessly continues to collect and provide data access to your PI clients. PIHOME PIHOME refers to the directory that is the common location for PI client applications. A typical PIHOME is C:\Program Files\PIPC. PI interfaces reside in a subdirectory of the Interfaces directory under PIHOME. For example, files for the PI_UFL Interface are in C:\Program Files\PIPC\Interfaces\PI_UFL. This document uses [PIHOME] as an abbreviation for the complete PIHOME directory. For example, ICU files in [PIHOME]\ICU. PI SDK The PI SDK is a library of functions that allow applications to communicate and exchange data with the PI Server. Some PI interfaces, in addition to using the PI API, require the use of the PI SDK. PI Server Node A PI Server Node is a computer on which PI Server programs are installed. The PI Server runs on the PI Server Node. PI SMT PI SMT refers to PI System Management Tools. PI SMT is the program that you use for configuring PI Servers. A single copy of PI SMT manages multiple PI Servers. PI SMT runs on either a PI Server Node or a PI Interface Node. Pipc.log The pipc.log file is the file to which OSIsoft applications write informational and error messages. While a PI interface runs, it writes to the pipc.log file. The ICU allows easy access to the pipc.log. Point The PI point is the basic building block for controlling data flow to and from the PI Server. For a given timestamp, a PI point holds a single value. A PI point does not necessarily correspond to a point on the foreign device. For example, a single point on the foreign device can consist of a set point, a process value, an alarm limit, and a discrete value. These four pieces of information require four separate PI points. Service A Service is a Windows program that runs without user interaction. A Service continues to run after you have logged off from Windows. It has the ability to start up when the computer itself starts up. The ICU allows you to configure a PI interface to run as a Service. Tag (Input Tag and Output Tag) The tag attribute of a PI point is the name of the PI point. There is a one-to-one correspondence between the name of a point and the point itself. Because of this relationship, PI System documentation uses the terms tag and point interchangeably. Interfaces read values from a device and write these values to an Input Tag. Interfaces use an Output Tag to write a value to the device. Introduction This document describes OSIsofts Universal File and Stream Loader (PI_UFL) interface to the PI System. It describes how to configure it as well as how to use it effectively. PI_UFL interface reads data from various ASCII stream data sources. Its modular concept is built on the functionality division the core part of the interface does the stream parsing and data forwarding to PI, while the actual data reading, which is proprietary to each data source, is implemented in dynamically loaded libraries (DLLs). These data sources must produce readable (ASCII) data; that is, ASCII streams with (repeatable) patterns. The interface parses those patterns and extracts the information the user specifies in a configuration file. As mentioned above, the interface is shipped with three DLLs, which implement the actual communication to the sources of ASCII text data: ASCII files: PI_UFL cyclically processes a given directory while looking for file names that match the user defined criteria (the directory and the file name pattern is one of the interfaces parameters). The interface thus scans the specified directory and if a file name matches the specified pattern, it opens the file, reads its content and looks for lines that pass the specified filters. After a file is processed, the interface renames the file and, optionally, deletes it. Reading data from Serial Ports (RS 232) works similarly. The interface continuously reads the specified serial port and when it encounters a character(s) that signals the end-of-the-line, it stores this line in a (memory) container. In the defined intervals, this memory is emptied and the lines processed, again looking for the specified patterns. The POP3 PlugIn periodically checks emails sent to the specified POP3 user on the given POP3 server. Emails are downloaded, processed and, finally, they are deleted. As stated in the previous paragraph, the ASCII streams from the data sources need to be processed and parsed. A mandatory startup parameter the PI_UFL interface needs is therefore the path to the configuration file. This config. (INI) file actually controls how the interface identifies and manipulates the retrieved lines. The basic principle is very simple. The data is examined line by line. Each line is checked to see whether it matches one of the several sets of criteria (filters) and in case a line satisfies a given filter, it is assigned a certain message type and is further broken into fields. The content of these fields is then assigned to variables, which can take part in arithmetic expressions. The results are finally forwarded to PI. Note: The PI UFL Interface is a replacement for the PI Batch File interface. Users of the PI Batch File interface should read  HYPERLINK \l "_Appendix_C:_CSV" Appendix B: CSV (Comma Delimited) Data Files before upgrading to PI UFL. Note: To operate the interface effectively, users must thoroughly read the  HYPERLINK \l "_Configuration_File" Configuration File section of this manual which describes in detail the required syntax for that file. The Interface runs on Intel machines with Microsoft Windows operating system (2000, XP, 2003, Vista, Windows 2008 Server). See  HYPERLINK \l "_Appendix_I_:" Appendix H : Tested Operating Systems for a full list of tested operating systems. The Interface Node may be either a PI home or PI Interface node see the  HYPERLINK \l "_Configuration_Diagram" Configuration Diagram section of this manual. This document contains the following topics: Brief design overview Installation and operation details PI points configuration details (points that will receive data via this interface) Configuration file specifications Supported command line parameters Examples of various configuration files (including a brief explanation of each presented feature) in appendices B,C and D  CAUTION! See chapter  HYPERLINK \l "_For_Users_of" For Users of Previous (2.x) Interface Versions that lists all the changes implemented in PI_UFL 3.x! Reference Manuals OSIsoft PI Server manuals PI API and PI SDK Installation manual UniInt Interface User Manual Supported Features FeatureSupportPart NumberPI-IN-OS-UFL-NTI*PlatformsWindows 2000 SP3 & SP4 / XP / 2003 / Windows Vista, Windows 2008 ServerAPS ConnectorNoPoint Builder Utility NoICU ControlYesPI Point TypesPI 3: int16 / int32 / float16 / float32 / float64 / digital / stringSub-Second TimestampsYes Sub-Second Scan ClassesNoAutomatically Incorporates PIPoint Attribute ChangesYesException ReportingYesOutputs from PINoInputs to PI Scan-BasedSupports Questionable BitYesMaximum Point CountUnlimitedSupports Multi-character PointSourceYes*Uses PI SDKYesPINet String SupportNo* Source of TimestampsCurrent time or from the input stream(s).* History RecoveryYesFailoverNo* UniInt-based Disconnected Startup SetDeviceStatusNo No YesVendor Software Required on PI API / PINet NodeNot applicableVendor Software Required on Foreign DeviceNot applicableVendor Hardware RequiredNot applicableAdditional PI Software Included with InterfaceNot applicableDevice Point TypesNot applicable* Serial-Based InterfaceYes* See paragraphs below for further explanation. Platforms The Interface is designed to run on the above mentioned Microsoft Windows operating systems and their associated service packs. Uses PI SDK The PI SDK and the PI API are bundled together and must be installed on each PI Interface Node. This Interface specifically makes PI SDK calls to create PI Points, and write PI Annotations. See section  HYPERLINK \l "_Use_of_PI" Use of PI SDK for more details. Source of Timestamps Timestamps are read from the input file or, when not specified, the current (Interface Node local time) is used. History Recovery History recovery is automatically included with a file-based interface. After the interface has been down for some reason, and, as long as the data files were not deleted, PI_UFL will process them during the 1st scan cycle after the start; no matter how much data is stored in these files and no matter how long the interface has been down. In case the interface communicates with data sources that do not persist the data (e.g. into ASCII files), there is nothing to recover from. This is the case when the interface communicates with a serial port. UniInt-based Note: PI_UFL is NOT a UniInt-based interface! There are several relevant reasons: PI_UFL can operate without the PointSource; the /PS= start-up parameter is not mandatory. PI_UFL stores values to PI Annotations PI_UFL automatically creates new PI Points and Digital Sets/States PI_UFL is designed with the modular concept of PlugIns At the time of writing, neither of the above listed features was applicable to UniInt.  PI_UFL is, to the maximum possible extent, designed as if it were built on the UniInt library. However, it must be recognized that 100% compatibility with all UniInt features has NOT been achieved. SetDeviceStatus Since version 3.0.3.16 PI_UFL implements Health Points. One of them is marked by [UI_DEVSTAT] in the Extended Descriptor and represents the status of the source device. The following events are written into the Device Status Health Point: Starting The interface has been started, has initialized the given PlugIn and is waiting for the first scan class. Good the interface is properly communicating and gets data from a data source (that is, from a directory with files, from a serial port or POP3 server). Intf Shutdown the interface was shut down. Note: Please use PI ICU (Interface Configuration Utility) to configure PI Health Tags. See more details in chapter  HYPERLINK \l "_Interface_Health_Monitoring" Interface Health Monitoring Points. Serial-Based Interface This interface can run with a serial connection. Server class machines often have inferior serial ports. Server class machines are not required for most interfaces and should not be used, especially not when serial port connections are required. Recent Dell server class machines are using only 3 volt power supplies to drive the serial port IEEE RS232 specification requires at least +/- 4.7 volts for a valid RS232 signal. Some recent model HP and Dell server class machines have been observed to have serial port circuitry which overheat and experience thermal shutdown after a few minutes or hours of operation over long cables or high speeds. (So called self-powered serial port extenders should not be used for interfaces.) Customers often attempt to extend serial port ranges using twisted pair wire devices or fiber optic cable devices. Devices with their own external power source (e.g. a wall wart transformer or other power source) should be the only types used. Devices which leach power from the PCs serial port will have difficulty at high data speeds (baud rates) or long cables. In some applications a cable more than 20-50 feet long may be considered long. Higher speeds and/or longer cables translate to sharply increased power supply demand by the serial port hardware. Configuration Diagram The drawing below depicts the basic configuration of the hardware and software components in a typical scenario used with the PI_UFL Interface:  Figure  SEQ Figure \* ARABIC 1. PI_UFL Configuration Diagram PI Home Node with PI Interface Node Or  Figure  SEQ Figure \* ARABIC 2 Hardware Diagram All PI Software installed on one node Principles of Operation A brief description of the basic principles has been given in the  HYPERLINK \l "_Introduction" Introduction chapter. Following paragraphs have more details: Interface Startup At startup, the PI_UFL interface checks the correctness of the specified start up parameters and continues with processing of the configuration (INI) file. As mentioned in the  HYPERLINK \l "_Introduction" Introduction chapter, the configuration file tells the PI_UFL interface how to extract and interpret data streams from the given data source. After the interface is started, it performs a series of syntax checks on the message parsing constructions and expressions specified in the INI file that is, it compiles it. If errors are found, detailed info about them is written to the output log file and the interface halts. Once the configuration file has been read and successfully compiled, the interface accesses the PI Point database according to the specifications found on the startup command line. The following paragraphs describe various modes depending on the presence of the following startup parameters - /ps and /tm. If the /ps parameter was specified, all PI points with that PointSource will be loaded into the interfaces memory and this list will be continuously updated through the signup for points update mechanism. The same is true for points that fit the /tm pattern. Both parameters (/ps and /tm) thus define the PI points that are loaded while the interface starts. If neither of the two was specified, no PI points will be loaded at startup. However, the interface will then continuously build its internal tag list out of the TagNames that appear in the data files as they arrive; that is, the list will be created dynamically. Note: the /ps (as well as the /tm) startup parameters are optional. Sending data to any PI tag is a feature that differentiates PI_UFL from the majority of OSIsoft interfaces! When used, both parameters also make sure the interface will write values only to tags that comply with the given specification. That is, if for instance, the /tm is set and a TagName arrives that does not fit the /tm specified pattern, the interface will NOT send the data to this tag. Neither will it create it. Simultaneous use of /ps and /tm is NOT supported! Note: If the configuration file specifies the value should be sent to PI via the string pattern found in the InstrumentTag (see section  HYPERLINK \l "_InstrumentTag" InstrumentTag) such a tag has to already be loaded into the internal interfaces tag-list. In case it is not, the value for this tag will be skipped (it will NOT be sent to PI). The reason is that PI Point database is not indexed by the InstrumentTag attribute and any on-line searching via this attribute is potentially expensive. The /ps or the /tm are thus required for addressing via the InstrumentTag. If all the configuration steps and checks during the start-up phase are completed, the interface continues with run-time operations: Runtime Operations During the run-time, the PI_UFL interface checks, at regular time intervals, whether new input files, emails have been created/received, or whether new lines have been identified on a serial port. This frequency is specified as the start-up parameter /f=hh:mm:ss on the command line (for more information on command-line parameters, see the  HYPERLINK \l "_Command-line_Parameters_1" Command-line Parameters section of this manual). Note: The PI_UFL interface supports just ONE scan class. The following bullets discuss what steps the runtime operations consist of: PI_UFL interface checks each input line against the filter declarations given in the configuration file. As soon as the input line satisfies any of the specified filters (see the description of the keyword  HYPERLINK \l "_MSG(n).Filter" MSG(n).Filter), the line is assigned a certain message type and is consequently broken into individual fields. These fields can be named and treated as variables. They can optionally take part in expressions. Fields (variables) are finally sent to PI via the StoreInPI() function:  HYPERLINK \l "_StoreInPi_(Tag,_InstrumentTag," StoreInPI (Tag, InstrumentTag, Timestamp, Value, Status, Questionable, [Annotation]). Following is an example, showing the described principles and used terminology: [field] field(1).name = time field(2).name = value field(3).name = tag [msg] msg(1).name = message1  [message1] message1 = C1==Line containing * time=C27-C46 value=C54-C56 tag=C62-C69  SHAPE \* MERGEFORMAT  message1.action = StoreInPi(tag,,time,value,,) Note: If the input message does not satisfy any filter definition, it is skipped and NO error is reported. The text lines are thus processed by the INI file as if it were a procedure and the lines input parameters. Which data source will the interface talk to; that is, which DLL it will load is specified in the PLUG-IN entry of the INI file in section [INTERFACE]. The following bullets list the main features (and corresponding run-time steps) implemented in the three installed DLLs AsciFiles.DLL, Serial.DLL and POP3.DLL. ASCII Files: Data files are processed in settable order they can be sorted according to the creation date, modification date and according to the actual file name. The sorting mode is given via the INI file (see the description of the  HYPERLINK \l "_IFS" IFS keyword). Note: Before the interface opens a data file, it moves it into the directory with the PI_UFL executable and temporarily renames it by prefixing the original name by the underscore. Then the whole file is read into the memory and the lines are processed. Thus new files (with the same name) can be copied into the data directory even if the interface is currently processing a file. After an input file has been processed, it is renamed with an extension indicating successful or erroneous processing. By default, the extension indicating a successful processing is ._OK; any runtime error causes the processed file is added the .ERR suffix. Both extensions can be explicitly specified. See chapter  HYPERLINK \l "_Configuration_File" Configuration File for more details. After the given time period, files that have been processed without errors will be deleted. This purge interval is specified by the PURGETIME keyword in the section [PLUG-IN] of the configuration file. Files that were given the .ERR suffix are NOT purged. The default purging period is one day (PURGETIME = 1d) and the purge time period represents the interval