Experimental Physics and
Industrial Control System

"Rees, NP \(Nick\)" <[email protected]> · Thu, 17 Nov 2005 15:49:53 -0000

Jens,

What I have done in the past is to support I/O interrupt scanning for
these sort of variables. Then whenever a write is initiated on a
variable, any other variables which are read in the same operation but
which are set to be I/O interrupt scanned are automatically updated.

What the driver has to recognize is that a set of variables all have the
same command string, and parse out different bits of the response string
to each one.

Cheers,

Nick Rees
Principal Software Engineer           Phone: +44 (0)1235-778430
Diamond Light Source                  Fax:   +44 (0)1235-446713

> -----Original Message-----
> From: Jens Rekow [mailto:[email protected]] 
> Sent: 17 November 2005 15:38
> To: [email protected]
> Subject: record/device support general style question
> 
> 
> 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