XPS email exchange with Mark Rivers

Subject:
RE: EPICS support for XPS
From:
"Mark Rivers" <rivers@cars.uchicago.edu>
Date:
Tue, 19 Apr 2011 13:16:37 -0500
To:
"Hovanes Egiyan" <hovanes.egiyan@gmail.com>

The FIFO filling up is never a problem on either the old or new driver.

In the old driver the FIFO is read out under the following
circumstances:

- Any MCA record reads its data
- The FIFO is almost full (a hardware interrupt)

The FIFO is read out into the driver's internal memory buffer, which is
then copied to the MCA records when they process.

On the SIS3820 the FIFO can be huge.  The standard is 64MB, and 512MB is
available as an option (which we have).

On the SIS3820 I can now collect 2 MCA records (2 SIS3820 inputs) with 2
million points each, and have a time per point of 1 microsecond.  Thus,
I am collecting 4 million points (16MB) in 2 seconds.  It works fine.

The code is in the motor module (for the trajectory scanning and XPS
driver) and the MCA module (for the SIS3820/3801 support).  Both are
available from the APS Subversion respository:

https://subversion.xor.aps.anl.gov/synApps/motor


https://subversion.xor.aps.anl.gov/synApps/mca/


Mark


-----Original Message-----
From: Hovanes Egiyan [mailto:hovanes.egiyan@gmail.com] 
Sent: Tuesday, April 19, 2011 12:43 PM
To: Mark Rivers
Subject: Re: EPICS support for XPS

Hi Mark,

I was thinking about the finite size of the FIFO which would have to be 
less than the number
of data points for a single reading. if there are 1000 data points
in each trajectory element, and there are many elements then there could

be a possibility
of filling up the scaler FIFO, which is usua lly ~65K long,depending on 
the installed memory.
But if you never ran into it, we probably won't have that problem in our

simpler
application here with ~10K data points.

I think now I have a basic idea how your application works, and it 
matches well with what
we would like to have. Would we be able to download and use your whole 
application as
the basis if we decide to use the XPS option?

Thanks again for you time,
         Hovanes.


