Message Passing Facility
Industry Pack Support

Release 1-4

Marty Kraimer
September 21, 1999


MPF will replace HIDEOS
Hardware Configurations
Install and Build MPF
Multiple Processor VME system
Getting Started
Using MPF in Applications
MPF Directory Structure
Epics Record to IP - Flow of Control
Message Passing Overview
Diagnostic Aids
Message Routers
MPF Device support
Utility Classes
Industry Pack Support
Serial Support
Gpib Support
Systran DAC128V Support
EXAMPLE Implementation: ip330Scan


The following people have contributed to MPF.
Jim Kowalkowski
Jim developed HIDEOS, the precursor of MPF. Many of the basic ideas for MPF come from Hideos. In addition the IP support for the ip330, GpibGsTi9914, OctalUart, and dac128 started with the Hideos support for these modules
Joe Sullivan
Joe developed the vxWorks board support packages that allow VME back plane communication.
Tom Coleman
Tom developed the original 162 Industry Pack Support and GpibGsTi9914 for MPF.
Mohan Ramanathan
Mohan was an early user of MPF and suffered patiently through the initial problems.
Andrew Johnson
Andrew made the changes so that his ipic support could be used with MPF.
Mark Rivers
Mark contributed many ideas that make the serial support general purpose. In addition he implemented the dac128 support.



This document describes a set of software which allows EPICS to access Industry Pack devices attached to the same or to remote processors. The following components are described:

Message Passing Facility

MPF provides client server message passing.  The messages are handled by message routers. Both local and remote message routers are provided.
Industry Pack Support
Industry Pack modules are supported via drvIpac, which supports dumb VME carriers as well as the mv162 and mv172. For details see drvIpac.
Epics Device Support for the MPF
Device support is provided that communicates with MPF.
All code is written in C++. It is written to minimize dependencies between various components. For example the IP support can be used without MPF, MPF without the IP support, etc. The current implementation uses the standard C library but not the standard C++ library.

MPF replaces HIDEOS


Experience has shown that "bare" HIDEOS is too hard to use and extend. The debugging environment is not only different than vxWorks but more primitive. Porting Hideos to new architectures would be a major task because it requires generating a "board support package" for each architecture. It must be mentioned, however, that many of the basic ideas are taken from Hideos. Hideos was doing a lot of things well.


The basic strategy is to abandon "bare" Hideos. Instead vxWorks will be required.

The most important goal is to provide a migration path for existing HIDEOS applications. An EPICS Hideos application uses the following Hideos components:

EPICS Records

The DTYP and INP fields of records can specify a connection to HIDEOS device support.  For some devices, MPF supports the HIDEOS conventions, which means existing EPICS record instances do not have to be modified when converting from HIDEOS to EPICS. In other cases, e.g. the ip330, changes are necessary.
Hideos Device Support
Modified to interface to the new MPF.
Hideos IP tasks
These are more generic. IP support is independent of MPF. MPF servers are provided to talk to the IP support.
Message Types
Message types are more general than the Hideos messages. Network messages are passed in an architecture independent representation. Hideos only allowed in-line methods. MPF removes this restriction.
Everything currently residing under the HIDEOS_SYS sub directory is abandoned.
MPF provides all the features needed to support existing Hideos IP tasks and the Hideos EPICS device support.  Existing support must, however, be modified. In addition it provides the following features not supported by Hideos.
  1. Network Transparent message passing. This allows messages to be passed between different machine architectures.
  2. Connection Management - The initial release allows either server or client to be started first. It allows either client or server to be rebooted without booting the partner. Rebooting the server usually works without rebooting the client. The converse has not been successfully tested.
  3. Messages can have regular methods. (HIDEOS required that all message methods be inline)

Hardware Configurations

The following configurations are supported: The first option has been tested on an mv162 and an mv172 It should work on any IP processor configured to run epics base release 3.13.beta12 or later.  The second option has been tested with an mv167 communicating with a mv162, and with an mv172 communicating with an mv162. The third option should now work but has not been tested (it is effectively identical to option one, but is not restricted to the mv162 and mv172 CPU boards).

When MPF is used between processors, communication is via a tcp connection. Thus the two processors can reside anywhere as long as it is possible for them to communicate via tcp.

Install and Build MPF

The following are instructions for building mpf in directory mpf under your home directory.

Obtain a tar file via mrk aps home page.

tar -xvf <file>
Next edit config/RELEASE:
cd mpf/config
cd ..

In order to run the tests included with MPF, the following files must be edited in mpf/iocBoot

The inet address "" must be replaced by the address of your test mv162.

Now issue the commands:

cd mpf
Now proceed to the next two sections.

Multiple Processor VME system

This section describes how to set up a system that has two or more processors in a single VME crate: The following IP address (all in same subnet) are needed: Board support packages for the mv167 and mv162 can be obtained from Joe Sullivan. The boot parameters have the following form:


boot device          : ei
processor number     : 0
host name            : <host>
file name            : <full path>/vxWorks
inet on ethernet (e) : <IPmv167>:<subnet mask>
inet on back plane (b): <IPgateway>
host inet (h)        : <IPhost>
gateway inet (g)     :
user (u)             : <user>
ftp password (pw) (blank = use rsh): <password>
flags (f)            : 0x0
target name (tn)     : ioc167
startup script (s)   : <full path name>/st.cmd
other (o)            :
boot device          : sm=0x80000600
processor number     : 1
host name            : <host>
file name            : <full path>/vxWorks
inet on ethernet (e) :
inet on back plane (b): <IPmv162>
host inet (h)        : <IPhost>
gateway inet (g)     : <IPgateway>
user (u)             : <user>
ftp password (pw) (blank = use rsh): <password>
flags (f)            : 0x0
target name (tn)     : ioc162
startup script (s)   : <full path name>/st.cmd

Getting Started

The mpf/iocBoot directory has a number of sub directories for running mpf tests and/or examples. The best example is a test which connects an epics database to a remote processor. To start the test: NOTE: In order to use the serial port tests a greensprings octal uart ip module is required. The tests assume that each of the 8 ports echos each character written to it, i.e. just wire pin2 to pin 3. The test assumes the ip module is installed in site IP_b.

The test consists of the following:

