Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018 
<== Date ==> <== Thread ==>

Subject: Re: AW: SIS3820 scaler limits
From: Mark Davis <davism50@msu.edu>
To: matthias.kirsch@struck.de
Cc: tech-talk@aps.anl.gov
Date: Mon, 01 Apr 2013 11:55:24 -0400
Another (perhaps wild) thought:

I know absolutely nothing about RTEMS or about the VME bus (yet), but I was wondering if the following might be possible:

* Use 2 channels: 1 to count the onboard reference clock, 1 to count the detector pulses * Use the 100Hz external start-of-particle-bunch signal to trigger an interrupt that continually does a read-on-the-fly operation for 1us then exits (also clear the counters if that doesn't introduce too much delay)

The counts for the reference clock channel would answer the question of what period of time was covered by each of the detector counts, and the difference between successive detector counts would indicate how many occurred since the last read-on-the fly.

The major questions are:
* How frequently the interrupt routine could do these reads? It only needs to read a handful of bytes each time, but I don't know what doing so over the VME bus entails and what delays that might introduce. * What kind of latency might there be before the interrupt routine begins executing? * How much variation is there likely to be in the difference between successive clock counts (for a single run of the interrupt routine)?
  * How useful the results would be if there is significant variation?

If this is even feasible, the last one is more a question for our folks. I am assuming that, given enough data points, the desired information can be derived from a large enough sample of counts even though the relative start and end period for those counts may vary quite a bit.

This approach would have the advantage over the target-one-specific-sub-microsecond-period-each-pass approach of not loosing any counts for a given 1us "scan". But I will have to find out from our physics people as to whether that would be better or worse than (possibly much larger) variations in the start and end times for each sub-microsecond period.


NOTE: The CPU card currently being used is an Emerson MVME3100 and it is running RTEMS (I don't yet know how much memory it has or what the processor speed is).

Anyone have any idea if this approach is even feasible? Or what detrimental effects there might be to allowing an interrupt routine to run non-stop for 1us once every 10ms (assuming RTEMS will even allow me to do that)?


Mark Davis
NSCL/FRIB




On 3/31/2013 2:42 AM, Dr. Matthias Kirsch wrote:
Hello,
at 20 ns or 50 MHz we are rather looking at a time stamper application.
You basically need a 50 MHz clock running and latch the clock value with a
count coming in.
As long as the average rate is not too high that can be done with a
dedicated firmware for the SIS3820 too.
Best regards
Matthias


-----Ursprüngliche Nachricht-----
Von: Mark Rivers [mailto:rivers@cars.uchicago.edu]
Gesendet: Sonntag, 31. März 2013 04:32
An: Mark Davis; tech-talk@aps.anl.gov
Cc: Matthias Kirsch
Betreff: RE: SIS3820 scaler limits

Hi Mark,

I've thought about this a little more, and I realized that you can actually
get better time resolution than the minimum dwell time, assuming that your
signal is repetitive and you can spend some "extra" time measuring it.

This technique would require a 2-channel external programmable pulse and
delay generator like the one I referenced in my previous message.

The first output of the pulse generator would be a train of short pulses
that goes to the LNE.  The pusle train would repeat every 10 ms.  Using
32-bit mode and 8 input channels, which my existing driver supports, the
minimum dwell time from the SIS3820 manual is 340 ns.  If the driver is
changed to support 8-bit mode the minimum dwell time decreases to 220 ns for
8 channels.  The pulses in the pulse train for LNE would be limited to this
pulse spacing.  Neither of these values is close to your desired value of 20
ns.

However, you could also provide a second output from the pulse generator
which goes to the "counter inhibit" input of the SIS3820.  This signal could
enable counting for a much shorter period of time, say 20 ns or 50 ns.  With
the pulse generator you can adjust the time delay between the LNE signal and
the "counter inhibit" signal.

Thus, you can acquire for some period of time with the delay=0.  Then adjust
the delay to 20 ns or 50 ns and acquire again.  Adjust again to 40 ns or 100
ns, etc.  In this manner you can get time resolution down to 20 ns by doing
successive acquisitions with different delays between the two signals.

This assumes of course that the signal you are trying to count is stable for
some period of time so you can acquire repetitively.

Can you describe more the signal you are trying to measure: what is the
frequency and how long is it "stable"?

Mark

________________________________
From: Mark Rivers
Sent: Saturday, March 30, 2013 8:35 AM
To: Mark Davis; tech-talk@aps.anl.gov
Cc: Matthias Kirsch
Subject: RE: SIS3820 scaler limits

Hi Mark,

I'll try to address your questions.

First, you want to start a new time-sweep every 10 ms, and capture the
counts for 1 ms with as short a time per point as possible.  I think the
easiest way to make the SIS3820 do that is to use an external programmable
pulse generator.  I have an EPICS driver for the Berkeley Nucleonics BNC-505
pulse generator. It costs about $2,000. It is in the synApps delayGen
module:

http://www.aps.anl.gov/bcda/synApps/delaygen/delaygen.html

This module can take your 10 ms pulse as a trigger and output a pulse stream
for 1ms with a programmable period, say 500ns or 200ns.  This pulse stream
would then go to the SIS3820 which would be operated in external channel
advance mode, not using the internal time base.

For what you want to do, my existing SIS3820 driver has 2 limitations that
could be overcome relatively easily.

1) It only works in 32-bit mode, not 16-bit or 8-bit mode.  That limits the
minimum dwell time to just under 1 microsecond I believe.  It would be
relatively easy to support the 16-bit and 8-bit modes, it just requires
unpacking the data differently.

2) It only acquires a "one-shot" time series before it needs to be re-armed
in software.  It does not support continuous acquisition with multiple
buffers streaming to disk or updating waveform records continuously.  It
does allow very long time series, limited only by RAM in the IOC.  I have
tested 10 million time samples on 2 input channels.  But this feature is
also easy to add.  The driver currently derives from the asynPortDriver base
class in asyn.  If instead it were derived from the asynNDArrayDriver in
areaDetector the data could be packed into NDArray objects and any of the
areaDetector plugins could be used.  This includes:
   - File plugins to stream the data to disk continuously
   - NDPluginStdArrays plugin to send the data stream to channel access
