Re: Some questions from a first-time driver author

[Zik Saleeba <ziksaleeba@southerninnovation.com>]

Thanks Dirk. That answers my questions perfectly. 

I did look at asyn but found it harder to find a nice example of a working driver using it so I based my driver on an existing non-asyn driver.

-- 
  Zik Saleeba, Senior Software Engineer
  ziksaleeba@southerninnovation.com

On Mon, 30 Jul 2018, at 9:45 PM, Dirk Zimoch wrote:
> 
> 
> On 30.07.2018 03:41, Zik Saleeba wrote:
> > I'm new to EPICS and I'm writing a new driver for an IP connected xray pulse detection device. I was wondering if more experienced people can help me with a couple of questions I have.
> 
> Welcome to the wonderful world of EPICS device driver programming.
> 
> > 
> > I've written a driver using PVs as the method for accessing the device state and it works but in some ways it seems unnecessarily awkward:
> > 
> > 1. I use separate longin and longout record types for getting and setting integer device variables. Is it possible to use just a single record for both input and output of the same variable? That seems like it would avoid unnecessary duplication and confusion between the two records.
> 
> Yes you can, but EPICS does not really support that. You typically have 
> a set value and a readback value. Things really become awkward when you 
> want to update your set records with changes someone did outside EPICS.
> 
> > 
> > 2. My C code registers dsets for each of the input and output types I use. These each provide an init method and either a read or write method depending on the direction. PV client writes result in immediate calls to my write callback from the dset which is what I expected but PV client reads only access the internal stored state of the record, they don't call my read method. Instead I have to get the value into the record using a SCAN field to regularly update the record. This seems to call the read method correctly. Is there a way to get the PV read to directly call my read method so I can provide the instantaneously correct value rather than just the most recently polled value?
> 
> That is how EPICS is designed. The idea is that the load on the hardware 
> does not depend on the number of clients. So you set a scan rate and 
> whether 0 or 1000 clients want to know the value, it is always the same 
> to the device. However sometimes that sucks. In that case the client can 
> write a 1 to the .PROC field using a synchronous caput (which will wait 
> until the record has finished processing) and then read the value.
> 
> > 
> > Thanks for your help,
> > 
> 
> Have you considered to use asyn and StreamDevice for your IP connected 
> device?
> 
> Dirk