Studying this example should give a good idea of how MPF works. In particular look at the following files because they give examples of things developers are likely to do.
mpf/dac128VApp/src This is an example of support for an ip device. It shows all required source modules: The ip support itself, an MPF server, and EPICS device support. Since this is a very simple device, the support can be used like a template for support for new ip modules.
mpf/mpfServerApp/testSrc/ The echo server for Int32 messages.
mpf/mpfServerApp/testSrc/ The makefiles, etc show how to build server applications.
mpf/epicsDevApp/testSrc/ The device support described above.
mpf/epicsDevApp/testSrc/ The makefiles, etc. show how to build client applications.
mpf/epicsDevApp/Db/*.db The databases for the example.
mpf/iocBoot/iocrstclient All files. NOTE: cdCommands is generated by make.
mpf/iocBoot/iocrstserver All files. NOTE: cdCommands is generated by make.

Studying the above will show how to write servers, device support, build servers and client, and boot servers and clients.

Using MPF in Applications

It is a good idea to keep mpf separate from applications which use it. An application can access mpf components by making the following changes in the application <top>/config directory.

Edit the files CONFIG_APP and RELEASE.

In CONFIG_APP add the lines:

ifdef MPF
USR_INCLUDES += -I$(MPF)/include
MPF_BIN = $(MPF)/bin/$(T_A)
In RELEASE add the line:
MPF=<full path name>
Then in Makefile.Vx statements like
LIBOBJS += $(MPF_BIN)/mpfLib
can be added. In addition .dbd files can be taken from mpf. For example:
include "devMpf.dbd"
If an application only uses the C++ interface to the industry pack support software that is defined by mpf in the header files IndustryPackCarrier.h and IndustryPackModule.h, then it should not need its configuration to be linked to the external ipac module as it can obtain the ipacLib library file directly from mpf.


This is where the various MPF binary files are installed. It contains a subdirectory for each target, e.g. mv167. This section describes the components most likely to be included by applications.

Epics applications

Server applications

Complete list


The following provide device definitions for use by epics applications:

MPF Directory Structure

Components which are of interest in the mpf tree are:
config This is almost exactly like <top>config described in the 3.13.1 version of makeBaseApp
RELEASE EPICS_BASE must be defined correctly.
utilSrc DLList, DataFreeList, FreeList, and WatchDog; Builds mpfUtilLib.
kernelSrc Contains the MPF code: Message, Routers, Tcp support; Builds mpfKernelLib
messageSrc Contains the code to build specific message types. If new messages type are added this is the place. If it proves necessary to support an endless number of message types a better way of building new message types must be developed. Builds mpfMessageLib.
libSrc Builds mpfLib which contains mpfUtilLib, mpfKernelLib, and mpfMessageLib.
testSrc Contains some low level test programs. Not of interest except for MPF core development.
ipApp/src The current ip support: Ip itself, Gpib, Serial Support.
mpfServerApp/serverSrc Contains gpibServer and serialServer. gpibServer is a generic server for gpib that is usable for remote gpib communication by any EPICS applications which use the gpib support provided with epics base. serialServer is generic MPF SerialPort support but as described elsewhere is not usable by all serial applications.
mpfServerApp/testSrc Contains serverInt32 and serverChar8Array which just echoes the messages sent to them. They are intended for testing and examples. clientInt32 and clientChar8Array are MPF clients. They are good examples of an MPF client and are also used for testing.
epicsDevApp/Db and adl Db contains the epics databases for the example in iocrstclient. adl contains the example medm screen.
epicsDevApp/epicsDevSrc This contains epics device support. Look at for an example of how to write MPF device support.  The code in epicsDevApp/testSrc/epicsDevApp/ is also a good example.
dac128VApp/src This is a good example of a complete set of support for an IP module, i.e. the ip support, a message server, and EPICS device support. Since this is a particularly simple device this can be used as a template for new devices.
iocrstclient Epics (mv167) side of example described previously.
iocrstserver Server (mv162) side of example described previously.
iocmpfclient/iocmpfserver Tests for remote MPF communication
iocmpflocal Test for local MPF communication
ioctcpclient/ioctcpserver Test for TCP communication.

Epics Record to IP - Flow of Control

Assume that some device is attached to a greensprings octal serial port Ip module. The device returns an ascii string whenever an ascii string command is given to it. Also assume that device support devSiExample is written which accepts INP fields with the format:
INP("C1 S0 @serialServer,<command>")
where When the record is processed the following sequence of events occur:

Message Passing Overview

The new message passing system follows a client server model. A client creates a connection to a server. Once a connection is established either the client or server can send messages to the other.

Messages are sent through a router. Two routers are provided: localRouter and RMR (Remote Message Router). The localRouter passes messages between a client and server residing on the same processor. RMR sends messages between a client and server on different processors via a tcp connection.

Message Client

typedef void (*clientCallback)(Message *message,void *clientPvt);
class MessageClient
    MessageClient(clientCallback,void *clientPvt);
    int bind(char *server, int location);
    int send(Message *message);
    void *getClientPvt();
A client of the message passing system must:
  1. Create an instance of MessageClient for each server with which it wants to communicate.
  2. Issue a bind call to establish communication.
  3. Call send to send messages.
  4. Provide a callback which is called whenever a connection is made or broken and is also called whenever the server sends a message to the client.
NOTE: DevMpf, described below, is a message client. Thus, for epics, new MPF device support is written rather than new message clients. MPF device support is implemented by creating a new class derived from base class DevMpf.

Message Server

class MessageServer
    MessageServer(const char* name);
    void waitForMessage();
    Message *receive();
    Message *allocReplyMessage(Message *clientMessage,messageType type);
    int reply(Message *);
    void setQueueSize(int size);
    const char *getName() const;
    void report() const;
A message server must
  1. Create an instance of MessageServer.
  2. Call waitForMessage if it wants to block until it receives messages.
  3. Call receive to accept messages.
  4. Call reply to send messages to a client.
  5. Call allocReplyMessage if it wants to send additional additional messages to a client


MPF is written so that an extensible set of message types can be provided. The following message types have been implemented: NOTE: The Int32Array, Float64, Float64Array, and OutOfBand messages have not been tested.

Message instances are kept on a free list. Thus malloc is called only if the free list is empty. Free is never called. Each message type has it's own free list.


Look at mpf/mpfServer/testSrc/ for an example client and mpf/mpfServer/testSrc/ for an example server. Also see EXAMPLE Implementation: ip330Scan.

Diagnostic Aids

The diagnostics described in the section are commands issued via the vxWorks shell.


Message Router Report provides a list of all client and server routers, connection state, queue sizes and state, and some statistics.

For servers it provides a report like the following:

iocrstserver> mrr
 1 RMRServer stateConnected queueSize 100 inQueue 0 replyQueueFull 0
   sendPerSec 240 receivePerSec 240  tcpSendPerSec 10 tcpReceivePerSec 10
It provides a report for each server router. It shows the connection state. The meaning of the other fields are: The statistics are calculated periodically and are truncated thus a value <1 is reported as 0.

For clients it produces the following type of report

iocrstclient> mrr
 1 RMRClient stateConnected queueSize 100 inQueue 0 sendQueueFull 0
   Server Int32 has 4 clients. bindState connected
   Server Char8Array has 4 clients. bindState connected
   Server serial[0] has 2 clients. bindState connected
   Server serial[1] has 2 clients. bindState connected
   Server serial[2] has 2 clients. bindState connected
   Server serial[3] has 2 clients. bindState connected
   Server serial[4] has 2 clients. bindState connected
   Server serial[5] has 2 clients. bindState connected
   Server serial[6] has 2 clients. bindState connected
   Server serial[7] has 2 clients. bindState connected
   sendPerSec 240 receivePerSec 240  tcpSendPerSec 10 tcpReceivePerSec 10
It produces a report for each client router. It shows if the router is connected. The queueSize, inQueue, and sendQueueFull provide statistics about the send queue. It also shows a list of each server attached to the router.

msr ("serverName")

Message Server Report provides statistics about the specified server or, if no argument is specified, all servers. For example:
iocrstserver> msr "serial[7]"
          queueSize 2
            inQueue 0
      queueRequests 132171
 queueFullResponses 1
      replyRequests 132171
The meaning of the fields are:


This command show every character transmitted and received by the specified port for the number of seconds specified. For example
serialPortSniff "UART[5]",1
value = 0 = 0x0
T31 T34 R31 T35 R34 T00 R35 R00 T31 T34 14154.5.14
R31 T36 R34 T00 R36 R00 T34 T31 R34 T32 164.6.4142
R31 T00 R32 R00 T31 T34 R31 T37 R34 T00 1.2.14174.
R37 R00 T31 T34 R31 T38 R34 T00 R38 R00 7.14184.8.
T31 T34 R31 T39 R34 T00 R39 R00 T31 T35 14194.9.15
R31 T30 R35 T00 R30 R00 T31 T35 R31 T31 105.0.1511
R35 T00 R31 R00 T34 T31 R34 T33 R31 T00 5.1.41431.
R33 R00 T31 T35 R31 T32 R35 T00 R32 R00 3.15125.2.
T31 T35 R31 T33 R35 T00 R33 R00 T31 T35 15135.3.15
R31 T34 R35 T00 R34 R00 145.4.
serialPortSniff done
The output displays 10 characters per line. It first shows the hex value preceeded by T (transmit) or R (receive). It then shows the ascii values. Non-printable ascii values are shown as ".".


This command show every character transmitted and received by the specified module for the number of seconds specified. For example:
value = 0 = 0x0
R-8.874270409E-01 0x0d 0x0a
R-9.341735006E-01 0x0d 0x0a
R-9.575970835E-01 0x0d 0x0a
R-1.004537279E+00 0x0d 0x0a
R-1.027972941E+00 0x0d 0x0a
R-1.051432207E+00 0x0d 0x0a
gpibSniff done

Message Routers

Local Message Router

The local message router passes message between a client and server residing in the same processor. When the client passes a message to a server the message is just appended to the server's queue. When the server sends a reply to the client, the client processes the message immediately. Thus when a client sends to the server the client never waits for the server. The server, however, will wait for the client to process a reply message.

Remote Message Router

The remote message router consists of two parts: the client router and the server router. Message are sent as architecture independent data(NOT TESTED). The sender deletes its message and the receiver has to allocate a new message, put the received data into the message and then pass it to the destination.

Router Configuration

Each processor that is a member of a set of MPF clients/servers is assigned a unique location, which is just an integer value. For example if the set is an mv167/mv162 the mv167 could be assigned location 0 and the mv162 location 1. All that matters is that each cpu is assigned a unique location and all cpus agree on the assignments.

Each vxWorks system using the message passing system needs the following command in the startup file:

If local communication is desired then the following command must appear: The parameter is the location of the local server. Note that the client specifies a location when it binds to a server.  Each cpu can start a local router.

If tcp communication is desired then for each remote system the client must have the following command:

Each system supporting remote servers must have the following command for each client machine: NOTE CAREFULLY: Each server router can only handle a single client router. A particular client/server pair is established by the client and server having EXACTLY the same (location,port,addresss) tuple. Also each server/client pair must use a unique port number.



A message is something that is sent from a client to a server or from a server to a client. MPF only knows how to handle messages defined by the files messageType.h and In addition there are firm rules about how messages are allocated and freed. The basic rules are: The definition of class Message is:
class Message
    messageType  getType();
    int32 getClientType();
    void setClientType(int32 type);
    int32 getClientExtra();
    void setClientExtra(int32 extra);
    virtual ~Message();
    virtual int  toBuffer(char **buffer);
    virtual int  fromBuffer(const char **buffer);
    virtual int  fromBufferSwitch(const char **buffer);
    virtual void print() const;
    static Message *allocate(messageType type);
    Message(messageType type);
Client and server code normally only call new, delete, the methods described in the following table, and message specific methods. The other methods are called by MPF itself. A message is allocated via a call to new and released via a call to delete. When delete is called the message is placed on a free list. Only one of the message types derived from Message can be created, i.e. it is not possible to create an object of type Message.

The virtual methods must be implement by any class that derives from Message. The toBuffer and fromBuffer methods are called to put and take messages from a buffer that passes over a communication link.
method Recommended Meaning
getType Returns the message type
These methods are for use by a client to access field clientType. When the server allocates a reply message via a call to allocateReplyMessage, the clientType from the clients message is copied to the reply message. In general a server should not use these methods. They are intended for clients that send multiple messages to a server and need to match reply messages with messages sent. Classes derived from DevMpf MUST NOT use these because DevMpf itself uses them. Use clientExtra instead.
These access a field clientExtra which is similar to clientType. They can be used by classes derived from DevMpf.

Architecture Independent Message Passing

MPF supports message passing between different architectures, i.e. different byte orders and/or different padding requirements. It does, however only work on architectures with 32 bit addressing. It provides support for the following data types: In order to support architecture independent message passing MPF provides some help but also requires that each message type provide methods to transfer data between a message instance and the network buffer.

MPF provides a header file "mpfType.h" which defines typedefs for int16, uint16, int32, uint32, float32, and float64. MPF provides static methods to transfer the following to/from network buffers:

Adding New Message Types

In order to provide a new message type the following must be done: mpfApp/messageSrc contains files xxxMessage.h and which are a skeleton header and source file for a new message type.  In addition look at other existing message types for examples.


A connect message is passed by MPF itself whenever a connection is made or broken or if a servers message queue is full. It contains the field status which can have one of the following values:


This class is not an actual message type but is a class used by other types. These fields provide additional services. The meaning of these fields is entirely up to the client/server combination between which the message is passed. The fields are:
Field Recommended Meaning
timeout The timeout the server can use it it has to wait for a device. It should be in seconds.
cmd A command. Servers can supply a header file defining an enum for the commands.
status A status value.
address For anything that is an int32 and can be interpreted as an address.
extra An extra int32 word that client/server can use for anything they want as long as they agree on the meaning.

Free Lists for Array Messages

All array messages use the utility class DataFreeList for managing storage for the actual arrays. DataFreeList keeps free lists of various sizes from 16 to 4096 bytes. If an array is larger than 4096 bytes the storage is allocated via a call to calloc and freed via a call to free. Thus Char8Arrays can contain 4096 characters, Int32Arrays 1024 elements, and Float64Arrays 512 elements before calloc/free is invoked.


This message type provides the standard fields in addition to the following additional fields
Field Recommended Meaning
value The address of a char8 array. The characters are not interpreted or translated by the message class, i.e. they are just a stream of octet values. The standard C library routines such as ::strcpy and ::memcpy can be used on the value field. 
numberRetrys A useful field for servers. It should be the number of retrys if a command fails.
eomLen A useful field for servers.  It should be the length of an end of message string.
eomString A useful field for servers.   It should be a 1 or 2 character end of message string.

Char8ArrayMessage provides the following methods for allocating and freeing the string value.
method usage
allocValue This is a static method which looks for the smallest freelist that can provide the needed space. If the requested size is larger than the size for the largest freelist, it calls new to allocate space.
setSize Sets the current size for the array. This size MUST be less than that allocated by allocValue.
getSize Gets the current array size.
getMaxSize This gets the size allocated by the call to allocValue
freeValue This puts storage obtained by allocValue back on the appropriate free list or calls delete if the storage was obtained via a call to new. This method is called automatically when a Char8Array message is deleted.


This message type provides the standard fields in addition to the following:
Field Recommended Meaning
value The Int32 value being passed.


This message type provides the standard fields in addition to an int32 array. The value field is just a pointer to an int32 array. An Int32ArrayMessage provides the following methods for allocating and freeing the array.
method usage
allocValue This is a static method which looks for the smallest freelist that can provide the needed space. If the requested size is larger than the size for the largest freelist, it calls new to allocate space.
setLength Sets the current length for the array. This length MUST be less than that allocated by allocValue.
getLength Gets the current array length.
getMaxLength This gets the length allocated by the call to allocValue
freeValue This puts storage obtained by allocValue back on the appropriate free list or calls delete if the storage was obtained via a call to new. This method is called automatically when an Int32Array message is deleted.


This message type provides the standard fields in addition to the following:
Field Recommended Meaning
value The Float64 value being passed


This message type provides the standard fields in addition to an float64 array. The value field is just a pointer to an float64 array. A Float64ArrayMessage provides the following methods for allocating and freeing the array.
method usage
allocValue This is a static method which looks for the smallest freelist that can provide the needed space. If the requested size is larger than the size for the largest freelist, it calls new to allocate space.
setLength Sets the current length for the array. This length MUST be less than that allocated by allocValue.
getLength Gets the current array length.
getMaxLength This gets the length allocated by the call to allocValue
freeValue This puts storage obtained by allocValue back on the appropriate free list or calls delete if the storage was obtained via a call to new. This method is called automatically when an Float64Array message is deleted.


field usage
baud Baud rate. 0 means don't change
stopBits Stop bits. Normally 1 or 2. 0 means don't change.
bitsPerChar Bits per character. Normally 5,6,7, or 8. 0 means don't change.
parity Single character. Normally 'E', 'O', or 'N'. 0 means don't change.
flowControl Single character. Normally 'H' or 'N'. 0 means don't change.


This is exactly like an Int32Message except for the type. It is used by a server to send messages to a client that are not responses to a request message.

MPF Device support

DevMpf is an abstract base class for implementing EPICS device support. See EXAMPLE Implementation: ip330Scan below for an example of how to use this base class. File DevMpf.h defines the class. The important part is:
// return codes for startIO and completeIO.

#define MPF_OK                  0
#define MPF_NoConvert           2

enum replyType {replyTypeNone, replyTypeCompleteIO, replyTypeReceiveReply};
class DevMpf
    DevMpf(dbCommon*,link*,bool iointValid);

    // Following must be implemented by device support modules
    virtual long startIO(dbCommon*)=0;  // start async IO
    virtual long completeIO(dbCommon*,Message *)=0; // end async IO
    // the following can be implemented by device support modules
    virtual void receiveReply(dbCommon*,Message *);
    virtual void connectIO(dbCommon*,Message *);     // connection message
    virtual void outOfBandIO(dbCommon*,OutOfBandMessage *);// outOfBand
    virtual long convert(dbCommon*,int pass);   // do linear conversion
    // send a message to MPF server with no reply expected
    int send(Message*);
    // send a message to MPF server and wait for reply via completeIO
    int sendReply(Message*);
    // send a message stating the type of reply
    int send(Message*,replyType);
    // This routine gets a pointer to the user portion of the parm field
    const char* getUserParm() const { return((const char*)userParm); }
    long getStatus() const { return(status);}
    // Following are DSET routines
    static long read_write(void*);      // generic DSET read/write routine
    static long ioint(int cmd,dbCommon*,IOSCANPVT* iopvt); // DSET i/o intr
    static long linconv(void*,int); // calls convert
    IOSCANPVT ioscanpvt;
    bool iointValid;
Before describing the methods a few comments may be helpful.

If the support is for a simple device, i.e. a device that can be supported via the following:

then device support only needs to implement startIO and completeIO. It calls sendReply to send messages. For such simple devices, the base class DevMpf takes care of everything else, e.g. connection and interfacing to record support.

For devices that are not simple, e.g. devices that must take special action when connecting to the server, additional methods are available: In particular:

connectIO is also useful for devices that generate unsolicited output . When it connects to a server, device support can send a message to the server stating that it wants to receive the unsolicited output. The server then sends a message to the client every time it receives a complete set of output from the device.

ioscanpvt is for provided for convenience.  If a derived class wishes to support io interrupt processing it can request that the base class perform the necessary initialization. The derived class must, however, call scanIoRequest.
method Usage meaning
DevMpf Constructor The constructor must be given the address of the record and link (INP or OUT). iointValid specifies if the base class should initialize  ioscanpvt
startIO Called by DevMpf When a request is made to process a record this is called only when the following conditions are all true: The server is connected, PACT is false, and no reply message from the server is available. This MUST be implemented by any class derived from DevMpf.

This method is always called as a result of a record being processed and the record is not active. If startIO issues a send(message,replyTypeCompleteIO) then PACT is set TRUE, i.e. the record will not complete processing until the reply message is received and completeIO is called.

completeIO Called by DevMpf DevMpf calls this when the reply to a send(message,replyTypeCompleteIO) is received. This MUST be implemented by any class that derives from DevMpf.

This method  is always called as a result of a record being processed 

receiveReply Called by DevMpf DevMpf calls this when the reply to a send(message,replyTypeReceiveReply) is received. This call does not involve record processing.

The default method just prints a message and deletes the message it received.

connectIO Called by DevMpf
Default supplied by DevMpf.
DevMpf calls this when it receives a ConnectMessage. DevMpf provides a default implementation. 

If device support implements this method it should call DevMpf::connectIO (just before returning) to ensure correct behavior. 

outOfBandIO Called by DevMpf
Default supplied by DevMpf.
DevMpf calls this when it receives an OutOfBand message. For example if server receives a send (no reply) message that can not be processed, the server can send an OutOfBand message to the client. 

The default method just prints a message and deletes the message it received.

convert Called by DevMpf, Default supplied by DevMpf This is the DSET convert routine for ai, ao type records. The default version does nothing. Device support derived from base can provide it's own version.
send(Message*) Equivalent to send(message,replyTypeNone) 
sendReply Equivalent to send(message,replyTypeCompleteIO) 
send(Message*,replyType) Called by derived class Send a message to the server.  SetClientType is called to specify the replyType. If the message is successfully sent and replyType is replyTypeCompleteIO pact is set true.

NOTE: Only one send(message,replyTypeCompleteIO) should be outstanding, i.e. after calling send(message,replyTypeCompleteIO) wait for completeIO to be called before issuing another send.

getUserParm Called by derived class Get the portion of the parm of the INP or OUT link that follows the server name.
getStatus Called by derived class Get the status. A 0 value is success. Any other value is device dependent.
read_write Called by record support This is the read or write DSET routine. Handled automatically by DevMpf
ioint Called by record support This is DSET get_io_intr routine. Handled automatically by DevMpf
linconv Called by record support This is DSET linr_conv routine. It calls convert.

The INP or OUT field MUST have the format:

field(INP or OUT, "#C<location> S<signal> @<server>,<deviceSpecific>")
Format of INP or OUT field
parameter meaning
location Location of the server. Must be integer which determines which message router handles messages.
signal For optional use by device support derived from DevMpf
server Name of the server which receives messages.
deviceSpecific For optional use by device support derived from DevMpf. Either a blank or comma can separate the server name from the device specific information.

Device Support Entry Tables

DevMpf.h provides macros for creating DSETs. They are:
MAKE_LINCONV_DSET(<dset name>,<dev init>)
MAKE_DSET(<dset name>,<dev init>)
The first is used for record types that support linear conversions, e.g. ai and ao, and the second for other record types.

Utility Classes

Several utility classes are used by the MPF classes: At least the DLList class should be replaced by using the Standard Template Library, which is part of the C++ .standard library. For now the standard C++ library is not being used by MPF. Instead only the ANSI standard C library is used.  These classes are used extensively by MPF and can also be used by user code.

FreeList provides the same functionality as the freeList facility provided with epics base, in fact it is just freeList redone in C++.

DLList is a double linked list class that does not require nodes to be embedded in objects placed in a list. This is different than the ellList facility provided by epics base.

WatchDog is a class that provides functionality similar to the vxWorks wdLib. The major exception is that the user supplied callback is called by a WatchDog supplied task rather than being called at interrupt level.

DataFreeList is a class for data free lists. It provides free lists of sizes ranging from 16 bytes to 4096 bytes. It is used by the array message types.

Reboot can be used to turn off interrupts when a soft reboot is being performed.

These classes are not described in this document. If you want to use them in new code look at examples in existing code.

IndustryPack Support

The Industry Pack software has been modified to utilize the ipac interface since it was first written, thus the methods provided may not implement the most efficient of interfaces but they are backwards-compatible with the older software.

IndustryPack Support consists of the following components:


The base class for an IndustryPack carrier. It allows access to IndustryPack carrier configuration and control independent of the specific carrier hardware board.
The base class for a specific site on a specific carrier, i.e. the place where an IP module resides.
Implements the IndustryPackCarrier and IndustryPackSite classes which actually pass requests on to the ipac software to implement.
Provides IndustryPack Module configuration independent of the specific IP carrier. This class is used by specific module support such as OctalUART and GpibGsTi9914.


This is a base class for board level support for IndustryPack carriers. The carrier must be initialized by using a board specific initialization routine prior to use by IndustryPackModule.
class IndustryPackCarrier
  int registerName(const char *carrierName);
  static IndustryPackCarrier *find(const char *carrierName);
  IndustryPackSite *findSite(const char *siteName);
  IndustryPackSite *addSite(IndustryPackSite *pSite);
  const char *getCarrierName();
  virtual volatile void *allocMemMapIP(int size) = 0;
class IndustryPackSite
  const char *getSiteName();
  virtual volatile void* allocMemMapIP(int size) = 0;
  virtual volatile IP_ID_PROM* getMemBaseID() = 0;
  virtual volatile void* getMemBaseIO() = 0;
  virtual volatile void* getMemBaseIP() = 0;
  virtual int intConfig(int num) = 0;
  virtual void intEnable(int num) = 0;
  virtual void intDisable(int num) = 0;
  const char *siteName;
  IndustryPackCarrier *pIpCarrier;
Method Implementor Usage Description
registerName IndustryPackCarrier Derived class. Register the carrier name.
find IndustryPackCarrier Public use. Find and return IndustryPackCarrier.
findSite IndustryPackCarrier IndustryPackModule Find and return site.
addSite IndustryPackCarrier Called by derived class. Add a site.
getCarrierName IndustryPackCarrier Public use. Return carrier name.
allocMemMapIP Derived Class IndustryPackModule Allocate memory.
getSiteName IndustryPackSite Derived class. Get site name
allocMemMapIP Derived class. IndustryPackModule See IndustryPackModule
getMemBaseID Derived class. IndustryPackModule See IndustryPackModule
getMemBaseIO Derived class. IndustryPackModule See IndustryPackModule
getMemBaseIP Derived class. IndustryPackModule See IndustryPackModule
intConfig Derived class. IndustryPackModule See IndustryPackModule
intEnable Derived class. IndustryPackModule See IndustryPackModule
intDisable Derived class. IndustryPackModule See IndustryPackModule


Mpf uses the  drvIpac  support from Andrew Johnson. The following example shows how to configure support for the mv162 . The same commands can be used for the MVME172 CPU, but the settings for sites C and D should be omitted as these do not exist on this board. Note that the following command must be on a single line in the startup file.
ipacAddCarrier(&ipmv162,"A:l=3,3 m=0xe0000000,64;B:l=3,3 m=0xe0010000,64;
C:l=3,3 m=0xe0020000,64;D:l=3,3 m=0xe0030000,64")
initIpacCarrier("carrierName", 0)


This is the class which IP module specific code uses, e.g. the Green Springs OctalUart support.
class IndustryPackModule
  static IndustryPackModule * createIndustryPackModule(
      const char *moduleName,
      const char *carrierName,
      const char *siteName);
  static IndustryPackModule *find(const char *moduleName);
  static IndustryPackModule *find(
      const char *carrierName,
      const char *siteName);
  volatile void *allocMemMapIP(int size);
  int intConfig(int num);
  int intEnable(int num);
  int intDisable(int num);
  volatile IP_ID_PROM *getMemBaseID();
  volatile void *getMemBaseIO();
  volatile void *getMemBaseIP();
  int getMemSizeIP();
  unsigned char getManufacturer();
  unsigned char getModel();
  unsigned char getRevision();
All public methods are implemented by IndustryPackModule and used by module specific code.
Method Description
createIndustryPackModule Creates an instance of IndustryPackModule. It prints an error message and returns 0 if carrierName or siteName does not exist or if moduleName already exists.
find Two find methods are provided. One finds modules by module name. The other finds modules by carrier and site name.
allocMemMapIP Allocate IP memory.
intConfig Interrupt Configure. The argument must be 0 or 1.
intEnable Enable interrupt. The argument must be 0 or 1.
intDisable Disable interrupt. The argument must be 0 or 1.
getMemBaseID Get the address of the module ID space.
getMemBaseIO Get the address of the module IO space.
getMemBaseIP Get the address of the module IP space.
getMemSizeIP Get the size of allocated IP memory.
getManufacturer Get the manufacter ID.
getModel Get the model ID.
getRevision Get the revision

Serial Support

Serial Support consists of the following components:


An abstract base class for a serial port. It allows access to a serial port independent of the specific serial interface.
Implements SerialPort for the Green Springs Quad/Octal IP carrier.
A generic MPF server for SerialPort. It accepts Char8Array messages.
Provides EPICS device support to send  string to a MPF server and receive a reply string.
SerialPort and OctalSerial can be used independent of MPF. SerialServer is the "glue" between MPF and SerialPort. DevStringMpf provides EPICS device support to send and receive string messages. It can be used with MPF servers other than serialServer. For example the MPF provides serverChar8Array, which just echoes whatever messages it is sent.

Because devices attached to serial ports have private protocols, serialServer and devStringMpf may not be usable. In such cases new device support and/or a new server  must be supplied. Usually only new device support is necessary, because serialServer is sufficiently generic.  For special devices a new server may also be needed. SerialServer and devStringMpf provide a model of how to write special support. This section provides details about SerialPort so the the code for serialServer is easier to follow.

SerialPort is independent of MPF and Industry Pack. It can be used as the base class for any type of serial port, i.e. VME, IP, etc. The code for OctalSerial provides a model of what needs to be done to derive from SerialPort.


enum byteHandlerRC {byteHandlerOK,byteHandlerEndRead,byteHandlerError};
enum serialPortStatus
    {serialPortSuccess, serialPortTimeout, serialPortFailure};
typedef byteHandlerRC (*BYTE_HANDLER)(void* parm,unsigned char byte);
typedef void (*PEEK_HANDLER)
    (void* parm,bool isReceive, unsigned char byte);
// If registered PEEK_HANDLER is called for every byte transmitted or received
class SerialPort

    int registerName(const char *portName);
    static SerialPort *find(const char *portName);
    static SerialPort *bind(const char *portName,void* bhparm,BYTE_HANDLER bh);
    void release();
    static bool setSniffHandler(
        const char *portName,void* phParm,PEEK_HANDLER ph);
    static void freeSniffHandler(const char *portName);
    serialPortStatus getStatus() { return(ioStatus);}
    virtual serialPortStatus write(
        unsigned char *data, int nbytes, int timeoutSeconds) = 0;
    virtual serialPortStatus read(int timeoutSeconds) =0;
    virtual serialPortStatus writeRead(
        unsigned char *data, int nbytes, int timeoutSeconds) =0;
    virtual bool config( int baud, int stopBits, int bitsPerChar,
        char parity, char flowControl) = 0;
    void clientStartIoTimeout(int seconds);
    void startIoTimeout(int seconds);
    void waitIo();
    requestType request;
    serialPortStatus ioStatus;
    void* bhParm;
    void* phParm;
    SEM_ID ioComplete;
Method Implementor Usage Description
find SerialPort Called by servers Given the name of a port, find and return SerialPort.
bind SerialPort Called by servers Bind the caller to the specified port and if successful return the address of the SerialPort. Only one caller can be bound to a particular port. After a successful bind the caller may call write, read, writeRead, and release.
setSniffHandler SerialPort Called by serialPortSniff or other diagnostics SerialPort locates the serial port and sets the field ph. The Derived Class is expected to call the peek handler for every character trasmitted and received if ph has a value.
freeSniffHandler SerialPort Called by serialPortSniff or other diagnostics SerialPort locates the serial port and clears the field ph.
release SerialPort Called by servers Release the caller that is bound to the port.
getStatus SerialPort Called by servers Return the status of the last I/O request.
write Derived Class Called by servers. Send data to the serial port.
read Derived Class Called by servers Read data from the serial port.
writeRead Derived Class Called by servers Send data to the serial port while simultaneously reading.
registerName SerialPort Called by derived class Register the serial port.
clientStartIoTimeout SerialPort Called by servers Starts a timeout BEFORE a call to read, write, or writeRead.
startIoTimeout SerialPort Called by derived class Start a time out request. If server calls clientStartIoTimeout before calling write, read, or writeRead then startIoTimout does nothing. NOTE that this does a semTake with NO_WAIT before starting a watchdog. If a server doesnt desire this action it must call clientStartIoTimeout.
waitIo SerialPort Called by derived class Wait for I/O to complete or timeout.

The bind call must supply a byte handler which is called for every input character received by the serial port. The byte handler returns one of the following values.
Byte Handler Return Codes
byteHandlerOK If any read request is outstanding, just continue.
byteHandlerEndRead If any read request is outstanding terminate it with success.
byteHandlerError If any read request is outstanding terminate it with failure.

OctalUART Support

This is support for the GreenSprings Octal and Quad serial IP modules. Before initializing the OctalUART the IndustryPack Carrier must be initialized. The following command initializes an OctalUart module.
parameter value
moduleName The IP Module name to be registered.
carrierName The name of the IP Carrier.
carrierSite The mezzanine slot location on a carrier. Eg: IP_a, IP_b, IP_c, IP_d
nports The number of ports. Must be 4 or 8.
intVec First interrupt vector to be used.

After the OctalUart is initialized each port can be initialized via the command.

parameter value
portName portName which is registered for port.
moduleName The IP module name for identification.
port port number. Must be between 0 and 7.
baud 1200, 2400, 4800, 9600, 19200, 38400
parity O, E, N for (Odd, Even, None)
stop_bits 1,2
bits_char 5,6,7,8
flowType H, N means (? , ?)


This is a MPF server for SerialPort. It accepts SerialConfigMessage sand Char8Array messages. Client code must include file "serialServer.h", which contains definitions for commands, options, and for return status.

When serialServer receives a SerialConfigMessage it calls SerialPort::config and returns an Int32Message. A status of 0 means success.

When serialServer receives a Char8Array message it returns  a Char8Array message. The return message contains any characters read and a status value which has one of the following values:
serialServerStatusOK Request operation OK
serialServerStatusTimeout Operation timeout.
serialServerStatusOverflow Input buffer overflow
serialServerStatusError Other error

The cmd field of the Char8Array message can contain a command and also options. The commands are:
cmdWrite Write value to the port. A Char8Array message is returned. Only the status field is of interest.
cmdRead Read from from the serial port. A Char8Array message is returned. The value contains the input. Status should always be checked. Input is read until the first of the following occurs: 1) the end of message string is read, 2) extra is non zero and extra bytes are read, 3) A read buffer overflow occurs, or 4) a timeout occurs.
cmdWriteRead The output string is sent to the serial port and a input string read. The port is enabled for input BEFORE any bytes are sent to the port.

The cmd field can also contain the following options:
cmdFlush Flush the input buffer before starting I/O. This is useful when circularBuffer mode is enabled.
cmdStartCircularBuffer Start circular buffer mode. When circular buffer mode is enabled, input is accepted even when no read request is present.
cmdStopCircularBuffrer Stop circularBuffer mode, i.e. ignore any input characters unless an input request is active.
cmdSetEom Set end of message string. If the option is set then the fields eomLen and eomString determine the new end of message string.

The following additional fields of the Char8ArrayMessage are also honored by the serialServer:
timeout The timeout value in seconds. This field must be set.
numberRetrys Number of times to retry the request if the initial request fails.
extra If extra <= 0 then it is ignored. If extra is > 0 then it is the maximum number of bytes to read before ending the read. Disabling the end of message string and specifying extra allows serialServer to read binary data.
eomLen If cmdSetEom is set, this field determines the length of the end of message string. It can have the value 0, 1, or 2.
A zero value disables the end of message string. If the value is 1 or 2 the string is determined by eomString
eomString If cmdSetEom is set and eomLen is 1 or 2, this is the end of message string.

The following command initializes a serial server:

serverName The MPF name for this server.
portName The name of the serial port to which the server is attached.
bufSize The size for the input buffer.  Note that this can not be changed after initialization
queuesize The maximum number of messages that can be on the servers queue.
eomstr The initial input terminator. It must be one or two characters.
circularBufferMode The initial state for circularBuffer. If (0,1) then circularBufferMode is (disabled, enabled)

Discussion of Circular Buffer Mode

Circular Buffer mode is provided for devices that respond with multiple lines of output in response to a single command request. Although it is possible to run with circular buffer mode always enabled this is not recommended because, if any errors occur, it is possible for writes and reads to get "out of sync". A better way to handle multiline requests is the following:

Circular buffer mode can also be used to send a command to a device with an output record and  read the response with an input record.  This method is discouraged because the output and input are not an atomic operation. If other records access the same port, it may be possible for one of the other records to send a message to the server between the output and input requests.


Three versions of device support are supplied with MPF, corresponding to the three commands that can be given to serialServer. The first to types are associated with a stringin record and the third with a stringout record. File devStringMpf.dbd provides the device definitions and devStringMpf.c provides the device support.

A record which uses MPFwriteRead has DTYP and INP defined as follows:

    field(INP, "#C<location> S0 @<server>,<inputRecord>")
pvname Record name
location Location of message server.
server Name of the message server
inputRecord Name of field from which a serial output string is obtained.

When the record is processed the following happens:

Please note the following restrictions: Unless these restrictions are acceptable specialized device support will have to be written.

A record which uses MPFread has DTYP and INP defined as follows:

    field(INP, "#C<location> S0 @<server>")
A record which uses MPFwrite has DTYP and OUT defined as follows:
    field(OUT, "#C<location> S0 @<server>")


What about a serialPortRecord?  Is it necessary? How does it relate to Mark River's generic serial record?

Also what do we do about null terminators for strings? serialServer does not add or remove null terminator nor should it. What about device or record support?  If we have serialPortRecord we could have additional options to handle this. What about flow control? How do we handle this in a generic way? What else am I missing?

Gpib Support

Gpib support consists of the following: The Gpib support is complete in the sense that most users will not have to extend it. It is compatible with the Gpib support provided with epics base.

Restriction: Only one of GpibHideosLocal or GpibHideosRemote can be used on a particular processor. Removing this restriction requires changes to the version of drvGpib supplied with base.

Systran DAC128V Support

This is support for the Systran DAC128V, an 8 channel, 12-bit D/A converter. The MPF distribution contains a file:
which contains instructions on how to configure the server, device support, and records.


This is support for the Acromag IP330 analog input Industrial I/O Pack module. The support configures the 330 as a scanning ADC.  32 single-ended or 16 differential channels are scanned. A complete set of readings is taken every millisecond. Every 200 samples the average of each channel is computed. The average value is returned to device support. Thus every .2 seconds a 200 sample average is available. Once a minute calibration is done automatically.

Device support sends Int32Messages with the following info:

address - channel
value - gain
The server returns
value - 32 bit unsigned integer from 0 to 0xffff
status - 0 means success. -1 means failure
The following command initializes the server:
modulename The IP Module name to be registered. This is also the server name
carrier The name of the IP Carrier
site The slot location on the carrier.
type The type: Must be (D,S) for (Differential, Single Ended)
range Range: Must be one of -5to5, -10to10, 0to5, 0to10
intVec The interrupt vector location
queueSize Maximum number of messages to queue

The device definition is:

Analog input records have the fields defined as follows:
field(SCAN,"1 second")
field(INP,"#C{card} S{signal} @{servername},{gain}
card The location of the server.
signal The input channel. For Differential 0-15. For single ended 0 - 31.
servername Must match the modulename specified with initIp330Scan.
gain Optional. If given must be 0,1,2,or 3. Default is 0.

The following summerizes the configuration options. The DIP Switch Settings column correspond to the value switches 1 - 10. A value of 101100001 corresponds to switches 1,3,4,9 on and 2,5,6,7,8 off.
Range DIP Switch Gain Full Value Low Value
-5to5 1011000010 0 5 -5
-5to5 1011000010 1 2.5 -2.5
-5to5 1011000010 2 1.25 -1.25
-5to5 1011000010 3 0.625 -.0625
-10to10 0100110010 0 10 -10
-10to10 0100110010 1 5 -5
-10to10 0100110010 2 2.5 -2.5
-10to10 0100110010 3 1.25 -1.25
0to5 1010100100 0 5 0
0to5 1010100100 1 2.5 0
0to5 1010100100 2 1.25 0
0to5 1010100100 3 0.625 0
0to10 1011001000 0 10 0
0to10 1011001000 1 5 0
0to10 1011001000 2 2.5 0
0to10 1011001000 3 1.25 0

Note for Hideos Users

This support is similar to the hideos ip330adc support. The main differences for database records are:

EXAMPLE Implementation: ip330Scan

This section describes EPICS device support which communicates with a server that accesses an IP module.. The example is the scanning adc support for the Acromag IP330 AI module.  The complete code resides in mpf/ip330ScanApp/src. This section explains how things fit together. It does not show device specific details. The support consists of four source modules:,, Ip330Scan.h, and

class DevAiIp330Scan : public DevMpf
        long startIO(dbCommon* pr);
        long completeIO(dbCommon* pr,Message* m);
        long convert(dbCommon* pr,int pass);
        static long dev_init(void*);
        int channel;
        int gain;
Class  DevAiIp330Scan implements device support which communicates with the ip330Server described below. It derives from class DevMpf. DevMpf  calls the methods DevAiIp330Scan, startIO, completeIO, and convert.
The macro MAKE_LINCONV_DSET  creates Device Support Entry Table devAiIp330Scan. DevAiIp330Scan::dev_init will be called by aiRecord during the second phase of record initialization.
DevAiIp330Scan::DevAiIp330Scan(dbCommon* pr,DBLINK* l)
: DevMpf(pr,l,false)
    vmeio* io = (vmeio*)&(l->value);
    gain = 0;
    aiRecord* prec=(aiRecord*)pr;
    const char* up = getUserParm();
    if(up && strlen(up)>0) {
        // decode the parm field, format: "gain"
        if((sscanf(up,"%d",&gain)<1) || gain<0 || gain>3) {
            epicsPrintf("%s Illegal INP parm field\n", prec->name);
    convert((dbCommon *)prec,1);
Constructor DevAiIp330Scan is called by DevAiIp330Scan::dev_init. It first calls DevMpf(pr,l,false) and then does private initialization. DevMpf takes care of establishing communication with the server, and it also calls startIO and completeIO.
long DevAiIp330Scan::startIO(dbCommon* )
    Int32Message *message = new Int32Message;
    message->value =gain;
    message->address =channel;
startIO is called by DevMpf when dbProcess requests record processing. It just sends a message to the server and returns.
long DevAiIp330Scan::completeIO(dbCommon* pr,Message* m)
    aiRecord* pai = (aiRecord*)pr;
    if((m->getType()) != messageTypeInt32) {
        epicsPrintf("%s ::completeIO illegal message type %d\n",
        delete m;
    Int32Message *pint32Message = (Int32Message *)m;
    if(pint32Message->status) {
        delete m;
    delete m;
completeIO is called when the server returns a message. It checks that it has received a valid message, sets rval equal  to the new value received from the server, deletes the message, and returns.
long DevAiIp330Scan::convert(dbCommon* pr,int /*pass*/)
    aiRecord* pai = (aiRecord*)pr;
    return 0;