On 04/19/2011 12:21 PM, Mark Rivers wrote:
> > Hi Hovanes,
> >
>> >> Is my understanding correct that now you are using the output pulse
of
>> >> XPS  to strobe the multi-channel scaler, and then monitor in SNL for
> > "mca.ACQG"
>> >> to be zero, which happens after a "long" DAQ time interval of the
> > scaler manually
>> >> set to match the pulse period and the scaler FIFO?
>> >> At that moment you read the scaler and XPS , and match the
>> >> two buffers, and reset the scaler acquisition. At that
>> >> time you also set the fields of the motors records from SNL.
> > I'm not quite sure I understand the question.  We don't need to
manually
> > set the scaler to match the pulse period.  The SIS3801/SIS3820 uses
the
> > XPS pulses to advance to the next memory location in its internal
> > buffer.  There is no preset time that the scaler counts for; it is
> > counting its 32 TTL inputs (up to 100MHz) into bin 0 for each, then an
> > XPS pulse arrives and it counts them into bin 1, etc.  The SNL program
> > thus does not need to do anything at each point in the scan, it is
> > completely driven by hardware.  Only at the end of the scan does it
read
> > out the actual motor positions and the scaler count arrays.
> >
> > The XPS can only output pulses at evenly spaced times, not distances,
at
> > least in the multi-axis PVT groups that we use.  This is a drawback, I
> > agree.  The older Newport MM4005 could put out pulses at constant
> > distance, rather than constant time.  But one could question what a
> > "distance" is in 8-dimensional space.  Is it the path integral?  What
if
> > the units or even dimensions of the axes are not the same, i.e. what
is
> > a "distance" of a 2-axis non-linear move where one axis is in degrees
> > and the other is in mm?
> >
> > Mark
> >
> >
> >
> >
> > -----Original Message-----
> > From: Hovanes Egiyan [mailto:hovanes.egiyan@gmail.com]
> > Sent: Tuesday, April 19, 2011 10:21 AM
> > To: Mark Rivers
> > Subject: Re: EPICS support for XPS
> >
> > Hi Mark,
> >
> > thanks for your prompt response. I am glad to hear that you have a
> > similar
> > application, this means that there should not be serious problems for
> > us. In fact,
> > the current application is a lot more sophisticated that what we need,
> > which are
> > simple beam profile scans with thin wires. I think you already have
all
> > we need.
> >
> > I was assuming that I would have to use SNL for this application
simply
> > because of the fast frequency (>10Hz) at which the scaler might need
to
> > be read
> > (which apparently is not the case if the synchronized output pulses
are
> > used).
> > Is my understanding correct that now you are using the output pulse of
> > XPS  to strobe the
> > multi-channel scaler, and then monitor in SNL for "mca.ACQG" to be
zero,
> > which happens after a "long" DAQ time interval of the scaler manually
> > set to match the pulse
> > period and the scaler FIFO? At that moment you read the scaler and XPS
,
> >
> > and match the
> > two buffers, and reset the scaler acquisition. At that
> > time you also set the fields of the motors records from SNL.
> >
> > Going through the description of the current support I read that  XPS
> > output
> > pulses are only evenly spaced in time, while on the Newport web page I
> > read that both
> > space and time spacing can be achieved.  I actually would prefer
> > scanning  with output
> > pulses generated at traveling certain distance if possible.
> >
> > I will try to browse the new source code, but I am not familiar with
> > asynPortDriver.
> > This could turn out to be a good time investment though, and being
able
> > to skip SNL
> > code would be nice.
> >
> > Thanks,
> >       Hovanes.
> >
> >
> > On 04/18/2011 04:43 PM, Mark Rivers wrote:
>> >> Hi Hovanes,
>> >>
>> >> We are using the XPS, and have generally been happy with them, though
>> >> they do have a few features we don't like.
>> >>
>> >> We do exactly the type of synchronization of a VME scaler (the
> > SIS3820)
>> >> with pulse outputs from the XPS that you are talking about.  We also
>> >> capture the actual encoder positions in the XPS when those pulses are
>> >> output.
>> >>
>> >> The documentation on that aspect of the controller in the current
>> >> support is here:
>> >>
>> >> http://cars9.uchicago.edu/software/epics/trajectoryScan.html
>> >>
>> >> If you read that document you will see that the current support for
> > this
>> >> on-the-fly scanning with position capture is base on an SNL program
> > that
>> >> talks directly to the controller, "behind the back" of the EPICS
motor
>> >> record driver.
>> >>
>> >> This is not a good idea, so I am in the middle of developing a new
> > model
>> >> for EPICS motor support.  It is written in C++ and uses the
>> >> asynPortDriver base class.  The new model supports coordinated
motion,
>> >> pulse output, and capturing actual motor positions in the driver
> > itself.
>> >> There is some documentation for this new driver model here:
>> >>
>> >>
> >
http://cars9.uchicago.edu/software/epics/motorDoxygenHTML/class_x_p_s_co
>> >> ntroller.html
>> >>
>> >> This documentation is done by doxygen based on comments in the source
>> >> code, and it still needs work.
>> >>
>> >> The coordinated motion, pulse output, and capturing features are now
>> >> working in the new XPS driver, though more work and testing is
needed.
>> >>
>> >> Let me know if you have more questions.
>> >>
>> >> Cheers,
>> >> Mark
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: Hovanes Egiyan [mailto:hovanes.egiyan@gmail.com]
>> >> Sent: Monday, April 18, 2011 1:14 PM
>> >> To: Mark Rivers
>> >> Subject: EPICS support for XPS
>> >>
>> >> Dear Mark,
>> >>
>> >> I work for Jefferson Lab in Newport News Virginia, and our group is
>> >> considering
>> >> using Newport XPS controller for some of our motorized application in
>> >> the beamline.
>> >> But we never used this device, and I do not know how well its EPICS
>> >> support is.
>> >> Considering its price I would like to have some idea of what we can
do
>> >> with it before
>> >> purchasing one of those modules and cards. From your posts I
> > understand
>> >> that you are using it
>> >> with EPICS, and I would  like to know what your general impressions
> > are
>> >> about this device.
>> >>
>> >> One of our applications would require synchronizing  VME-based read
> > out
>> >> of scalers from a data acquisition system with  precise 1D position
>> >> (<30mu) of a motor every ~
>> >> 50 msec. I was wondering if you used any of the synchronizing
features
>> >> like " one dedicated TTL
>> >> trigger output per axis that can be either configured to output a
> > single
>> >> pulse when
>> >> crossing a specified position or output continuous pulses at
specified
>> >> distance intervals",
>> >> or the position capturing  on receiving an external trigger. Although
> > I
>> >> have some understanding
>> >> how this can be achieved in principle, I have no idea if and how this
> > is
>> >> implemented in EPICS.
>> >> If there is a documentation on EPICS support of this controller I
> > would
>> >> appreciate if you could
>> >> point me to it.
>> >>
>> >> Thanks in advance,
>> >>            Hovanes.