Experimental Physics and
Industrial Control System

[email protected] (Jeff Hill) · Thu, 25 May 2000 12:11:42 -0600

Fritz,

One possibility: add special BI device support and
associated device addressing for a pseudo binary IO
in your device which returns the status from the last
IO request. You might have specialized information in
the parm field of INST_IO or some other addressing format which
binds with your device's status. For example, if the addressing 
is typically "CARD 0 SIGNAL 4" then the addressing for
the associated device status might be "CARD 0 SIGNAL 4 <STATUS>". 

The downside of course is that you would need an additional 
BI record for each signal, and I understand that you have more
than a few signals there.

We could avoid this overhead by adding a new pseudo field name to
all records which does not exist in the recod but is instead fetched 
through a new entry at the end of the record support entry table. 
This RSET entry might then call a new entry at the end of the device 
support entry table.

Another way to solve this problem (long term) would be to allow
certain records to be created on-the-fly from a template only 
when clients are looking at them. These pseudo BI's communicating
with your device's status would therefore only exist if a client 
was attached to them.

Alternatively, we could look at device support extensibility 
mechanisms for the "STAT" field.

Jeff

> -----Original Message-----
> From: J. Frederick Bartlett ([email protected])
> [mailto:[email protected]]
> Sent: Thursday, May 25, 2000 11:21 AM
> To: [email protected]
> Cc: [email protected]
> Subject: Status return from EPICS device support
> 
> 
>   I have a question for the experts. Is there a standard field in all
> records in which detailed device status (status from device support)
> may be placed where is is accessible by a database get operation.
> 
>   My particular difficulty appears with asynchronous device support
> for the MIL/STD1553B bus. We have a controller for the 1553 bus which
> generates an interrupt at the end of a bus transaction. The 1553 bus
> driver reschedules record "processing" (PACT is non-zero at this point) at
> interrupt time via a call to callbackRequestProcessCallback, passing a
> longword with bus I/O completion status. I need to save this status in
> a standard record field (one that all records have) so that, if there
> was an error, the application program may retrieve it. Any
> suggestions?
> 
> 						Fritz Bartlett
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System