Experimental Physics and
Industrial Control System

"Mark S. Engbretson" <[email protected]> · Fri, 14 Apr 2017 11:07:38 -0500

I am assuming that how does Area Detector or Camera values actually end up
in EPICS hosted PV's?

It all happens down in the template files and the db's. The AD has actually
already  links to all possible commands that you intend to use, what their
data types are, storage spaces, and at  a handful of places in the AD
sources, changes or updates to paramters perculate up and down into the
PV's. In the example below , most probably readfloat64 or writefloat64, you
should read or set something which rather auto-magically then ends up in
EPICS.

Example:

record(ao, "$(P)$(R)DelayTime") 
45 { 
46     field (DESC, "Delay after trigger") 
47     field (DTYP, "asynFloat64") 
48     field (OUT,  "@asyn($(PORT),$(ADDR),$(TIMEOUT))SD_DELAY_TIME") 
49     field (EGU,  "s") 
50     field (PREC, "4") 
51     field (VAL,  "0.1") 
52     field (PINI, "YES") 
53 } 
54 

55 record(ai, "$(P)$(R)DelayTime_RBV") 
56 { 
57     field(DESC, "Delay after trigger") 
58     field(DTYP, "asynFloat64") 
59     field(INP,  "@asyn($(PORT),$(ADDR),$(TIMEOUT))SD_DELAY_TIME") 
60     field(EGU,  "s") 
61     field(PREC, "7") 
62     field(SCAN, "I/O Intr") 
63 }

-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Iain Marcuson
Sent: Friday, April 14, 2017 10:51 AM
To: Mark Rivers <[email protected]>; [email protected]
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:[email protected]]
> Sent: Tuesday, April 11, 2017 5:16 PM
> To: Iain Marcuson <[email protected]>; tech- 
> [email protected]
> 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:[email protected]]
> Sent: Tuesday, April 11, 2017 3:54 PM
> To: Mark Rivers; [email protected]
> 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.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System