clients through waveform records
   - NDPluginProcess plugin to do summing, averaging, etc. on the data
   - NDPluginStats plugin to calculate statistics on the data

My new quadEM module does exactly these things, since it derives from
asynNDArrayDriver:

http://cars9.uchicago.edu/software/epics/quadEM.html

Can someone explain the LNE (Load Next Event) concept?
  Depending the context it is used in, it seems that sometimes it means
to advance which channel's count is being incremented, and other times it
seems to mean copy the counts to the FIFO.

There are 2 possible meanings of "channel".
1) The time-bin or time-point, which can range from 0 to a very large number
2) The TTL hardware input channel, which ranges from 0 to 31

Is either of these correct?  Does it mean something different for
different modes?  When does it apply and when does it not?

The LNE increments the "channel" in meaning 1) above, i.e. the time bin.  It
also copies the counts to the FIFO when the SIS3820 is operating in FIFO
mode, which is the mode my driver uses.  The LNE signal cause the SIS3820 to
take the current counts in all the enabled channels, and copy them to the
FIFO.  It is then effectively counting in the new time bin.

The minimum dwell times for the "Histogramming Scaler mode (MCS with add
enabled)" are longer than those for the MCS mode with the same number of
channels and counter depth.  Why is that?
What IS the minimum dwell time for counting on a single channel?
I don't know the answers to those questions, hopefully Matthias can answer
them.

Mark


________________________________
From: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on
behalf of Mark Davis [davism50@msu.edu]
Sent: Friday, March 29, 2013 2:57 PM
To: tech-talk@aps.anl.gov
Subject: SIS3820 scaler limits

I am new to synApps and use of scaler/counters, etc. and I have some
questions regarding the use and capabilities of the SIS3820 VME scaler and
its driver.

