Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Tue, 4 Sep 2007 17:38:18 -0600

Hello Gabriel,

There is of course nothing hindering you from calling your C API from inside
of a device support interface module.

In general, a particular EPICS device support interface communicates with a
single scalar (or vector) parameter in your device or instrument. So you can
write an independent device support interface for each of the configuration
parameters in your instrument, for each of the outputs in your instrument,
and for each of the inputs in your instrument. You will need to invent an
(probably INST_IO) addressing scheme that allows each of these to be
addressed uniquely. 

What is harder to do using EPICS device support is to atomically communicate
with a generalized messaging (multiple simultaneous input and output
parameter) communication end point. For example, a generalized C API with 3
input and 3 output parameters per function call presents some challenges.
There are several possibilities (all with some limitations).

1) Pass your message as a string, and parse the string to form the
parameters in the message (function call).
2) Pass your message as a homogenous array of "float", a homogenous array of
"int", etc.
3) Pass your message as an array of characters that form a binary encoding
of the data structure that you need to pass (don't take this as a
recommendation for this option).
4) Cache all of the current device settings in device support, and when a
single configuration parameter is being set from device support form a
complete set using the missing elements from cache. This one maybe weakly
addresses your specific issue of needing to pass input and output parameters
at the same time.

> Can I use the INP and OUT fields arbitrarily, parsing a 
> common syntax (i.e. a single string value such as "@function arg1 arg2") 
> in the device support layer, to make function wrappers

It's hard to make specific recommendations without examining your callable
API, but you might find that it is better to aim for a somewhat higher level
of abstraction in your device support interface so that mistakes made when
configuring the database will not cause an interface violation that would
for example cause an unexpected result, undefined result, or cause device
support to crash.

Jeff

-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Gabriel L. Rael
Sent: Tuesday, September 04, 2007 4:59 PM
To: [email protected]
Subject: EPICS device support questions

Hello, all.

We are in the process of creating an EPICS interface to our 
oscilloscope.  It is a PCI device with its own kernel driver and user 
space driver with the host processor that will be running our EPICS IOC.

It seems that though EPICS supports a list of communication interfaces 
(GPIB, VME, VXI, serial, etc.), it does not allow for a device to be 
connected above this layer through an ANSI-C API easily.  Though asyn 
device support is a complete solution down to the kernel level, we want 
to be able to leverage our existing drivers.

For packaging up this functionality, we want to create records that map 
directly to our API calls, which are functions with variable arguments, 
some that may be passed by reference for modification.  We have function 
tables containing our calls with variable argument types, but we are not 
seeing a common way to link PVs to function calls with arguments.  In 
the dbd, we are doing something like:  device(ao, INST_IO, devScopeao, 
"scopeAPI").  Can I use the INP and OUT fields arbitrarily, parsing a 
common syntax (i.e. a single string value such as "@function arg1 arg2") 
in the device support layer, to make function wrappers?  Is there a 
general way that we can hook into something that already accomplishes 
this?  Does this break the ability to link PVs properly?  Can I do this 
using the standard record types?  Am I missing something else?

Thanks in advance!

-glr

-- 
Gabriel L. Rael
Jr. Software Engineer
ZTEC Instruments
http://www.ztecinstruments.com

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System