Experimental Physics and
Industrial Control System

Tim Mooney <[email protected]> · Mon, 30 Jul 2007 17:19:09 -0500

Mark Rivers wrote:
-----Original Message-----

From: [email protected]
[mailto:[email protected]] On Behalf Of
Christopher Larrieu

Sent: Monday, July 30, 2007 12:51 PM

To: [email protected]

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 ([email protected]) (630)252-5417
Beamline Controls & Data Acquisition Group
Advanced Photon Source, Argonne National Lab.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System