EPICS: Allen Bradley
Driver and Device Support

Marty Kraimer
Argonne National Laboratory - Advanced Photon Source
Bob Dalesio
Los Alamos National Laboratory - Accelerator Technology
Ric Claus SLAC (Stepper Motor Support)
Stephanie Allison SLAC (SLC 500 Support)
Updated: January 1999

 

 
 
 
 
 


Table of Contents


Release Notes January 1999

Overview

EPICS provides support for the Allen Bradley VMEbus I/O Scanner. Models 6008-SV, 6008-SV1R, and 6008-SV2R can be used. The differences are: EPICS support consists of a driver (drvAb),  device support for standard record types, and  record support for many Allen Bradley I/O modules.

The driver provides the following features:

Device support is provided for the following record types
ai
ao
bi
bo
mbbi
mbbo
mbbiDirect
mbboDirect
For block transfer modules all new support is being developed via device record types together with device support for standard record types. Ultimately all old support for ai/ao device support should be replaced by device record types. Support for the 1771-IL, 1771-IR, and the 1771-OFE modules have not been replaced, i.e. only the old support is available.

The reader should also consult the manuals

EPICS: Allen Bradley - Hardware Reference Manual, Greg Nawrocki,

Allen Bradley manuals:

Installing and Building the Allen Bradley Support

IOC Applications System Manager

The following are instructions for building the allen bradley support in directory <allenBradleyTop>.

If you have access to the epics CVS repository.

    cd <allenBradleyTop>
    cvs checkout -d . epics/unbundled/allenBradley

Otherwise obtain a tar file from the APS WWW site and:

    cd <allenBradleyTop>
    tar -xvf <file>

Next edit config/RELEASE:

    cd <allenBradleyTop>/config
    vi RELEASE

In RELEASE set EPICS_BASE correctly.
Now issue the commands:

    cd <allenBradleyTop>
    gnumake
 

Application Developer

After the allen bradley support has been built, it is ready for use by individual applications. The following are recommended procedures for using it for a specific application.

In <top>/config edit the files CONFIG_APP and RELEASE.

In CONFIG_APP add the lines:
 

ifdef ALLEN_BRADLEY
USR_INCLUDES += -I$(ALLEN_BRADLEY)/include
USER_DBDFLAGS += -I$(ALLEN_BRADLEY)/dbd
ALLEN_BRADLEY_BIN = $(ALLEN_BRADLEY)/bin/$(T_A)
endif
In RELEASE add the line:
ALLEN_BRADLEY=<allenBradleyTop>


In the src directory where record/device/driver support is built.

Scanner Configuration

The default VME configuration parameters are compatible with the previous version of abDrv. Each of the configuration routines can be executed from the vxWorks shell. The new scanners (SV1R and SV2R) require that abConfigAuto and/or abConfigScanListAscii  be executed after the allen bradley driver is loaded and before iocInit is executed.

This section describes a number of configuration commands. They may be given in any order except:

Each 6008-SV and 6008-SV1R supports one link and the 6008-SV2R supports two links.

abConfigNlinks

Format:
abConfigNlinks(number)
The maximum number of VME scanner modules in a VME crate. Each 6008-SV2R counts as two links.  The default is two links.  If this command is given it must be the first scanner configuration command.

abConfigAuto

Format:
abConfigAuto(link)

where:

link   link number
If this command is given the allen bradley scanner will automatically determine the rack configuration. All racks must be turned on in order for this to work.

SUGGESTION: When you have a new configuration use the abConfigAuto command until you are sure the associated abConfigScanListAscii file is defined correctly. Once it is defined correctly do not use the abConfigAuto command because it has extra overhead and also requires that every allenBradley chassis is powered up.

abConfigScanListAscii

NOTE: If the abConfigAuto and abConfigScanListAscii are both given for the same link then only the logical addressing information in the abConfigScanListAscii file has any effect.

Format:

abConfigScanListAscii(link,"filename",setRackSize)
 
link link number starting with 0
filename File name containing information described next.
setRackSize 0 for 6008-SV and 1 for 6008-SV1R or 6008-SV2R

