Experimental Physics and
Industrial Control System

"Thompson, David H." <[email protected]> · Tue, 13 Apr 2004 14:49:28 -0400

I hadn't needed to implement a separate record type.  I haven't seen a
need for there to be both an INP field and an OUT field, device support
should be able to find the hardware using either one.  There may be
exceptions out there tho.

It looks as if SNS is not the only place that has run into this
problem....

It comes down to being able to avoid doing output on an output record
when it is really doing input. There are as many ways to that as there
are people who want to be able to do it, times 3.  If you can set the
val field and post a monitor without "processing" the record that would
work as well as having the device support being able to identify the
caller.   It is all a matter of how to package what is in fact a new
device support function (input) and trick the existing record support
into posting the monitors while the device support does nothing.

What makes sense to me is to have the device support's init function
register the record and input function with a "bidirectional" scan task
that handles the input mode by calling a device support input function
and then processing the record, all with the record locked.   Managing
the context so device support can know when to or not to do output is
all up to device support, nothing extra would have to pass through the
record's process routine in input mode.  In the shared memory
application's device support I added a field to the dset structure to
provide the "input" function pointer to the scan task. I think now that
passing input function pointer as an argument to the registration
function would be cleaner.  This is something that could be added to
core without breaking anything and would provide a standard way to
implement bi-directional IO. For whatever it's worth.

You could make the record "track" a device side set point using a
separate input field and a calcout record.  That would add a couple of
PVs per signal.

-----Original Message-----
From: Luedeke Andreas [mailto:[email protected]] 
Sent: Tuesday, April 13, 2004 9:32 AM
To: Williams Jr, Ernest L.
Cc: Ralph Lange; EPICS Tech-Talk; Andrew Johnson
Subject: Re: Bidirectional device support

Ernest L. Williams Jr. wrote:

> Can you achieve most of what you want by using a collection of
database
>
>[...]
>
>Ernest
>  
>
Of course one can implement most or even all of the bi-directional
functionality using the existing record types. That was the start of the
discussion. But if you want to make heavy use of this feature in your
databases then you'll get big and opaque databases.
The question is: do we need this feature that often that these new
records should be part of EPICS base?

For me the answer is in some of the given arguments: the more smart
devices we have the more important it is to have these records. Because
due to the local intelligence you don't want to have a difference
between
  - two or more clients modifying one channel or
  - clients or "hardware" sources modifying it.

It is difficult to explain to an operator why a corrector output channel
changes as long as an orbit feedback application is active and
doesn't change anymore when the orbit feedback DSP is taking over.
Todays physics applications are firmware!

But even if we decide to have it, the question remains how to do it.
For most databases I would need two independent links to my device
support.
Sometimes it would be helpful to have a field to show, if the VAL field
was
updated from the processing of the INP or the OUT link (by writing to
VAL).
A "latency" field would be nice, to supress the update of the VAL field 
by INP
for a certain time period after a write to the OUT link, to make sure
the
modification already took effect.
And it could be useful to disable modification from INP or from OUT 
permanently.
I'm always hesitant to add new record types, but I could actually make
use
of the record types: aio, bio, mbbio, longio, stringio and waveio.

But of course I want someone else to do all that work ;-)
Should we postpone the discussion or is there a "potential volunteer"?

Andreas

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System