convert is called by the aiRecord when conversion fields are changed and also by the constructor DevAiIp330Scan. This implementation knows that ip330Scan  always returns a value between 0 and 0xffff.
long DevAiIp330Scan::dev_init(void* v)
        aiRecord* pr = (aiRecord*)v;
        DevAiIp330Scan* pDevAiIp330Scan
            = new DevAiIp330Scan((dbCommon*)pr,&(pr->inp));
        return pDevAiIp330Scan->getStatus();
dev_init  calls the constructor and returns a status obtained from DevMpf.

ip330ScanServer receives messages from DevAiIp330Scan, calls ip330Scan, and sends a reply message. The server is written as a separate module so that ip330Scan is independent of MPF.
class Ip330ScanServer {
    Ip330Scan *pIp330Scan;
    MessageServer *pMessageServer;
    static void ip330Server(Ip330ScanServer *);
This is a class definition that connects ip330Server to Ip330Scan.
static char taskname[] = "ip330";
extern "C" int initIp330Scan(
    const char *moduleName, const char *carrierName, const char *siteName,
    const char *typeString,const char *rangeString, int intVec,
    int queueSize)
    Ip330Scan *pIp330Scan = Ip330Scan::init(moduleName,carrierName,siteName,
    if(!pIp330Scan) return(0);
    Ip330ScanServer *pIp330ScanServer = new Ip330ScanServer;
    pIp330ScanServer->pIp330Scan = pIp330Scan;
    pIp330ScanServer->pMessageServer = new MessageServer(moduleName,queueSize);
    int taskId = taskSpawn(taskname,100,VX_FP_TASK,2000,
        printf("%s ip330Server taskSpawn Failure\n",
The initialization routine is called from the server st.cmd file. It does the following: The init routine is the "glue" between MPF and the IP support.
void Ip330ScanServer::ip330Server(Ip330ScanServer *pIp330ScanServer)
    while(true) {
        MessageServer *pMessageServer = pIp330ScanServer->pMessageServer;
        Ip330Scan *pIp330Scan = pIp330ScanServer->pIp330Scan;
        Message *inmsg;
        while((inmsg = pMessageServer->receive())) {
            if(inmsg->getType()!=messageTypeInt32) {
                printf("%s ip330Server got illegal message type %d\n",
                    pMessageServer->getName(), inmsg->getType());
                delete inmsg;
            } else {
                Int32Message *pmessage = (Int32Message *)inmsg;
                pmessage->status = 0;
                int gain = pmessage->value;
                int channel = pmessage->address;
                if(pIp330Scan->setGain( gain,channel)) pmessage->status= -1;
                if(pmessage->status==0) {
                    pmessage->value = (int32)pIp330Scan->getValue(channel);
ip330Server accepts MPF messages, calls Ip330Scan methods, and sends a reply message.


class WatchDog;
class MessageServer;
class IndustryPackModule;
class ip330ADCregs;
class ip330ADCchans;

enum signalType {differential, singleEnded};
class Ip330Scan
    static Ip330Scan * init(
        const char *moduleName, const char *carrierName,
        const char *siteName,
        const char *type,const char *range,int intVec);
    int getValue(int channel);
    int setGain(int gain,int channel);
    Ip330Scan(IndustryPackModule *pIndustryPackModule,
         signalType type, int range, int intVec);

This is a typical example of the class definition for an IP support module.  It has the following public methods: init, getValue, and setGain. getValue and setGain are specific to the IP330 support. The init routine is typical of what is needed for many IP support modules. Note that the class constructor is private because a new instance should only be created via a call to init.

NOTE: This is only part of the source module. All device specific code is suppressed.
Ip330Scan * Ip330Scan::init(
    const char *moduleName, const char *carrierName, const char *siteName,
    const char *typeString,const char *rangeString, int intVec)
    IndustryPackModule *pIPM = IndustryPackModule::createIndustryPackModule(
    if(!pIPM) return(0);
    unsigned char manufacturer = pIPM->getManufacturer();
    unsigned char model = pIPM->getModel();
    if(manufacturer!=ACROMAG_ID) {
        printf("initIp330Scan manufacturer 0x%x not ACROMAG_ID\n",
    if(model!=ACRO_IP330) {
       printf("initIp330Scan model 0x%x not a ACRO_IP330\n",model);
    .... // device specific details
    Ip330Scan *pIp330Scan = new Ip330Scan(pIPM,type,range,intVec);
This code creates and binds to a new IndustryPackModule. It then checks that the IP module is what it expects. Finally it creates a new Ip330Scan object.
Ip330Scan:: Ip330Scan(
    IndustryPackModule *pIndustryPackModule,
    signalType type, int range, int intVec)
: pIPM(pIndustryPackModule), type(type), range(range), accumulated(0)
    ... // device specific details
    pIPM->intConfig(0); pIPM->intConfig(1);
        printf("Ip330Scan intConnect Failure\n");
    ... // device specific details
This shows how to connect to an interrupt location.


The purpose of this section is to give some performance numbers that help understand some of the MPF design decisions and also to help users decide when  it might be worthwhile to have a non-EPICS MPF processor talking to an EPICS ioc.

The local tests were run on an mv162. The remote tests were run on an mv167 client  and mv162 server. I think they were both 25 MHz processors. msgPerSec and tcpPerSec are round trip, i.e. a send and receive. The message in all cases was just an Int32 value. The no buffer case means that a value was sent and the client waited for that response before sending the next message. The buffer case means that the specified number of values were sent before waiting for the responses.

Raw TCP  performance

Test msgPerSec tcpPerSec client idle server idle
tcpLocalNoBuffer 237 237 15% -
tcpLocalBuffer100 6050 60 5% -
tcpRemoteNoBuffer 485 485 54% 39%
tcpRemoteBuffer100 10050 100 52% 40%

MPF Performance

Test msgPerSec tcpPerSec client idle server idle
mpfLocalNoBuffer 3705 - 0% -
mpfLocalBuffer100 7966 - 0% -
mpfRemoteNoBuffer 331 331 52% 40%
mpfRemoteBuffer100 1440 14 52% 43%
mpfRemoteBuffer1000 2100 16 31% 18%

EPICS to remote server performance

The example described previously was started and all menu options set to .1 second scan rate.
Test msgPerSec tcpPerSec client idle server idle
local 240 - 51% -
remote 240 10 64% 73%


octalSerialPort performance

This test consisted of sending 100 character messages to each of the 8 serial ports. Each port was configured at 38400 baud. The results are for the server.
Test msgPerSec interrupt idle total
local 159 76% 0% 89%
remote 156 65% 10% 91%