Filename is a file that defines the adapter (rack) configuration for the specified link. It contains a line for each rack. In addition comment lines (any line beginning with the character #) are allowed. The definition for each rack is:

rack,group,size,logicalAddressing
 
rack The rack number. The first rack is rack 0.
group Starting group within the rack.
size Rack size. This must be one of the values 1/4, 1/2, 3/4, Full
logicalAddressing Must be 2,1,1/2 for 2slot, 1 slot, or 1/2 slot logical addressing. This MUST agree with how a physical rack is configured. There is no way for the driver to determine if an error has been made.

 

An example definition is:

#Allen Bradley Scan List
0 0 Full 2
1 0 3/4 2
2 0 3/4 2
3 0 3/4 2
If you do not know your configuration use the abConfigAuto command and then after iocInit finishes execute the command:
dbior "drvAb",4
The link status as reported by the scanner is described in this document. From this you can determine the configuration.
 

abConfigVme

Format:
abConfigVme(link,base,vector,level)
 
link As before
base VME base address. Only 24 bit addressing is supported.
vector Interrupt vector number
level Interrupt level

 

If this routine is not called then the default base and interrupt vector for the first link are taken from module_types (AB_BASE_ADDR and AB_VEC_BASE), which are currently set to 0xc00000 and 0x60. For links other than 0, the base address is relative to that for link (each scanner uses 0x1000 bytes). The interrupt vectors are also consecutive.

For the 6008-SV1R and 6008-SV2R the base address of 0xc00000 corresponds to SW1 = 00000000 and SW2=11000000. Also SW3=00011000.

The default interrupt level is 5.

abConfigBaud

Format:
abConfigBaud(link,rate)
A rate value of (0,1) specifies (57.6,115.2) kbps. The default is 0. All physical adapters must be jumpered to the same baud rate. Note that the 230.4 kbps rate of 6008-SV1R and 6008-SV2R is not supported because the 6008-SV compatibility mode is being used.

Hardware Addressing

Module addressing is described in chapter 3 of the 6008-SVxR manual and also in the Allen Bradley I/O Concepts manual. This section summarizes this information and explains how EPICS terminology relates to Allen Bradley's.

Each Allen Bradley chassis can be configured, via hardware switches on the chassis, for 2 slot, 1 slot, or 1/2 slot addressing. EPICS supports all three types of addressing. Greg Nawrocki's Allen Bradley Document describes how to configure the hardware for 2 slot addressing. If you want to use 1 slot or 1/2 slot addressing his document is still valid except for the following qualifications:

  1. The I/O chassis backplane switches must be configured for the addressing mode desired.
  2. If 1 slot addressing is chosen then any chassis with more than 8 slots appears as multiple racks.
  3. If 1/2 slot addressing is chosen then any chassis with more than 4 slots appears as multiple racks.

Terminology

The terminology and rules connected with addressing Allen Bradley modules is rather confusing. To make matters worse EPICS, in some cases, uses different terms than Allen Bradley. The following is intended to help clarify matters.

Some definitions:

The number of I/O modules addressed as a single rack depends on the addressing mode. For (2 slot, 1 slot, 1/2 slot) addressing a single rack can address (16, 8, 4) I/O modules. Note that for 1 slot and 1/2 slot addressing a single chassis may appear as more than one rack. For example if a 12 slot chassis is configured for 1 slot addressing then it is addressed as two racks even though it has only one adapter.

INP/OUT definitions

The following items are specified when configuring the link field for a database record linked to an Allen Bradley module: NOTE: link, rack, slot, and signal all start from 0.

The binary and old analog support uses the AB_IO link type which has the format

#Llink Aadapter Ccard Ssignal @parm
That is it uses link, adapter, card, signal. The new record types, such as  1771DCM, contain fields link, rack, slot. The reason for switch from (adapter, card) to (rack, slot) is that (rack,slot) more closely match the Allen Bradley documentation.

2 slot addressing

Each pair of slots is called an I/O group. There are restrictions on which I/O modules can share the same group. EPICS addresses each module via the slot number.

1 slot addressing

Unless 32 bit binary modules are present there are no restrictions on module placement. For 32 bit modules the following restrictions apply: EPICS addresses each I/O module via the slot number.Each 8 modules is addressed as a rack. For example if a chassis has 12 slots and it's physical adapter has been configured to start with rack 3 then the first 8 modules are addressed as rack=3 and slot = 0,1,2,3,4,5,6,7 and the last four modules are addressed as rack=4 and slot = 0,1,2,3.

1/2 slot addressing

For 1/2 slot addressing there are no restrictions on where cards may be placed

EPICS addresses each I/O module via the slot number. Each 4 modules is addressed as a rack. For example if a chassis has 12 slots and it's physical adapter has been configured to start with rack 3 then the first 4 modules are addressed as rack=3 and slot = 0,1,2,3 the second 4 modules as rack=4 and slot= 0,1,2,3 and the last four modules are addressed as rack=5 and slot = 0,1,2,3.

Device Support Overview

Allen Bradley devices can be divided into two classes:
  1. Digital devices that are addressed via the I/O image table
  2. Block Transfer Devices, e.g. Analog I/O, stepper motor, etc
Digital devices can be accessed via the Binary Device Support described in the next section.

Until Allen Bradley support was unbundled from base the only block transfer devices supported were 1771IFE, 1771IL, 1771IXE, 1771IR, and 1771OFE. These were supported via device support attached to appropriate record types. This support did not allow complete configuration of the devices. This support is now called Old Analog Support.

The new method of supporting block transfer devices is to provide a record support module for each different device. This type of record is refered to as a device record. Module configuration is done via configuration fields. Device support is also provided to allow appropriate record types to link to the device record.

As each device record (or the old style device support) is initialized the first step is to register the card. The registration call includes the module type (analog input, analog output, binary input, binary output, arbitrary block transfer) and well as a module type name. The first call for a particular link, adapter, card determines the card type. Other calls for the same card are checked for compatibility. The following rules are enforced:

Binary Device Support

Support is provided for 8, 16, and 32 bit input and output digital modules. Device support is provided for the bi, bo, mbbi, mbbo, mbbiDirect, and mbboDirect records.

I/O Interrupt processing is supported for Binary Inputs. Every 1/10 of a second the driver checks for changes in the input image table. If a word changes the device support is notified and requests I/O interrupt processing for the corresponding card. Note that all records attached to the card and with SCAN=I/O Intr will be processed, i.e. no attempt is made to look at individual bits.

When the device support finds that it has just registered a new card, it waits for the driver to have a chance to obtain the current values from the card. These are used to initialize the record, i.e. it restores values when the ioc is rebooted.

The binary device support also works for special Allen Bradley digital devices. It has been tested on the Allen Bradley rediPanel and also on the 1791 Series digital I/O (discused below).

The Allen Bradley rediPanel looks like a single logical adapter that contains one 16 bit digital input card and one 16 bit digital output card each addressed as card 0.

Adapter and Card Status

Two mbbi device support modules (devMbbiAbAdapterStat and devMbbiAbCardStat) allow monitoring of adapter or card status. A record instance can be created for each adapter or card that needs monitoring. Device support, at record initialization time, fills in the mask, string, and alarm severity fields of the record. Thus the user need only program the SCAN, DTYP, and INP fields. Each time the record processes it calls the driver to find the current status. The record is placed into major alarm for any status other than success.

At the present time I/O Intr scanning is not supported by these device support modules, i.e. the record should be set to periodic scanning.

Old Style Analog Input/Output

Several Analog Input modules are supported. For all types device support asks the driver to scan them periodically. The driver attempts to scan at the rate desired but because of time-outs and other problems the rate can not be guaranteed. For all analog inputs, I/O interrupt processing is supported. Whenever the driver obtains a new set of values from an analog input module it notifies the associated device support. Device support checks each channel for a change in value and asks that records attached to that channel be I/O interrupt processed. The records must have SCAN = I/O Intr for this to work.

Old analog support does not provide the ability to configure individual signals of analog modules. Thus all channels on a card are configured identically. The configurations options for a card are determined by the first record that is attached to the card during ioc initialization.

1771 IFE

NOTE: New support via a special hardware record is now available and described below (See 1771-IFE) Thus the support described in this section is now obsolete and should NOT be used for new applications.

The basic scan rate is every 1/10 second.

Several configurations are allowed. The choices are provided via a combination of jumper settings on the module and software configuration, The software configurations supported are:.

1771 IL

The basic scan rate is every 4/10 second.

The only configuration allowed is -10 to +10 volts differential;.

1771 IXE

NOTE: New support via a special hardware record is now available and described below (See 1771-IX (E and HR). Thus the support described in this section is now obsolete and should NOT be used for new applications.

The basic scan rate is every .5 seconds

The configuration options provide for millivolt input (+- 100 millivolt), and for type K, J, E, T, R, and S thermocouples. For thermocouple inputs conversion to degC and degF can be chosen.

The IXE module is chosen by specifying DTYP as "AB-1771IXE-Millivolt In". The configuration option is chosen via the field "LINR", i.e. the conversion type. If the conversion type is "NO_CONVERSION" or "LINEAR" then millivolt conversion is selected. If any of the types typeKdegF to typeSdegC is chosen then the IXE module is configured accordingly. If one of the thermocouple types is chosen device support sets the value of LINR to no conversion so that record support does not attempt any conversions.

NOTE: This method should NOT have been used to choose configuration options. Users are strongly encouraged to use the new 1771-IX(E and HR) support describes below.

1771 IR

The basic scan rate is every 1/2 second.

The module can be configured, via the field DTYP, for Platinum or for Copper.

The PARM portion on the INP field allows configuration of units as follows: The units configuration option is used to configure the board and also to set the EGU field of the record.

The field LINR is set to NO_CONVERSION so that record support does not attempt any conversions.

1771 OFE

The configuration options are all selected via hardware jumpers.

When the device support finds that it has just registered a new card, it waits for the driver to have a chance to obtain the current values from the OFE. These are used to initialize the record, i.e. it restores values when the ioc is rebooted. The software always uses the default software configuration.

Whenever device support is called to write a new value it asks the EPICS driver to write the new value. It is the scan task of the driver that does the actual transfer. the transfer will be requested during the next scan, which happens at 1/10 second intervals.

New block transfer writes to the OFE are requested every 10 seconds even if no new values are requested by record support
 

Stepper Motor Support (Ric Claus SLAC)

These release notes describe changes made to stepper motor related code that was supplied with EPICS Version R3.12.2 SLAC Date: 1996/01/28 01:38:17. Additionally, support is described for the Allen Bradley 1746-HSTP1 stepper motor controller module.

The basic modification was to move the implementation of the initialization algorithm (supplied through the IALG field in a stepper motor record) from the record support code (recSteppermotor.c) to the device or driver support code. This allows the specific device to determine how to move the stepper motor to the positive or negative limit. Both of the stepper motor drivers standardly supplied with EPICS (drvCompuSm.c and drvOms.c) were modified to accommodate this change. Other nonstandard stepper motor support codes will need modification to handle the new SM_FIND_LIMIT (defined in steppermotor.h) command (see the CompuMotor or OMS codes for examples).

In addition, two new algorithms have been added to the list of initialization algorithm choices. These are "Move to Positive Home" and "Move to Negative Home", which are implemented through the new SM_FIND_HOME command. These were added in accommodation of the new device support for the Allen Bradley 1746-HSTP1 stepper motor controller (devSmAB1746HSTP1.c), which allows the use of a home limit switch in addition to the standard end point limit switches. Nonstandard device and driver support for stepper motor controllers which do not have this capability should be modified to ignore or complain when they receive the SM_FIND_HOME command (cf, drvCompuSm.c or drvOms.c).

The new device support code for the Allen Bradley 1746-HSTP1 stepper motor controller requires the EPICS standard issue Allen Bradley driver (drvAb.c).

From the comments at the top of devSmAB1746HSTP1.c [perhaps good for inclusion into the "EPICS: AllenBradley Driver and Device Support" manual?]:

Device support for the 1746-HSTP1 module was written assuming that there are no wiring errors. Consequently, if your apparatus does not agree throughout itself which direction is clockwise (+) and which direction is counterclockwise (-), unexpected things may happen.

The 1746-HSTP1 device support code was written from the perspective of the Allen Bradley 1746-HSTP1 module. Clockwise (+) is therefore defined to be the direction in which the stepper motor axis turns when it is viewed from the shaft end of the motor, as per page 4-18 of the 1746-HSTP1 User's Manual (AB Pub No. 1746-999-121, March 1995).

The 1746-HSTP1 devices have no hardware configuration switches or jumpers to be concerned with. However, "HSTP1 CONFIG OUTPUT WORDs" (Pages 4-4 and A-1 of the User's Manual) must be passed to the device support layer in the parm section of the stepper motor record .OUT field. The string is parsed with the format string "%hi%hi%i" and is allowed to be a maximum of AB_PARAM_SZ (currently #defined to be 26 in include/link.h) characters long. Use only whitespace to separate the values. The three values that must be supplied are:

     Hstp1CfgCsr[0] - Configuration word
     Hstp1CfgCsr[1] - Active level word
     Hstp1StartSpd  - Starting speed word (1 - 250000 pulses/sec)

  An example param string is:    0x8413 0x0010 500
Page 4-4 of the User's Manual states that valid configurations require the home limit switch input and one or both of the end (CW or CCW) limit switch inputs to be enabled, even if the associated switch is not present.

Due to the way in which the HSTP1 handles limit switch conditions, it is best to avoid them. If a limit switch has been activated, one can either issue a Find Home command to the HSTP1 to make it hunt for the home switch, or issue single step (Jog) commands to bump the jig off the switch. The jogging procedure is very slow since it requires a reading the HSTP1 registers to get the current state of the limit switches, a clearing of the HSTP1 command register to make the appropriate jog bit sensitive to transition and a setting of the appropriate jog bit in the command register. A 25 MHz NI VXIcpu-030 operating with an AB 6008-SV1R scanning module can thus achieve a jog rate of about 3 Hz. If a position request causes the jig to run into one of the switches, the only motion requests that are accepted by this code are those that move the jig in the direction of getting off of the switch, again, presuming no wiring errors.

One of the rules of writing EPICS device support code is that the process routine must complete as fast as possible since any delays in it cause other records to be held up. For this reason all commands to this device support layer issued by the record support process routine are queued onto a message queue. The reason it is done this way rather than processing the commands directly is that there are sometimes delays in getting access to the hard- ware, either the VME scanner, or the controller itself. Because it is easy to set up a situation in which EPICS sends commands to this code faster than they can be processed, one must handle the case where the queue fills up. When the queue is full, we break the rules and wait for up to HSTP1_K_EPICSQDLY seconds for previously entered commands to be taken off the queue in an attempt to throttle EPICS. If the timeout expires, bad status is returned to indicate that the command could not be handled at the time. Typically, the queue is configured to be deep enough that this situation never arises.

In order to reduce the chance of a knobbed .VAL field from overflowing the command queue, the motor is declared to be moving as soon as a motion request is recognized, even though it is not necessarily moving yet. This prevents the record support layer from sending out corrections until the motor arrives at the requested spot. However, there is a problem because if the position request is changed while the motor is still moving, it will be ignored by the record support. To prevent this, supply a non-zero retry count and an appropriate deadband when setting up your database. Additionally, always put knobs and sliders in "release" mode rather than in "motion" mode.

The basic scan rate when there are active stepper motors is 1/3 second. When there are no active stepper motors, this code sleeps. Consequently, any manual motion of the stepper motor axes is not accounted for.

This code can, in principle, handle an arbitrary number of 1746-HSTP1 stepper motor controller modules. However, limitations are provided by memory, semaphore, and message queue resources, and bus and "blue hose" bandwidths. Note that this code spawns only two tasks, both of which are terminated with corresponding resources freed if no stepper motor records are found in the system.

1791 Series Support

1791 Analog Block I/O

Allen Bradley 1791 Block I/O consists of small, self-contained remote I/O devices. Each device contains 4 analog input channels and 2 outputs. Each 1791 can be configured as a full rack or up to four 1791 modules can be configured as a single rack(not tested).

EPICS support consists of a device record ab1791Record and device support for the ai and ao record.

In addition to dbCommon, ab1791Record  contains the following fields:

VAL
Not used.
TYPE
Menu field specifying Voltage or Current
RANG
Menu field specifying range.
FILT
Menu field specifying filter option
LKST
Character string giving status. NOTE: The VAL field should have been used for this purpose.
LOCA
Loss Of Communication Acknowledgement. If yes then a scanIoRequest will be issued for all DCM words. Thus any records attached to the record and declared I/O Intr scanned will be processed.
LINK
RACK
SLOT
The allen bradley scanner, rack, and slot.
NFAI
Number of failures.
INPi (i=0,...,3)
Raw value of channel 0
OUTi (i=0,1)
Raw value of channel 0
These fields provide for configuration and also run time statis and statistics.

The process routine processes according to field SCAN. It keeps internal state that determines what is done each time it processes, i.e. initialize, write, read. It make block transfer requests to the driver. It follows the asynchronous record processing model, with the completion phase being triggered when a block transfer request completes. It honors I/O interrupt scanning for attached device support.

It provides device support for ai and ao record. Device support links to a particular ab1791Record via the INP or OUT field. The bus type is specified as INST_IO, which specifies only a parm for the link. Parm is set equal to the <record_name>.<field_name> of the input or output channel desired.

1791 Digital Block I/O

The standard binary device support can be used. If you use 32 bit binary I/O all bits can be addressed as one card.

1771-DCM Direct Communication Module

The abDcm support is designed to monitor messages received from personnel and/or equipment protection systems. Because the other system is a safety system, the design minimizes interaction between the two systems. The protection system is likely to be a Program Logic Controller (PLC).

In addition control messages can be sent from an IOC to the PLC via the DCM.

The following is expected of the PLC. The PLC must contain one or more AB 1771-DCM modules. Communication via each DCM is modeled as follows:

  1. The dcm resides in the PLC.
  2. The PLC continuously sends a set of messages. A message is just 64 short words. Word TOFF is the message number. Thus the PLC does the following:
  3.        1) Send message with message(toff) = 0
           2) Send message with message(toff) = 1
              ...
           n) Send message with message(toff) = n-1
           go to step 1)
    The dcm is strapped so that the PLC can not send a message until the IOC has read the previous message. The number of messages must be between 1 and 10.
  4. The PLC must assume that the EPICS system may be down and thus is not currently reading.
  5. The PLC developer and the EPICS developer must agree on the what the messages mean. Normally message words are just words transfered from the PLC's I/O Image tables.
  6. Word 0 of each message is used by the dcm for status. Thus TOFF must be >0.
  7. The PLC system must also read dcm mesages sent from the ioc if output to the PLC is desired. The messages have the format:
  8.    word 0 - dcm status word
       word 1 - Tag number, i.e. message tag.
    All other DCM words are data words. For data see output device support given below. The PLC developer and the EPICS developer must agree on the what the tag values mean.