Our current setup for the project I am working on is a VME crate with an
Emerson MVME3100 CPU board, an SIS3820 scaler, and a Hytec VDD2670 DAC.
Don't know at the moment how much memory the CPU card has, or if the memory
card on the 3820 is larger than 64M.  The CPU is running RTEMS rather than
VxWorks.

The use of this setup is currently a fairly straightforward scan (using
sscan records) where the DAC output is ramped over a range of values, and a
new count captured at the end of each acquisition period (dwell time) during
which the DAC output is stable.  The dwell time is currently hundreds of
milliseconds, so nothing that even comes close to the limits of the scaler
card.

But the next step is to support the following scenario:

   *   An external pulse indicates when to start counting the number of
events on a single channel.  This pulse will repeat about every 10ms (100
Hz)

   *   For each external pulse, begin counting event pulses on the one
channel.  At regular intervals, capture the current counter value (doesn't
matter if it is reset at the start of each period, although I am guessing
that NOT resetting it is probably safer, as it would be less likely to miss
an event close to the start of the next interval).

   *   Continue this for a specified number of the regular intervals, then
stop capturing the counter value until the next external pulse

Basically there will be an external pulse once every 10ms that indicates the
start of a 1ms long period of interest.  During that 1ms period, we need to
capture the state of the counter as often as possible (minimum dwell time),
but at regular intervals.

The original specs called for the dwell time to be 20ns, but after looking
over the specs on the 3820, it seems that is not possible.

So here are my questions:

   *   What IS the minimum dwell time for counting on a single channel?  The
smallest one indicated in the documentation says 220ns for 8 channels (using
8-bit counts, which - as the doco points out - is more than large enough for
such short dwell times).  Can this be made even smaller when we really only
need to count 1 channel?  Or maybe 2, if we needed to also count 50MHz
pulses on channel 1 to use as a time reference?

   *   The minimum dwell times for the "Histogramming Scaler mode (MCS with
add enabled)" are longer than those for the MCS mode with the same number of
channels and counter depth.  Why is that?  Is it really doing an addition
operation that is taking up time?  I would have thought that the Histogram
mode would be the same as the MCS mode except that you do NOT take the time
to clear the counts (expect prior to the first scan).  And to guard against
incrementing the counts between scans, simply disabling the inputs or
counting of them would do the job.  So unless disabling the counting between
scans takes a lot longer than clearing them at the start of each scan, I
would think that the Histogram mode would have the same or shorter dwell
times than MCS mode, not LONGER!  Why is it the other way around?

   *   Is it possible to get at least the 220ns dwell time performance using
the existing driver, or would I have to modify it?

   *   If modification is not needed, how do I get it do do the MCS mode with
8-bit counts and the 220ns dwell time?

   *   If I modified the driver, could I get even smaller dwell times
(without changing the firmware/FPGA programming)?

   *   Can someone explain the LNE (Load Next Event) concept?  Depending the
context it is used in, it seems that sometimes it means to advance which
channel's count is being incremented, and other times it seems to mean copy
the counts to the FIFO.  Is either of these correct?  Does it mean something
different for different modes?  When does it apply and when does it not?

Probably more questions as I dig in to this some more, but any pointers,
explanations, insights, suggestions, etc  would be much appreciated.

Thanks,

Mark Davis
NSCL, MIchigan State University






References:
SIS3820 scaler limits Mark Davis
RE: SIS3820 scaler limits Mark Rivers
RE: SIS3820 scaler limits Mark Rivers
AW: SIS3820 scaler limits Dr. Matthias Kirsch

Navigate by Date:
Prev: AW: SIS3820 scaler limits Dr. Matthias Kirsch
Next: Stream Device errors and record initialization Christian Roehrig
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018 
Navigate by Thread:
Prev: AW: SIS3820 scaler limits Dr. Matthias Kirsch
Next: Re: SIS3820 scaler limits Mark Davis
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018 
ANJ, 20 Apr 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·