The actual MCA-3 software is able to save in sequential mode individual
spectra immediately after each completed cycle and this way allows very
low deadtime between individual measurements (about 14 msec for 2k
spectra). Here is part of the readme file describing the news (see
especially first part at v 3.05):
Server v 3.06 (Sep-25-2009):
- New commands:
qdac+=val
increments qdac (DAC2) by the (decimal) value val.
oncycle command
executes "command" after a cycle end in sequential mode.
It is possible to enter up to 512 different such commands, each can
be maximal 20 character long. The next in the series will be executed
after the next cycle. When the last such entered command was executed
the first one will be executed again after the next cycle.
oncycle off
switches off the oncycle command executing.
Server v 3.05 (Aug-25-2009):
- A new checkbox "Save Cycle" in the Settings dialog allows in
sequential MCS mode an automatic saving of each row in the 2D
spectra immediately when it is acquired. The filename is made from
the standard data filename by attaching _00000, _00001,...
- The "highrate" option for MCS listmode with more than 255 counts
per bin now can be edited in the Settings dialog (see below at v 2.87).
The dwelltime must be > 2 mikrosec, otherwise a warning will be shown.
If short acquisitions with a spectra length between 2k and 16k are
started, stopped, saved and erased, this costs acually a time of about
200..300 msec. But if sequential mode is used, it is for example possible
to acquire 256 2k spectra into the card RAM with a dead time of only about
14 msec for switching the acquisition from one row to the next. The long
dead time for single acquisitions comes from the mechanism of starting and
stopping Windows threads that do the reading and evaluation of data in a
polling loop. These threads are not stopped and restarted when using
sequential mode and this way it can be done much faster. If the card RAM
is full, you could either stop, save, erase and restart, which cost about
5.8 seconds (1.6 sec just for erasing), or continue the acquisition in a
new sequence without erasing the RAM. If you have the old RAM content
saved in your application you could subtract the old values and this way
run the system with pretty low deadtime. I did my tests using the
built-in command language using loops with a script like loop.ctl with a
command line "onstop start" for acquisition loops with erasing or "onstop
cont" without erasing. (This works only with the latest release that can
be downloaded from our website). The precise time of start and stop
can be seen in the first comment line.
