Allen-Bradley RSLinxcdn.osisoft.com/interfaces/95/PI_ABRSLinx_3.02.doc · Web viewAllen-Bradley...

Allen-Bradley RSLinxInterface to the PI System

Version 3.02 and greaterNovember 30, 2000

How to Contact UsPhone (510) 297-5800 (main number)

(510) 297-5828 (technical support)

Fax (510) 357-8136

Internet [email protected]

World Wide Web

http://www.osisoft.com

Mail OSI Software, Inc.P.O. Box 727San Leandro, CA 94577-0427USA

OSI Software GmbH Hauptstrae 30 D-63674 Altenstadt 1Deutschland

OSI Software, LtdP. O. Box 8256Level One, 6-8 Nugent StreetAuckland 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 (c)(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.Allen Bradley RSLink PI-IN-SI-SIMAT-NT

2000 OSI Software, Inc. All rights reserved777 Davis Street, Suite 250, San Leandro, CA 94577

iii OSI Software Inc.

http://www.osisoft.com/

mailto:[email protected]

Table of Contents

Introduction...........................................................................................................................1

Interface Design Overview...................................................................................................2Interface Point List...............................................................................................................4

Input and Output.................................................................................................................4

Time Stamps.......................................................................................................................4

Solicited Mode PI Point Definition.......................................................................................5

Unsolicited Data Collection................................................................................................12Setting up a Message Block..............................................................................................12

Unsolicited Mode PI Point Definition.................................................................................12

Order of Pre/Post Processing............................................................................................15

Software Configuration......................................................................................................16PI Software – PI 2 Systems...............................................................................................16

PI-RSLinx Interface Files - NT and UNIX..........................................................................16

PIRSLINX.BAT / PIRSLINX.SH.....................................................................................17INI File...........................................................................................................................22Rate Counter – IORATES.DAT file................................................................................23

Installation...........................................................................................................................24Installation - NT and UNIX.................................................................................................24

Interface Operation.............................................................................................................25Interface Operation - NT and UNIX...................................................................................25

Startup - NT...................................................................................................................25Startup - UNIX...............................................................................................................26Shutdown.......................................................................................................................26Information and Error Messages - NT............................................................................27Information and Error Messages - UNIX........................................................................27

Common Errors Returned from the RSLinx.......................................................................28

November 30, 2000 iii

Appendix A. Data Table Specifications.............................................................................30

Appendix B. Configuring the INI file..................................................................................33

Appendix C. Old Style Data Addressing Scheme............................................................35

Appendix D. Troubleshooting Tips....................................................................................37

Appendix E. Configuring the RSLinx UNSOL.INI File......................................................39

Appendix F. PI-RSConvert Conversion Utility..................................................................40

iv OSI Software, Inc.

IntroductionThis document describes Oil System's Allen-Bradley RSLinx Interface to the Plant Information (PI) System. The Interface runs with Allen Bradley's RSLinx (NT) or INTERCHANGE (HP-UX) software. When using RSLinx, install the Allen-Bradley RSLinx vendor software on an Intel 486 or Pentium based machine running Windows NT version 3.51 or later. When using INTERCHANGE, install the Allen-Bradley INTERCHANGE software on a HP-UX workstation running version 10.10 or 10.20. The selected machine may be a PI-Home or PI-API node.

For more information about software requirements, see the Software Configuration section.

The Interface supports communications to any PLC-2, PLC-3, PLC-5, or SLC 500 processor on a Data Highway or Data Highway Plus Link. In addition, the Interface can obtain data directly from Ethernet PLCs or through a serial port via the DF1 protocol. Drivers for Ethernet, 1784-KT, 1784-KTX, 1784-PCMK, the Serial DF1 full duplex protocol, and perhaps other protocols are included with the RSLinx package distributed by Rockwell Software. The interface can also support communication with the WinLinx and ControlLogix gateway controllers, although the interface cannot talk to an INTERCHANGE module if the ControlLogix gateway is being used.

Note: If data will be gathered directly from the ControlLogix processor, the PI-OPC interface should be used in place of the PI-RSLinx interface.

To access data, the user defines groups of tags known as data tables. The Interface collectively scans these data tables either at a user defined rate or based on events of a specified tag. In addition, the Interface allows for output of data tables based on events.

The interface operates in two mutually exclusive modes, solicited and unsolicited. In solicited mode, the Interface scans data tables either at a user defined rate or based on events of a specified tag. In solicited mode, the interface also allows for output of data tables based on events. In unsolicited mode, the interface defines data tables to the INTERCHANGE (or RSLinx) server with unique addresses for a single interface. Devices on the Allen-Bradley network may then direct data to these data items based upon the destination address. In INTERCHANGE parlance, this is called an unsolicited write to the host application. Currently the interface does not support unsolicited reads from PI to the Allen-Bradley network.

To operate the Interface effectively, the user must be familiar with Rockwell-Software’s RSLinx or INTERCHANGE software. In particular, the user must know how to specify which data in the PLC the Interface will be accessing. In addition, the user should possess the appropriate RSLinx, INTERCHANGE or DTL (Data Table Library) documentation set.

After this introduction, this document contains a brief design overview followed by the details of creating points to be scanned by this Interface. Subsequent sections provide an overview of the hardware and software configurations while instructions for operation and installation are contained at the end.

November 30, 2000 1

Allen-Bradley RSLinx Interface Documentation to the PI System

What is UniInt?UniInt stands for Universal Interface, and it is an OSI-developed template used to create many of our interfaces. UniInt is not a separate product or file, it is solely a template used by our developers, and is integrated into the 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. UniInt is constantly being upgraded with new options and features. In any UniInt interface, some of the supplied configuration parameters are used by the UniInt features of the interface, and some are used by the interface-specific features of the interface.

The Supported Features TableSupported Features

Platforms NTI

PI Point Types digital, integer, float (16 & 32 bit), string

Sub-second Timestamps Yes

Sub-second Scan Classes Yes

Automatically Incorporates PI Point Attribute Changes

Yes

Exception Reporting Yes

Outputs from PI Yes

History Recovery* No

Failover* No

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

All types

UniInt-based Yes

Maximum Point Count Unlimited

SDK No

Vendor Software Required on PI API / PINet node*

Yes

Vendor Software Required on DCS System* Yes

Vendor Hardware Required* No

Additional PI Software Included with Interface* No

see paragraphs below for further description

History Recovery

History Recovery is not applicable to this interface.

2 OSI Software, Inc.

FailoverThe PI-RSLinx interface can be run in a Microsoft Clustered Environment. The interface would run simultaneously on both the Primary and Backup Cluster Nodes, but only the Primary Node would send data to the PI Server. If the current data collecting node should go down or if the interface itself stops on the primary node, then the secondary interface will start sending it's data to PI instead.

Vendor Software Required

The customer is required to purchase one of the following software packages from Rockwell Software/Allen Bradley:

9355-WABENE (RSLinx Professional Software) <or>

9355-WABOEMENE (RSLinx OEM Software)

The interface must run on the same PC where RSLinx is installed and running.

Vendor Hardware Required

No vendor hardware is required.

Additional PI Software

No additional PI software is included.

Diagram of Hardware Connection:

November 30, 2000 3


Interface Design OverviewThe RSLinx Interface consists of a single executable program and a number of utility files for the interface startup and shutdown. The Interface must be installed on either a HP-UX workstation (version 10.10 or 10.20) or an Intel 486 or Pentium based machine running Windows NT version 3.51 or later. For NT, RSLinx OEM software (part #9355-WABOEM) or the full RSLinx package (part #9355-WAB) must be installed before operation of the Interface can be successful. For HP-UX, the INTERCHANGE software (part #9351-HPUS) is required for successful operation.

Multiple copies of this interface can run on a single machine; however, each Interface will need to communicate through its own dedicated communications device, (i.e. 1784-KT Card, COM port, etc.). The PI System can support multiple RSLinx interfaces each running on its own PI or PI-API node.

Interface Point ListAt startup, the RSLinx Interface scans the PI Point Database for all associated PI points and builds a point list. This list is composed of all unique Data Table (DT) Definitions and all points associated with each Data Table. The Interface performs bounds checking on all important point attributes, and each Data Table Definition is passed to the Data Table Library for verification. Not all of the parameters in the Data Table Definition string can be verified before communication with the remote A-B PLC processor is attempted. Therefore, specifying invalid remote PLCs can introduce errors that are not well defined.

The Interface signs up for point updates and updates (approximately every 2 minutes) its point list: adding, changing, or deleting points as necessary. Large changes to the point database can result in a short break in scanning while the interface reconfigures its tag list.

Input and OutputThe RSLinx Interface supports, in solicited mode, both data input and data output with any PLC-2, PLC-3, PLC-5, PLC-5/250 or SLC 500 processor on a Data Highway or Data Highway Plus Link. In addition, the Interface supports bidirectional access to Ethernet PLCs as well as through the DF1 serial port protocol. All data transactions take place in the form of Data Table transfers. A Data Table (DT) is defined by its starting address, the number of elements, and additional routing information that specifies routing to the remote hardware.

Input Data Tables may be associated with multiple points, improving communications efficiency and overall throughput. For output data points, a unique output Data Table must be defined for each point. To improve performance, output data are only sent based on events of the source tag for the output point.

Time StampsData scanned by the RSLinx Interface are put into the snapshot using the PI Server’s Windows NT system time that corresponds to the time the data are received. Time Stamps are not used in conjunction with output data. Subsecond timestamps are now supported for input points.


Solicited Mode PI Point DefinitionA PI Point or Tag corresponds to a single parameter in a programmable controller. For example, a counter, a set point, a process variable, and the high and low control limits would each serve as a separate point in the PI System Database. Each of these points must be defined and configured individually using either the PI Tag Configurator, PIConfig or PIDIFF utilities. The following describes the PI point configuration for use with the RSLinx Interface. For more information regarding point configuration, see the Data Archive (DA) section of the PI System Manuals.

Note: PI2 and PI3 point requirements differ in some instances with respect to the content of the point database fields; these differences will be pointed out.

Tag

Tag refers to the PI tag name of the PI-RSLinx point. The interface can handle PI tag names with a maximum of characters; however, when the interface logs messages in the interface log, it will only print the first 12 characters of a tag name, for both PI2 and PI3 systems.

PointSource

All points defined in the PI Point Database for use with the RSLinx Interface must share a common point source. The point source may be any single character or symbol. In PI 2, the point source for the interface must be defined in the point source library before interface operation (see Software Configuration).

PointType

The interface supports all PI point types except for the PI 3 blob point type.

Note that an Integer (PI 2), an int16 (PI 3) and a float16 (PI 3) are 15-bit unsigned integers with a possible range of 0 to 32,767. If a value collected by the Interface is outside of this range, a Real (PI 2), int32 (PI 3), or float32 (PI 3) point type should be used. Otherwise, the value will be flagged as "Under Range" or “Over Range”.

Note: Negative integer and string point support was added in version 3.0 of the interface. String output tags are only supported if the version of the PI-API is 1.3.2 or greater.

Location1

The first location is the interface number. There can be up to 256 copies of the interface running using the same point source. That is, each RSLinx Interface System requires a unique interface to the PI System, identified by any arbitrarily chosen integer number from 1 to 256. This is used to distinguish the Interface from multiple RSLinx interfaces running on the same or different nodes.

November 30, 2000 5


Location2

The second location parameter specifies the data type on the foreign device. The following table lists the different supported data types.

Location 2 Parameter Description

Element Size (in Bytes)

0 RAW (single byte) 1

1 WORD (16 bit) 2

2 LONG WORD (32 bit) 4

3 3 DIGIT BCD (not PLC5) 2

4 4 DIGIT BCD (not PLC5) 2

5 FLOAT (except PLC-3) 4

6 FLOAT (PLC-3) 4

7 FLOAT (SLC500) 4

8 LONG WORD(PLC-3) 4

9 UNSIGNED WORD (16 bit) 2

10 3 DIGIT BCD (PLC5) 2

11 4 DIGIT BCD (PLC5) 2

12 String (PLC5) 84

13 ASCII (two characters per element) 2

Location3

The third location parameter specifies the offset location of this point's data in a data table. The offset location is specified as an integer number of bytes with the first byte in a data table having an offset location of 0. By default, output data has an offset of zero (0). If the data table has multiple elements, you must consult the above chart to decide how to set the offset for elements other than the first one in the table. For instance, if you have a data table that is collecting two float values, the first one would be retrieved using an offset of 0 and the second would be retrieved using an offset of 4, since the Float data type is 4 bytes long according to the chart above. Similarly, if you were collecting 3 string values in one table, the second string would be retrieved using an offset of 84 and the third would be retrieved using an offset of 168.

It is important to configure your data tables to collect multiple data points whenever possible to improve performance. For example, if you need to collect data for the range of points from N7:10 to N7:19, you would create one data table (using the extended descriptor) for all ten of these points. Then, you would use Location3 to set the offset into the data table for each tag. In this example, the offset for N7:14 would be 8, because each element is two bytes long in the N table and N7:14 is the fourth element (N7:10 is the 0 th element) in the data table. By the same logic, the offset for N7:10 would be 0, and the offset for N7:11 would be 2.


Note: Most Allen-Bradley hardware uses word or two byte registers whereas the offset specified in location parameter 3 must correspond to the offset in bytes (not registers) of the desired data from the starting address. For example, a floating point or long word register will contribute to a four byte offset while a word register contributes to a two byte offset. For example, if a data table range is setup to read 10 elements starting at Float file type F19:10, then elements F19:10 through F19:19 will be read. If a tag in that data table is to read element F19:11 then the Location3 parameter, referring to bytes, would be at offset 4 not 1. Similarly F19:19 would be specified as offset 36 not 9.

Location4

The fourth location is used to specify the scan class number for inputs. Scan Classes are defined on the startup command line for the Interface. The value entered in Location4 must specify one of the scan classes entered on the command line where the scan classes are established in the order they are listed on the command line.

For details on configuring each scan class, see the discussion of the /f parameter under the Software Configuration section.

Location4 should be 0 for output and event tags.0 = output and event tags1 = 1st Scan Rate found on command line2 = 2nd Scan Rate found on command line…n = nth Scan Rate found on command line

Note: It is vital that all tags in a particular data table have the same scan class number. You cannot scan some tags in a data table at different rates than other tags in the table. Location4 must be the same for each tag in the data table. For more information on data tables, see the Extended Descriptor discussion later in this document.

Note: String output tags are only supported if the version of the PI-API is 1.3.2 or greater.

Location5

Location parameter 5 is interpreted as a flag bit field. Currently only bit position number 1 is being interpreted.

Bit Position (1-16) Description

1 Scaling Flag (ON = Scaling)

2-16 Undefined

The scaling flag indicates whether the interface will execute a linear transformation on the incoming data. The transformation uses the zero, span and the conversion factor in conjunction with the incoming data, to generate the value to send to the snapshot.Value(snapshot) = ( Value(input) * span / convers ) + zero

Scaling may only be applied to input (scanned) with a point type of real (float). If no scaling is specified then the conversion factor acts as it used to, (i.e., as a direct multiplier of the incoming value), with real and integer tags. (Neither scaling nor conversion factors apply to digital tags.)

November 30, 2000 7


InstrumentTag

The InstrumentTag field may be used to specify an optional bit mask for interpretation of scanned (read) data only. This bit mask can be specified by including the following statement:bm=<bit_mask>

The bit mask should only be used with word register data and for PI integer or digital tags.

It is disregarded if the point is a PI real tag. If a bit mask is omitted then the default is NO bit mask. To define a bit mask, the starting and ending bit positions are specified. Bits are ordered from 0 (the low end bit) to 15 (the high end bit). The following formula is used to calculate the bit mask:ending bit position + ( 100 * starting bit position ) + 10000 = Bit Mask

For example, if we wanted to look at just the first bit in the scanned word, we would specify a bit mask of 10000:0 + (100 * 0) + 10000 = 10000.

If bits 4 through 7 correspond to the states of a control loop, we would access them by specifying a bit mask in location parameter 4 equal to 10407:7 + (100 * 4) + 10000 = 10407.

This could then correspond to 16 states in a Digital State Set, if the tag’s point type is Digital.

Convers

The conversion factor is a straight multiplier on the raw data. The conversion factor may be used to shift decimal places or as scaling parameters. The default is 1.0 if this entry is omitted, which means no scaling is applied.

SquareRoot

The square root code is used by the interface to square or to take the square root of the raw data. The square root code may be applied to either input or output data. The default code if no entry is specified is 0. The following codes apply:

SquareRoot Code

Result

0 raw value

1 square root of raw value

2 raw value is squared

Exception Specs (ExcDev, ExcMin, ExcMax)

The RSLinx Interface automatically performs exception reporting on scanned data. For discrete points all changes are considered to be an exception. For floating point and integer inputs, an exception only occurs when the difference between the current value and the last exception is greater than the dead band. To prevent exception reporting, set all exception reporting parameters to zero.


Scan

The scan flag of a tag is used by the interface to determine if the interface should update its snapshot. This allows the user to stop processing values for a point while the interface is on-line. However, this does not stop the Interface from reading data tables. Thus, the scan flag may not be used to affect communications traffic in the case of read or input data. However, the scan flag will suppress the writing of output points. The digital state SCAN OFF will be written to input tags whose scan flag is off and to output tags, which have a source tag.

Extended Descriptor (ExDesc)

The extended descriptor specifies the following Data Table and scanning information:

Data Table Number

Data Definition String

Event/Trigger Tag (optional)

A semicolon separates each of the above fields within the extended descriptor.

The Interface reads and writes data in the form of a user-defined Data Table. It is important to understand that the Data Table is created when the interface detects a tag with a new data table number. Every subsequent tag that is configured to use this data table number MUST use the same extended descriptor as the original tag. If the data table needs to be changed and more than one tag is using the data table, then you must either edit every tag in the data table, then stop and restart the interface. Or, you must remove each tag from the interface list (change the pointsource or turn scan to OFF), then make the changes to all of them at once, and add them all back in.

Every Data Table has an associated data definition string and an event or trigger tag. Every tag in a given Data Table must have the same data table number, data definition string, and scan rate or event tag.

A basic extended descriptor has one of the following formats:data_table_number;data_definition_stringdata_table_number;data_definition_string;EVENT=trigger_tagdata_table_number;data_definition_string;TRIG=trigger_tag

The minimum data table number is 1. The maximum number of Data Tables is limited by the amount of memory available. The default maximum is 999, but may be increased by specifying the /dt=<max_number> limit as a command line argument where <max_number> is the new maximum limit. The data table numbers may be arranged in any manner.

Unless the /unix option is specified, the data definition string takes this format:data_address, elements, plc_id

with each parameter as described in the following table:

Data Definition String Parameters

Data Address Specifies the starting address of the data item. For more information regarding A-B PLC Addressing, refer to the RSLinx user manuals.

Elements Specifies the number of elements in the Data Table. Elements are contiguous and start with the one specified in Data Address. The byte size of each element is implied by the Data Address and Processor Type of the PLC, which is specified in the interface INI file. If you omit Elements the default is one element. You should attempt to configure your data table to collect multiple elements whenever possible to maximize the performance of the interface.

November 30, 2000 9



PLC_ ID The plc_id specifies the identifier of the associated PLC in the PI-RSLinx INI file. Plc_id must be a value from 1 to 255. For example, specifying a 2 for the plc_id would cause the interface to search for PLC2 in the interface INI file.

(*special note for version 1.x users)

The Port_id, Station_num, Processor_type, and Net_id fields are now all specified in the PLC definition string in the INI file. Please see the discussion of the PI-RSLinx INI file for a more detailed explanation of the PLC identifier.

If the /unix option IS specified, please see Appendix C for a description on how to configure the data definition string.

The maximum length of a single Data Table is 244 bytes or 122 WORDS. This number includes bytes of overhead for each data table. The number of overhead bytes can differ for each memory file type.

For the maximum data table lengths that are supported for a given processor and memory file type, see Appendix A. Data Table Specifications on page 30.

If two tags are created with different definition strings for the same data table number, then the first definition encountered will be used, and a warning message will be logged for each tag with an inconsistent data table definition.

For more information on data definition strings, consult the DTL or RSLinx documentation set. Specifically, look in the reference manual for the DTL_C_DEFINE() function.

Note: In the previous version of the interface that ran on PI2 systems, the last parameter specified in the data definition string was the scan rate. This parameter is now ignored.

Event Tag in ExDesc

The event tag may be any PI point for which events will be monitored and used as the basis for scans of input data tables.

Note: Outputs based on a trigger tag are not supported.

Input tag extended descriptors will fall into one of two categories with either a time based scan rate or a trigger (event) based scan. The following are examples of input tag data definitions in the extended descriptor:

1. 12;$F20:10,16,1

2. 13;$N20:10,16,1;TRIG=TR:IG.01These examples show the extended descriptors for two input Data Tables from remote AB PLC5’s. The first DT (12) assumes a fixed scan rate specified from the scan class in Location4, while the second DT (13) will be scanned every time there is an event for the event tag TR:IG.01. Note that NO spaces are allowed in the event tag specification: TRIG=TRIG.01.Output tag extended descriptors will fall into one of a number of categories depending on whether the write will be based on events of the output tag (self triggering) or a source tag. Also, the source of the output may come from either the output tag or a specified source tag. It is recommended that a separate source tag be used. The source tag should be defined in the SourceTag field for a PI Point. The following is an example of an output tag extended descriptor:1. 14;$N7:5,1,1The above example uses Data table 14 to write one value back to the N7:5 location on PLC1. The tag can either be self triggering or it can use a source tag.


Source Tag

This field is only used for output points. The Source Tag field should contain the name of the PI point whose value will be sent to the external A-B PLC specified in the Data Definition String. The source tag can be any other point on the PI system; e.g. performance calculation, lab tag, etc. The value of the source tag will be written back to the output tag when an output is sent out. When the source tag is not defined for an output point then the value of the output tag will be sent to the specified A-B PLC.

Additional Tag Configuration

There are additional configuration parameters which apply to points used in the RSLinx Interface and which are necessary for proper operation. See the PI System manual for more information on these attributes:

TypicalValue

Zero (For PI 2 digital points, this is starting digital code)

Span (For PI 2 digital points, this is number of digital states)

DigitalSet (PI 3 digital points only)

Res (Resolution Code) - PI 2 only

Step (PI 3 only)

CompDev, CompMin, CompMax (Compression Specifications)

Compressing

Archiving

Shutdown (PI 3 only)

Point attributes not used by the interface are:

TotalCode

DisplayDigits

Groupsize

DisplayGroup

UserInt1, UserInt2

UserReal1, UserReal2

November 30, 2000 11


Unsolicited Data CollectionSetting up a Message Block

In order to set up points to receive unsolicited data from an Allen-Bradley PLC, the user must configure a Message Block using one of Allen-Bradley’s PLC configuration software programs that include the 6200 Series programming software, the AI Series programming software, or the RSLogix programming software.

The message block is added by inserting a rung into the current ladder for the PLC and then adding a MSG object. The user will is required to specify a MG-type file element to accept status and error messages for the MSG object. Once the MSG object has been inserted, the user will be prompted to enter the following information to configure the message block:

COMM Command – Set to PLC2 Unprotected Write.

Data Table Address – This is the source data table that contains the data to be sent to PI.

Size in Elements – This is the number of elements that the message will contain.

Port Number – Set to 2, 2A, or 3A for Ethernet

Destination Data Table Address – This corresponds to the Application Address this is specified in the PI point extended descriptor. The user chooses this value. See the extended descriptor discussion in the following section for more information about choosing a valid number for this field.

Ethernet (IP) Address – Set to the IP address of the PC where the PI-RSLinx interface is running.

Once the message block has been configured, the user can begin configuring PI points to receive data from the new message object. See the next section for more information about setting up unsolicited PI points.

Note: Remember to specify the /unsol command line option in the interface startup file to enable unsolicited data collection. In addition, if you are running version 2.0 or later of RSLinx, you CANNOT specify the /unix option on the command line.

Unsolicited Mode PI Point DefinitionPoint definition for unsolicited mode is very similar to solicited mode. However, there are important differences. Event tags and source tags are not relevant to unsolicited data. This section will summarize the relevant point attributes for unsolicited tags. Any attributes not mentioned in this section are configured the same as for solicited tags.

Location2

Same as solicited mode, except point type #12 (String) is not supported.


Location3

Same as solicited mode. The user must be careful to insure that the total number of elements multiplied by the size of each data element must exactly match what the PLC is transferring.

Location4

Should always be set to 1. Unsolicited mode requires no scan classes, but in order to maintain normal operation of all interface tasks (including point updates), two scan classes are required. The scan classes should be defined on the command line as follows:/f=1:00 /f=1:00

This will instruct the interface to perform housekeeping tasks every minute.

Extended Descriptor

The extended descriptor specifies the following information:

Application Address

Data Definition String

A semicolon separates each of the above fields within the extended descriptor.

The Interface reads and writes data in the form of a user-defined data table. Every data table has an associated data definition string. Every tag in a given data table must have the same unique identifier and data definition string. In unsolicited mode, the unique identifier is called the application address. This application address corresponds to the Destination Data Table Address that is specified when you create the Message Block using the 6200, AI, or RSLogix configuration software. This remote data table is treated as a virtual PLC2 table by devices on the Allen-Bradley network, and its address must conform to the PLC2 table-addressing scheme. In general, addresses 012-0111621 octal (excluding 0116-0155) are valid addresses (in decimal, 10-37777, excluding 78 -109). The addresses should be entered in octal, in conformance with the expected PLC2 format.

The data definition string for unsolicited tags resembles the data definition string for solicited tags. The following table lists each of the parameters:


Data Address

If the UNSOL.INI file is not used, this field may be left blank since the data address is equivalent to the application address and can be considered the identifier for a unique data table. If the UNSOL.INI file is used, the Data Address should be set to match one of the message numbers specified in the UNSOL.INI file for this PLC. For more information on the UNSOL.INI file, please see Appendix E.

Elements Specifies the number of elements in the virtual data table. Elements are contiguous. This value must match the number of elements that was specified during the creation of the Message Block in the AB configuration software.

PLC ID The PLC ID specifies the PLC identifier. The PLC ID must be a value between 1 and 255. Please see the discussion of the interface INI file for more information on setting this value.

If the /unix option is specified, the data definition string has a completely different format. Please see Appendix C for more information on this old style format.



A typical extended descriptor for an unsolicited tag could be as follows:273; ,100,1

and the PLC ID string in the INI file would be:PLC1=AB:LOCAL,76,PLC5,AB_ETH-1

The maximum length of a single Data Table is 244 bytes or 122 WORDS. This number includes bytes of overhead for each data table. The number of overhead bytes can differ for each memory file type. See the Data Table Specifications section for the maximum data table lengths that are supported for a given processor and memory file type. The size of the Data Table does not correspond to actual PLC data tables; instead, the size limit is imposed by Allen-Bradley network protocols.

If there is a discrepancy between definition strings for tags belonging to the same data table number, then the first definition encountered will be used, and a warning message will be logged for each tag with an inconsistent data table definition.

For more information on data definition strings, consult the DTL or RSLinx documentation set. Specifically, look in the reference manual for the DTL_C_DEFINE() function.


Order of Pre/Post ProcessingWhen a data table is read by an interface, the data are interpreted (processed) in the following order:

Read Raw Data

Convert to Word, BCD, Real, etc.

Interpret the Bit Mask

Apply the Square Root Code

Convert to PI Type real, integer, or digital

Apply the Conversion Factor

Output data are processed in the reverse order.



Software ConfigurationPI Software – PI 2 Systems

The interface on PI 2 systems requires that the interface Point Source, Scan Classes and files associated with interface operation be specified. Additionally, the Digital State table should be modified to include the digital states listed below.

Point Source

The point source may be any alpha character not currently used by another process or interface. The point source may be defined by running the Point Src display on the PI menu, choosing a blank field from the point source list, and entering the following location parameter limits.

Location1 Location2 Location3 Location4 Location5

1 0 0 0 0

256 6 32767 65536 65536

Digital State Table

Check that the following digital state codes are defined in the Digital State Table. These are defaults that should be present in every PI system.

Digital State Code Digital State String

237 Bad Output

238 Scan Off

239 Scan On

PI-RSLinx Interface Files - NT and UNIXThe RSLinx interface is responsible for retrieving dynamic analog and digital data from the specified memory file type of a remote A-B device on an exception basis. This process is also responsible for sending digital and analog values by exception to A-B devices. Multiple copies of the interface can be run to communicate to the same or different PLC’s. The maximum number of interface copies is 256.

The interface has an associated startup file called PIRSLINX.BAT for NT and PIRSLINX.SH for UNIX. If multiple copies of the interface are to be run, a startup file is required for each copy. The PIRSLINX.BAT or PIRSLINX.SH file should be copied to PIRSLINX#.BAT or PIRSLINX#.SH, where the # identifies a startup file with a particular interface copy. The # sign should be the same number that the /id parameter is set to in the bat file.


PIRSLINX.BAT / PIRSLINX.SHEach PIRSLINX interface process is started by executing the bat file PIRSLINX#.BAT for NT or PIRSLINX#.sh for UNIX where # represents the number of the interface. This means there will be a PIRSLINX#.BAT or PIRSLINX#.sh startup script for each instance of the interface. PIRSLINX#.BAT or PIRSLINX#.sh contains the following required and optional parameters which must be edited for the interface of interest. All parameters are case-insensitive.

Required Parameters

/ps Point source character to be used for the PI-RSLinx interface

/id Interface number. Will always be associated with a specific PI-RSLinx Interface.

/f Scan class frequencies. Each scan class is defined with the scan class flag, /f, followed by the time period and an optional scan offset. The classes are established in the order they are listed on the command line. The format for each scan class is: /f=hh:mm:ss.xx, hh:mm:ss.xx where the section prior to the comma corresponds to the scan frequency and the section after the comma corresponds to the scan offset. For instance to specify a frequency of 10 seconds with an offset of 3 seconds, you would set /f=00:00:10,00:00:03 or /f=10,3.

Note that hh stands for hours, mm for minutes, ss for seconds, and xx represents the subsecond portion of the frequency.

If an integer is specified for the frequency, the interface will treat the integer as number of seconds. So a scan rate of 5 seconds could be specified using /f=5 instead of /f=00:00:05. A scan rate of /f=4:30 would represent a 4 minute 30 second scan interval. A scan rate of /f=0.5 would represent a ½ second scan rate.

Note that subsecond timestamps will only be sent to PI if either the scan class frequency or its offset is set to a fraction of a second. However, it the tags are triggered or event-based or if the /unsol parameter is set, all timestamps will be sent to PI with subsecond resolution, regardless of the /f parameter.

Also note that the value specified in Location4 of the PI tag configuration determines which of the /f parameters will be used for the scan class. For instance, if the command line contains: /f=1:00 /f=30, then specifying a 1 in Location4 will cause the tag to scan at an interval of 1 minute, while specifying a 2 in Location4 will cause the tag to scan every 30 seconds.

Optional Parameters

/host Name of PI home node. If the interface is running on a different machine then the PI system, use /host=PI3NAME:5450 or /host=PI2NAME:545, where PI3NAME is the name of the host machine running the PI3 server and PI2NAME is the name of the host machine running the PI2 server. If the interface is running on the same machine as the PI system, use /host=localhost:5450 for a PI3 system and /host=localhost:545 for a PI2 system..

/dt Maximum number of Data Tables the interface can service. The default is 999. The absolute maximum is 999999 but may actually be much less due to memory limitations and RSLinx software restrictions.

/ec I/O rate counter. This counter measures the rate at which the interface sends values to the PI Snapshot. That is, it serves as a measure of the data input load. The I/O Rate Counter does not account for the output data load. See the Event Counter section for more information about creating an IORATES.DAT file and setting up an I/O Rate tag in PI.



/wp Wait Period to retry communications for those DT(s) which have timed-out. The default is 10 seconds.

/db Debug Flag. This flag controls the printing of additional messages to both the interface command prompt screen and to the pipc.log file. This can be specified as simply /db or /db=x where x specifies a debug level, the higher the value of x the more debugging info will be printed out. This setting should only be used for initial startup and testing since debug messages may fill up the output file quickly. The debug level can range from 1 to 6 with this current version.

/unix Use the old style data addressing scheme.

This switch MUST be specified when running the interface on UNIX.

/ini Specifies the name and location of the PI-RSLinx INI file. The user has the option of either specifying a full path and filename to the INI file OR to simply specify a path only whereby the driver will look for the RSLINX#.INI file in that path where # is the interface number. If the /ini switch is not specified on the command line then the interface will look for a file called <c:\PI\interfaces\pirslinx\rslinx#.ini> where # is the interface number. If the file is not found then the interface will write an error to the log and exit.

/sio Specifies to the interface not to send values of output tags on startup. Values will be sent after startup when exceptions are detected on output tags or source tags for output tags. If output tags are added during runtime, the values will be sent immediately.

/notim[eout] Specifies to the interface not to mark tags that have a communications timeout with the “I/O Timeout” state. This is used with large tag configurations (greater than 50 DTs/sec) whereby a bottleneck on the transmissions medium can occur and some DTs will timeout temporarily from time to time.

/nobad[input] Specifies to the interface not to mark tags that have a configuration error present with the “Bad Input” state. This is also used when high poll rates (greater than 50 DTs/sec.) are present whereby a bottleneck over the transmissions medium can occur and some DTs will otherwise be set to “Bad Input” temporarily from time to time due to RSLinx limitations.

/asyncr, /asyncw, /asyncrw, /asyncwr

Causes the interface to use Asynchronous I/O for Reading and/or Writing data with RSLinx A-B devices, as opposed to the default Synchronous I/O. For instance, the interface can specify use of asynchronous I/O for inputs (/asyncr) and the outputs will be done via synchronous communication (by default). The meaning of the switches is given below:/asyncr -> asynchronous I/O for inputs only/asyncw -> asynchronous I/O for outputs only/asyncrw or/asyncwr -> asynchronous I/O both inputs and outputs

There are advantages and disadvantages to both, depending on the system requirements. Synchronous I/O Writes (default) should be used if every output must be output before the interface continues with another operation. With synchronous I/O the program waits for the I/O to complete before continuing. Whereas with the asynchronous method (/asyncw), I/O is queued up and does not wait for the last operation to complete before continuing. Thus with asynchronous I/O if a large number of outputs must be sent out at any given time then bottlenecking may occur (due to H/W limitations, baud rate, etc.) and large number of outputs may not actually get sent out on schedule. They will be queued to be output but are not guaranteed to be delivered, whereas with synchronous I/O the output tags are almost guaranteed to be written out with the drawback of slower poll rates for the input tags, thus the Input tag rate will suffer.


Note 1: The previous version of the interface that ran on the VAX and ALPHA only supported asynchronous communication.

Note 2: If Synchronous I/O is to be used (default) then do not detach the interface cables connecting the various A-B devices to the NT machine while the interface is running. This includes DH+ cabling, Ethernet cabling, or serial RS232 lines. This has been seen to lockup the driver whereby no further I/O operations will occur. Error messages will not be displayed for this error condition, nor will “I/O timeout” be written to any PI tags. The driver must be restarted. Rockwell Software is aware of this NT bug and will hopefully correct it in future versions of their software. This does not occur with asynchronous I/O.

/top Time-Out Period (internal time-out). Used to specify to RSLinx lower-level software how long to wait for a reply after an I/O transaction is requested (in milliseconds). Default is 200 (mSec). Caution: This setting will affect scan rates of all Input tags if it is set too high for Sync I/O and there is an actual I/O communications problem (disconnected cable, downed network, etc.). This setting is made available for systems where the default 200 msec is too short a period and must be increased. Do not attempt to change this setting unless you are experiencing I/O Timeout problems.

/perf=# Change the scan performance summary frequency or suppress it all together. Setting /perf=0 suppresses the summary. Setting /perf=12 would cause the summary to run every 12 hours. The default is 8 hours.

/unsol Use unsolicited mode for inputs into PI. When running in unsolicited mode, the async or sync parameters must not be used. All data is received by unsolicited writes from the PLC in synchronous mode. Two scan classes should be defined (as explained above) when unsolicited mode is used.

Note: If version 2.0 or later of RSLinx is being used, you CANNOT specify the /unix option when specifying the /unsol option.



A copy of the interface startup file, PIRSLINX#.BAT for NT is shown below:

REM pirslinx.bat PIRSLinx Interface Startup Batch FileREMREM this command procedure passes required -default parameters toREM process pirslinx.REM REM if multiple copies of the interface are to be run, copy pirslinx.bat to REM pirslinx#.bat where # is the same number passed by /id=# in the command string.REMREM command line arguments:REM /ps point source for rni interfaceREM /id interface numberREM /f scan class definitionREMREM optional argumentsREM /host pihome nameREM /dt maximum number of data tablesREM /ec i/o rates counter numberREM /ini specifies location and name(optional) of PIRSLINX ini fileREM /wp wait period after I/O Timeout before comm. retryREM /db prints out tag info for each tag in the databaseREM /unix use old style data addressing schemeREM /sio don't send values of output tags at startupREM /notim don't send I/O Timeout to tags with communications problemsREM /nobad don't send Bad Input to tags that have configuration errorsREM /async[r][w] use asynchronous reading and/or writing for inteface I/OREM /top time-out periodREM /perf alters the frequency of the scan performance summaryREMREM run string needs a space between arguments, no spaces within argument.REM..\interfaces\pirslinx\pirslinx.exe /host=localhost:5450 /ps=A /id=1 /ec=1

/dt=500 /f=00:00:05 /f=00:00:01 /f=00:00:30 /dbREMREM end of pirslinx.bat


A copy of the interface startup file, PIRSLINX#.sh for UNIX is shown below:

# PIRSLinx Interface Startup Script File## if multiple copies are to be run, copy pirslinx.sh to pirslinx#.sh# where # if the same number passed by /in=# in the command string.## required command line arguments:# /ps point source for RSLinx Interface# /in interface number (#)# /f scan class definition# /unix use old style data addressing scheme## optional parameters# /host pihome name# /db prints out tag info for each tag in the database# /ini specifies location and name(optional) of PIRSLINX ini file# /dt maximum number of data tables# /ec i/o rate counter number# /wp wait period after I/O Timeout before comm. retry# /db prints out tag info for each tag in the database# /sio don't send values of output tags at startup# /async[r][w] use asynchronous reading and/or writing for inteface I/O# /top time-out period# /perf alters the frequency of the scan performance summary## run string needs a space between arguments, no spaces within argument.#($PIHOME)/interfaces/pirslinx /host=205.208.194.200:5450 /ps=A /id=1 /ec=1 /unix /db# end of PIRSLINX.SH



INI FileEach PIRSLINX interface process which uses Ethernet for a communications link to a remote A-B PLC requires a Data Initialization File usually called pirslinx#.ini, where # is the interface number for that process. The name and location of this file is specified by the /ini switch in the interface startup batch file. See the PIRSLINX.BAT section for more information on this switch.

Note: As of version 1.29, the interface prints out a message at startup that identifies the location of the INI file that it is using. The user should verify that this location is correct. If not, the user should make sure to specify the full path of the INI file by using the /ini parameter in the interface startup file.

The INI file is used to map the plc_id parameter in the Data Definition String specified in each PI tag’s extended descriptor to a PLC ID string. The PLC ID string takes the following format:

PLCx=Port_ID, Station_Num, Processor_Type, Driver_ID

where x is the plc_id which will be mapped to this PLC string. Port_ID, Station_Num, and Process_Type are all fields that used to be specified in the extended descriptor of each tag in 1.x versions of the interface. Please see the following chart for more info on how to conifigure them.

Port_ID The port id should take the following format: AB:KEY/L:l/P:p/M:m/C:c (see following chart for explanation)

Field Description Valid Values

KEY keyword ASA, NAME, LOCAL, LONGLOCAL, PIGATEWAY, PIGATEWAYIP, PIGATEWAYNAME ,

OFFLINKl destination link id 0 - 177777 (octal)p pushwheel number 0 - 8 (decimal)m module type KA, KT, RMc channel number 0, 2, 3b bridge address 1-376 (octal)/KA bridge requires 1785-KA /KA switch is required to communicate

addressing mode through a 1785-KA from DH+ to DH.

Sometimes, the KEY will be the only portion that needs to be specified. See Appendix B for a list of examples that show how to set up the Port ID with various PLC configurations.

Note: The link id is octal. RSLinx specifies the link id as decimal, so a conversion is necessary to calculate the octal representation of the link id.

There are no spaces allowed in the port id string.

If the /unsol flag is specified, this field can be left blank.

Station_Num The station num is an octal number (0 - 376) identifying the address of the remote station. Valid Station Numbers:

Data Highway: 1 to 376 (octal)DH+: 0 to 77 (octal)DH-485: 0 to 37 (octal)


RS-232(DF1): 0 to 77 (octal)

If the PLC is accessed via a ControlLogix, the Station Num takes the following format:

port.slot.channel.stationwhere:

Port is the backplane, which is always 1 for ethernet. Slot is the location of the DHRIO module in the backplane.Channel is the DHRIO module channel number (A=2,B=3)Station is the destination node number (in decimal)

Processor_Type This string is a keyword that identifies the processor type of the remote station (i.e., SLC500, PLC5250, PLC5, PLC3, PLC2).

Driver_ID This string represents the name of the RSLinx driver that has been configured to communicate with this PLC. Examples include AB_ETH-1, TCP-1, and AB_DF1-1. Each driver is configured in the RSLinx software using the Configure Drivers menu option.

Following is an example pirslinx.ini file using this format:

[PLC]PLC1=AB:LOCAL,5,PLC5,AB_ETH-1PLC2=AB:ASA/L:2,1.0.3.27,PLC5,TCP-1

In this example, PLC1 represents a PLC5 that is connected via ethernet. It is listed in the AB_ETH-1 driver of RSLinx as station number 5. PLC2 represents a PLC5 that is connected to a ControlLogix gateway under link-id 2 using the TCP-1 driver. Appendix B provides several other examples that should prove helpful during INI file configuration.

Rate Counter – IORATES.DAT fileThe I/O Rate Counter measures the rate at which the interface sends values to the PI Snapshot. That is, it serves as a measure of the data input load. The I/O Rate Counter does not account for the output data load.

To take advantage of the IORates counter, create an IORATES.DAT file in the (PIHOME)\DAT directory. This will usually be in \PIPC\DAT. The format of the file is as follows:

IORateTagName, EventCounter

where IORateTagName is the name of the PI tag that will be used to store the event rate. The tag will update every 10 minutes and will contain a 1-minute average of the input event rate. Usually an IORates tag is given a pointsource of L and it must be assigned an appropriate zero and span. EventCounter corresponds to the /ec option specified in the startup .bat file of each interface. An example IORATES.DAT file might look like:

SY:RS1, 10SY:RS2, 11

SY:RS1 would collect data for the RSLINX interface with /ec=10 specified in its startup bat file. SY:RS2 would collect data for the interface with /ec=11.



Installation Installation - NT and UNIX

The following steps should be taken to install the PI-RSLinx interface on NT or UNIX:

1. Choose a Point Source Character for the RSLinx Interface and define it using Point Src from the PI Menu. (For PI2 systems only)

2. Assign a number to each PI-RSLinx Interface. Note that each PI-RSLinx Interface can handle multiple PLC Devices.

3. Update the Digital State Table. (For PI2 systems only)

4. Install the A-B Communications Device (i.e. 1784-KT, 1784-KTX, Ethernet Card, etc.).

5. Install the RSLinx vendor software on the NT machine or UNIX machine.

6. Configure the communications device according to Rockwell Software’s instructions using their RSLinx Lite or similar Configuration program. Select Communications and click on Configure Devices. In that dialog box select Add New Device to add the new communications device driver.

7. Use the “SuperWho” function on the RSLinx vender software to verify that the PLC’s are connected to the newly configured communications device. From the RSLinx menu, select Communications and click on SuperWho. All available A-B PLC devices will be displayed in the window if they are connected.

8. Install the PI-RSLinx Interface files. For NT, the recommended location for these files is the \PIPC\interfaces\pirslinx directory. For UNIX the recommended location is ($PIHOME)/interfaces/pirslinx#. However, the user has the option of choosing a different directory for both NT and UNIX. Note that in NT the pirslinx#.bat and pirslinx#.exe files must be in the same directory and have the same name (excluding the extension).

9. If running on NT, copy the pirslinx.dbg file to the \WinNT\symbols\exe directory.

10. Edit the PIRSLINX#.BAT for NT or PIRSLINX#.sh for UNIX so that the proper parameters are passed.

11. If running the interface on an NT home node, add the interface startup commands shown below to the (PIHOME)\adm\pisrvsitestart.bat file for each copy of the interface:net start pirslinx#If running the interface on a HP-UX home node, edit the ($PIHOME)/adm/pisitestart.sh script and add pirslinx# to the list of interfaces on the first line.

11. Configure each of your PLCs in the PI-RSLinx INI file by adding a PLCx=<data> entry for each PLC under the [PLC] section of the file. See the discussion of the INI file in this manual for more info.

12. Configure Points for the PI-RSLinx Interface.


Interface OperationInterface Operation - NT and UNIX

After configuration of the hardware and the software, the PI-RSLinx Interface may be started. The Interface may be run by hand from the DOS prompt or it may be configured to start automatically whenever the PI System is started.

Startup - NTThe interface can be started up as an NT service or can be started from a Command Prompt window.

The interface can be manually started from the (PIHOME)\adm directory by typing:start ..\interfaces\pirslinx\pirslinx#.bat

or it will be started when the PI system starts up if PIRSLINX#.BAT is executed when (PIHOME)\adm\pisitestart.bat is executed (see under installation instructions). A Command Prompt window will be created for each interface process created. The window for the RSLinx OEM Server will appear initially during Startup and become minimized thereafter. The RSLinx Server is required to be running at all times that the PI-RSLinx Interface is running. If it is shutdown for any reason during interface operation then the interface must be shutdown and restarted.

Running as an NT Service

It is recommended that the interface be run as a service on an NT system running PI 3.1 or later or on an NT API node with buffering installed as a service.

1. If the interface is not running on the home node, skip to step 2. Otherwise, edit the (PIHOME)\adm\pisrvsitestart.bat file to add:

net start pirslinx#

2. Go to the pirslinx directory (usually \PIPC\interfaces\pirslinx#) and type:

pirslinx# -install -auto -depend “tcpip rslinx” (no buffering)

<or>

pirslinx# -install -auto -depend “tcpip rslinx bufserv” (buffering)

This will install the service and it will be set to start automatically at reboot. If you don’t want the service to start automatically at reboot, remove the –auto from the install line. You can also configure the interface to start automatically by editing the service using the Services dialog box on the Control Panel.

Note: The interface will still run as a service if you leave the RSLinx dependency out of your install command; however, if the RSLinx vendor software is not running when you start the PIRSLinx service, the RSLinx software will be started up under the SYSTEM desktop and you will not have access to it until you reboot.



Note: If you plan to run the interface as a service with buffering, you must be running version 1.0.4 or later of bufserv, and it too must be set up to run as a service.

3. You can start the pirslinx service in 2 ways:

A. Go to the directory that contains the pirslinx#.exe and type: pirslinx# –start

B. Open the Control Panel and double click on the services icon. Highlight the pirslinx# service and click the start button.

Note: In each of the above examples, the # symbol stands for the interface number. This is only necessary if you are running multiple copies of the interface.

More information for running the interface as a service can be found in your PI Data Archive for NT and UNIX for version 3.1 document, PI Installation and Upgrade on Windows NT chapter in section Configuring NT Services.

Startup - UNIXThere are several choices for startup. Initial testing should be run interactively with the /db command line parameter to verify correct operation. Press Ctrl-C to quit the interactive session. After verification of normal operation, the shell script can be modified to run in background mode using standard shell tools. Whether the interface can operate in nohup mode using the background directive depends on the specific platform. If the interface does not allow the user to log out without killing the process, then nohup must be used explicitly in the startup file.

If the interface is to be started as part of the PI3 startup procedure, the pisitestart.sh script should be modified to cd to the proper directories and then execute the interface startup script.

The RSLinx Server is required to be running at all times that the PI-RSLinx Interface is running. If it is shutdown for any reason during interface operation then the interface must be shutdown and restarted.

ShutdownOn the UNIX platform, if the interface is running on the PI home node, the PI-RSLinx interface is normally stopped automatically by the PI Data Archive shutdown procedure. The pisitestop.sh script must be edited to set this up. You can also stop the interface by using standard system tools to kill the UNIX processes.

On the NT platform, if the interface is running interactively, you can stop it by typing <Ctrl-C> in the appropriate Command Prompt window.

If the interface is running as a service on an NT system, you can stop the pirslinx service in 2 ways:

1. Go to the directory that contains the pirslinx#.exe and type: pirslinx# –stop

2. Open the Control Panel and double click on the services icon. Highlight the pirslinx# service and click the stop button.

If the interface is running on a NT PI 3 home node, make sure to edit the (PIHOME)/adm/pisrvsitestop.bat file to add:

net stop pirslinx#

This way the interface (running as a service) will automatically be stopped whenever PI is stopped.


If for some reason you need to remove the pirslinx service, go to the directory that contains the pirslinx#.exe and type: pirslinx# -remove

Information and Error Messages - NTAll messages pertaining to the interface will be written to the pipc.log file. If either PI-Datalink or PI-ProcessBook is loaded, the file should be located in the \PIPC\dat directory; otherwise one will be created in the root directory on your C: drive. Startup messages as well as important messages regarding the status of communication will be written to the interface Command Prompt window.

The user can specify that special debug messages get printed out both in the interface Command Prompt window and the pipc.log file. These messages are designed to aid in interface trouble-shooting and do not need to be turned on during ordinary circumstances. The user turns the debug messages by setting the /db flag in the interface start up file, PIRSLINX#.BAT. Removing the debug flag from the startup file will result in those messages not printing out. Remember to stop and restart the interface each time the flag is changed so that the change is picked up.

The default buffer size for a Command Prompt window is a width of 80 characters and a height of 25 lines. It is advisable to increase the height to approximately 1000 lines so that information does not scroll off the screen. Command Prompt window settings are changed from the window itself. Right click on the horizontal bar in the upper left hand corner, choose the Properties option and then edit the Screen Buffer Height option under the Layout tab. Adjust the height and width appropriately and then choose the option to save the screen buffer size.

Note: The interface will not print a message if the RSLinx software is shutdown while the interface is running. If you then try to restart the RSLinx software, the interface will fail to reconnect. Therefore, never shut down the RSLinx server software while the PI-RSLinx interface is running.

Information and Error Messages - UNIXIn order to see interface messages, PI-API processes must be running concurrently with the interface. This applies also to machines running PI3 server processes. When the PI-API processes are running, messages are logged to the PI-API log file as well as to an output file that can be defined through redirection in the startup script. Most of the messages, however, are logged to the PI-API message log. Consult the PI-API manual regarding the name and location of the PI-API message log file.

The user can specify that special debug messages get printed out both to stdout (or the redirected file) or the PI-API log file. These messages are designed to aid in interface trouble-shooting and do not need to be turned on during ordinary circumstances. The user turns the debug messages by setting the /db flag in the interface start up file. Removing the debug flag from the startup file will result in those messages not printing out. Remember to stop and restart the interface each time the flag is changed so that the change is picked up.



Common Errors Returned from the RSLinx

DTL Errors

The table shown below specifies a few typical RSLinx DTL errors (as shown in Interchange/RSLinx literature) and gives a brief synopsis of the problem as well as the corrective action that may be taken.

DTL Error #

DTL Error Code Name Meaning/Possible Corrective Action

02 DTL_E_DEFBAD1 Invalid defined DT string, check the Data Definition string of the PI tag(s) which belong to that DT.

03 DTL_E_DEFBAD2 Invalid number of elements in defined DT, check the Data Definition string of the PI tag(s) which belong to that DT.

04 DTL_E_DEFBAD3 Invalid Data Type for the defined DT, check the Data Definition string of the PI tag(s) which belong to that DT and make sure that the Data Type is correct

05 DTL_E_DEFBAD4 Invalid Access Rights for defined DT, check the PI tag(s) which belong to that DT and make sure that the Address specified is readable or writeable. Note RSLinx cannot Read or Write a data item from the Input or Output sections of a SLC500, SLC5/01, or SLC5/02 processor data table.

06 DTL_E_DEFBAD5 Invalid Module, pushwheel, or channel for defined DT, check the PI tag(s) which belong to that DT and make sure that the Port ID is correct.

07 DTL_E_DEFBAD6 Invalid Remote Station Address for defined DT, check the PI tag(s) which belong to that DT and make sure that the PLC Station Address is correct.

08 DTL_E_DEFBAD7 Invalid PLC Processor Type for defined DT, check the PI tag(s) which belong to that DT and make sure that the PLC Processor Type is correct.

09 DTL_E_DEFBADN Invalid # of DT parameters. Check the DT string for that Data Definition.

10 DTL_E_DEFCONF The defined DT is in conflict.

11 DTL_E_FULL The Define Table is Full, stop interface and increase the /dt parameter in order to allocate more space for DTs.

31 DTL_E_TOOBIG Data size exceeds the maximum transfer size for the specified section. Stop the interface and reconfigure the <elements> field in all tags that belong to that DT#, the <elements> field was too big. For the Maximum Data Table lengths, check "Appendix A. Data Table Specifications" on page 30.

38 DTL_E_DFBADADR When a DT is Invalid due to an incorrectly specified DT definition. Check the specified data table definition string of DT(#) in the error message. Verify that address exists in specified PLC and length of DT does not exceed limit. Restart Interface.

122 DTL_E_NO_SERVER RSLinx Server is not loaded into memory.

123 DTL_E_SERVER_NOT_RUNNING

RSLinx Server is not running. Interface must be stopped and restarted since it cannot automatically reconnect to the RSLinx Server.


See Allen-Bradley/Rockwell Software’s INTERCHANGE Reference Manual or RSLinx reference manual for additional error codes.

Other error conditions that have been found are listed next:

If Synchronous I/O is to be used (default) then do not detach the interface cables connecting the various A-B devices to the NT machine while the interface is running. This includes the DH+ cabling, the Ethernet cabling (if Ethernet is used to access A-B PLC data) or the serial RS232 lines (if a serial interface is used). This has been seen to lockup the driver whereby no further I/O operations will occur. No error messages will be displayed for this error condition, nor will “I/O timeout” be written to any PI tags. The driver must be restarted. Rockwell Software is aware of this NT bug and will hopefully correct it in future versions of their software. This does not occur with asynchronous I/O.

If Asynchronous I/O [/asyncrw] is used keep in mind that a definitive I/O throughput limit exists for the given H/W and baud rates whereby if exceeded will cause bottlenecking to occur. From testing with the DH+ protocol that limit was around 200 outputs/sec. If 100 or more outputs will be written over a DH+ network every second then Synchronous I/O should be used. Otherwise, if the driver is left running with the bottleneck condition then eventually that network will become so loaded that an I/O rate of maybe 1 output/sec may be seen, due to impending overhead in handling I/O timeouts for the rest of the unwritten tags. This limit is less with serial baud rates and higher with Ethernet.



Appendix A. Data Table SpecificationsThe tables shown below display the maximum Data Table lengths that can be defined for a given processor type and Memory File Type as well as the range of the starting Data Address field for the Data Table Definition String.

Table 1. PLC-5 Processor

Memory File Type Maximum Data Table Length

Starting Data Address Range

Example Starting Address for Data Table

O 118 0-277 (octal) O:10

I 118 0-277 (octal) I:40

T0-T999 40 0-999 T4:1

PD0-PD999* 1 0-999 PD20:4

C0-C999 40 0-999 C5:50

N0-N999 118 0-999 N7:200

D0-D999 118 0-999 D34:6

B0-B999 118 0-999 B3:100

S 118 0-127 S:16

F0-F999 59 0-999 F8:0

A0-A999 118 0-999 A12:0

L0-L999 59 0-999 L9:100

R0-R999 40 0-999 R6:20

MG0-MG999* 1 0-999 MG99:2

ST0-ST999* 2 0-999 ST12:0

BT0-BT999* 2 0-999 ST12:0

*Note: Max address for these memory types may vary between PLC-5 processors


Table 2. SLC 500 Processor Family

Processor Type Memory File Type

Max. Data Table Length



SLC-5 T4,T10-255 13 0-255 T4:1

C5,C10-255 13 0-255 C5:10

N7, N10-255 41 0-255 N7:0

B3, B10-255 41 0-255 B3:10

S 41 0-15 S:0

R6, R10-255 13 0-255 R6:10

SLC-5/04, T4, T10-255 39 0-255 T4:3

SLC-5/03 C5, C9-255 39 0-255 C5:20

N7, N9-255 118 0-255 N7:10

B3, B10-255 118 0-255 B3:20

S 97 0-15 S:1

F8,F10-255 59 0-255 F8:120

A9-255 118 0-255 A12:0

ST0-255 2 0-255 ST10:0

R6, R10-255 39 0-255 R6:0

O 118 0-30 O:1

I 118 0-30 I:2

Table 3. PLC-3 Processor

Memory File Type

Maximum Data Table Length



O0-O999 118 0-377 octal O0:10

I0-I999 118 0-377 octal I0:10

T 40 0-9999 T:30

C 40 0-9999 C:50

N0-N999 118 0-9999 N7:20

D0-D999 118 0-9999 D10:20

B0-B999 118 0-9999 B10:20

S0-S999 118 0-9999 S10:50

F0-F999 59 0-9999 F8:10



Table 4. PLC2 Processor




000-37777(octal) 118 10-37777 octal excluding 78-109

10

Table 5. PLC-5/250 Processor




IS 118 0-777 octal IS:50

O 118 0-377 octal O:34

I 118 0-377 octal I:32

T0-T9999 40 0-9999 T4:10

C0-C9999 40 0-9999 C5:23

N0-N9999 118 0-9999 N7:10

B0-B9999 118 0-9999 B3:12

S 118 0-9999 S:12

F0-F9999 59 0-9999 F8:400

L0-L9999 59 0-9999 L10:200

R0-R9999 40 0-9999 R6:10

PD0-PD9999 1 0-9999 PD19:0

MSG0-MSG9999 1 0-9999 MSG19:0

BTD0-BTD9999 118 0-9999 BTD20:0

AS0-AS37 (octal) 59 0-4 AS12:1

ST0-ST9999 2 0-9999 ST16:0


Appendix B. Configuring the INI fileThe following examples show how to define entries for the PLC ID string, which is mapped to a plc_id number in the exdesc of each point.

For a local Ethernet PLC-5 processor where the target processor is mapped to station 5 in the RSLinx Ethernet Driver Configuration dialog box, and the Ethernet driver is AB_ETH-1, the syntax is:PLC1=AB:LOCAL, 5, PLC5, AB_ETH-1

Note: This is the format that would be used to replace the old style extended descriptor that would be used to talk to an ethernet PLC. The old style format would have been something like:

1; $N7:0, 1, RAW, READ,,, PLC5, 1

and the IP address would have been specified in the INI file as HOST1.

For a remote PLC-5 processor accessed via a DH+ network where the DH+ station number is 021 and the driver is AB_ETH-1, the syntax is:PLC1=AB:LOCAL, 021, PLC5, AB_ETH-1

For a local PLC-5 processor accessed via the local PC COM port, where the driver is AB_DF1-1, and the station number is 0, the syntax is:PLC1=AB:LOCAL, 0, PLC5, AB_DF1-1

For a remote PLC-5 accessed through a DHRIO module in a ControlLogix Gateway, where the port id is AB:ASA/L:2 (where 2 is the octal link id of the DHRIO channel connected to the processor), the station number is a path specified as port.slot.channel.station (port is always 1, slot is the zero-based slot number of the DHRIO module in the ControlLogix chassis, channel is the DHRIO channel connected to the DH+ network, station is the address of the PLC in decimal), and the driver is TCP-1, the syntax is:PLC1=AB:ASA/L:2, 1.0.3.27, PLC5, TCP-1

For a local Ethernet PLC-5 processor where the target processor's dot address is 130.151.188.128, and the RSLinx Ethernet driver is AB_ETH-1, the syntax is:PLC1=AB:NAME, 130.151.188.128, PLC5, AB_ETH-1

For a local Ethernet PLC-5 processor where the target processor’s 32-bit IP address is 2159843202, and the RSLinx Ethernet driver is AB_ETH-1, the syntax is:PLC1=AB:LONGLOCAL, 2159843202, PLC5, AB_ETH-1

For a remote PLC-5 processor where the target processor’s station number is 10 (octal) and is connected via DH to a 85KA module at bridge address 32 using a KT, and the RSLinx driver is AB_KT-1, the syntax is:PLC1=AB:OFFLINK/B:032/KA,10,PLC5,AB_KT-1

For a remote PLC-5 processor accessed via an Ethernet link where the Ethernet gateway is mapped to station 3, the PLC-5 is connected to channel 2 of the first KA module, DH+ station number is 021, and the RSLinx Ethernet driver is AB_ETH-1, the syntax is:PLC1=AB:PIGATEWAY/p:1/m:KA/c:2/e:3, 021, PLC5, AB_ETH-1



For a remote PLC-5 processor accessed by an Pyramid Integrator gateway where the Pyramid Integrator’s dot address is 130.151.188.135, the target processor’s DH+ address is 020, and the RSLinx Ethernet driver is AB_ETH-1, the syntax is:PLC1=AB:PIGATEWAYNAME/p:0/m:rm/c:2/e:130.151.188.135, 020, PLC5, AB_ETH-1

For a remote PLC-5 processor accessed by an Pyramid Integrator gateway where the Pyramid Integrator's 32-bit IP address is 2277283714, the target processor’s DH+ address is 020, and the RSLinx Ethernet driver is AB_ETH-1, the syntax is:PLC1=AB:PIGATEWAYIP/p:0/m:rm/c:2/e:2277283714, 020, PLC5, AB_ETH-1


Appendix C. Old Style Data Addressing Scheme If the /unix command line parameter is specified, the interface will use the old style addressing scheme. The /unix parameter is required when running the interface on Unix. It can also be specified for NT interfaces. This is only recommended if the interface will be collecting data for points that have been configured for previous versions of the interface. The /unix option allows users to run the 2.x version of the interface without breaking previously defined points.

The format of the data definition string in the extended descriptor and the format of the PI-RSLinx INI file are the main differences between the two addressing schemes. The old style format of the data definition string in the extended descriptor is as follows:data_address, elements, application data type, access_type, port_id,

station_num, processor type, net_id

with each parameter as described in the following table:

Data Definition String Parameters with the /unix option

Data Address

Specifies the starting address of the data item. For more information regarding A-B PLC Addressing, refer to the respective hardware.

Elements Specifies the number of elements in the Data Table. Elements are contiguous and start with the one specified in Data Address. The byte size of each element is implied by the Data Address and Processor Type. If you omit elements the default is one element. You should attempt to configure your data table to collect multiple elements whenever possible to maximize the performance of the interface.

Application Data Type

The application data type should always be set to RAW, as the interface will be responsible for executing the proper conversion.

Access Type Access type may be either READ for read only data tables, or MODIFY, for read/write access. PROTW and UNPROTW are used with PLC-2 data tables.

Port ID The port id string identifies the external communications path through which the RSLinx interface will access a remote station. The port ID is mapped to a particular RSLinx driver, which must be created using RSLinx OEM software. To map a port ID to a driver using the RSLinx OEM software, choose the Configure Client Applications option under the Communications menu item. Then choose the INTERCHANGE Port Mapping tab and map a new portID.

Examples of common port IDs are 1KT:0 and 2KT:0.

If the port is Ethernet then leave this field blank

Station Num If the port is not Ethernet, the station num is an octal number (0 - 376) identifying the address of the remote station. Valid Station Numbers:

Data Highway: 1 to 376 (octal)DH+: 0 to 77 (octal)DH-485: 0 to 37 (octal)RS-232(DF1): 0 to 77 (octal)

If the port is Ethernet then leave this field blank

Processor This string is a keyword that identifies the processor type of the remote station (i.e.,



Data Definition String Parameters with the /unix option

Type SLC500, PLC5250, PLC5, PLC3, PLC2). Caveats: For local PLC-5/250 processor, you must omit this string. For local Ethernet (PLC-5E) processor, the processor type must be specified as PLC5.

Network Interface ID

The ni_id specifies the network interface number. (optional - defaults to 0) When the network interface is KT, ni_id must be 0. If the network interface is Ethernet, ni_id must be a value from 1 to 40.

The format of the PI-RSLinx INI file is also different when /unix is specified. PLC ID strings are not used. Instead, the INI file is used to map the net_id parameter in the Data Definition String of a PI tag to a remote host either through a remote host name or through an IP address. An entry called [HOSTx] will need to be created under a section called [CONNECTIONS] for each remote Ethernet PLC of interest. The syntax of the entry is as follows:

HOSTx=<IP address or Host Name>

where x is the net_id mapped to this IP Address or remote Host Name.

Following is an example pirslinx.ini file for an old style interface:

[CONNECTIONS]HOST1=158.106.10.9HOST2=158.106.10.10

In this example, one connection (net_id 1) will be a direct Ethernet connection to a PLC5/40E at IP address 158.106.10.9, and a second connection (net_id 2) will be a direct Ethernet connection to a PLC5/40E at IP address 158.106.10.10. All points that need to get data from the 158.106.10.9 PLC would then specify a 1 for the net_id, and those points connecting to the Ethernet PLC at 158.106.10.10 would specify a 2 for the net_id.

Note: If you are connecting directly to a PLC using Ethernet and you are using the /unix switch, you should specify either the IP address or the Host name, not the driver name.

The net_id can be any user-selected number in the range of 1 to 40. Note if the INI file is not located then all Ethernet based points will receive errors when the interface first starts up.


Appendix D. Troubleshooting TipsHere is a list of possible errors that can be found in the PIPC.LOG and the appropriate steps to fix the problem:

1. Warning: Inconsistent Data Definition in Point xxxxx, Current Data Definition: xxxxx Requested Data Definition: xxxxx

This means that you have defined two or more tags with the same data table number, but their extended descriptors do not match. You must change the extended descriptor of one or more of the tags to match the extended descriptor of the first tag that uses that data table number. Or you must choose a different data table number for the new tag(s).

2. PutSnap Error -10401: Pt xxx, IStat xxx, Rval xxx, Time xxx

This means that the interface cannot write to the point on the PI 3 home node. You either need to change the dataaccess attribute of the point to allow world RW access. Or you will need to add an entry for your interface node in the PI Proxy Database on the PI server. Please see the Data Archive manual for more information on how to add a PI proxy entry.

3. Communication lost with PLC X

The interface can no longer communicate with the specified PLC. Check the connection between the PLC and the PC running the interface.

4. Non-numeric character (X) detected in PLC ID for tag xxxxx

Usually this indicates that the extended descriptor has been set up using the old style format. Please see the point configuration section, the INI file section as well as Appendix B for more info on configuring extended descriptors and the INI file using the new style format.

5. DTL DEFINE ERR>DTL_E_DEFBADN, Invalid Number of DEFINE Parameters

Either the extended descriptor or the PLC ID string has been setup incorrectly. Please review the point configuration and INI file sections of this manual to review the expected formats.

6. Invalid DT(x); Check DT define: xxxx, PCCCEXT07> Illegal Size

The size of the data table is bigger than the size of the source file on the PLC. Check the source file on the PLC and see how many elements it has defined. Make sure that the data table that you are defining does not cross the boundary of that file. For instance, if the N7 table only has 10 elements, you will get this error if you try to create a data table starting with N7:4 that is 10 elements long because there are only 6 elements in the table after N7:4.

7. DT(X)>DTL ERROR>DTL_E_BAD_ADDRESS, Bad DTSA_TYPE Station Address

The station number that the data packet returns doesn’t match the expected station number for this tag. This message should only be seen when the interface is collecting unsolicited data. This usually means that the station number specified in the tag does not match the station number being sent by the accompanying message block.

8. DTL error PCCCSTS10, illegal command or format, including an odd address



The station number for this tag is not found on the Allen Bradley network of PLCs. Likely, this is caused by specifying an invalid station number in the PLC ID string.

9. DTL error> DTL_E_UNKERR, unknown error ( 464 )

This indicates that the link ID that was specified in the port_id portion of the PLC ID is invalid. The most common cause of this is specifying the link id as a decimal number. RSLinx has the user specify a decimal value, but the interface requires this value to be converted to octal.

10. DTL_UNSOL_DEF ERR>DTL_E_PLC2MEMORY, Unable to register/unregister for PLC-2 unsolicited

This message should only appear if the /unsol parameter is specified in the startup command file. The error indicates that the data table address that the interface is trying to register is already in use by another program. This usually occurs if you try to setup two unsolicited interfaces to try to read from the same data table address. This can also occur if the interface fails to shut down properly. In the latter cases, a reboot of the interface PC may be necessary to clear the error.


Appendix E. Configuring the RSLinx UNSOL.INI FileThe PIUNSOL.INI file must be located within the RSLinx home directory and can be created with any text editor that comes with your operating system. Below is an example of how the PIUNSOL.INI file is formatted (do not include any comments within this file, those below are just for clarification):

[148.98.79.136] IP Address of Device03154=21 Starting PLC-2 Address, Number of contiguous words being transmitted03275=18 "03160=40[148.98.79.143] IP Address of Device02750=3 Starting PLC-2 Address, Number of contiguous words being transmitted07253=40 "

The PIUNSOL.INI file must be created whenever an application/device needs to send and unsolicited message formatted as a PLC-2 style message, to RSLinx on Ethernet.

When RSLinx is launched it checks for the existence of the PIUNSOL.INI file and, if found the PLC-2 address within that file are register (locked in) to that RSLinx station. Note that the usage of this file is the first RSLinx station that comes on-line with this file, owns these addresses and will lock out any other RSLinx station using identical or overlapping addresses. Again, each RSLinx station can have its own PIUNSOL.INI file but all the address must be unique in each file.



Appendix F. PI-RSConvert Conversion UtilityVersions 2.0 and later of the PI-RSLinx interface use a new format for the interface INI file, the interface BAT file, and the extended descriptor of each PI point. To make the transition from version 1.x to version 2.x a smooth and easy process, there is now an interface conversion utility that will automatically update the BAT and INI files and update each of the PI points as needed. This utility is called PIRSConv.Exe and is only supported for interfaces running on the NT platform. The following steps explain how to set up and use the utility.

1. First, you must install the PI-SDK on the interface node. Version 1.0 of the PI-SDK is available from the OSI Support Web site:

http://support.osisoft.com/ProgTools/pisdk/default.asp

2. Login to NT as a user with administrative privileges.

3. If the /do option is specified in your interface BAT file, make sure to make a backup of the current extended descriptors of your points collected by this interface, just in case there are problems during the conversion. It is easiest to use PI-SMT to do this.

4. Run the PIRSConv.Exe utility. It’s generally most convenient if the utility is located in the same directory as the interface to be converted.

5. The utility will prompt you for the location of the startup BAT file of the interface that needs to be converted. You can either enter the location directly (include the filename at the end of the path) or you can Browse to select the file.

6. Once you have selected the file and the proper filename and path are displayed in the filename window, you can select the Convert button.

7. If the utility is able to locate and parse the file, it will prompt you to verify the interface information that it found in the BAT file, specifically the PI server, the location of the INI file, and the pointsource and the location1 parameters of the points that belong to this interface. If any of the information is incorrect, please edit it and select OK. Or choose Cancel to abort the conversion process.

Note: The PI Server name found in the BAT file may not necessarily match the one that is required by the PI-SDK, since the PI-SDK allows you to name your PI server something other than its network node name. This occurs rarely, but if a connection cannot be established, this is one of the first things to check. Use the PI-SDK name for your PI server instead of the one found in your BAT file if there is a discrepancy.

8. Once you have verified the interface info, you will be prompted for a PI username and password. It is highly recommended that you use the piadmin user to run this utility in order to ensure that all points get converted properly.

9. That’s it! The utility will then attempt to convert the BAT file, and the INI file and PI points if necessary. If the /do option was not being used by your interface, only the BAT file will need to be converted. However, if it WAS specified, then the INI file and PI points will need to be converted, as well. The status window will let you know when the installation is complete and whether or not any problems were encountered. Once the conversion is complete, you can either select another BAT file to convert or select OK to exit.


http://support.osisoft.com/ProgTools/pisdk/default.asp

If there are any problems encountered during the conversion process, you will be notified by pop up error messages or by the status window of the conversion dialog box. The status window will also update with the progress of the conversion. If there was a problem converting any of the points, it will notify you that there were problems.

Note that if the interface has a problem writing the new INI file because of file access permissions, it will write the new entries to the local PI message log. Run pigetmsg on the interface node to see what the new entries should be and update the INI file manually to reflect the changes.

Second, if the utility has a problem updating the extended descriptor of any of the interface points it will write the new extended descriptor to the message log of the PI server. If the status window indicates that some points had conversion problems, run pigetmsg on the PI server to find out what the new extended descriptor should be for each of the points that failed to be converted. Then manually edit the affected points as necessary.

These last two problems should never occur if you are properly logged into NT as a user with Administrative privileges and you login to the PI server using the piadmin PI user.



Revision HistoryDate Author Comments

JUN 11, 1996 RRP Initial Rough Draft per review of OSI

AUG 27, 1996 RRP Revision per Release v1.00

FEB 25, 1997 MMG Revised for NT service and UNIX

MAR 15,1997 PKIM Revision per release v.1.1 (unix, unsolicited mode)

JUN 10, 1997 PKIM Revision per release v.1.23 (/noout, /ini)

DEC 3, 1997 SAN Revision per release v1.27 with UNIINT version 2.25

JAN 16, 1998 SAN Revision per release v1.28, added a few minor notes

MAR 26, 1998 SAN Revision per release v1.29, added /id parameter

OCT 15, 1998 SAN Fixed documentation errors regarding /do switch and unsolicited mode. Added Appendix B and discussion of setting up a message block for unsolicited data retrieval.

JAN 22, 1999 SAN Altered for release version 2.0. Removed tag example section and added troubleshooting section.

APR 28, 1999 SAN Altered for release version 2.06. Moved discussion of old style addressing to Appendix C. Removed all references to /do option, which is obsolete. Changed /noout parameter references to /sio, which is the uniint equivalent.

JUL 1, 1999 SAN Edited for release version 2.08. Added Appendix E that describes the new PI-RSConvert conversion utility.

JUL 28, 1999 JK Edited list of PLCs for clarification (All models of PLC-5 are ok)

FEB 11, 2000 SAN Altered for release version 3.00. Added description of extended API features including support for strings and subsecond timestamps.

MAR 10, 2000 SAN Fixed minor inconsistencies regarding trigger tags & outputs

JUL 18, 2000 SAN Added discussion of subsecond scanning to the /f parameter description. Fixed /ini file documentation error regarding default location of the pirslinx.ini file.

JUL 25, 2000 SAN Added ASCII data type to the available data types for location2.

SEP 14, 2000 SAN Added note that OPC is required to talk directly to ControlLogix processors.

NOV 13, 2000 AKF Updated formatting, added hyperlinks


Allen-Bradley RSLinxcdn.osisoft.com/interfaces/95/PI_ABRSLinx_3.02.doc · Web viewAllen-Bradley...

Documents

Transcript of Allen-Bradley RSLinxcdn.osisoft.com/interfaces/95/PI_ABRSLinx_3.02.doc · Web viewAllen-Bradley...