Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017 Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
<== Date ==> <== Thread ==>

Subject: RE: Writing Area Detector Monitor
From: Mark Rivers <rivers@cars.uchicago.edu>
To: Iain Marcuson <Iain.Marcuson@sydorinstruments.com>, "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Fri, 14 Apr 2017 17:38:05 +0000
Hi Iain,

I think the answer to your question is that the C/C++ interface is asynPortDriver http://www.aps.anl.gov/epics/modules/soft/asyn/R4-31/asynPortDriver.html

Here is what happens for an ao output record with asynFloat64 device support.

- Write to record
- Record calls standard asynFloat64 device support
- Device support calls the asynFloat64->write() method, which is implemented in asynPortDriver
- asynPortDriver calls the writeFloat64 method in the derived class C++ driver.  This is the Mythen driver.

For an ai input record with SCAN=I/O Intr the chain is this:

- Derived class driver calls asynPortDriver::setDoubleParam, and then asynPortDriver::callParamCallbacks()
- asynPortDriver::callParamCallbacks does the callback to the standard asynFloat64 device support
- Device support causes the input record to process to update with the new callback value.

Let me know if you have more questions.

Mark

________________________________________
From: Iain Marcuson [Iain.Marcuson@sydorinstruments.com]
Sent: Friday, April 14, 2017 10:51 AM
To: Mark Rivers; tech-talk@aps.anl.gov
Subject: RE: Writing Area Detector Monitor

I've been studying the Mythen driver, but I am quite puzzled on how the EPICS side talks to the C/C++ side.  Are there any references on the C/C++ bindings?

Thank you,

Iain Marcuson.

> -----Original Message-----
> From: Mark Rivers [mailto:rivers@cars.uchicago.edu]
> Sent: Tuesday, April 11, 2017 5:16 PM
> To: Iain Marcuson <Iain.Marcuson@sydorinstruments.com>; tech-
> talk@aps.anl.gov
> Subject: RE: Writing Area Detector Monitor
>
> Hi Iain,
>
> The drivers which directly receive images over the network are ADPSL,
> ADPixirad,  ADMerlin,  and ADMythen.
>
> Many other drivers receive images over the network, but they do this
> through a vendor API (e.g. ADProsilica, aravisGigE, ADPointGrey, etc.).
>
> If you want to create a driver which works like other areaDetector drivers
> you should not use StreamDevice for the command/response, you should do
> it through the driver itself.  Your driver will receive a call each time the user
> changes things like exposure time, acquire start/stop, frame binning, etc.
> You can talk to the device from your driver using the asynIPPort driver and
> the asynOctetSyncIO interface. All of the drivers I listed above do that so you
> can see how to do it.
>
> Mark
>
>
> -----Original Message-----
> From: Iain Marcuson [mailto:Iain.Marcuson@sydorinstruments.com]
> Sent: Tuesday, April 11, 2017 3:54 PM
> To: Mark Rivers; tech-talk@aps.anl.gov
> Subject: RE: Writing Area Detector Monitor
>
>
> > Do you mean that you have a device that sends images over a network
> > port, and you would like to create an areaDetector driver to receive those
> images?
> > The driver would convert the images into NDArrays in an EPICS IOC, and
> > thus be able to use the areaDetector plugins for file saving, image
> > processing, and sending images to EPICS Channel Access clients, etc.?
> >
>
> The device would send images over a network port, and we would be looking
> to convert them into NDArrays as you describe.
>
> > If this is what you want to do then you can use one of the existing
> > areaDetector drivers as a model.  Those create a complete application
> > to control and read data from a specific type of camera or detector.
> >
> > Can you describe your device a bit more, so I know which existing
> > driver to recommend as a starting point?  Can you control the device
> > from your driver (exposure time, start/stop, etc.)?  If so are those
> > ASCII commands?  Is it TCP/IP or some other protocol?  Is the image data in
> binary?
> >
>
> The device would be controlled via an IOC.  We will likely use Stream Device,
> which we have used successfully for a similar control scheme.  The
> commands would be ASCII based.  The image data is in binary, and at present
> we are looking towards UDP, although we may use TCP.


References:
Writing Area Detector Monitor Iain Marcuson
RE: Writing Area Detector Monitor Mark Rivers
RE: Writing Area Detector Monitor Iain Marcuson
RE: Writing Area Detector Monitor Mark Rivers
RE: Writing Area Detector Monitor Iain Marcuson

Navigate by Date:
Prev: Re: Init pv properly Miguel
Next: Fwd: CSS binary color text Miguel
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
Navigate by Thread:
Prev: RE: Writing Area Detector Monitor Mark S. Engbretson
Next: RE: Writing Area Detector Monitor Iain Marcuson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
ANJ, 14 Apr 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·