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.
- Replies:
- RE: correlations application Dalesio, Leo `Bob`
- RE: correlations application Mark Rivers
- References:
- Re: correlations application Tim Mooney
- Navigate by Date:
- Prev:
Re: correlations application Pete R. Jemian
- Next:
RE: correlations application Dalesio, Leo `Bob`
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
<2007>
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: correlations application Pete R. Jemian
- Next:
RE: correlations application Dalesio, Leo `Bob`
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
<2007>
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|