Re: correlations application

[Tim Mooney <mooney@aps.anl.gov>]

Mark Rivers wrote:

> > -----Original Message-----
> > From: tech-talk-bounces@aps.anl.gov 
> > [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of 
> > Christopher Larrieu
> > Sent: Monday, July 30, 2007 12:51 PM
> > To: tech-talk@aps.anl.gov
> > Subject: correlations application
> >
> > Hi,
> >
> > I've been tasked with developing a new correlation 
> > application to replace
> > the storied Correlation Plots from the old SLC control system.
> >
> > My intent was to develop an eclipse-based java app to accomplish this.

I'll guess the easiest and most widely useful choice would be to 
develop an eclipse-based java app that programs sscan records and 
displays their data.

> > However, Earnest Williams and Stephanie Allison suggested 
> > that I should look
> > into sscan and SynApps.
> >
> > While these tools do seem feature-rich, they don't provide 
> > all of the things
> > that we want.  So my questions are
> >
> > (1) can they provide the functionality we want?
> > (2) do we need the functionality that we think we want?
> >
> > The main issues:
> >
> > (a) user-extensibility
> > We want our physicists and other users easily to define 
> > steps, measures, and step functions using tools they are familiar
>
> with, like Matlab.
>
> The sscan record can certainly do that.  It can do conventional linear
> scans (start, stop, step), and also table-mode where a table of target
> positions is downloaded.  We use IDL to generate tables for EXAFS, where
> the step sizes are different in different parts of the scan (pre-edge,
> XANES, EXAFS).

If your users are familiar with EPICS, and particularly with using 
EPICS' run-time programmable records, such as the *calcout records,
they can do a fair amount of scan programming right in the IOC, and
other software in the IOC can easily control the resulting system.

> > (b) beam synchronous data acquisition
> > We need to use our specially developed beam synchronous data 
> > acquisition system to acquire pulse-synchronous data.  How can the
>
> sscan 
>
> > record support this?
>
>
> I think you can do it with a detector trigger, but need more information
> to be sure.

Me too.

> > (c) concurrent use
> > Can one perform multiple scans concurrently with the sscan 
> > record, or must one pre-create multiple instances of the record to
>
> achieve such?
>
> What do you mean by "concurrently".  Really at the same time (then you
> need multiple sscan records) or in quick succession (then one sscan
> record can be used and the parameters changed from the client).  Note
> that sscan records can be nested to generated N-dimensional scans.

I don't understand what's meant here either, but I'll guess you need 
to preload.  Note that a sscan record doesn't take up all that much 
memory until it's actually used, so you can load *lots* of them in 
modern processors, such as the 5100.  (Only the positioner arrays are 
allocated at init time.)  Also note that scan nesting is programmable 
at run time, so you don't need to load a bunch of 1D scans, and a 
separate bunch of 2D scans.

> > (d) data types
> > Can this system retrieve data of types other than simple numbers?
>
>
> Yes, it can retrieve arrays.  The detector readback fields are doubles,
> so it cannot handle strings, for example.
>
>
> > (e) design philosophy
> > Is it a good idea to put this sort of functionality in an 
> > IOC?  It seems sort of limiting to me.  Why do it?  Is it a matter of
>
> using 
>
> > the tools at hand, or are there more compelling reasons that I don't
>
> see, 
>
> > being mostly unfamiliar with IOC level applications?
>
>
> It was designed this way for performance.  If all of the things being
> scanned are in that IOC (which they do not have to be) then scans of
> hundreds of points per second can be achieved.  This is difficult to do
> over the network from a client.
>
> Now that we have soft IOCs, if you don't have strict performance
> requirements, then you don't need to put the scans in the real-time
> (RTEMS, vxWorks) IOC, but rather run them on a workstation IOC (Linux,
> Windows, etc.)

One very nice thing about IOC-level applications is that they are 
automatically middleware.  Thus, they can drive lower-level software, 
or be driven by higher-level software, or both.  So an IOC-level 
application can easily become a building block in someone else's new 
design.  For example, someone might want to implement automated 
alignment, using data from a series of scans.  The job would be much 
easier if one could simply reuse existing scan software.

If you implement scans in a client outside of an IOC, you can 
certainly engineer this sort of capability in, but you have to do it 
on purpose, it's not a bit easy, and you don't get as much help from 
EPICS' core (e.g., Channel Access, putNotify, automatic data-type 
conversion, access security, and all the other nice things we've come 
to take for granted in EPICS) or from other EPICS support (e.g., 
save/restore, stripTool, MEDM, probe, archivers).

If scans are implemented in an IOC, then "everybody" already knows how 
to talk to them, and can do it easily from EPICS, IDL, Python, Java, 
Igor, Matlab, SNL, etc.

--
Tim Mooney (mooney@aps.anl.gov) (630)252-5417
Beamline Controls & Data Acquisition Group
Advanced Photon Source, Argonne National Lab.