The following are the DCM switch settings used in a system at APS.
Bank    Switch  Setting
0       1       OFF     115.2 baud (scanner must be configured)
0       2       OFF     Not Used
0       3       OFF     Last Rack
0       4       ON      Block Transfer (DONT CHANGE THIS)
0       5       OFF     Not Used
0       6       OFF     Protected Data (DONT CHANGE THIS)
0       7-8     OFF     Rack Size

1       1-6     (Determines adapter(rack) number
1       7-8     ON ON   First Module Group Number
The next part of this note describes EPICS support for reading the dcm.

EPICS support consists of a device record abDcmRecord and device support for the ai, bi, li, and mbbi records.

For each physical DCM, the application will create an abDcmRecord instance. Thus the rest of this note explains things from the point of view of a single dcm.

Each time the abDcmRecord is processed (by normal scan mechanisms such as periodically), it reads one set of messages. The dcm record has fields T0, T1, ... T9. Each is an array of 64 shorts. Each holds one of the messages of the set. Note that when it starts it does not look for message 0 first. Instead it just takes the messages as they come until n messages are received.

The complete set of fields (not including dbCommon) of abDcm are as follows:

VAL
This is a character string field that gives the status of the link to the dcm. It can be used by Channel Access Clients to monitor the link status.
DCMT
DCM type. This specifies if the DCM is a real DCM or a PLC adapter port.
Ti
(i=0,...9) Field containing message i. Each field is array of 64 shorts.
NT
Number of tables, i.e. messages, to use.
TOFF
The offset in each table that contains the table number.
DLY
Delay in seconds before sending block transfer request. This is provided in case the PLC is not executing BT writes quickly enough. Suggestion: Start with this field set to 0. If LKST reports extra messages then specify this field. The actual delay will be in clock ticks. If DLY>0 then at least one clock tick will be forced. Fractions of a second are permitted.
LOCA
Loss Of Communication Acknowledgement. If yes then a scanIoRequest will be issued for all DCM words. Thus any records attached to dcm record and declared I/O Intr scanned will be processed. Note that this will cause alarm storms.
LINK

RACK
SLOT
These fields identify the location of the dcm module. LINK is the allen bradley scanner number, RACK the rack (EPICS calls this adapter). SLOT is the location within the rack. See the EPICS Allen Bradley documentation for details.
MCW
Maximum consecutive writes before switching to read. This prevents write storms from stopping input.
Device support is available for ai, bi, mbbi, li records. In each case the application developer configures the record by specifying the appropriate value for DTYP "Ab Dcm", and then giving a value to INP The value specified is either in the form
        dcmrec.Ti[word]
or
        dcmrec.Ti[word,bit]
The first form is for ai and li. The second form is for bi and mbbi. The meaning is as follows
dcmrec
The name of the dcm record containing the data of interest.
Ti
The table containing the data for message i.
word
The word containing the data (4 to 63)
bit
The bit within the word (0 to 15 starting from low order bit)
bi,mbbi, and li
always refer to 16 bit words. ai must reference a double word that is in IEEE floating point format. In addition ai records MUST reference even words.
All dcm device support provides I/O Intr scanning. In fact this is the prefered mode of scanning since it minimizes cpu usage.

The remainder of this message describes output capability.

Device support for the record types is provided:

The link fields of the output records are of the form:
dcmrec[tag]
Where tag is the value agreed upon with the PLC programmer.

The data values are:

ao
- IEE float format
bo, mbbo, longout
- unsigned short value
A vxWorks shell command exists to dump the data tables.
int dcmpt(char *name,int first,int last)
for example
dcmpt("dcmrec.T0",0,10)

1771-N Series Analog Modules

NOTE:  The NSeries is actually a set of 21 different devices. Although the support has been written to support all types only the 1771NT1 and 1771-NOV have been tested.

EPICS support consists of a device record ab1771NRecord and device support for the ai and bo records.

The ab1771NRecord can be scanned at up to a 10 Hz rate. Each time it is processed it reads the associated 1771-N module. It provides I/O interrupt support for ai records. When associated ao records are processed, the ab1771NRecord is notified of the change and when the next process occurs, the 1771-N module is updated.

ab1771NRecord has the following fields:

VAL
A string field showing status of the ab1771N module.
CMD
A command field. It currently has the values "None" and "Initialize". When the Initialize command is issued, the module is reinitialized. Several configuration fields can be dynamically changed. Until the Initialize command is given, however, the new values have no effect. The command field allows the user to change several configuration fields before the module is reinitialized. The following configuration fields can be changed after iocInit: CJAE, FILi, RALi, OHMi.
LOCA
Loss Of Communication Acknowledgement. If yes then a scanIoRequest will be issued for all inputs. Thus any records attached to the record and declared I/O Intr scanned will be processed.
LINK
RACK
SLOT
The allen bradley scanner, rack, and slot containing the 1771-N module.
OUTM
INPM
These are array fields that hold the raw output and input messages sent to the 1771-N module.
IAI1
IAO1
Fields that hold the address on the interfaces for device support.
MTYP
A menu field which specifies the module type.
SCAL
A menu field which specifies the temperature scale. The choices are degF, degC, and Ohms (for RTD devices).
CJAE
Should the Cold Junction Alarm feature be enabled
CJS
Cold Junction Status
CJT
Cold Junction temperature.

Each channel has the following fields (i =1,...8).
TYPi
The channel type. Record support checks that the type chosen is valid for the module type. An error message is issued if a mismatch occurs.
FILi
Filter time constant.
RALi
Channel rate alarm.
OHMi
If TYPi is RTD Copper this is the 10 ohm offset.
STAi
Status for channel.
RAWi
Raw value for channel.

 

Print I/O messages

The following routine prints the last input and output messages:
ab1771Npm("record name")

Device Support

Device support consists of two general purpose device support modules
 
device(ai,INST_IO,devInterfaceAI1,"InterfaceAI1")
device(ao,INST_IO,devInterfaceAO1,"InterfaceAO1")
The INP  (OUT is similar) field of an ai record has the form:
    field(INP,"record_name[signal]")
where
    record_name - The name of the 1771N record instance
    signal - signal number. signals are numbered 0,...7.
Thus signal 0 means to channel 1, etc.

1771-IX (E and HR)

This is support for the 1771-IXE and 1771-IXHR modules. Each supports millivolt and Tc inputs. Support consists of a device record ab1771IXRecord and device support for the ai record.

The ab1771IXRecord can be scanned at up to a 5 Hz rate for an IXHR module and 2 Hz for an IXE module. Each time it is processed it reads the associated module. It provides I/O interrupt support for ai records.

The ab1771IXRecord has the following fields.

VAL
A string field showing status of the module.
CMD
A command field. It currently has the values "None" and "Initialize". When the Initialize command is issued, the module is reinitialized.
LOCA
Loss Of Communication Acknowledgement. If yes then a scanIoRequest will be issued for all inputs. Thus any records attached to the record and declared I/O Intr scanned will be processed.
LINK
RACK
SLOT
The allen bradley scanner, rack, and slot containing the  module.
OUTM
INPM
These are array fields that hold the raw output and input messages sent to the module.
IAI1
Field that hold the address on the interfaces for device support.
MTYP
A menu field which specifies the module type. It specifies either an IXE or anIXHR module.
TYPA
Type for channels 1-4.
TYPB
Type for channels 5-8.
SCAL
A menu field which specifies the temperature scale. The choices are degF or degC.
STIM
Sample Time. See Allen Bradley Documentation for details
ZOOM (IXHR only)
Should zoom be enabled
ZCA
Zoom center for channels 1-4
ZCB
Zoom center for channels 5-8
FILA (IXHR only)
Filter value channels 1-4
FILB (IXHR only)
Filter value channels 5-8
CJT
Cold Junction temperature.
Each channel has the following fields (i =1,...8).
STAi
Status for channel.
RAWi
Raw value for channel.

 

Print I/O messages

The following routine prints the last input and output messages:
ab1771IXpm("record name")

Device Support

Device support is the same as the ai device support for the 17771-N series described in the previously.

1771-IFE

This is support for the 1771-IFE. Support consists of a device record ab1771IFERecord and device support for the ai record.

The ab1771IFEecord can be scanned at up to a 10 Hz rate. Each time it is processed it reads the associated module. It provides I/O interrupt support for ai records.

The ab1771IFERecord has the following fields.

VAL
A string field showing status of the module.
CMD
A command field. It currently has the values "None" and "Initialize". When the Initialize command is issued, the module is reinitialized.
LOCA
Loss Of Communication Acknowledgement. If yes then a scanIoRequest will be issued for all inputs. Thus any records attached to the record and declared I/O Intr scanned will be processed.
LINK
RACK
SLOT
The allen bradley scanner, rack, and slot containing the  module.
OUTM
INPM
These are array fields that hold the raw output and input messages sent to the module.
IAI1
Field that hold the address on the interfaces for device support.
SEDI
A menu field to choose between single an double ended.
FILT
The filter time constant. The value is an integer between 0 and 99, which represents 0 to .99 seconds.
STIM
Real Time Sample Mode (0 to 0x1f). See the Allen Bradley 1771-IFE manual for the meaning on this field.
Ri
Range for signal i.  I is 0 to 7 id SEDI is double ended and 0 to 15 if SEDI is single ended.

 

Print I/O messages

The following routine prints the last input and output messages:
ab1771IFEpm("record name")

Device Support

Device support is the same as the ai device support for the 17771-N series described previously.

SLC 500 DCM


Support consists of device support (module devABSLCDCM.c) for the following:

device(ai,AB_IO,devAiAbSlcDcm,"AB-SLC500DCM")
device(ai,AB_IO,devAiAbSlcDcmSigned,"AB-SLC500DCM-Signed")
device(ao,AB_IO,devAoAbSlcDcm,"AB-SLC500DCM")
device(longin,AB_IO,devLiAbSlcDcm,"AB-SLC500DCM")
device(longout,AB_IO,devLoAbSlcDcm,"AB-SLC500DCM")
Device support is provided for the Allen Bradley SLC 500 DCM. This DCM has a table of 8 16-bit words (slots) where the first word is reserved for status. The next 7 words are used for either reading or writing or both (the read and write areas are kept separate). The device support uses the same INP/OUT definition as other Allen Bradley modules where the card is the word in the table multiplied by 2 (card 0 to 14 for word 0 to 7).

Binary and multibit binary device support is the same as the general 16 bit binary support (AB-16 bit BI and BO). For diagnostic purposes, it is good practice to have a multibit input record defined for the DCM status word (Success = 0x0000, mode error = 0x0300, and invalid data = 0x0500 and 0x0700).

Longin and analog device support is also provided (AB-SLC500DCM). The underlying logic is very similar to the binary device support with extra processing added depending on the specific record type. Linear conversion is available for analog records. Analog output linear conversion assumes only positive values and the raw value (RVAL) will range from 0 and 0x7FFF, corresponding to low and high engineering units (EGUL and EGUF). Two different types of device support is provided for analog inputs (AB-SLC500DCM and AB-SLC500DCM-Signed). Signed analog input device support is meant to be used by records with EGUL set to -EGUF that need linear conversion.

The general adapter and card status device support may be used for monitoring the SLC 500 DCM (AB-Adapter Status and AB-Card Status). One adapter status may be defined for the DCM and one card status mbbi record may be defined for each word in the table.

drvAb: The Allen Bradley Driver

EPICS provides a driver, drvAb, for the Allen Bradley VME I/O scanner. This driver provides support for software that interfaces to specific types of I/O modules, e.g. device support. In addition it provides support for configuring the scanner itself and also to reset the scanner.

This section first discusses initialization, then the I/O report, and finally the software interface to the driver.

Initialization

The driver has a normal EPICS driver entry table. When the initialization call is made the first thing the driver does is to see if the scanner is already initialized. If it is the driver does not reinitialize the scanner. This will be true whenever the scanner is running and a non-powerup reboot occurs.

NOTE: Chassis switch #1

If this switch is off then the output image table is set to all zeros whenever the scanner is initialized or a hard reboot is performed. Thus is the switch is off then only a ctl/x reboot preserves the output image table. Note that a ab_reset reinitializes the scanner.

If this switch is on then only a VME power cycle will cause the output image table to be reset. Thus a hard reboot or ab_reset can be issued without causing the output image table to be set to zeros.


Binary output and analog output device support both attempt to initialize their associated records with values obtained from the I/O modules.

I/O Report

The following is an example report issued via the vxWorks command:

dbior "drvAb",3

Driver: drvAb
AB-6008SV link: 0 osw 00ec vme: 0xf0c00000
OSW is the current operating status word. Consult the AB manual for details. VME is the base VME address for this scanner.
    AB-6008SV link: 0 osw 00ac vme: 0xf0c00000
    6008SV2R Scanner  Series A Revision B Copyright (c) 1995,96  Allen-Bradley Company
The above message identifies the current version of the Allen Bradley Scanner. This message only appears after a power up reboot, i.e. it will not appear for a ctl/x reboot.
         Mailbox lock timeouts 0
              Command timeouts 6
               Command Failure 0
         Interrupts per second 79
    Block Transfers per second 39
The above, which is only displayed if the print level is > 2, displays the information returned by the scanner for the last link status command. See the Allen Bradley Scanner manual for details. It is essential that you learn how to interpet this report. For example the first word (1f20) states that the first rack is:
  Adapter 0 ONLINE 2 slot addressing
    CARD 0: BIBO  8_Bit Scanning in 0x0 out 0x0
    CARD 1: BIBO  8_Bit Scanning in 0x0 out 0x0
  Adapter 1 ONLINE
    CARD 0: AI  Scanning IFEDIFF initialized 1 times
  Write
  ffff ffff 0700 ffff 0000 0000 4095 0000 4095 0000 
  4095 0000 4095 0000 4095 0000 4095 0000 4095 0000 
  4095 0000 4095 0000 4095 0000 4095 0000 4095 0000 
  4095 0000 4095 0000 4095 0000 4095 
  Read
  0000 0000 0000 0000 064f 064e 04c4 04c4 0d0c 0d0d 
  0e08 0e08 
    CARD 1: AO  Scanning OFE initialized 1 times
  Write
  0650 04c5 0d0d 0e08 8000 
  Read
  0bcd 08b3 0698 086b 0040 
    CARD 2: BI  8_Bit Scanning 0x81
    CARD 3: BO 16_Bit Scanning 0x81
    CARD 4: BI 16_Bit Scanning 0x8001
    CARD 5: BO 16_Bit Scanning 0x8001
    CARD 6: BI  8_Bit Scanning 0x0
    CARD 7: BO  8_Bit Scanning 0x0
    CARD 8: BI 16_Bit Scanning 0x0
    CARD 9: BO 16_Bit Scanning 0x0
 (Many more lines left out)
For each adapter the following information is displayed:

Include File

The following include file defines the interface to the driver
/* drvAb.h */
/* interface types */
typedef enum {
    typeNotAssigned,typeBi,typeBo,typeBiBo,typeAi,typeAo,typeBt
} cardType;

/* status values*/
typedef enum{
    abSuccess,abNewCard,abCardConflict,abNoCard,abNotInitialized,
    abBtqueued,abBusy,abTimeout,abAdapterDown,abFailure
} abStatus;

extern char **abStatusMessage;
typedef enum{
    abBitNotdefined,abBit8,abBit16,abBit32
} abNumBits;

extern char **abNumBitsMessage;
/*entry table for dev to drv routines*/
typedef struct {
    abStatus (*registerCard)
        (unsigned short link,unsigned short adapter, unsigned short card,
        cardType type, const char *card_name,
        void (*callback)(void *drvPvt),
        void  **drvPvt);
    void (*getLocation)
        (void *drvPvt,
        unsigned short *link, unsigned short *adapter,unsigned short *card);
    abStatus (*setNbits)(void *drvPvt, abNumBits nbits);
    void (*setUserPvt)(void *drvPvt, void *userPvt);
    void *(*getUserPvt)(void *drvPvt);
    abStatus (*getStatus)(void *drvPvt);
    abStatus(*startScan)
        (void *drvPvt, unsigned short update_rate,
        unsigned short *pwrite_msg, unsigned short write_msg_len,
        unsigned short *pread_msg, unsigned short read_msg_len);
    abStatus(*updateAo)(void *drvPvt);
    abStatus(*updateBo) (void *drvPvt,unsigned long value,unsigned long mask);
    abStatus(*readBo) (void *drvPvt,unsigned long *value,unsigned long mask);
    abStatus(*readBi) (void *drvPvt,unsigned long *value,unsigned long mask);
    abStatus(*btRead)(void *drvPvt,unsigned short *pread_msg,
        unsigned short read_msg_len);
    abStatus(*btWrite)(void *drvPvt,unsigned short *pwrite_msg,
        unsigned short write_msg_len);
    abStatus (*adapterStatus)
        (unsigned short link,unsigned short adapter);
    abStatus (*cardStatus)
        (unsigned short link,unsigned short adapter, unsigned short card);
}abDrv;
 
extern abDrv *pabDrv;
abDrv is a structure containing all the routines (methods) supported by the driver that can be used to access specific Allen Bradley I/O.modules. pabDrv, is the address of this structure.
int ab_reset(void);
int ab_reset_link(int link);
int abConfigNlinks(int nlinks);
int abConfigVme(int link, int base, int vector, int level);
int abConfigBaud(int link, int baud);
int abConfigScanList(int link, int scan_list_len, char *scan_list);
#endif /*INCdrvAbh*/
The above commands can be issued from the vxWorks shell.

Card Registration

Before any I/O module can be accessed, registerCard must be called. For example to register a binary card the following call is issued:
abStatus        status;
unsigned short  link,adapter,card;
void            *drvPvt;
...
status = (*pabDrv->registerCard)(link,adapter,card,
  typeBi,"BINARY",userCallback,&drvPvt);
switch(status) {
case abSuccess:
  /*Success. This card was previously registered*/
  ...
case abNewCard:
  /*Success. This is the first registration call for this card*/
  ...
default:
  /*All other status values are errors*/
  printf(" error: %s\n",abStatusMessage(status);
  ...
}
RegisterCard performs the following functions:

Type Independent Commands

Commands are available to get the card location, retrieve status of a card, and to specify and retrieve a user private pointer.

getLocation

This routine, given the drvPvt field, returns the link, adapter, and card. This is useful for a callback routine that handles multiple card types.

getStatus

Retrieves the status for the communication with the card. It returns one of the following values: Note that the status values returned depend on the type of card. For example binary cards never return any of the block transfer related status values.

setUserPvt getUserPvt

These routines store and retrieve a void * pointer in the private structure managed by abDrv.

Binary I/O

After registerCard, setNbits must be called before other driver calls. The actual algorithm executed by the read and update routines are determined by the number of bits specified in the call to setNbits.

setNbits

Before a binary module can be accessed the routine setNbits must be called. The first call to this routine for a card determines the number of bits. If a conflict arises abFailure is returned. The caller may proceed at it's own risk. The first call to setNbits for a card also sets that card active. All active input cards are scanned every 1/10 second. If any bit has changed since the last scan the binary input callback routine specified in registerCard is called.

readBi

This command retrieves, from the input image table, the current value of the binary input word. Note that the user supplies a mask that determines the bits that can be set in the value, i.e. the image table value is logically ored with the mask. It returns the value returned by getStatus.

readBo

This command retrieves, from the output image table, the current value of the binary input word. Note that the user supplies a mask that determines the bits that can be set in the value, i.e. the image table value is logically ored with the mask. It returns the value returned by getStatus.

updateBo

This command performs the following operations:

Binary Scanning

The scan task discussed in the next section also checks binary modules. For both bi and bo the user supplied callback is called whenever the adapter status changes. For binary inputs the user callback is called whenever the value changes.

Block Transfer Requests

Both block transfer reads and writes can be issued. Only one request at a time can be outstanding. When the block transfer completes the user callback, supplied in the call to registerCard, is called. It is permissible to issue another block transfer read or write request from the callback routine. If a block transfer request fails, the driver will retry a total of 10 times before it reports a failure to the caller.

btRead btWrite

These routines return abBtqueued if the block transfer request is successfully queued. The caller must be prepared to deal with problems like ablinkDown. If a request is already outstanding then abBusy is returned.

Analog Scanning

abDrv provides scanning support for analog modules. The card type, specified when calling registerCard, is either typeAo or typeAi. The actual meaning of these terms is: For each link, i.e. VME scanner, abDrv spawns a scan task. This task runs, waits 1/10 second, runs, etc. This task keeps track of adapter status, card initialization, and periodic (reads, writes) of each typeAi and typeAo module.

It calls the callback whenever an adapter changes status or whenever a periodic block transfer completes. Note that no callback is made when the initialization block transfer completes.

After registerCard is called, startScan must be called to start scanning. This call specifies the output and input block transfer messages as well as the update rate. The update rate is in units of.1 seconds, i.e. the basic scan task rate. It should be notified that this is not a guaranteed rate. The scanner retries unsuccessful block transfer requests several times before calling the user supplied callback. Also the "blue hose" may limit the number of block transfers.

adapterStatus cardStatus

These routines return the current adapter/card status.

Scanner Reset

Two vxWorks shell commands are available to reinitialize the VME scanner. Hopefully these routines will never be needed.

ab_reset

This command resets all links.

ab_reset_link(link)

This command resets a specific link.