Experimental Physics and
Industrial Control System

Marty Kraimer <[email protected]> · Thu, 17 Nov 2005 10:22:06 -0600

The release notes for R4-3 state:
lockPort/unlockPort
These are new asynManager methods. They can be used in place of
queueRequest if the caller can block. They have been added to make it
easier to implement a driver with one addressing scheme that is a
asynUser of a driver with a different addressing scheme. For example a
multi-drop serial driver can be implemented that calls a standard serial
driver.
One use is for what your are describing.
I have not done the following so the ideas may need some refinement.
There are two ports involved:
serialPort - standard serial support that comes with asyn, i.e. serial
or ethernet

specialPort - The support for your device, e.g. loCuM4.
A stringin recort will be connected to serialPort using
asynSiOctetCmdResponse or asynSiOctetWriteRead device support, i.e. it
uses standard asyn devEpics support.
ai, bi, mbbi, records will; be attached via standard asyn devEpics
support to specialPort.

The following will happen.
The stringin record can be processed periodically. Each time it is
processed the following happens:
a command is sent to the the serial port and the response read.

specialPort will be called because it has registered via
asynOctet:registerInterruptUser.

It breaks the response into individual data items and causes the
associated ai,bi,mbbi,etc records to process because they have been set
to be I/O Intr scanned.
So what does the specialPort have to do to make this happen?
It appears as a multi address driver to the records that attach to it.
It is an asynUser of the serialPort.
At initialization it connects to the serial port, locates the asynOctet
interface and calls asynOctet:registerInterruptUser.
It implements interfaces asynInt32 and asynUInt32Digital.
Please note also that you can use asynDrvUser to pass driver specific
info from the INP and OUT links to the driver.

Hope this helps you get started.
Marty

Jens Rekow wrote:
Hi All,
it is rather an architectural/style question that I ran into working on
the device support for a message based serial/ethernet device (yes, it is
the LoCuM4).
Imagine there is a command that retrieves various status values binary
encoded in a string (bytes, shifted to printable characters...). I would
like to serve several PV's out of that. (It wouldn't make sense to put so
much information in just one record, mbbi, whatsoever)!
As always there are different ways to deal with that:
Worst case that I can think of is to have AsynDriver device support for
each record, so EACH time ONE of them is processed there would be I/O
transaction at the interface for retrieving the whole status string and
the tiny bit (literally!) of interest will be extracted.
My way so far is another: There is one AsynDriver-powered record
(stringin) which retrieves and holds the status string. That value is read
by a longin record via dbGetField() in a standard device support, which
extracts the information and distributes to all the other relevant records
via dbPutField(). Thus these other records don't need any device/record
support implementation themselves but are set remotely. Unfortunately this
complicates handling the alarm/invalid states of these records.
So the question is:
Would it be better to have already my AsynDriver-powered record, which
reads the status bytes, distributing the values to the different records
via dbPutField()?
Alternatively I like the idea of only one device support implementation
for several records which is flexible using the INP field as a
parameter...

Any suggestions?
What could be more 'stylish'?
Thanks in advance,
Jens

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System