Experimental Physics and
Industrial Control System

"Dalesio, Leo `Bob`" <[email protected]> · Tue, 31 Jul 2007 06:07:35 -0700

It seems reasonable to allow the correlation plot to either collect channels in the client - or delegate the collection of the data to a remote server. This allows the correlation plot to either run on top of a channel based protocol - or to allow the low level application to collect the data in the case where the server is better suited. I can think of cases when both are useful and I think that they've been commented on in this email thread.

Running in the server allows more efficient collection of the data to take place below the correlation plot - less latency, less use of network and host resources, use of distributed data collection tailored to the application collecting the data.

Running in the client allows more flexibility. If the data can be collected sample by sample on the client side, the correlation plot can handle it.

I assume that the correlation plot using a time stamp / scalar value array - is this correct?
Does it also need to integrate fast data that currently comes from EPICS as a time stamp / vector (where no period between samples is provided)? If so, how are you handling the time between samples?

Bob

________________________________

From: [email protected] on behalf of Christopher Larrieu
Sent: Mon 7/30/2007 4:17 PM
To: Tim Mooney
Cc: [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