Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Tue, 31 Jul 2007 09:40:20 -0500

Chris,

Before you rule out sscan you should consider some of the problems you
will have if you do need to scan EPICS PVs as positioners and read EPICS
PVs as detectors.  How will you know when the positioner PV is "done"?
Polling is slow, and prone to error because you may think it is done
when it has not actually started to move yet.  The same is true for
detectors:  in many cases you need to start the detector counting and
wait for it to finish.  EPICS has a mechanism for dealing with this
(ca_put_callback) that the sscan record is well-designed to exploit.  It
is non-trivial to come up with a robust solution like that in a client
that is general, i.e. can scan any EPICS PV as a positioner and read any
EPICS PV as a detector.

Mark

> -----Original Message-----
> From: Christopher Larrieu [mailto:[email protected]] 
> Sent: Monday, July 30, 2007 6:17 PM
> To: Tim Mooney
> Cc: Mark Rivers; [email protected]
> Subject: Re: correlations application
> 
> Thanks for the feedback.
> 
> By "run concurrently", I mean "support several users running 
> a correlation
> experiment simultaneously".
> 
> Based on the feedback I've had so far, it seems that the 
> sscan record is
> great if you're fully invested in EPICS.  Mainly, I was 
> curious if any of
> the EPICS-friendly tools offer sufficiently compelling 
> functionality that it
> makes sense to start with them.
> 
> But I don't see that there would be much benefit in architecting an
> application around the sscan record, since our aim is to provide a
> significant level of functionality above step-and-measure, we 
> are not 100%
> channel access.
> 
> Chris 
> 
> 
> 
> 
> 
> On 7/30/07 3:19 PM, "Tim Mooney" <[email protected]> wrote:
> 
> > 
> > 
> > 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.
> 
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System